[Bug tree-optimization/93946] Bogus redundant store removal

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93946 --- Comment #14 from Richard Biener --- (In reply to sandra from comment #13) > Well, no. The problem is that the scheduler is moving > > ldw r2, 0(r4) > > ahead of > > stw zero, 0(r5) > > which is incorrect because

[Bug gcov-profile/94394] [GCOV]It will cause random kernel panic during collecting kernel code coverage

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94394 --- Comment #2 from Martin Liška --- If I remember correctly kernel implements its own "runtime library" libgcov, so I would expect a crash somewhere in it. Anyway, a reasonable reproducer would be needed.

[Bug c++/93597] [9 Regression] ICE in get_fns since r10-6219

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93597 Richard Biener changed: What|Removed |Added Resolution|FIXED |--- Status|RESOLVED

[Bug target/94373] 548.exchange2_r run time is 7-12% worse than GCC 9 at -O2 and generic march/mtune

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94373 --- Comment #3 from Hongtao.liu --- (In reply to Hongtao.liu from comment #2) > I think > Change lea_cost from 2 --> 1 in skylake can fix this regressions. > > Since it's stage4 now, i hold my patch. Classify: it's for -O2 -mtune=skylake-avx512

[Bug gcov-profile/94394] [GCOV]It will cause random kernel panic during collecting kernel code coverage

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94394 Andrew Pinski changed: What|Removed |Added Ever confirmed|0 |1 Last reconfirmed|

[Bug middle-end/94387] Excess read instructions are generated in case of writing to fields of volatile + packed type (structure)

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94387 --- Comment #4 from Petro Karashchenko --- Andrew Pinski could you please share with me requirements needed for strict alignment? Actually I do not understand why read-write cycle is needed if no "read" or "modify" operation is requested (I mean

[Bug target/94395] New: Powerpc suboptimal 64-bit constant generation near large values with few bits set

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94395 Bug ID: 94395 Summary: Powerpc suboptimal 64-bit constant generation near large values with few bits set Product: gcc Version: 9.2.1 Status: UNCONFIRMED Severit

[Bug tree-optimization/94375] 548.exchange2_r run time is 8-18% worse than GCC 9 at -Ofast -march=native

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94375 --- Comment #1 from Hongtao.liu --- Try -mprefer-vector-width=128,256-bit vectorization is not helpful for 548 according to our experience.

[Bug target/94373] 548.exchange2_r run time is 7-12% worse than GCC 9 at -O2 and generic march/mtune

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94373 --- Comment #2 from Hongtao.liu --- I think Change lea_cost from 2 --> 1 in skylake can fix this regressions. Since it's stage4 now, i hold my patch.

[Bug target/94391] gcc refers to absolute symbols with R_X86_64_PC32 relocation

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94391 --- Comment #10 from Fangrui Song --- > extern unsigned long _binary_a_c_size; > unsigned long foo() { return _binary_a_c_size; } This is incorrect. The code will treat the value of _binary_a_c_size as an address (load base + size) and dereferen

[Bug gcov-profile/94394] New: [GCOV]It will cause random kernel panic during collecting kernel code coverage

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94394 Bug ID: 94394 Summary: [GCOV]It will cause random kernel panic during collecting kernel code coverage Product: gcc Version: 9.3.1 Status: UNCONFIRMED Severity:

[Bug target/94391] gcc refers to absolute symbols with R_X86_64_PC32 relocation

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94391 --- Comment #9 from H.J. Lu --- (In reply to Fangrui Song from comment #5) > This bug exposes several problems: > > * GNU ld does not reject a PC-relative relocation referencing a SHN_ABS > symbol > * GCC should not produce R_X86_64_PC32 referen

[Bug target/94391] gcc refers to absolute symbols with R_X86_64_PC32 relocation

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94391 --- Comment #8 from Andrew Pinski --- Also it is wrong for a person to assume a normal C variable could be SHN_ABS; that is the bug here. It is a bug in the user code. I showed up to fix it by using an top level inline-asm.

