[Bug tree-optimization/113753] New: wrong code with _BitInt(129) multiplication and division at -O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113753 Bug ID: 113753 Summary: wrong code with _BitInt(129) multiplication and division at -O2 Product: gcc Version: 14.0 Status: UNCONFIRMED Keywords: wrong-code Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: zsojka at seznam dot cz CC: jakub at gcc dot gnu.org Target Milestone: --- Host: x86_64-pc-linux-gnu Target: x86_64-pc-linux-gnu Created attachment 57316 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57316=edit reduced testcase Output: $ x86_64-pc-linux-gnu-gcc -O2 testcase.c $ ./a.out Aborted The result of "u * m" does not fit into unsigned _BitInt(129), but at -O2, 'm' is returned. $ x86_64-pc-linux-gnu-gcc -v Using built-in specs. COLLECT_GCC=/repo/gcc-trunk/binary-latest-amd64/bin/x86_64-pc-linux-gnu-gcc COLLECT_LTO_WRAPPER=/repo/gcc-trunk/binary-trunk-r14-8779-20240203093135-gd436e8e70da-checking-yes-rtl-df-extra-nobootstrap-amd64/bin/../libexec/gcc/x86_64-pc-linux-gnu/14.0.1/lto-wrapper Target: x86_64-pc-linux-gnu Configured with: /repo/gcc-trunk//configure --enable-languages=c,c++ --enable-valgrind-annotations --disable-nls --enable-checking=yes,rtl,df,extra --disable-bootstrap --with-cloog --with-ppl --with-isl --build=x86_64-pc-linux-gnu --host=x86_64-pc-linux-gnu --target=x86_64-pc-linux-gnu --with-ld=/usr/bin/x86_64-pc-linux-gnu-ld --with-as=/usr/bin/x86_64-pc-linux-gnu-as --disable-libstdcxx-pch --prefix=/repo/gcc-trunk//binary-trunk-r14-8779-20240203093135-gd436e8e70da-checking-yes-rtl-df-extra-nobootstrap-amd64 Thread model: posix Supported LTO compression algorithms: zlib zstd gcc version 14.0.1 20240203 (experimental) (GCC)
[Bug target/113729] Missing APX NDD optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113729
--- Comment #2 from Hongtao Liu ---
extern unsigned char b;
int
foo (void)
{
return (unsigned char)(200 + b);
}
gcc -O2 -mapxf
foo():
subb $56, b(%rip), %al
movzbl %al, %eax
ret
And this can be optimzied to
foo():
subb $56, b(%rip), %al
ret
Note, if we want to optimize it in pass_combine, the pattern need to generate
explicit APX NDD instructions, since APX non-NDD will not clear upper bits.
[Bug target/113465] [mingw-w64] dllexported constexpr (inline) variables not automatically emitted
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113465 --- Comment #6 from Thiago Macieira --- Mind if I ask you reconsider the decision for inline variables (which all constexpr ones are)?
[Bug tree-optimization/113752] [14 Regression] warning: ‘%s’ directive writing up to 10218 bytes into a region of size between 0 and 10240 [-Wformat-overflow=]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113752
--- Comment #2 from H.J. Lu ---
[hjl@gnu-skx-1 gcc]$ cat /tmp/foo.i
char a[10256];
char b;
char *c, *g;
int d, e, f;
int sprintf(char *, char *, ...);
unsigned long strlen(char *);
int h(char *j) {
if (strlen(j) + strlen(c) + strlen(g) + 32 > 10256)
return 0;
sprintf(a, "%s:%s:%d:%d:%d:%c:%s\n", j, c, d, e, f, b, g);
return 1;
}
void i() { h("wctype"); }
[hjl@gnu-skx-1 gcc]$ ./xgcc -B./ -O3 -Wall -S /tmp/foo.i
/tmp/foo.i: In function ?i?:
/tmp/foo.i:10:33: warning: ?%s? directive writing up to 10218 bytes into a
region of size between 0 and 10240 [-Wformat-overflow=]
10 | sprintf(a, "%s:%s:%d:%d:%d:%c:%s\n", j, c, d, e, f, b, g);
| ^~
In function ?h?,
inlined from ?i? at /tmp/foo.i:13:12:
/tmp/foo.i:10:3: note: ?sprintf? output between 18 and 20484 bytes into a
destination of size 10256
10 | sprintf(a, "%s:%s:%d:%d:%d:%c:%s\n", j, c, d, e, f, b, g);
| ^
[hjl@gnu-skx-1 gcc]$
[Bug tree-optimization/113752] [14 Regression] warning: ‘%s’ directive writing up to 10218 bytes into a region of size between 0 and 10240 [-Wformat-overflow=]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113752 H.J. Lu changed: What|Removed |Added Ever confirmed|0 |1 Last reconfirmed||2024-02-04 CC||aldyh at redhat dot com Status|UNCONFIRMED |NEW --- Comment #1 from H.J. Lu --- It is caused by r14-261.
[Bug tree-optimization/113714] [11/12/13/14 Regression] Missed optimization for redundancy computation elimination: -(w+d-x)-x => -(w+d)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113714 Andrew Pinski changed: What|Removed |Added Known to fail|11.1.0 | --- Comment #2 from Andrew Pinski --- Hmm, for x86_64, it regressed in GCC 11 but for aarch64, it seems like it is only a regression on the trunk ...
[Bug tree-optimization/113714] [11/12/13/14 Regression] Missed optimization for redundancy computation elimination: -(w+d-x)-x => -(w+d)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113714 Andrew Pinski changed: What|Removed |Added Ever confirmed|0 |1 Last reconfirmed||2024-02-04 Target Milestone|--- |11.5 Keywords||needs-bisection Status|UNCONFIRMED |NEW --- Comment #1 from Andrew Pinski --- Confirmed.
[Bug c++/113746] [14 Regression] ICE: tree check: expected enumeral_type, have error_mark in tsubst_expr, at cp/pt.cc:21458 with missing typename
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113746 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever confirmed|0 |1 Last reconfirmed||2024-02-04 --- Comment #2 from Andrew Pinski --- .
[Bug tree-optimization/113752] [14 Regression] warning: ‘%s’ directive writing up to 10218 bytes into a region of size between 0 and 10240 [-Wformat-overflow=]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113752 Andrew Pinski changed: What|Removed |Added Keywords||needs-bisection, ||needs-reduction Target Milestone|--- |14.0
[Bug c/113752] New: [14 Regression] warning: ‘%s’ directive writing up to 10218 bytes into a region of size between 0 and 10240 [-Wformat-overflow=]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113752 Bug ID: 113752 Summary: [14 Regression] warning: ‘%s’ directive writing up to 10218 bytes into a region of size between 0 and 10240 [-Wformat-overflow=] Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: hjl.tools at gmail dot com Target Milestone: --- Created attachment 57315 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57315=edit A testcase [hjl@gnu-tgl-2 tmp]$ /usr/gcc-14.0.1-x32-apx/bin/gcc -O3 -S x.i -Wall In file included from tests-mbwc/tst_wctype.c:8: tests-mbwc/tsp_common.c: In function ‘result.constprop.isra’: tests-mbwc/tsp_common.c:55:24: warning: ‘%s’ directive writing up to 10218 bytes into a region of size between 0 and 10240 [-Wformat-overflow=] tests-mbwc/tsp_common.c:55:3: note: ‘sprintf’ output between 18 and 20484 bytes into a destination of size 10256 [hjl@gnu-tgl-2 tmp]$ GCC 13 is OK.
[Bug c++/113718] std::bit_cast making the compiler generate unnecessary code.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113718 Andrew Pinski changed: What|Removed |Added Ever confirmed|0 |1 Severity|normal |enhancement See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=102876, ||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=4131 Component|tree-optimization |c++ Last reconfirmed||2024-02-04 Status|UNCONFIRMED |NEW --- Comment #1 from Andrew Pinski --- void f(); static auto const p2 = __builtin_bit_cast(void(*)(), ()); Even causes the front-end to emit a dynamic initializer for p2. There is definitely 2 issues here, one for the above and one for the original code. Note bit_cast is not a const expression due to being a pointer type and that is what causes the front-end to emit dynamic initializer. But I wonder if the front-end could try to do it without the dynamic initializer. Anyways confirmed. Note there is another bug about converting dynamic initializers to static initializers (PR 4131 and PR 102876).
[Bug target/113751] -mapxf -mfma4 generates wrong assembly code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113751 Andrew Pinski changed: What|Removed |Added Last reconfirmed||2024-02-04 Ever confirmed|0 |1 Status|UNCONFIRMED |NEW --- Comment #2 from Andrew Pinski --- .
[Bug target/113744] Unnecessary "m" constraint in *adddi_4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113744 Hongtao Liu changed: What|Removed |Added CC||liuhongt at gcc dot gnu.org --- Comment #2 from Hongtao Liu --- 7018; For comparisons against 1, -1 and 128, we may generate better code 7019; by converting cmp to add, inc or dec as done by peephole2. This pattern 7020; is matched then. We can't accept general immediate, because for 7021; case of overflows, the result is messed up. 7022; Also carry flag is reversed compared to cmp, so this conversion is valid 7023; only for comparisons not depending on it. 7024 It sounds to me those peephole2 can be extended to memory operand since APX_NDD supports that. So it's not redudant m constraint in the pattern, but miss optimization in those peepholes.
[Bug target/113751] -mapxf -mfma4 generates wrong assembly code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113751 Hongyu Wang changed: What|Removed |Added CC||hongyuw at gcc dot gnu.org --- Comment #1 from Hongyu Wang --- We haven't disable AMD ISAs like XOP/FMA4 as it will not invoke with APX. Quoted from Richard's comment > We haven’t disabled EGPR for 3DNOW/XOP/LWP/FMA4/TBM instructions, as they will > be co-operated with -mapxf. We can disable EGPR for them if AMD guys requires. I think most of these are retired by now, so it's unlikely an implementation providing these and also APX will appear.
[Bug target/113729] Missing APX NDD optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113729
Hongtao Liu changed:
What|Removed |Added
CC||liuhongt at gcc dot gnu.org
--- Comment #1 from Hongtao Liu ---
At gimple level it's (int) b + 200, it's different from (int)(b +200) when
there's overflow, i.e. b = 200.
For
extern unsigned char b;
unsigned char
foo (void)
{
return 200 + b;
}
gcc already generate
sub al, BYTE PTR b[rip], 56
[Bug target/113751] New: -mapxf -mfma4 generates wrong assembly code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113751
Bug ID: 113751
Summary: -mapxf -mfma4 generates wrong assembly code
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: hjl.tools at gmail dot com
CC: crazylht at gmail dot com
Target Milestone: ---
Target: x86-64
[hjl@gnu-icx-1 creduce-1]$ cat x.i
struct {
double a[8]
} a;
double b, c, d;
int e, f, g;
void h() {
f = e;
d = a.a[g + 1];
c = a.a[g] + a.a[g + 3] * (a.a[g + 4] *
(a.a[g + 5] *
(a.a[g + 6] * (a.a[g + 7] * a.a[g + 8] + b;
d += e > a.a[g + 11];
}
[hjl@gnu-icx-1 creduce-1]$
/export/build/gnu/tools-build/gcc-x32-gitlab/release/usr/gcc-14.0.1-x32/bin/gcc
-O3 -mfma4 -mapxf x.i -w -c
/tmp/cchsm1V9.s: Assembler messages:
/tmp/cchsm1V9.s:38: Error: extended GPR cannot be used as base/index for
`vfmaddsd'
[hjl@gnu-icx-1 creduce-1]$
[Bug rtl-optimization/113723] switch (jump) tables don't get along with -freorder-blocks-and-partition on non-x86
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113723 Andrew Pinski changed: What|Removed |Added Last reconfirmed||2024-02-04 Ever confirmed|0 |1 Summary|-freorder-blocks-and-partit |switch (jump) tables don't |ion emits bogus asm |get along with |directives on aarch64 |-freorder-blocks-and-partit ||ion on non-x86 Status|UNCONFIRMED |NEW --- Comment #2 from Andrew Pinski --- x86 works via using .long: .long .L13-.L4 For x86 we get: (jump_table_data 18 17 19 (addr_diff_vec:SI (label_ref:DI 17) While on aarch64 we get incorrectly: (jump_table_data 12 11 13 (addr_diff_vec:QI (label_ref:DI 11) The shortening pass turns it into QI. But that is not the only issue.
[Bug target/113697] RISC-V: Redundant vsetvl insn in function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113697 Li Pan changed: What|Removed |Added Resolution|--- |FIXED Status|UNCONFIRMED |RESOLVED --- Comment #2 from Li Pan --- Fixed.
[Bug middle-end/113750] [14 Regression] ICE in vect building gcc/m2/gm2-libs/NumberIO.mod
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113750 --- Comment #1 from Iain Sandoe --- .. (gdb) p debug_tree(current_function_decl) > SI size unit-size align:32 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type 0xf5b5d008 arg-types chain chain chain pointer_to_this > addressable used public static DI ../../../../src/libgm2/libm2pim/../../gcc/m2/gm2-libs/NumberIO.mod:237:1 align:32 warn_if_not_align:0 context initial result VOID ../../../../src/libgm2/libm2pim/../../gcc/m2/gm2-libs/NumberIO.mod:270:1 align:8 warn_if_not_align:0 context > arguments unit-size align:32 warn_if_not_align:0 symtab:-172293664 alias-set 2 canonical-type 0xf5b50690 precision:32 min max pointer_to_this reference_to_this > used unsigned SI ../../../../src/libgm2/libm2pim/../../gcc/m2/gm2-libs/NumberIO.mod:232:21 size unit-size align:32 warn_if_not_align:0 context arg-type chain used unsigned SI ../../../../src/libgm2/libm2pim/../../gcc/m2/gm2-libs/NumberIO.mod:232:24 size unit-size align:32 warn_if_not_align:0 context arg-type chain >> struct-function 0xf5bd0730 chain > $1 = void (gdb) p debug_tree(current_function_decl->function_decl.saved_tree) $2 = void
[Bug tree-optimization/113725] [14 Regression] ICE during GIMPLE pass: cunroll since r14-8683
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113725 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever confirmed|0 |1 Last reconfirmed||2024-02-03 --- Comment #1 from Andrew Pinski --- Confirmed. Keeping eliminated stmt live as copy because of out-of-region uses
[Bug tree-optimization/113588] [14 Regression] The vectorizer is introducing out-of-bounds memory access
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113588 Sam James changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #7 from Sam James --- done, I think
[Bug middle-end/26163] [meta-bug] missed optimization in SPEC (2k17, 2k and 2k6 and 95)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=26163 Bug 26163 depends on bug 113588, which changed state. Bug 113588 Summary: [14 Regression] The vectorizer is introducing out-of-bounds memory access https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113588 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED
[Bug tree-optimization/113467] [14 regression] libgcrypt-1.10.3 is miscompiled
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113467 Sam James changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #31 from Sam James --- .
[Bug c++/113746] [14 Regression] ICE: tree check: expected enumeral_type, have error_mark in tsubst_expr, at cp/pt.cc:21458 with missing typename
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113746 Andrew Pinski changed: What|Removed |Added Target Milestone|--- |14.0 Keywords||needs-bisection --- Comment #1 from Andrew Pinski --- I am not sure if this is a regression ...
[Bug middle-end/113734] [14 regression] libarchive miscompiled (fails libarchive_test_read_format_rar5_extra_field_version test) since r14-8768-g85094e2aa6dba7
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113734 Andrew Pinski changed: What|Removed |Added Last reconfirmed||2024-02-03 Target Milestone|--- |14.0 Ever confirmed|0 |1 Status|UNCONFIRMED |ASSIGNED --- Comment #3 from Andrew Pinski --- From https://gcc.gnu.org/pipermail/gcc-patches/2024-February/644888.html ``` FAIL: libgomp.fortran/non-rectangular-loop-1.f90 -O1 execution test ``` Maybe that failure is the same issue as this one too.
[Bug middle-end/113738] [14 Regression] ICE: in df_reg_chain_verify_unmarked, at df-scan.cc:4001 with -O2 -march=rv64gcv
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113738 --- Comment #1 from Andrew Pinski --- Note this only shows up with DF checking ...
[Bug middle-end/113738] [14 Regression] ICE: in df_reg_chain_verify_unmarked, at df-scan.cc:4001 with -O2 -march=rv64gcv
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113738 Andrew Pinski changed: What|Removed |Added CC||pinskia at gcc dot gnu.org Target Milestone|--- |14.0 Component|target |middle-end
[Bug middle-end/113750] [14 Regression] ICE in vect building gcc/m2/gm2-libs/NumberIO.mod
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113750 Andrew Pinski changed: What|Removed |Added CC||pinskia at gcc dot gnu.org Target Milestone|--- |14.0
[Bug middle-end/113750] New: [14 Regression] ICE in vect building gcc/m2/gm2-libs/NumberIO.mod
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113750 Bug ID: 113750 Summary: [14 Regression] ICE in vect building gcc/m2/gm2-libs/NumberIO.mod Product: gcc Version: 14.0 Status: UNCONFIRMED Keywords: ice-on-valid-code Severity: normal Priority: P3 Component: middle-end Assignee: unassigned at gcc dot gnu.org Reporter: iains at gcc dot gnu.org Target Milestone: --- Host: aarch64-linux Target: aarch64-linux This is on cfarm185 (aarch64-linux) with a compiler configured: ../src/configure --prefix=... --enable-languages=all -save-temps is not giving me any intermediate and fdump-tree-gimple gives no output, will have figure out how to reduce this. /home/iains/gcc-master/bld/./gcc/cc1gm2 -v -iprefix /home/iains/gcc-master/bld/gcc/../lib/gcc/aarch64-unknown-linux-gnu/14.0.1/ -isystem /home/iains/gcc-master/bld/./gcc/include -isystem /home/iains/gcc-master/bld/./gcc/include-fixed -B /home/iains/gcc-master/bld/./gcc/ -save-temps -quiet -dumpdir .libs/ -dumpbase NumberIO.mod -dumpbase-ext .mod -mlittle-endian -mabi=lp64 -g -g -g -O2 -O2 -Wcase-enum -Wreturn-type -version -fm2-g -fcase -fm2-prefix=m2pim -fPIC -fdump-tree-gimple -fm2-pathname=m2pim -fm2-pathnameI. -fm2-pathnameI/home/iains/gcc-master/src/gcc/m2/gm2-libs -fm2-pathname=m2iso -fm2-pathnameI/home/iains/gcc-master/src/gcc/m2/gm2-libs-iso -fscaffold-dynamic -flibs=m2cor,m2log,m2pim,m2iso -fm2-pathname=m2pim -fm2-pathnameI. -fm2-pathnameI/home/iains/gcc-master/src/gcc/m2/gm2-libs -fm2-pathname=m2iso -fm2-pathnameI/home/iains/gcc-master/src/gcc/m2/gm2-libs-iso ../../../../src/libgm2/libm2pim/../../gcc/m2/gm2-libs/NumberIO.mod -c -o .libs/NumberIO.s GNU Modula-2 (GCC) version 14.0.1 20240203 (experimental) [master revision r14-8771-g4b7d4d8a4af7] (aarch64-unknown-linux-gnu) compiled by GNU C version 14.0.1 20240203 (experimental) [master revision r14-8771-g4b7d4d8a4af7], GMP version 6.1.2, MPFR version 3.1.6-p2, MPC version 1.1.0, isl version none GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096 Compiling: ../../../../src/libgm2/libm2pim/../../gcc/m2/gm2-libs/NumberIO.mod ../../../../src/libgm2/libm2pim/../../gcc/m2/gm2-libs/NumberIO.mod: In function ‘m2pim_NumberIO_HexToStr’: ../../../../src/libgm2/libm2pim/../../gcc/m2/gm2-libs/NumberIO.mod:237:1: error: label ‘.L873’ in the middle of basic block 3 237 | BEGIN | ^ during GIMPLE pass: vect ../../../../src/libgm2/libm2pim/../../gcc/m2/gm2-libs/NumberIO.mod:237:1: internal compiler error: verify_flow_info failed 0x91900b verify_flow_info() ../../src/gcc/cfghooks.cc:287 0xf0a15f checking_verify_flow_info() ../../src/gcc/cfghooks.h:214 0xf0a15f cleanup_tree_cfg_noloop ../../src/gcc/tree-cfgcleanup.cc:1154 0xf0a15f cleanup_tree_cfg(unsigned int) ../../src/gcc/tree-cfgcleanup.cc:1205 0xd8737b execute_function_todo ../../src/gcc/passes.cc:2057 0xd879ab execute_todo ../../src/gcc/passes.cc:2142
[Bug c++/111923] default argument is not treated as a complete-class context of a class
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111923 Jens Maurer changed: What|Removed |Added CC||jens.maurer at gmx dot net --- Comment #12 from Jens Maurer --- In general, we want to be rather careful that the layout of the non-static data members of a class cannot depend on properties of other non-static data members that are visible due to some "complete class" rules. Otherwise, it's way too easy to construct cycles.
[Bug tree-optimization/96245] Failure to optimize arithmetic pattern in switch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96245 Andrew Pinski changed: What|Removed |Added CC||b.buschinski at googlemail dot com --- Comment #12 from Andrew Pinski --- *** Bug 113741 has been marked as a duplicate of this bug. ***
[Bug tree-optimization/113741] missed optimization switch transformation to same function call
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113741 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #3 from Andrew Pinski --- Dup of bug 96245. *** This bug has been marked as a duplicate of bug 96245 ***
[Bug middle-end/113722] [14 Regression] Constant folding of __builtin_bswap128 is broken since r14-1455
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113722 Jakub Jelinek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #6 from Jakub Jelinek --- Fixed.
[Bug c++/113710] [14 Regression] g++.dg/modules/hello-1 ICE: canonical types differ for identical types since r14-8710-g65b4cba9d6a9ff
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113710 Andrew Pinski changed: What|Removed |Added CC||danglin at gcc dot gnu.org --- Comment #4 from Andrew Pinski --- *** Bug 113743 has been marked as a duplicate of this bug. ***
[Bug libstdc++/113743] [14 Regression] FAIL: g++.dg/modules/hello-1_b.C -std=c++17 (test for excess errors)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113743 Andrew Pinski changed: What|Removed |Added Resolution|--- |DUPLICATE Status|UNCONFIRMED |RESOLVED --- Comment #3 from Andrew Pinski --- It is the same bug, libstdc++ header changes exposed a latent bug in the C++ Modules support. *** This bug has been marked as a duplicate of bug 113710 ***
[Bug libstdc++/113743] [14 Regression] FAIL: g++.dg/modules/hello-1_b.C -std=c++17 (test for excess errors)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113743 Andrew Pinski changed: What|Removed |Added See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=113710 --- Comment #2 from Andrew Pinski --- Different error message from PR 113710 but I suspect it is the same bug ...
[Bug c/113727] csmith: differences from nothing to -O1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113727
--- Comment #12 from Xi Ruoyao ---
(In reply to David Binderman from comment #11)
> Created attachment 57310 [details]
> C source code
static uint32_t (safe_mul_func_uint32_t_u_u)(uint32_t ui1, uint32_t ui2 ) {
}
This thing is UB if you use its return value (in C; in C++ it will be an UB
even if the return value is not used).
Better adding -Werror=return-type to cvise.
[Bug c++/113748] GCC rejects valid program involving befriending class with name same as typedef
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113748 Andrew Pinski changed: What|Removed |Added See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=21498 --- Comment #1 from Andrew Pinski --- >This should be valid because `friend class C;` befriend a global class named >`C`. Hmm, see PR 21498 ...
[Bug modula2/113749] New: [14 Regression] m2 enabled build times out on i686-gnu (GNU Hurd)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113749 Bug ID: 113749 Summary: [14 Regression] m2 enabled build times out on i686-gnu (GNU Hurd) Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: modula2 Assignee: gaius at gcc dot gnu.org Reporter: doko at gcc dot gnu.org Target Milestone: --- seen with trunk, works with the gcc-13 branch on i686-gnu: [...] test -d m2/gm2-libs-boot || /bin/bash ../../src/gcc/../mkinstalldirs m2/gm2-libs-boot m2/boot-bin/mc --olang=c++ --h-file-prefix=G -I../../src/gcc/m2/gm2-libs -I../../src/gcc/m2/gm2-comp iler -I../../src/gcc/m2/gm2-libiberty -I../../src/gcc/m2/gm2-gcc --quiet --gcc-config-system -o=m2/ gm2-libs-boot/GASCII.h ../../src/gcc/m2/gm2-libs/ASCII.def E: Build killed with signal TERM after 180 minutes of inactivity
[Bug fortran/109358] Wrong formatting with T-descriptor during stream output
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109358 Jerry DeLisle changed: What|Removed |Added CC||nmm1 at cam dot ac.uk --- Comment #8 from Jerry DeLisle --- *** Bug 53962 has been marked as a duplicate of this bug. ***
[Bug libfortran/53962] Tab handling with formatted stream output
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53962 Jerry DeLisle changed: What|Removed |Added Resolution|--- |DUPLICATE Status|ASSIGNED|RESOLVED --- Comment #5 from Jerry DeLisle --- Marking this as a duplicate and will roll the test case here into PR109358 as I work it shortly. *** This bug has been marked as a duplicate of bug 109358 ***
[Bug libfortran/111022] ES0.0E0 format gave ES0.dE0 output with d too high.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111022 --- Comment #29 from GCC Commits --- The master branch has been updated by Jerry DeLisle : https://gcc.gnu.org/g:d436e8e70dacd9c06247bb56d0abeded8fcb4242 commit r14-8779-gd436e8e70dacd9c06247bb56d0abeded8fcb4242 Author: Jerry DeLisle Date: Fri Feb 2 18:12:33 2024 -0800 libgfortran: EN0.0E0 and ES0.0E0 format editing. F2018 and F2023 standards added zero width exponents. This required additional special handing in the process of building formatted floating point strings. G formatting uses either F or E formatting as documented in write_float.def comments. This logic changes the format token from FMT_G to FMT_F or FMT_E. The new formatting requirements interfere with this process when a FMT_G float string is being built. To avoid this, a new component called 'pushed' is added to the fnode structure to save this condition. The 'pushed' condition is then used to bypass portions of the new ES,E,EN, and D formatting, falling through to the existing default formatting which is retained. libgfortran/ChangeLog: PR libfortran/111022 * io/format.c (get_fnode): Update initialization of fnode. (parse_format_list): Initialization. * io/format.h (struct fnode): Added the new 'pushed' component. * io/write.c (select_buffer): Whitespace. (write_real): Whitespace. (write_real_w0): Adjust logic for the d == 0 condition. * io/write_float.def (determine_precision): Whitespace. (build_float_string): Calculate width of ..E0 exponents and adjust logic accordingly. (build_infnan_string): Whitespace. (CALCULATE_EXP): Whitespace. (quadmath_snprintf): Whitespace. (determine_en_precision): Whitespace. gcc/testsuite/ChangeLog: PR libfortran/111022 * gfortran.dg/fmt_error_10.f: Show D+0 exponent. * gfortran.dg/pr96436_4.f90: Show E+0 exponent. * gfortran.dg/pr96436_5.f90: Show E+0 exponent. * gfortran.dg/pr111022.f90: New test.
[Bug libstdc++/113743] [14 Regression] FAIL: g++.dg/modules/hello-1_b.C -std=c++17 (test for excess errors)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113743 --- Comment #1 from John David Anglin --- revision r14-8702-g314cbfe2980 was okay.
[Bug c++/113748] New: GCC rejects valid program involving befriending class with name same as typedef
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113748
Bug ID: 113748
Summary: GCC rejects valid program involving befriending class
with name same as typedef
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: jlame646 at gmail dot com
Target Milestone: ---
The following program is rejected by gcc and clang.
https://godbolt.org/z/3K31ev4YT
```
#include
#include
class A {
};
class B {
using C = A;
friend class C; //gcc and clang rejects this but msvc accepts
};
```
GCC says:
```
:11:18: error: using typedef-name 'using B::C = class A' after 'class'
11 | friend class C; //gcc and clang rejects this but msvc accepts
| ^
:8:11: note: 'using B::C = class A' has a previous declaration here
8 | using C = A;
| ^
:11:5: error: friend declaration does not name a class or function
11 | friend class C; //gcc and clang rejects this but msvc accepts
| ^~
Compiler returned: 1
```
This should be valid because `friend class C;` befriend a global class named
`C`.
[Bug libstdc++/113745] Poor diagnostics quality for resize() without a default-constructible type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113745 Jonathan Wakely changed: What|Removed |Added Last reconfirmed||2024-02-03 Ever confirmed|0 |1 Component|c++ |libstdc++ Status|UNCONFIRMED |NEW --- Comment #1 from Jonathan Wakely --- (In reply to Jan Schultke from comment #0) > Maybe we could add a static_assert to resize() which informs the user about > the issue more concisely. That's not possible in general, because there is no trait for Cpp17DefaultInsertable. It involves a call to allocator_traits::construct which is not constrained, so checking it always succeeds. For std::allocator we can use is_default_constructible. Slightly more generally, we can detect whether A::construct exists, because if it doesn't then we know that the default definition of allocator_traits::construct will be used, and we know what that does (because program-defined specializations of allocator_traits are forbidden). So we can use is_default_constructible in that case too. I think this should be component=libstdc++.
[Bug tree-optimization/113747] New: ICE: SIGSEGV in non_type_check (tree.h:3822) with -fopenacc --param=openacc-kernels=decompose on invalid code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113747 Bug ID: 113747 Summary: ICE: SIGSEGV in non_type_check (tree.h:3822) with -fopenacc --param=openacc-kernels=decompose on invalid code Product: gcc Version: 14.0 Status: UNCONFIRMED Keywords: ice-on-invalid-code Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: zsojka at seznam dot cz Target Milestone: --- Host: x86_64-pc-linux-gnu Target: x86_64-pc-linux-gnu Created attachment 57314 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57314=edit reduced testcase Compiler output: $ x86_64-pc-linux-gnu-gcc -fopenacc --param=openacc-kernels=decompose testcase.C -wrapper valgrind,-q testcase.C: In function 'void foo()': testcase.C:6:5: error: 'a' was not declared in this scope 6 | a[i] = i; | ^ ==6033== Invalid read of size 2 ==6033==at 0x1661F2C: non_type_check (tree.h:3822) ==6033==by 0x1661F2C: fixup_remapped_decl(tree_node*, omp_context*, bool) (omp-low.cc:907) ==6033==by 0x1668AAC: scan_sharing_clauses(tree_node*, omp_context*) (omp-low.cc:1919) ==6033==by 0x166A107: scan_omp_target(gomp_target*, omp_context*) (omp-low.cc:3120) ==6033==by 0x166AFF1: scan_omp_1_stmt(gimple_stmt_iterator*, bool*, walk_stmt_info*) (omp-low.cc:4230) ==6033==by 0x149A9CA: walk_gimple_stmt(gimple_stmt_iterator*, tree_node* (*)(gimple_stmt_iterator*, bool*, walk_stmt_info*), tree_node* (*)(tree_node**, int*, void*), walk_stmt_info*) (gimple-walk.cc:618) ==6033==by 0x149ABAD: walk_gimple_seq_mod(gimple**, tree_node* (*)(gimple_stmt_iterator*, bool*, walk_stmt_info*), tree_node* (*)(tree_node**, int*, void*), walk_stmt_info*) (gimple-walk.cc:51) ==6033==by 0x149AA81: walk_gimple_stmt(gimple_stmt_iterator*, tree_node* (*)(gimple_stmt_iterator*, bool*, walk_stmt_info*), tree_node* (*)(tree_node**, int*, void*), walk_stmt_info*) (gimple-walk.cc:735) ==6033==by 0x149ABAD: walk_gimple_seq_mod(gimple**, tree_node* (*)(gimple_stmt_iterator*, bool*, walk_stmt_info*), tree_node* (*)(tree_node**, int*, void*), walk_stmt_info*) (gimple-walk.cc:51) ==6033==by 0x149AAC1: walk_gimple_stmt(gimple_stmt_iterator*, tree_node* (*)(gimple_stmt_iterator*, bool*, walk_stmt_info*), tree_node* (*)(tree_node**, int*, void*), walk_stmt_info*) (gimple-walk.cc:681) ==6033==by 0x149ABAD: walk_gimple_seq_mod(gimple**, tree_node* (*)(gimple_stmt_iterator*, bool*, walk_stmt_info*), tree_node* (*)(tree_node**, int*, void*), walk_stmt_info*) (gimple-walk.cc:51) ==6033==by 0x166A145: scan_omp (omp-low.cc:4284) ==6033==by 0x166A145: scan_omp_target(gomp_target*, omp_context*) (omp-low.cc:3121) ==6033==by 0x166AEE0: scan_omp_1_stmt(gimple_stmt_iterator*, bool*, walk_stmt_info*) (omp-low.cc:4234) ==6033== Address 0x0 is not stack'd, malloc'd or (recently) free'd ==6033== during GIMPLE pass: omplower testcase.C:4:9: internal compiler error: Segmentation fault 4 | #pragma acc kernels | ^~~ 0x1816b62 crash_signal /repo/gcc-trunk/gcc/toplev.cc:317 $ x86_64-pc-linux-gnu-gcc -v Using built-in specs. COLLECT_GCC=/repo/gcc-trunk/binary-latest-amd64/bin/x86_64-pc-linux-gnu-gcc COLLECT_LTO_WRAPPER=/repo/gcc-trunk/binary-trunk-r14-8771-20240203001826-g4b7d4d8a4af-checking-yes-rtl-df-extra-amd64/bin/../libexec/gcc/x86_64-pc-linux-gnu/14.0.1/lto-wrapper Target: x86_64-pc-linux-gnu Configured with: /repo/gcc-trunk//configure --enable-languages=c,c++ --enable-valgrind-annotations --disable-nls --enable-checking=yes,rtl,df,extra --with-cloog --with-ppl --with-isl --build=x86_64-pc-linux-gnu --host=x86_64-pc-linux-gnu --target=x86_64-pc-linux-gnu --with-ld=/usr/bin/x86_64-pc-linux-gnu-ld --with-as=/usr/bin/x86_64-pc-linux-gnu-as --disable-libstdcxx-pch --prefix=/repo/gcc-trunk//binary-trunk-r14-8771-20240203001826-g4b7d4d8a4af-checking-yes-rtl-df-extra-amd64 Thread model: posix Supported LTO compression algorithms: zlib zstd gcc version 14.0.1 20240203 (experimental) (GCC)
[Bug target/59778] FAIL: gcc.dg/atomic/c11-atomic-exec-5.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59778 John David Anglin changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #6 from John David Anglin --- Fixed on trunk.
[Bug c++/113746] New: [14 Regression] ICE: tree check: expected enumeral_type, have error_mark in tsubst_expr, at cp/pt.cc:21458 with missing typename
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113746
Bug ID: 113746
Summary: [14 Regression] ICE: tree check: expected
enumeral_type, have error_mark in tsubst_expr, at
cp/pt.cc:21458 with missing typename
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Keywords: ice-on-invalid-code
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: zsojka at seznam dot cz
Target Milestone: ---
Host: x86_64-pc-linux-gnu
Target: x86_64-pc-linux-gnu
Created attachment 57313
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57313=edit
reduced testcase
Compiler output:
$ x86_64-pc-linux-gnu-gcc testcase.C -wrapper valgrind,-q
testcase.C:1:12: error: 'typename_T' has not been declared
1 | template < typename_T > struct S {
|^~
testcase.C:2:24: internal compiler error: tree check: expected enumeral_type,
have error_mark in tsubst_expr, at cp/pt.cc:21458
2 | enum { e0 = 0, e00 = e0 };
|^~
0x96eab7 tree_check_failed(tree_node const*, char const*, int, char const*,
...)
/repo/gcc-trunk/gcc/tree.cc:8952
==27631== Invalid read of size 1
==27631==at 0x2DF67C0: x86_64_fallback_frame_state (md-unwind-support.h:63)
==27631==by 0x2DF67C0: uw_frame_state_for (unwind-dw2.c:1013)
==27631==by 0x2DF7AFD: _Unwind_Backtrace (unwind.inc:303)
==27631==by 0x2DA0F49: backtrace_full (backtrace.c:127)
==27631==by 0x2D03556:
diagnostic_context::action_after_output(diagnostic_t) (diagnostic.cc:781)
==27631==by 0x2D0376B: diagnostic_action_after_output (diagnostic.h:1002)
==27631==by 0x2D0376B:
diagnostic_context::report_diagnostic(diagnostic_info*) (diagnostic.cc:1633)
==27631==by 0x2D03AE8: diagnostic_impl(rich_location*, diagnostic_metadata
const*, int, char const*, __va_list_tag (*) [1], diagnostic_t)
(diagnostic.cc:1767)
==27631==by 0x2D041B6: internal_error(char const*, ...)
(diagnostic.cc:2225)
==27631==by 0x96EAB7: tree_check_failed(tree_node const*, char const*, int,
char const*, ...) (tree.cc:8952)
==27631== Address 0x1 is not stack'd, malloc'd or (recently) free'd
==27631==
testcase.C:2:24: internal compiler error: Segmentation fault
0x1816b62 crash_signal
/repo/gcc-trunk/gcc/toplev.cc:317
0x2df67c0 x86_64_fallback_frame_state
./md-unwind-support.h:63
0x2df67c0 uw_frame_state_for
/repo/gcc-trunk/libgcc/unwind-dw2.c:1013
0x2df7afd _Unwind_Backtrace
/repo/gcc-trunk/libgcc/unwind.inc:303
0x2da0f49 backtrace_full
/repo/gcc-trunk/libbacktrace/backtrace.c:127
0x2d03556 diagnostic_context::action_after_output(diagnostic_t)
/repo/gcc-trunk/gcc/diagnostic.cc:781
0x2d0376b diagnostic_action_after_output(diagnostic_context*, diagnostic_t)
/repo/gcc-trunk/gcc/diagnostic.h:1002
0x2d0376b diagnostic_context::report_diagnostic(diagnostic_info*)
/repo/gcc-trunk/gcc/diagnostic.cc:1633
0x2d03ae8 diagnostic_impl
/repo/gcc-trunk/gcc/diagnostic.cc:1767
0x2d041b6 internal_error(char const*, ...)
/repo/gcc-trunk/gcc/diagnostic.cc:2225
0x96eab7 tree_check_failed(tree_node const*, char const*, int, char const*,
...)
/repo/gcc-trunk/gcc/tree.cc:8952
$ x86_64-pc-linux-gnu-gcc -v
Using built-in specs.
COLLECT_GCC=/repo/gcc-trunk/binary-latest-amd64/bin/x86_64-pc-linux-gnu-gcc
COLLECT_LTO_WRAPPER=/repo/gcc-trunk/binary-trunk-r14-8771-20240203001826-g4b7d4d8a4af-checking-yes-rtl-df-extra-amd64/bin/../libexec/gcc/x86_64-pc-linux-gnu/14.0.1/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /repo/gcc-trunk//configure --enable-languages=c,c++
--enable-valgrind-annotations --disable-nls --enable-checking=yes,rtl,df,extra
--with-cloog --with-ppl --with-isl --build=x86_64-pc-linux-gnu
--host=x86_64-pc-linux-gnu --target=x86_64-pc-linux-gnu
--with-ld=/usr/bin/x86_64-pc-linux-gnu-ld
--with-as=/usr/bin/x86_64-pc-linux-gnu-as --disable-libstdcxx-pch
--prefix=/repo/gcc-trunk//binary-trunk-r14-8771-20240203001826-g4b7d4d8a4af-checking-yes-rtl-df-extra-amd64
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 14.0.1 20240203 (experimental) (GCC)
[Bug target/59778] FAIL: gcc.dg/atomic/c11-atomic-exec-5.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59778 --- Comment #5 from GCC Commits --- The master branch has been updated by John David Anglin : https://gcc.gnu.org/g:266354012e0aa42e0d1639ee7708595f316cc36b commit r14-8778-g266354012e0aa42e0d1639ee7708595f316cc36b Author: John David Anglin Date: Sat Feb 3 15:43:00 2024 + libatomic: Provide FPU exception defines for __hppa__ The exception defines in do not match the exception bits in the FPU status register on hppa-linux and hppa64-hpux11.11. On linux, they match the trap enable bits. On 64-bit hpux, they match the exception bits for IA64. The IA64 bits are in a different order and location than HPPA. HP uses table look ups to reorder the bits in code to test and raise exceptions. All the architectures that I looked at just pass the FPU status register to __atomic_feraiseexcept(). The simplest approach for hppa is to define FE_INEXACT, etc, to match the status register and not include .. 2024-02-03 John David Anglin libatomic/ChangeLog: PR target/59778 * configure.tgt (hppa*): Set ARCH. * config/pa/fenv.c: New file.
[Bug target/113711] APX instruction set and instructions longer than 15 bytes (assembly warning)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113711
--- Comment #9 from H.J. Lu ---
Many NDD patterns have the same issue. Here is another testcase:
[hjl@gnu-cfl-3 pr113711]$ cat apx-ndd-length-X.c
/* { dg-do assemble { target { apxf && { ! ia32 } } } } */
/* { dg-options "-mapxf -O2" } */
typedef signed __int128 S;
int o;
S
qux (void)
{
S z;
o = __builtin_add_overflow (*(S __seg_fs *) 0x1000, 0x200, );
return z;
}
[hjl@gnu-cfl-3 pr113711]$ make apx-ndd-length-X.o
/export/build/gnu/tools-build/gcc-gitlab-debug/build-x86_64-linux/gcc/xgcc
-B/export/build/gnu/tools-build/gcc-gitlab-debug/build-x86_64-linux/gcc/ -mapxf
-O3 -dp -c -o apx-ndd-length-X.o apx-ndd-length-X.c
/tmp/cc1eMHh5.s: Assembler messages:
/tmp/cc1eMHh5.s:9: Warning: instruction length of 16 bytes exceeds the limit of
15
[hjl@gnu-cfl-3 pr113711]$ cat apx-ndd-length-Y.c
/* { dg-do assemble { target { apxf && { ! ia32 } } } } */
/* { dg-options "-mapxf -O2" } */
__thread signed __int128 var;
int o;
signed __int128
qux (void)
{
signed __int128 z;
o = __builtin_add_overflow (var, 0x200, );
return z;
}
[hjl@gnu-cfl-3 pr113711]$ make apx-ndd-length-Y.o
/export/build/gnu/tools-build/gcc-gitlab-debug/build-x86_64-linux/gcc/xgcc
-B/export/build/gnu/tools-build/gcc-gitlab-debug/build-x86_64-linux/gcc/ -mapxf
-O3 -dp -c -o apx-ndd-length-Y.o apx-ndd-length-Y.c
/tmp/ccwvDbZA.s: Assembler messages:
/tmp/ccwvDbZA.s:9: Warning: instruction length of 16 bytes exceeds the limit of
15
[hjl@gnu-cfl-3 pr113711]$
We need to exam all NDD patterns to check invalid memory constraint.
We should find a testcase for each issue we find.
[Bug c++/113745] New: Poor diagnostics quality for resize() without a default-constructible type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113745
Bug ID: 113745
Summary: Poor diagnostics quality for resize() without a
default-constructible type
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: janschultke at googlemail dot com
Target Milestone: ---
## Code to reproduce (https://godbolt.org/z/6ETnffr8c)
#include
struct non_default_constructible {
non_default_constructible(int) {}
};
int main() {
std::vector v;
v.resize(0);
}
## Diagnostic
In file included from
/opt/compiler-explorer/gcc-trunk-20240203/include/c++/14.0.1/bits/stl_iterator.h:78,
from
/opt/compiler-explorer/gcc-trunk-20240203/include/c++/14.0.1/bits/stl_algobase.h:67,
from
/opt/compiler-explorer/gcc-trunk-20240203/include/c++/14.0.1/vector:62,
from :1:
/opt/compiler-explorer/gcc-trunk-20240203/include/c++/14.0.1/bits/stl_construct.h:
In instantiation of 'constexpr void std::_Construct(_Tp*, _Args&& ...) [with
_Tp = non_default_constructible; _Args = {}]':
/opt/compiler-explorer/gcc-trunk-20240203/include/c++/14.0.1/bits/stl_uninitialized.h:643:18:
required from 'static constexpr _ForwardIterator
std::__uninitialized_default_n_1<_TrivialValueType>::__uninit_default_n(_ForwardIterator,
_Size) [with _ForwardIterator = non_default_constructible*; _Size = long
unsigned int; bool _TrivialValueType = false]'
643 | std::_Construct(std::__addressof(*__cur));
| ~~~^~
/opt/compiler-explorer/gcc-trunk-20240203/include/c++/14.0.1/bits/stl_uninitialized.h:701:22:
required from 'constexpr _ForwardIterator
std::__uninitialized_default_n(_ForwardIterator, _Size) [with _ForwardIterator
= non_default_constructible*; _Size = long unsigned int]'
700 | return __uninitialized_default_n_1::
|
701 | __uninit_default_n(__first, __n);
| ~~^~
/opt/compiler-explorer/gcc-trunk-20240203/include/c++/14.0.1/bits/stl_uninitialized.h:779:44:
required from 'constexpr _ForwardIterator
std::__uninitialized_default_n_a(_ForwardIterator, _Size, allocator<_Tp>&)
[with _ForwardIterator = non_default_constructible*; _Size = long unsigned int;
_Tp = non_default_constructible]'
779 | { return std::__uninitialized_default_n(__first, __n); }
| ~~^~
/opt/compiler-explorer/gcc-trunk-20240203/include/c++/14.0.1/bits/vector.tcc:821:35:
required from 'constexpr void std::vector<_Tp,
_Alloc>::_M_default_append(size_type) [with _Tp = non_default_constructible;
_Alloc = std::allocator; size_type = long unsigned
int]'
821 |
std::__uninitialized_default_n_a(this->_M_impl._M_finish,
|
^
822 | __n,
_M_get_Tp_allocator());
|
~~~
/opt/compiler-explorer/gcc-trunk-20240203/include/c++/14.0.1/bits/stl_vector.h:1013:4:
required from 'constexpr void std::vector<_Tp, _Alloc>::resize(size_type)
[with _Tp = non_default_constructible; _Alloc =
std::allocator; size_type = long unsigned int]'
1013 | _M_default_append(__new_size - size());
| ^
:9:13: required from here
9 | v.resize(0);
| ~~~~^~~
/opt/compiler-explorer/gcc-trunk-20240203/include/c++/14.0.1/bits/stl_construct.h:115:28:
error: no matching function for call to
'construct_at(non_default_constructible*&)'
115 | std::construct_at(__p, std::forward<_Args>(__args)...);
| ~^~~~~
/opt/compiler-explorer/gcc-trunk-20240203/include/c++/14.0.1/bits/stl_construct.h:94:5:
note: candidate: 'template constexpr decltype
(::new(void*(0)) _Tp) std::construct_at(_Tp*, _Args&& ...)'
94 | construct_at(_Tp* __location, _Args&&... __args)
| ^~~~
/opt/compiler-explorer/gcc-trunk-20240203/include/c++/14.0.1/bits/stl_construct.h:94:5:
note: template argument deduction/substitution failed:
/opt/compiler-explorer/gcc-trunk-20240203/include/c++/14.0.1/bits/stl_construct.h:
In substitution of 'template constexpr decltype
(::new(void*(0)) _Tp) std::construct_at(_Tp*, _Args&& ...) [with _Tp =
non_default_constructible; _Args = {}]':
/opt/compiler-explorer/gcc-trunk-20240203/include/c++/14.0.1/bits/stl_construct.h:115:21:
required from 'constexpr void std::_Construct(_Tp*, _Args&& ...) [with _Tp =
non_default_constructibl
[Bug target/113744] Unnecessary "m" constraint in *adddi_4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113744 --- Comment #1 from H.J. Lu --- Other *add patterns may have the same issue.
[Bug target/113744] New: Unnecessary "m" constraint in *adddi_4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113744 Bug ID: 113744 Summary: Unnecessary "m" constraint in *adddi_4 Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: hjl.tools at gmail dot com CC: crazylht at gmail dot com, hongyuw at gcc dot gnu.org, lingling.kong7 at gmail dot com Target Milestone: --- commit 7abcef725e40589553a079df9258ae094b811751 Author: Kong Lingling Date: Wed Jan 18 17:23:29 2023 +0800 [APX NDD] Support APX NDD for optimization patterns of add has @@ -6994,31 +7021,35 @@ (define_insn "*addsi_3_zext" (define_insn "*adddi_4" [(set (reg FLAGS_REG) (compare -(match_operand:DI 1 "nonimmediate_operand" "0") -(match_operand:DI 2 "x86_64_immediate_operand" "e"))) - (clobber (match_scratch:DI 0 "=r"))] +(match_operand:DI 1 "nonimmediate_operand" "0,rm") +(match_operand:DI 2 "x86_64_immediate_operand" "e,e"))) + (clobber (match_scratch:DI 0 "=r,r"))] "TARGET_64BIT && ix86_match_ccmode (insn, CCGCmode)" But peephole which generates *adddi_4 only supports register as operand 2.
[Bug libstdc++/113743] New: [14 Regression] FAIL: g++.dg/modules/hello-1_b.C -std=c++17 (test for excess errors)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113743 Bug ID: 113743 Summary: [14 Regression] FAIL: g++.dg/modules/hello-1_b.C -std=c++17 (test for excess errors) Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: danglin at gcc dot gnu.org Target Milestone: --- Host: hppa64-hp-hpux11.11 Target: hppa64-hp-hpux11.11 Build: hppa64-hp-hpux11.11 spawn -ignore SIGHUP /home/dave/gnu/gcc/objdir64/gcc/testsuite/g++1/../../xg++ -B/home/dave/gnu/gcc/objdir64/gcc/testsuite/g++1/../../ /home/dave/gnu/gcc/gcc/gcc/testsuite/g++.dg/modules/hello-1_b.C -fdiagnostics-plain-output -nostdinc++ -I/home/dave/gnu/gcc/objdir64/hppa64-hp-hpux11.11/libstdc++-v3/include/hppa64-hp-hpux11.11 -I/home/dave/gnu/gcc/objdir64/hppa64-hp-hpux11.11/libstdc++-v3/include -I/home/dave/gnu/gcc/gcc/libstdc++-v3/libsupc++ -I/home/dave/gnu/gcc/gcc/libstdc++-v3/include/backward -I/home/dave/gnu/gcc/gcc/libstdc++-v3/testsuite/util -fmessage-length=0 -std=c++17 -pedantic-errors -Wno-long-long -fmodules-ts -S -o hello-1_b.s In file included from /home/dave/gnu/gcc/objdir64/hppa64-hp-hpux11.11/libstdc++-v3/include/bits/stl_pair.h:62, from /home/dave/gnu/gcc/objdir64/hppa64-hp-hpux11.11/libstdc++-v3/include/bits/stl_algobase.h:64, from /home/dave/gnu/gcc/objdir64/hppa64-hp-hpux11.11/libstdc++-v3/include/string:51, from /home/dave/gnu/gcc/objdir64/hppa64-hp-hpux11.11/libstdc++-v3/include/bits/locale_classes.h:40, from /home/dave/gnu/gcc/objdir64/hppa64-hp-hpux11.11/libstdc++-v3/include/bits/ios_base.h:41, from /home/dave/gnu/gcc/objdir64/hppa64-hp-hpux11.11/libstdc++-v3/include/ios:44, from /home/dave/gnu/gcc/objdir64/hppa64-hp-hpux11.11/libstdc++-v3/include/ostream:40, from /home/dave/gnu/gcc/objdir64/hppa64-hp-hpux11.11/libstdc++-v3/include/iostream:41, from /home/dave/gnu/gcc/gcc/gcc/testsuite/g++.dg/modules/hello-1_a.C:5, of module hello, imported at /home/dave/gnu/gcc/gcc/gcc/testsuite/g++.dg/modules/hello-1_b.C:4: /home/dave/gnu/gcc/objdir64/hppa64-hp-hpux11.11/libstdc++-v3/include/bits/utility.h: In function 'int main()': /home/dave/gnu/gcc/objdir64/hppa64-hp-hpux11.11/libstdc++-v3/include/bits/utility.h:84:11: error: conflicting global module declaration 'using std::__tuple_element_t = typename std::tuple_element<__i, std::tuple<_Elements ...> >::type' In file included from /home/dave/gnu/gcc/objdir64/hppa64-hp-hpux11.11/libstdc++-v3/include/bits/stl_pair.h:62, from /home/dave/gnu/gcc/objdir64/hppa64-hp-hpux11.11/libstdc++-v3/include/bits/stl_algobase.h:64, from /home/dave/gnu/gcc/objdir64/hppa64-hp-hpux11.11/libstdc++-v3/include/string_view:52, from /home/dave/gnu/gcc/gcc/gcc/testsuite/g++.dg/modules/hello-1_b.C:3: /home/dave/gnu/gcc/objdir64/hppa64-hp-hpux11.11/libstdc++-v3/include/bits/utility.h:84:11: note: existing declaration 'using std::__tuple_element_t = typename std::tuple_element<__i, std::tuple<_Elements ...> >::type' /home/dave/gnu/gcc/gcc/gcc/testsuite/g++.dg/modules/hello-1_b.C:7:3: note: during load of binding '::greeter@hello' compiler exited with status 1 FAIL: g++.dg/modules/hello-1_b.C -std=c++17 (test for excess errors) Excess errors: /home/dave/gnu/gcc/objdir64/hppa64-hp-hpux11.11/libstdc++-v3/include/bits/utility.h:84:11: error: conflicting global module declaration 'using std::__tuple_element_t = typename std::tuple_element<__i, std::tuple<_Elements ...> >::type' UNRESOLVED: g++.dg/modules/hello-1 -std=c++17 link UNRESOLVED: g++.dg/modules/hello-1 -std=c++17 execute Similar fails: FAIL: g++.dg/modules/hello-1_b.C -std=c++2a (test for excess errors) FAIL: g++.dg/modules/hello-1_b.C -std=c++2b (test for excess errors)
[Bug middle-end/113722] [14 Regression] Constant folding of __builtin_bswap128 is broken since r14-1455
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113722 --- Comment #5 from GCC Commits --- The master branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:09df058a09f888daad26fa80634068b38b4ad04d commit r14-8776-g09df058a09f888daad26fa80634068b38b4ad04d Author: Jakub Jelinek Date: Sat Feb 3 14:38:27 2024 +0100 wide-int: Fix up wi::bswap_large [PR113722] Since bswap has been converted from a method to a function we miscompile the following testcase. The problem is the assumption that the passed in len argument (number of limbs in the xval array) is the upper bound for the bswap result, which is true only if precision is <= 64. If precision is larger than that, e.g. 128 as in the testcase, if the argument has only one limb (i.e. 0 to ~(unsigned HOST_WIDE_INT) 0), the result can still need 2 limbs for that precision, or generally BLOCKS_NEEDED (precision) limbs, it all depends on how many least significant limbs of the operand are zero. bswap_large as implemented only cleared len limbs of result, then swapped the bytes (invoking UB when oring something in all the limbs above it) and finally passed len to canonize, saying that more limbs aren't needed. The following patch fixes it by renaming len to xlen (so that it is clear it is X's length), using it solely for safe_uhwi argument when we attempt to read from X, and using new len = BLOCKS_NEEDED (precision) instead in the other two spots (i.e. when clearing the val array, turned it also into memset, and in canonize argument). wi::bswap asserts it isn't invoked on widest_int, so we are always invoked on wide_int or similar and those have preallocated result sized for the corresponding precision (i.e. BLOCKS_NEEDED (precision)). 2024-02-03 Jakub Jelinek PR middle-end/113722 * wide-int.cc (wi::bswap_large): Rename third argument from len to xlen and adjust use in safe_uhwi. Add len variable, set it to BLOCKS_NEEDED (precision) and use it for clearing of val and as canonize argument. Clear val using memset instead of a loop. * gcc.dg/pr113722.c: New test.
[Bug target/113720] [14 Regression] internal compiler error: in extract_insn, at recog.cc:2812 targeting alpha-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113720 --- Comment #6 from Matthias Klose --- will do, but cannot do that before next week.
[Bug tree-optimization/113736] ICE: verify_gimple failed: incompatible types in 'PHI' argument 0 with _BitInt() struct copy to __seg_fs/gs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113736
--- Comment #2 from Jakub Jelinek ---
struct S { int a[4]; };
struct T { struct S b[16]; };
void
foo (__seg_gs struct T *p, int q)
{
for (int i = 0; i < 16; ++i)
{
p->b[i].a[0] = q;
p->b[i].a[1] = q;
p->b[i].a[2] = q;
p->b[i].a[3] = q;
}
}
is vectorized right though (uses vector(4) int * vectp_p.4).
[Bug c/113740] ICE: in build_bitint_type, at tree.cc:7178 with _BitInt() as bitfeld
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113740 Jakub Jelinek changed: What|Removed |Added Ever confirmed|0 |1 Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org Last reconfirmed||2024-02-03 Status|UNCONFIRMED |ASSIGNED --- Comment #1 from Jakub Jelinek --- Created attachment 57312 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57312=edit gcc14-pr113740.patch Untested fix.
[Bug ada/113536] [14 regression] valid reduction expression rejected
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113536 Eric Botcazou changed: What|Removed |Added Target Milestone|--- |14.0 Last reconfirmed||2024-02-03 CC||ebotcazou at gcc dot gnu.org Ever confirmed|0 |1 Summary|valid reduction expression |[14 regression] valid |rejected by -gnatVo |reduction expression ||rejected Status|UNCONFIRMED |NEW --- Comment #2 from Eric Botcazou --- Yes, it's a regression on the mainline.
[Bug tree-optimization/113737] ICE: in lower_stmt, at gimple-lower-bitint.cc:5455 with _BitInt() used in switch at -O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113737 Jakub Jelinek changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org Last reconfirmed||2024-02-03 Ever confirmed|0 |1 Status|UNCONFIRMED |ASSIGNED --- Comment #1 from Jakub Jelinek --- Created attachment 57311 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57311=edit gcc14-pr113737.patch Untested fix.
[Bug go/90685] failure of go in gcc-9.1.0 to build in i686-pc-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90685 Brjd changed: What|Removed |Added CC||brjd_epdjq36 at kygur dot com --- Comment #5 from Brjd --- I got the same error on x86_64-pc-linux-gnu at libgo/libgotool.a : go1: error: ‘-fsplit-stack’ currently only supported on GNU/Linux go1: error: ‘-fsplit-stack’ is not supported by this compiler configuration I disable the build since it stops at gotools. It is not quite clear if it is supported in all glibc versions, whether -fsplit-stack is needed for the gccgo build or not, and I see that it is disabled for non-glibcs in the gnu.h header because of -fsplit-stack issues which is correct of course. I guess these problems may be serious, e.g. possible memory corruption, segfaults etc. But I was unable to find reliable information in the gcc docs. I would suggest if the checks of compatibility are made at the very beginning when the build is configured initially, so that users know if the go build is supported on their system or not.
[Bug middle-end/113734] [14 regression] libarchive miscompiled (fails libarchive_test_read_format_rar5_extra_field_version test) since r14-8768-g85094e2aa6dba7
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113734 Tamar Christina changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |tnfchris at gcc dot gnu.org --- Comment #2 from Tamar Christina --- Yeah that's enough info for me to go on. Will fix Monday morning.
[Bug ada/113516] macro POLLPRI redefined during GNAT build
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113516 Eric Botcazou changed: What|Removed |Added CC||ebotcazou at gcc dot gnu.org Ever confirmed|0 |1 Last reconfirmed||2024-02-03 Summary|POLLPRI redefined on|macro POLLPRI redefined |windows building ada|during GNAT build Status|UNCONFIRMED |NEW --- Comment #1 from Eric Botcazou --- Macro (re)definitions should indeed by guarded properly.
[Bug libstdc++/100147] libstdc++-v3/include/bits/gslice.h:170: missing check for assignment to self ?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100147 Jonathan Wakely changed: What|Removed |Added Ever confirmed|0 |1 Assignee|unassigned at gcc dot gnu.org |redi at gcc dot gnu.org Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2024-02-03 --- Comment #2 from Jonathan Wakely --- Due to the aliasing rules for valarrays and slices, I think it would be undefined to assign a gslice to itself. So the overhead of checking for something that should never happen to avoid a redundant increment/decrement pair is a poor trade off. Letting it redundantly inc/dec the reference count is safe and correct for self-assignment, without adding a branch to handle "impossible" cases. I suppose we can add a comment to that effect.
[Bug tree-optimization/113741] missed / wrong optimization switch transformation to same function call
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113741 --- Comment #2 from Bernd Buschinski --- Ah sorry, I did not know that. Please rephrase the topic to better match the actual problem :) (Or tell me what it should be rephrased to)
[Bug c/113727] csmith: differences from nothing to -O1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113727 --- Comment #11 from David Binderman --- Created attachment 57310 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57310=edit C source code
[Bug target/113742] New: ICE: RTL check: expected elt 1 type 'i' or 'n', have 'e' (rtx set) in riscv_macro_fusion_pair_p, at config/riscv/riscv.cc:8416 with -O2 -finstrument-functions -mtune=sifive-p6
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113742
Bug ID: 113742
Summary: ICE: RTL check: expected elt 1 type 'i' or 'n', have
'e' (rtx set) in riscv_macro_fusion_pair_p, at
config/riscv/riscv.cc:8416 with -O2
-finstrument-functions -mtune=sifive-p600-series
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: zsojka at seznam dot cz
Target Milestone: ---
Host: x86_64-pc-linux-gnu
Target: riscv64-unknown-linux-gnu
Created attachment 57309
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57309=edit
reduced testcase
This might need RTL checking enabled.
Compiler output:
$ riscv64-unknown-linux-gnu-gcc -O2 -finstrument-functions
-mtune=sifive-p600-series testcase.c
during RTL pass: sched2
testcase.c: In function 'foo':
testcase.c:1:17: internal compiler error: RTL check: expected elt 1 type 'i' or
'n', have 'e' (rtx set) in riscv_macro_fusion_pair_p, at
config/riscv/riscv.cc:8416
1 | void foo(void) {}
| ^
0xad8030 rtl_check_failed_type2(rtx_def const*, int, int, int, char const*,
int, char const*)
/repo/gcc-trunk/gcc/rtl.cc:761
0xb8d03e riscv_macro_fusion_pair_p
/repo/gcc-trunk/gcc/config/riscv/riscv.cc:8416
0x2b933a4 sched_macro_fuse_insns
/repo/gcc-trunk/gcc/sched-deps.cc:2859
0x2b933a4 sched_analyze_insn
/repo/gcc-trunk/gcc/sched-deps.cc:2898
0x2b94099 deps_analyze_insn(deps_desc*, rtx_insn*)
/repo/gcc-trunk/gcc/sched-deps.cc:3690
0x2b9718a sched_analyze(deps_desc*, rtx_insn*, rtx_insn*)
/repo/gcc-trunk/gcc/sched-deps.cc:3843
0x16af378 compute_block_dependences
/repo/gcc-trunk/gcc/sched-rgn.cc:2738
0x16af378 sched_rgn_compute_dependencies(int)
/repo/gcc-trunk/gcc/sched-rgn.cc:3367
0x16b1c18 schedule_region
/repo/gcc-trunk/gcc/sched-rgn.cc:3139
0x16b1c18 schedule_insns()
/repo/gcc-trunk/gcc/sched-rgn.cc:3525
0x16b22bd schedule_insns()
/repo/gcc-trunk/gcc/sched-rgn.cc:3511
0x16b22bd rest_of_handle_sched2
/repo/gcc-trunk/gcc/sched-rgn.cc:3749
0x16b22bd execute
/repo/gcc-trunk/gcc/sched-rgn.cc:3888
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.
$ riscv64-unknown-linux-gnu-gcc -v
Using built-in specs.
COLLECT_GCC=/repo/gcc-trunk/binary-latest-riscv64/bin/riscv64-unknown-linux-gnu-gcc
COLLECT_LTO_WRAPPER=/repo/gcc-trunk/binary-trunk-r14-8771-20240203001826-g4b7d4d8a4af-checking-yes-rtl-df-extra-riscv64/bin/../libexec/gcc/riscv64-unknown-linux-gnu/14.0.1/lto-wrapper
Target: riscv64-unknown-linux-gnu
Configured with: /repo/gcc-trunk//configure --enable-languages=c,c++
--enable-valgrind-annotations --disable-nls --enable-checking=yes,rtl,df,extra
--with-cloog --with-ppl --with-isl --with-isa-spec=2.2
--with-sysroot=/usr/riscv64-unknown-linux-gnu --build=x86_64-pc-linux-gnu
--host=x86_64-pc-linux-gnu --target=riscv64-unknown-linux-gnu
--with-ld=/usr/bin/riscv64-unknown-linux-gnu-ld
--with-as=/usr/bin/riscv64-unknown-linux-gnu-as --disable-multilib
--disable-libstdcxx-pch
--prefix=/repo/gcc-trunk//binary-trunk-r14-8771-20240203001826-g4b7d4d8a4af-checking-yes-rtl-df-extra-riscv64
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 14.0.1 20240203 (experimental) (GCC)
[Bug c/113727] csmith: differences from nothing to -O1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113727 --- Comment #10 from David Binderman --- (In reply to Sam James from comment #7) > Can you try produce a testcase without UB please? I have some partly reduced code that seems to have no UB. cvise $ ~/gcc/results/bin/gcc -w -fsanitize=address,undefined bug1002.c cvise $ ./a.out 1 > 0 cvise $ ~/gcc/results/bin/gcc -w -fsanitize=address,undefined -O1 bug1002.c cvise $ ./a.out 1 > 1 cvise $ diff 0 1 469c469 < ...checksum after hashing g_994.f3 : 5F99C263 --- > ...checksum after hashing g_994.f3 : 3D4A5D24 cvise $
[Bug tree-optimization/113741] missed / wrong optimization switch transformation to same function call
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113741 Sam James changed: What|Removed |Added CC||sjames at gcc dot gnu.org --- Comment #1 from Sam James --- Note that we reserve the term "wrong" for invalid results or otherwise unsound transformations.
[Bug tree-optimization/113741] New: missed / wrong optimization switch transformation to same function call
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113741 Bug ID: 113741 Summary: missed / wrong optimization switch transformation to same function call Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: b.buschinski at googlemail dot com Target Milestone: --- Created attachment 57308 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57308=edit Attached code + asm from the compiler explorer link Compiler Explorer Link: https://godbolt.org/z/KozK9M5YY The code is reduced from a "hot" path with huge macros. I actually improved the macros with adding the "else" in the code, but I noticed it suddenly created even more instructions and got slower. The GCC version has 52 ASM lines. The clang version only 9 ASM lines. Clang is doing a better job here. As far as I understand the ASM code, GCC generates a switch statement, but after the: cmp edi, 5 ja .L11 it should not be needed at all anymore. Additionally, GCC "reloads" the static values again (for every .L*: label) mov edi, 4 , which are already stored in "i" (C code). Tested with GCC-13.2 and compiler explorer gcc "trunk". On x86_64 Linux. Please let me know if you need any additional details or if this report was useful at all.
[Bug libstdc++/105810] __glibcxx_assert can be improved greatly.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105810
--- Comment #11 from Jonathan Wakely ---
(In reply to Jonathan Wakely from comment #2)
> Specifically, the suggested implementation is:
>
> template
> [[noreturn,__gnu__::__cold__,__gnu__::__noinline__]]
> inline void __my_glibcxx_constexpr_assert() noexcept
> {
> constexpr __glibcxxassertiontype __assertinfo;
>
> __glibcxx_assert_fail(__assertinfo.__glibcxx_assertion_file,__assertinfo.
> __glibcxx_assertion_line,
>
> __assertinfo.__glibcxx_pretty_function,__assertinfo.
> __glibcxx_assertion_condition);
> }
>
> #define my_glibcxx_assert(_Condition) \
> { \
> if (!bool(_Condition))[[unlikely]] \
N.B. we can't use [[unlikely]] in C++98 mode, it needs to be __builtin_expect.
We can't even use [[unlikely]] in C++11, it would need to be [[__unlikely__]].
> { \
> \
> constexpr char const* __glibcxx_pretty_function_impl =
> __PRETTY_FUNCTION__;\
> struct __glibcxxassertion{\
> char const* __glibcxx_assertion_file=__FILE__;\
> int __glibcxx_assertion_line=__LINE__;\
> char const* __glibcxx_pretty_function="";\
> char const* __glibcxx_assertion_condition=#_Condition;\
> };\
> __my_glibcxx_constexpr_assert<__glibcxxassertion>();
> \
We can't use a local class as a template argument in C++98, because the type
has no linkage.
[Bug c/113740] New: ICE: in build_bitint_type, at tree.cc:7178 with _BitInt() as bitfeld
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113740 Bug ID: 113740 Summary: ICE: in build_bitint_type, at tree.cc:7178 with _BitInt() as bitfeld Product: gcc Version: 14.0 Status: UNCONFIRMED Keywords: ice-on-valid-code Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: zsojka at seznam dot cz CC: jakub at gcc dot gnu.org Target Milestone: --- Host: x86_64-pc-linux-gnu Target: x86_64-pc-linux-gnu Created attachment 57307 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57307=edit reduced testcase Compiler output: $ x86_64-pc-linux-gnu-gcc testcase.c testcase.c:3:1: internal compiler error: in build_bitint_type, at tree.cc:7178 3 | }; | ^ 0x89961c build_bitint_type(unsigned long, int) /repo/gcc-trunk/gcc/tree.cc:7178 0xe0e96b finish_struct(unsigned int, tree_node*, tree_node*, tree_node*, c_struct_parse_info*, tree_node**) /repo/gcc-trunk/gcc/c/c-decl.cc:9560 0xe69d7d c_parser_struct_or_union_specifier /repo/gcc-trunk/gcc/c/c-parser.cc:4090 0xe69d7d c_parser_declspecs(c_parser*, c_declspecs*, bool, bool, bool, bool, bool, bool, bool, c_lookahead_kind) /repo/gcc-trunk/gcc/c/c-parser.cc:3494 0xe792ec c_parser_declaration_or_fndef /repo/gcc-trunk/gcc/c/c-parser.cc:2306 0xe854bb c_parser_external_declaration /repo/gcc-trunk/gcc/c/c-parser.cc:2046 0xe85ea5 c_parser_translation_unit /repo/gcc-trunk/gcc/c/c-parser.cc:1900 0xe85ea5 c_parse_file() /repo/gcc-trunk/gcc/c/c-parser.cc:26815 0xefd681 c_common_parse_file() /repo/gcc-trunk/gcc/c-family/c-opts.cc:1306 Please submit a full bug report, with preprocessed source (by using -freport-bug). Please include the complete backtrace with any bug report. See <https://gcc.gnu.org/bugs/> for instructions. $ x86_64-pc-linux-gnu-gcc -v Using built-in specs. COLLECT_GCC=/repo/gcc-trunk/binary-latest-amd64/bin/x86_64-pc-linux-gnu-gcc COLLECT_LTO_WRAPPER=/repo/gcc-trunk/binary-trunk-r14-8771-20240203001826-g4b7d4d8a4af-checking-yes-rtl-df-extra-amd64/bin/../libexec/gcc/x86_64-pc-linux-gnu/14.0.1/lto-wrapper Target: x86_64-pc-linux-gnu Configured with: /repo/gcc-trunk//configure --enable-languages=c,c++ --enable-valgrind-annotations --disable-nls --enable-checking=yes,rtl,df,extra --with-cloog --with-ppl --with-isl --build=x86_64-pc-linux-gnu --host=x86_64-pc-linux-gnu --target=x86_64-pc-linux-gnu --with-ld=/usr/bin/x86_64-pc-linux-gnu-ld --with-as=/usr/bin/x86_64-pc-linux-gnu-as --disable-libstdcxx-pch --prefix=/repo/gcc-trunk//binary-trunk-r14-8771-20240203001826-g4b7d4d8a4af-checking-yes-rtl-df-extra-amd64 Thread model: posix Supported LTO compression algorithms: zlib zstd gcc version 14.0.1 20240203 (experimental) (GCC)
[Bug libstdc++/90276] PSTL tests fail in Debug Mode
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90276 --- Comment #13 from Jonathan Wakely --- The remaining failures are: 25_algorithms/pstl/alg_nonmodifying/nth_element.cc 25_algorithms/pstl/alg_sorting/includes.cc 25_algorithms/pstl/alg_sorting/minmax_element.cc 25_algorithms/pstl/alg_sorting/partial_sort.cc 25_algorithms/pstl/alg_sorting/set_difference.cc 25_algorithms/pstl/alg_sorting/set_intersection.cc 25_algorithms/pstl/alg_sorting/set_symmetric_difference.cc 25_algorithms/pstl/alg_sorting/set_union.cc But they're all timeouts except for partial_sort.cc which is analyzed above, starting from comment 6.
[Bug target/113739] New: ICE: in riscv_hard_regno_nregs, at config/riscv/riscv.cc:8072 with __attribute__((__target__("arch=rv64gcv")))
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113739
Bug ID: 113739
Summary: ICE: in riscv_hard_regno_nregs, at
config/riscv/riscv.cc:8072 with
__attribute__((__target__("arch=rv64gcv")))
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: zsojka at seznam dot cz
Target Milestone: ---
Host: x86_64-pc-linux-gnu
Target: riscv64-unknown-linux-gnu
Created attachment 57306
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57306=edit
reduced testcase (from gcc.target/riscv/target-attr-01.c)
Compiler output:
$ riscv64-unknown-linux-gnu-gcc testcase.c
testcase.c: In function 'foo':
testcase.c:4:1: internal compiler error: in riscv_hard_regno_nregs, at
config/riscv/riscv.cc:8072
4 | {
| ^
0xb8742e riscv_hard_regno_nregs
/repo/gcc-trunk/gcc/config/riscv/riscv.cc:8072
0x166c5fa init_reg_modes_target()
/repo/gcc-trunk/gcc/reginfo.cc:471
0x128b5f3 init_emit_regs()
/repo/gcc-trunk/gcc/emit-rtl.cc:6237
0x171df76 target_reinit()
/repo/gcc-trunk/gcc/toplev.cc:1934
0x2b9c43a save_target_globals()
/repo/gcc-trunk/gcc/target-globals.cc:92
0x1aeb99d riscv_save_restore_target_globals(tree_node*)
/repo/gcc-trunk/gcc/config/riscv/riscv.cc:9081
0x1aeb99d riscv_save_restore_target_globals(tree_node*)
/repo/gcc-trunk/gcc/config/riscv/riscv.cc:9074
0x133c4f4 invoke_set_current_function_hook
/repo/gcc-trunk/gcc/function.cc:4689
0x1345917 invoke_set_current_function_hook
/repo/gcc-trunk/gcc/function.cc:4863
0x1345917 allocate_struct_function(tree_node*, bool)
/repo/gcc-trunk/gcc/function.cc:4812
0x100f6ed store_parm_decls()
/repo/gcc-trunk/gcc/c/c-decl.cc:11084
0x10780f2 c_parser_declaration_or_fndef
/repo/gcc-trunk/gcc/c/c-parser.cc:2975
0x1081f2b c_parser_external_declaration
/repo/gcc-trunk/gcc/c/c-parser.cc:2046
0x1082913 c_parser_translation_unit
/repo/gcc-trunk/gcc/c/c-parser.cc:1900
0x1082913 c_parse_file()
/repo/gcc-trunk/gcc/c/c-parser.cc:26815
0x10f83b1 c_common_parse_file()
/repo/gcc-trunk/gcc/c-family/c-opts.cc:1306
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.
$ riscv64-unknown-linux-gnu-gcc -v
Using built-in specs.
COLLECT_GCC=/repo/gcc-trunk/binary-latest-riscv64/bin/riscv64-unknown-linux-gnu-gcc
COLLECT_LTO_WRAPPER=/repo/gcc-trunk/binary-trunk-r14-8771-20240203001826-g4b7d4d8a4af-checking-yes-rtl-df-extra-riscv64/bin/../libexec/gcc/riscv64-unknown-linux-gnu/14.0.1/lto-wrapper
Target: riscv64-unknown-linux-gnu
Configured with: /repo/gcc-trunk//configure --enable-languages=c,c++
--enable-valgrind-annotations --disable-nls --enable-checking=yes,rtl,df,extra
--with-cloog --with-ppl --with-isl --with-isa-spec=2.2
--with-sysroot=/usr/riscv64-unknown-linux-gnu --build=x86_64-pc-linux-gnu
--host=x86_64-pc-linux-gnu --target=riscv64-unknown-linux-gnu
--with-ld=/usr/bin/riscv64-unknown-linux-gnu-ld
--with-as=/usr/bin/riscv64-unknown-linux-gnu-as --disable-multilib
--disable-libstdcxx-pch
--prefix=/repo/gcc-trunk//binary-trunk-r14-8771-20240203001826-g4b7d4d8a4af-checking-yes-rtl-df-extra-riscv64
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 14.0.1 20240203 (experimental) (GCC)
[Bug tree-optimization/113736] ICE: verify_gimple failed: incompatible types in 'PHI' argument 0 with _BitInt() struct copy to __seg_fs/gs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113736
Jakub Jelinek changed:
What|Removed |Added
Last reconfirmed||2024-02-03
CC||rguenth at gcc dot gnu.org
Ever confirmed|0 |1
Status|UNCONFIRMED |NEW
--- Comment #1 from Jakub Jelinek ---
struct S { _BitInt(710) a; };
struct T { struct S b[2]; };
void
foo (__seg_gs struct T *p)
{
struct S s;
p->b[0] = s;
}
Bitint lowering changes here
MEM < _BitInt(768)> [( struct T *)p_2(D)] =
s_4(D);
to
VIEW_CONVERT_EXPR(MEM < _BitInt(768)>
[( struct T *)p_2(D)])[_5] = s_7(D);
accesses in a loop. Is that invalid and should have also in
the VCE type? Or is this just a vectorizer bug?
[Bug target/113738] New: [14 Regression] ICE: in df_reg_chain_verify_unmarked, at df-scan.cc:4001 with -O2 -march=rv64gcv
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113738 Bug ID: 113738 Summary: [14 Regression] ICE: in df_reg_chain_verify_unmarked, at df-scan.cc:4001 with -O2 -march=rv64gcv Product: gcc Version: 14.0 Status: UNCONFIRMED Keywords: ice-on-valid-code Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: zsojka at seznam dot cz Target Milestone: --- Host: x86_64-pc-linux-gnu Target: riscv64-unknown-linux-gnu Created attachment 57305 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57305=edit reduced testcase (from gcc.dg/torture/pr45764.c) Compiler output: $ riscv64-unknown-linux-gnu-gcc -O2 -march=rv64gcv testcase.c during RTL pass: rtl_dce testcase.c: In function 'foo': testcase.c:7:1: internal compiler error: in df_reg_chain_verify_unmarked, at df-scan.cc:4001 7 | } | ^ 0xa138ee df_reg_chain_verify_unmarked /repo/gcc-trunk/gcc/df-scan.cc:4001 0xa15111 df_reg_chain_verify_unmarked /repo/gcc-trunk/gcc/df-scan.cc:4218 0xa15111 df_scan_verify() /repo/gcc-trunk/gcc/df-scan.cc:4264 0x11f06d1 df_verify() /repo/gcc-trunk/gcc/df-core.cc:1834 0x11f06d1 df_analyze_1 /repo/gcc-trunk/gcc/df-core.cc:1221 0x29de3d5 init_dce /repo/gcc-trunk/gcc/dce.cc:763 0x29e103d rest_of_handle_fast_dce /repo/gcc-trunk/gcc/dce.cc:1193 0x29e103d execute /repo/gcc-trunk/gcc/dce.cc:1290 Please submit a full bug report, with preprocessed source (by using -freport-bug). Please include the complete backtrace with any bug report. See <https://gcc.gnu.org/bugs/> for instructions. $ riscv64-unknown-linux-gnu-gcc -v Using built-in specs. COLLECT_GCC=/repo/gcc-trunk/binary-latest-riscv64/bin/riscv64-unknown-linux-gnu-gcc COLLECT_LTO_WRAPPER=/repo/gcc-trunk/binary-trunk-r14-8771-20240203001826-g4b7d4d8a4af-checking-yes-rtl-df-extra-riscv64/bin/../libexec/gcc/riscv64-unknown-linux-gnu/14.0.1/lto-wrapper Target: riscv64-unknown-linux-gnu Configured with: /repo/gcc-trunk//configure --enable-languages=c,c++ --enable-valgrind-annotations --disable-nls --enable-checking=yes,rtl,df,extra --with-cloog --with-ppl --with-isl --with-isa-spec=2.2 --with-sysroot=/usr/riscv64-unknown-linux-gnu --build=x86_64-pc-linux-gnu --host=x86_64-pc-linux-gnu --target=riscv64-unknown-linux-gnu --with-ld=/usr/bin/riscv64-unknown-linux-gnu-ld --with-as=/usr/bin/riscv64-unknown-linux-gnu-as --disable-multilib --disable-libstdcxx-pch --prefix=/repo/gcc-trunk//binary-trunk-r14-8771-20240203001826-g4b7d4d8a4af-checking-yes-rtl-df-extra-riscv64 Thread model: posix Supported LTO compression algorithms: zlib zstd gcc version 14.0.1 20240203 (experimental) (GCC)
[Bug c/113727] csmith: differences from nothing to -O1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113727 Xi Ruoyao changed: What|Removed |Added See Also|https://gcc.gnu.org/bugzill | |a/show_bug.cgi?id=109982| --- Comment #9 from Xi Ruoyao --- Nope. Even with #pragma removed the result is still wrong.
[Bug tree-optimization/113735] ICE: in operator[], at vec.h:910 with _BitInt() at -O and above
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113735
Jakub Jelinek changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed||2024-02-03
Status|UNCONFIRMED |NEW
CC||aldyh at gcc dot gnu.org,
||amacleod at redhat dot com
--- Comment #1 from Jakub Jelinek ---
Slightly tweaked, still -O1:
char b;
void bar (void);
void
foo (_BitInt(6110) j)
{
for (;;)
{
_BitInt(10) k = b % j;
for (j = 6; j; --j)
if (k)
bar ();
}
}
The ICE is in on:
721 if (!m_equiv[bb->index])
because bb->index is larger than m_equiv size.
The bitint lowering pass works by walking the IL and replacing some statements
in there with lowered code, which can involve new basic blocks (either through
splitting existing blocks or creating fresh new ones) and the like. And asks
the ranger about range of statements during that.
Is that something that ranger doesn't/can't support?
So, would I need to ensure to find out what ranges I'll need before making any
changes,
ask for them, remember them somewhere on the side and then use them during the
transformations?
#0 fancy_abort (file=0x2c76d8a "../../gcc/vec.h", line=910, function=0x2c76d7f
"operator[]") at ../../gcc/diagnostic.cc:2313
#1 0x011fcb6b in vec::operator[]
(this=0x39fb660 = {...}, ix=16) at ../../gcc/vec.h:910
#2 0x011fc4b7 in vec::operator[]
(Python Exception : There is no member or method named
m_vecpfx.
this=0x39fc050, ix=16) at ../../gcc/vec.h:1599
#3 0x011f81c4 in equiv_oracle::add_equiv_to_block (this=0x39fbf80,
bb=, equiv_set=0x3ad29b8) at
../../gcc/value-relation.cc:721
#4 0x011f7f1e in equiv_oracle::register_initial_def (this=0x39fbf80,
ssa=) at ../../gcc/value-relation.cc:643
#5 0x011f8025 in equiv_oracle::register_relation (this=0x39fbf80,
bb=, k=VREL_EQ, ssa1=,
ssa2=) at ../../gcc/value-relation.cc:675
#6 0x011f98a5 in dom_oracle::register_relation (this=0x39fbf80,
bb=, k=VREL_EQ, op1=,
op2=) at ../../gcc/value-relation.cc:
#7 0x011f96d7 in relation_oracle::register_stmt (this=0x39fbf80,
stmt=, k=VREL_EQ, op1=,
op2=) at ../../gcc/value-relation.cc:1069
#8 0x025fb5fe in fur_depend::register_relation (this=0x7fffbcd0,
s=, k=VREL_EQ, op1=,
op2=) at ../../gcc/gimple-range-fold.cc:202
#9 0x025fe3d3 in fold_using_range::range_of_phi (this=0x7fffbcff,
r=..., phi=0x7fffea30ae00, src=...) at ../../gcc/gimple-range-fold.cc:932
#10 0x025fcaa8 in fold_using_range::fold_stmt (this=0x7fffbcff,
r=..., s=, src=..., name=)
at ../../gcc/gimple-range-fold.cc:604
#11 0x025ee502 in gimple_ranger::fold_range_internal (this=0x3b91ca0,
r=..., s=, name=)
at ../../gcc/gimple-range.cc:265
#12 0x025eeb24 in gimple_ranger::prefill_stmt_dependencies
(this=0x3b91ca0, ssa=) at
../../gcc/gimple-range.cc:404
#13 0x025ee7c3 in gimple_ranger::range_of_stmt (this=0x3b91ca0, r=...,
s=, name=) at
../../gcc/gimple-range.cc:322
#14 0x025edc52 in gimple_ranger::range_of_expr (this=0x3b91ca0, r=...,
expr=, stmt=)
at ../../gcc/gimple-range.cc:134
#15 0x025cb0a0 in (anonymous namespace)::range_to_prec (op=, stmt=) at
../../gcc/gimple-lower-bitint.cc:2008
#16 0x025cc539 in (anonymous
namespace)::bitint_large_huge::handle_operand_addr (this=0x7fffd560,
op=, stmt=,
prec_stored=0x0, prec=0x7fffd148) at
../../gcc/gimple-lower-bitint.cc:2211
#17 0x025d3688 in (anonymous
namespace)::bitint_large_huge::lower_muldiv_stmt (this=0x7fffd560,
obj=, stmt=)
at ../../gcc/gimple-lower-bitint.cc:3403
#18 0x025de784 in (anonymous namespace)::bitint_large_huge::lower_stmt
(this=0x7fffd560, stmt=) at
../../gcc/gimple-lower-bitint.cc:5439
#19 0x025e4297 in gimple_lower_bitint () at
../../gcc/gimple-lower-bitint.cc:6575
#20 0x025e5719 in (anonymous namespace)::pass_lower_bitint::execute
(this=0x3a10fe0) at ../../gcc/gimple-lower-bitint.cc:6837
[Bug c/113727] csmith: differences from nothing to -O1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113727
Xi Ruoyao changed:
What|Removed |Added
CC||xry111 at gcc dot gnu.org
See Also||https://gcc.gnu.org/bugzill
||a/show_bug.cgi?id=109982
--- Comment #8 from Xi Ruoyao ---
#pragma pack(push)
#pragma pack(1)
struct S0 {
signed f0 : 22;
uint32_t f1;
unsigned f2 : 5;
unsigned f3 : 21;
unsigned f4 : 8;
signed f5 : 22;
signed f6 : 1;
signed f7 : 23;
signed f8 : 10;
};
#pragma pack(pop)
Removing these #pragma silence the UBSan. But I bet the code is just invalid
with those #pragma and with #pragma removed the issue will just gone, like
PR109982.
[Bug tree-optimization/113737] New: ICE: in lower_stmt, at gimple-lower-bitint.cc:5455 with _BitInt() used in switch at -O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113737 Bug ID: 113737 Summary: ICE: in lower_stmt, at gimple-lower-bitint.cc:5455 with _BitInt() used in switch at -O2 Product: gcc Version: 14.0 Status: UNCONFIRMED Keywords: ice-on-valid-code Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: zsojka at seznam dot cz CC: jakub at gcc dot gnu.org Target Milestone: --- Host: x86_64-pc-linux-gnu Target: x86_64-pc-linux-gnu Created attachment 57304 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57304=edit reduced testcase (from gcc.dg/pr80823.c) Compiler output: $ x86_64-pc-linux-gnu-gcc -O2 testcase.c during GIMPLE pass: bitintlower testcase.c: In function 'fn2': testcase.c:16:1: internal compiler error: in lower_stmt, at gimple-lower-bitint.cc:5455 16 | fn2(int i) | ^~~ 0xd898b9 lower_stmt /repo/gcc-trunk/gcc/gimple-lower-bitint.cc:5455 0x274dc73 gimple_lower_bitint /repo/gcc-trunk/gcc/gimple-lower-bitint.cc:6575 Please submit a full bug report, with preprocessed source (by using -freport-bug). Please include the complete backtrace with any bug report. See <https://gcc.gnu.org/bugs/> for instructions. $ x86_64-pc-linux-gnu-gcc -v Using built-in specs. COLLECT_GCC=/repo/gcc-trunk/binary-latest-amd64/bin/x86_64-pc-linux-gnu-gcc COLLECT_LTO_WRAPPER=/repo/gcc-trunk/binary-trunk-r14-8771-20240203001826-g4b7d4d8a4af-checking-yes-rtl-df-extra-amd64/bin/../libexec/gcc/x86_64-pc-linux-gnu/14.0.1/lto-wrapper Target: x86_64-pc-linux-gnu Configured with: /repo/gcc-trunk//configure --enable-languages=c,c++ --enable-valgrind-annotations --disable-nls --enable-checking=yes,rtl,df,extra --with-cloog --with-ppl --with-isl --build=x86_64-pc-linux-gnu --host=x86_64-pc-linux-gnu --target=x86_64-pc-linux-gnu --with-ld=/usr/bin/x86_64-pc-linux-gnu-ld --with-as=/usr/bin/x86_64-pc-linux-gnu-as --disable-libstdcxx-pch --prefix=/repo/gcc-trunk//binary-trunk-r14-8771-20240203001826-g4b7d4d8a4af-checking-yes-rtl-df-extra-amd64 Thread model: posix Supported LTO compression algorithms: zlib zstd gcc version 14.0.1 20240203 (experimental) (GCC)
[Bug target/113720] [14 Regression] internal compiler error: in extract_insn, at recog.cc:2812 targeting alpha-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113720 --- Comment #5 from Uroš Bizjak --- (In reply to Matthias Klose from comment #4) > Uros proposed patch lets the build succeed. FTR, the problem was in umuldi3_highpart expander, which did: if (REG_P (operands[2])) operands[2] = gen_rtx_ZERO_EXTEND (TImode, operands[2]); on register_operand predicate, which also allows SUBREG RTX. So, subregs were emitted without ZERO_EXTEND RTX. But nowadays we have UMUL_HIGHPART that allows us to fix this issue while also simplifying the instruction RTX. Matthias, can you please run the regression check - The fix is kind of obvious, but just to be sure.
[Bug tree-optimization/113736] New: ICE: verify_gimple failed: incompatible types in 'PHI' argument 0 with _BitInt() struct copy to __seg_fs/gs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113736
Bug ID: 113736
Summary: ICE: verify_gimple failed: incompatible types in 'PHI'
argument 0 with _BitInt() struct copy to __seg_fs/gs
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: zsojka at seznam dot cz
Target Milestone: ---
Host: x86_64-pc-linux-gnu
Target: x86_64-pc-linux-gnu
Created attachment 57303
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57303=edit
reduced testcase (from gcc.target/i386/pr90856.c)
Compiler output:
$ x86_64-pc-linux-gnu-gcc -O2 testcase.c
testcase.c: In function 'clearS2_n':
testcase.c:12:1: error: incompatible types in 'PHI' argument 0
12 | clearS2_n (__seg_gs S2 *p)
| ^
vector(2) unsigned long * {ref-all}
struct S2 *
vectp_p.4_14 = PHI
during GIMPLE pass: vect
testcase.c:12:1: internal compiler error: verify_gimple failed
0x1567165 verify_gimple_in_cfg(function*, bool, bool)
/repo/gcc-trunk/gcc/tree-cfg.cc:5666
0x13cf7e4 execute_function_todo
/repo/gcc-trunk/gcc/passes.cc:2088
0x13cfd3e execute_todo
/repo/gcc-trunk/gcc/passes.cc:2142
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.
$ x86_64-pc-linux-gnu-gcc -v
Using built-in specs.
COLLECT_GCC=/repo/gcc-trunk/binary-latest-amd64/bin/x86_64-pc-linux-gnu-gcc
COLLECT_LTO_WRAPPER=/repo/gcc-trunk/binary-trunk-r14-8771-20240203001826-g4b7d4d8a4af-checking-yes-rtl-df-extra-amd64/bin/../libexec/gcc/x86_64-pc-linux-gnu/14.0.1/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /repo/gcc-trunk//configure --enable-languages=c,c++
--enable-valgrind-annotations --disable-nls --enable-checking=yes,rtl,df,extra
--with-cloog --with-ppl --with-isl --build=x86_64-pc-linux-gnu
--host=x86_64-pc-linux-gnu --target=x86_64-pc-linux-gnu
--with-ld=/usr/bin/x86_64-pc-linux-gnu-ld
--with-as=/usr/bin/x86_64-pc-linux-gnu-as --disable-libstdcxx-pch
--prefix=/repo/gcc-trunk//binary-trunk-r14-8771-20240203001826-g4b7d4d8a4af-checking-yes-rtl-df-extra-amd64
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 14.0.1 20240203 (experimental) (GCC)
[Bug target/113720] [14 Regression] internal compiler error: in extract_insn, at recog.cc:2812 targeting alpha-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113720 --- Comment #4 from Matthias Klose --- Uros proposed patch lets the build succeed.
[Bug tree-optimization/113735] New: ICE: in operator[], at vec.h:910 with _BitInt() at -O and above
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113735 Bug ID: 113735 Summary: ICE: in operator[], at vec.h:910 with _BitInt() at -O and above Product: gcc Version: 14.0 Status: UNCONFIRMED Keywords: ice-on-valid-code Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: zsojka at seznam dot cz CC: jakub at gcc dot gnu.org Target Milestone: --- Host: x86_64-pc-linux-gnu Target: x86_64-pc-linux-gnu Created attachment 57302 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57302=edit reduced testcase Compiler output: $ x86_64-pc-linux-gnu-gcc -O testcase.c during GIMPLE pass: bitintlower testcase.c: In function 'foo': testcase.c:4:1: internal compiler error: in operator[], at vec.h:910 4 | foo (_BitInt(6110) j) | ^~~ 0x8a2ed8 vec::operator[](unsigned int) /repo/gcc-trunk/gcc/vec.h:910 0x8a30be vec::operator[](unsigned int) /repo/gcc-trunk/gcc/value-relation.cc:736 0x8a30be vec::operator[](unsigned int) /repo/gcc-trunk/gcc/vec.h:1599 0x8a30be equiv_oracle::add_equiv_to_block(basic_block_def*, bitmap_head*) /repo/gcc-trunk/gcc/value-relation.cc:721 0x1868312 equiv_oracle::register_relation(basic_block_def*, relation_kind_t, tree_node*, tree_node*) /repo/gcc-trunk/gcc/value-relation.cc:675 0x2741a67 fold_using_range::range_of_phi(vrange&, gphi*, fur_source&) /repo/gcc-trunk/gcc/gimple-range-fold.cc:932 0x27458f0 fold_using_range::fold_stmt(vrange&, gimple*, fur_source&, tree_node*) /repo/gcc-trunk/gcc/gimple-range-fold.cc:604 0x272c929 gimple_ranger::fold_range_internal(vrange&, gimple*, tree_node*) /repo/gcc-trunk/gcc/gimple-range.cc:265 0x272c929 gimple_ranger::prefill_stmt_dependencies(tree_node*) /repo/gcc-trunk/gcc/gimple-range.cc:404 0x272d9ca gimple_ranger::range_of_stmt(vrange&, gimple*, tree_node*) /repo/gcc-trunk/gcc/gimple-range.cc:322 0x27315aa gimple_ranger::range_of_expr(vrange&, tree_node*, gimple*) /repo/gcc-trunk/gcc/gimple-range.cc:134 0x27077e2 range_to_prec /repo/gcc-trunk/gcc/gimple-lower-bitint.cc:2008 0x270c7e0 handle_operand_addr /repo/gcc-trunk/gcc/gimple-lower-bitint.cc:2211 0x270cbe7 lower_muldiv_stmt /repo/gcc-trunk/gcc/gimple-lower-bitint.cc:3403 0x2720eb9 gimple_lower_bitint /repo/gcc-trunk/gcc/gimple-lower-bitint.cc:6575 Please submit a full bug report, with preprocessed source (by using -freport-bug). Please include the complete backtrace with any bug report. See <https://gcc.gnu.org/bugs/> for instructions. $ x86_64-pc-linux-gnu-gcc -v Using built-in specs. COLLECT_GCC=/repo/gcc-trunk/binary-latest-amd64/bin/x86_64-pc-linux-gnu-gcc COLLECT_LTO_WRAPPER=/repo/gcc-trunk/binary-trunk-r14-8771-20240203001826-g4b7d4d8a4af-checking-yes-rtl-df-extra-amd64/bin/../libexec/gcc/x86_64-pc-linux-gnu/14.0.1/lto-wrapper Target: x86_64-pc-linux-gnu Configured with: /repo/gcc-trunk//configure --enable-languages=c,c++ --enable-valgrind-annotations --disable-nls --enable-checking=yes,rtl,df,extra --with-cloog --with-ppl --with-isl --build=x86_64-pc-linux-gnu --host=x86_64-pc-linux-gnu --target=x86_64-pc-linux-gnu --with-ld=/usr/bin/x86_64-pc-linux-gnu-ld --with-as=/usr/bin/x86_64-pc-linux-gnu-as --disable-libstdcxx-pch --prefix=/repo/gcc-trunk//binary-trunk-r14-8771-20240203001826-g4b7d4d8a4af-checking-yes-rtl-df-extra-amd64 Thread model: posix Supported LTO compression algorithms: zlib zstd gcc version 14.0.1 20240203 (experimental) (GCC)
[Bug middle-end/113734] [14 regression] libarchive miscompiled (fails libarchive_test_read_format_rar5_extra_field_version test) since r14-8768-g85094e2aa6dba7
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113734
--- Comment #1 from Sam James ---
Not made much progress yet.
libarchive/archive_read_support_format_rar5.c.o is the miscompiled obj, using
#pragma GCC optimize ("O0") on parse_tables fixes things.
