[Bug ipa/96734] gcc 10.2.0 fails to compile on mips64 due to crash in IPA SRA pass
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96734 Martin Liška changed: What|Removed |Added Ever confirmed|0 |1 Last reconfirmed||2020-08-24 Status|UNCONFIRMED |WAITING --- Comment #2 from Martin Liška --- (In reply to Ariadne Conill from comment #1) > Manually compiling cp/method.o using: > > g++ -c -o cp/method.o -O2 method.ii Can you please try it will all the original arguments: -march=mips3 -mtune=mips64 -mabi=64 -msoft-float -mllsc -mips3 -mno-shared -auxbase-strip cp/method.o -Os -Wextra -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wno-error=format-diag -Wsuggest-attribute=format -Woverloaded-virtual -Wpedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -version -fno-PIE -fno-exceptions -fno-rtti -fasynchronous-unwind-tables -fomit-frame-pointer > > works fine. > > I wonder if this is somehow related to pre-compiled headers, actually. If I see correctly, pre-compiled headers are not used in your case.
[Bug lto/96752] -fwhopr feature - is it available in gcc 9.2.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96752 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |WAITING Ever confirmed|0 |1 Last reconfirmed||2020-08-24 --- Comment #3 from Martin Liška --- > I was very curious to explore Link-Time-Optimization in a GCC and I though > it can improve my project. I found that during linking I also need to > provide the same option which I have used during compiling. That's not needed. LTO streams options per-function basis and similarly for GCC's --param options. It's commonly used technique to mix various options during build of a project (like Firefox).
[Bug tree-optimization/96597] valgrind error in do_hoist_insertion during O3 build
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96597 --- Comment #9 from CVS Commits --- The master branch has been updated by Martin Liska : https://gcc.gnu.org/g:adc646b10c7168c3c95373ee9321e3760fc4c5f1 commit r11-2816-gadc646b10c7168c3c95373ee9321e3760fc4c5f1 Author: Martin Liska Date: Thu Aug 13 13:05:12 2020 +0200 Add missing vn_reference_t::punned initialization gcc/ChangeLog: PR tree-optimization/96597 * tree-ssa-sccvn.c (vn_reference_lookup_call): Add missing initialization of ::punned. (vn_reference_insert): Use consistently false instead of 0. (vn_reference_insert_pieces): Likewise.
[Bug tree-optimization/96597] valgrind error in do_hoist_insertion during O3 build
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96597 Martin Liška changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #10 from Martin Liška --- Fixed.
[Bug target/96759] New: ICE in extract_insn, at recog.c:2294
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96759
Bug ID: 96759
Summary: ICE in extract_insn, at recog.c:2294
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: marxin at gcc dot gnu.org
CC: kito at gcc dot gnu.org, wilson at gcc dot gnu.org
Target Milestone: ---
Host: x86_64-linux-gnu
Target: riscv64-linux-gnu
The following fails:
$ cat live.cpp
struct S {
int a;
double b;
};
S GetNumbers();
auto [globalC, globalD] = GetNumbers();
$ riscv64-linux-gnu-gcc live.cpp -mno-strict-align
live.cpp: In function ‘void __static_initialization_and_destruction_0(int,
int)’:
live.cpp:6:39: error: unrecognizable insn:
6 | auto [globalC, globalD] = GetNumbers();
| ^
(insn 27 29 28 5 (set (subreg:DI (reg:TI 87) 0)
(subreg:DI (parallel:TI [
(expr_list:REG_DEP_TRUE (reg:SI 83)
(const_int 0 [0]))
(expr_list:REG_DEP_TRUE (reg:DF 84)
(const_int 8 [0x8]))
]) 0)) "live.cpp":6:38 -1
(nil))
during RTL pass: vregs
live.cpp:6:39: internal compiler error: in extract_insn, at recog.c:2294
0x5e1f55 _fatal_insn(char const*, rtx_def const*, char const*, int, char
const*)
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-trunk-riscv64/build/gcc/rtl-error.c:108
0x5e1f71 _fatal_insn_not_found(rtx_def const*, char const*, int, char const*)
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-trunk-riscv64/build/gcc/rtl-error.c:116
0x5e143a extract_insn(rtx_insn*)
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-trunk-riscv64/build/gcc/recog.c:2294
0x970a6f instantiate_virtual_regs_in_insn
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-trunk-riscv64/build/gcc/function.c:1607
0x970a6f instantiate_virtual_regs
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-trunk-riscv64/build/gcc/function.c:1977
0x970a6f execute
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-trunk-riscv64/build/gcc/function.c:2026
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See
[Bug target/96744] [11 Regression] FAIL: gcc.target/i386/avx512bitalgvl-vpopcntb-1.c execution test
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96744
--- Comment #2 from Hongtao.liu ---
Created attachment 49107
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49107&action=edit
Enable spill to mask only under m_core_AVX512
this patch will fail
cat test.c
#include
void
_mm512_2intersect_epi32_cut (__m512i __A, __m512i __B, __mmask16 *__U,
__mmask16 *__M)
{
__builtin_ia32_2intersectd512 (__U, __M, (__v16si) __A, (__v16si) __B);
}
void
_mm512_2intersect_epi64_cut (__m512i __A, __m512i __B, __mmask8 *__U,
__mmask8 *__M)
{
__builtin_ia32_2intersectq512 (__U, __M, (__v8di) __A, (__v8di) __B);
}
---
with gcc -O2 -mavx512vp2intersect -mavx512bw -mavx512dq
during RTL pass: reload
dump file: avx-1_cut.c.287r.reload
avx-1_cut.c: In function ‘_mm512_2intersect_epi32_cut’:
avx-1_cut.c:7:1: internal compiler error: in emit_move_multi_word, at
expr.c:3680
7 | }
| ^
0xd59c56 emit_move_multi_word
/export/users2/liuhongt/gcc/gnu-toolchain/tune_spill_to_mask/gcc/expr.c:3680
0xd5a2e3 emit_move_insn_1(rtx_def*, rtx_def*)
/export/users2/liuhongt/gcc/gnu-toolchain/tune_spill_to_mask/gcc/expr.c:3802
0xd5ab32 emit_move_insn(rtx_def*, rtx_def*)
/export/users2/liuhongt/gcc/gnu-toolchain/tune_spill_to_mask/gcc/expr.c:3935
0x1024e79 lra_emit_move(rtx_def*, rtx_def*)
/export/users2/liuhongt/gcc/gnu-toolchain/tune_spill_to_mask/gcc/lra.c:502
0x1043bb3 curr_insn_transform
/export/users2/liuhongt/gcc/gnu-toolchain/tune_spill_to_mask/gcc/lra-constraints.c:4440
0x10459d4 lra_constraints(bool)
/export/users2/liuhongt/gcc/gnu-toolchain/tune_spill_to_mask/gcc/lra-constraints.c:5031
0x1029896 lra(_IO_FILE*)
/export/users2/liuhongt/gcc/gnu-toolchain/tune_spill_to_mask/gcc/lra.c:2415
0xfba828 do_reload
/export/users2/liuhongt/gcc/gnu-toolchain/tune_spill_to_mask/gcc/ira.c:5525
0xfbad1e execute
/export/users2/liuhongt/gcc/gnu-toolchain/tune_spill_to_mask/gcc/ira.c:5711
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
Need to add define_insn for movp2qi/movp2hi?
with -mavx512vp2intersect -mavx512bw -mavx512dq -m32 got different failure
message.
avx-1_cut.c: In function ‘_mm512_2intersect_epi32_cut’:
avx-1_cut.c:7:1: internal compiler error: maximum number of generated reload
insns per insn achieved (90)
7 | }
| ^
0x1045568 lra_constraints(bool)
/export/users2/liuhongt/gcc/gnu-toolchain/tune_spill_to_mask/gcc/lra-constraints.c:4954
0x1029896 lra(_IO_FILE*)
/export/users2/liuhongt/gcc/gnu-toolchain/tune_spill_to_mask/gcc/lra.c:2415
0xfba828 do_reload
/export/users2/liuhongt/gcc/gnu-toolchain/tune_spill_to_mask/gcc/ira.c:5525
0xfbad1e execute
/export/users2/liuhongt/gcc/gnu-toolchain/tune_spill_to_mask/gcc/ira.c:5711
Please submit a full bug report,
Not sure about this one.
[Bug tree-optimization/96729] [11 Regression] hang on x86_64-linux-gnu with `-g -O3` since r11-39-gf9e1ea10e657af9f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96729 Martin Liška changed: What|Removed |Added Summary|hang on x86_64-linux-gnu|[11 Regression] hang on |with `-g -O3` |x86_64-linux-gnu with `-g ||-O3` since ||r11-39-gf9e1ea10e657af9f CC||marxin at gcc dot gnu.org, ||rguenth at gcc dot gnu.org Known to fail||11.0 Status|UNCONFIRMED |NEW Priority|P3 |P1 Ever confirmed|0 |1 Known to work||10.2.0 Last reconfirmed||2020-08-24 --- Comment #1 from Martin Liška --- Confirmed, started with Richi's r11-39-gf9e1ea10e657af9f.
[Bug tree-optimization/96730] [10/11 Regression] ICE on x86_64-linux-gnu with `-O1` to `-O3` (in verify_sra_access_forest, at tree-sra.c:2352) since r10-6320-g5b9e89c922dc2e7e
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96730 Martin Liška changed: What|Removed |Added Ever confirmed|0 |1 Last reconfirmed||2020-08-24 Summary|ICE on x86_64-linux-gnu |[10/11 Regression] ICE on |with `-O1` to `-O3` (in |x86_64-linux-gnu with `-O1` |verify_sra_access_forest, |to `-O3` (in |at tree-sra.c:2352) |verify_sra_access_forest, ||at tree-sra.c:2352) since ||r10-6320-g5b9e89c922dc2e7e CC||jamborm at gcc dot gnu.org, ||marxin at gcc dot gnu.org Known to work||9.3.0 Status|UNCONFIRMED |NEW Known to fail||10.2.0, 11.0 --- Comment #1 from Martin Liška --- Thanks for report. Started with Martin's r10-6320-g5b9e89c922dc2e7e.
[Bug c++/96732] [11 Regression] ice in pop_nested_class
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96732 --- Comment #2 from Martin Liška --- (In reply to Marek Polacek from comment #1) > Started with r11-2748 Can you please CC author of the revision that caused that? Thanks.
[Bug target/96755] [11 Regression] ICE in final_scan_insn_1, at final.c:3073 with -O3 -march=skylake-avx512
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96755 --- Comment #2 from Hongtao.liu --- Sorry for TYPO --- (define_split [(set (match_operand:DI 0 "mask_reg_operand") (zero_extend:DI - (not:DI (match_operand:SI 1 "mask_reg_operand"] + (not:SI (match_operand:SI 1 "mask_reg_operand"] "TARGET_AVX512BW && reload_completed" ---
[Bug c++/94938] [10 Regression] internal compiler error: in value_dependent_expression_p, at cp/pt.c:26522
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94938 Martin Liška changed: What|Removed |Added CC||andysem at mail dot ru --- Comment #9 from Martin Liška --- *** Bug 96741 has been marked as a duplicate of this bug. ***
[Bug c++/96741] ICE in value_dependent_expression_p when compiling Boost.Xpressive in C++03 mode
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96741 Martin Liška changed: What|Removed |Added Resolution|--- |DUPLICATE Status|UNCONFIRMED |RESOLVED CC||marxin at gcc dot gnu.org --- Comment #1 from Martin Liška --- Dup. *** This bug has been marked as a duplicate of bug 94938 ***
[Bug tree-optimization/96758] [10/11 Regression] strncmp miscompiles as memcmp since r10-3920-g27c14dbc6b01d5b7
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96758
Martin Liška changed:
What|Removed |Added
Last reconfirmed||2020-08-24
Known to work||9.3.0
CC||jakub at gcc dot gnu.org,
||marxin at gcc dot gnu.org,
||msebor at gcc dot gnu.org
Ever confirmed|0 |1
Keywords||wrong-code
Summary|strncmp miscompiles as |[10/11 Regression] strncmp
|memcmp |miscompiles as memcmp since
||r10-3920-g27c14dbc6b01d5b7
Known to fail||10.2.0, 11.0
Status|UNCONFIRMED |NEW
Priority|P3 |P1
--- Comment #1 from Martin Liška ---
Thank you for the report. It really started with r10-3920-g27c14dbc6b01d5b7.
Slightly modified test-case:
$ cat pr96758.c
int main(int argc, char *argv[]) {
const char *s = argc > 0 ? "a" : "b";
char x[5];
char y[5] = "a\0a";
__builtin_memcpy(x, y, sizeof(y));
if (__builtin_strncmp(x, s, 4) != 0)
__builtin_abort ();
return 0;
}
[Bug tree-optimization/96748] ICE in get_default_value, at tree-ssa-ccp.c:311
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96748 Martin Liška changed: What|Removed |Added CC||marxin at gcc dot gnu.org --- Comment #4 from Martin Liška --- I don't see the failure for any of recent GCC releases: Releases 8.1.0 (406c2abec3f998e9)(02 May 2018 10:13): [took: 4.858s] result: OK 8.2.0 (ddeb81e76461fc00)(26 Jul 2018 09:47): [took: 4.871s] result: OK 8.3.0 (4c44b708f11eec6f)(22 Feb 2019 14:20): [took: 4.913s] result: OK 8.4.0 (8cd3bffead2ed1d1)(04 Mar 2020 08:30): [took: 4.821s] result: OK 9.1.0 (c8913260b0756f97)(03 May 2019 07:59): [took: 4.729s] result: OK 9.2.0 (a0c06cc27d2146b7)(12 Aug 2019 09:38): [took: 4.731s] result: OK 9.3.0 (4212a6a3e44f8704)(12 Mar 2020 11:08): [took: 4.770s] result: OK 10.1.0 (6e6e3f144a33ae50)(07 May 2020 10:50): [took: 4.924s] result: OK 10.2.0 (ee5c3db6c5b2c333)(23 Jul 2020 06:35): [took: 4.919s] result: OK
[Bug middle-end/96750] 10-12% performance decrease in benchmark going from GCC8 to GCC9/GCC10
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96750 Martin Liška changed: What|Removed |Added Last reconfirmed||2020-08-24 CC||hubicka at gcc dot gnu.org, ||marxin at gcc dot gnu.org Ever confirmed|0 |1 Status|UNCONFIRMED |NEW --- Comment #1 from Martin Liška --- Confirmed, started with r9-5763-g61a8637c8893a252: after: 1794240.0 before: 1802710.0 Anyway, using PGO one can get to: 1488310.0
[Bug tree-optimization/96748] ICE in get_default_value, at tree-ssa-ccp.c:311
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96748 --- Comment #5 from Manuel Lauss --- (In reply to Martin Liška from comment #4) > I don't see the failure for any of recent GCC releases: > > Releases > 8.1.0 (406c2abec3f998e9)(02 May 2018 10:13): [took: 4.858s] result: OK > 8.2.0 (ddeb81e76461fc00)(26 Jul 2018 09:47): [took: 4.871s] result: OK > 8.3.0 (4c44b708f11eec6f)(22 Feb 2019 14:20): [took: 4.913s] result: OK > 8.4.0 (8cd3bffead2ed1d1)(04 Mar 2020 08:30): [took: 4.821s] result: OK > 9.1.0 (c8913260b0756f97)(03 May 2019 07:59): [took: 4.729s] result: OK > 9.2.0 (a0c06cc27d2146b7)(12 Aug 2019 09:38): [took: 4.731s] result: OK > 9.3.0 (4212a6a3e44f8704)(12 Mar 2020 11:08): [took: 4.770s] result: OK > 10.1.0 (6e6e3f144a33ae50)(07 May 2020 10:50): [took: 4.924s] result: OK > 10.2.0 (ee5c3db6c5b2c333)(23 Jul 2020 06:35): [took: 4.919s] result: OK As I wrote in comment 3, I can no longer reproduce it either. It appeared in a 10.2.0 branch build of ~13.08.2020, but has since been resolved.
[Bug target/96759] ICE in extract_insn, at recog.c:2294
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96759 Kito Cheng changed: What|Removed |Added Ever confirmed|0 |1 Status|UNCONFIRMED |NEW Last reconfirmed||2020-08-24 --- Comment #1 from Kito Cheng --- Confirmed
[Bug c/96760] New: Faulty optimization in nested loops with -O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96760
Bug ID: 96760
Summary: Faulty optimization in nested loops with -O2
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: zhige.yu18 at imperial dot ac.uk
Target Milestone: ---
The following code snippet:
#include
char a = 0, f = 0, c = 5;
unsigned long d = 0;
int g = 0;
int *e = &g;
int main() {
char b = 0;
for (;;) {
for (a = 20; a; a++) {
if (c) {
printf("%lu\n", d);
return 0;
}
}
f = (d++, *e);
}
}
> $ /usr/gcc-trunk/bin/gcc -O2 bug.c; ./a.out
> 140728921720328
> $ gcc-9 -O2 bug.c; ./a.out
> 0
When compiled with -O2, it prints out a random value instead of 0. This bug can
be found on GCC-11.0.0 20200823. GCC-10.2 and earlier GCCs do not have this
bug.
[Bug tree-optimization/96698] [10/11 Regression] ICE during GIMPLE pass:vect
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96698 Richard Biener changed: What|Removed |Added Keywords||ice-on-valid-code Target Milestone|--- |10.3 Priority|P3 |P2 Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org Summary|aarch64: ICE during GIMPLE |[10/11 Regression] ICE |pass:vect |during GIMPLE pass:vect --- Comment #1 from Richard Biener --- The case should be vectorizable - the issue is that the latch updating of the vectorized reduction PHI happens before this PHI is created. Confirmed on x86_64 as well. Also crashes on the GCC 10 branch.
[Bug target/94538] [9/10/11 Regression] ICE: in extract_constrain_insn_cached, at recog.c:2223 (insn does not satisfy its constraints) with -mcpu=cortex-m23 -mslow-flash-data
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94538 --- Comment #20 from CVS Commits --- The master branch has been updated by Christophe Lyon : https://gcc.gnu.org/g:259d072067997ab8f55afcf735c91b6740fd0425 commit r11-2818-g259d072067997ab8f55afcf735c91b6740fd0425 Author: Christophe Lyon Date: Wed Aug 19 09:02:21 2020 + arm: Fix -mpure-code support/-mslow-flash-data for armv8-m.base [PR94538] armv8-m.base (cortex-m23) has the movt instruction, so we need to disable the define_split to generate a constant in this case, otherwise we get incorrect insn constraints as described in PR94538. We also need to fix the pure-code alternative for thumb1_movsi_insn because the assembler complains with instructions like movs r0, #:upper8_15:1234 (Internal error in md_apply_fix) We now generate movs r0, 4 instead. 2020-08-24 Christophe Lyon PR target/94538 gcc/ * config/arm/thumb1.md: Disable set-constant splitter when TARGET_HAVE_MOVT. (thumb1_movsi_insn): Fix -mpure-code alternative. PR target/94538 gcc/testsuite/ * gcc.target/arm/pure-code/pr94538-1.c: New test. * gcc.target/arm/pure-code/pr94538-2.c: New test.
[Bug middle-end/96750] 10-12% performance decrease in benchmark going from GCC8 to GCC9/GCC10
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96750 --- Comment #2 from Marc Glisse --- (In reply to Martin Liška from comment #1) > after: > 1794240.0 > > before: > 1802710.0 That's less than 1% of difference (with "after" better than "before"), not the 10% regression claimed, maybe there is another relevant commit?
[Bug c++/96761] New: "error: call of overloaded ‘func(size_t)’ is ambiguous" when argument is size_t(0) and func(int) and func(const char *) are visible
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96761
Bug ID: 96761
Summary: "error: call of overloaded ‘func(size_t)’ is
ambiguous" when argument is size_t(0) and func(int)
and func(const char *) are visible
Product: gcc
Version: 9.3.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: darktemplar at basealt dot ru
Target Milestone: ---
Following example fails to compile with g++-9.3.1:
#include
#include
void func(int arg)
{
printf("Called func(int) with arg = %d\n", arg);
}
void func(const char *arg)
{
printf("Called func(const char*) with arg = \"%s\"\n", arg);
}
int main(int argc, char **argv)
{
func(size_t(0));
func(0);
func(size_t(1));
func(size_t(1) - size_t(1));
#define emptystring ""
#define nonemptystring "non empty string"
func(emptystring);
func(sizeof(emptystring) - 1);
func(nonemptystring);
func(sizeof(nonemptystring) - 1);
return 0;
}
It fails to compile on line "func(size_t(0));" but lines "func(0);",
"func(size_t(1));", "func(size_t(1) - size_t(1));" and
"func(sizeof(emptystring) - 1);" are compiled fine. This result looks
inconsistent.
Compilation result is:
$ g++ test.cpp -o test
test.cpp: In function ‘int main(int, char**)’:
test.cpp:16:16: error: call of overloaded ‘func(size_t)’ is ambiguous
16 | func(size_t(0));
|^
test.cpp:4:6: note: candidate: ‘void func(int)’
4 | void func(int arg)
| ^~~~
test.cpp:9:6: note: candidate: ‘void func(const char*)’
9 | void func(const char *arg)
| ^~~~
Expected result:
Successful compilation, with "func(int)" being chosen for "func(size_t(0))"
call.
g++ version:
$ LC_ALL=C g++ --version
x86_64-alt-linux-g++ (GCC) 9.3.1 20200518 (ALT Sisyphus 9.3.1-alt1)
Copyright (C) 2019 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
[Bug target/96762] New: ICE in extract_insn, at recog.c:2294 (error: unrecognizable insn)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96762
Bug ID: 96762
Summary: ICE in extract_insn, at recog.c:2294 (error:
unrecognizable insn)
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: asolokha at gmx dot com
Target Milestone: ---
Target: powerpc-*-linux-gnu
gcc-11.0.0-alpha20200823 snapshot (g:87c753ac241f25d222d46ba1ac66ceba89d6a200)
ICEs when compiling the following testcase w/ -mcpu=power10:
void
g4 (void)
{
char zj[] = "";
}
% powerpc-e300c3-linux-gnu-gcc-11.0.0 -mcpu=power10 -c gqga9ph8.c
gqga9ph8.c: In function 'g4':
gqga9ph8.c:5:1: error: unrecognizable insn:
5 | }
| ^
(insn 11 7 12 2 (set (reg:DI 123)
(ashift:DI (reg:DI 122)
(const_int 56 [0x38]))) "gqga9ph8.c":4:8 -1
(nil))
during RTL pass: vregs
gqga9ph8.c:5:1: internal compiler error: in extract_insn, at recog.c:2294
0x65b11b _fatal_insn(char const*, rtx_def const*, char const*, int, char
const*)
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-11.0.0_alpha20200823/work/gcc-11-20200823/gcc/rtl-error.c:108
0x65b13b _fatal_insn_not_found(rtx_def const*, char const*, int, char const*)
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-11.0.0_alpha20200823/work/gcc-11-20200823/gcc/rtl-error.c:116
0x6596e9 extract_insn(rtx_insn*)
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-11.0.0_alpha20200823/work/gcc-11-20200823/gcc/recog.c:2294
0xa87ee1 instantiate_virtual_regs_in_insn
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-11.0.0_alpha20200823/work/gcc-11-20200823/gcc/function.c:1607
0xa87ee1 instantiate_virtual_regs
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-11.0.0_alpha20200823/work/gcc-11-20200823/gcc/function.c:1977
0xa87ee1 execute
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-11.0.0_alpha20200823/work/gcc-11-20200823/gcc/function.c:2026
[Bug c/96739] attribute(constructor) vs format NULL check
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96739 --- Comment #2 from Dr. David Alan Gilbert --- Created attachment 49108 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49108&action=edit less boiled down test
[Bug tree-optimization/96758] [10/11 Regression] strncmp miscompiles as memcmp since r10-3920-g27c14dbc6b01d5b7
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96758 Jakub Jelinek changed: What|Removed |Added Target Milestone|--- |10.3 Priority|P1 |P2 Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org
[Bug middle-end/96750] 10-12% performance decrease in benchmark going from GCC8 to GCC9/GCC10
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96750 --- Comment #3 from Martin Liška --- (In reply to Marc Glisse from comment #2) > (In reply to Martin Liška from comment #1) > > after: > > 1794240.0 > > > > before: > > 1802710.0 > > That's less than 1% of difference (with "after" better than "before"), not > the 10% regression claimed, maybe there is another relevant commit? Sorry, I copied bad numbers: after: 1806140.0 before: 1705630.0 which is ~6% regression.
[Bug c/96739] attribute(constructor) vs format NULL check
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96739 --- Comment #3 from Dr. David Alan Gilbert --- Hi Martin, Thanks for the response. I've added a slightly less boiled down test that I think is still valid. I agree with that you say in the case of the call from help_all->help_oneline because cmd and ct are related; however int he original, and new attachment, there's another independent call to help_oneline via help_onecmd->help_oneline where the cmd is argv[1]. So while it's true, that as you say, in the help_all->help_oneline case, if the cmd is NULL then so is ct->name, this is only true for one caller of help_oneline.
[Bug analyzer/96763] New: [11 Regression] ICE in get_subregion_within_ctor, at analyzer/store.cc:379
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96763
Bug ID: 96763
Summary: [11 Regression] ICE in get_subregion_within_ctor, at
analyzer/store.cc:379
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: analyzer
Assignee: dmalcolm at gcc dot gnu.org
Reporter: asolokha at gmx dot com
Target Milestone: ---
Target: powerpc-*-linux-gnu
g++-11.0.0-alpha20200823 snapshot (g:87c753ac241f25d222d46ba1ac66ceba89d6a200)
ICEs when compiling the following testcase, reduced from
gcc/testsuite/g++.dg/cpp2a/nontype-class16.C, w/ -fanalyzer:
struct c0;
struct md {
int c0::*jj[2];
};
void
n0 ()
{
md{};
}
% powerpc-e300c3-linux-gnu-g++-11.0.0 -fanalyzer -c a3ufwiij.C
during IPA pass: analyzer
a3ufwiij.C: In function 'void n0()':
a3ufwiij.C:10:3: internal compiler error: in get_subregion_within_ctor, at
analyzer/store.cc:379
10 | md{};
| ^~~~
0x7db089 get_subregion_within_ctor
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-11.0.0_alpha20200823/work/gcc-11-20200823/gcc/analyzer/store.cc:379
0x7db089 ana::binding_map::apply_ctor_to_region(ana::region const*, tree_node*,
ana::region_model_manager*)
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-11.0.0_alpha20200823/work/gcc-11-20200823/gcc/analyzer/store.cc:423
0x13f7bb5 ana::binding_map::apply_ctor_to_region(ana::region const*,
tree_node*, ana::region_model_manager*)
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-11.0.0_alpha20200823/work/gcc-11-20200823/gcc/analyzer/store.cc:425
0x13c4f7a ana::decl_region::get_svalue_for_constructor(tree_node*,
ana::region_model_manager*) const
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-11.0.0_alpha20200823/work/gcc-11-20200823/gcc/analyzer/region.cc:907
0x13c9f54 ana::region_model::get_store_value(ana::region const*) const
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-11.0.0_alpha20200823/work/gcc-11-20200823/gcc/analyzer/region-model.cc:1284
0x13cbca3 ana::region_model::get_rvalue(ana::path_var,
ana::region_model_context*)
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-11.0.0_alpha20200823/work/gcc-11-20200823/gcc/analyzer/region-model.cc:1190
0x13cc0a7 ana::region_model::on_assignment(gassign const*,
ana::region_model_context*)
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-11.0.0_alpha20200823/work/gcc-11-20200823/gcc/analyzer/region-model.cc:562
0x13af66a ana::exploded_node::on_stmt(ana::exploded_graph&, ana::supernode
const*, gimple const*, ana::program_state*) const
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-11.0.0_alpha20200823/work/gcc-11-20200823/gcc/analyzer/engine.cc:1029
0x13b08a5 ana::exploded_graph::process_node(ana::exploded_node*)
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-11.0.0_alpha20200823/work/gcc-11-20200823/gcc/analyzer/engine.cc:2526
0x13b1102 ana::exploded_graph::process_worklist()
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-11.0.0_alpha20200823/work/gcc-11-20200823/gcc/analyzer/engine.cc:2341
0x13b31e4 ana::impl_run_checkers(ana::logger*)
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-11.0.0_alpha20200823/work/gcc-11-20200823/gcc/analyzer/engine.cc:4107
0x13b3e91 ana::run_checkers()
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-11.0.0_alpha20200823/work/gcc-11-20200823/gcc/analyzer/engine.cc:4175
0x13a8a68 execute
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-11.0.0_alpha20200823/work/gcc-11-20200823/gcc/analyzer/analyzer-pass.cc:84
[Bug c/96760] Faulty optimization in nested loops with -O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96760
Thomas Koenig changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
CC||tkoenig at gcc dot gnu.org
Resolution|--- |INVALID
--- Comment #1 from Thomas Koenig ---
The loop
for (a = 20; a; a++) {
increases a, which is a char, beyond its value range, and then tests
against zero.
This is undefined behavior.
N4659, Clause 8:
# If during the evaluation of an expression, the result is not mathematically
# defined or not in the range of representable values for its type, the
# behavior is undefined.
If you had made a an unsigned type (for example an unsigned char), then
the results would probably have been closer to what you expected.
[Bug tree-optimization/96730] [10/11 Regression] ICE on x86_64-linux-gnu with `-O1` to `-O3` (in verify_sra_access_forest, at tree-sra.c:2352) since r10-6320-g5b9e89c922dc2e7e
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96730 Martin Jambor changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |jamborm at gcc dot gnu.org --- Comment #2 from Martin Jambor --- Mine.
[Bug c/96760] Faulty optimization in nested loops with -O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96760 Andreas Schwab changed: What|Removed |Added Status|RESOLVED|REOPENED Last reconfirmed||2020-08-24 Ever confirmed|0 |1 Resolution|INVALID |--- --- Comment #2 from Andreas Schwab --- The inner loop never reaches the increment expression because c is nonzero, thus no undefined behaviour occurs.
[Bug ipa/96734] gcc 10.2.0 fails to compile on mips64 due to crash in IPA SRA pass
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96734 --- Comment #3 from Ariadne Conill --- When that method.ii is compiled against g++ 9.3.0 with the provided options, it compiles successfully. When built using a cross-compiled g++ 10.2.0, it crashes. So, the issue is specific to 10.2.0 it seems.
[Bug tree-optimization/96758] [10/11 Regression] strncmp miscompiles as memcmp since r10-3920-g27c14dbc6b01d5b7
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96758 --- Comment #2 from Jakub Jelinek --- Created attachment 49109 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49109&action=edit gcc11-pr96758.patch Untested fix. cmpsiz has been computed incorrectly and while the code had the intent to handle the case where both strings have known constant string length, that case actually wasn't handled. That part IMHO shouldn't be backported.
[Bug ipa/96734] gcc 10.2.0 fails to compile on mips64 due to crash in IPA SRA pass
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96734 --- Comment #4 from Martin Liška --- (In reply to Ariadne Conill from comment #3) > When that method.ii is compiled against g++ 9.3.0 with the provided options, > it compiles successfully. > > When built using a cross-compiled g++ 10.2.0, it crashes. So, the issue is > specific to 10.2.0 it seems. I've just tried building 10.2.0 cross compiler (x86_64-linux-gnu as host) and I can't reproduce it. Which options do you use?
[Bug fortran/96486] get_environment_variable crashes for environment variables that are empty strings
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96486 --- Comment #29 from CVS Commits --- The master branch has been updated by Mark Eggleston : https://gcc.gnu.org/g:de09e7ebc9d653745a103eef2b20c7f1dd76 commit r11-2819-gde09e7ebc9d653745a103eef2b20c7f1dd76 Author: Mark Eggleston Date: Mon Aug 10 08:07:39 2020 +0100 Fortran : get_environment_variable runtime error PR96486 Runtime error occurs when the type of the value argument is character(0): "Zero-length string passed as value...". The status argument, intent(out), will contain -1 if the value of the environment is too large to fit in the value argument, this is the case if the type is character(0) so there is no reason to produce a runtime error if the value argument is zero length. 2020-08-24 Mark Eggleston libgfortran/ PR fortran/96486 * intrinsics/env.c: If value_len is > 0 blank the string. Copy the result only if its length is > 0. 2020-08-24 Mark Eggleston gcc/testsuite/ PR fortran/96486 * gfortran.dg/pr96486.f90: New test.
[Bug c/201] Switch statement will not accept constant integer variable as case label
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=201 Stas Sergeev changed: What|Removed |Added CC||stsp at users dot sourceforge.net --- Comment #6 from Stas Sergeev --- Is there some switch to enable that as an extension?
[Bug ipa/96734] gcc 10.2.0 fails to compile on mips64 due to crash in IPA SRA pass
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96734 --- Comment #5 from Ariadne Conill --- I should clarify. I cross-compiled g++ 10.2.0 to run on mips64 *host*. That part worked fine. Afterwards, the *host* mips64 g++ cannot compile itself. The *host* mips64 g++ (which was cross-compiled from an aarch64 machine), is built with: Configured with: /home/buildozer/aports/main/gcc/src/gcc-10.2.0/configure --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --build=mips64-alpine-linux-musl --host=mips64-alpine-linux-musl --target=mips64-alpine-linux-musl --with-pkgversion='Alpine 10.2.0' --enable-checking=release --disable-fixed-point --disable-libstdcxx-pch --disable-multilib --disable-nls --disable-werror --disable-symvers --enable-__cxa_atexit --enable-default-pie --enable-default-ssp --enable-cloog-backend --enable-languages=c,c++,d,objc,fortran,ada --with-arch=mips3 --with-tune=mips64 --with-mips-plt --with-float=soft --with-abi=64 --disable-bootstrap --disable-libquadmath --disable-libssp --disable-libmpx --disable-libmudflap --disable-libsanitizer --enable-shared --enable-threads --enable-tls --disable-libitm --with-system-zlib --with-linker-hash-style=sysv So we have this crashing whenever we try to build gcc with 10.2.0 on a mips64 host, either rebuilding from gcc 9.3.0 or from cross-compiled 10.2.0.
[Bug ipa/96734] gcc 10.2.0 fails to compile on mips64 due to crash in IPA SRA pass
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96734 --- Comment #6 from Ariadne Conill --- (In reply to Ariadne Conill from comment #5) > I should clarify. > > I cross-compiled g++ 10.2.0 to run on mips64 *host*. That part worked fine. > > Afterwards, the *host* mips64 g++ cannot compile itself. > > The *host* mips64 g++ (which was cross-compiled from an aarch64 machine), is > built with: > > Configured with: /home/buildozer/aports/main/gcc/src/gcc-10.2.0/configure > --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info > --build=mips64-alpine-linux-musl --host=mips64-alpine-linux-musl > --target=mips64-alpine-linux-musl --with-pkgversion='Alpine 10.2.0' > --enable-checking=release --disable-fixed-point --disable-libstdcxx-pch > --disable-multilib --disable-nls --disable-werror --disable-symvers > --enable-__cxa_atexit --enable-default-pie --enable-default-ssp > --enable-cloog-backend --enable-languages=c,c++,d,objc,fortran,ada > --with-arch=mips3 --with-tune=mips64 --with-mips-plt --with-float=soft > --with-abi=64 --disable-bootstrap --disable-libquadmath --disable-libssp > --disable-libmpx --disable-libmudflap --disable-libsanitizer --enable-shared > --enable-threads --enable-tls --disable-libitm --with-system-zlib > --with-linker-hash-style=sysv > > So we have this crashing whenever we try to build gcc with 10.2.0 on a > mips64 host, either rebuilding from gcc 9.3.0 or from cross-compiled 10.2.0. An easy way to observe the behavior for yourself would be to use an Alpine chroot on a mips64 host (I think the GCC build farm has one, if not, I can facilitate access to a mips64 container).
[Bug c++/96721] [11 Regression] pseudo-destructor calls on pointers since r11-2238
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96721 --- Comment #3 from Jakub Jelinek --- Created attachment 49110 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49110&action=edit gcc11-pr96721.patch Untested fix.
[Bug tree-optimization/96722] [8/9/10/11 Regression] Clobbers on NULL since r8-1519
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96722
--- Comment #3 from Jakub Jelinek ---
Created attachment 49111
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49111&action=edit
gcc11-pr96722.patch
If *0 ={v} {CLOBBER}; is supposed to be a fancy nop, then we should ignore it
during path isolation (shouldn't infer UB from clobber stmts).
[Bug debug/96690] [10/11 Regression] ICE in write_type since r10-6087
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96690
Richard Biener changed:
What|Removed |Added
Component|c++ |debug
Keywords||ice-on-valid-code
--- Comment #4 from Richard Biener ---
Hmm, but we're pushing TYPE_MAIN_VARIANT (). The issue seems to be that
we're mangling 'foo' via rtl_for_decl_init () which is the init of
a template value, &foo, that is only required from debug and FLD does not
walk those template trees we eventually generate this debug from.
That said, we're expecting to have mangled everything we have to eventually
mangle at the time FLD runs but here we're mangling things after the fact.
IMHO the template paramter DIE should have a more symbolic representation
and not use relocations to say 'foo'. Trying to bypass rtl_for_decl_init
via
diff --git a/gcc/dwarf2out.c b/gcc/dwarf2out.c
index 9deca031fc2..4d652e594ad 100644
--- a/gcc/dwarf2out.c
+++ b/gcc/dwarf2out.c
@@ -19764,6 +19793,9 @@ reference_to_unused (tree * tp, int * walk_subtrees,
if (!node || !node->definition)
return *tp;
}
+ else if (TREE_CODE (*tp) == FUNCTION_DECL
+ && !DECL_ASSEMBLER_NAME_SET_P (*tp))
+return *tp;
else if (TREE_CODE (*tp) == FUNCTION_DECL
&& (!DECL_EXTERNAL (*tp) || DECL_DECLARED_INLINE_P (*tp)))
{
turns this into the very same issue via
0xfe0d36 cst_pool_loc_descr
../../src/gcc/gcc/dwarf2out.c:17485
0xfe21e9 loc_list_from_tree_1
../../src/gcc/gcc/dwarf2out.c:18305
0xfe4823 loc_list_from_tree
../../src/gcc/gcc/dwarf2out.c:19042
0xfe4881 loc_descriptor_from_tree
../../src/gcc/gcc/dwarf2out.c:19055
0xffb29d gen_remaining_tmpl_value_param_die_attribute
../../src/gcc/gcc/dwarf2out.c:27168
where loc_list_from_tree_1 doesn't seem to have the same "protection"
against referencing unused symbols as rtl_for_decl_init has.
Note without -flto we do not appear to output a DIE refering to 'foo'.
[Bug fortran/96486] get_environment_variable crashes for environment variables that are empty strings
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96486 --- Comment #30 from CVS Commits --- The releases/gcc-10 branch has been updated by Mark Eggleston : https://gcc.gnu.org/g:5effbd0733f9a4d42ddae965e4c28701be7811ac commit r10-8658-g5effbd0733f9a4d42ddae965e4c28701be7811ac Author: Mark Eggleston Date: Mon Aug 10 08:07:39 2020 +0100 Fortran : get_environment_variable runtime error PR96486 Runtime error occurs when the type of the value argument is character(0): "Zero-length string passed as value...". The status argument, intent(out), will contain -1 if the value of the environment is too large to fit in the value argument, this is the case if the type is character(0) so there is no reason to produce a runtime error if the value argument is zero length. 2020-08-24 Mark Eggleston libgfortran/ PR fortran/96486 * intrinsics/env.c: If value_len is > 0 blank the string. Copy the result only if its length is > 0. 2020-08-24 Mark Eggleston gcc/testsuite/ PR fortran/96486 * gfortran.dg/pr96486.f90: New test. (cherry picked from commit de09e7ebc9d653745a103eef2b20c7f1dd76)
[Bug analyzer/96764] New: [11 Regression] ICE in fold_convert_const_int_from_real, at fold-const.c:2038
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96764
Bug ID: 96764
Summary: [11 Regression] ICE in
fold_convert_const_int_from_real, at fold-const.c:2038
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: analyzer
Assignee: dmalcolm at gcc dot gnu.org
Reporter: asolokha at gmx dot com
Target Milestone: ---
gcc-11.0.0-alpha20200823 snapshot (g:87c753ac241f25d222d46ba1ac66ceba89d6a200)
ICEs when compiling the following testcase, reduced from
gcc/testsuite/gcc.c-torture/execute/pr36343.c, w/ -fanalyzer:
void
ar (int *hd)
{
int **zv = &hd;
*(double *) zv = 0.0;
}
% gcc-11.0.0 -fanalyzer -c akrcmvle.c
during IPA pass: analyzer
akrcmvle.c: In function 'ar':
akrcmvle.c:5:18: internal compiler error: in fold_convert_const_int_from_real,
at fold-const.c:2038
5 | *(double *) zv = 0.0;
| ~~~^
0x62f411 fold_convert_const_int_from_real
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20200823/work/gcc-11-20200823/gcc/fold-const.c:2038
0x62f411 fold_convert_const
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20200823/work/gcc-11-20200823/gcc/fold-const.c:2284
0xa711ad fold_unary_loc(unsigned int, tree_code, tree_node*, tree_node*)
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20200823/work/gcc-11-20200823/gcc/fold-const.c:8732
0x1125ecc ana::region_model_manager::maybe_fold_unaryop(tree_node*, tree_code,
ana::svalue const*)
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20200823/work/gcc-11-20200823/gcc/analyzer/region-model-manager.cc:369
0x1125fd8 ana::region_model_manager::get_or_create_unaryop(tree_node*,
tree_code, ana::svalue const*)
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20200823/work/gcc-11-20200823/gcc/analyzer/region-model-manager.cc:382
0x1125fd8 ana::region_model_manager::get_or_create_cast(tree_node*, ana::svalue
const*)
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20200823/work/gcc-11-20200823/gcc/analyzer/region-model-manager.cc:404
0x114c203 ana::initial_svalue::implicitly_live_p(hash_set > const&, ana::region_model
const*) const
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20200823/work/gcc-11-20200823/gcc/analyzer/svalue.cc:529
0x114c203 ana::initial_svalue::implicitly_live_p(hash_set > const&, ana::region_model
const*) const
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20200823/work/gcc-11-20200823/gcc/analyzer/svalue.cc:518
0x1105d59 ana::program_state::detect_leaks(ana::program_state const&,
ana::program_state const&, ana::svalue const*, ana::extrinsic_state const&,
ana::region_model_context*)
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20200823/work/gcc-11-20200823/gcc/analyzer/program-state.cc:1028
0x10f607a ana::exploded_graph::process_node(ana::exploded_node*)
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20200823/work/gcc-11-20200823/gcc/analyzer/engine.cc:2538
0x10f6aca ana::exploded_graph::process_worklist()
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20200823/work/gcc-11-20200823/gcc/analyzer/engine.cc:2341
0x10f8bff ana::impl_run_checkers(ana::logger*)
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20200823/work/gcc-11-20200823/gcc/analyzer/engine.cc:4107
0x10f981c ana::run_checkers()
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20200823/work/gcc-11-20200823/gcc/analyzer/engine.cc:4175
0x10ee1d8 execute
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20200823/work/gcc-11-20200823/gcc/analyzer/analyzer-pass.cc:84
[Bug c++/96765] New: Base class constructor cast to derived should cause a warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96765
Bug ID: 96765
Summary: Base class constructor cast to derived should cause a
warning
Product: gcc
Version: 10.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: jzwinck at gmail dot com
Target Milestone: ---
If I cast "this" in a base class constructor to a derived class type, there is
no warning even with -Wall -Wextra. Such a cast is undefined behavior, and
seems like it should be diagnosed at compile time.
For example:
struct Base
{
Base();
int num;
};
struct Derived : Base
{
int calc() const { return 42; }
};
Base::Base()
// UB: Derived not yet constructed
: num(static_cast(this)->calc())
{
}
int main()
{
Derived d;
return d.num;
}
It compiles cleanly with "-Wall -Wextra -Werror" in GCC 8 and 10, with and
without optimization. I think it should produce a diagnostic such as "invalid
static_cast from type ‘Base*’ to type ‘Derived*’ before the latter is
constructed".
UBSan reports the undefined behavior if Base has a virtual method (e.g. if you
add "virtual ~Base() = default;"), but not with the code as written, making it
even more advantageous to diagnose at compile time.
Live demo: https://godbolt.org/z/x3fa4Y
[Bug analyzer/96763] [11 Regression] ICE in get_subregion_within_ctor, at analyzer/store.cc:379 on RANGE_EXPR index
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96763 David Malcolm changed: What|Removed |Added Summary|[11 Regression] ICE in |[11 Regression] ICE in |get_subregion_within_ctor, |get_subregion_within_ctor, |at analyzer/store.cc:379|at analyzer/store.cc:379 on ||RANGE_EXPR index Ever confirmed|0 |1 Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2020-08-24 --- Comment #1 from David Malcolm --- Thanks for filing this; confirmed on powerpc64 and arm. index is a range_expr.
[Bug debug/96690] [10/11 Regression] ICE in write_type since r10-6087
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96690
--- Comment #5 from Richard Biener ---
Forcing the mangling via generating garbage RTL early doesn't work since
the
/* ??? The C++ FE emits debug information for using decls, so
putting gcc_unreachable here falls over. See PR31899. For now
be conservative. */
else if (!symtab->global_info_ready && VAR_OR_FUNCTION_DECL_P (*tp))
return *tp;
check in reference_to_unused triggers during the early debug pass over
template params and thus no RTL is generated from there. But the late
pass looks phishy:
else if (TREE_CODE (*tp) == FUNCTION_DECL
&& (!DECL_EXTERNAL (*tp) || DECL_DECLARED_INLINE_P (*tp)))
{
/* The call graph machinery must have finished analyzing,
optimizing and gimplifying the CU by now.
So if *TP has no call graph node associated
to it, it means *TP will not be emitted. */
if (!cgraph_node::get (*tp))
return *tp;
but 'foo' is DECL_EXTERNAL and TREE_PUBLIC. The following works on this
testcase though:
diff --git a/gcc/dwarf2out.c b/gcc/dwarf2out.c
index 9deca031fc2..29e011a296d 100644
--- a/gcc/dwarf2out.c
+++ b/gcc/dwarf2out.c
@@ -19756,7 +19785,7 @@ reference_to_unused (tree * tp, int * walk_subtrees,
/* ??? The C++ FE emits debug information for using decls, so
putting gcc_unreachable here falls over. See PR31899. For now
be conservative. */
- else if (!symtab->global_info_ready && VAR_OR_FUNCTION_DECL_P (*tp))
+ else if (!symtab->global_info_ready && VAR_P (*tp))
return *tp;
else if (VAR_P (*tp))
{
@@ -19771,7 +19800,7 @@ reference_to_unused (tree * tp, int * walk_subtrees,
optimizing and gimplifying the CU by now.
So if *TP has no call graph node associated
to it, it means *TP will not be emitted. */
- if (!cgraph_node::get (*tp))
+ if (!symtab->global_info_ready || !cgraph_node::get (*tp))
return *tp;
}
else if (TREE_CODE (*tp) == STRING_CST && !TREE_ASM_WRITTEN (*tp))
@@ -20295,12 +20324,11 @@ tree_add_const_value_attribute (dw_die_ref die, tree
t)
return true;
}
}
- if (! early_dwarf)
-{
- rtl = rtl_for_decl_init (init, type);
- if (rtl)
- return add_const_value_attribute (die, rtl);
-}
+ /* Generate the RTL even if early_dwarf to force mangling of all refered to
+ symbols. */
+ rtl = rtl_for_decl_init (init, type);
+ if (rtl && !early_dwarf)
+return add_const_value_attribute (die, rtl);
/* If the host and target are sane, try harder. */
if (CHAR_BIT == 8 && BITS_PER_UNIT == 8
&& initializer_constant_valid_p (init, type))
[Bug analyzer/96764] [11 Regression] ICE in fold_convert_const_int_from_real, at fold-const.c:2038
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96764 David Malcolm changed: What|Removed |Added Ever confirmed|0 |1 Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2020-08-24 --- Comment #1 from David Malcolm --- Thanks for filing this; confirmed.
[Bug debug/96690] [10/11 Regression] ICE in write_type since r10-6087
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96690 --- Comment #6 from Jakub Jelinek --- Without LTO, gen_remaining_tmpl_value_param_die_attribute will try to get it, and will mangle the foo decl, but shortly after will throw it away due to const_ok_for_output failing on it. Your patch makes sense to me.
[Bug c++/96761] "error: call of overloaded ‘func(size_t)’ is ambiguous" when argument is size_t(0) and func(int) and func(const char *) are visible
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96761 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #1 from Jakub Jelinek --- GCC treats size_t(0) in this case the same as 0UL (for arches where size_t is unsigned long), while clang does not. With func(0UL); it is ambiguous in both compilers.
[Bug target/96744] [11 Regression] FAIL: gcc.target/i386/avx512bitalgvl-vpopcntb-1.c execution test
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96744 --- Comment #3 from Uroš Bizjak --- Created attachment 49112 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49112&action=edit Retune mask <-> general moves cost It looks to me that mask <-> general cost is too low, so the compiler now prefers these moves too much. Attached patch equalizes mask <-> general cost with xmm <-> general cost, and it seems to fix the problem. Hongjiu, can you please retune the costs, using the attached patch as the start?
[Bug tree-optimization/96722] [8/9/10/11 Regression] Clobbers on NULL since r8-1519
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96722
--- Comment #4 from rguenther at suse dot de ---
On Mon, 24 Aug 2020, jakub at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96722
>
> --- Comment #3 from Jakub Jelinek ---
> Created attachment 49111
> --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49111&action=edit
> gcc11-pr96722.patch
>
> If *0 ={v} {CLOBBER}; is supposed to be a fancy nop, then we should ignore it
> during path isolation (shouldn't infer UB from clobber stmts).
Hmm, I guess the bug is that walk_stmt_load_store_addr_ops considers
clobbers a store. OTOH it may be that callers expect it to do that
(the callback gets passed the stmt to check itself if it wants).
So definitely the patch makes sense but still IMHO CDDCE has a
wrong-code bug here - it makes a conditional clobber unconditional.
Not sure if we can create a wrong-code testcase from C++s placement
of clobbers for a non-NULL case though.
[Bug c/96760] Faulty optimization in nested loops with -O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96760
--- Comment #3 from Yu Zhige ---
(In reply to Thomas Koenig from comment #1)
> The loop
>
> for (a = 20; a; a++) {
>
> increases a, which is a char, beyond its value range, and then tests
> against zero.
>
> This is undefined behavior.
>
> N4659, Clause 8:
>
> # If during the evaluation of an expression, the result is not mathematically
> # defined or not in the range of representable values for its type, the
> # behavior is undefined.
>
> If you had made a an unsigned type (for example an unsigned char), then
> the results would probably have been closer to what you expected.
Hi. The bug still exists even if we remove the UB in the inner for-loop. That
is, for this program:
#include
char a = 0, f = 0, c = 5;
unsigned long d = 0;
int g = 0;
int *e = &g;
int main() {
char b = 0;
for (;;) {
for (a = 0; a < 2; a++) { // no UB I believe
if (c) {
printf("%lu\n", d);
return 0;
}
}
f = (d++, *e);
}
}
The program would still trigger the bug with GCC-trunk.
[Bug debug/96690] [10/11 Regression] ICE in write_type since r10-6087
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96690 Richard Biener changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org --- Comment #7 from Richard Biener --- Testing the patch.
[Bug c++/96761] "error: call of overloaded ‘func(size_t)’ is ambiguous" when argument is size_t(0) and func(int) and func(const char *) are visible
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96761
Jakub Jelinek changed:
What|Removed |Added
Last reconfirmed||2020-08-24
Ever confirmed|0 |1
Status|UNCONFIRMED |NEW
CC||jason at gcc dot gnu.org,
||mpolacek at gcc dot gnu.org
--- Comment #2 from Jakub Jelinek ---
Shorter testcase (for -std=c++14 and later, at least for C++98 I think it is
correctly ambiguous):
typedef decltype(sizeof 0) size_t;
void foo (int);
void foo (const char *);
void
bar ()
{
foo (size_t (0));
}
I think the problem is that convert_to_integer_maybe_fold will ignore the
dofold argument if the expression is constant.
So, shall we punt on folding that, or just punt on folding it in the
problematic case (possibly wrapped 0 constant), something else?
[Bug libstdc++/96766] New: std::swap(std::variant, std::variant) triggers undefined behavior sanitizer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96766
Bug ID: 96766
Summary: std::swap(std::variant, std::variant) triggers
undefined behavior sanitizer
Product: gcc
Version: 10.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: kndevl at outlook dot com
Target Milestone: ---
Created attachment 49113
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49113&action=edit
preprocessed source
This snippet
```
#include
class Foo {
};
class Bar {
};
using T = std::variant;
int main()
{
T t1 { Foo {} };
T t2 { Bar {} };
std::swap(t1, t2);
return 0;
}
```
triggers the following warning
```
/usr/bin/../lib64/gcc/x86_64-pc-linux-gnu/10.2.0/../../../../include/c++/10.2.0/variant:444:20:
runtime error: implicit conversion from type 'std::size_t' (aka 'unsigned
long') of value 18446744073709551615 (64-bit, unsigned) to type
'std::__detail::__variant::_Variant_storage::__index_type' (aka
'unsigned char') changed the value to 255 (8-bit, unsigned)
#0 0x55c00ff464ea in std::__detail::__variant::_Variant_storage::_M_reset()
/usr/bin/../lib64/gcc/x86_64-pc-linux-gnu/10.2.0/../../../../include/c++/10.2.0/variant:444
#1 0x55c00ff476a4 in void std::__detail::__variant::_Move_ctor_base::_M_destructive_move(unsigned short, Bar&&)
/usr/bin/../lib64/gcc/x86_64-pc-linux-gnu/10.2.0/../../../../include/c++/10.2.0/variant:564
#2 0x55c00ff472fb in auto std::variant::swap(std::variant&)::{lambda(auto:1&&, auto:2)#1}::operator() >(Bar&,
std::integral_constant)
/usr/bin/../lib64/gcc/x86_64-pc-linux-gnu/10.2.0/../../../../include/c++/10.2.0/variant:1588
#3 0x55c00ff4701e in void std::__invoke_impl::swap(std::variant&)::{lambda(auto:1&&, auto:2)#1}, Bar&,
std::integral_constant >(std::__invoke_other,
std::variant::swap(std::variant&)::{lambda(auto:1&&,
auto:2)#1}&&, Bar&, std::integral_constant&&)
/usr/bin/../lib64/gcc/x86_64-pc-linux-gnu/10.2.0/../../../../include/c++/10.2.0/bits/invoke.h:60
#4 0x55c00ff46e3f in std::__invoke_result::swap(std::variant&)::{lambda(auto:1&&, auto:2)#1}, Bar&,
std::integral_constant >::type
std::__invoke::swap(std::variant&)::{lambda(auto:1&&, auto:2)#1}, Bar&, std::integral_constant >(std::variant::swap(std::variant&)::{lambda(auto:1&&, auto:2)#1}&&, (std::__invoke_result&&)...)
/usr/bin/../lib64/gcc/x86_64-pc-linux-gnu/10.2.0/../../../../include/c++/10.2.0/bits/invoke.h:95
#5 0x55c00ff458e3 in
std::__detail::__variant::__gen_vtable_impl::swap(std::variant&)::{lambda(auto:1&&,
auto:2)#1}&&, std::variant&)>, std::integer_sequence >::__visit_invoke(std::variant::swap(std::variant&)::{lambda(auto:1&&, auto:2)#1}, std::variant&)
/usr/bin/../lib64/gcc/x86_64-pc-linux-gnu/10.2.0/../../../../include/c++/10.2.0/variant:1001
#6 0x55c00ff4537c in decltype(auto)
std::__do_visit::swap(std::variant&)::{lambda(auto:1&&,
auto:2)#1}, std::variant&>(std::variant::swap(std::variant&)::{lambda(auto:1&&, auto:2)#1}&&,
std::variant&)
/usr/bin/../lib64/gcc/x86_64-pc-linux-gnu/10.2.0/../../../../include/c++/10.2.0/variant:1694
#7 0x55c00ff45188 in void
std::__detail::__variant::__raw_idx_visit::swap(std::variant&)::{lambda(auto:1&&, auto:2)#1},
std::variant&>(std::variant::swap(std::variant&)::{lambda(auto:1&&, auto:2)#1}&&, std::variant&)
/usr/bin/../lib64/gcc/x86_64-pc-linux-gnu/10.2.0/../../../../include/c++/10.2.0/variant:201
#8 0x55c00ff4505a in std::variant::swap(std::variant&)
/usr/bin/../lib64/gcc/x86_64-pc-linux-gnu/10.2.0/../../../../include/c++/10.2.0/variant:1570
#9 0x55c00ff44451 in std::enable_if<(((is_move_constructible_v)&&...))&&(((is_swappable_v)&&...)), void>::type std::swap(std::variant&, std::variant&)
/usr/bin/../lib64/gcc/x86_64-pc-linux-gnu/10.2.0/../../../../include/c++/10.2.0/variant:1240
#10 0x55c00ff44278 in main ../ubsan.cpp:14
#11 0x7f7f64b19151 in __libc_start_main (/usr/lib/libc.so.6+0x28151)
#12 0x55c00ff4414d in _start
(/home/user/main/cmake-build-debug-clang/ubsan-test+0x514d)
```
Is this a bug in libstdc++ or clang's sanitizer?
[Bug libstdc++/96766] std::swap(std::variant, std::variant) triggers undefined behavior sanitizer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96766 --- Comment #1 from Karthik Nishanth --- Reproducer https://www.godbolt.org/z/Whz6ab
[Bug libstdc++/96766] std::swap(std::variant, std::variant) triggers undefined behavior sanitizer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96766 --- Comment #2 from Jonathan Wakely --- This is clang's stupid "unsigned overflow" sanitizer, which complains about correct code. The conversion here is intended, and does exactly the right thing, converting numeric_limits::max() to numeric_limits::max().
[Bug libstdc++/96766] std::swap(std::variant, std::variant) triggers undefined behavior sanitizer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96766 Jonathan Wakely changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |redi at gcc dot gnu.org Ever confirmed|0 |1 Last reconfirmed||2020-08-24 Status|UNCONFIRMED |ASSIGNED --- Comment #3 from Jonathan Wakely --- I'll use static_cast to suppress the bogus errors.
[Bug tree-optimization/96722] [8/9/10/11 Regression] Clobbers on NULL since r8-1519
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96722 --- Comment #5 from Jakub Jelinek --- On the CDDCE side, I'm afraid I have no idea what can be done. The pass works by not considering clobber stmts necessary, and when about to remove (all) clobbers as unnecessary, it instead attempts to keep them unless they refer to SSA_NAMEs that weren't processed. At that point, it has no idea if some clobber got turned from conditional into unconditional, or the more likely case that it is kept as is. So we'd need to remove (or somehow mark for guaranteed removal) the clobbers earlier if they were turned from conditional into unconditional.
[Bug c++/96765] Base class constructor cast to derived should cause a warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96765 Jonathan Wakely changed: What|Removed |Added Last reconfirmed||2020-08-24 Ever confirmed|0 |1 Status|UNCONFIRMED |NEW --- Comment #1 from Jonathan Wakely --- I agree a diagnostic makes sense.
[Bug tree-optimization/96758] [10/11 Regression] strncmp miscompiles as memcmp since r10-3920-g27c14dbc6b01d5b7
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96758 --- Comment #3 from R. Evans --- Thanks for the quick patch! Applied to head (87c753ac) and confirmed that it passes the test case and fixes the problem with smartmontools-7.1.
[Bug target/96767] New: -mpure-code produces indirect loads for thumb-1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96767
Bug ID: 96767
Summary: -mpure-code produces indirect loads for thumb-1
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: clyon at gcc dot gnu.org
Target Milestone: ---
As described in PR94538, -mpure-code produces suboptimal code for thumb-1 CPUs.
int x;
int f1 (void) { return x; }
Compiled with -O2 -mpure-code,
-mcpu=cortex-m0:
movsr3, #:upper8_15:#.LC0
lslsr3, #8
addsr3, #:upper0_7:#.LC0
lslsr3, #8
addsr3, #:lower8_15:#.LC0
lslsr3, #8
addsr3, #:lower0_7:#.LC0
@ sp needed
ldr r3, [r3]
ldr r0, [r3]
bx lr
-> extra indirection, there should be only one ldr
For reference, -mcpu=cortex-m[347] and m23 produce:
movwr3, #:lower16:.LANCHOR0
movtr3, #:upper16:.LANCHOR0
ldr r0, [r3]
bx lr
[Bug target/96768] New: -mpure-code produces switch tables for thumb-1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96768
Bug ID: 96768
Summary: -mpure-code produces switch tables for thumb-1
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: clyon at gcc dot gnu.org
Target Milestone: ---
As discussed in PR94538, -mpure-code produces switch tables for thumb-1.
int f2 (int x, int y)
{
switch (x)
{
case 0: return y + 0;
case 1: return y + 1;
case 2: return y + 2;
case 3: return y + 3;
case 4: return y + 4;
case 5: return y + 5;
}
return y;
}
Compiled with -O2 -mpure-code,
-mcpu=cortex-m0:
f2:
cmp r0, #5
bhi .L9
movsr2, #:upper8_15:#.LC0
lslsr2, #8
addsr2, #:upper0_7:#.LC0
lslsr2, #8
addsr2, #:lower8_15:#.LC0
lslsr2, #8
addsr2, #:lower0_7:#.LC0
ldr r2, [r2]
lslsr0, r0, #2
ldr r3, [r2, r0]
mov pc, r3
.section.rodata
.align 2
.L4:
.word .L9
.word .L8
.word .L7
.word .L6
.word .L5
.word .L3
.section .text,"0x2006",%progbits
.L3:
addsr0, r1, #5
.L1:
@ sp needed
bx lr
.L8:
addsr0, r1, #1
b .L1
.L7:
addsr0, r1, #2
b .L1
.L6:
addsr0, r1, #3
b .L1
.L5:
addsr0, r1, #4
b .L1
.L9:
movsr0, r1
b .L1
For cortex-m23:
f2:
cmp r0, #5
bhi .L9
movwr2, #:lower16:.LC0
movtr2, #:upper16:.LC0
ldr r2, [r2]
lslsr0, r0, #2
ldr r3, [r2, r0]
mov pc, r3
For reference, for cortex-m3:
f2:
cmp r0, #3
beq .L2
ble .L11
cmp r0, #4
beq .L7
cmp r0, #5
bne .L9
addsr0, r1, #5
bx lr
.L11:
cmp r0, #1
beq .L4
cmp r0, #2
bne .L9
addsr0, r1, #2
bx lr
.L2:
addsr0, r1, #3
bx lr
.L7:
addsr0, r1, #4
bx lr
.L4:
addsr0, r1, #1
bx lr
.L9:
mov r0, r1
bx lr
[Bug target/96769] New: -mpure-code produces suboptimal code for immediate generation for thumb-1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96769
Bug ID: 96769
Summary: -mpure-code produces suboptimal code for immediate
generation for thumb-1
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: clyon at gcc dot gnu.org
Target Milestone: ---
As discussed in PR94538, -mpure-code produces switch tables for thumb-1.
int f3 (void) { return 0x1100; }
int f3_2 (void) { return 0x12345678; }
Compiled with -O2 -mpure-code,
-mcpu=cortex-m0:
f3:
movsr0, #17
@ sp needed
lslsr0, r0, #8
lslsr0, r0, #8
lslsr0, r0, #8
bx lr
f3_2:
movsr0, #18
@ sp needed
lslsr0, r0, #8
addsr0, r0, #52
lslsr0, r0, #8
addsr0, r0, #86
lslsr0, r0, #8
addsr0, r0, #120
bx lr
-mcpu=cortex-m23:
f3:
movsr0, #136
@ sp needed
lslsr0, r0, #21
bx lr
f3_2:
movwr0, #22136
@ sp needed
movtr0, 4660
bx lr
Code for cortex-m23 is OK, but the code for cortex-m0 could be improved for
f3(). For f3_2(), code for cortex-m0 looks OK since that CPU does not have
movw/movt instructions.
[Bug target/96770] New: -mpure-code produces suboptimal code for relocations with small offset for thumb-1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96770
Bug ID: 96770
Summary: -mpure-code produces suboptimal code for relocations
with small offset for thumb-1
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: clyon at gcc dot gnu.org
Target Milestone: ---
As discussed in PR94538, -mpure-code produces suboptimal code for relocations
with small offset for thumb-1.
int arr[10];
int *f4 (void) { return &arr[1]; }
Compiled with -O2 -mpure-code,
-mcpu=cortex-m0:
f4:
movsr3, #:upper8_15:#.LC0
lslsr3, #8
addsr3, #:upper0_7:#.LC0
lslsr3, #8
addsr3, #:lower8_15:#.LC0
lslsr3, #8
addsr3, #:lower0_7:#.LC0
@ sp needed
ldr r0, [r3]
addsr0, r0, #4
bx lr
We should avoid the extra load from the literal pool (related to PR96767), and
the 'adds r0,r0,4'.
-mcpu=cortex-m23:
f4:
movwr0, #:lower16:.LANCHOR0
@ sp needed
movtr0, #:upper16:.LANCHOR0
addsr0, r0, #4
bx lr
For reference, -mcpu=cortex-m3 produces:
f4:
movwr0, #:lower16:.LANCHOR0+4
movtr0, #:upper16:.LANCHOR0+4
bx lr
We should generate the same code for cortex-m23.
[Bug target/94538] [9/10/11 Regression] ICE: in extract_constrain_insn_cached, at recog.c:2223 (insn does not satisfy its constraints) with -mcpu=cortex-m23 -mslow-flash-data
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94538 --- Comment #21 from Christophe Lyon --- I filed PR96767, PR96768, PR96769, PR96770 to track the enhancements discussed here. The ICE is now fixed in trunk.
[Bug tree-optimization/96722] [8/9/10/11 Regression] Clobbers on NULL since r8-1519
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96722
--- Comment #6 from Richard Biener ---
I don't have a good idea either but eventually something along the following -
if we remove any control stmt in a clobbers control dependence chain
force-remove the clobber. Obviously as written it's highly inefficient,
such tracking would need to be done only once per BB. It might also be
too conservative - eventually only the "immediate" control dependence matters
(but the control dependence machinery does not give us this easily).
Eventually we can also check the last_stmt_necessary bitmap instead
of looking at last_stmt itself.
diff --git a/gcc/tree-ssa-dce.c b/gcc/tree-ssa-dce.c
index fae5ae72340..9066dbf6373 100644
--- a/gcc/tree-ssa-dce.c
+++ b/gcc/tree-ssa-dce.c
@@ -1428,6 +1431,23 @@ eliminate_unnecessary_stmts (void)
break;
}
}
+ if (!dead && cd)
+ {
+ bitmap_iterator bi;
+ unsigned edge_number;
+ EXECUTE_IF_SET_IN_BITMAP (cd->get_edges_dependent_on
+ (bb->index),
+ 0, edge_number, bi)
+ {
+ basic_block cd_bb = cd->get_edge_src (edge_number);
+ if (cd_bb != bb
+ && !gimple_plf (last_stmt (cd_bb),
STMT_NECESSARY))
+ {
+ dead = true;
+ break;
+ }
+ }
+ }
if (!dead)
{
bitmap_clear (debug_seen);
@@ -1665,6 +1685,7 @@ tree_dce_done (bool aggressive)
if (aggressive)
{
delete cd;
+ cd = NULL;
sbitmap_free (visited_control_parents);
sbitmap_free (last_stmt_necessary);
sbitmap_free (bb_contains_live_stmts);
[Bug fortran/96486] get_environment_variable crashes for environment variables that are empty strings
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96486 --- Comment #31 from CVS Commits --- The releases/gcc-9 branch has been updated by Mark Eggleston : https://gcc.gnu.org/g:bbe17767c602f1ff08a1520a1d989c6b86b536fd commit r9-8829-gbbe17767c602f1ff08a1520a1d989c6b86b536fd Author: Mark Eggleston Date: Mon Aug 10 08:07:39 2020 +0100 Fortran : get_environment_variable runtime error PR96486 Runtime error occurs when the type of the value argument is character(0): "Zero-length string passed as value...". The status argument, intent(out), will contain -1 if the value of the environment is too large to fit in the value argument, this is the case if the type is character(0) so there is no reason to produce a runtime error if the value argument is zero length. 2020-08-24 Mark Eggleston libgfortran/ PR fortran/96486 * intrinsics/env.c: If value_len is > 0 blank the string. Copy the result only if its length is > 0. 2020-08-24 Mark Eggleston gcc/testsuite/ PR fortran/96486 * gfortran.dg/pr96486.f90: New test. (cherry picked from commit de09e7ebc9d653745a103eef2b20c7f1dd76)
[Bug fortran/96486] get_environment_variable crashes for environment variables that are empty strings
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96486 markeggleston at gcc dot gnu.org changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #32 from markeggleston at gcc dot gnu.org --- Committed to master and backported to gcc-10 and gcc-9. For F2018 conformance see PR96583.
[Bug target/96744] [11 Regression] FAIL: gcc.target/i386/avx512bitalgvl-vpopcntb-1.c execution test
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96744 --- Comment #4 from Uroš Bizjak --- Created attachment 49114 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49114&action=edit Double-reg mask moves
[Bug target/96744] [11 Regression] FAIL: gcc.target/i386/avx512bitalgvl-vpopcntb-1.c execution test
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96744 --- Comment #5 from Uroš Bizjak --- (In reply to Hongtao.liu from comment #2) > Need to add define_insn for movp2qi/movp2hi? Yes, this is needed to cover some corner cases. Please see attachment 49114. However, the patch assumes that avx512vp2intersect implies mavx512dq, otherwise there is no direct QImode move from mask register to memory available.
[Bug tree-optimization/96715] Failure to optimize copysign of variable by negated variable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96715 Jakub Jelinek changed: What|Removed |Added Last reconfirmed||2020-08-24 Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org Status|UNCONFIRMED |ASSIGNED Ever confirmed|0 |1 --- Comment #1 from Jakub Jelinek --- Created attachment 49115 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49115&action=edit gcc11-pr96715.patch Untested fix.
[Bug target/96744] [11 Regression] FAIL: gcc.target/i386/avx512bitalgvl-vpopcntb-1.c execution test
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96744
--- Comment #6 from Uroš Bizjak ---
(In reply to Uroš Bizjak from comment #5)
> However, the patch assumes that avx512vp2intersect implies mavx512dq,
> otherwise there is no direct QImode move from mask register to memory
> available.
This is the testcase:
--cut here--
typedef unsigned char __mmask8;
typedef unsigned short __mmask16;
typedef long long __m512i __attribute__ ((__vector_size__ (64),
__may_alias__));
typedef int __v16si __attribute__ ((__vector_size__ (64)));
typedef long long __v8di __attribute__ ((__vector_size__ (64)));
void
_mm512_2intersect_epi64 (__m512i __A, __m512i __B, __mmask8 *__U,
__mmask8 *__M)
{
__builtin_ia32_2intersectq512 (__U, __M, (__v8di) __A, (__v8di) __B);
}
--cut here--
cc1 -O2 -march=k8 -mavx512vp2intersect -mavx512bw pr96744.c
pr96744.c:13:1: error: insn does not satisfy its constraints:
13 | }
| ^
(insn 24 9 25 2 (set (mem/c:QI (plus:DI (reg/f:DI 7 sp)
(const_int -2 [0xfffe])) [1 %sfp+-2 S1 A16])
(reg:QI 68 k0 [86])) "pr96744.c":12:3 77 {*movqi_internal}
(expr_list:REG_DEAD (reg:QI 68 k0 [86])
(nil)))
during RTL pass: cprop_hardreg
compiles OK when -mavx512dq is added.
[Bug tree-optimization/96730] [10/11 Regression] ICE on x86_64-linux-gnu with `-O1` to `-O3` (in verify_sra_access_forest, at tree-sra.c:2352) since r10-6320-g5b9e89c922dc2e7e
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96730 --- Comment #3 from Martin Jambor --- I have proposed a fix on the mailing list: https://gcc.gnu.org/pipermail/gcc-patches/2020-August/552488.html
[Bug libstdc++/96766] std::swap(std::variant, std::variant) triggers undefined behavior sanitizer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96766 --- Comment #4 from CVS Commits --- The master branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:074436cf8cdd2a9ce75cadd36deb8301f00e55b9 commit r11-2822-g074436cf8cdd2a9ce75cadd36deb8301f00e55b9 Author: Jonathan Wakely Date: Mon Aug 24 16:10:07 2020 +0100 libstdc++: Make variant_npos conversions explicit [PR 96766] libstdc++-v3/ChangeLog: PR libstdc++/96766 * include/std/variant (_Variant_storage): Replace implicit conversions from size_t to __index_type with explicit casts.
[Bug middle-end/96771] New: arm/pr32920-2.c fails since svn r228175 / f11a7b6d57f6fcba1bf2e5a0403dc49120195320
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96771
Bug ID: 96771
Summary: arm/pr32920-2.c fails since svn r228175 /
f11a7b6d57f6fcba1bf2e5a0403dc49120195320
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: clyon at gcc dot gnu.org
Target Milestone: ---
The gcc.target/arm/pr43920-c testcase fails since svn r228175 / git
f11a7b6d57f6fcba1bf2e5a0403dc49120195320 (r6-3529).
That commit from 2015 says:
revert to assign_parms assignments using default defs
Revert the fragile and complicated changes to assign_parms designed to
enable it to use RTL assigments chosen by cfgexpand, and instead have
cfgexpand use the RTL assignments by assign_parms, keying them off of
the default defs that are now necessarily introduced for each parm and
result. The possible lack of a default def was already a problem, and
the fallbacks in place were not enough, as shown by PR67312. We now
have checking asserts in set_rtl that verify that we're assigning to
each var a piece of RTL that matches the expectations set forth by
use_register_for_decl.
Looking at the generated code, before the patch we had: (-mcpu=cortex-m3):
getFileStartAndLength:
@ args = 0, pretend = 0, frame = 0
@ frame_needed = 0, uses_anonymous_args = 0
push{r3, r4, r5, r6, r7, lr}
mov r6, r1
mov r5, r2
movsr1, #0
movsr2, #1
mov r7, r0
bl lseek
mov r4, r0
movsr2, #2
movsr1, #0
mov r0, r7
bl lseek
addsr2, r4, #1
beq .L4
addsr3, r0, #1
beq .L2
subsr0, r0, r4
beq .L4
str r4, [r6]
str r0, [r5]
movsr0, #0
pop {r3, r4, r5, r6, r7, pc}
.L4:
mov r0, #-1
.L2:
pop {r3, r4, r5, r6, r7, pc}
and now we have:
getFileStartAndLength:
@ args = 0, pretend = 0, frame = 0
@ frame_needed = 0, uses_anonymous_args = 0
push{r3, r4, r5, r6, r7, lr}
mov r6, r1
mov r5, r2
movsr1, #0
movsr2, #1
mov r7, r0
bl lseek
mov r4, r0
movsr2, #2
movsr1, #0
mov r0, r7
bl lseek
addsr2, r4, #1
beq .L1
addsr3, r0, #1
beq .L4
subsr0, r0, r4
beq .L4
str r4, [r6]
str r0, [r5]
movsr4, #0
b .L1
.L4:
mov r4, #-1
.L1:
mov r0, r4
pop {r3, r4, r5, r6, r7, pc}
The testcase fails because we now generate only one 'pop' instruction while we
expect two.
But the exit code sequence is actually longer now.
Before that patch we had either:
pop {r3, r4, r5, r6, r7, pc}
or
mov r0, #-1
pop {r3, r4, r5, r6, r7, pc}
We now have either:
mov r0, r4
pop {r3, r4, r5, r6, r7, pc}
or
mov r4, #-1
mov r0, r4
pop {r3, r4, r5, r6, r7, pc}
[Bug middle-end/96733] std::clamp for floats and doubles produces worse code than a combo of std::min / std::max
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96733 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org, ||redi at gcc dot gnu.org --- Comment #2 from Jakub Jelinek --- I'm afraid there is nothing that the compiler can do to optimize the clamp_builtin into similar code to clamp_minmax, because the optimizer doesn't know an important restriction on std::clamp - "The behavior is undefined if the value of lo is greater than hi". In the IL this isn't expressed in any way, and when the compiler sees (__val < __lo) ? __lo : (__hi < __val) ? __hi : __val it can only optimize (for -Ofast) the (__hi < __val) ? __hi : __val part into min (__hi, __val), but as it needs to assume e.g. __lo could be 10 and __hi 5, it can't emit max.
[Bug middle-end/96733] std::clamp for floats and doubles produces worse code than a combo of std::min / std::max
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96733 --- Comment #3 from Jonathan Wakely --- Shouldn't this help in the library then? if (__hi < __lo) __builtin_unreachable();
[Bug middle-end/96733] std::clamp for floats and doubles produces worse code than a combo of std::min / std::max
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96733 --- Comment #4 from Jakub Jelinek --- (In reply to Jonathan Wakely from comment #3) > Shouldn't this help in the library then? > > if (__hi < __lo) > __builtin_unreachable(); For integers, I guess it could if Andrew's/Aldy's stuff gets in and can be used for that, for floating point types, we don't really have any value range handling, and without -ffast-math it might be even impossible to optimize away. Can't std::clamp be implemented using std::min/std::max instead, or at least as code that can be optimized into that?
[Bug target/96772] New: Power VSX libmvec implementation for OpenMP SIMD
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96772 Bug ID: 96772 Summary: Power VSX libmvec implementation for OpenMP SIMD Product: gcc Version: unknown Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: dje at gcc dot gnu.org Target Milestone: --- Target: powerpc64le-*-linux
[Bug target/96772] Power VSX libmvec implementation for OpenMP SIMD
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96772 David Edelsohn changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever confirmed|0 |1 Last reconfirmed||2020-08-24 --- Comment #1 from David Edelsohn --- Feature request for Power VSX libmvec "ABI" implementation in GCC.
[Bug c++/88003] ICE on outside definition of inner function-local class in poplevel_class, at cp/name-lookup.c:4325
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88003 Nathan Sidwell changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |nathan at gcc dot gnu.org CC||nathan at gcc dot gnu.org Status|NEW |ASSIGNED --- Comment #4 from Nathan Sidwell --- I accidentally fixed this, cos I grepped for internal compiler error to find what I'd just broken. You tricked me!
[Bug c++/96742] "warning: comparison of unsigned expression in ‘< 0’ is always false" with dependent values
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96742 Marek Polacek changed: What|Removed |Added CC||mpolacek at gcc dot gnu.org --- Comment #1 from Marek Polacek --- Started with my r11-155. Why do you think this is a bug though? Isn't that warning legit? It doesn't occur when the template isn't instantiated, or is instantiated, but with N that isn't 0.
[Bug c++/88003] ICE on outside definition of inner function-local class in poplevel_class, at cp/name-lookup.c:4325
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88003 --- Comment #5 from Marek Polacek --- All part of my grand plan. Seriously though, you must've grepped an ICE that was XFAILed (the only one, thus far).
[Bug libstdc++/96733] std::clamp for floats and doubles produces worse code than a combo of std::min / std::max
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96733 Jonathan Wakely changed: What|Removed |Added Component|middle-end |libstdc++ --- Comment #5 from Jonathan Wakely --- Yes, it looks like we might want to do that then. We can have different code for different types if needed. Reassigning to libstdc++.
[Bug sanitizer/96773] New: ASan: please provide __asan_address_is_shadow() for complex programs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96773 Bug ID: 96773 Summary: ASan: please provide __asan_address_is_shadow() for complex programs Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: sanitizer Assignee: unassigned at gcc dot gnu.org Reporter: diane2332 at gmail dot com CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org, jakub at gcc dot gnu.org, kcc at gcc dot gnu.org, marxin at gcc dot gnu.org Target Milestone: --- I am using ASan on a huge application, and it does things like dumping various memory areas when there is an error. It has a function that indicates whether a particular address is safe to dereference. If this function says that an address in ASan's shadow or shadow gap is ok to reference, and the caller is instrumented for ASan, a SEGV can occur. For this reason I would like ASan to provide a function to indicate whether an address is in ASan's shadow or shadow gap, and therefore, shouldn't be dereferenced. My suggested interface for this is: int __asan_address_is_shadow (void *address); // returns 1 if address is in high shadow, low shadow, or shadow gap I know that the addresses of these areas on various targets are published in AddressSanitizerAlgorithm, but they are subject to change under various flags, so it's best not to rely on these addresses. Please see also the GitHub I filed: https://github.com/google/sanitizers/issues/1299
[Bug sanitizer/96773] ASan: please provide __asan_address_is_shadow() for complex programs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96773 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |SUSPENDED Ever confirmed|0 |1 Last reconfirmed||2020-08-24 --- Comment #1 from Andrew Pinski --- Suspend until it is fixed upstream.
[Bug sanitizer/96774] New: UBSan: please provide __ubsan_set_error_report_callback() to capture error messages
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96774 Bug ID: 96774 Summary: UBSan: please provide __ubsan_set_error_report_callback() to capture error messages Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: sanitizer Assignee: unassigned at gcc dot gnu.org Reporter: diane2332 at gmail dot com CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org, jakub at gcc dot gnu.org, kcc at gcc dot gnu.org, marxin at gcc dot gnu.org Target Milestone: --- I am using UBSan (UndefinedBehaviorSanitizer) on a huge application and the method of redirecting errors to a log file really doesn't work well for developers. They want to use their own error handling functions that produce alerts and memory dumps, etc. Please provide a similar function to __asan_set_error_report_callback(). Please see the GitHub issue I filed: https://github.com/google/sanitizers/issues/1298
[Bug sanitizer/96775] New: UBSan: confusing error message load of address with insufficient space
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96775
Bug ID: 96775
Summary: UBSan: confusing error message load of address with
insufficient space
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: sanitizer
Assignee: unassigned at gcc dot gnu.org
Reporter: diane2332 at gmail dot com
CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org,
jakub at gcc dot gnu.org, kcc at gcc dot gnu.org, marxin at
gcc dot gnu.org
Target Milestone: ---
UBSan gives 2 very confusing error messages:
load of address with insufficient space for an object of type 'whatever'
store of address with insufficient space for an object of type 'whatever'
We ran UBSan on a very large application and filed many bugs detected.
Developers of this application were stumped as to what this message meant, and
I was also for a while. Eventually I realized that this message really
indicates either BUFFER OVERFLOW READ or BUFFER OVERFLOW WRITE. This is what's
happening and this is something that developers understand and can take action
on. Here is a simple example:
#include
int main()
{
const unsigned int size = 20;
unsigned int array = (unsigned int)malloc(sizeof(unsigned int) * size);
array[size] = array[size+1];
return array[-1];
}
gcc test3.c -O -fsanitize=undefined
./a.out
test3.c:7:16: runtime error: load of address 0x01bf8064 with insufficient
space for an object of type 'unsigned int'
0x01bf8064: note: pointer points here
00 00 00 00 00 00 00 00 a1 0f 02 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00
^
test3.c:7:16: runtime error: store to address 0x01bf8060 with insufficient
space for an object of type 'unsigned int'
0x01bf8060: note: pointer points here
00 00 00 00 00 00 00 00 00 00 00 00 a1 0f 02 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00
^
I'm using gcc 8.2.1.
It would be much clearer to say something like:
test3.c:7:16: runtime error: BUFFER OVERFLOW READ on address 0x01bf8064 for
an object of type 'unsigned int'
Please see the GitHub issue I filed for this:
https://github.com/google/sanitizers/issues/1297
[Bug sanitizer/96774] UBSan: please provide __ubsan_set_error_report_callback() to capture error messages
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96774 Andrew Pinski changed: What|Removed |Added Ever confirmed|0 |1 See Also||https://github.com/google/s ||anitizers/issues/1298 Status|UNCONFIRMED |SUSPENDED Last reconfirmed||2020-08-24 --- Comment #1 from Andrew Pinski --- Suspending until fixed upstream.
[Bug sanitizer/96775] UBSan: confusing error message load of address with insufficient space
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96775 Andrew Pinski changed: What|Removed |Added See Also||https://github.com/google/s ||anitizers/issues/1297 Version|unknown |8.2.1 --- Comment #1 from Andrew Pinski --- You might want to try a newer version of GCC as newer version of san has been included. Also 8.x will never include the change.
[Bug d/96153] d: struct literals have non-deterministic hash values
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96153 --- Comment #7 from Iain Buclaw --- Fixing the case for SPARC64 triggers the test case in pr96157 to fail on x86_64.
[Bug sanitizer/96775] UBSan: confusing error message load of address with insufficient space
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96775 --- Comment #2 from Diane Meirowitz --- I have the latest llvm source code and it's the same. We will back port any fixes.
[Bug middle-end/88780] [8/9/10/11 Regression] bogus -Wstringop-truncation for copying as many bytes from a string as its length
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88780 --- Comment #8 from Marietto --- https://bugs.launchpad.net/ubuntu/+source/gcc-9/+bug/1892475 Il giorno mar 18 ago 2020 alle ore 19:26 msebor at gcc dot gnu.org < gcc-bugzi...@gcc.gnu.org> ha scritto: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88780 > > --- Comment #7 from Martin Sebor --- > (In reply to Marietto from comment #6) > ... > > In function ‘strncpy’, > > inlined from ‘xc_set_cpufreq_gov’ at xc_pm.c:308:5: > > /usr/include/x86_64-linux-gnu/bits/string_fortified.h:106:10: error: > > ‘__builtin_strncpy’ specified bound 16 equals destination size > > [-Werror=stringop-truncation] > > 106 | return __builtin___strncpy_chk (__dest, __src, __len, __bos > (__dest)); > > | ^~ > > This instance of the warning is most likely unrelated to the one reported > in > comment #0 (to tell for sure we'd need a test case to reproduce it). It > indicates that strncpy is being called with the third argument set to the > size > of the destination array, which leaves the destination unterminated unless > the > source string is shorter. The following articles describe the problem and > the > suggested solutions in detail: > > > https://developers.redhat.com/blog/2018/05/24/detecting-string-truncation-with-gcc-8/ > > https://us-cert.cisa.gov/bsi/articles/knowledge/coding-practices/strncpy-and-strncat > > -- > You are receiving this mail because: > You are on the CC list for the bug.
[Bug sanitizer/94448] LSan: leaks should report PID and TID of allocation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94448 Diane Meirowitz changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |WONTFIX --- Comment #3 from Diane Meirowitz --- GitHub issue has been closed because nobody else has requested TID in 7 years. This is fine I don't think we need it after all. Closing.
[Bug sanitizer/96775] UBSan: confusing error message load of address with insufficient space
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96775 Andrew Pinski changed: What|Removed |Added Ever confirmed|0 |1 Last reconfirmed||2020-08-24 Status|UNCONFIRMED |SUSPENDED --- Comment #3 from Andrew Pinski --- So suspending until the bug has been fixed upstream.
[Bug c++/96776] New: Missing tail call optimization when passing local variable by reference to yet another function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96776
Bug ID: 96776
Summary: Missing tail call optimization when passing local
variable by reference to yet another function
Product: gcc
Version: 10.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: mizvekov at gmail dot com
Target Milestone: ---
Compiler explorer workspace showing the problem: https://godbolt.org/z/z8W74T
Calling `foo` with reference to local should not prevent tail calling `cont` in
this case.
Code for reference:
```
extern void foo(const int &) noexcept;
extern void cont() noexcept;
void test(int a) noexcept {
foo(a);
return cont();
}
```
[Bug c++/96776] Missing tail call optimization when passing local variable by reference to yet another function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96776
Andrew Pinski changed:
What|Removed |Added
Resolution|--- |INVALID
Status|UNCONFIRMED |RESOLVED
--- Comment #1 from Andrew Pinski ---
>Calling `foo` with reference to local should not prevent tail calling `cont`
>in this case
WRONG.
foo could store the local reference variable into a global pointer.
E.g.
static const int *a;
void foo(const int &b) noexcept
{
a = &b;
}
void cont(void)
{
printf(*a);
}
You can't do tail call as the argument variable escapes.
[Bug c++/96776] Missing tail call optimization when passing local variable by reference to yet another function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96776 Matheus Izvekov changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|INVALID |--- --- Comment #2 from Matheus Izvekov --- Oh, nevermind, scratch this issue please, I realized this is invalid anyway, it would be legal for foo to escape that reference and expect it to live until the end of test.
[Bug target/96709] cmov and vectorization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96709 Andrew Pinski changed: What|Removed |Added Last reconfirmed||2020-08-24 Status|UNCONFIRMED |WAITING Target||x86_64-linux-gnu Ever confirmed|0 |1 Component|c++ |target --- Comment #1 from Andrew Pinski --- Can you attach the preprocessed source as boost versions matter.