[Bug target/94391] gcc refers to absolute symbols with R_X86_64_PC32 relocation

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94391 --- Comment #7 from Andrew Pinski --- (In reply to Fangrui Song from comment #5) > This bug exposes several problems: > > * GNU ld does not reject a PC-relative relocation referencing a SHN_ABS > symbol > * GCC should not produce R_X86_64_PC32 r

[Bug target/94391] gcc refers to absolute symbols with R_X86_64_PC32 relocation

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94391 --- Comment #6 from Fangrui Song --- > It is incorrect to reference a non-preemptible symbol with a PC relative > relocation in a -pie link. GNU ld allows it but the code can be incorrect at > runtime. Correction: It is incorrect to reference

[Bug target/94391] gcc refers to absolute symbols with R_X86_64_PC32 relocation

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94391 Fangrui Song changed: What|Removed |Added CC||i at maskray dot me --- Comment #5 from F

[Bug target/94391] gcc refers to absolute symbols with R_X86_64_PC32 relocation

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94391 H.J. Lu changed: What|Removed |Added Resolution|WONTFIX |WORKSFORME --- Comment #4 from H.J. Lu --- (I

[Bug target/94391] gcc refers to absolute symbols with R_X86_64_PC32 relocation

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94391 Andrew Pinski changed: What|Removed |Added Resolution|--- |WONTFIX Status|UNCONFIRMED

[Bug target/94391] gcc refers to absolute symbols with R_X86_64_PC32 relocation

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94391 Yuxuan Shui changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|INVALID

[Bug target/94393] New: Powerpc suboptimal 64-bit constant comparison

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94393 Bug ID: 94393 Summary: Powerpc suboptimal 64-bit constant comparison Product: gcc Version: 9.2.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tar

[Bug driver/94381] -falign-function/-falign-labels/-falign-loops documentation is inaccurate

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94381 H.J. Lu changed: What|Removed |Added Status|NEW |RESOLVED Resolution|---

[Bug driver/94381] -falign-function/-falign-labels/-falign-loops documentation is inaccurate

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94381 --- Comment #3 from CVS Commits --- The master branch has been updated by H.J. Lu : https://gcc.gnu.org/g:dacc7effeead9ad3e63673f6957661c55e351eb9 commit r10-7454-gdacc7effeead9ad3e63673f6957661c55e351eb9 Author: H.J. Lu Date: Sun Mar 29 15:

[Bug middle-end/94387] Excess read instructions are generated in case of writing to fields of volatile + packed type (structure)

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94387 --- Comment #3 from Andrew Pinski --- so I think this is fine as it is doing a read-write cycle as needed for strict alignment requirements

[Bug middle-end/94387] Excess read instructions are generated in case of writing to fields of volatile + packed type (structure)

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94387 --- Comment #2 from Andrew Pinski --- volatile and packed on strict alignment targets are interesting to say the least. packed makes the alignment to 1 too.

[Bug fortran/92775] [8 Regression] Incorrect expression in DW_AT_byte_stride on an array

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92775 Jakub Jelinek changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED

[Bug fortran/92775] [8 Regression] Incorrect expression in DW_AT_byte_stride on an array

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92775 --- Comment #11 from CVS Commits --- The releases/gcc-8 branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:2e50319ad2437e7b3a7691aa1351d522437d5b95 commit r8-10150-g2e50319ad2437e7b3a7691aa1351d522437d5b95 Author: Jakub Jelinek D

[Bug c/94392] Infinite loops are optimized away for C99

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94392 --- Comment #1 from Andrew Pinski --- I was looking at the patch email thread and the issue of finiteness not being discussed.

[Bug target/94391] gcc refers to absolute symbols with R_X86_64_PC32 relocation

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94391 Andrew Pinski changed: What|Removed |Added Resolution|--- |INVALID Status|UNCONFIRMED

[Bug c/94392] New: Infinite loops are optimized away for C99

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94392 Bug ID: 94392 Summary: Infinite loops are optimized away for C99 Product: gcc Version: 10.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c

[Bug other/94391] New: gcc refers to absolute symbols with R_X86_64_PC32 relocation

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94391 Bug ID: 94391 Summary: gcc refers to absolute symbols with R_X86_64_PC32 relocation Product: gcc Version: 9.3.0 Status: UNCONFIRMED Severity: normal P

