[Bug c++/103909] co_yield of aggregate-initialized temporaries leads to segmentation faults.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103909 Iain Sandoe changed: What|Removed |Added Status|UNCONFIRMED |NEW Keywords||wrong-code Last reconfirmed||2022-01-05 Ever confirmed|0 |1 Target Milestone|--- |11.3 --- Comment #1 from Iain Sandoe --- thanks for the report and the reproducer.
[Bug tree-optimization/103899] [12 Regression] make profiledbootstrap fails due to uninitialized warning in expr.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103899
Andrew Pinski changed:
What|Removed |Added
Keywords||missed-optimization,
||needs-bisection
Host|x86_64-linux-gnu|
Component|bootstrap |tree-optimization
Build|x86_64-linux-gnu|
Summary|make profiledbootstrap |[12 Regression] make
|fails due to uninitialized |profiledbootstrap fails due
|warning in expr.c |to uninitialized warning in
||expr.c
Target Milestone|--- |12.0
--- Comment #4 from Andrew Pinski ---
Reduced testcase:
int h;
int l ();
int *k ();
void nn ();
void expand_expr_real_1 (int *exp)
{
int m;
int *context;
m = 2;
if (h || !exp)
m = l ();
if (exp)
context = k ();
if (exp && context && context[0] == 0)
if (m == 0)
nn ();
}
- CUT
Compile with "-O2 -W -Wall -Werror", there is no warning but once you add
-fprofile-generate there is an uninitialized warning for context.
There is a missing jump threading on the trunk which is causing the warning to
show up.
[Bug tree-optimization/103899] [12 Regression] make profiledbootstrap fails due to uninitialized warning in expr.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103899
Martin Liška changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever confirmed|0 |1
Last reconfirmed||2022-01-05
CC||aldyh at gcc dot gnu.org
--- Comment #5 from Martin Liška ---
(In reply to Andrew Pinski from comment #4)
> Reduced testcase:
> int h;
> int l ();
> int *k ();
> void nn ();
> void expand_expr_real_1 (int *exp)
> {
> int m;
> int *context;
> m = 2;
> if (h || !exp)
> m = l ();
> if (exp)
> context = k ();
> if (exp && context && context[0] == 0)
> if (m == 0)
> nn ();
> }
> - CUT
> Compile with "-O2 -W -Wall -Werror", there is no warning but once you add
> -fprofile-generate there is an uninitialized warning for context.
> There is a missing jump threading on the trunk which is causing the warning
> to show up.
Started with r12-4790-g4b3a325f07acebf4, may I remove needs-bisection Keyword?
[Bug target/103910] openjdk17 causes ICE on -O3 -march=opteron -fchecking-new: during GIMPLE pass: aprefetch: in gimple_build_call, at gimple.c:267
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103910 --- Comment #4 from Sergei Trofimovich --- (In reply to Andrew Pinski from comment #3) > This should fix the issue: > apinski@xeond:~/src/upstream-gcc/gcc/gcc/config/i386$ git diff i386.h > diff --git a/gcc/config/i386/i386.h b/gcc/config/i386/i386.h > index f027608eefa..3ac0f698ae2 100644 > --- a/gcc/config/i386/i386.h > +++ b/gcc/config/i386/i386.h > @@ -486,7 +486,7 @@ extern unsigned char ix86_prefetch_sse; > > /* Fence to use after loop using storent. */ > > -extern tree x86_mfence; > +extern GTY(()) tree x86_mfence; > #define FENCE_FOLLOWING_MOVNT x86_mfence > > /* Once GDB has been enhanced to deal with functions without frame This fix helps to build openjdk17 on patched gcc. Thank you!
[Bug libstdc++/103904] [defect fix] Please backport P2325R3 to 10 and 11
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103904 --- Comment #7 from Richard Biener --- Btw, from a RM perspective I'm happy to go with judgement from the libstdc++ folks in whatever direction they want. (not sure if it makes sense or is possible to throw in a non-default -D_LIBSTDCXX_FORCE_OLD_VIEW or so)
[Bug c++/103758] bogus warning: misspelled term 'decl' in format; use 'declaration' instead [-Wformat-diag]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103758 --- Comment #5 from Martin Liška --- Btw. can we remove the last 3 remaining warnings for x86_64 and enabled -Werror=format-diag (at least for bootstrap on x86_64): /home/marxin/Programming/gcc/gcc/c-family/c-pragma.c:774:60: warning: unquoted identifier or keyword ‘ignored_attributes’ in format [-Wformat-diag] /home/marxin/Programming/gcc/gcc/c-family/c-pragma.c:833:61: warning: unquoted identifier or keyword ‘ignored_attributes’ in format [-Wformat-diag] /home/marxin/Programming/gcc/gcc/gimple-ssa-warn-access.cc:2844:30: warning: quoted ‘%s’ directive in format; use ‘%qs’ instead [-Wformat-diag] We've got -Wformat-diag for quite some time, but we haven't enabled -Werror for it yet.
[Bug ada/103014] gnat1 segfaults in tree_could_trap_p when C double parameter, -O2 -gnatn -gnatVa
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103014 Eric Botcazou changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Summary|[11/12 Regression] gnat1|gnat1 segfaults in |segfaults in|tree_could_trap_p when C |tree_could_trap_p when C|double parameter, -O2 |double parameter, -O2 |-gnatn -gnatVa |-gnatn -gnatVa | CC||ebotcazou at gcc dot gnu.org Resolution|--- |WORKSFORME --- Comment #2 from Eric Botcazou --- I can reproduce neither on mainline nor on 11 branch, so this might come from Debian. Please concatenate the sources and upload them as an attachment in the PR next time.
[Bug target/103905] [12 Regression] Miscompiled i386-expand.c with -march=bdver1 and -O3 since r12-1789-g836328b2c99f5b8d
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103905 Uroš Bizjak changed: What|Removed |Added Attachment #52123|0 |1 is obsolete|| Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |ubizjak at gmail dot com --- Comment #8 from Uroš Bizjak --- Created attachment 52127 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52127&action=edit Proposed patch This patch should fix the failure. @Martin: Can you please test this patch?
[Bug target/103771] [12 Regression] Missed vectorization under -mavx512f -mavx512vl after r12-5489
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103771 --- Comment #2 from Hongtao.liu --- (In reply to Tamar Christina from comment #1) > Looks like the change causes the simpler conditional to be detected by the > vectorizer as a masked operation, which in principle makes sense: > > note: vect_recog_mask_conversion_pattern: detected: iftmp.0_21 = x.1_14 > > 255 ? iftmp.0_19 : iftmp.0_20; > note: mask_conversion pattern recognized: patt_43 = patt_42 ? iftmp.0_19 : > iftmp.0_20; > note: extra pattern stmt: patt_40 = x.1_14 > 255; > note: extra pattern stmt: patt_42 = () patt_40; > > However not quite sure how the masking works on x86. The additional > statement generated for patt_42 causes it to fail during vectorization: > > note: ==> examining pattern def statement: patt_42 = () > patt_40; > note: ==> examining statement: patt_42 = () patt_40; > note: vect_is_simple_use: operand x.1_14 > 255, type of def: internal > note: vect_is_simple_use: vectype vector(8) > missed: conversion not supported by target. > note: vect_is_simple_use: operand x.1_14 > 255, type of def: internal > note: vect_is_simple_use: vectype vector(8) > note: vect_is_simple_use: operand x.1_14 > 255, type of def: internal > note: vect_is_simple_use: vectype vector(8) > missed: not vectorized: relevant stmt not supported: patt_42 = > () patt_40; > missed: bad operation or unsupported loop bound. > note: * Analysis failed with vector mode V32QI > > as there's no conversion patterns for `VEC_UNPACK_LO_EXPR` between bool and > a mask. W/ avx512, we're using scalar mode for mask, can we use VEC_UNPACKS_SBOOL_LO_ here? Since we have vec_unpsack_sbool_lo/hi_qi which should be used for conversion from vector<8> to vector<4> . > > which explains why it works for AVX2 and AVX512BW. AVX512F doesn't seem to > allow any QI mode conversions [1] so it fails.. > > Not sure why it's doing the replacement without checking to see that the > target is able to vectorize the statements it generates later. Specifically > it doesn't check if what's returned by build_mask_conversion is supported or > not. > > My guess is because vectorizable_condition will fail anyway without the type > of the conditional being a vector boolean. > > With -mavx512vl V32QI seems to generate in the pattern mask conversions > between vector (8) and without it vector(32) > . I think some x86 person needs to give a hint here :) > > [1] https://www.felixcloutier.com/x86/kunpckbw:kunpckwd:kunpckdq
[Bug target/103905] [12 Regression] Miscompiled i386-expand.c with -march=bdver1 and -O3 since r12-1789-g836328b2c99f5b8d
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103905 --- Comment #9 from Martin Liška --- (In reply to Uroš Bizjak from comment #8) > Created attachment 52127 [details] > Proposed patch > > This patch should fix the failure. > > @Martin: Can you please test this patch? The patch fixes the test-case, thanks!
[Bug target/103895] [12 Regression] ICE in extract_insn, at recog.c:2769 since r12-6071-g19dcecd963295b02
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103895 --- Comment #5 from CVS Commits --- The master branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:4ce3bd7993bc8413197e07c4f54052e4ecaeccaa commit r12-6220-g4ce3bd7993bc8413197e07c4f54052e4ecaeccaa Author: Jakub Jelinek Date: Wed Jan 5 10:03:18 2022 +0100 testsuite: Fix gcc.target/i386/pr103895.c testcase [PR103895] The testcase uses SSE and SSE2 intrinsics, so fails on i686-linux if -msse2 isn't enabled by default. Fixed by adding -msse2 to dg-options. 2022-01-05 Jakub Jelinek PR target/103895 * gcc.target/i386/pr103895.c: Add -msse2 to dg-options.
[Bug tree-optimization/103816] [12 Regression] ICE: in vect_build_slp_tree_2, at tree-vect-slp.c:1748 since r12-1551-g3dfa4fe9f1a089b2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103816 --- Comment #3 from Richard Biener --- Note the access to 'g' makes it larger than half of the address space which makes the program ill-formed.
[Bug target/103905] [12 Regression] Miscompiled i386-expand.c with -march=bdver1 and -O3 since r12-1789-g836328b2c99f5b8d
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103905 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #10 from Jakub Jelinek --- Can we include some testcase into the testsuite?
[Bug libstdc++/103848] [11/12 Regression] std::deque<>::iterator operator- uses "0" for nullptr check, triggers "zero-as-null-pointer-constant" warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103848 --- Comment #9 from Jonathan Wakely --- Either that isn't the correct g++ command, or something in the code you're compiling uses "#pragma GCC diagnostic error ..." to enable the warning. There is no way to get an *error* from a non-default warning in a system header otherwise.
[Bug target/103905] [12 Regression] Miscompiled i386-expand.c with -march=bdver1 and -O3 since r12-1789-g836328b2c99f5b8d
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103905 Uroš Bizjak changed: What|Removed |Added Attachment #52120|0 |1 is obsolete|| --- Comment #11 from Uroš Bizjak --- Created attachment 52128 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52128&action=edit Testcase for the testsuite @Martin: Can you please test attached testcase?
[Bug libstdc++/103848] [11/12 Regression] std::deque<>::iterator operator- uses "0" for nullptr check, triggers "zero-as-null-pointer-constant" warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103848 --- Comment #10 from Jakub Jelinek --- Please rerun that command with -c -o test_allheaders_allheaders.o replaced with -E -dD -o test_allheaders_allheaders.ii Then compress it and attach here.
[Bug fortran/103914] New: -fcheck=do: Problems with omp parallel do construct
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103914 Bug ID: 103914 Summary: -fcheck=do: Problems with omp parallel do construct Product: gcc Version: 10.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: xiao@compiler-dev.com Target Milestone: --- The test case do.f90: program test integer :: i !$omp parallel do do i = 1, 10 call foo(i) end do !$omp end parallel do contains subroutine foo(i) integer :: i i = i + 3 end subroutine end program test When compile it with "gfortran do.f90 -fcheck=do" run a.out, error message is: At line 4 of file do.f90 Fortran runtime error: Loop variable has been modified When compile it with "gfortran do.f90 -fcheck=do -fopenmp" run a.out, no runtime error occur. I have some questions: why the option "-fcheck=do" do not take effect for "parallel do"? Should the option "-fcheck=do" take effect for "parallel do"?
[Bug fortran/103691] [12 Regression] ICE in get_array_ctor_element_at_index, at fold-const.c:13314 since r12-4694-gcb153222404e2e14
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103691 --- Comment #7 from CVS Commits --- The master branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:a4c2e62d60f47d47cdd94951e16b0de50495cdab commit r12-6221-ga4c2e62d60f47d47cdd94951e16b0de50495cdab Author: Jakub Jelinek Date: Wed Jan 5 10:45:26 2022 +0100 gimple-fold: Remove incorrect folding of debug stmts [PR103691] For ADDR_EXPR gimple_debug_bind_get_value fold_stmt_1 uses maybe_canonicalize_mem_ref_addr earlier and I think that should resolve the concerns raised in PR52329. But folding ADDR_EXPR operand using maybe_fold_reference and then taking address of that looks like an invalid transformation, it can transform # DEBUG D.4293 => &a[0] into # DEBUG D.4293 => &2.0e+0 etc., all we want to allow are the lhs folding of the operand which maybe_fold_reference no longer does since r12-21-g0bf8cd9d5e8ac. 2022-01-05 Jakub Jelinek PR fortran/103691 * gimple-fold.c (fold_stmt_1): Don't call maybe_fold_reference for DEBUG stmts with ADDR_EXPR gimple_debug_bind_get_value, it can do unwanted rhs folding like &a[0] into &2.0 etc. * gfortran.dg/pr103691.f90: New test.
[Bug fortran/103691] [12 Regression] ICE in get_array_ctor_element_at_index, at fold-const.c:13314 since r12-4694-gcb153222404e2e14
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103691 --- Comment #8 from Jakub Jelinek --- Regression now fixed though it would be nice to fix the FE too.
[Bug tree-optimization/103903] Loops handling r,g,b values are not vectorized to use power of 2 vectors even if they can
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103903 Jan Hubicka changed: What|Removed |Added Resolution|--- |INVALID Status|NEW |RESOLVED --- Comment #3 from Jan Hubicka --- Aha, sorry. I did not spot the typo in cut&paste. Unrolling is fine. I need to figure out why in the real testcase we don't do the same transformation.
[Bug tree-optimization/53947] [meta-bug] vectorizer missed-optimizations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53947 Bug 53947 depends on bug 103903, which changed state. Bug 103903 Summary: Loops handling r,g,b values are not vectorized to use power of 2 vectors even if they can https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103903 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |INVALID
[Bug middle-end/39075] alignment for "unsigned short a[10000]" vs "extern unsigned short a[10000]"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=39075 Andrew Pinski changed: What|Removed |Added Target||x86_64 Known to work|8.1.0 | --- Comment #4 from Andrew Pinski --- GCC 8 (because of r8-376) and above produce: .L2: movups %xmm0, (%rax) addq$16, %rax cmpq%rax, %rdx jne .L2 So an unaligned store but it should be still an aligned store.
[Bug middle-end/39075] alignment for "unsigned short a[10000]" vs "extern unsigned short a[10000]"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=39075 --- Comment #5 from Andrew Pinski --- (In reply to Andrew Pinski from comment #4) > So an unaligned store but it should be still an aligned store. Because of the ABI that is.
[Bug target/103905] [12 Regression] Miscompiled i386-expand.c with -march=bdver1 and -O3 since r12-1789-g836328b2c99f5b8d
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103905 --- Comment #12 from Martin Liška --- (In reply to Uroš Bizjak from comment #11) > Created attachment 52128 [details] > Testcase for the testsuite > > @Martin: Can you please test attached testcase? The test fails w/o the patch and works with the patch candidate!
[Bug libstdc++/103853] std::forward_list::merge should check if __list != this
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103853 --- Comment #3 from Jonathan Wakely --- N.B. this is https://cplusplus.github.io/LWG/issue3088 Currently the standard actually requires that x.merge(x) does x.clear() which is obviously not what we want.
[Bug tree-optimization/41486] cselim is not dse aware
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=41486 Andrew Pinski changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE --- Comment #5 from Andrew Pinski --- So this was fixed in GCC 4.8 by the patch which fixes PR 52448. It is actually an exact dup of bug 52448 really. Even though PR 52448 is newer than this bug, it records the revision where the fix occured, so closing as a dup of bug 52448. *** This bug has been marked as a duplicate of bug 52448 ***
[Bug tree-optimization/52448] [4.7 Regression] cselim broken with calls
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52448 Andrew Pinski changed: What|Removed |Added CC||chrbr at gcc dot gnu.org --- Comment #13 from Andrew Pinski --- *** Bug 41486 has been marked as a duplicate of this bug. ***
[Bug target/103915] New: [12 Regression] ICE: SIGSEGV in memory_operand with -flive-range-shrinkage
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103915 Bug ID: 103915 Summary: [12 Regression] ICE: SIGSEGV in memory_operand with -flive-range-shrinkage Product: gcc Version: 12.0 Status: UNCONFIRMED Keywords: ice-on-valid-code Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: zsojka at seznam dot cz CC: ubizjak at gmail dot com Target Milestone: --- Host: x86_64-pc-linux-gnu Target: x86_64-pc-linux-gnu Created attachment 52129 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52129&action=edit reduced testcase Compiler output: $ x86_64-pc-linux-gnu-gcc -flive-range-shrinkage testcase.c -wrapper valgrind,-q ==29614== Invalid read of size 2 ==29614==at 0x12BBDFA: memory_operand(rtx_def*, machine_mode) (recog.c:1812) ==29614==by 0x1AE5525: get_attr_memory(rtx_insn*) (i386.md:5096) ==29614==by 0x1EF0820: insn_default_latency_generic(rtx_insn*) (i386.md:19503) ==29614==by 0x231B911: insn_sched_cost(rtx_insn*) (haifa-sched.c:1421) ==29614==by 0x231FF12: dep_cost_1(_dep*, unsigned int) (haifa-sched.c:1474) ==29614==by 0x2321BD1: dep_cost (haifa-sched.c:1510) ==29614==by 0x2321BD1: priority(rtx_insn*, bool) [clone .part.0] (haifa-sched.c:1661) ==29614==by 0x23224C2: priority (haifa-sched.c:1593) ==29614==by 0x23224C2: set_priorities(rtx_insn*, rtx_insn*) (haifa-sched.c:7166) ==29614==by 0x13101E2: compute_priorities() (sched-rgn.c:3025) ==29614==by 0x1312EF5: schedule_region (sched-rgn.c:3118) ==29614==by 0x1312EF5: schedule_insns() [clone .part.0] (sched-rgn.c:3518) ==29614==by 0x13135AB: schedule_insns (sched-rgn.c:3504) ==29614==by 0x13135AB: rest_of_handle_live_range_shrinkage (sched-rgn.c:3706) ==29614==by 0x13135AB: (anonymous namespace)::pass_live_range_shrinkage::execute(function*) (sched-rgn.c:3793) ==29614==by 0x126BEEA: execute_one_pass(opt_pass*) (passes.c:2637) ==29614==by 0x126C7AF: execute_pass_list_1(opt_pass*) (passes.c:2737) ==29614== Address 0xabababababababab is not stack'd, malloc'd or (recently) free'd ==29614== during RTL pass: lr_shrinkage testcase.c: In function 'foo': testcase.c:7:1: internal compiler error: Segmentation fault 7 | } | ^ 0x1373cef crash_signal /repo/gcc-trunk/gcc/toplev.c:322 0x12bbdfa memory_operand(rtx_def*, machine_mode) /repo/gcc-trunk/gcc/recog.c:1812 0x1ae5525 get_attr_memory(rtx_insn*) /repo/gcc-trunk/gcc/config/i386/i386.md:5096 0x1ef0820 insn_default_latency_generic(rtx_insn*) /repo/gcc-trunk/gcc/config/i386/i386.md:19503 0x231b911 insn_sched_cost(rtx_insn*) /repo/gcc-trunk/gcc/haifa-sched.c:1421 0x231ff12 dep_cost_1(_dep*, unsigned int) /repo/gcc-trunk/gcc/haifa-sched.c:1474 0x2321bd1 dep_cost(_dep*) /repo/gcc-trunk/gcc/haifa-sched.c:1510 0x2321bd1 priority /repo/gcc-trunk/gcc/haifa-sched.c:1661 0x23224c2 priority /repo/gcc-trunk/gcc/haifa-sched.c:1593 0x23224c2 set_priorities(rtx_insn*, rtx_insn*) /repo/gcc-trunk/gcc/haifa-sched.c:7166 0x13101e2 compute_priorities() /repo/gcc-trunk/gcc/sched-rgn.c:3025 0x1312ef5 schedule_region /repo/gcc-trunk/gcc/sched-rgn.c:3118 0x1312ef5 schedule_insns() /repo/gcc-trunk/gcc/sched-rgn.c:3518 0x13135ab schedule_insns() /repo/gcc-trunk/gcc/sched-rgn.c:3504 0x13135ab rest_of_handle_live_range_shrinkage /repo/gcc-trunk/gcc/sched-rgn.c:3706 0x13135ab execute /repo/gcc-trunk/gcc/sched-rgn.c:3793 Please submit a full bug report, with preprocessed source if appropriate. Please include the complete backtrace with any bug report. See <https://gcc.gnu.org/bugs/> for instructions. $ x86_64-pc-linux-gnu-gcc -v Using built-in specs. COLLECT_GCC=/repo/gcc-trunk/binary-latest/bin/x86_64-pc-linux-gnu-gcc COLLECT_LTO_WRAPPER=/repo/gcc-trunk/binary-trunk-r12-6219-20220104202718-g0fc60c18335-checking-yes-rtl-df-extra-amd64/bin/../libexec/gcc/x86_64-pc-linux-gnu/12.0.0/lto-wrapper Target: x86_64-pc-linux-gnu Configured with: /repo/gcc-trunk//configure --enable-languages=c,c++ --enable-valgrind-annotations --disable-nls --enable-checking=yes,rtl,df,extra --with-cloog --with-ppl --with-isl --build=x86_64-pc-linux-gnu --host=x86_64-pc-linux-gnu --target=x86_64-pc-linux-gnu --with-ld=/usr/bin/x86_64-pc-linux-gnu-ld --with-as=/usr/bin/x86_64-pc-linux-gnu-as --disable-libstdcxx-pch --prefix=/repo/gcc-trunk//binary-trunk-r12-6219-20220104202718-g0fc60c18335-checking-yes-rtl-df-extra-amd64 Thread model: posix Supported LTO compression algorithms: zlib zstd gcc version 12.0.0 20220105 (experimental) (GCC)
[Bug tree-optimization/103916] New: [meta-bug] -Os vs loop header copy
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103916 Bug ID: 103916 Summary: [meta-bug] -Os vs loop header copy Product: gcc Version: 12.0 Status: UNCONFIRMED Keywords: missed-optimization Severity: enhancement Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: pinskia at gcc dot gnu.org Target Milestone: --- There are a bunch of bugs related to -Os and the loop header copy pass not happening so record them all in one place.
[Bug c/94669] libcc1: 4 * minor performance problem
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94669 --- Comment #7 from David Binderman --- Could this bug be marked as fixed, then ?
[Bug libstdc++/103917] New: libstdc++-v3/src/c++17/fs_path.cc:74: struct passed by value ?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103917
Bug ID: 103917
Summary: libstdc++-v3/src/c++17/fs_path.cc:74: struct passed by
value ?
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: dcb314 at hotmail dot com
Target Milestone: ---
cppcheck says:
libstdc++-v3/src/c++17/fs_path.cc:74:28: performance: Function parameter 's'
should be passed by const reference. [passedByValue]
Source code is
_Parser(string_view_type s, size_t o = 0) : input(s), origin(o) { }
[Bug target/100432] gcc arm compilation binary output is bigger with -Os than -O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100432 Andrew Pinski changed: What|Removed |Added Ever confirmed|1 |0 Status|WAITING |UNCONFIRMED
[Bug libstdc++/103853] std::forward_list::merge should check if __list != this
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103853 --- Comment #4 from Jonathan Wakely --- Pavel, I'm going to use your original patch, or parts of it anyway (the addition to the changelog is wrong, we do not patch the changelog by hand it's auto-generated). Are you willing and able to certify the origin of the code under the terms of https://gcc.gnu.org/dco.html ?
[Bug tree-optimization/103816] [12 Regression] ICE: in vect_build_slp_tree_2, at tree-vect-slp.c:1748 since r12-1551-g3dfa4fe9f1a089b2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103816 --- Comment #4 from CVS Commits --- The master branch has been updated by Richard Biener : https://gcc.gnu.org/g:1021b72bf6542f3c08e5404b65063216ee1b06f7 commit r12-6222-g1021b72bf6542f3c08e5404b65063216ee1b06f7 Author: Richard Biener Date: Wed Jan 5 10:14:52 2022 +0100 tree-optimization/103816 - detect offset overflow in SLP group analysis This makes sure to detect overflow when computing DR_GROUP_GAP and DR_GROUP_SIZE more thoroughly so artificial testcases like the added one are not fooling the existing check. 2022-01-05 Richard Biener PR tree-optimization/103816 * tree-vect-data-refs.c (vect_analyze_group_access_1): Also check DR_GROUP_GAP compute for overflow and representability. * gcc.dg/torture/pr103816.c: New testcase.
[Bug tree-optimization/103916] [meta-bug] -Os vs loop header copy
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103916 Richard Biener changed: What|Removed |Added Last reconfirmed||2022-01-05 Status|UNCONFIRMED |NEW Ever confirmed|0 |1 --- Comment #1 from Richard Biener --- Note the pass is run but we have /* Avoid loop header copying when optimizing for size unless we can determine that the loop condition is static in the first iteration. */ if (optimize_loop_for_size_p (loop) && !loop->force_vectorize && !entry_loop_condition_is_static (loop, query)) guarding it where the optimize_loop_for_size_p is conservative to size for -Os. We might want to use similar logic as unrolling to determine the size cost of the BB peeling done (basically share it) and thus allow more cases.
[Bug target/103915] [12 Regression] ICE: SIGSEGV in memory_operand with -flive-range-shrinkage
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103915 Richard Biener changed: What|Removed |Added Target Milestone|--- |12.0
[Bug tree-optimization/103816] [12 Regression] ICE: in vect_build_slp_tree_2, at tree-vect-slp.c:1748 since r12-1551-g3dfa4fe9f1a089b2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103816 Richard Biener changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #5 from Richard Biener --- Fixed.
[Bug c++/103918] New: ICE in make_decl_rtl, at varasm.c:1422
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103918
Bug ID: 103918
Summary: ICE in make_decl_rtl, at varasm.c:1422
Product: gcc
Version: 11.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: juki at gcc dot mail.kapsi.fi
Target Milestone: ---
$ g++ --version:
g++ (Gentoo 11.2.0 p1) 11.2.0
Test case:
int main()
{
int value = 2;
int localArray[2][value] = {};
return 0;
}
$ g++ -O0 main.cpp
during RTL pass: expand
main.cpp: In function ‘int main()’:
main.cpp:4:13: internal compiler error: in make_decl_rtl, at varasm.c:1422
4 | int localArray[2][value] = {};
| ^~
Please submit a full bug report,
with preprocessed source if appropriate.
See
[Bug target/103915] [12 Regression] ICE: SIGSEGV in memory_operand with -flive-range-shrinkage since r12-6215-g708b87dcb6e48cb4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103915 Martin Liška changed: What|Removed |Added CC||marxin at gcc dot gnu.org Ever confirmed|0 |1 Status|UNCONFIRMED |NEW Last reconfirmed||2022-01-05 Priority|P3 |P1 Summary|[12 Regression] ICE:|[12 Regression] ICE: |SIGSEGV in memory_operand |SIGSEGV in memory_operand |with -flive-range-shrinkage |with -flive-range-shrinkage ||since ||r12-6215-g708b87dcb6e48cb4 --- Comment #1 from Martin Liška --- Started with r12-6215-g708b87dcb6e48cb4.
[Bug target/103915] [12 Regression] ICE: SIGSEGV in memory_operand with -flive-range-shrinkage since r12-6215-g708b87dcb6e48cb4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103915 Uroš Bizjak changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |ubizjak at gmail dot com --- Comment #2 from Uroš Bizjak --- diff --git a/gcc/config/i386/mmx.md b/gcc/config/i386/mmx.md index fc8ec5e4d49..96d85a54e10 100644 --- a/gcc/config/i386/mmx.md +++ b/gcc/config/i386/mmx.md @@ -2752,7 +2752,7 @@ "" "#" [(set_attr "isa" "*,sse2,avx512vl") - (set_attr "type" "negnot,sselog,sselog") + (set_attr "type" "negnot,sselog1,sselog1") (set_attr "mode" "SI,TI,TI")]) (define_split
[Bug c++/103918] ICE in make_decl_rtl, at varasm.c:1422
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103918 Andrew Pinski changed: What|Removed |Added Resolution|--- |DUPLICATE Status|UNCONFIRMED |RESOLVED --- Comment #1 from Andrew Pinski --- Dup of bug 58646. *** This bug has been marked as a duplicate of bug 58646 ***
[Bug c++/58646] [9/10/11/12 Regression] ICE on a multidimensional VLA with an empty initializer list
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58646 Andrew Pinski changed: What|Removed |Added CC||juki at gcc dot mail.kapsi.fi --- Comment #15 from Andrew Pinski --- *** Bug 103918 has been marked as a duplicate of this bug. ***
[Bug libstdc++/103917] libstdc++-v3/src/c++17/fs_path.cc:74: struct passed by value ?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103917 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #1 from Jonathan Wakely --- cppcheck is wrong. https://stackoverflow.com/questions/27256377/c-view-types-pass-by-const-or-by-value https://quuxplusone.github.io/blog/2021/11/09/pass-string-view-by-value/
[Bug c++/103912] ICE in a consteval function which returns a lambda which takes a "non-POD" argument and the consteval has other code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103912
--- Comment #3 from Jakub Jelinek ---
This happens because of:
/* Preserve a functions function context node. It will
later be needed to output debug info. */
if (tree fn = decl_function_context (decl))
{
cgraph_node *origin_node = cgraph_node::get_create (fn);
enqueue_node (origin_node);
}
in cgraphunit.c, operator() of the lambda is needed, so it is enqueued and the
above forces gimplification of the consteval function too, which is a big no
no, such functions shouldn't exist.
The big question is what do we want to do for debug info in these cases.
When using instead:
struct A {A (); };
constexpr auto
foo ()
{
if (1)
;
return [] (A x) { };
}
void
bar (A x)
{
constinit static auto h = foo ();
h (x);
}
ipa.c discovers that foo isn't reachable even when it is needed (as function
context of the lambda) and throws away the body and in the debug info just
emits DW_TAG_subprogram etc. for foo, but only emits non-code related stuff for
it.
[Bug c++/103912] ICE in a consteval function which returns a lambda which takes a "non-POD" argument and the consteval has other code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103912 Jakub Jelinek changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org --- Comment #4 from Jakub Jelinek --- Created attachment 52130 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52130&action=edit gcc12-pr103912.patch Untested fix.
[Bug libstdc++/103877] libstdc++ docs give a bad recommendation for printing C++ defines
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103877 --- Comment #2 from CVS Commits --- The master branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:cebe875f6f44b905a0d56a2007b5a638a33a893c commit r12-6259-gcebe875f6f44b905a0d56a2007b5a638a33a893c Author: Jonathan Wakely Date: Tue Jan 4 15:54:16 2022 + libstdc++: Fix example preprocessor command in FAQ [PR103877] libstdc++-v3/ChangeLog: PR libstdc++/103877 * doc/xml/faq.xml: Add '-x c++' to preprocessor command. * doc/html/faq.html: Regenerate.
[Bug libstdc++/103848] [11/12 Regression] std::deque<>::iterator operator- uses "0" for nullptr check, triggers "zero-as-null-pointer-constant" warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103848 --- Comment #11 from CVS Commits --- The master branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:76a45931ab7c831e32cebf13a6317e5e142f8151 commit r12-6261-g76a45931ab7c831e32cebf13a6317e5e142f8151 Author: Jonathan Wakely Date: Tue Jan 4 21:57:16 2022 + libstdc++: Avoid -Wzero-as-null-pointer-constant warning [PR103848] libstdc++-v3/ChangeLog: PR libstdc++/103848 * include/bits/stl_deque.h (operator-): Do not use 0 as null pointer constant.
[Bug libstdc++/103877] libstdc++ docs give a bad recommendation for printing C++ defines
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103877 Jonathan Wakely changed: What|Removed |Added Status|NEW |RESOLVED Target Milestone|--- |12.0 Resolution|--- |FIXED --- Comment #3 from Jonathan Wakely --- Fixed on trunk.
[Bug c++/96780] debuginfo for std::move and std::forward isn't useful
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96780 Patrick Palka changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |ppalka at gcc dot gnu.org
[Bug tree-optimization/103899] [12 Regression] make profiledbootstrap fails due to uninitialized warning in expr.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103899
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #6 from Jakub Jelinek ---
While we should fix uninit warning to deal with this if possible, I think we
should also try to work around this in expr.c.
If following works, then I think it would be even a cleanup (as it moves the
context variable declaration to the sole spot where it is used):
--- gcc/expr.c.jj 2022-01-03 10:40:41.203164211 +0100
+++ gcc/expr.c 2022-01-05 14:47:47.684660031 +0100
@@ -10340,7 +10340,6 @@ expand_expr_real_1 (tree exp, rtx target
enum tree_code code = TREE_CODE (exp);
rtx subtarget, original_target;
int ignore;
- tree context;
bool reduce_bit_field;
location_t loc = EXPR_LOCATION (exp);
struct separate_ops ops;
@@ -10579,14 +10578,16 @@ expand_expr_real_1 (tree exp, rtx target
/* Variables inherited from containing functions should have
been lowered by this point. */
if (exp)
- context = decl_function_context (exp);
- gcc_assert (!exp
- || SCOPE_FILE_SCOPE_P (context)
- || context == current_function_decl
- || TREE_STATIC (exp)
- || DECL_EXTERNAL (exp)
- /* ??? C++ creates functions that are not TREE_STATIC. */
- || TREE_CODE (exp) == FUNCTION_DECL);
+ {
+ tree context = decl_function_context (exp);
+ gcc_assert (SCOPE_FILE_SCOPE_P (context)
+ || context == current_function_decl
+ || TREE_STATIC (exp)
+ || DECL_EXTERNAL (exp)
+ /* ??? C++ creates functions that are not
+TREE_STATIC. */
+ || TREE_CODE (exp) == FUNCTION_DECL);
+ }
/* This is the case of an array whose size is to be determined
from its initializer, while the initializer is still being parsed.
[Bug tree-optimization/103835] bogus sprintf warnings due to missing strlen propagation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103835 --- Comment #4 from lavr at ncbi dot nlm.nih.gov --- Thank you for investigating this! Like I said, it's better NOT to emit any warnings if some machinery in the compiler is not perfect enough to recognize the danger correctly (as it used to be the case in previous versions and so they were silent in this respect). There is the second warning there, too, which seems not being addressed by the discussion. Not only the count (499) is not given correctly (but maybe it's because of the constant propagation that was mentioned), there's the second part (the note), which follows, and which looks extremely bad and unintelligent w.r.t. the output size calculation: test.c:8:21: warning: ‘a = ’ directive writing 4 bytes into a region of size between 0 and 499 [-Wformat-overflow=] 8 | sprintf(buf, "%sa = %d\n" | ^~~~ test.c:8:5: note: ‘sprintf’ output between 13 and 1031 bytes into a destination of size 499 Is this the same cause, too?
[Bug tree-optimization/103899] [12 Regression] make profiledbootstrap fails due to uninitialized warning in expr.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103899 --- Comment #7 from Jakub Jelinek --- Confirmed it does help.
[Bug middle-end/101530] ICE: 'verify_gimple' failed: non-top-level 'bit_field_ref' with __builtin_shufflevector()[0]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101530
Richard Biener changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot
gnu.org
Status|NEW |ASSIGNED
--- Comment #3 from Richard Biener ---
If we stop walking in gimplify_compound_lval we still gimplify the tail in the
same way, not assigning the register typed BIT_FIELD_REF to a temporary.
A bit less degenerate testcase:
typedef int __attribute__((__vector_size__ (16))) V;
int
foo(V v, int i)
{
return __builtin_shufflevector (v, v, 2, 3)[i];
}
We can't really simplify the original GENERIC much here:
return VIEW_CONVERT_EXPR(BIT_FIELD_REF < VEC_PERM_EXPR < v , v , { 2,
3, 2, 3 } > , 64, 0>)[i];
the BIT_FIELD_REF is used to subset the vector, what we'd need to somehow
ensure is to force that to an rvalue. I suppose that would be possible
if we'd wrap it in a TARGET_EXPR somehow. At least the following works for me:
diff --git a/gcc/c-family/c-common.c b/gcc/c-family/c-common.c
index 13341fa315e..4631d50c6f0 100644
--- a/gcc/c-family/c-common.c
+++ b/gcc/c-family/c-common.c
@@ -1243,6 +1243,8 @@ c_build_shufflevector (location_t loc, tree v0, tree v1,
tree lpartt = build_vector_type (TREE_TYPE (ret_type), mask.length ());
ret = build3_loc (loc, BIT_FIELD_REF,
lpartt, ret, TYPE_SIZE (lpartt), bitsize_zero_node);
+ tree tem = create_tmp_var_raw (lpartt);
+ ret = build4 (TARGET_EXPR, lpartt, tem, ret, NULL_TREE, NULL_TREE);
}
if (!c_dialect_cxx () && !wrap)
[Bug tree-optimization/100801] [9/10/11/12 Regression] Aggressive loop optimizations cause incorrect warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100801 Richard Biener changed: What|Removed |Added Priority|P3 |P2
[Bug libstdc++/103853] std::forward_list::merge should check if __list != this
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103853 --- Comment #5 from Pavel I. Kryukov --- > Are you willing and able to certify the origin of the code under the terms of > https://gcc.gnu.org/dco.html ? Yes. Do I need to resubmit a signed-off patch?
[Bug c++/100409] C++ FE elides pure throwing call
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100409 Richard Biener changed: What|Removed |Added Resolution|--- |INVALID Status|UNCONFIRMED |RESOLVED --- Comment #16 from Richard Biener --- So it's not invalid to elide this (for C++) but instead conflicting specification by the user.
[Bug tree-optimization/101373] PRE hoists trapping instructions over possibly throwing calls
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101373 Bug 101373 depends on bug 100409, which changed state. Bug 100409 Summary: C++ FE elides pure throwing call https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100409 What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID
[Bug tree-optimization/92860] [9/10/11/12 regression] Global flags affected by -O settings are clobbered by optimize attribute
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92860 --- Comment #90 from Martin Liška --- Note that I can bootstrap with -O3 -march=native on bdver1 when I apply the fix for PR103905.
[Bug target/100347] [11/12 Regression] GCC 11 does not recognize skylake; translates "march=native" to "x86_64"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100347 Richard Biener changed: What|Removed |Added Ever confirmed|0 |1 Status|UNCONFIRMED |WAITING Last reconfirmed||2022-01-05 --- Comment #19 from Richard Biener --- Going over the audit log it seems Iain cannot reproduce the observed failure of -march=native, the only speciality the reporter mentions is that his build system inserts a -march=skylake to each compiler command when building GCC (I assume for stage1 only, and the reporter performs a bootstrap). Erik, can you arrange for the compiler wrapper to not insert -march=skylake and see whether that makes a difference? Otherwise as suggested you need to step through the -march=native code, see comment#9 I've verified building (not bootstrapping) with --with-cpu= doesn't break -march=native handling on x86_64-linux.
[Bug libstdc++/103919] New: The basic_string(const T&, size_type, size_type) constructor is overconstrained
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103919
Bug ID: 103919
Summary: The basic_string(const T&, size_type, size_type)
constructor is overconstrained
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: barry.revzin at gmail dot com
Target Milestone: ---
>From StackOverflow (https://stackoverflow.com/q/70591571/2069064), with a clear
description of the problem.
This constructor:
template>
_GLIBCXX20_CONSTEXPR
basic_string(const _Tp& __t, size_type __pos, size_type __n,
const _Alloc& __a = _Alloc())
: basic_string(_S_to_string_view(__t).substr(__pos, __n), __a) { }
is constrained using:
template
using _If_sv = enable_if_t<
__and_,
__not_>,
__not_>>::value,
_Res>;
But while the (const T&, const Allocator&) constructor does need that
additional requirement that const T& isn't convertible to const charT* (and is
specified to have this check), the original constructor I linked to does not -
since there wouldn't be any ambiguity there
(http://eel.is/c++draft/string.cons#5).
As such, a construction like:
string s("some string to test", 2, 3);
Instead of converting the literal to a string_view and doing a substr, instead
invokes this constructor:
_GLIBCXX20_CONSTEXPR
basic_string(const basic_string& __str, size_type __pos,
const _Alloc& __a = _Alloc())
Which requires (unnecessarily) allocating a new string.
[Bug libstdc++/103853] std::forward_list::merge should check if __list != this
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103853 --- Comment #6 from Jonathan Wakely --- I think I can probably just add the Signed-off-by: tag based on your comment above, and push it. But it wouldn't hurt to attach a signed-off patch here. Thanks!
[Bug libstdc++/103919] The basic_string(const T&, size_type, size_type) constructor is overconstrained
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103919 Jonathan Wakely changed: What|Removed |Added Ever confirmed|0 |1 Status|UNCONFIRMED |NEW Last reconfirmed||2022-01-05
[Bug c++/103758] bogus warning: misspelled term 'decl' in format; use 'declaration' instead [-Wformat-diag]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103758 --- Comment #6 from Marek Polacek --- Yes, the one in gimple-ssa-warn-access.c looks trivial, the other two are mine, and will probably need another exception.
[Bug c++/103913] Several variables declared in one declarator have distinct types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103913 Marek Polacek changed: What|Removed |Added CC||mpolacek at gcc dot gnu.org Ever confirmed|0 |1 Last reconfirmed||2022-01-05 Status|UNCONFIRMED |NEW --- Comment #1 from Marek Polacek --- Confirmed.
[Bug tree-optimization/100359] missed optimization for dead code elimination at -O3 (vs. -O2)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100359
Richard Biener changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot
gnu.org
--- Comment #2 from Richard Biener ---
Indeed:
-Setting value number of a.0_1 to &b (changed)
+Setting value number of a.0_1 to a.0_1 (changed)
+Using extra use virtual operand .MEM_39
+Making available beyond BB2 a.0_1 for value a.0_1
...
Setting value number of _3 to &b (changed)
Value numbering stmt = _4 = *_3;
-Setting value number of _4 to 0 (changed)
+Setting value number of _4 to _4 (changed)
+Making available beyond BB2 _4 for value _4
Value numbering stmt = if (_4 != 0)
-marking known outgoing edge 2 -> 5 executable
and the IL difference is just
[local count: 1073741824]:
f = 0;
a = &b;
- c.2_18 = c;
- *c.2_18 = &b;
+ j ={v} {CLOBBER};
+ c.2_40 = c;
+ *c.2_40 = &b;
f = 1;
a.0_1 = a;
*a.0_1 = 0;
note that 'a' is ESCAPED and _18/_40 point to ESCAPED. So what doesn't
work with the CLOBBER is
/* If we reach a clobbering statement try to skip it and see if
we find a VN result with exactly the same value as the
possible clobber. In this case we can ignore the clobber
and return the found value. */
in vn_reference_lookup_3 because that does a non-walking lookup. I think
we have a duplicate report for this exact issue somewhere.
The clobber is removed at -O2 as part of the useless vars removal before
stdarg. DCE2 leaves us with
[local count: 8687547609]:
- a = &b;
+ j[0] = &b;
+ _13 = j[0];
+ a = _13;
j ={v} {CLOBBER};
so we have stray uses left with -O3 which is ultimatively because cunrolli
unrolls only the outer loop with -O3!?
Ah, the reason is try_unroll_loop_completely has
/* See if we can improve our estimate by using recorded loop bounds. */
if ((allow_peel || maxiter == 0 || ul == UL_NO_GROWTH)
&& maxiter >= 0
&& (!n_unroll_found || (unsigned HOST_WIDE_INT)maxiter < n_unroll))
{
n_unroll = maxiter;
n_unroll_found = true;
/* Loop terminates before the IV variable test, so we cannot
remove it in the last iteration. */
edge_to_cancel = NULL;
}
but with -O3 we have !allow_peel and ul == UL_ALL (and maxiter == 1),
niter is unknown. I changed this with
g:a52206ae28ed3e55d601118bedd52739456401ab but the intent there was
clearly to allow the peeling if we restrict the cases to UL_NO_GROWTH,
not to disallow it with UL_ALL.
[Bug c++/103758] bogus warning: misspelled term 'decl' in format; use 'declaration' instead [-Wformat-diag]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103758
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #7 from Jakub Jelinek ---
For ignored_attributes, I must say I don't really like the missing [x|y|z]
after ... wording, missing %, %, % after ... would be slightly less
compact, but more readable. All of that appears in c-pragma.c and not
elsewhere:
c-family/c-pragma.c:GCC_BAD ("missing [big-endian|little-endian|default]
after %<#pragma scalar_storage_order%>");
c-family/c-pragma.c:GCC_BAD ("expected [big-endian|little-endian|default]
after %<#pragma scalar_storage_order%>");
c-family/c-pragma.c: "missing
[error|warning|ignored|push|pop|ignored_attributes]"
c-family/c-pragma.c: "expected
[error|warning|ignored|push|pop|ignored_attributes]"
[Bug c++/103758] bogus warning: misspelled term 'decl' in format; use 'declaration' instead [-Wformat-diag]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103758 --- Comment #8 from Jakub Jelinek --- %, %, or % after actually.
[Bug c++/103758] bogus warning: misspelled term 'decl' in format; use 'declaration' instead [-Wformat-diag]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103758 --- Comment #9 from Marek Polacek --- Sure, I can make that change!
[Bug c++/90925] gcc allows calling private overridden operators
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90925 Patrick Palka changed: What|Removed |Added CC||ppalka at gcc dot gnu.org Status|NEW |RESOLVED Resolution|--- |DUPLICATE --- Comment #8 from Patrick Palka --- (In reply to Andrew Pinski from comment #7) > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55361#c5 I suspect applies here. Yeah, this seems to be essentially a dup of PR55361 *** This bug has been marked as a duplicate of bug 55361 ***
[Bug c++/55361] Access control in templates only happens when instantiating a method
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55361 Patrick Palka changed: What|Removed |Added CC||zhonghao at pku dot org.cn --- Comment #7 from Patrick Palka --- *** Bug 90925 has been marked as a duplicate of this bug. ***
[Bug c++/59002] [meta-bug] Access checking in templates
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59002 Bug 59002 depends on bug 90925, which changed state. Bug 90925 Summary: gcc allows calling private overridden operators https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90925 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE
[Bug c++/103758] bogus warning: misspelled term 'decl' in format; use 'declaration' instead [-Wformat-diag]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103758 --- Comment #10 from Martin Sebor --- The diagnostic kinds in the call: warning_at (loc, OPT_Wpragmas, "missing [error|warning|ignored|push|pop|ignored_attributes]" " after %<#pragma GCC diagnostic%>"); should be quoted, just like the #pragma. (That's also what the message is telling us.) That said, rather than adding exceptions for every term of grammar that triggers this warning, adding a new quoting directive will avoid the problem and also let us annotate them in their own font (e.g., in italics).
[Bug c++/96780] debuginfo for std::move and std::forward isn't useful
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96780 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #6 from Jakub Jelinek --- Please declare those functions in cp-tree.h though.
[Bug c++/103879] error: accessing value of variant::_Copy_ctor_base through a 'const variant' glvalue in a constant expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103879
--- Comment #7 from 康桓瑋 ---
(In reply to Patrick Palka from comment #6)
> Reduced C++14 rejects-valid testcase:
>
> struct A {
> int n = 42;
> };
>
> struct B : A { };
>
> struct C {
> B b;
> };
>
> constexpr int f() {
> C c;
> A& a = static_cast(c.b);
> B& b = static_cast(a);
> return b.n;
> }
>
> static_assert(f() == 42, "");
Is this the same issue?
#include
#include
int main() {
using namespace std::string_literals;
static_assert(std::ranges::distance(
std::views::iota(0, 2) | std::ranges::views::transform([](int) { return
""s; })
| std::ranges::views::join));
}
https://godbolt.org/z/8nve43zvW
[Bug libstdc++/103919] The basic_string(const T&, size_type, size_type) constructor is overconstrained
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103919 --- Comment #1 from CVS Commits --- The master branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:6aa0859afaf28f4fb13121352225bc5877e02a44 commit r12-6267-g6aa0859afaf28f4fb13121352225bc5877e02a44 Author: Jonathan Wakely Date: Wed Jan 5 15:16:33 2022 + libstdc++: Fix overconstrained std::string constructor [PR103919] The C++17 basic_string(const T&, size_t, size_t) constructor is overconstrained, so it can't be used for a NTBS and a temporary string gets constructed (potentially allocating memory). There is no corresponding constructor taking an NTBS, so no need to disambiguate from it. Accepting an NTBS avoids the temporary (and potential allocation) and is what the standard requires. libstdc++-v3/ChangeLog: PR libstdc++/103919 * include/bits/basic_string.h (basic_string(const T&, size_t, size_t)): Relax constraints on string_view parameter. * include/bits/cow_string.h (basic_string(const T&, size_t, size_t)): Likewise. * testsuite/21_strings/basic_string/cons/char/103919.cc: New test.
[Bug c++/103879] error: accessing value of variant::_Copy_ctor_base through a 'const variant' glvalue in a constant expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103879 --- Comment #8 from Jonathan Wakely --- Yes, looks like it.
[Bug libstdc++/103919] The basic_string(const T&, size_type, size_type) constructor is overconstrained
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103919 --- Comment #2 from Jonathan Wakely --- Fixed on trunk, but worth backporting to gcc-11.
[Bug libstdc++/103919] The basic_string(const T&, size_type, size_type) constructor is overconstrained
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103919 Jonathan Wakely changed: What|Removed |Added Target Milestone|--- |11.3
[Bug c++/89074] valid pointer equality constexpr comparison rejected
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89074 Patrick Palka changed: What|Removed |Added CC||ppalka at gcc dot gnu.org --- Comment #7 from Patrick Palka --- The first three testcases are PR94716 and accepted by GCC 12. We still incorrectly reject the comment #5 testcase though.
[Bug c/103920] New: No warning for large structs passed by value ?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103920
Bug ID: 103920
Summary: No warning for large structs passed by value ?
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: dcb314 at hotmail dot com
Target Milestone: ---
For the following code:
$ more jan5c.cc
struct S
{
long a;
long b;
long c;
long d;
long a2;
long b2;
long c2;
long d2;
};
void f1( const S s);
void f2( S s);
gcc has not a lot to say:
$ /home/dcb/gcc/results/bin/gcc -c -O2 -Wall -Wextra -pedantic jan5c.cc
$
cppcheck does a slightly better job:
$ /home/dcb/cppcheck/trunk.git/cppcheck --enable=all jan5c.cc
jan5c.cc:14:18: performance: Function parameter 's' should be passed by const
reference. [passedByValue]
void f1( const S s);
^
Also, clang-13 doesn't say anything.
Judgement call, but "large" might mean four words or more.
Example code derived from code in the Linux kernel, so even kernel programmers
do this kind of thing in practice.
[Bug c++/103921] New: [modules] ICE requires in explicit-specifier of instantiation of imported template
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103921
Bug ID: 103921
Summary: [modules] ICE requires in explicit-specifier of
instantiation of imported template
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: johelegp at gmail dot com
CC: johelegp at gmail dot com
Target Milestone: ---
See https://godbolt.org/z/Tb1eMbE3W.
I think it's valid because Clang accepts it: https://godbolt.org/z/xcK7Kenb5.
mod.cpp:
```C++
export module mod;
export template struct quantity {
template
explicit(requires { 0; }) operator quantity() const;
};
export template
bool operator==(const quantity& l, const quantity& r);
```
test.cpp:
```C++
import mod;
int main() {
return requires { quantity{} == quantity{}; };
}
```
Output:
```
In module mod, imported at /app/test.cpp:1:
mod.cpp: In instantiation of 'struct quantity@mod':
test.cpp:3:35: required from here
mod.cpp:5:29: internal compiler error: Segmentation fault
5 | explicit(requires { 0; }) operator quantity() const;
| ^~~~
0x2139bd9 internal_error(char const*, ...)
???:0
0x9ada27 tsubst(tree_node*, tree_node*, int, tree_node*)
???:0
0x9f2c99 instantiate_class_template(tree_node*)
???:0
0xa184bc finish_compound_literal(tree_node*, tree_node*, int, fcl_t)
???:0
0x97a00d c_parse_file()
???:0
0xb08022 c_common_parse_file()
???:0
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See
[Bug c++/89074] valid pointer equality constexpr comparison rejected
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89074 --- Comment #8 from Jakub Jelinek --- At least when not constant evaluating that, a + 2 can be equal to b + 0 or can be different, shouldn't we reject at least that? It is true that for automatic variables if at least one of the pointers is into a middle of some automatic var and the other is to some other var they can't be equal.
[Bug c++/103921] [modules] ICE requires in explicit-specifier of instantiation of imported template
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103921
--- Comment #1 from Johel Ernesto Guerrero Peña ---
Simplified: https://godbolt.org/z/zzbjj7W3K.
mod.cpp:
```C++
export module mod;
export template struct quantity {
template
explicit(requires { 0; }) operator quantity() const;
};
```
test.cpp:
```C++
import mod;
int main() {
return requires { (quantity)quantity{}; };
}
```
Output:
```
In module mod, imported at /app/test.cpp:1:
mod.cpp: In instantiation of 'struct quantity@mod':
test.cpp:3:53: required from here
mod.cpp:5:29: internal compiler error: Segmentation fault
5 | explicit(requires { 0; }) operator quantity() const;
| ^~~~
0x2139bd9 internal_error(char const*, ...)
???:0
0x9ada27 tsubst(tree_node*, tree_node*, int, tree_node*)
???:0
0x9f2c99 instantiate_class_template(tree_node*)
???:0
0xa184bc finish_compound_literal(tree_node*, tree_node*, int, fcl_t)
???:0
0x97a00d c_parse_file()
???:0
0xb08022 c_common_parse_file()
???:0
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See
[Bug fortran/103258] [12 Regression] ICE in gfc_typenode_for_spec, at fortran/trans-types.c:1114 since r12-4979-gee11be7f2d788e60
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103258 --- Comment #6 from CVS Commits --- The master branch has been updated by Sandra Loosemore : https://gcc.gnu.org/g:85a3442c85aedb00c59e986f16cccbb8ec60d777 commit r12-6268-g85a3442c85aedb00c59e986f16cccbb8ec60d777 Author: Sandra Loosemore Date: Tue Jan 4 18:18:13 2022 -0800 Fortran: Fix ICE caused by missing error for untyped symbol [PR103258] The bit on a symbol to mark that it had already been diagnosed as lacking a type was getting set even when the error was suppressed or discarded, specifically when doing early resolution on a character length expression to see if it can be constant-folded. Explicitly suppress errors before doing that, then check whether they are suppressed before setting the bit. 2022-01-04 Sandra Loosemore PR fortran/103258 gcc/fortran/ * decl.c (gfc_match_char_spec): Suppress errors around call to gfc_reduce_init_expr. * error.c (gfc_query_suppress_errors): New. * gfortran.h (gfc_query_suppress_errors): Declare. * symbol.c (gfc_set_default_type): Check gfc_query_suppress_errors. gcc/testsuite/ * gfortran.dg/pr103258.f90: New.
[Bug fortran/103390] [12 Regression] ICE: gimplification failed since r12-4591-g1af78e731feb9327
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103390 sandra at gcc dot gnu.org changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #11 from sandra at gcc dot gnu.org --- Marking this as fixed since we have a new issue for the other bug.
[Bug fortran/103258] [12 Regression] ICE in gfc_typenode_for_spec, at fortran/trans-types.c:1114 since r12-4979-gee11be7f2d788e60
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103258 sandra at gcc dot gnu.org changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #7 from sandra at gcc dot gnu.org --- Should be fixed now.
[Bug c++/89074] valid pointer equality constexpr comparison rejected
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89074 --- Comment #9 from Patrick Palka --- (In reply to Jakub Jelinek from comment #8) > At least when not constant evaluating that, a + 2 can be equal to b + 0 or > can be different, shouldn't we reject at least that? I think so, according to https://eel.is/c++draft/expr.eq#3.1 and http://eel.is/c++draft/expr.const#5.25
[Bug c/103920] No warning for large structs passed by value ?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103920 Jonathan Wakely changed: What|Removed |Added Keywords||diagnostic Blocks||87403 Severity|normal |enhancement Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87403 [Bug 87403] [Meta-bug] Issues that suggest a new warning
[Bug fortran/95879] [10/11/12 Regression] ICE in gfc_resolve_formal_arglist, at fortran/resolve.c:313
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95879 sandra at gcc dot gnu.org changed: What|Removed |Added CC||sandra at gcc dot gnu.org --- Comment #5 from sandra at gcc dot gnu.org --- The ICE from the z1.90 example is gone on mainline now. I don't know if the error on y1.f90 is correct or not without further research.
[Bug inline-asm/98096] Inconsistent operand numbering for asm goto with in-out operands
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98096 James Y Knight changed: What|Removed |Added CC||foom at fuhm dot net --- Comment #7 from James Y Knight --- Previously, you never needed to care about the numbering of the extra hidden input constraints generated for an in-out constraints, because they were _last_. Their existence previously only mattered in that you needed to count them as part of the "max 30" constraint limit. That's why it is sensible to _keep_ these internal constraints last -- after ALL user-specified constraints, including asm-goto labels. Putting in the middle, and forcing users to count them just adds extra unnecessary complexity to the user-facing API. It appears to me that the GCC decision here was accidental, and that when pointed out, the bug was simply documented rather than fixed. That's unfortunate.
[Bug libstdc++/103086] [11 Regression] std::unique_ptr printer gets confused by [[no_unique_address]] in tuple
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103086 --- Comment #9 from CVS Commits --- The releases/gcc-10 branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:5400112aa94163b1e94404e74b3000779d24303b commit r10-10374-g5400112aa94163b1e94404e74b3000779d24303b Author: Jonathan Wakely Date: Thu Nov 4 22:50:02 2021 + libstdc++: Fix pretty printing of std::unique_ptr [PR103086] Since std::tuple started using [[no_unique_address]] the tuple member of std::unique_ptr has two _M_head_impl subobjects, in different base classes. That means this printer code is ambiguous: tuple_head_type = tuple_impl_type.fields()[1].type # _Head_base head_field = tuple_head_type.fields()[0] if head_field.name == '_M_head_impl': self.pointer = tuple_member['_M_head_impl'] In older versions of GDB it happened to work by chance, because GDB returned the last _M_head_impl member and std::tuple's base classes are stored in reverse order, so the last one was the T* element of the tuple. Since GDB 11 it returns the first _M_head_impl, which is the deleter element. The fix is for the printer to stop using an ambiguous field name and cast the tuple to the correct base class before accessing the _M_head_impl member. Instead of fixing this in both UniquePointerPrinter and StdPathPrinter a new unique_ptr_get function is defined to do it correctly. That is defined in terms of new tuple_get and _tuple_impl_get functions. It would be possible to reuse _tuple_impl_get to access each element in StdTuplePrinter._iterator.__next__, but that already does the correct casting, and wouldn't be much simpler anyway. libstdc++-v3/ChangeLog: PR libstdc++/103086 * python/libstdcxx/v6/printers.py (_tuple_impl_get): New helper for accessing the tuple element stored in a _Tuple_impl node. (tuple_get): New function for accessing a tuple element. (unique_ptr_get): New function for accessing a unique_ptr. (UniquePointerPrinter, StdPathPrinter): Use unique_ptr_get. * python/libstdcxx/v6/xmethods.py (UniquePtrGetWorker): Cast tuple to its base class before accessing _M_head_impl. (cherry picked from commit a634928f5c8a281442ac8f5fb1636aed048ed72c)
[Bug libstdc++/103086] [11 Regression] std::unique_ptr printer gets confused by [[no_unique_address]] in tuple
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103086 --- Comment #10 from CVS Commits --- The releases/gcc-10 branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:865ad53c49953f2950901aaf45b34a38841df019 commit r10-10375-g865ad53c49953f2950901aaf45b34a38841df019 Author: Jonathan Wakely Date: Tue Nov 23 21:35:40 2021 + libstdc++: Add another testcase for std::unique_ptr printer [PR103086] libstdc++-v3/ChangeLog: PR libstdc++/103086 * testsuite/libstdc++-prettyprinters/cxx11.cc: Check unique_ptr with non-empty pointer and non-empty deleter. (cherry picked from commit c59ec55c3459fba619e05ee7f59480b71e85ffd7)
[Bug inline-asm/98096] Inconsistent operand numbering for asm goto with in-out operands
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98096 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #8 from Jakub Jelinek --- That isn't easibly possible, the labels are really significantly different from the implementation POV, so having them intermixed with inputs is hard. If you don't want to count on those extra inputs, name the labels...
[Bug libstdc++/103086] [11 Regression] std::unique_ptr printer gets confused by [[no_unique_address]] in tuple
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103086 --- Comment #11 from Jonathan Wakely --- Also fixed for 10.4 now.
[Bug target/103197] ppc inline expansion of memcpy/memmove should not use lxsibzx/stxsibx for a single byte
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103197 --- Comment #9 from Segher Boessenkool --- Created attachment 52131 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52131&action=edit Proposed patch
[Bug c++/103921] [modules] ICE dependent expression in explicit-specifier of instantiation of imported template
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103921
Johel Ernesto Guerrero Peña changed:
What|Removed |Added
Summary|[modules] ICE requires in |[modules] ICE dependent
|explicit-specifier of |expression in
|instantiation of imported |explicit-specifier of
|template|instantiation of imported
||template
--- Comment #2 from Johel Ernesto Guerrero Peña ---
It actually ICEs whenever the expression is dependent:
https://godbolt.org/z/oqbnanoex.
mod.cpp:
```C++
export module mod;
template constexpr bool b{true};
export template struct quantity {
template
explicit(b) operator quantity() const;
};
```
[Bug fortran/103914] -fcheck=do seems not to work with omp parallel do construct
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103914 anlauf at gcc dot gnu.org changed: What|Removed |Added Severity|normal |enhancement Status|UNCONFIRMED |NEW Priority|P3 |P5 Ever confirmed|0 |1 Last reconfirmed||2022-01-05 --- Comment #1 from anlauf at gcc dot gnu.org --- (In reply to xiao@compiler-dev.com from comment #0) > I have some questions: > why the option "-fcheck=do" do not take effect for "parallel do"? Just an observation: The code for ordinary do loops is generated in gfc_trans_do(), which also adds code for runtime checking. The code for OpenMP annotated loops is generated in gfc_trans_omp_do(). There appears to be no runtime checking implemented for this type of loops.
[Bug target/102169] powerpc64 int memory operations using FP instructions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102169 Segher Boessenkool changed: What|Removed |Added Resolution|--- |DUPLICATE Status|NEW |RESOLVED --- Comment #6 from Segher Boessenkool --- Proposed patch in PR103197, doing similar to what Hao Chen says in comment 4. *** This bug has been marked as a duplicate of bug 103197 ***
[Bug target/103197] ppc inline expansion of memcpy/memmove should not use lxsibzx/stxsibx for a single byte
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103197 Segher Boessenkool changed: What|Removed |Added CC||npiggin at gmail dot com --- Comment #10 from Segher Boessenkool --- *** Bug 102169 has been marked as a duplicate of this bug. ***
[Bug c/94669] libcc1: 4 * minor performance problem
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94669 --- Comment #8 from Tom Tromey --- (In reply to David Binderman from comment #7) > Could this bug be marked as fixed, then ? Yes, but I don't really know the GCC rules about closing reports any more, so someone else probably ought to handle it.
