[Bug target/104664] ICE: in extract_constrain_insn, at recog.cc:2670 (insn does not satisfy its constraints) with -Og -ffinite-math-only
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104664 --- Comment #2 from Hongyu Wang --- starting from r12-6021
[Bug c/104673] New: powerpc e500mc Error: unrecognized opcode: `isel'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104673 Bug ID: 104673 Summary: powerpc e500mc Error: unrecognized opcode: `isel' Product: gcc Version: 11.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: judge.packham at gmail dot com Target Milestone: --- Created attachment 52503 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52503&action=edit assembly file emitted by GCC When building for powerpc with -mcpu=e500mc the generated assembly includes a ".machine ppc" directive which causes gas to ignore the command line -me500mc flag. This means that it decides any e500mc specific instructions are invalid. Attached is the generated assembly from a build with gcc 11.2 cross-compiled for powerpc. As you can see the .machine directive says ppc but when gas sees this it will reset it's internal state and decide the isel instruction is invalid. I think this might be an regression from https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=2d94f7dea9. GCC only seems to have a limited set of machines it will emit which don't match with what binutils uses.
[Bug target/104673] powerpc e500mc Error: unrecognized opcode: `isel'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104673 --- Comment #1 from Andrew Pinski --- How did you configure GCC? How did you invoke GCC? Can you attach the preprocessed source rather than the generated assembly code?
[Bug target/104663] [12 Regression] C-ray 1.1 performance is 50% worse at -O2 in GCC 12 than before on alderlake
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104663 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #4 from Jakub Jelinek --- Isn't this related or dup of PR101908 ?
[Bug target/104666] [12 Regression] ICE in related_vector_mode, at stor-layout.c:537
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104666
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #5 from Jakub Jelinek ---
Wouldn't the right fix be instead to move the ix86_expand_builtin
HOST_WIDE_INT isa = ix86_isa_flags;
HOST_WIDE_INT isa2 = ix86_isa_flags2;
HOST_WIDE_INT bisa = ix86_builtins_isa[fcode].isa;
HOST_WIDE_INT bisa2 = ix86_builtins_isa[fcode].isa2;
...
if ((bisa & OPTION_MASK_ISA_MMX) && !TARGET_MMX && TARGET_MMX_WITH_SSE
/* __builtin_ia32_maskmovq requires MMX registers. */
&& fcode != IX86_BUILTIN_MASKMOVQ)
{
bisa &= ~OPTION_MASK_ISA_MMX;
bisa |= OPTION_MASK_ISA_SSE2;
}
if ((bisa & isa) != bisa || (bisa2 & isa2) != bisa2)
code into a helper function and simply return early in
ix86_fold_builtin and ix86_gimple_fold_builtin if there is a mismatch (so
effectively keep those md builtins as calls for the cases of mismatch and
during expansion diagnose it?
[Bug c++/98202] C++ cannot parse F128 suffix for float128 literals
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98202 Jonathan Wakely changed: What|Removed |Added Resolution|--- |DUPLICATE Status|UNCONFIRMED |RESOLVED --- Comment #2 from Jonathan Wakely --- I suppose we can combine them. This one is about the internal macros, which do not require -std=gnu++NN modes, and they fail to compile even if you use a gnu++NN mode. The other bug only fails for strict c++NN modes. *** This bug has been marked as a duplicate of bug 87274 ***
[Bug c++/87274] -std=c++11 breaks quadmath macros
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87274 Jonathan Wakely changed: What|Removed |Added CC||redi at gcc dot gnu.org --- Comment #6 from Jonathan Wakely --- *** Bug 98202 has been marked as a duplicate of this bug. ***
[Bug c++/87274] -std=c++11 breaks quadmath macros
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87274 --- Comment #7 from Jonathan Wakely --- There's a related (but slightly different) problem for F128 suffixes: auto f = __FLT128_MIN__; f128.C:1:10: error: unable to find numeric literal operator ‘operator""F128’ The macros for the F128 constants all end in a F128 suffix, which the C++ compiler doesn't understand at all, for any -std mode. Either the macros shouldn't be defined for C++ or (preferably) they should work correctly, maybe when __extension__ is used. This would allow libstdc++ to define std::numeric_limits<__ieee128> for powerpc64le.
[Bug libstdc++/103407] [12 regression] abi_check FAILs on Solaris
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103407 Jonathan Wakely changed: What|Removed |Added Attachment #52501|0 |1 is obsolete|| --- Comment #9 from Jonathan Wakely --- Created attachment 52504 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52504&action=edit Correct patch for this bug
[Bug c/104674] New: i686 sse2: The two results of __divmoddi4 are mixed up
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104674 Bug ID: 104674 Summary: i686 sse2: The two results of __divmoddi4 are mixed up Product: gcc Version: 11.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: xavier.leroy at inria dot fr Target Milestone: --- Created attachment 52505 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52505&action=edit Repro case Configuration: GCC 11.2.0 configured for i686-pc-cygwin, as packaged by Cygwin, running under Cygwin. When compiled with gcc -O2 -mfpmath=sse -msse2 the attached repro case incorrectly prints 88.08889 The correct result is 88.0. "gcc -O2" and "gcc -O1 -mfpmath=sse -msse2" produce the correct result. Looking at the assembly code generated by "gcc -O2 -mfpmath=sse -msse2", we see that the two results of __divmoddi4 (the quotient and the remainder) end up stored at the same stack location: leal40(%esp), %eax <-- address where to store the remainder movl68(%esp), %edx movl$1000, 8(%esp) movl%eax, 16(%esp) movl64(%esp), %eax movl$0, 12(%esp) movl%eax, (%esp) movl%edx, 4(%esp) call___divmoddi4 <-- quotient is in edx:eax movsd LC1, %xmm2 movd%eax, %xmm0 movd%edx, %xmm3 punpckldq %xmm3, %xmm0 <-- quotient is in xmm0 movq%xmm0, 40(%esp) <-- overwrites the remainder Regards, - Xavier Leroy
[Bug target/104663] [12 Regression] C-ray 1.1 performance is 50% worse at -O2 in GCC 12 than before on alderlake
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104663 Richard Biener changed: What|Removed |Added Resolution|--- |DUPLICATE Status|WAITING |RESOLVED --- Comment #5 from Richard Biener --- Yes, it is. *** This bug has been marked as a duplicate of bug 101908 ***
[Bug target/101908] [12 regression] cray regression with -O2 -ftree-slp-vectorize compared to -O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101908 Richard Biener changed: What|Removed |Added CC||aros at gmx dot com --- Comment #20 from Richard Biener --- *** Bug 104663 has been marked as a duplicate of this bug. ***
[Bug target/104664] [12 Regression] ICE: in extract_constrain_insn, at recog.cc:2670 (insn does not satisfy its constraints) with -Og -ffinite-math-only
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104664 Richard Biener changed: What|Removed |Added Summary|ICE: in |[12 Regression] ICE: in |extract_constrain_insn, at |extract_constrain_insn, at |recog.cc:2670 (insn does|recog.cc:2670 (insn does |not satisfy its |not satisfy its |constraints) with -Og |constraints) with -Og |-ffinite-math-only |-ffinite-math-only Target Milestone|--- |12.0
[Bug target/98341] [11/12 Regression] Ada bootstrap fails with erroneous memory access on m68k
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98341 --- Comment #19 from John Paul Adrian Glaubitz --- (In reply to John Paul Adrian Glaubitz from comment #18) > The git snapshot 20220130 from the gcc-11 branch still fails. However, since > Matthias just uploaded 20220222, I can try that as well and report back. gcc-11 is still affected.
[Bug tree-optimization/104665] Failure to recognize memcpy
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104665 --- Comment #4 from Richard Biener --- In principle loop distribution could recognize this but it currently is doing too simplistic checking for this, not sure how difficult handling this would be.
[Bug target/104666] [12 Regression] ICE in related_vector_mode, at stor-layout.c:537
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104666 Richard Biener changed: What|Removed |Added Target Milestone|--- |12.0
[Bug target/104674] [11/12 Regression] i686 sse2: The two results of __divmoddi4 are mixed up
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104674 Richard Biener changed: What|Removed |Added Keywords||needs-bisection Ever confirmed|0 |1 Status|UNCONFIRMED |NEW Component|middle-end |target Last reconfirmed||2022-02-24 Target Milestone|--- |11.3 Target|i686-pc-cygwin |i?86-*-* Summary|i686 sse2: The two results |[11/12 Regression] i686 |of __divmoddi4 are mixed up |sse2: The two results of ||__divmoddi4 are mixed up --- Comment #1 from Richard Biener --- Confirmed. It seems to work for me with GCC 10 but that uses separate div/mod calls.
[Bug ipa/104648] [12 Regression] ICE in cgraphunit_cc_finalize, at cgraphunit.cc:2540
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104648 Martin Liška changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |marxin at gcc dot gnu.org --- Comment #2 from Martin Liška --- Lemme take a look.
[Bug target/104674] [11/12 Regression] i686 sse2: The two results of __divmoddi4 are mixed up
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104674 Jakub Jelinek changed: What|Removed |Added Keywords|needs-bisection | CC||jakub at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org Priority|P3 |P2 Status|NEW |ASSIGNED --- Comment #2 from Jakub Jelinek --- Started with my r11-3671-gbf510679bb3f9bfd6019666065016bb26a5b5466 I'll have a look.
[Bug rtl-optimization/104675] New: [9/10/11/12 Regression] ICE: in expand_expr_real_2, at expr.cc:9773 at -O with __real__ + __imag__ extraction
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104675 Bug ID: 104675 Summary: [9/10/11/12 Regression] ICE: in expand_expr_real_2, at expr.cc:9773 at -O with __real__ + __imag__ extraction Product: gcc Version: 12.0 Status: UNCONFIRMED Keywords: ice-on-valid-code Severity: normal Priority: P3 Component: rtl-optimization Assignee: unassigned at gcc dot gnu.org Reporter: zsojka at seznam dot cz Target Milestone: --- Host: x86_64-pc-linux-gnu Target: x86_64-pc-linux-gnu Created attachment 52506 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52506&action=edit reduced testcase Compiler output: $ x86_64-pc-linux-gnu-gcc -O testcase.c during RTL pass: expand In function 'bar', inlined from 'foo' at testcase.c:13:3: testcase.c:6:5: internal compiler error: in expand_expr_real_2, at expr.cc:9773 6 | c -= s; | ~~^~~~ 0x6ca3fa expand_expr_real_2(separate_ops*, rtx_def*, machine_mode, expand_modifier) /repo/gcc-trunk/gcc/expr.cc:9773 0xe6a0d8 expand_gimple_stmt_1 /repo/gcc-trunk/gcc/cfgexpand.cc:3967 0xe6a0d8 expand_gimple_stmt /repo/gcc-trunk/gcc/cfgexpand.cc:4028 0xe70186 expand_gimple_basic_block /repo/gcc-trunk/gcc/cfgexpand.cc:6069 0xe71d67 execute /repo/gcc-trunk/gcc/cfgexpand.cc:6795 Please submit a full bug report, with preprocessed source (by using -freport-bug). 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-amd64/bin/x86_64-pc-linux-gnu-gcc COLLECT_LTO_WRAPPER=/repo/gcc-trunk/binary-trunk-r12-7366-20220224090510-gffb2c671707-checking-yes-rtl-df-extra-amd64/bin/../libexec/gcc/x86_64-pc-linux-gnu/12.0.1/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-7366-20220224090510-gffb2c671707-checking-yes-rtl-df-extra-amd64 Thread model: posix Supported LTO compression algorithms: zlib zstd gcc version 12.0.1 20220224 (experimental) (GCC)
[Bug c++/88907] Variadic template function deduction failure.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88907
Andrew Pinski changed:
What|Removed |Added
Last reconfirmed||2022-02-24
Status|UNCONFIRMED |NEW
Ever confirmed|0 |1
--- Comment #2 from Andrew Pinski ---
Reduced testcase:
template class Base{};
template void error(Base const &... args){}
template void error(Ts &&... args){}
int main()
{
Base const a;
error(a);
}
CUT ---
Looks like GCC takes into account the default template argument incorrectly.
[Bug c++/104672] C++ frontend failing when function pointer argument types contain a parameter pack
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104672 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #1 from Andrew Pinski --- Dup of bug 56190. *** This bug has been marked as a duplicate of bug 56190 ***
[Bug c++/56190] GCC fails deducing a "void(*)(int, float, double)" to a "void(*)(T..., float, double)" with T={int}
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56190 Andrew Pinski changed: What|Removed |Added CC||eliphat at sjtu dot edu.cn --- Comment #4 from Andrew Pinski --- *** Bug 104672 has been marked as a duplicate of this bug. ***
[Bug rtl-optimization/104675] [9/10/11/12 Regression] ICE: in expand_expr_real_2, at expr.cc:9773 at -O with __real__ + __imag__ extraction
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104675 Jakub Jelinek changed: What|Removed |Added Target Milestone|--- |9.5 Priority|P3 |P2 Ever confirmed|0 |1 Last reconfirmed||2022-02-24 Status|UNCONFIRMED |NEW CC||jakub at gcc dot gnu.org --- Comment #1 from Jakub Jelinek --- Started with r6-779-gbc4315fbb0075e29d9a246bf73ff4c56ccf8fa6b
[Bug rtl-optimization/104675] [9/10/11/12 Regression] ICE: in expand_expr_real_2, at expr.cc:9773 at -O with __real__ + __imag__ extraction
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104675 --- Comment #2 from Andrew Pinski --- It was this part: (-1 - A -> ~A): Remove unnecessary condition. Which caused the issue.
[Bug tree-optimization/64454] optimize (x%5)%5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64454 Andrew Pinski changed: What|Removed |Added Target Milestone|--- |6.0
[Bug fortran/104428] [12 Regression] ICE in gfc_trans_omp_declare_variant, at fortran/trans-openmp.cc:7648 since r12-4409-g724ee5a0093da443
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104428 Martin Liška changed: What|Removed |Added Last reconfirmed||2022-02-24 CC||marxin at gcc dot gnu.org Summary|[12 Regression] ICE in |[12 Regression] ICE in |gfc_trans_omp_declare_varia |gfc_trans_omp_declare_varia |nt, at |nt, at |fortran/trans-openmp.cc:764 |fortran/trans-openmp.cc:764 |8 |8 since ||r12-4409-g724ee5a0093da443 Status|UNCONFIRMED |NEW Ever confirmed|0 |1 --- Comment #1 from Martin Liška --- Started with r12-4409-g724ee5a0093da443.
[Bug fortran/104429] [9/10/11/12 Regression] ICE in gfc_conv_variable, at fortran/trans-expr.cc:3056 since r9-2664-g1312bb902382cb48
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104429 Martin Liška changed: What|Removed |Added Last reconfirmed||2022-02-24 CC||marxin at gcc dot gnu.org, ||pault at gcc dot gnu.org Status|UNCONFIRMED |NEW Summary|[9/10/11/12 Regression] ICE |[9/10/11/12 Regression] ICE |in gfc_conv_variable, at|in gfc_conv_variable, at |fortran/trans-expr.cc:3056 |fortran/trans-expr.cc:3056 ||since ||r9-2664-g1312bb902382cb48 Ever confirmed|0 |1 --- Comment #1 from Martin Liška --- Started with r9-2664-g1312bb902382cb48.
[Bug fortran/104430] [9/10/11/12 Regression] ICE in gfc_conv_component_ref, at fortran/trans-expr.cc:2742 since r9-3522-gd0477233215e37de
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104430 Martin Liška changed: What|Removed |Added CC||burnus at gcc dot gnu.org, ||marxin at gcc dot gnu.org Last reconfirmed||2022-02-24 Ever confirmed|0 |1 Status|UNCONFIRMED |NEW Summary|[9/10/11/12 Regression] ICE |[9/10/11/12 Regression] ICE |in gfc_conv_component_ref, |in gfc_conv_component_ref, |at |at |fortran/trans-expr.cc:2742 |fortran/trans-expr.cc:2742 ||since ||r9-3522-gd0477233215e37de --- Comment #1 from Martin Liška --- Started with r9-3522-gd0477233215e37de.
[Bug rtl-optimization/104438] Combine optimization opportunity exposed after pro_and_epilogue
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104438 Martin Liška changed: What|Removed |Added CC||marxin at gcc dot gnu.org --- Comment #7 from Martin Liška --- (In reply to Hongtao.liu from comment #6) > The opportunity disappear after r12-7125. Can you please install the latest contrib/gcc-git-customization.sh? Doing that, you will se: $ git gcc-descr r12-7369-ga046033ea0ba97 So hash is added to revision.
[Bug ipa/104457] ipa-cp with autofdo: internal compiler error in update_specialized_profile, at ipa-cp.c:4422
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104457 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |WAITING Ever confirmed|0 |1 Last reconfirmed||2022-02-24
[Bug rtl-optimization/104675] [9/10/11/12 Regression] ICE: in expand_expr_real_2, at expr.cc:9773 at -O with __real__ + __imag__ extraction
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104675
Jakub Jelinek changed:
What|Removed |Added
Known to fail|10.3.1, 11.2.1, 12.0, |
|6.5.0, 7.5.0, 8.5.0, 9.4.1 |
--- Comment #3 from Jakub Jelinek ---
It isn't just that match.pd change though, consider:
_Complex int foo (_Complex int a) { return (-1 + -1i) - a; }
_Complex int bar (_Complex int a) { return - a - (1 + 1i); }
_Complex int baz (_Complex int a) { _Complex int b = -1 + -1i; return b - a; }
_Complex int qux (_Complex int a) { _Complex int b = 1 + 1i; return - a - b; }
I think both:
/* -A - 1 -> ~A */
(simplify
(minus (convert? (negate @0)) integer_each_onep)
(if (!TYPE_OVERFLOW_TRAPS (type)
&& tree_nop_conversion_p (type, TREE_TYPE (@0)))
(bit_not (convert @0
/* -1 - A -> ~A */
(simplify
(minus integer_all_onesp @0)
(bit_not @0))
needs to punt for COMPLEX_TYPE.
[Bug c/104468] with -O -g, quadratic compile time of function with __attribute__(("00")) that passes large structs by value
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104468 Martin Liška changed: What|Removed |Added Keywords|needs-bisection | CC||marxin at gcc dot gnu.org --- Comment #5 from Martin Liška --- I see the following changes: 2.66s -> 0.8s : r12-2633-ge5e164effa30fd2b 0.8s -> 0.07s : r12-4397-g4cb52980e5d5fb64
[Bug tree-optimization/104675] [9/10/11/12 Regression] ICE: in expand_expr_real_2, at expr.cc:9773 at -O with __real__ + __imag__ extraction
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104675 --- Comment #4 from Andrew Pinski --- (In reply to Jakub Jelinek from comment #3) > > I think both: > /* -A - 1 -> ~A */ > (simplify >(minus (convert? (negate @0)) integer_each_onep) >(if (!TYPE_OVERFLOW_TRAPS (type) > && tree_nop_conversion_p (type, TREE_TYPE (@0))) > (bit_not (convert @0 > > /* -1 - A -> ~A */ > (simplify >(minus integer_all_onesp @0) >(bit_not @0)) > needs to punt for COMPLEX_TYPE. Yes agreed. In fact that is basically what I wrote to the original patch on the mailing list a few minutes ago.
[Bug target/102485] -Wa,-many no longer has any effect
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102485 --- Comment #10 from Alan Modra --- I have spent some time over the last few days digging into history relevant to this bug as part of looking into a binutils report that an ARCH=powerpc CROSS_COMPILE=powerpc-linux- pmac32_defconfig linux kernel no longer builds with binutils-2.38. As a result I've partly reverted the effect of binutils commit "ignore sticky options for .machine", on both mainline binutils and the 2.38 branch. Given the way gcc operates, that commit was a mistake on my part. The initial .machine passed by gcc will again keep -many, -maltivec, -mvsx, -mvle, -mspe or -mspe2 in effect. A .machine later in an assembly file, after some output to any section (even .align counts), will be more strictly enforced. That's the best I can do to solve this mess. It does not completely fix this bug, which I believe is a valid complaint. For instance a user who has power10 asm() but does not want gcc generated power10 code, perhaps due to a gcc code gen bug, might like to use -mcpu=power9 -Wa,-mpower10 on the gcc command line. Instead they would be forced to write ".machine power10" in their asm. (Ideally, .machine push; .machine power10; user asm; .machine pop, on each use of power10 instructions.) At least, that is the case for current mainline gcc and binutils-2.38 where even "-mcpu=power9 -Wa,-many" won't work. We simply cannot dictate to users that their assembly needs rewriting. A lot of this came about by accident. On the gas side, it was by accident that any of the gas command line cpu options were sticky for .machine. The intent behind the sticky options was to support people writing gas command lines like "-maltivec -mppc" as well as the canonical "-mppc -maltivec". When you consider that gas also needs to support multiple cpu options on a command line, with the last overriding any previous selection, it is more obvious why options that add functional units like -maltivec are special. On the gcc side, we have pr59828 and commit b9f12a01bedb5 which is where gcc started to emit .machine rather than passing correct arguments to gas. Current mainline gcc continues to pass the wrong cpu to gas on the command line when multiple -mcpu options are given to gcc, as can be seen by examining -v output from the kernel compile mentioned above. There have been multiple gcc bug reports about that .machine directive, pr71216, pr91050, pr101393 to point out some. This means there are versions of gcc in widespread use that pass an incorrect .machine to gas, which is why I say my gas change to make .machine more strict was a mistake. We can't expect the kernel and other users of the toolchain to cope with gas using wrong cpu info if -many is disabled by .machine. Of course, the bugs in .machine might have been found earlier if -many hadn't been covering them. Similarly for bugs in the linux kernel makefiles; mfsrin and mtsrin are not ppc64 instructions. Overall, I think using .machine as a workaround for pr59828 was a mistake, especially since digging into this bug reminded me that I'd submitted a conceptually simple patch to fix pr59828 by passing on all the cpu args to gas. Which went unreviewed for a whole year before being dismissed.
[Bug tree-optimization/104675] [9/10/11/12 Regression] ICE: in expand_expr_real_2, at expr.cc:9773 at -O with __real__ + __imag__ extraction
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104675 Jakub Jelinek changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org --- Comment #5 from Jakub Jelinek --- Created attachment 52507 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52507&action=edit gcc12-pr104675.patch Full untested patch.
[Bug c++/104537] ICE when generic-lambda as function parameter fails to be converted to pointer to function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104537 Martin Liška changed: What|Removed |Added CC||edlinger at gcc dot gnu.org, ||marxin at gcc dot gnu.org --- Comment #1 from Martin Liška --- Likely started with r10-4254-ge0d91792eec490d1.
[Bug fortran/104554] ICE in check_assumed_size_reference, at fortran/resolve.cc:1650
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104554 Martin Liška changed: What|Removed |Added CC||marxin at gcc dot gnu.org, ||pault at gcc dot gnu.org --- Comment #2 from Martin Liška --- I think it started with r12-570-ga2c593009fef1564.
[Bug fortran/104555] ICE in gfc_compare_derived_types, at fortran/interface.cc:628 since r10-2912-g70570ec192745095
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104555 Martin Liška changed: What|Removed |Added Ever confirmed|0 |1 Summary|ICE in |ICE in |gfc_compare_derived_types, |gfc_compare_derived_types, |at fortran/interface.cc:628 |at fortran/interface.cc:628 ||since ||r10-2912-g70570ec192745095 Last reconfirmed||2022-02-24 Status|UNCONFIRMED |NEW CC||marxin at gcc dot gnu.org, ||pault at gcc dot gnu.org --- Comment #2 from Martin Liška --- Started with r10-2912-g70570ec192745095.
[Bug fortran/104556] ICE in gfc_conv_class_to_class, at fortran/trans-expr.cc:1267 since r12-570-ga2c593009fef1564
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104556 Martin Liška changed: What|Removed |Added Summary|ICE in |ICE in |gfc_conv_class_to_class, at |gfc_conv_class_to_class, at |fortran/trans-expr.cc:1267 |fortran/trans-expr.cc:1267 ||since ||r12-570-ga2c593009fef1564 Ever confirmed|0 |1 Status|UNCONFIRMED |NEW CC||marxin at gcc dot gnu.org, ||pault at gcc dot gnu.org Last reconfirmed||2022-02-24 --- Comment #1 from Martin Liška --- Started with r12-570-ga2c593009fef1564.
[Bug target/104671] -Wa,-m no longer has any effect
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104671
Alan Modra changed:
What|Removed |Added
CC||amodra at gmail dot com
--- Comment #3 from Alan Modra ---
(In reply to Nicholas Piggin from comment #0)
> Commit e154242724b084380e3221df7c08fcdbd8460674 ("Don't pass -many to the
> assembler") also added a workaround emitting a ".machine" directive to the
> top of each generated .s file
Nope, wrong commit. The added .machine there is one in response to an
attribute or pragma selecting a different cpu. ie. it's in response to user
source code saying "compile this function for this particular cpu, not
necessarily the one given on the gcc command line".
Commit b9f12a01bedb5 is the first commit that added .machine to the top of
assembly files. The early .machine was not always emitted by that particular
commit. Always emitting the early .machine came later.
[Bug target/103353] Indefinite recursion when compiling -mmma requiring testcase w/ -maltivec
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103353
--- Comment #7 from Segher Boessenkool ---
(In reply to Kewen Lin from comment #5)
> (In reply to Segher Boessenkool from comment #4)
> > You miss all extra errors the expand_call can generate. This is the general
> > reason why we try to continue instead of stopping after the first error.
> > The
> > reason is that later errors may be more obvious to the user. This of course
> > does no longer work so well because our errors now take 30 lines instead of
> > 1.
>
> Thanks for the explanation! One consequent question is that this point can
> be applied for the other places where some expected conditions don't hold
> for bif expansion, but I saw the other places are using "return const0_rtx".
> Is there something special causing this difference?
Not really, no. In general we try to continue a bit longer (like, evaluate
the arguments, as here). This gives much better diagnostics to the user. In
a few cases you just have to give up early though, for practical reasons.
> > It probably is best if the generic opaque-mode emit_move code does not try
> > to move it via some other mode_class. Peter?
> >
> > Failing that, we can work around it by having move patterns for those modes
> > always, but hard erroring on them (FAIL is no good).
>
> Yeah, one workround can help the ICE gone: (similar thing needed for XOmode
> as well):
>
> diff --git a/gcc/config/rs6000/mma.md b/gcc/config/rs6000/mma.md
> index 907c9d6d516..04e887ad147 100644
> --- a/gcc/config/rs6000/mma.md
> +++ b/gcc/config/rs6000/mma.md
> @@ -268,10 +268,12 @@ (define_int_attr avvi4i4i4 [(UNSPEC_MMA_PMXVI8GER4PP
> "pmxvi8ger4pp")
> (define_expand "movoo"
>[(set (match_operand:OO 0 "nonimmediate_operand")
> (match_operand:OO 1 "input_operand"))]
> - "TARGET_MMA"
> + ""
> {
> - rs6000_emit_move (operands[0], operands[1], OOmode);
> - DONE;
> + if (TARGET_MMA) {
> +rs6000_emit_move (operands[0], operands[1], OOmode);
> +DONE;
> + }
> })
Like that. But with a big fat comment, what is done when !TARGET_MMA, and
why we do that. It is arguably the completely wrong thing to do for opaque
modes.
[Bug libstdc++/68350] std::uninitialized_copy overly restrictive for trivially_copyable types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68350 Jonathan Wakely changed: What|Removed |Added Assignee|ville.voutilainen at gmail dot com |redi at gcc dot gnu.org --- Comment #9 from Jonathan Wakely --- (In reply to Barry Revzin from comment #8) > Whereas the copy_b case could also use memmove. I'd been working on the assumption that it can't, because for types that aren't trivially default constructible we need a constructor to begin the lifetime. But the rules for implicit-lifetime class types only require at least one trivial constructor and a trivial destructor, so a trivial copy constructor is enough. And memcpy/memmove implicitly create objects in the destination storage. I don't think that was really explicit before the implicit-lifetime rules in C++20. The example in C++17 [basic.types] p3 implies that the destination doesn't need to be an initialized object, but nothing said that normatively. Quite the opposite: C++17 [basic.life] seems clear that initialisation must be done for types with non-vacuous initialization (such as Barry's type B), and nothing in C++17 said that memcpy/memmove do any initialization. C++20 is clear though. So: - If the input and output type are the same size and both are trivially constructible, we can use memcpy. We should call memcpy directly from std::uninitialized_copy rather than via std::copy, because std::copy doesn't allow overlapping ranges, and has to use memmove instead. - If the output type is trivially default constructible and is assignable from the input type, we can use std::copy (but it's unclear whether that gives any benefit if we can't turn it into memcpy/memmove). - Otherwise, just use std::construct_at on each element. I have a patch, but it's for stage 1 not GCC 12.
[Bug target/104674] [11/12 Regression] i686 sse2: The two results of __divmoddi4 are mixed up
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104674
Jakub Jelinek changed:
What|Removed |Added
CC||uros at gcc dot gnu.org
--- Comment #3 from Jakub Jelinek ---
So, when emitting the __divmoddi4 call, expand_DIVMOD ->
ix86_expand_divmod_libfunc calls
assign_386_stack_local (E_DImode, SLOT_TEMP)
to obtain a temporary stack slot for the remainder.
(mem:DI (plus:SI (frame) (const_int -8)))
is what is returned and the IL looks reasonable e.g. in vregs:
(insn 12 6 13 2 (parallel [
(set (reg:SI 97)
(plus:SI (reg/f:SI 19 frame)
(const_int -8 [0xfff8])))
(clobber (reg:CC 17 flags))
]) 229 {*addsi_1}
(nil))
...
(insn 19 18 20 2 (set (reg:DI 89 [ divmod_tmp_15 ])
(reg:DI 0 ax)) 80 {*movdi_internal}
(nil))
(insn 20 19 21 2 (set (reg:DI 90 [ divmod_tmp_15+8 ])
(mem/c:DI (plus:SI (reg/f:SI 19 frame)
(const_int -8 [0xfff8])) [0 S8 A64])) 80
{*movdi_internal}
(nil))
...
(insn 25 24 26 2 (set (reg/v:DF 87 [ s ])
(float:DF (reg:DI 89 [ divmod_tmp_15 ]))) "pr104674.c":8:10 214
{*floatdidf2_i387}
(nil))
...
(insn 30 29 31 2 (set (reg:DF 98)
(float:DF (reg:SI 104 [ divmod_tmp_15+8 ]))) "pr104674.c":9:14 207
{*floatsidf2}
(expr_list:REG_DEAD (reg:SI 104 [ divmod_tmp_15+8 ])
(nil)))
i.e. it first loads from the temporary slot and only afterwards does some
further operations on the results.
Later on that insn 20 becomes
(insn 67 19 21 2 (set (reg:SI 104 [ divmod_tmp_15+8 ])
(mem/c:SI (plus:SI (reg/f:SI 19 frame)
(const_int -8 [0xfff8])) [0 S4 A64])) 81
{*movsi_internal}
(nil))
but it is still ok. Combine propagates that memory load into a later insn
though, so we have:
...
(insn 70 18 19 2 (set (reg:DI 106)
(reg:DI 0 ax)) -1
(expr_list:REG_DEAD (reg:DI 0 ax)
(nil)))
...
(insn 25 24 26 2 (set (reg/v:DF 87 [ s ])
(float:DF (reg:DI 106))) "pr104674.c":8:10 214 {*floatdidf2_i387}
(expr_list:REG_DEAD (reg:DI 106)
(nil)))
...
(insn 30 29 31 2 (set (reg:DF 98)
(float:DF (mem/c:SI (plus:SI (reg/f:SI 19 frame)
(const_int -8 [0xfff8])) [0 S4 A64])))
"pr104674.c":9:14 207 {*floatsidf2}
(nil))
i.e. effective it extended the lifetime of the DImode SLOT_TEMP (well, the low
SImode part of it) across insn 25.
But then the split1 pass splits the:
(insn 25 24 26 2 (set (reg/v:DF 87 [ s ])
(float:DF (reg:DI 106))) "pr104674.c":8:10 214 {*floatdidf2_i387}
(expr_list:REG_DEAD (reg:DI 106)
(nil)))
insn into:
(insn 72 24 26 2 (parallel [
(set (reg/v:DF 87 [ s ])
(float:DF (reg:DI 106)))
(clobber (mem/c:DI (plus:SI (reg/f:SI 19 frame)
(const_int -8 [0xfff8])) [0 S8 A64]))
(clobber (scratch:V4SI))
(clobber (scratch:V4SI))
]) "pr104674.c":8:10 -1
(nil))
and uses there assign_386_stack_local (E_DImode, SLOT_TEMP) which returns
the same temporary slot which is unfortunately live across that instruction:
;; Avoid store forwarding (partial memory) stall penalty
;; by passing DImode value through XMM registers. */
(define_split
[(set (match_operand:X87MODEF 0 "register_operand")
(float:X87MODEF
(match_operand:DI 1 "register_operand")))]
"!TARGET_64BIT && TARGET_INTER_UNIT_MOVES_TO_VEC
&& TARGET_80387 && X87_ENABLE_FLOAT (mode, DImode)
&& TARGET_SSE2 && optimize_function_for_speed_p (cfun)
&& can_create_pseudo_p ()"
[(const_int 0)]
{
emit_insn (gen_floatdi2_i387_with_xmm
(operands[0], operands[1],
assign_386_stack_local (DImode, SLOT_TEMP)));
DONE;
})
>From what I can see, SLOT_TEMP is used in:
i386.md: assign_386_stack_local (DImode, SLOT_TEMP)));
i386.md: assign_386_stack_local (DImode, SLOT_TEMP)));
sync.md:assign_386_stack_local (DImode, SLOT_TEMP)));
sync.md: assign_386_stack_local (DImode, SLOT_TEMP)));
i386-expand.cc: target = assign_386_stack_local (SImode, SLOT_TEMP);
i386-expand.cc: target = assign_386_stack_local (SImode, SLOT_TEMP);
i386-expand.cc: rtx rem = assign_386_stack_local (mode, SLOT_TEMP);
and except for this define_split, all other uses are either in some builtin's
expansion or in define_expand, those look good, but in this define_split, I
think it can't guarantee that SLOT_TEMP isn't live across the insn being split.
so we need to use a different SLOT_* kind there.
[Bug target/104674] [11/12 Regression] i686 sse2: The two results of __divmoddi4 are mixed up
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104674 --- Comment #4 from Jakub Jelinek --- Seems similar to PR78791.
[Bug rtl-optimization/104664] [12 Regression] ICE: in extract_constrain_insn, at recog.cc:2670 (insn does not satisfy its constraints) with -Og -ffinite-math-only
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104664
Uroš Bizjak changed:
What|Removed |Added
Keywords||ra
Component|target |rtl-optimization
--- Comment #3 from Uroš Bizjak ---
Reload wants to generate (-mavx2) the following reload for (insn 28):
28: r127:HF=vec_select(r217:V8HF,parallel)
Inserting insn reload before:
177: r218:V8HF=vec_duplicate([`*.LC1'])
178: r217:V8HF=r218:V8HF
But without -mavx2 it generates:
28: r217:HF=vec_select(r218:V8HF,parallel)
Inserting insn reload before:
179: r221:HF=[`*.LC1']
180: r220:V8HF=r221:HF#0
182: r222:V8HF=vec_select(vec_concat(r220:V8HF,r220:V8HF),parallel)
183: r223:V4SI=vec_select(r222:V8HF#0,parallel)
184: r219:V8HF=r223:V4SI#0
185: r218:V8HF=r219:V8HF
Inserting insn reload after:
178: r127:HF=r217:HF
where:
Choosing alt 2 in insn 179: (0) ?r (1) m {*movhf_internal}
Choosing alt 2 in insn 180: (0) v (1) vm {movv8hf_internal}
The allocator could choose alternative 9 (v,m) in:
(define_insn "*movhf_internal"
[(set (match_operand:HF 0 "nonimmediate_operand"
"=?r,?r,?r,?m,v,v,?r,m,?v,v")
(match_operand:HF 1 "general_operand"
"r ,F ,m ,rF,C,v, v,v,r ,m"))]
Since xmm registers support HF and V8HF modes.
Reconfirmed as RA issue.
[Bug c/89408] No constant folding when dereferencing string literals
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89408 --- Comment #7 from Stephen Kell --- Thanks for the backstory. I understand that 'accept as much as possible' isn't the goal, nor would it be wise. The pedwarn message you quoted, which explicitly makes reference to integer constant expressions, is a good one. What's not good is that the issued diagnostic is not that. It is not coming from c/c-typeck.cc. It seems to be coming from c-family/c-common.cc. I now understand why this behaviour has arisen -- the pre-4.5 compatibility hack, combined with whatever foldings the compiler happens to do. I would still say it's not a desirable or desired behaviour. Arguably more desirable would be a behaviour consistent with the analogous extension that is allowed for initializers. Of course keeping the pedwarn -- and adding one for the initializer case, which currently lacks one. Being neither stable nor documented is still fine for many purposes (including mine).
[Bug tree-optimization/104676] New: [12 Regression] ICE in verify_loop_structure, at cfgloop.cc:1748 (error: loop 3's number of iterations '(unsigned int) + 4294967295' references the released SSA nam
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104676
Bug ID: 104676
Summary: [12 Regression] ICE in verify_loop_structure, at
cfgloop.cc:1748 (error: loop 3's number of iterations
'(unsigned int) + 4294967295' references the released
SSA name '')
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: ---
gcc 12.0.1 20220220 snapshot (g:e49508ac6b36adb8a2056c5a1fb6e0178de2439d) ICEs
when compiling the following testcase w/ -O1 -ftree-loop-distribution
-ftree-parallelize-loops=2:
struct S {
int f;
};
int n;
int
foo (struct S *s)
{
int arr[3];
int v = 0;
for (n = 0; n < 2; ++n)
{
int i;
for (i = 0; i < 2; ++i)
{
int j;
for (j = 0; j < s->f; ++j)
++v;
}
if (v)
arr[0] = 0;
arr[n + 1] = 0;
}
return arr[0];
}
% gcc-12.0.1 -O1 -ftree-loop-distribution -ftree-parallelize-loops=2 -c
opcatmkb.c
opcatmkb.c: In function 'foo':
opcatmkb.c:8:1: error: loop 3's number of iterations '(unsigned int) +
4294967295' references the released SSA name ''
8 | foo (struct S *s)
| ^~~
during GIMPLE pass: ldist
opcatmkb.c:8:1: internal compiler error: in verify_loop_structure, at
cfgloop.cc:1748
0x68eb89 verify_loop_structure()
/var/tmp/portage/sys-devel/gcc-12.0.1_p20220220/work/gcc-12-20220220/gcc/cfgloop.cc:1748
0xf752ee checking_verify_loop_structure
/var/tmp/portage/sys-devel/gcc-12.0.1_p20220220/work/gcc-12-20220220/gcc/cfgloop.h:646
0xf752ee loop_distribution::execute(function*)
/var/tmp/portage/sys-devel/gcc-12.0.1_p20220220/work/gcc-12-20220220/gcc/tree-loop-distribution.cc:3861
0xf7551b execute
/var/tmp/portage/sys-devel/gcc-12.0.1_p20220220/work/gcc-12-20220220/gcc/tree-loop-distribution.cc:3905
[Bug gcov-profile/104677] New: With -fprofile-arcs, the name of the .gcda file is incorrect
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104677
Bug ID: 104677
Summary: With -fprofile-arcs, the name of the .gcda file is
incorrect
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: gcov-profile
Assignee: unassigned at gcc dot gnu.org
Reporter: vincent-gcc at vinc17 dot net
CC: marxin at gcc dot gnu.org
Target Milestone: ---
Under Debian/unstable, if I do "gcc foo.c -o foo2 -fprofile-arcs", the name of
the .gcda file is "foo2-foo.gcda" instead of "foo.gcda".
The behavior is correct until GCC 10.3.0, but it is incorrect with GCC 11.2.0
and
gcc-12 (Debian 12-20220222-1) 12.0.1 20220222 (experimental) [master
r12-7325-g2f59f067610].
The current gcc/doc/invoke.texi documentation for -fprofile-arcs contains:
Each object file's @var{auxname} is generated from the name of the output file,
if explicitly specified and it is not the final executable, otherwise it is the
basename of the source file.
but this has not changed since GCC 9 at least. Here, foo2 is the final
executable (but why the word "final"?), so that one should be in the
"otherwise" case.
[Bug target/104674] [11/12 Regression] i686 sse2: The two results of __divmoddi4 are mixed up
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104674 --- Comment #5 from Jakub Jelinek --- Created attachment 52508 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52508&action=edit gcc12-pr104674.patch Untested fix.
[Bug c++/104670] [9/10/11/12 Regression] ICE when using decltype of a lambda returning a struct inside of a struct
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104670 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org, ||mpolacek at gcc dot gnu.org, ||ppalka at gcc dot gnu.org Summary|ICE when using decltype of |[9/10/11/12 Regression] ICE |a lambda returning a struct |when using decltype of a |inside of a struct |lambda returning a struct ||inside of a struct Priority|P3 |P4 Target Milestone|--- |9.5 --- Comment #3 from Jakub Jelinek --- Well, it is a regression since r9-4045-g0c1e0d63fe0ceabbd04384070f3b59f8bf50de09 because before that we rejected the testcase, now we rejecte it for a different reason and ICE during error recovery. But error recovery ICEs are lower priority.
[Bug fortran/104569] ICE in generate_coarray_sym_init, at fortran/trans-decl.cc:5537 since r8-3365-gb89a63b916340ef2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104569 Martin Liška changed: What|Removed |Added Summary|ICE in |ICE in |generate_coarray_sym_init, |generate_coarray_sym_init, |at |at |fortran/trans-decl.cc:5537 |fortran/trans-decl.cc:5537 ||since ||r8-3365-gb89a63b916340ef2 Status|UNCONFIRMED |NEW Ever confirmed|0 |1 Last reconfirmed||2022-02-24 CC||marxin at gcc dot gnu.org, ||pault at gcc dot gnu.org --- Comment #1 from Martin Liška --- Started with r8-3365-gb89a63b916340ef2.
[Bug gcov-profile/104677] With -fprofile-arcs, the name of the .gcda file is incorrect
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104677 Richard Biener changed: What|Removed |Added CC||aoliva at gcc dot gnu.org Version|unknown |11.2.0 Keywords||documentation --- Comment #1 from Richard Biener --- It's working as intended, maybe the documentation can be clarified. See https://gcc.gnu.org/gcc-11/changes.html in the Caveats section we have 'Naming and location of auxiliary and dump output files changed. If you compile multiple input files in a single command, if you enable Link Time Optimization, or if you use -dumpbase, -dumpdir, -save-temps=*, and you expect any file other than the primary output file(s) to be created as a side effect, watch out for improvements and a few surprises. See the patch, particularly its textual description, for more details about the changes.'
[Bug tree-optimization/104676] [12 Regression] ICE in verify_loop_structure, at cfgloop.cc:1748 (error: loop 3's number of iterations '(unsigned int) + 4294967295' references the released SSA name '
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104676 Jakub Jelinek changed: What|Removed |Added Last reconfirmed||2022-02-24 Target Milestone|--- |12.0 CC||jakub at gcc dot gnu.org, ||rguenth at gcc dot gnu.org Priority|P3 |P1 Ever confirmed|0 |1 Status|UNCONFIRMED |NEW --- Comment #1 from Jakub Jelinek --- Started with r12-7228-g0a1a3afb5fb36e2d10ad92bf788e16d837451571
[Bug tree-optimization/104676] [12 Regression] ICE in verify_loop_structure, at cfgloop.cc:1748 (error: loop 3's number of iterations '(unsigned int) + 4294967295' references the released SSA name '
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104676 Richard Biener changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org Keywords||ice-checking Status|NEW |ASSIGNED --- Comment #2 from Richard Biener --- I will have a look.
[Bug fortran/104570] [12 Regression] ICE in gfc_conv_scalarized_array_ref, at fortran/trans-array.cc:3681 since r12-7217-g57da34939703a6e6
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104570 Martin Liška changed: What|Removed |Added CC||marxin at gcc dot gnu.org, ||mikael at gcc dot gnu.org Ever confirmed|0 |1 Last reconfirmed||2022-02-24 Summary|[12 Regression] ICE in |[12 Regression] ICE in |gfc_conv_scalarized_array_r |gfc_conv_scalarized_array_r |ef, at |ef, at |fortran/trans-array.cc:3681 |fortran/trans-array.cc:3681 ||since ||r12-7217-g57da34939703a6e6 Status|UNCONFIRMED |NEW --- Comment #2 from Martin Liška --- Started with r12-7217-g57da34939703a6e6.
[Bug tree-optimization/104676] [12 Regression] ICE in verify_loop_structure, at cfgloop.cc:1748 (error: loop 3's number of iterations '(unsigned int) + 4294967295' references the released SSA name '
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104676 --- Comment #3 from Richard Biener --- loop distribution removes _31 = s_18(D)->f; releasing SSA name 31 but loop 3 still has nb_iterations == (unsigned int) _31 + 4294967295 loop distribution already does scev_reset_htab but should just use scev_reset here.
[Bug driver/104614] "Undocumented" option flag ignored with --help=target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104614 Martin Liška changed: What|Removed |Added CC||marxin at gcc dot gnu.org Status|UNCONFIRMED |ASSIGNED Ever confirmed|0 |1 Last reconfirmed||2022-02-24 --- Comment #3 from Martin Liška --- I can take a look at this.
[Bug libstdc++/68350] std::uninitialized_copy overly restrictive for trivially_copyable types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68350
--- Comment #10 from Jonathan Wakely ---
(In reply to Jonathan Wakely from comment #9)
> - If the input and output type are the same size and both are trivially
> constructible, we can use memcpy.
Correction: they need to be the same type. We can't memcpy here:
struct A { };
struct B { B() = default; B(A) { do_stuff(); } };
void (A* f, A* l, B* out) {
std::uninitialized_copy(f, l, out);
}
Both types are trivially copyable, but using memcpy is only valid for a single
type.
[Bug fortran/104625] ICE in fixup_array_ref, at fortran/resolve.cc:9275 since r10-2912-g70570ec192745095
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104625 Martin Liška changed: What|Removed |Added Summary|ICE in fixup_array_ref, at |ICE in fixup_array_ref, at |fortran/resolve.cc:9275 |fortran/resolve.cc:9275 ||since ||r10-2912-g70570ec192745095 CC||marxin at gcc dot gnu.org, ||pault at gcc dot gnu.org Ever confirmed|0 |1 Status|UNCONFIRMED |NEW Last reconfirmed||2022-02-24 --- Comment #2 from Martin Liška --- Started with r10-2912-g70570ec192745095.
[Bug c/104627] [12 Regression] New failure in deprecated.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104627 Martin Liška changed: What|Removed |Added Ever confirmed|0 |1 Last reconfirmed||2022-02-24 Status|UNCONFIRMED |NEW CC||jason at gcc dot gnu.org, ||marxin at gcc dot gnu.org
[Bug tree-optimization/104675] [9/10/11/12 Regression] ICE: in expand_expr_real_2, at expr.cc:9773 at -O with __real__ + __imag__ extraction
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104675
--- Comment #6 from Marc Glisse ---
I am only learning now that bit ops don't exist for complex numbers :-/
I don't really see why not, but that's a different question. Thanks for fixing
this.
Looking to see if I could quickly find other similar issues, I only noticed 2
ICEs
typedef _Complex unsigned T;
T f(T x){
return (x/2)*2;
}
T g(T x){
return (x*2)/2;
}
[Bug tree-optimization/104601] [11/12 Regression] Invalid branch elimination at -O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104601
--- Comment #12 from CVS Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:9251b457eb8df912f2e8203d0ee8ab300c041520
commit r12-7371-g9251b457eb8df912f2e8203d0ee8ab300c041520
Author: Jakub Jelinek
Date: Thu Feb 24 15:29:02 2022 +0100
sccvn: Fix visit_reference_op_call value numbering of vdefs [PR104601]
The following testcase is miscompiled, because -fipa-pure-const discovers
that bar is const, but when sccvn during fre3 sees
# .MEM_140 = VDEF <.MEM_96>
*__pred$__d_43 = _50 (_49);
where _50 value numbers to &bar, it value numbers .MEM_140 to
vuse_ssa_val (gimple_vuse (stmt)). For const/pure calls that return
a SSA_NAME (or don't have lhs) that is fine, those calls don't store
anything, but if the lhs is present and not an SSA_NAME, value numbering
the vdef to anything but itself means that e.g. walk_non_aliased_vuses
won't consider the call, but the call acts as a store to its lhs.
When it is ignored, sccvn will return whatever has been stored to the
lhs earlier.
I've bootstrapped/regtested an earlier version of this patch, which did the
if (!lhs && gimple_call_lhs (stmt))
changed |= set_ssa_val_to (vdef, vdef);
part before else if (vnresult->result_vdef), and that regressed
+FAIL: gcc.dg/pr51879-16.c scan-tree-dump-times pre "foo (" 1
+FAIL: gcc.dg/pr51879-16.c scan-tree-dump-times pre "foo2 (" 1
so this updated patch uses result_vdef there as before and only otherwise
(which I think must be the const/pure case) decides based on whether the
lhs is non-SSA_NAME.
2022-02-24 Jakub Jelinek
PR tree-optimization/104601
* tree-ssa-sccvn.cc (visit_reference_op_call): For calls with
non-SSA_NAME lhs value number vdef to itself instead of e.g. the
vuse value number.
* g++.dg/torture/pr104601.C: New test.
[Bug tree-optimization/104601] [11 Regression] Invalid branch elimination at -O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104601 Jakub Jelinek changed: What|Removed |Added Summary|[11/12 Regression] Invalid |[11 Regression] Invalid |branch elimination at -O2 |branch elimination at -O2 --- Comment #13 from Jakub Jelinek --- Fixed on the trunk so far.
[Bug target/104662] arm: ice in simd_valid_immediate
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104662
Christophe Lyon changed:
What|Removed |Added
CC||clyon at gcc dot gnu.org
--- Comment #1 from Christophe Lyon ---
Hello,
Do you mean you are running 'make check' with a cross-gcc configure with
--target arm-linux-gnueabif and you see this failure? On my side, 'make check'
shows no error on this test.
Given the flags you show, it seems you are in fact compiling the testcase by
hand, effectively not including the mandatory -march=armv8.1-m.main+mve?
V*BI types require MVE, so the test is not supposed to run without this option.
However, this small change avoids the ICE:
diff --git a/gcc/config/arm/arm.cc b/gcc/config/arm/arm.cc
index c1103d9..5adc45b 100644
--- a/gcc/config/arm/arm.cc
+++ b/gcc/config/arm/arm.cc
@@ -12811,6 +12811,9 @@ simd_valid_immediate (rtx op, machine_mode mode, int
inverse,
|| n_elts * innersize != 16))
return -1;
+ if (!TARGET_HAVE_MVE && (GET_MODE_CLASS (mode) == MODE_VECTOR_BOOL))
+ return -1;
+
/* Vectors of float constants. */
if (GET_MODE_CLASS (mode) == MODE_VECTOR_FLOAT)
{
[Bug target/104662] arm: ice in simd_valid_immediate
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104662
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #2 from Jakub Jelinek ---
(In reply to Christophe Lyon from comment #1)
> --- a/gcc/config/arm/arm.cc
> +++ b/gcc/config/arm/arm.cc
> @@ -12811,6 +12811,9 @@ simd_valid_immediate (rtx op, machine_mode mode, int
> inverse,
> || n_elts * innersize != 16))
> return -1;
>
> + if (!TARGET_HAVE_MVE && (GET_MODE_CLASS (mode) == MODE_VECTOR_BOOL))
> + return -1;
> +
>/* Vectors of float constants. */
>if (GET_MODE_CLASS (mode) == MODE_VECTOR_FLOAT)
> {
Formatting, wrong indentation of return -1; and useless ()s around the ==.
[Bug libstdc++/68350] std::uninitialized_copy overly restrictive for trivially_copyable types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68350
--- Comment #11 from Jonathan Wakely ---
(In reply to Jonathan Wakely from comment #9)
> - If the output type is trivially default constructible and is assignable
> from
> the input type, we can use std::copy (but it's unclear whether that gives
> any
> benefit if we can't turn it into memcpy/memmove).
It's also not clear that it would be allowed.
struct A { };
struct B {
B() = default;
B(A) { do_stuff(); }
B& operator=(A) { do_other_stuff(); }
};
void (A* f, A* l, B* out) {
std::uninitialized_copy(f, l, out);
}
It's observable whether we construct B from A, or default construct B and then
assign to it from A.
My patch just removes all uses of std::copy/fill/fill_n in the
std::uninitialized_copy/fill/fill_n algos.
[Bug libstdc++/68350] std::uninitialized_copy overly restrictive for trivially_copyable types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68350
--- Comment #12 from Arthur O'Dwyer ---
jwakely wrote:
> Correction: they need to be the same type. We can't memcpy here:
>
> struct A { };
> struct B { B() = default; B(A) { do_stuff(); } };
>
> void (A* f, A* l, B* out) {
> std::uninitialized_copy(f, l, out);
> }
Right, in your case, the ctor `B(A)` runs user-defined code (it's not
"trivial") so obviously we can't do the optimization. But even in general, see
my 2018 blog post "Trivially-constructible-from."
https://quuxplusone.github.io/blog/2018/07/03/trivially-constructible-from/
using A2 = long long;
using B2 = int64_t; // for the sake of argument, this is "long int"
void (A* f, A* l, B* out) {
std::uninitialized_copy(f, l, out);
}
The library can't, by itself, determine that memcpy would be safe here. The
library needs help from the compiler, e.g. via a new compiler builtin
__is_trivially_constructible_from(T, U). (This is *not* the same as the
existing `is_trivially_constructible` type trait, because blog post.)
[Bug tree-optimization/104676] [12 Regression] ICE in verify_loop_structure, at cfgloop.cc:1748 (error: loop 3's number of iterations '(unsigned int) + 4294967295' references the released SSA name '
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104676 --- Comment #4 from CVS Commits --- The master branch has been updated by Richard Biener : https://gcc.gnu.org/g:a4066d3a5097333f17c0d7be1630a98f3a5b1c1d commit r12-7372-ga4066d3a5097333f17c0d7be1630a98f3a5b1c1d Author: Richard Biener Date: Thu Feb 24 14:34:52 2022 +0100 tree-optimization/104676 - free nb_iterations after loop distribution Loop distribution can release SSA names used in nb_iterations, make sure to release those. 2022-02-24 Richard Biener PR tree-optimization/104676 * tree-loop-distribution.cc (loop_distribution::execute): Do a full scev_reset. * gcc.dg/torture/pr104676.c: New testcase.
[Bug tree-optimization/104676] [12 Regression] ICE in verify_loop_structure, at cfgloop.cc:1748 (error: loop 3's number of iterations '(unsigned int) + 4294967295' references the released SSA name '
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104676 Richard Biener changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #5 from Richard Biener --- Fixed.
[Bug c++/104678] New: pointer to member cannot be passed as template argument after derived/base cast
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104678
Bug ID: 104678
Summary: pointer to member cannot be passed as template
argument after derived/base cast
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: schaumb at gmail dot com
Target Milestone: ---
If I has a pointer to member value, when I static cast to derived member
pointer then back to the original, it cannot be used as a template argument.
struct B { int m; };
struct D : B {};
template
struct X;
constexpr int B::* memptr = &B::m;
constexpr int B::* same_p = static_cast(static_cast(&B::m));
static_assert(memptr == same_p, ""); // OK
// static_assert(std::is_corresponding_member(memptr, same_p)); // OK
using Good = X; // OK
using Bad = X; // error
fails with the following message:
error: '0' is not a valid template argument for type 'int B::*'
note: it must be a pointer-to-member of the form '&X::Y
as you can see here:
https://godbolt.org/z/oa3jY6c41
The C++20 ISO says:
§ 7.3.12, 2:
A prvalue of type “pointer to member of B of type cv T”, where B is a class
type, can be converted to a prvalue of type “pointer to member of D of type cv
T”, where D is a complete class derived (11.7) from B.
The result of the conversion refers to the same member as the pointer to member
before the conversion took place, but it refers to the base class member as if
it were a member of the derived class. The result refers to the member in D’s
instance of B.
The result is the same as if indirecting through the pointer to member of B
with the B subobject of D.
§ 7.6.1.7, 12:
A prvalue of type “pointer to member of D of type cv1 T” can be converted to a
prvalue of type “pointer to member of B of type cv2 T”, where D is a complete
class type and B is a base class (11.7) of D, if cv2 is the same
cv-qualification as, or greater cv-qualification than, cv1.
If class B contains the original member, or is a base or derived class of the
class containing the original member, the resulting pointer to member points to
the original member.
- All gcc version affected
- The problem is system independent
- The gcc compile options are not related
- command line: see at godbolt, g++ main.cpp
- error message: see above
[Bug gcov-profile/104677] Please update documentation about the name of the .gcda files
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104677
Vincent Lefèvre changed:
What|Removed |Added
Summary|With -fprofile-arcs, the|Please update documentation
|name of the .gcda file is |about the name of the .gcda
|incorrect |files
--- Comment #2 from Vincent Lefèvre ---
OK. The patch should have updated the -fprofile-arcs documentation.
BTW, @file{@var{sourcename}.gcda} appears a couple of times in invoke.texi (for
-fbranch-probabilities and for -fprofile-dir). This should be updated too.
[Bug gcov-profile/104677] Please update documentation about the name of the .gcda files
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104677 Martin Liška changed: What|Removed |Added Ever confirmed|0 |1 Assignee|unassigned at gcc dot gnu.org |marxin at gcc dot gnu.org Last reconfirmed||2022-02-24 Status|UNCONFIRMED |ASSIGNED --- Comment #3 from Martin Liška --- I'm going to update the documentation.
[Bug c++/104629] Constexpr static functions and variables in templates, in the wrong order and under specific circumstances produces ICEs under some versions, compiles (but shouldn't) on others
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104629 Martin Liška changed: What|Removed |Added CC||jason at gcc dot gnu.org, ||marxin at gcc dot gnu.org Last reconfirmed||2022-02-24 Ever confirmed|0 |1 Status|UNCONFIRMED |NEW --- Comment #2 from Martin Liška --- With -std=c++14 it started with r11-703-g7b599b9f9a1e036f.
[Bug target/104637] ICE: maximum number of LRA assignment passes is achieved (30) with -Og -fno-forward-propagate -mavx since r9-5221-gd8fcab689435a29d
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104637 Martin Liška changed: What|Removed |Added Last reconfirmed||2022-02-24 CC||jakub at gcc dot gnu.org, ||marxin at gcc dot gnu.org Summary|ICE: maximum number of LRA |ICE: maximum number of LRA |assignment passes is|assignment passes is |achieved (30) with -Og |achieved (30) with -Og |-fno-forward-propagate |-fno-forward-propagate |-mavx |-mavx since ||r9-5221-gd8fcab689435a29d Status|UNCONFIRMED |NEW Ever confirmed|0 |1 --- Comment #1 from Martin Liška --- Started with r9-5221-gd8fcab689435a29d.
[Bug rtl-optimization/104638] ICE: maximum number of LRA assignment passes is achieved (30) with -O since r12-1128-gef8176e0fac935c0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104638 Martin Liška changed: What|Removed |Added Summary|ICE: maximum number of LRA |ICE: maximum number of LRA |assignment passes is|assignment passes is |achieved (30) with -O |achieved (30) with -O since ||r12-1128-gef8176e0fac935c0 Last reconfirmed||2022-02-24 Status|UNCONFIRMED |NEW CC||marxin at gcc dot gnu.org, ||rguenth at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Martin Liška --- Started with r12-1128-gef8176e0fac935c0.
[Bug target/104643] gcc/config/rs6000/driver-rs6000.cc: 2 * pointless call ?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104643 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |NEW CC||andreast at gcc dot gnu.org, ||marxin at gcc dot gnu.org Last reconfirmed||2022-02-24 Ever confirmed|0 |1 --- Comment #1 from Martin Liška --- Confirmed, the code is there since g:3b7abfdae7e8e03e26f6b8066336d388eac17277.
[Bug tree-optimization/104679] New: [12 Regression] ICE in connect_traces, at dwarf2cfi.c:3071 since r12-6637-g463d9108766dcbb6
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104679
Bug ID: 104679
Summary: [12 Regression] ICE in connect_traces, at
dwarf2cfi.c:3071 since r12-6637-g463d9108766dcbb6
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: marxin at gcc dot gnu.org
CC: jakub at redhat dot com
Target Milestone: ---
Reduced from libreoffice:
$ cat ice.ii
namespace rtl {
struct OStringBuffer {
~OStringBuffer();
};
} // namespace rtl
using rtl::OStringBuffer;
void lclSplitBlock(double, long);
void lclAppendBlock();
double ScInterpreterScBahtText_fBaht;
long ScInterpreterScBahtText_nSatang;
void ScInterpreterScBahtText() {
lclSplitBlock(ScInterpreterScBahtText_fBaht,
ScInterpreterScBahtText_nSatang);
if (ScInterpreterScBahtText_fBaht == 0.0)
;
else
while (ScInterpreterScBahtText_fBaht > 0.0) {
OStringBuffer aBlock;
lclAppendBlock();
}
}
$ g++ ice.ii -O2 -m32 -c
during RTL pass: dwarf2
ice.ii: In function ‘void ScInterpreterScBahtText()’:
ice.ii:20:1: internal compiler error: in connect_traces, at dwarf2cfi.cc:3071
20 | }
| ^
0x7d36b1 connect_traces
/home/marxin/Programming/gcc/gcc/dwarf2cfi.cc:3071
0x7d36b1 execute_dwarf2_frame
/home/marxin/Programming/gcc/gcc/dwarf2cfi.cc:3302
0x7d36b1 execute
/home/marxin/Programming/gcc/gcc/dwarf2cfi.cc:3789
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See
[Bug tree-optimization/104679] [12 Regression] ICE in connect_traces, at dwarf2cfi.c:3071 since r12-6637-g463d9108766dcbb6
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104679 Martin Liška changed: What|Removed |Added Target Milestone|--- |12.0 Status|UNCONFIRMED |NEW Ever confirmed|0 |1 Priority|P3 |P1 Last reconfirmed||2022-02-24
[Bug c++/104647] [9/10/11/12 Regression] ICE in get_or_insert_ctor_field, at cp/constexpr.cc:3705 since r9-3836-g4be5c72cf3ea3ee9
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104647 Martin Liška changed: What|Removed |Added Summary|[9/10/11/12 Regression] ICE |[9/10/11/12 Regression] ICE |in |in |get_or_insert_ctor_field, |get_or_insert_ctor_field, |at cp/constexpr.cc:3705 |at cp/constexpr.cc:3705 ||since ||r9-3836-g4be5c72cf3ea3ee9 CC||jason at gcc dot gnu.org, ||marxin at gcc dot gnu.org --- Comment #2 from Martin Liška --- Started with r9-3836-g4be5c72cf3ea3ee9.
[Bug fortran/104649] ICE in gfc_match_formal_arglist, at fortran/decl.cc:6733 since r6-1958-g4668d6f9c00d4767
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104649 Martin Liška changed: What|Removed |Added Summary|ICE in |ICE in |gfc_match_formal_arglist, |gfc_match_formal_arglist, |at fortran/decl.cc:6733 |at fortran/decl.cc:6733 ||since ||r6-1958-g4668d6f9c00d4767 CC||marxin at gcc dot gnu.org, ||pault at gcc dot gnu.org Status|UNCONFIRMED |NEW Ever confirmed|0 |1 Last reconfirmed||2022-02-24 --- Comment #1 from Martin Liška --- Started with r6-1958-g4668d6f9c00d4767.
[Bug fortran/104650] [PDT] ICE in gfc_resolve_finalizers, at fortran/resolve.cc:13749 since r8-3056-g5bab4c9631c478b7
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104650 Martin Liška changed: What|Removed |Added Last reconfirmed||2022-02-24 Ever confirmed|0 |1 CC||marxin at gcc dot gnu.org, ||pault at gcc dot gnu.org Summary|[PDT] ICE in|[PDT] ICE in |gfc_resolve_finalizers, at |gfc_resolve_finalizers, at |fortran/resolve.cc:13749|fortran/resolve.cc:13749 ||since ||r8-3056-g5bab4c9631c478b7 Status|UNCONFIRMED |NEW --- Comment #2 from Martin Liška --- Started with r8-3056-g5bab4c9631c478b7.
[Bug c++/104668] [12 Regression] ICE in lookup_attribute_spec, at attribs.cc:425
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104668 Martin Liška changed: What|Removed |Added CC||marxin at gcc dot gnu.org --- Comment #2 from Martin Liška --- (In reply to Marek Polacek from comment #1) > Started with r12-6904. Please update to the latest version of git gcc-descr alias (that append git hash by default). Thanks.
[Bug target/104656] [12 Regression] trunk 20220222 ftbfs for bpf
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104656 --- Comment #6 from CVS Commits --- The master branch has been updated by Jose E. Marchesi : https://gcc.gnu.org/g:39be73d07bb667fd5d313a3398f5399e091f2c0c commit r12-7373-g39be73d07bb667fd5d313a3398f5399e091f2c0c Author: Jose E. Marchesi Date: Wed Feb 23 20:48:30 2022 +0100 bpf: do not --enable-gcov for bpf-*-* targets This patch changes the build machinery in order to disable the build of GCOV (both compiler and libgcc) in bpf-*-* targets. The reason for this change is that BPF is (currently) too restricted in order to support the coverage instrumentalization. Tested in bpf-unknown-none and x86_64-linux-gnu targets. 2022-02-23 Jose E. Marchesi gcc/ChangeLog PR target/104656 * configure.ac: --disable-gcov if targetting bpf-*. * configure: Regenerate. libgcc/ChangeLog PR target/104656 * configure.ac: --disable-gcov if targetting bpf-*. * configure: Regenerate.
[Bug c/104680] New: identical inner condition not detected
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104680
Bug ID: 104680
Summary: identical inner condition not detected
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 this C++ code, with a identical inner condition:
extern void g( int);
void f( int n)
{
if (n > 31)
{
if (n > 31)
{
g( 2 * n);
}
}
else
g( n);
}
g++ currently has nothing to say:
$ /home/dcb/gcc/results/bin/g++ -c -g -O2 -Wall -Wextra -Wduplicated-branches
feb24e.cc
$
cppcheck managed to find the problem, usually a result of
sloppy cut'n'paste:
feb24e.cc:8:9: warning: Identical inner 'if' condition is always true.
[identicalInnerCondition]
if (n > 31)
^
feb24e.cc:6:8: note: outer condition: n>31
if (n > 31)
^
feb24e.cc:8:9: note: identical inner condition: n>31
if (n > 31)
^
Here is a list of all the places in the gcc source code where this
problem occurs:
trunk.git/gcc/config/avr/avr.cc:8674:22: warning: Identical inner 'if'
condition is always true. [identicalInnerCondition]
trunk.git/gcc/config/mn10300/mn10300.cc:888:8: warning: Identical inner 'if'
condition is always true. [identicalInnerCondition]
trunk.git/gcc/d/expr.cc:689:17: warning: Identical inner 'if' condition is
always true. [identicalInnerCondition]
trunk.git/libffi/src/m32r/ffi.c:66:15: warning: Identical inner 'if' condition
is always true. [identicalInnerCondition]
trunk.git/liboffloadmic/runtime/offload_engine.cpp:113:13: warning: Identical
inner 'if' condition is always true. [identicalInnerCondition]
trunk.git/zlib/contrib/minizip/zip.c:1212:26: warning: Identical inner 'if'
condition is always true. [identicalInnerCondition]
There are also 67 cases of this in the current linux kernel,
so it looks like it might be a real problem.
[Bug c/104680] identical inner condition not detected
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104680 Andrew Pinski changed: What|Removed |Added Severity|normal |enhancement Keywords||diagnostic --- Comment #1 from Andrew Pinski --- Wduplicated-branches only currently works for the a && a case and not the if (a) if (a) case. Maybe this could be done by the analyzer instead.
[Bug middle-end/104679] [12 Regression] ICE in connect_traces, at dwarf2cfi.c:3071 since r12-6637-g463d9108766dcbb6
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104679 Jakub Jelinek changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org Status|NEW |ASSIGNED --- Comment #1 from Jakub Jelinek --- Created attachment 52509 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52509&action=edit gcc12-pr104679.patch Untested fix.
[Bug target/22271] No builtin preprocessing defines to tell SDATA mode.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=22271 Eric Gallager changed: What|Removed |Added CC||egallager at gcc dot gnu.org Resolution|--- |WONTFIX Status|WAITING |RESOLVED --- Comment #6 from Eric Gallager --- (In reply to Martin Sebor from comment #5) > This enhancement request has a patch but it's over 10 years old. Is it > still applicable/worthwhile applying? If so, Sergei, can you post it to > gcc-patches? If not, should it be closed as WONTFIX? probably not; closing as WONTFIX
[Bug libstdc++/70508] libstdc++.*-gdb.py': No such file or directory
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70508 Eric Gallager changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |INVALID CC||egallager at gcc dot gnu.org --- Comment #2 from Eric Gallager --- (In reply to Jonathan Wakely from comment #1) > (In reply to Fiodar from comment #0) > > Making install in python > > make[3]: Entering directory > > `/d/mbuild/src/build-gcc/arm-none-symbianelf/libstdc++-v3/python' > > make[4]: Entering directory > > `/d/mbuild/src/build-gcc/arm-none-symbianelf/libstdc++-v3/python' > > make[4]: Nothing to be done for `install-exec-am'. > > /bin/install -c -m 644 gdb.py > > /usr/local/gcc-5.3.0/arm-none-symbianelf/lib/libstdc++.*-gdb.py > > /bin/install: cannot create regular file > > `/usr/local/gcc-5.3.0/arm-none-symbianelf/lib/libstdc++.*-gdb.py': No such > > file or directory > > This means libstdc++.* didn't match any files, which means the shared lib > hasn't been built yet. That shouldn't happen. > > Do you still see this with current releases? no reply from the reporter; closing due to being left in WAITING for over 3 months
[Bug c++/91777] No warning for iterator going out of scope
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91777
Eric Gallager changed:
What|Removed |Added
Resolution|--- |WONTFIX
Status|WAITING |RESOLVED
--- Comment #9 from Eric Gallager ---
(In reply to Eric Gallager from comment #8)
> (In reply to Jonathan Wakely from comment #7)
> > It's also diagnosed by libstdc++ Debug Mode:
> >
> > /home/jwakely/gcc/10/include/c++/10.0.0/debug/safe_iterator.h:294:
> > In function:
> > __gnu_debug::_Safe_iterator<_Iterator, _Sequence, _Category>::reference
> > __gnu_debug::_Safe_iterator<_Iterator, _Sequence,
> > _Category>::operator*() const [with _Iterator =
> > std::__cxx1998::_List_const_iterator; _Sequence =
> > std::__debug::list; _Category = std::forward_iterator_tag;
> > __gnu_debug::_Safe_iterator<_Iterator, _Sequence, _Category>::reference
> > = const int&]
> >
> > Error: attempt to dereference a singular iterator.
> >
> > Objects involved in the operation:
> > iterator "this" @ 0x0x7b1db7f0 {
> > type = std::__cxx1998::_List_const_iterator (constant iterator);
> > state = singular;
> > }
> > Aborted (core dumped)
> >
> >
> > I don't think it's feasible to warn about this. As far as the compiler
> > knows, the iterator is just a value type. It's not practical to expect the
> > compiler to track that it contains a pointer to a node that is about to be
> > destroyed by a container going out of scope.
>
> Maybe not in the compiler proper; could be material for someone to write a
> plugin for...
eh, in any case, it doesn't look like anyone's going to work on this; closing
as WONTFIX
[Bug c++/87403] [Meta-bug] Issues that suggest a new warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87403 Bug 87403 depends on bug 91777, which changed state. Bug 91777 Summary: No warning for iterator going out of scope https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91777 What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |WONTFIX
[Bug other/92456] libiberty/make-relative-prefix.c: read buffer overflow in split_directories()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92456 Eric Gallager changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |tim.ruehsen at gmx dot de Status|WAITING |NEW CC||egallager at gcc dot gnu.org URL||https://gcc.gnu.org/ml/gcc- ||patches/2019-11/msg02593.ht ||ml Keywords||patch --- Comment #3 from Eric Gallager --- (In reply to Tim Ruehsen from comment #2) > (In reply to Martin Liška from comment #1) > > @Tim: Can you please send the patch to GCC patches mailing list? > > It's long ago, but finally found it: > https://gcc.gnu.org/ml/gcc-patches/2019-11/msg02593.html ok, taking out of WAITING and assigning to you, then
[Bug c/104468] with -O -g, quadratic compile time of function with __attribute__(("00")) that passes large structs by value
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104468
--- Comment #6 from Erik Carstensen ---
thanks! Looks like the second change repairs __attribute__((optimize("O0")));
this leads to a smaller reproducer: the problem is reproduced if I remove that
attribute and compile with "-g -O0 -fvar-tracking" only.
The first commit somehow enables "QI vector mode", whatever that is. 0.8s still
seems like quite a lot; what happens in a recent gcc if you change the function
to, say,
void f(void)
{
// more than 4x slower if you add R2()
R8(R256(fun(S,S,S,S);))
}
and compile with -g -O0 -fvar-tracking ? if ~6s, then I suppose we are down to
slow linear time; if ~50s, then we still have a quadratic behaviour.
[Bug tree-optimization/91514] optimization needs fictive memory allocation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91514 Eric Gallager changed: What|Removed |Added Resolution|--- |INVALID CC||egallager at gcc dot gnu.org Status|WAITING |RESOLVED --- Comment #2 from Eric Gallager --- (In reply to Richard Biener from comment #1) > So what's the variant w/o the fictive allocation? It would be nice to > see source with the variants controlled by a #define so one can compare > both compiling with -DFICTIVE or -UFICTIVE? no reply from the reporter; closing due to the rule about bugs being in WAITING for more than 3 months
[Bug tree-optimization/53947] [meta-bug] vectorizer missed-optimizations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53947 Bug 53947 depends on bug 91514, which changed state. Bug 91514 Summary: optimization needs fictive memory allocation https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91514 What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |INVALID
[Bug target/70676] suboptimal code generation on AVR
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70676 Eric Gallager changed: What|Removed |Added Resolution|--- |INVALID Status|WAITING |RESOLVED CC||egallager at gcc dot gnu.org --- Comment #11 from Eric Gallager --- (In reply to Georg-Johann Lay from comment #10) > (In reply to night_ghost from comment #9) > > Really this is a best way to fix bugs! Just ignore them - like an ostrich, > > hiding head in the sand. > > I just requested some information as outlines in the bug reporting > instructions. > > That you have the information available does not mean I can guess it by > magic, and guessing has turned out to be extremely ineffective, time > consuming and often enough it comes up with guesses that completely diverge > from a bug reportes intention. > > At some point I just stopped digging into your stuff and requested some more > information. > > Yust the fact that you are not able or not willing to provide that > information does not mean it's nor required. So, closing again, since the requested information still hasn't been supplied yet.
[Bug debug/104468] with -O -g, quadratic compile time of function with __attribute__(("00")) that passes large structs by value
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104468 --- Comment #7 from Andrew Pinski --- https://gcc.gnu.org/bugzilla/buglist.cgi?bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=SUSPENDED&bug_status=WAITING&bug_status=REOPENED&cf_known_to_fail_type=allwords&cf_known_to_work_type=allwords&keywords=compile-time-hog%2C%20&keywords_type=allwords&list_id=340184&longdesc=var-tracking&longdesc_type=allwordssubstr&query_format=advanced
[Bug libstdc++/58628] Incorrect std::isalpha results with UTF-8 locale on illumos
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58628 Eric Gallager changed: What|Removed |Added Last reconfirmed||2022-02-24 Status|UNCONFIRMED |WAITING CC||egallager at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #2 from Eric Gallager --- 3.4, 4.4, and 4.7 are pretty old at this point; does this still happen with newer versions of GCC?
[Bug libstdc++/56482] missing -lpthread in configure when checking for pthreads_num_processors_np
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56482 Eric Gallager changed: What|Removed |Added Status|NEW |WAITING CC||egallager at gcc dot gnu.org --- Comment #6 from Eric Gallager --- (In reply to Jonathan Wakely from comment #5) > Created attachment 32993 [details] > change GCC_TRY_COMPILE_OR_LINK test to AC_TRY_COMPILE > > Does this patch (against trunk) solve the problem? marking this as WAITING on a reply from the reporter
[Bug fortran/84519] [F2018] STOP and ERROR STOP statements with QUIET specifier
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84519 --- Comment #6 from CVS Commits --- The master branch has been updated by Harald Anlauf : https://gcc.gnu.org/g:916b809fbfdd2740006270baf549bf22fe9ec3c4 commit r12-7377-g916b809fbfdd2740006270baf549bf22fe9ec3c4 Author: Harald Anlauf Date: Wed Feb 23 23:08:29 2022 +0100 Fortran: frontend code for F2018 QUIET specifier to STOP and ERROR STOP Fortran 2018 allows for a QUIET specifier to the STOP and ERROR STOP statements. Whilst the gfortran library code provides support for this specifier for quite some time, the frontend implementation was missing. gcc/fortran/ChangeLog: PR fortran/84519 * dump-parse-tree.cc (show_code_node): Dump QUIET specifier when present. * match.cc (gfc_match_stopcode): Implement parsing of F2018 QUIET specifier. F2018 stopcodes may have non-default integer kind. * resolve.cc (gfc_resolve_code): Add checks for QUIET argument. * trans-stmt.cc (gfc_trans_stop): Pass QUIET specifier to call of library function. gcc/testsuite/ChangeLog: PR fortran/84519 * gfortran.dg/stop_1.f90: New test. * gfortran.dg/stop_2.f: New test. * gfortran.dg/stop_3.f90: New test. * gfortran.dg/stop_4.f90: New test.
