[Bug target/113255] [11/12/13/14 Regression] wrong code with -O2 -mtune=k8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113255 --- Comment #5 from Jakub Jelinek --- (In reply to Richard Biener from comment #4) > I'm unsure the above parallel is valid, isn't parallel executing stmts > in "parallel" (unspecified order)? I don't see anything invalid on it. In addition to the memory copying, it describes the other effects at the end of the pattern (that the counter goes to 0 and the di/si pointers are incremented by the original counter times 8). All the uses of pseudos in the pattern are the values of those pseudos before the instruction, then all the sets at the end set the updated pseudos.
[Bug target/113115] [14 Regression] ICE In extract_constrain_insn_cached recog.cc with ppc64le-linux-gnu crosscompiler from r14-3592-g9ea1248604d7b6
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113115 --- Comment #6 from Segher Boessenkool --- Using -mpower9-vector while not having -mcpu=power9 (or later) is wrong, and should not work. Using -mno-power9-vector is just weird. If we can neuter the -mpower9-vector (etc.) options now, that would be good. But there are some complications with the testsuite at least?
[Bug target/113288] [i386] Missing #define for -mavx10.1-256 and -mavx10.1-512
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113288 --- Comment #3 from Haochen Jiang --- Adding them are quite straightforward. But I am not quite sure how the whole libgomp patch works. Is the patch attempt to check whether it is a perfect match for each ISA detected from a hardware? If that is the case, we need them to be added. BTW, under this scenario, no need to add an if clause for macro __EVEX512__ and __EVEX256__ in that patch since those two are not true ISAs.
[Bug target/113255] [11/12/13/14 Regression] wrong code with -O2 -mtune=k8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113255
--- Comment #4 from Richard Biener ---
DSE thinks the store is dead because it falls off the function.
(insn 41 40 46 4 (set (mem/c:SI (plus:DI (reg/f:DI 19 frame)
(const_int -36 [0xffdc])) [2 e[1].y+0 S4 A32])
(reg:SI 98 [ e$1$y ])) "t.c":21:9 85 {*movsi_internal}
(expr_list:REG_DEAD (reg:SI 98 [ e$1$y ])
(nil)))
...
(insn 64 63 68 4 (parallel [
(set (reg:DI 131)
(const_int 0 [0]))
(set (reg/f:DI 129)
(plus:DI (ashift:DI (reg:DI 131)
(const_int 3 [0x3]))
(reg/f:DI 129)))
(set (reg/f:DI 119)
(plus:DI (ashift:DI (reg:DI 131)
(const_int 3 [0x3]))
(reg/f:DI 119)))
(set (mem/c:BLK (reg/f:DI 129) [1 A64])
(mem/c:BLK (reg/f:DI 119) [1 A8]))
(use (reg:DI 131))
]) "t.c":21:9 1416 {*rep_movdi_rex64}
(expr_list:REG_UNUSED (reg:DI 131)
(expr_list:REG_UNUSED (reg/f:DI 129)
(expr_list:REG_UNUSED (reg/f:DI 119)
(nil)
it appears to be a bit convoluted how we compute the source of the block
copy (reg/f:DI 119) and this is probably confusing "frame related" vs.
non-frame-related MEM disambiguation.
I'm unsure the above parallel is valid, isn't parallel executing stmts
in "parallel" (unspecified order)?
**scanning insn=64
mem: (reg/f:DI 119)
after canon_rtx address: (reg/f:DI 119)
after cselib_expand address: (minus:DI (plus:DI (reg/f:DI 129)
(reg/f:DI 133))
(reg/f:DI 134))
after canon_rtx address: (minus:DI (plus:DI (reg/f:DI 129)
(reg/f:DI 133))
(reg/f:DI 134))
varying cselib base=17:1741806 offset = 0
processing cselib load mem:(mem/c:BLK (reg/f:DI 119) [1 A8])
processing cselib load against insn 55
removing from active insn=55 has store
processing cselib load against insn 47
removing from active insn=47 has store
processing cselib load against insn 41
mems_found = 0, cannot_delete = true
we're calling canon_true_dependence with
(gdb) p debug_rtx (store_info->mem)
(mem/c:SI (plus:DI (reg/f:DI 19 frame)
(const_int -36 [0xffdc])) [2 e[1].y+0 S4 A32])
(gdb) p debug_rtx (mem)
(mem/c:BLK (reg/f:DI 119) [1 A8])
(gdb) p debug_rtx (mem_addr)
(minus:DI (plus:DI (value:DI 8:1741643 @0x49c8ba8/0x49b8e80)
(value:DI 11:11 @0x49c8bf0/0x49b8f10))
(value:DI 9:9 @0x49c8bc0/0x49b8eb0))
and find_base_term of the mem_addr is returning
(symbol_ref:DI ("g_e") [flags 0x2] )
which is because of the weird way we compute the source address (involving
the address of the destination). There's a very old bug about find_base_term
which tends to pick up a wrong base if multiple candidates are involved.
I can't decipher this from what expand generates but the problem lies
there (the rep_8bytes expansion).
[Bug target/113288] [i386] Missing #define for -mavx10.1-256 and -mavx10.1-512
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113288 Hongtao Liu changed: What|Removed |Added CC||liuhongt at gcc dot gnu.org --- Comment #2 from Hongtao Liu --- I think we can add #define for -mavx10.1-256 and -mavx10.1-512.
[Bug tree-optimization/110279] [14 Regression] Regressions on aarch64 cause by handing FMA in reassoc (510.parest_r, 508.namd_r)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110279 --- Comment #7 from Di Zhao --- This patch is to fix the regression test failures: "Fix compile options of pr110279-1.c and pr110279-2.c" (https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=6cec7b06b3c8187b36fc05cfd4dd38b42313d727)
[Bug target/113288] [i386] Missing #define for -mavx10.1-256 and -mavx10.1-512
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113288 --- Comment #1 from Haochen Jiang --- (In reply to Tobias Burnus from comment #0) > As noted in > https://gcc.gnu.org/pipermail/gcc-patches/2024-January/642025.html > > There is not #define for -mavx10.1-256 and -mavx10.1-512 > > By contrast, there is one for, e.g., > > __AVX10_512BIT__ and "avx10-max-512bit" > __AVX10_1__ and "avx10.1" I think both of these two are also not on current trunk, they are the previous design but get obsoleted at the end. Let me see if we need something like that. > __AMX_FP16__ and -mamx-fp16 > etc.
[Bug target/113288] New: [i386] Missing #define for -mavx10.1-256 and -mavx10.1-512
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113288 Bug ID: 113288 Summary: [i386] Missing #define for -mavx10.1-256 and -mavx10.1-512 Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: burnus at gcc dot gnu.org CC: haochen.jiang at intel dot com, hongyuw at gcc dot gnu.org Target Milestone: --- Target: i386,x86_64 As noted in https://gcc.gnu.org/pipermail/gcc-patches/2024-January/642025.html There is not #define for -mavx10.1-256 and -mavx10.1-512 By contrast, there is one for, e.g., __AVX10_512BIT__ and "avx10-max-512bit" __AVX10_1__ and "avx10.1" __AMX_FP16__ and -mamx-fp16 etc.
[Bug sanitizer/113251] [14 Regression] ICE on gcc.dg/asan/pr63845.c on i686-linux since r14-6946
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113251 Richard Biener changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #4 from Richard Biener --- Fixed.
[Bug libstdc++/113258] Pre-C++17 code that supplies operator new/delete crashes when mixed with post-C+17 code that uses the align_val_t variants of new/delete
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113258 --- Comment #20 from Andrew Pinski --- So if you use an old tcmalloc and a c11 or c++1 library use aligned_alloc it would crash in the same way. Is that the same as this issue here, yes. Is it an abi change, NO because the abi for malloc displacement is not technically a stable one and would be a glibc issue rather than a gcc/libstdc++ one. It just happens libstdc++ uses aligned_alloc.
[Bug libstdc++/113258] Pre-C++17 code that supplies operator new/delete crashes when mixed with post-C+17 code that uses the align_val_t variants of new/delete
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113258 --- Comment #19 from Nicholas Miell --- (In reply to Jonathan Wakely from comment #17) > It's irrelevant whether C++14 has aligned_alloc, since libstdc++ doesn't > provide that anyway. What matters is whether the underlying libc provides > it. If it does, we call it. > Yeah, and I'm saying that you can't use aligned_alloc, specifically because libstdc++.so.6 is supposed to be backwards compatible with binaries that predate C11 and C++11 (or target versions of C/C++ before then), and because the language spec allows programs to displace operator new and delete and (in practice) programs that do that are also going to replace the C malloc functions *but only the C malloc functions that existed at the time*. In fact, instead of over-allocating and then aligning the returned pointer in the enlarged region, you can probably get away with using posix_memalign instead of aligned_alloc. That dates back to 2001, before the libstdc++.so.5 to 6 SONAME bump and any allocator replacement you're going to encounter in libstdc++.so.6 would've had to deal with the fact that free() has to be able to free pointers returned from posix_memalign(). > The problem has ABSOLUTELY NOTHING to do with replacing new/delete, it's > ENTIRELY due to replacing malloc/free. > > You would get exactly the same problem in C code if your library using an > old tcmalloc was called by a new application that used aligned_alloc and > then called free, resulting in a call to the old tcmalloc free. > And if that were to happen it would have to be dealt with in some other way, but in this particular oddball case where the C++ standard has an underspecified poorly thought out feature, it unfortunately becomes the C++ runtime's problem to deal with. You're going to have to deal with this anyway if libstdc++ ever starts using the aligned new and delete operators internally, because libstdc++ has to stay compatible with programs that predate aligned_alloc. > This is not a libstdc++ problem, nor a C++ problem. > > If you want to blame the ABI break on something, blame C11 for adding > aligned_alloc and requiring that free can handle it. Libstdc++ has no way to > know if the version of free present at runtime can handle aligned_alloc. All > we can tell is that aligned_alloc exists, we can't tell whether some library > that might be linked to later breaks the libc ABI by replacing free in a way > that makes aligned_alloc unusable. You can use dladdr() to figure out which shared libraries a symbol comes from and then make decisions about which features to used based on which subset of symbols come from which libraries. It probably could be done from an IFUNC resolver. Seems like overkill, though. Not using aligned_alloc at all would be easier.
[Bug tree-optimization/113271] [Regression] Wrong code at -O1/2/3 since GCC-9 (could be due to wrong optimization)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113271 --- Comment #3 from Yi <652023330028 at smail dot nju.edu.cn> --- (In reply to Xi Ruoyao from comment #2) > -fsanitize=undefined is even explicitly mentioned in the bug report > guideline at https://gcc.gnu.org/bugs/. And the red banner in the new bug > page also mentions -fwrapv. I'm sorry about this issue. I knew what you mentioned. I seemed a little out of my mind when I brought up the issue. (In reply to Jakub Jelinek from comment #1) > This is UB, as can be seen if you compile with -fsanitize=undefined: I'm sorry again.
[Bug tree-optimization/113271] [Regression] Wrong code at -O1/2/3 since GCC-9 (could be due to wrong optimization)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113271 Xi Ruoyao changed: What|Removed |Added CC||xry111 at gcc dot gnu.org --- Comment #2 from Xi Ruoyao --- -fsanitize=undefined is even explicitly mentioned in the bug report guideline at https://gcc.gnu.org/bugs/. And the red banner in the new bug page also mentions -fwrapv.
[Bug rtl-optimization/113287] New: wrong code with __builtin_mul_overflow_p() and _BitInt() with -O3 -msse4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113287 Bug ID: 113287 Summary: wrong code with __builtin_mul_overflow_p() and _BitInt() with -O3 -msse4 Product: gcc Version: 14.0 Status: UNCONFIRMED Keywords: wrong-code Severity: normal Priority: P3 Component: rtl-optimization Assignee: unassigned at gcc dot gnu.org Reporter: zsojka at seznam dot cz Target Milestone: --- Host: x86_64-pc-linux-gnu Target: x86_64-pc-linux-gnu Created attachment 57013 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57013=edit reduced testcase I don't know if this is a _BitInt() issue, or if it's related to PR113144 (or is a standalone issue), since it appears only when vectorisation is enabled. Output: $ x86_64-pc-linux-gnu-gcc -O3 -msse4 testcase.c $ ./a.out Aborted $ 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-7009-20240108175617-ga17299c17af-checking-yes-rtl-df-extra-nobootstrap-amd64/bin/../libexec/gcc/x86_64-pc-linux-gnu/14.0.0/lto-wrapper Target: x86_64-pc-linux-gnu Configured with: /repo/gcc-trunk//configure --enable-languages=c,c++ --enable-valgrind-annotations --disable-nls --enable-checking=yes,rtl,df,extra --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-7009-20240108175617-ga17299c17af-checking-yes-rtl-df-extra-nobootstrap-amd64 Thread model: posix Supported LTO compression algorithms: zlib zstd gcc version 14.0.0 20240108 (experimental) (GCC)
[Bug target/113115] [14 Regression] ICE In extract_constrain_insn_cached recog.cc with ppc64le-linux-gnu crosscompiler from r14-3592-g9ea1248604d7b6
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113115
--- Comment #5 from Peter Bergner ---
(In reply to Kewen Lin from comment #4)
> Yes, I agree it's duplicated of PR109987, Jeevitha's commit just exposed
> this known issue, since we are in stage 3, I wonder if we can go with
> power9-vector guarding first
> (https://gcc.gnu.org/pipermail/gcc-patches/2021-December/587310.html) since
> power9-vector still exists in this release, and we can try to remove these
> workaround options in next release. (Sorry that I missed to follow up the
> power{8,9}-vector removal)
I really dislike the -mpower{8,9}-vector options, but maybe it's too late to
remove them for this release? I'm not sure how involved/invasive that patch
would be. Segher, do you have a preference on remove them now or use the
workaround above and remove in the next release?
[Bug c++/62240] A using-declaration within a class can publish a public base of a private base.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62240 Andrew Pinski changed: What|Removed |Added CC||jlame646 at gmail dot com --- Comment #2 from Andrew Pinski --- *** Bug 113286 has been marked as a duplicate of this bug. ***
[Bug c++/113286] GCC accepts invalid program involving cast to protected base class
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113286 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #1 from Andrew Pinski --- Dup of bug 62240. *** This bug has been marked as a duplicate of bug 62240 ***
[Bug tree-optimization/113144] [14 regression] ICE when building dpkg-1.21.15 in verify_dominators (error: dominator of 9 should be 48, not 12)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113144 --- Comment #12 from Tamar Christina --- (In reply to Andrew Pinski from comment #11) > (In reply to Zdenek Sojka from comment #10) > > Created attachment 57009 [details] > > simpler testcase using _BitInt() > > > > $ x86_64-pc-linux-gnu-gcc -O3 -mavx2 testcase.c > > testcase.c: In function 'foo': > > testcase.c:5:1: error: dominator of 24 should be 57, not 12 > > 5 | foo (void) > > | ^~~ > > testcase.c:5:1: error: dominator of 25 should be 57, not 12 > > during GIMPLE pass: vect > > testcase.c:5:1: internal compiler error: in verify_dominators, at > > dominance.cc:1194 > > 0x742528 verify_dominators(cdi_direction) > > ... > > that might be a different issue ... It's the same issue, but also fixed by the patch. It's however not simpler :) this expands into a series of loops, and one of the loops has 3 exits which is why it triggers. The fixes that I am re-spinning fixes this and correctly vectorizes the loops.
[Bug c++/113286] New: GCC accepts invalid program involving cast to protected base class
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113286
Bug ID: 113286
Summary: GCC accepts invalid program involving cast to
protected base class
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 invalid program is accepted only by gcc.
https://godbolt.org/z/73Mh9bres
```
struct A {};
struct B: public A {int stuff() {return 5;} };
struct C: protected B { using B::A; };
void call(A &) {}
int main()
{
C c;
call(c);
}
```
[Bug middle-end/107840] ICE when compiling cursed setjmp/longjmp nested function calls and non-local jumps
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107840 Andrew Pinski changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE --- Comment #7 from Andrew Pinski --- Dup of bug 40317. *** This bug has been marked as a duplicate of bug 40317 ***
[Bug middle-end/40317] verify_flow_info ICE with nested functions and non-local goto/labels
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=40317 Andrew Pinski changed: What|Removed |Added CC||gabravier at gmail dot com --- Comment #4 from Andrew Pinski --- *** Bug 107840 has been marked as a duplicate of this bug. ***
[Bug middle-end/40317] verify_flow_info ICE with nested functions and non-local goto/labels
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=40317 Andrew Pinski changed: What|Removed |Added CC||iamanonymous.cs at gmail dot com --- Comment #3 from Andrew Pinski --- *** Bug 113285 has been marked as a duplicate of this bug. ***
[Bug middle-end/113285] ICE: verify_flow_info failed with nested functions and non-local gotos
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113285 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #1 from Andrew Pinski --- Dup of bug 40317. *** This bug has been marked as a duplicate of bug 40317 ***
[Bug testsuite/113278] analyzer tests relying on fileno() fail on arm-eabi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113278 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever confirmed|0 |1 Last reconfirmed||2024-01-09 --- Comment #2 from Andrew Pinski --- So for C++, -std=c++98 (and others) are passed which causes __STRICT_ANSI__ to be defined which in turn newlib decides not to enable POSIX functions (via defining _DEFAULT_SOURCE which defines _POSIX_SOURCE). So confirmed, this is just a testsuite issue and the simple way of fixing this is to add -D_GNU_SOURCE to the command line options which causes the POSIX functions in stdio.h to be declared.
[Bug tree-optimization/113285] New: ICE: verify_flow_info failed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113285
Bug ID: 113285
Summary: ICE: verify_flow_info failed
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: iamanonymous.cs at gmail dot com
Target Milestone: ---
Compiler Explorer: https://godbolt.org/z/8Ebhao48a
***
OS and Platform:
$ uname -a:
Linux ubuntu 4.15.0-213-generic #224-Ubuntu SMP Mon Jun 19 13:30:12 UTC 2023
x86_64 x86_64 x86_64 GNU/Linux
***
gcc version:
$ gcc -v
Using built-in specs.
COLLECT_GCC=/root/gcc_set/202311291030/bin/gcc
COLLECT_LTO_WRAPPER=/root/gcc_set/202311291030/libexec/gcc/x86_64-pc-linux-gnu/14.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc/configure --prefix=/root/gcc_set/202311291030
--with-gmp=/root/build_essential --with-mpfr=/root/build_essential
--with-mpc=/root/build_essential --enable-languages=c,c++ --disable-multilib
--with-sanitizer=address,undefined,thread,leak
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 14.0.0 20231129 (experimental) (GCC)
git version: 99fa0bfd63d97825c4221dcd3123940f1d0e6291
***
Program:
$ cat mutant.c
void f(void)
{
void p(void)
{
__label__ l1;
void q(void)
{
goto l1;
}
l1:;
}
p();
}
***
Command Lines:
$ gcc mutant.c
mutant.c: In function ‘p’:
mutant.c:3:8: error: label ‘({anonymous})’ has incorrect context in bb 4
3 | void p(void)
|^
during GIMPLE pass: cfg
mutant.c:3:8: internal compiler error: verify_flow_info failed
0xae444e verify_flow_info()
../../gcc/gcc/cfghooks.cc:287
0x1066aac checking_verify_flow_info()
../../gcc/gcc/cfghooks.h:214
0x1066aac cleanup_tree_cfg_noloop
../../gcc/gcc/tree-cfgcleanup.cc:1154
0x1066aac cleanup_tree_cfg(unsigned int)
../../gcc/gcc/tree-cfgcleanup.cc:1205
0x105e6f4 execute_build_cfg
../../gcc/gcc/tree-cfg.cc:378
0x105e6f4 execute
../../gcc/gcc/tree-cfg.cc:412
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See
[Bug libstdc++/113283] missing C++26 freestanding headers.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113283 Andrew Pinski changed: What|Removed |Added Severity|normal |enhancement
[Bug tree-optimization/113281] [14 Regression] Wrong code due to vectorization of shift reduction and missing promotions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113281 --- Comment #9 from Andrew Pinski --- (In reply to JuzheZhong from comment #8) > It should be mismatch on both RISC-V and ARM SVE with -fno-vect-cost-model. Changed and checked to see that GCC 13 didn't vectorize the loop for aarch64 SVE either so it is a regression.
[Bug tree-optimization/113281] [14 Regression] Wrong code due to vectorization of shift reduction and missing promotions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113281 Andrew Pinski changed: What|Removed |Added Summary|[14] RISC-V rv64gcv_zvl256b |[14 Regression] Wrong code |vector: Runtime mismatch|due to vectorization of |with rv64gc |shift reduction and missing ||promotions Target Milestone|--- |14.0 Known to work||13.2.0
[Bug tree-optimization/113281] [14] RISC-V rv64gcv_zvl256b vector: Runtime mismatch with rv64gc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113281 --- Comment #8 from JuzheZhong --- (In reply to Andrew Pinski from comment #7) > > short b = a = 0; > > s/short/int/ allows it to work ... Thanks Andrew. I think we should change the tittle. It should be mismatch on both RISC-V and ARM SVE with -fno-vect-cost-model.
[Bug tree-optimization/113281] [14] RISC-V rv64gcv_zvl256b vector: Runtime mismatch with rv64gc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113281 --- Comment #7 from Andrew Pinski --- > short b = a = 0; s/short/int/ allows it to work ...
[Bug tree-optimization/113281] [14] RISC-V rv64gcv_zvl256b vector: Runtime mismatch with rv64gc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113281 Andrew Pinski changed: What|Removed |Added Last reconfirmed||2024-01-09 Status|UNCONFIRMED |NEW Ever confirmed|0 |1 Component|target |tree-optimization Target|riscv |riscv aarch64-linux-gnu --- Comment #6 from Andrew Pinski --- Confirmed on aarch64 too: [apinski@xeond2 upstream-full-cross]$ ./install/bin/aarch64-linux-gnu-gcc -O3 -march=armv9-a+sve2 t.c -static -fno-vect-cost-model [apinski@xeond2 upstream-full-cross]$ ./install-qemu/bin/qemu-aarch64 a.out ;echo $? 1
[Bug target/113281] [14] RISC-V rv64gcv_zvl256b vector: Runtime mismatch with rv64gc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113281
--- Comment #5 from JuzheZhong ---
(In reply to JuzheZhong from comment #4)
> Confirm reduced case:
>
> #include
> unsigned char a;
>
> int main() {
> short b = a = 0;
> for (; a != 19; a++)
> if (a)
> b = 32872 >> a;
>
> assert (b == 0);
> }
>
> with -fno-vect-cost-model -march=rv64gcv -O3:
>
> https://godbolt.org/z/joGb3e9Eb
>
> Also run failed assertion "b == 0" failed: file "bug.c", line 10, function:
> main
>
> I suspect ARM SVE has the same fail.
>
> Hi, Andrew. Could you test this case on ARM to see whether ARM has same
> issue as RISC-V for me ?
The vect dump tree is quite similar between ARM and RISC-V.
[Bug target/113115] [14 Regression] ICE In extract_constrain_insn_cached recog.cc with ppc64le-linux-gnu crosscompiler from r14-3592-g9ea1248604d7b6
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113115
Kewen Lin changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|--- |DUPLICATE
--- Comment #4 from Kewen Lin ---
(In reply to Peter Bergner from comment #3)
> Ke Wen, is this just a duplicate of PR109987 and PR103627? I know it was
> bisected to Jeevitha's commit, but it seems more like her commit exposed the
> same latent issue as those other PRs, rather than causing it. Your thoughts?
Yes, I agree it's duplicated of PR109987, Jeevitha's commit just exposed this
known issue, since we are in stage 3, I wonder if we can go with power9-vector
guarding first
(https://gcc.gnu.org/pipermail/gcc-patches/2021-December/587310.html) since
power9-vector still exists in this release, and we can try to remove these
workaround options in next release. (Sorry that I missed to follow up the
power{8,9}-vector removal)
*** This bug has been marked as a duplicate of bug 109987 ***
[Bug target/109987] ICE in in rs6000_emit_le_vsx_store on ppc64le with -Ofast -mno-power8-vector
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109987 Kewen Lin changed: What|Removed |Added CC||fkastl at suse dot cz --- Comment #2 from Kewen Lin --- *** Bug 113115 has been marked as a duplicate of this bug. ***
[Bug target/113281] [14] RISC-V rv64gcv_zvl256b vector: Runtime mismatch with rv64gc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113281
--- Comment #4 from JuzheZhong ---
Confirm reduced case:
#include
unsigned char a;
int main() {
short b = a = 0;
for (; a != 19; a++)
if (a)
b = 32872 >> a;
assert (b == 0);
}
with -fno-vect-cost-model -march=rv64gcv -O3:
https://godbolt.org/z/joGb3e9Eb
Also run failed assertion "b == 0" failed: file "bug.c", line 10, function:
main
I suspect ARM SVE has the same fail.
Hi, Andrew. Could you test this case on ARM to see whether ARM has same issue
as RISC-V for me ?
[Bug target/113087] [14] RISC-V rv64gcv vector: Runtime mismatch with rv64gc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113087 --- Comment #29 from Li Pan --- (In reply to Patrick O'Neill from comment #27) > Linking the discussion/plan here since more interested people are CCd here. > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113206#c9 > Using 4a0a8dc1b88408222b88e10278017189f6144602, the spec run failed on: > zvl128b (All runtime fails): > 527.cam4 (Runtime) > 531.deepsjeng (Runtime) > 521.wrf (Runtime) > 523.xalancbmk (Runtime) > > zvl256b: > 507.cactuBSSN (Runtime) > 521.wrf (Build) > 527.cam4 (Runtime) > 531.deepsjeng (Runtime) > 549.fotonik3d (Runtime) > > With that info I think the next steps are: > 1. Triage the zvl256b 521.wrf build failure > 2. Bisect the newly-failing testcases > 3. Finish triaging the remaining testcases the fuzzer found > 4. Attempt to manually reduce cam4 for zvl128b (since it seems to have the > fastest build+runtime) > 5. Attempt to manually reduce other fails. Hi Patrick, Thanks a lot for the summary. Could you please help to share some more information about the spec2017 for above data? Like data set (test, train, or ref), the enviornment (qemu, spike, or hardware) as well as the spec config file. Just would like to make sure we are on the same page for the failures and reproducible from others. Thanks again. Pan
[Bug target/113281] [14] RISC-V rv64gcv_zvl256b vector: Runtime mismatch with rv64gc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113281 --- Comment #3 from JuzheZhong --- I think there are 2 issues here: 1. We should adjust cost model to let loop vectorizer eliminate the unprofitable vectorization. It should be done in RISC-V backend. 2. We should fix run fail bug with -fno-vect-cost-model. I think 1st issue is simpler than second one. And I highly doubt that the second one is not RISC-V bug is middle-end bug.
[Bug target/113249] RISC-V: regression testsuite errors -mtune=generic-ooo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113249 --- Comment #3 from Edwin Lu --- (In reply to Edwin Lu from comment #2) > > If there are new execution failures that would be more concerning and > > indicate a real bug. > I've gone through a few of the differences between rocket and generic-ooo > and found PR113248 which Pan helped fix. I'm not familiar enough with rvv to > be able to identify if there's a bug hidden in the assembly though. Whoops misread the author. Thanks to Pan and Juzhe for fixing the bug
[Bug target/113249] RISC-V: regression testsuite errors -mtune=generic-ooo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113249 --- Comment #2 from Edwin Lu --- (In reply to Robin Dapp from comment #1) > Yes, several (most?) of those are expected because the tests rely on the > default latency model. One option is to hard code the tune in those tests. > On the other hand the dump tests checking for a more or less optimal code > sequence (under certain conditions and regardless of uarch of course) and > deviation from that sequence might also indicate sub-optimal code. I > commented on this a bit when first introducing generic-ooo. > One of the reasons I've been testing things with generic-ooo is because generic-ooo had initial vector pipelines defined. For cleaning up the scheduler, I copied over the generic-ooo pipelines into generic and sifive-7 md files. As you mentioned, the scan dump fails are likely less optimal code sequences for the as a result of the cost model. I'm planning on sending up a patch in my series that adds -fno-schedule-insns -fno-schedule-insns2 to the dump scan tests that fail but do you think it would be better to hard code the tune instead? > If there are new execution failures that would be more concerning and > indicate a real bug. I've gone through a few of the differences between rocket and generic-ooo and found PR113248 which Pan helped fix. I'm not familiar enough with rvv to be able to identify if there's a bug hidden in the assembly though.
[Bug target/113248] RISC-V: Invalid vsetvli fusion using -mtune=generic-ooo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113248 Edwin Lu changed: What|Removed |Added Resolution|--- |FIXED Status|UNCONFIRMED |RESOLVED --- Comment #2 from Edwin Lu --- Appears to be fixed. Thanks!
[Bug libstdc++/113283] missing C++26 freestanding headers.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113283 --- Comment #4 from cqwrteur --- Created attachment 57012 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57012=edit Proposed errno numbers These numbers come from Linux Kernel Headers and redhat Newlib-Cygwin. I guess these numbers would be ok and commonly agreed. If you think this is ok, i will start working on clang and libcxx to use these numbers.
[Bug sanitizer/113284] [14 regression] many failures in asan after r14-6946-ge66dc37b299cac
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113284
--- Comment #3 from seurer at gcc dot gnu.org ---
There was a mistake in my report. This was on a power 9 BE system, not LE.
Configure was:
/home/seurer/gcc/git/gcc-test/configure
--prefix=/home/seurer/gcc/git/install/gcc-test --enable-languages=c,fortran,c++
--enable-secureplt --with-cpu=power9 --disable-bootstrap --enable-multilib
g:e66dc37b299cac4171b1c5b90cf6b54388bd5bc5, r14-6946-ge66dc37b299cac
make -k check-gcc RUNTESTFLAGS="--target_board=unix'{-m32,-m64}'
asan.exp=c-c++-common/asan/alloca_loop_unpoisoning.c"
FAIL: c-c++-common/asan/alloca_loop_unpoisoning.c -O0 (test for excess
errors)
FAIL: c-c++-common/asan/alloca_loop_unpoisoning.c -O1 (test for excess
errors)
FAIL: c-c++-common/asan/alloca_loop_unpoisoning.c -O2 (test for excess
errors)
FAIL: c-c++-common/asan/alloca_loop_unpoisoning.c -O3 -fomit-frame-pointer
-funroll-loops -fpeel-loops -ftracer -finline-functions (test for excess
errors)
FAIL: c-c++-common/asan/alloca_loop_unpoisoning.c -O3 -g (test for excess
errors)
FAIL: c-c++-common/asan/alloca_loop_unpoisoning.c -Os (test for excess
errors)
FAIL: c-c++-common/asan/alloca_loop_unpoisoning.c -O2 -flto
-fno-use-linker-plugin -flto-partition=none (test for excess errors)
FAIL: c-c++-common/asan/alloca_loop_unpoisoning.c -O2 -flto
-fuse-linker-plugin -fno-fat-lto-objects (test for excess errors)
FAIL: c-c++-common/asan/alloca_loop_unpoisoning.c -O0 (test for excess
errors)
FAIL: c-c++-common/asan/alloca_loop_unpoisoning.c -O1 (test for excess
errors)
FAIL: c-c++-common/asan/alloca_loop_unpoisoning.c -O2 (test for excess
errors)
FAIL: c-c++-common/asan/alloca_loop_unpoisoning.c -O3 -fomit-frame-pointer
-funroll-loops -fpeel-loops -ftracer -finline-functions (test for excess
errors)
FAIL: c-c++-common/asan/alloca_loop_unpoisoning.c -O3 -g (test for excess
errors)
FAIL: c-c++-common/asan/alloca_loop_unpoisoning.c -Os (test for excess
errors)
FAIL: c-c++-common/asan/alloca_loop_unpoisoning.c -O2 -flto
-fno-use-linker-plugin -flto-partition=none (test for excess errors)
FAIL: c-c++-common/asan/alloca_loop_unpoisoning.c -O2 -flto
-fuse-linker-plugin -fno-fat-lto-objects (test for excess errors)
[Bug modula2/112920] gm2 hangs in the type resolver
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112920 --- Comment #2 from Gaius Mulley --- Created attachment 57011 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57011=edit Proposed fix Here is a proposed fix which compiles the previous attached test cases and causes no extra regression test failures.
[Bug libstdc++/113283] missing C++26 freestanding headers.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113283 --- Comment #3 from cqwrteur --- I do not see errno.h in freestanding C. Am i correct? Should compiler provide an errno.h? https://en.cppreference.com/w/c/language/conformance
[Bug target/112817] RISC-V: RVV: provide attribute riscv_rvv_vector_bits for VLS codegen
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112817 --- Comment #11 from Andrew Pinski --- (In reply to Vineet Gupta from comment #9) > I was looking for a new entry in gcc/c-family/c-attribs.cc or would be > somewhere else. It would more likely be in config/riscv/riscv.cc defined in riscv_attribute_table.
[Bug libstdc++/113283] missing C++26 freestanding headers.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113283 --- Comment #2 from cqwrteur --- (In reply to Jonathan Wakely from comment #1) > We can just make up our own numbers, since we won't be getting errno values > from the OS. i would like to make libcxx to have the same numbers as libstdc++. My proposed patches before to libcxx was using linux's errno numbers as the fallback if __has_include_next() does not exist. What do you think?
[Bug target/112817] RISC-V: RVV: provide attribute riscv_rvv_vector_bits for VLS codegen
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112817 --- Comment #10 from JuzheZhong --- Yes. I haven't support VLS attributes. I guess kito may have some ideas.
[Bug target/112817] RISC-V: RVV: provide a preprocessor macro for VLS codegen
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112817 --- Comment #9 from Vineet Gupta --- (In reply to JuzheZhong from comment #5) > Support VLS codegen with -mrvv-vector-bits and attribute is reasonable to be > landed on GCC-14. > > Could you first implement -mrvv-vector-bits feature ? > > I have support it in rvv-next, but I don't have time to migrate that into > trunk GCC. I presume you are referring to https://github.com/riscv-collab/riscv-gcc.git and #riscv-gcc-rvv-next I don't see the attribute support. Is it called something else there ? I was looking for a new entry in gcc/c-family/c-attribs.cc or would be somewhere else.
[Bug libstdc++/113283] missing C++26 freestanding headers.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113283 Jonathan Wakely changed: What|Removed |Added Blocks||110339 --- Comment #1 from Jonathan Wakely --- We can just make up our own numbers, since we won't be getting errno values from the OS. Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110339 [Bug 110339] Implement C++26 library features
[Bug target/113282] RISC-V non-atomic union store/load reordering
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113282 Andrew Pinski changed: What|Removed |Added Resolution|FIXED |INVALID --- Comment #5 from Andrew Pinski --- It is even mentioned here: https://gcc.gnu.org/bugs/#nonbugs
[Bug libgomp/113192] [11/12/13/14 Regression] ERROR: couldn't execute "../../../gcc/libgomp/testsuite/flock": no such file or directory
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113192
--- Comment #5 from dave.anglin at bell dot net ---
On 2024-01-08 3:49 p.m., jakub at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113192
>
> --- Comment #4 from Jakub Jelinek ---
> What about:
> --- libgomp/configure.ac.jj 2023-11-02 07:49:21.693801244 +0100
> +++ libgomp/configure.ac2024-01-08 21:46:21.014765685 +0100
> @@ -343,7 +343,7 @@ AX_COUNT_CPUS
> AC_CHECK_PROGS(FLOCK, flock)
> # Fallback if 'perl' is available.
> if test -z "$FLOCK"; then
> - AC_CHECK_PROG(FLOCK, perl, $srcdir/testsuite/flock)
> + AC_CHECK_PROG(FLOCK, perl, \$(abs_top_srcdir)/testsuite/flock)
> fi
>
> AC_SUBST(SYSROOT_CFLAGS_FOR_TARGET)
> --- libgomp/configure.jj2024-01-06 02:29:24.566795886 +0100
> +++ libgomp/configure 2024-01-08 21:46:23.799726387 +0100
> @@ -16655,7 +16655,7 @@ do
> test -z "$as_dir" && as_dir=.
> for ac_exec_ext in '' $ac_executable_extensions; do
> if as_fn_executable_p "$as_dir/$ac_word$ac_exec_ext"; then
> -ac_cv_prog_FLOCK="$srcdir/testsuite/flock"
> +ac_cv_prog_FLOCK="\$(abs_top_srcdir)/testsuite/flock"
> $as_echo "$as_me:${as_lineno-$LINENO}: found
> $as_dir/$ac_word$ac_exec_ext"
>> &5
> break 2
> fi
>
Works.
Thanks,
Dave
[Bug target/113282] RISC-V non-atomic union store/load reordering
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113282 Patrick O'Neill changed: What|Removed |Added Resolution|INVALID |FIXED --- Comment #4 from Patrick O'Neill --- Thanks for the explanation! I didn't know about strict aliasing :)
[Bug sanitizer/113284] [14 regression] many failures in asan after r14-6946-ge66dc37b299cac
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113284 Andrew Pinski changed: What|Removed |Added Keywords||link-failure --- Comment #2 from Andrew Pinski --- Also provide the exact binutils version too since this might be dependent there.
[Bug sanitizer/113284] [14 regression] many failures in asan after r14-6946-ge66dc37b299cac
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113284 Ilya Leoshkevich changed: What|Removed |Added CC||iii at linux dot ibm.com --- Comment #1 from Ilya Leoshkevich --- Could you please share the configure command that you use? I originally regtested that patch on cfarm120 (POWER10) with `./configure --enable-checking=yes,rtl`, and I cannot reproduce the issue there.
[Bug target/113282] RISC-V non-atomic union store/load reordering
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113282 --- Comment #3 from Andrew Pinski --- Note -fno-strict-aliasing will allow the code to work the way you want it to work.
[Bug target/113282] RISC-V non-atomic union store/load reordering
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113282 --- Comment #2 from Andrew Pinski --- > On x86 this problem Yes x86 does not enable the scheduler before ra and has less registers so the scheduler is not as aggressive as on the other targets. Note this is standard strict aliasing issue even. Which is definitely mentioned as a non issue even.
[Bug sanitizer/113284] New: [14 regression] many failures in asan after r14-6946-ge66dc37b299cac
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113284 Bug ID: 113284 Summary: [14 regression] many failures in asan after r14-6946-ge66dc37b299cac Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: sanitizer Assignee: unassigned at gcc dot gnu.org Reporter: seurer at gcc dot gnu.org 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: --- g:e66dc37b299cac4171b1c5b90cf6b54388bd5bc5, r14-6946-ge66dc37b299cac I am seeing these on one of our powerpc64 LE systems. Looks like they are like this: ./gcc/testsuite/g++/g++.log:/home/seurer/gcc/git/gcc-test/gcc/testsuite/c-c++-common/asan/alloca_loop_unpoisoning.c:16:(.text+0x3e): undefined reference to `.LASANPC0' ./gcc/testsuite/g++/g++.log:/usr/bin/ld: /home/seurer/gcc/git/gcc-test/gcc/testsuite/c-c++-common/asan/alloca_loop_unpoisoning.c:16:(.text+0x5e): undefined reference to `.LASANPC0' FAIL: c-c++-common/asan/alloca_loop_unpoisoning.c -O0 (test for excess errors) FAIL: c-c++-common/asan/alloca_loop_unpoisoning.c -O0 (test for excess errors) FAIL: c-c++-common/asan/alloca_loop_unpoisoning.c -O1 (test for excess errors) FAIL: c-c++-common/asan/alloca_loop_unpoisoning.c -O1 (test for excess errors) FAIL: c-c++-common/asan/alloca_loop_unpoisoning.c -O2 (test for excess errors) FAIL: c-c++-common/asan/alloca_loop_unpoisoning.c -O2 (test for excess errors) FAIL: c-c++-common/asan/alloca_loop_unpoisoning.c -O2 -flto -fno-use-linker-plugin -flto-partition=none (test for excess errors) FAIL: c-c++-common/asan/alloca_loop_unpoisoning.c -O2 -flto -fno-use-linker-plugin -flto-partition=none (test for excess errors) FAIL: c-c++-common/asan/alloca_loop_unpoisoning.c -O2 -flto -fuse-linker-plugin -fno-fat-lto-objects (test for excess errors) FAIL: c-c++-common/asan/alloca_loop_unpoisoning.c -O2 -flto -fuse-linker-plugin -fno-fat-lto-objects (test for excess errors) FAIL: c-c++-common/asan/alloca_loop_unpoisoning.c -O3 -fomit-frame-pointer -funroll-loops -fpeel-loops -ftracer -finline-functions (test for excess errors) FAIL: c-c++-common/asan/alloca_loop_unpoisoning.c -O3 -fomit-frame-pointer -funroll-loops -fpeel-loops -ftracer -finline-functions (test for excess errors) FAIL: c-c++-common/asan/alloca_loop_unpoisoning.c -O3 -g (test for excess errors) FAIL: c-c++-common/asan/alloca_loop_unpoisoning.c -O3 -g (test for excess errors) FAIL: c-c++-common/asan/alloca_loop_unpoisoning.c -Os (test for excess errors) FAIL: c-c++-common/asan/alloca_loop_unpoisoning.c -Os (test for excess errors) FAIL: c-c++-common/asan/asan-interface-1.c -O0 (test for excess errors) FAIL: c-c++-common/asan/asan-interface-1.c -O0 (test for excess errors) FAIL: c-c++-common/asan/asan-interface-1.c -O1 (test for excess errors) FAIL: c-c++-common/asan/asan-interface-1.c -O1 (test for excess errors) FAIL: c-c++-common/asan/asan-interface-1.c -O2 (test for excess errors) FAIL: c-c++-common/asan/asan-interface-1.c -O2 (test for excess errors) FAIL: c-c++-common/asan/asan-interface-1.c -O2 -flto -fno-use-linker-plugin -flto-partition=none (test for excess errors) FAIL: c-c++-common/asan/asan-interface-1.c -O2 -flto -fno-use-linker-plugin -flto-partition=none (test for excess errors) FAIL: c-c++-common/asan/asan-interface-1.c -O2 -flto -fuse-linker-plugin -fno-fat-lto-objects (test for excess errors) FAIL: c-c++-common/asan/asan-interface-1.c -O2 -flto -fuse-linker-plugin -fno-fat-lto-objects (test for excess errors) FAIL: c-c++-common/asan/asan-interface-1.c -O3 -g (test for excess errors) FAIL: c-c++-common/asan/asan-interface-1.c -O3 -g (test for excess errors) FAIL: c-c++-common/asan/asan-interface-1.c -Os (test for excess errors) FAIL: c-c++-common/asan/asan-interface-1.c -Os (test for excess errors) FAIL: c-c++-common/asan/asan-stack-small.c -O0 (test for excess errors) FAIL: c-c++-common/asan/asan-stack-small.c -O0 (test for excess errors) FAIL: c-c++-common/asan/asan-stack-small.c -O1 (test for excess errors) FAIL: c-c++-common/asan/asan-stack-small.c -O1 (test for excess errors) FAIL: c-c++-common/asan/asan-stack-small.c -O2 (test for excess errors) FAIL: c-c++-common/asan/asan-stack-small.c -O2 (test for excess errors) FAIL: c-c++-common/asan/asan-stack-small.c -O2 -flto -fno-use-linker-plugin -flto-partition=none (test for excess errors) FAIL: c-c++-common/asan/asan-stack-small.c -O2 -flto -fno-use-linker-plugin -flto-partition=none (test for excess errors) FAIL: c-c++-common/asan/asan-stack-small.c -O2 -flto -fuse-linker-plugin -fno-fat-lto-objects (test for excess errors) FAIL: c-c++-common/asan/asan-stack-small.c -O2 -flto -fuse-linker-plugin -fno-fat-lto-objects (test for
[Bug target/113282] RISC-V non-atomic union store/load reordering
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113282 Andrew Pinski changed: What|Removed |Added Resolution|--- |INVALID Keywords||alias Status|UNCONFIRMED |RESOLVED --- Comment #1 from Andrew Pinski --- Int and long does not alias so moving the store past the load is a valid thing to do. Note the union does not make a difference here since it is not seen due taking the address of the fields.
[Bug target/113226] [14 Regression] testsuite/std/ranges/iota/max_size_type.cc fails for cris-elf after r14-6888-ga138b99646a555
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113226 Hans-Peter Nilsson changed: What|Removed |Added Component|testsuite |target --- Comment #4 from Hans-Peter Nilsson --- (In reply to Hans-Peter Nilsson from comment #3) > (In reply to Patrick Palka from comment #1) > > Huh, how bizarre. > > Indeed. I'm *not* ruling out an actual gcc bug. Whether in the target or > middle-end this time I dare not guess; too few posts. I don't see this FAIL for m68k-unknown-linux-gnu in https://gcc.gnu.org/pipermail/gcc-testresults/2024-January/804595.html so let's change to target component. I'll see if I can revive one of the other *-elf toolchains to the point where the libstdc++-v3 tests are useful before digging in. (But also subject to other priorities and unfortunately not among the highest.)
[Bug target/113281] [14] RISC-V rv64gcv_zvl256b vector: Runtime mismatch with rv64gc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113281
--- Comment #2 from Robin Dapp ---
Confirmed. Funny, we shouldn't vectorize that but really optimize to "return
0". Costing might be questionable but we also haven't optimized away the loop
when comparing costs.
Disregarding that, of course the vectorization should be correct.
The vect output doesn't really make sense to me but I haven't looked very
closely yet:
_177 = .SELECT_VL (2, POLY_INT_CST [16, 16]);
vect_patt_82.18_166 = (vector([16,16]) unsigned short) { 17, 18, 19, ... };
vect_patt_84.19_168 = MIN_EXPR ;
vect_patt_85.20_170 = { 32872, ... } >> vect_patt_84.19_168;
vect_patt_87.21_171 = VIEW_CONVERT_EXPR(vect_patt_85.20_170);
_173 = _177 + 18446744073709551615;
# RANGE [irange] short int [0, 16436] MASK 0x7fff VALUE 0x0
_174 = .VEC_EXTRACT (vect_patt_87.21_171, _173);
vect_patt_85.20_170 should be all zeros and then we'd just vec_extract a 0 and
return that. However, 32872 >> 15 == 1 so we return 1.
[Bug libstdc++/113283] New: missing C++26 freestanding headers.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113283 Bug ID: 113283 Summary: missing C++26 freestanding headers. Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: unlvsur at live dot com Target Milestone: --- C++26 adds things like cerrno to be freestanding. I do not know how you are going to support that. libcxx wants to forward the errno.h to the compiler side.
[Bug target/113282] New: RISC-V non-atomic union store/load reordering
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113282
Bug ID: 113282
Summary: RISC-V non-atomic union store/load reordering
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: patrick at rivosinc dot com
Target Milestone: ---
I'm not sure if this is a bug or a valid optimization. Posting this here to
educate myself :)
Testcase:
union {
long c;
int b;
} e;
int f;
int *g =
long *h =
int main() {
*g = 1;
if (*h == 1)
return 0;
else
return 1;
}
risc-v -O2:
main:
lui a5,%hi(h)
ld a5,%lo(h)(a5)
ld a0,0(a5)
lui a5,%hi(g)
ld a5,%lo(g)(a5) << Load
li a4,1
addia0,a0,-1
sneza0,a0
sw a4,0(a5) << Store pushed below the load
ret
f:
.zero 4
.zero 4
e:
.zero 8
h:
.dword e
g:
.dword e
My educated guess is that since the operations aren't marked as atomic, the
compiler is free to ignore the dependency and optimize the load before the
store. After marking the ops as atomic:
union {
long c;
int b;
} e;
int f;
int *g =
long *h =
int main() {
__atomic_store_n(g, 1, __ATOMIC_RELAXED);
if (__atomic_load_n(h, __ATOMIC_RELAXED) == 1)
return 0;
else
return 1;
}
The problem goes away:
main:
lui a5,%hi(g)
ld a5,%lo(g)(a5)
li a4,1
sw a4,0(a5) << Store remains above the load
lui a5,%hi(h)
ld a5,%lo(h)(a5)
ld a0,0(a5) << Load
addia0,a0,-1
sneza0,a0
ret
f:
.zero 4
.zero 4
e:
.zero 8
h:
.dword e
g:
.dword e
Is that a correct line of reasoning? On x86 this problem doesn't manifest so
it's also possibly a risc-v bug.
[Bug c/113262] [11/12/13/14 Regression] ICE when using [[gnu::copy("")]] attribute
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113262 Jakub Jelinek changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org --- Comment #3 from Jakub Jelinek --- Created attachment 57010 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57010=edit gcc14-pr113262.patch Ugh, what a mess. The function uses DECL_SOURCE_LOCATION (*node) heavily, even when it allows to be present also on types.
[Bug c/113262] [11/12/13/14 Regression] ICE when using [[gnu::copy("")]] attribute
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113262 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #2 from Jakub Jelinek --- Started to ICE with r10-4969-g1723e1bedb9545c45619c4023729755243524584
[Bug target/113115] [14 Regression] ICE In extract_constrain_insn_cached recog.cc with ppc64le-linux-gnu crosscompiler from r14-3592-g9ea1248604d7b6
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113115 Peter Bergner changed: What|Removed |Added CC||bergner at gcc dot gnu.org, ||dje at gcc dot gnu.org, ||linkw at gcc dot gnu.org, ||segher at gcc dot gnu.org --- Comment #3 from Peter Bergner --- Ke Wen, is this just a duplicate of PR109987 and PR103627? I know it was bisected to Jeevitha's commit, but it seems more like her commit exposed the same latent issue as those other PRs, rather than causing it. Your thoughts?
[Bug libgomp/113192] [11/12/13/14 Regression] ERROR: couldn't execute "../../../gcc/libgomp/testsuite/flock": no such file or directory
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113192
--- Comment #4 from Jakub Jelinek ---
What about:
--- libgomp/configure.ac.jj 2023-11-02 07:49:21.693801244 +0100
+++ libgomp/configure.ac2024-01-08 21:46:21.014765685 +0100
@@ -343,7 +343,7 @@ AX_COUNT_CPUS
AC_CHECK_PROGS(FLOCK, flock)
# Fallback if 'perl' is available.
if test -z "$FLOCK"; then
- AC_CHECK_PROG(FLOCK, perl, $srcdir/testsuite/flock)
+ AC_CHECK_PROG(FLOCK, perl, \$(abs_top_srcdir)/testsuite/flock)
fi
AC_SUBST(SYSROOT_CFLAGS_FOR_TARGET)
--- libgomp/configure.jj2024-01-06 02:29:24.566795886 +0100
+++ libgomp/configure 2024-01-08 21:46:23.799726387 +0100
@@ -16655,7 +16655,7 @@ do
test -z "$as_dir" && as_dir=.
for ac_exec_ext in '' $ac_executable_extensions; do
if as_fn_executable_p "$as_dir/$ac_word$ac_exec_ext"; then
-ac_cv_prog_FLOCK="$srcdir/testsuite/flock"
+ac_cv_prog_FLOCK="\$(abs_top_srcdir)/testsuite/flock"
$as_echo "$as_me:${as_lineno-$LINENO}: found $as_dir/$ac_word$ac_exec_ext"
>&5
break 2
fi
[Bug fortran/113245] SIZE with optional DIM argument that has the OPTIONAL+VALUE attributes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113245 anlauf at gcc dot gnu.org changed: What|Removed |Added Resolution|--- |FIXED Target Milestone|--- |14.0 Status|ASSIGNED|RESOLVED --- Comment #4 from anlauf at gcc dot gnu.org --- Fixed.
[Bug testsuite/94253] FAIL: gfortran.dg/bind_c_coms.f90 -O0 (test for excess errors)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94253 John David Anglin changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #5 from John David Anglin --- Fixed on trunk.
[Bug testsuite/94253] FAIL: gfortran.dg/bind_c_coms.f90 -O0 (test for excess errors)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94253 --- Comment #4 from GCC Commits --- The master branch has been updated by John David Anglin : https://gcc.gnu.org/g:932b8d077c23986da5279bf8b5d84875de1fb826 commit r14-7015-g932b8d077c23986da5279bf8b5d84875de1fb826 Author: John David Anglin Date: Mon Jan 8 20:27:20 2024 + hppa: Fix bind_c_coms.f90 and bind_c_vars.f90 tests on hppa Commit 6271dd98 changed the default from -fcommon to -fno-common. This silently changed the alignment of uninitialized BSS data on hppa where the alignment of common data must be greater or equal to the alignment of the largest type that will fit in the block. For example, the alignment of `double d[2];' changed from 16 to 8 on hppa64. The hppa architecture requires strict alignment and the linker warns about inconsistent alignment of variables. This change broke the gfortran.dg/bind_c_coms.f90 and gfortran.dg/bind_c_vars.f90 tests. These tests check whether bind_c works between fortran and C. Adding the -fcommon option fixes the tests. Probably, gcc and HP C are now by default inconsistent but that's water under the bridge. 2024-01-08 John David Anglin gcc/testsuite/ChangeLog: PR testsuite/94253 * gfortran.dg/bind_c_coms.f90: Add -fcommon option on hppa*-*-*. * gfortran.dg/bind_c_vars.f90: Likewise.
[Bug tree-optimization/113144] [14 regression] ICE when building dpkg-1.21.15 in verify_dominators (error: dominator of 9 should be 48, not 12)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113144 --- Comment #11 from Andrew Pinski --- (In reply to Zdenek Sojka from comment #10) > Created attachment 57009 [details] > simpler testcase using _BitInt() > > $ x86_64-pc-linux-gnu-gcc -O3 -mavx2 testcase.c > testcase.c: In function 'foo': > testcase.c:5:1: error: dominator of 24 should be 57, not 12 > 5 | foo (void) > | ^~~ > testcase.c:5:1: error: dominator of 25 should be 57, not 12 > during GIMPLE pass: vect > testcase.c:5:1: internal compiler error: in verify_dominators, at > dominance.cc:1194 > 0x742528 verify_dominators(cdi_direction) > ... that might be a different issue ...
[Bug tree-optimization/113144] [14 regression] ICE when building dpkg-1.21.15 in verify_dominators (error: dominator of 9 should be 48, not 12)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113144 --- Comment #10 from Zdenek Sojka --- Created attachment 57009 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57009=edit simpler testcase using _BitInt() $ x86_64-pc-linux-gnu-gcc -O3 -mavx2 testcase.c testcase.c: In function 'foo': testcase.c:5:1: error: dominator of 24 should be 57, not 12 5 | foo (void) | ^~~ testcase.c:5:1: error: dominator of 25 should be 57, not 12 during GIMPLE pass: vect testcase.c:5:1: internal compiler error: in verify_dominators, at dominance.cc:1194 0x742528 verify_dominators(cdi_direction) ...
[Bug target/113249] RISC-V: regression testsuite errors -mtune=generic-ooo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113249 --- Comment #1 from Robin Dapp --- Yes, several (most?) of those are expected because the tests rely on the default latency model. One option is to hard code the tune in those tests. On the other hand the dump tests checking for a more or less optimal code sequence (under certain conditions and regardless of uarch of course) and deviation from that sequence might also indicate sub-optimal code. I commented on this a bit when first introducing generic-ooo. If there are new execution failures that would be more concerning and indicate a real bug.
[Bug target/113281] [14] RISC-V rv64gcv_zvl256b vector: Runtime mismatch with rv64gc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113281 Patrick O'Neill changed: What|Removed |Added Keywords||wrong-code CC||juzhe.zhong at rivai dot ai, ||patrick at rivosinc dot com, ||rdapp at gcc dot gnu.org, ||vineetg at rivosinc dot com Target||riscv --- Comment #1 from Patrick O'Neill --- Godbolt: https://godbolt.org/z/efPhqzcr5
[Bug target/113281] New: [14] RISC-V rv64gcv_zvl256b vector: Runtime mismatch with rv64gc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113281
Bug ID: 113281
Summary: [14] RISC-V rv64gcv_zvl256b vector: Runtime mismatch
with rv64gc
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: patrick at rivosinc dot com
Target Milestone: ---
Testcase:
unsigned char a;
int main() {
short b = a = 0;
for (; a != 19; a++)
if (a)
b = 32872 >> a;
if (b == 0)
return 0;
else
return 1;
}
Commands:
rv64gcv_zvl256b:
> /scratch/tc-testing/tc-jan-8-trunk/build-rv64gcv/bin/riscv64-unknown-linux-gnu-gcc
> -march=rv64gcv_zvl256b -O3 red.c -o user-config.out
> QEMU_CPU=rv64,vlen=256,v=true,vext_spec=v1.0,Zve32f=true,Zve64f=true timeout
> --verbose -k 0.1 1
> /scratch/tc-testing/tc-jan-8-trunk/build-rv64gcv/bin/qemu-riscv64
> user-config.out
> echo $?
1
rv64gc:
> /scratch/tc-testing/tc-jan-8-trunk/build-rv64gcv/bin/riscv64-unknown-linux-gnu-gcc
> -march=rv64gc -O3 red.c -o rv64gc.out
> QEMU_CPU=rv64,vlen=256,v=true,vext_spec=v1.0,Zve32f=true,Zve64f=true timeout
> --verbose -k 0.1 1
> /scratch/tc-testing/tc-jan-8-trunk/build-rv64gcv/bin/qemu-riscv64 rv64gc.out
> echo $?
0
[Bug rtl-optimization/113280] Strange error for empty inline assembly with +X constraint
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113280
--- Comment #2 from Andrew Pinski ---
(In reply to Andrew Pinski from comment #1)
> So the problem seems like combine decides somehow to
> combine:
> ```
> (insn 7 4 9 2 (set (reg/v:SF 100 [ xD.4459 ])
> (plus:SF (reg/v:SF 102 [ aD.4455 ])
> (reg/v:SF 103 [ bD.4456 ]))) "/app/example.cpp":6:7 1043 {addsf3}
> (expr_list:REG_DEAD (reg/v:SF 102 [ aD.4455 ])
> (nil)))
> (insn 9 7 10 2 (set (reg:SF 104 [ xD.4459 ])
> (asm_operands:SF ("") ("=X") 0 [
> (reg/v:SF 100 [ xD.4459 ])
> ]
> [
> (asm_input:SF ("0") /app/example.cpp:8)
> ]
> [] /app/example.cpp:8)) "/app/example.cpp":8:5 -1
> (expr_list:REG_DEAD (reg/v:SF 100 [ xD.4459 ])
> (nil)))
> into:
> ```
> (insn 9 7 10 2 (set (reg:SF 104 [ xD.4459 ])
> (asm_operands:SF ("") ("=X") 0 [
> (plus:SF (reg:SF 106)
> (reg/v:SF 103 [ bD.4456 ]))
> ]
> [
> (asm_input:SF ("0") /app/example.cpp:8)
> ]
> [] /app/example.cpp:8)) "/app/example.cpp":8:5 -1
> (expr_list:REG_DEAD (reg:SF 106)
> (nil)))
> ```
>
> But the dump from combine does not make sense:
> ```
> Trying 7 -> 9:
> 7: r100:SF=r106:SF+r103:SF
> REG_DEAD r106:SF
> 9: r104:SF=asm_operands
> REG_DEAD r100:SF
> Failed to match this instruction:
> (set (reg:SF 104 [ xD.4459 ])
> (asm_operands:SF ("") ("=X") 0 [
> (plus:SF (reg:SF 106)
> (reg/v:SF 103 [ bD.4456 ]))
> ]
> [
> (asm_input:SF ("0") /app/example.cpp:8)
> ]
> [] /app/example.cpp:8))
> allowing combination of insns 7 and 9
> original costs 8 + 4 = 12
> replacement cost 4
> deferring deletion of insn with uid = 7.
> modifying insn i3 9: r104:SF=asm_operands
> REG_DEAD r106:SF
> deferring rescan insn with uid = 9.
> ```
So basically check_asm_operands accepts the insn because the plus matches the
operand but this is an output operand which does not work as it is not an
lvalue ...
[Bug rtl-optimization/113280] Strange error for empty inline assembly with +X constraint
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113280
Andrew Pinski changed:
What|Removed |Added
Keywords|ra |
Ever confirmed|0 |1
Last reconfirmed||2024-01-08
Component|middle-end |rtl-optimization
Status|UNCONFIRMED |NEW
--- Comment #1 from Andrew Pinski ---
So the problem seems like combine decides somehow to
combine:
```
(insn 7 4 9 2 (set (reg/v:SF 100 [ xD.4459 ])
(plus:SF (reg/v:SF 102 [ aD.4455 ])
(reg/v:SF 103 [ bD.4456 ]))) "/app/example.cpp":6:7 1043 {addsf3}
(expr_list:REG_DEAD (reg/v:SF 102 [ aD.4455 ])
(nil)))
(insn 9 7 10 2 (set (reg:SF 104 [ xD.4459 ])
(asm_operands:SF ("") ("=X") 0 [
(reg/v:SF 100 [ xD.4459 ])
]
[
(asm_input:SF ("0") /app/example.cpp:8)
]
[] /app/example.cpp:8)) "/app/example.cpp":8:5 -1
(expr_list:REG_DEAD (reg/v:SF 100 [ xD.4459 ])
(nil)))
into:
```
(insn 9 7 10 2 (set (reg:SF 104 [ xD.4459 ])
(asm_operands:SF ("") ("=X") 0 [
(plus:SF (reg:SF 106)
(reg/v:SF 103 [ bD.4456 ]))
]
[
(asm_input:SF ("0") /app/example.cpp:8)
]
[] /app/example.cpp:8)) "/app/example.cpp":8:5 -1
(expr_list:REG_DEAD (reg:SF 106)
(nil)))
```
But the dump from combine does not make sense:
```
Trying 7 -> 9:
7: r100:SF=r106:SF+r103:SF
REG_DEAD r106:SF
9: r104:SF=asm_operands
REG_DEAD r100:SF
Failed to match this instruction:
(set (reg:SF 104 [ xD.4459 ])
(asm_operands:SF ("") ("=X") 0 [
(plus:SF (reg:SF 106)
(reg/v:SF 103 [ bD.4456 ]))
]
[
(asm_input:SF ("0") /app/example.cpp:8)
]
[] /app/example.cpp:8))
allowing combination of insns 7 and 9
original costs 8 + 4 = 12
replacement cost 4
deferring deletion of insn with uid = 7.
modifying insn i3 9: r104:SF=asm_operands
REG_DEAD r106:SF
deferring rescan insn with uid = 9.
```
[Bug analyzer/105102] RFE: analyzer handling for asprintf and vasprintf
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105102 --- Comment #1 from David Malcolm --- See also bug 113277
[Bug analyzer/113277] RFE: analyzer diagnose allocation error leading to pass NULL to snprintf
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113277 David Malcolm changed: What|Removed |Added Ever confirmed|0 |1 Status|UNCONFIRMED |NEW Last reconfirmed||2024-01-08 --- Comment #1 from David Malcolm --- Thanks for filing this report. As I understand it, snprintf can accept a NULL destination argument when the size is zero, but otherwise the destination argument must be non-NULL. Hence (as you note), we can't simply add the __nonnull__ attribute to the declaration. Currently the analyzer doesn't have any special-case knowledge of the behavior of sprintf. Looks like we should add it. In particular, looks like we should model the write to the destination buffer (and thus require the non-NULL-ness of the pointer for the known non-zero size case). See also RFE 105102.
[Bug sanitizer/113251] [14 Regression] ICE on gcc.dg/asan/pr63845.c on i686-linux since r14-6946
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113251 Andrew Pinski changed: What|Removed |Added CC||mjires at suse dot cz --- Comment #3 from Andrew Pinski --- *** Bug 113273 has been marked as a duplicate of this bug. ***
[Bug target/113273] [14 Regression][x86][asan] ICE Segmentation fault since r14-6946-ge66dc37b299cac
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113273 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #5 from Andrew Pinski --- Dup of bug 113251. *** This bug has been marked as a duplicate of bug 113251 ***
[Bug target/113273] [14 Regression][x86][asan] ICE Segmentation fault since r14-6946-ge66dc37b299cac
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113273 --- Comment #4 from Ilya Leoshkevich --- I've pushed the fix. This can be closed as a duplicate of https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113251.
[Bug c/113280] New: Strange error for empty inline assembly with +X constraint
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113280
Bug ID: 113280
Summary: Strange error for empty inline assembly with +X
constraint
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: david at westcontrol dot com
Target Milestone: ---
I am getting strange results with an empty inline assembly line, used as an
optimisation barrier. This is the test code I've tried in different setups:
#define opt 1
typedef int T;
T test(T a, T b) {
T x = a + b;
#if opt == 1
asm ("" : "+X" (x));
#endif
#if opt == 2
asm ("" : "+X" (x) : "0" (x));
#endif
#if opt == 3
asm ("" :: "X" (x));
asm ("" : "+X" (x));
#endif
return x - b;
}
The idea of the assembly line is to be an optimisation barrier - it forces the
compiler to calculate the value of "x" before the assembly line, and has to use
that value (rather than any pre-calculated information) after the assembly
line. This makes it something like an "asm("" ::: "memory")" barrier, but
focused on a single variable, which may not need to be moved out of registers.
I've found this kind of construct "asm("" : "+g" (x))" useful to control
ordering of code around disabled interrupt sections of embedded code, and it
can also force the order of floating point calculations even while -ffast-math
is used. Usually I've used "g" as the operand constraint, and that has worked
perfectly for everything except floating point types on targets that have
dedicated floating point registers.
I had expected "+X" (option 1 above) to work smoothly for floating point types.
And it does, sometimes - other times I get an error:
error: inconsistent operand constraints in an 'asm'
I've tested mainly on x86-64 (current trunk, which will be 14.0) and ARM 32-bit
(13.2), with -O2 optimisation. I get no errors with -O0, but there is no need
of an optimisation barrier if optimisation is not enabled! The exact compiler
version does not seem to make a difference, but the target does, as does the
type T.
I can't see why there should be a difference in the way these three variations
work, or why some combinations give errors. When there is no compiler error,
the code (in all my testing) has been optimal as intended.
Some test results:
T = float :
opt 1 arm-32 fail x86-64 fail
opt 2 arm-32 fail x86-64 ok
opt 3 arm-32 ok x86-64 ok
T = int :
opt 1 arm-32 fail x86-64 fail
opt 2 arm-32 fail x86-64 ok
opt 3 arm-32 ok x86-64 ok
T = double :
opt 1 arm-32 fail x86-64 fail
opt 2 arm-32 fail x86-64 ok
opt 3 arm-32 ok x86-64 ok
T = long long int :
opt 1 arm-32 ok x86-64 fail
opt 2 arm-32 ok x86-64 ok
opt 3 arm-32 ok x86-64 ok
T = _Complex double :
opt 1 arm-32 ok x86-64 ok
opt 2 arm-32 fail x86-64 fail
opt 3 arm-32 ok x86-64 ok
T = long double :
(arm-32 has 64-bit long double, so the results are not relevant)
opt 1 gives "inconsistent operand constraints in an asm"
opt 2 and 3 give "output constraint 0 must specify a single register", which
is an understandable error.
It looks like the "+X" constraint only works reliably if preceded by the
assembly line with the "X" input constraint. For my own use, I can live with
that - it all goes in a macro anyway. But maybe it points to a deeper issue,
or at least a potential for neatening things up.
[Bug sanitizer/113251] [14 Regression] ICE on gcc.dg/asan/pr63845.c on i686-linux since r14-6946
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113251
--- Comment #2 from GCC Commits ---
The master branch has been updated by Ilya Leoshkevich :
https://gcc.gnu.org/g:ba4cfef0a45dd50e16ca7bee158bc630fa646ee7
commit r14-7012-gba4cfef0a45dd50e16ca7bee158bc630fa646ee7
Author: Ilya Leoshkevich
Date: Mon Jan 8 10:11:59 2024 +0100
asan: Do not call asan_function_start () without the current function
[PR113251]
Using ASAN on i686-linux with -fPIC causes an ICE, because when
pc_thunks are generated, there is no current function anymore, but
asan_function_start () expects one.
Fix by not calling asan_function_start () without one.
A narrower fix would be to temporarily disable ASAN around pc_thunk
generation. However, the issue looks generic enough, and may affect
less often tested configurations, so go for a broader fix.
Fixes: e66dc37b299c ("asan: Align .LASANPC on function boundary")
Suggested-by: Jakub Jelinek
Signed-off-by: Ilya Leoshkevich
gcc/ChangeLog:
PR sanitizer/113251
* varasm.cc (assemble_function_label_raw): Do not call
asan_function_start () without the current function.
[Bug target/113225] bpf: attribute((kernel_helper)) adds inconsistent BTF extern function decl entry.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113225 --- Comment #1 from GCC Commits --- The master branch has been updated by Cupertino Miranda : https://gcc.gnu.org/g:dfc88fb51c1f9c26215adf6a308c18e23992cdd9 commit r14-7011-gdfc88fb51c1f9c26215adf6a308c18e23992cdd9 Author: Cupertino Miranda Date: Wed Jan 3 11:37:34 2024 + bpf: Correct BTF for kernel_helper attributed decls This patch fix a problem with kernel_helper attribute BTF information, which incorrectly generates BTF_KIND_FUNC entry. This BTF entry although accurate with traditional extern function declarations, once the function is attributed with kernel_helper, it is semantically incompatible of the kernel helpers in BPF infrastructure. gcc/ChangeLog: PR target/113225 * btfout.cc (btf_collect_datasec): Skip creating BTF info for extern and kernel_helper attributed function decls. gcc/testsuite/ChangeLog: * gcc.target/bpf/attr-kernel-helper.c: New test.
[Bug middle-end/113279] New: OpenMP 5 - Audit GOMP_MAP_FIRSTPRIVATE_REFERENCE handling for references to pointers to pointers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113279 Bug ID: 113279 Summary: OpenMP 5 - Audit GOMP_MAP_FIRSTPRIVATE_REFERENCE handling for references to pointers to pointers Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end Assignee: unassigned at gcc dot gnu.org Reporter: jules at gcc dot gnu.org Target Milestone: --- The patch (approved and soon to be committed) to support "lvalue" parsing for C++ has a corner-case issue whereby references to pointers to pointers do not quite work interchangeably with pointers to pointers (i.e. when implicitly mapped). See the "ref2ptrptr_offset_decl_member_slice" functions in the libgomp test cases baseptrs-4.C and baseptrs-6.C. https://gcc.gnu.org/pipermail/gcc-patches/2024-January/641924.html It is possible that a slight semantic tweak to GOMP_MAP_FIRSTPRIVATE_REFERENCE handling in gimplify.cc or omp-low.cc might be able to repair these cases, if indeed that is required by the spec.
[Bug testsuite/113278] analyzer tests relying on fileno() fail on arm-eabi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113278 --- Comment #1 from Richard Earnshaw --- newlib certainly implements fileno(): $ nm libc.a|grep fileno libc_a-fileno.o: T fileno U fileno libc_a-fileno_u.o: T fileno_unlocked U fileno So perhaps the issue is that the prototype is missing (or missing with the default compilation options since it's Posix and I don't think we pass options to enable that by default). Grepping the source, I suspect the former.
[Bug fortran/113245] SIZE with optional DIM argument that has the OPTIONAL+VALUE attributes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113245 --- Comment #3 from GCC Commits --- The master branch has been updated by Harald Anlauf : https://gcc.gnu.org/g:0056458550ba6df0a339589736729be8b886790a commit r14-7008-g0056458550ba6df0a339589736729be8b886790a Author: Harald Anlauf Date: Sun Jan 7 22:24:25 2024 +0100 Fortran: SIZE optional DIM argument having OPTIONAL+VALUE attributes [PR113245] gcc/fortran/ChangeLog: PR fortran/113245 * trans-intrinsic.cc (gfc_conv_intrinsic_size): Use gfc_conv_expr_present() for proper check of optional DIM argument. gcc/testsuite/ChangeLog: PR fortran/113245 * gfortran.dg/size_optional_dim_2.f90: New test.
[Bug c++/98363] C++ 20 module ICE for fast_io library
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98363 --- Comment #8 from Patrick Palka --- (In reply to Patrick Palka from comment #7) > Seems this has long been fixed by r11-6308 oops, r11-6309 rather
[Bug c++/103524] [meta-bug] modules issue
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103524 Bug 103524 depends on bug 98363, which changed state. Bug 98363 Summary: C++ 20 module ICE for fast_io library https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98363 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED
[Bug c++/98363] C++ 20 module ICE for fast_io library
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98363 Patrick Palka changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED Target Milestone|--- |11.0 CC||ppalka at gcc dot gnu.org --- Comment #7 from Patrick Palka --- Seems this has long been fixed by r11-6308
[Bug testsuite/113278] New: analyzer tests relying on fileno() fail on arm-eabi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113278 Bug ID: 113278 Summary: analyzer tests relying on fileno() fail on arm-eabi Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: testsuite Assignee: unassigned at gcc dot gnu.org Reporter: clyon at gcc dot gnu.org Target Milestone: --- Target: arm-eabi A few analyzer tests relying on fileno() fail on arm-eabi: c-c++-common/analyzer/fileno-1.c c-c++-common/analyzer/flex-with-call-summaries.c c-c++-common/analyzer/flex-without-call-summaries.c g++.log contains: gcc/testsuite/c-c++-common/analyzer/fileno-1.c:5:10: error: 'fileno' was not declared in this scope newlib does provide fileno() but maybe it's actually a newlib bug, or a bug in the way we build it.
[Bug middle-end/113205] [14 Regression] internal compiler error: in backward_pass, at tree-vect-slp.cc:5346 since r14-3220
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113205 Jakub Jelinek changed: What|Removed |Added Priority|P3 |P1
[Bug middle-end/113205] [14 Regression] internal compiler error: in backward_pass, at tree-vect-slp.cc:5346 since r14-3220
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113205
Jakub Jelinek changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Keywords|needs-bisection,|
|needs-reduction |
Summary|[14 Regression] internal|[14 Regression] internal
|compiler error: in |compiler error: in
|backward_pass, at |backward_pass, at
|tree-vect-slp.cc:5346 |tree-vect-slp.cc:5346 since
||r14-3220
Ever confirmed|0 |1
Last reconfirmed||2024-01-08
--- Comment #3 from Jakub Jelinek ---
char a;
char *b, *c;
int d, e, f, g, h;
int *i;
void
foo (void)
{
unsigned p;
d = i[0];
e = i[1];
f = i[2];
g = i[3];
p = d * b[0];
p += f * c[h];
p += e * b[h];
p += g * c[h];
a = (p + 8000) >> (__SIZEOF_INT__ * __CHAR_BIT__ / 2);
}
is reduced from mlt, ICEs at -O2 since
r14-3220-gf049868d8db773da4be61d82025e97453d6e9f2b.
[Bug c++/112588] ICE in make_decl_rtl when returning str literal when string header imported in module
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112588 Patrick Palka changed: What|Removed |Added See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=99244 CC||ppalka at gcc dot gnu.org --- Comment #3 from Patrick Palka --- The proposed patch seems to fix PR99244 as well
[Bug analyzer/113277] New: RFE: analyzer diagnose allocation error leading to pass NULL to snprintf
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113277
Bug ID: 113277
Summary: RFE: analyzer diagnose allocation error leading to
pass NULL to snprintf
Product: gcc
Version: 13.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: analyzer
Assignee: dmalcolm at gcc dot gnu.org
Reporter: aldot at gcc dot gnu.org
Target Milestone: ---
Currently the analyzer does not diagnose passing in NULL as first argument to
snprintf when NULL might stem from an unchecked allocation error.
See the undiagnosed occurrence in nak() here:
$ cat ~/gcc-alloc-vs-snprintf.c; echo EOF
#include
#include
#if 0
//snprintf first argument can be NULL according to POSIX, so we cannot
extern int snprintf (char *__restrict __s, size_t __maxlen,
const char *__restrict __format, ...)
__THROWNL __attribute__ ((__format__ (__printf__, 3, 4),__nonnull__ ((1;
#endif
/* pass NULL as first arg to snprintf */
int by_arg (void) {
int ret = snprintf (NULL, 42, "%d%s", 1234, "mystring");
if (ret != 12) {
__builtin_abort ();
}
return 0;
}
/* pass NULL via variable as first arg to snprintf */
int by_var (void) {
char *chp = NULL;
int ret = snprintf (chp, 42, "%d%s", 1234, "mystring");
if (ret != 12) {
__builtin_abort ();
}
return 0;
}
/* pass NULL on allocation failure as first arg to snprintf */
int nak (void) {
char *chp = calloc (42, sizeof(unsigned char));
// chp != NULL not checked here
int ret = snprintf (chp, 42, "%d%s", 1234, "mystring");
if (ret != 12) {
__builtin_abort ();
}
return 0;
}
EOF
Gives:
$ gcc -std=c11 -W -Wall -Wextra -pedantic -O2 -fanalyzer -c -o /tmp/foo.o
gcc-alloc-vs-snprintf.c
gcc-alloc-vs-snprintf.c: In function ‘by_arg’:
gcc-alloc-vs-snprintf.c:12:13: warning: null destination pointer
[-Wformat-truncation=]
12 | int ret = snprintf (NULL, 42, "%d%s", 1234, "mystring");
| ^
gcc-alloc-vs-snprintf.c: In function ‘by_var’:
gcc-alloc-vs-snprintf.c:12:13: warning: null destination pointer
[-Wformat-truncation=]
12 | int ret = snprintf (NULL, 42, "%d%s", 1234, "mystring");
| ^
I would have hoped that in nak() it is noted that the return value of calloc()
was not checked before being passed to snprintf and hence might be NULL (even
though the size argument was non-zero).
[Bug target/113022] GCN offloading bricked by "amdgcn: Work around XNACK register allocation problem"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113022 Thomas Schwinge changed: What|Removed |Added Resolution|--- |FIXED Status|UNCONFIRMED |RESOLVED Assignee|unassigned at gcc dot gnu.org |ams at gcc dot gnu.org --- Comment #2 from Thomas Schwinge --- Resolved via commit r14-6997-g78dff4c25c1b959e4682d7da50d00fb371849a46 "amdgcn: Match new XNACK defaults in mkoffload".
[Bug target/113276] New: gcc.dg/torture/fp-double-convert-float-1.c fails at execution on arm cortex-m33
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113276 Bug ID: 113276 Summary: gcc.dg/torture/fp-double-convert-float-1.c fails at execution on arm cortex-m33 Product: gcc Version: 14.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: --- Target: arm-eabi As discussed in https://gcc.gnu.org/pipermail/gcc-patches/2023-November/637422.html , gcc.dg/torture/fp-double-convert-float-1.c fails at execution time when targeting cortex-m33 (-mthumb/-march=armv8-m.main+dsp+fp/-mtune=cortex-m33/-mfloat-abi=hard/-mfpu=auto) FAIL: gcc.dg/torture/fp-double-convert-float-1.c -O0 execution test FAIL: gcc.dg/torture/fp-double-convert-float-1.c -O1 execution test FAIL: gcc.dg/torture/fp-double-convert-float-1.c -O2 execution test FAIL: gcc.dg/torture/fp-double-convert-float-1.c -O2 -flto -fno-use-linker-plugin -flto-partition=none execution test FAIL: gcc.dg/torture/fp-double-convert-float-1.c -O2 -flto -fuse-linker-plugin -fno-fat-lto-objects execution test FAIL: gcc.dg/torture/fp-double-convert-float-1.c -O3 -g execution test FAIL: gcc.dg/torture/fp-double-convert-float-1.c -Os execution test
[Bug c++/68891] must use a typedef to declare a conversion to 'double (&)[3]'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68891
Mital Ashok changed:
What|Removed |Added
CC||mital at mitalashok dot co.uk
--- Comment #3 from Mital Ashok ---
This is also erroneously named with `operator double`:
assert(V{0,1,2}.operator double()[1] == 1.0);
using T = double;
assert(V{0,1,2}.operator T()[1] == 1.0);
using U = double(&)[3];
// 'struct V' has no member named 'operator U'
// V{0,1,2}.operator U();
And a similar thing happens with user defined conversions to function pointers
/ references
[Bug target/113270] [14 Regression] AArch64 ICEs in register_tuple_type since r14-6524
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113270 --- Comment #8 from Richard Sandiford --- Thanks for trying it, and sorry for not doing it myself. The patch LGTM FWIW, so preapproved if it passes testing (which I'm sure it will :))
[Bug debug/52160] gdb ignores line "bar: if(foo)goto bar;"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52160 Hannes Domani changed: What|Removed |Added CC||ssbssa at yahoo dot de --- Comment #5 from Hannes Domani --- I can reproduce this issue with gcc-4.6.1, but not with gcc-4.9.1 or newer, so I think this has been fixed already.