[Bug rtl-optimization/94368] [9/10 Regression] ICE in final_scan_insn_1, at final.c:3074(error: could not split insn) on aarch64-linux-gnu since r9-3744

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94368 Jakub Jelinek changed: What|Removed |Added Status|WAITING |NEW Summary|[9/10 Regression]

[Bug target/87163] ICE in extract_insn, at recog.c:2305

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87163 --- Comment #13 from Segher Boessenkool --- If both compilers default to ibmlongdouble, both should use TFmode, no?

[Bug libstdc++/51965] Redundant move constructions in heap algorithms

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51965 --- Comment #19 from Marc Glisse --- (In reply to Jonathan Wakely from comment #16) > (In reply to Marc Glisse from comment #5) > > (The split into push_heap and __push_heap is just so the first part can be > > inlined without the second, right?)

[Bug fortran/94386] [10 Regression] FAIL: gfortran.dg/pr93365.f90

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94386 --- Comment #4 from Bill Seurer --- The problem is definitely caused by g:7d57570b0658b8c1b8a97dafa53dfd4ab4bd3f65, r10-7444 I built it before and no problems, errors after.

[Bug libstdc++/63706] stl_heap.h:make_heap()'s worst time complexity doesn't conform with C++ standard

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63706 Marc Glisse changed: What|Removed |Added Last reconfirmed||2020-03-29 Status|UNCONFIRMED

[Bug fortran/94386] [10 Regression] FAIL: gfortran.dg/pr93365.f90

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94386 --- Comment #3 from Paul Thomas --- (In reply to H.J. Lu from comment #0) > commit 7d57570b0658b8c1b8a97dafa53dfd4ab4bd3f65 > Author: Paul Thomas > Date: Sat Mar 28 19:11:35 2020 + > > Patch for PR94246 Since the ICE occurs in primar

[Bug c++/94126] [concepts] suboptimal diagnostic when type after substitution is ill-formed

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94126 Patrick Palka changed: What|Removed |Added Resolution|--- |FIXED Target Milestone|---

[Bug fortran/94386] [10 Regression] FAIL: gfortran.dg/pr93365.f90

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94386 Martin Liška changed: What|Removed |Added CC||seurer at linux dot vnet.ibm.com --- Com

[Bug fortran/94390] [10 regression] After r10-xxx ICEs in gfortran.dg/pr93600_1.f90 and gfortran.dg/gfortran.dg/pr93365.f90

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94390 Martin Liška changed: What|Removed |Added Resolution|--- |DUPLICATE CC|

[Bug fortran/94390] New: [10 regression] After r10-xxx ICEs in gfortran.dg/pr93600_1.f90 and gfortran.dg/gfortran.dg/pr93365.f90

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94390 Bug ID: 94390 Summary: [10 regression] After r10-xxx ICEs in gfortran.dg/pr93600_1.f90 and gfortran.dg/gfortran.dg/pr93365.f90 Product: gcc Version: 10.0

[Bug ipa/94363] possible typo: attribute attribute

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94363 --- Comment #2 from CVS Commits --- The master branch has been updated by Martin Liska : https://gcc.gnu.org/g:85f6f317ec8c02beea0a8dcb9c9274ebcffc1da7 commit r10-7451-g85f6f317ec8c02beea0a8dcb9c9274ebcffc1da7 Author: Martin Liska Date: Sun

[Bug ipa/94363] possible typo: attribute attribute

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94363 Martin Liška changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|---

[Bug gcov-profile/91601] gcov: ICE in handle_cycle, at gcov.c:699 happen which get code coverage with lcov.

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91601 Martin Liška changed: What|Removed |Added Resolution|--- |FIXED Status|NEW

[Bug gcov-profile/91601] gcov: ICE in handle_cycle, at gcov.c:699 happen which get code coverage with lcov.

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91601 --- Comment #15 from CVS Commits --- The releases/gcc-8 branch has been updated by Martin Liska : https://gcc.gnu.org/g:40aa944391dfec4529fb6970b9e78d5805f88fc5 commit r8-10149-g40aa944391dfec4529fb6970b9e78d5805f88fc5 Author: Martin Liska Dat

[Bug target/87163] ICE in extract_insn, at recog.c:2305

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87163 --- Comment #12 from Bill Seurer --- confgures are identical. Default compiler options are also identical, from -Q --help=target: The following options are target specific: -G0 -m32

[Bug c/94389] New: __attribute__((warn_unused_result)) will warn if the result is discarded as an optimisation

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94389 Bug ID: 94389 Summary: __attribute__((warn_unused_result)) will warn if the result is discarded as an optimisation Product: gcc Version: 9.3.1 Status: UNCONFIRMED

[Bug rtl-optimization/94368] [9/10 Regression] ICE in final_scan_insn_1, at final.c:3074(error: could not split insn) on aarch64-linux-gnu

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94368 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #2

[Bug rtl-optimization/94368] [9/10 Regression] ICE in final_scan_insn_1, at final.c:3074(error: could not split insn) on aarch64-linux-gnu

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94368 Martin Liška changed: What|Removed |Added Last reconfirmed||2020-03-29 Status|UNCONFIRMED

[Bug analyzer/94378] -Wanalyzer-malloc-leak false positive when returning a struct by value holding a heap-allocated pointer

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94378 Martin Liška changed: What|Removed |Added Last reconfirmed||2020-03-29 Ever confirmed|0

[Bug c/94370] double negation in diagnostic

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94370 Martin Liška changed: What|Removed |Added Ever confirmed|0 |1 Known to work|

[Bug fortran/94380] Nested associate+select type blocks cause compiler segfault

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94380 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever confirmed|0

[Bug fortran/94388] New: FAIL: gfortran.dg/unlimited_polymorphic_30.f03 execution test

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94388 Bug ID: 94388 Summary: FAIL: gfortran.dg/unlimited_polymorphic_30.f03 execution test Product: gcc Version: 10.0 Status: UNCONFIRMED Severity: normal P

[Bug fortran/94386] [10 Regression] FAIL: gfortran.dg/pr93365.f90

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94386 Thomas Koenig changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever confirmed|0

[Bug middle-end/94387] Excess read instructions are generated in case of writing to fields of volatile + packed type (structure)

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94387 --- Comment #1 from Petro Karashchenko --- Also the ambiguity of the issue is that excess read instructions generation depends on type of the field. Excess reads are not generated when 8 bit types are accessed and generated when data types greate

[Bug middle-end/94387] New: Excess read instructions are generated in case of writing to fields of volatile + packed type (structure)

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94387 Bug ID: 94387 Summary: Excess read instructions are generated in case of writing to fields of volatile + packed type (structure) Product: gcc Version: 9.3.1

[Bug gcov-profile/94369] 505.mcf_r is 6-7% slower at -Ofast -march=native with PGO+LTO than with just LTO

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94369 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever confirmed|0

[Bug gcov-profile/91601] gcov: ICE in handle_cycle, at gcov.c:699 happen which get code coverage with lcov.

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91601 Martin Liška changed: What|Removed |Added Resolution|FIXED |--- Status|RESOLVED

[Bug ipa/94363] possible typo: attribute attribute

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94363 Martin Liška changed: What|Removed |Added Ever confirmed|0 |1 Known to fail|

[Bug c++/94385] [10 Regression] Internal compiler error for __builtin_convertvector + statement expr

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94385 Jakub Jelinek changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned a

[Bug fortran/94386] New: [10 Regression] FAIL: gfortran.dg/pr93365.f90

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94386 Bug ID: 94386 Summary: [10 Regression] FAIL: gfortran.dg/pr93365.f90 Product: gcc Version: 10.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fort

[Bug target/94359] new test case g++.dg/coroutines/torture/symmetric-transfer-00-basic.C fails

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94359 --- Comment #6 from Iain Sandoe --- (In reply to Iain Sandoe from comment #5) > (In reply to Iain Sandoe from comment #4) > I'm going to discuss this with the coroutines paper authors - as to whether > any constraints had been considered. Note,

[Bug fortran/83705] [8/9/10 Regression] ICE/wrong code with large values of REPEAT after revision r256284

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83705 Martin Diehl changed: What|Removed |Added CC||m.diehl at mpie dot de --- Comment #15 fr