[Bug target/96339] [SVE] Optimise svlast[ab]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96339 --- Comment #8 from CVS Commits --- The master branch has been updated by Tejas Belagod : https://gcc.gnu.org/g:22d85c10a004f4f5eaf6b68b62a0792faf048bf8 commit r14-1744-g22d85c10a004f4f5eaf6b68b62a0792faf048bf8 Author: Tejas Belagod Date: Tue May 11 11:09:03 2021 +0100 AArch64: [PR96339] Optimise svlast[ab] This PR optimizes an SVE intrinsics sequence where svlasta (svptrue_pat_b8 (SV_VL1), x) a scalar is selected based on a constant predicate and a variable vector. This sequence is optimized to return the correspoding element of a NEON vector. For eg. svlasta (svptrue_pat_b8 (SV_VL1), x) returns umovw0, v0.b[1] Likewise, svlastb (svptrue_pat_b8 (SV_VL1), x) returns umovw0, v0.b[0] This optimization only works provided the constant predicate maps to a range that is within the bounds of a 128-bit NEON register. gcc/ChangeLog: PR target/96339 * config/aarch64/aarch64-sve-builtins-base.cc (svlast_impl::fold): Fold sve calls that have a constant input predicate vector. (svlast_impl::is_lasta): Query to check if intrinsic is svlasta. (svlast_impl::is_lastb): Query to check if intrinsic is svlastb. (svlast_impl::vect_all_same): Check if all vector elements are equal. gcc/testsuite/ChangeLog: PR target/96339 * gcc.target/aarch64/sve/acle/general-c/svlast.c: New. * gcc.target/aarch64/sve/acle/general-c/svlast128_run.c: New. * gcc.target/aarch64/sve/acle/general-c/svlast256_run.c: New. * gcc.target/aarch64/sve/pcs/return_4.c (caller_bf16): Fix asm to expect optimized code for function body. * gcc.target/aarch64/sve/pcs/return_4_128.c (caller_bf16): Likewise. * gcc.target/aarch64/sve/pcs/return_4_256.c (caller_bf16): Likewise. * gcc.target/aarch64/sve/pcs/return_4_512.c (caller_bf16): Likewise. * gcc.target/aarch64/sve/pcs/return_4_1024.c (caller_bf16): Likewise. * gcc.target/aarch64/sve/pcs/return_4_2048.c (caller_bf16): Likewise. * gcc.target/aarch64/sve/pcs/return_5.c (caller_bf16): Likewise. * gcc.target/aarch64/sve/pcs/return_5_128.c (caller_bf16): Likewise. * gcc.target/aarch64/sve/pcs/return_5_256.c (caller_bf16): Likewise. * gcc.target/aarch64/sve/pcs/return_5_512.c (caller_bf16): Likewise. * gcc.target/aarch64/sve/pcs/return_5_1024.c (caller_bf16): Likewise. * gcc.target/aarch64/sve/pcs/return_5_2048.c (caller_bf16): Likewise.
[Bug target/96339] [SVE] Optimise svlast[ab]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96339 Tejas Belagod changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED Target Milestone|12.4|14.0 --- Comment #9 from Tejas Belagod --- Now fixed on master.
[Bug middle-end/110232] New: failure to constant fold VIEW_CONVERT_EXPR>(65534)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110232
Bug ID: 110232
Summary: failure to constant fold VIEW_CONVERT_EXPR>(65534)
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: rguenth at gcc dot gnu.org
Target Milestone: ---
With
int a[4096];
void foo ()
{
for (int i = 1; i < 4095; ++i)
a[i] = 42;
}
and -O3 -march=znver4 --param vect-partial-vector-usage=2 -fno-vect-cost-model
which triggers peeling for alignment and a fully masked loop we end up with
[local count: 10737416]:
_17 = VIEW_CONVERT_EXPR>(65534);
[local count: 75161909]:
# i_8 = PHI
# ivtmp_2 = PHI
# vectp_a.4_6 = PHI
# ivtmp_14 = PHI
# loop_mask_12 = PHI <_18(5), _17(2)>
.MASK_STORE (vectp_a.4_6, 512B, loop_mask_12, { 42, 42, 42, 42, 42, 42, 42,
42, 42, 42, 42, 42, 42, 42, 42, 42 });
which isn't constant folded until we expand to RTL.
[Bug middle-end/110232] failure to constant fold VIEW_CONVERT_EXPR>(65534)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110232 Richard Biener changed: What|Removed |Added Ever confirmed|0 |1 Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org Last reconfirmed||2023-06-13 Status|UNCONFIRMED |ASSIGNED
[Bug c/110233] New: Wrong code at -Os on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110233
Bug ID: 110233
Summary: Wrong code at -Os on x86_64-linux-gnu
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: shaohua.li at inf dot ethz.ch
Target Milestone: ---
This seems to be a regression since GCC-12.
Compiler explorer: https://godbolt.org/z/8ab6hz9e1
$ cat a.c
int a, b = 1691021644, c = 1790785003;
short d;
short e() {
for (; c + 18446744073709551608UL + b - 1691021644 + 18446744073709551608UL -
1790784987 <=
2;) {
int *f[2];
int g = 0;
for (; b + (b - 1691021644) - 1691021636 + g < 2; g++)
f[g] = &a;
int **h = &f[1];
d = b;
if (d)
;
else
**h = 0;
return b;
}
return 1;
}
int main() { e(); }
$
$ gcc-tk -Os a.c && ./a.out
Segmentation fault
$ gcc-tk -O0 a.c && ./a.out
$
$ gcc-tk -O0 -fsanitize=address,undefined a.c && ./a.out
$
[Bug c/110234] New: [RISCV] Improper endian encoding when using floats and doubles with -mbig-endian
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110234 Bug ID: 110234 Summary: [RISCV] Improper endian encoding when using floats and doubles with -mbig-endian Product: gcc Version: 12.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: branislav.brzak at syrmia dot com Target Milestone: --- Problem description RISCV Gcc has a -mbig-endian flag that is supposed to flip endian on every available data type, except instructions stored in `.text`. However, there is an issue with how floats and doubles are stored. With the following min repro: .section .text .global _start _start: j _start .section .data float1: .float 1.1 That is compiled with the following makefile: all: riscv64-unknown-linux-gnu-gcc -ffreestanding -nostdlib -march=rv64imafd -mno-riscv-attribute -mabi=lp64d -Tlink.ld -nostartfiles -mcmodel=medany -Wl,--no-warn-rwx-segments -g -o le_test.elf test.s riscv64-unknown-linux-gnu-gcc -ffreestanding -nostdlib -march=rv64imafd -mno-riscv-attribute -mabi=lp64d -Tlink.ld -nostartfiles -mcmodel=medany -Wl,--no-warn-rwx-segments -mbig-endian -g -o be_test.elf test.s riscv64-unknown-elf-objdump -D le_test.elf > le_test.dump riscv64-unknown-elf-objdump -D be_test.elf > be_test.dump riscv64-unknown-linux-gnu-objcopy -O binary le_test.elf le_test.bin riscv64-unknown-linux-gnu-objcopy -O binary be_test.elf be_test.bin xxd le_test.bin > le_test.hex xxd be_test.bin > be_test.hex diff: @diff le_test.hex be_test.hex Doing `make diff` on the resulting hex dumps gives: 1c1 < : 6f00 cdcc 8c3f o..? --- > : 6f00 cccd 3f8c o.?. Upper one is the LE binary while the lower one is BE. Here we can see that compared to LE (that is properly encoded), BE's endian is flipped only on 2 byte boundaries. The correct BE sequence in this case would be 3f 8c cc cd 2 byte stores are also reflected in the elf file as well: GCC version info riscv64-unknown-linux-gnu-gcc -v Using built-in specs. COLLECT_GCC=riscv64-unknown-linux-gnu-gcc COLLECT_LTO_WRAPPER=/opt/riscv/libexec/gcc/riscv64-unknown-linux-gnu/12.2.0/lto-wrapper Target: riscv64-unknown-linux-gnu Configured with: /home/fix/tasks/riscvbe/new/riscv-gnu-toolchain/gcc/configure --target=riscv64-unknown-linux-gnu --prefix=/opt/riscv --with-sysroot=/opt/riscv/sysroot --with-pkgversion=g2ee5e430018 --with-system-zlib --enable-shared --enable-tls --enable-languages=c,c++,fortran --disable-libmudflap --disable-libssp --disable-libquadmath --disable-libsanitizer --disable-nls --disable-bootstrap --src=.././gcc --disable-multilib --with-abi=lp64d --with-arch=rv64imafdc --with-tune=rocket --with-isa-spec=20191213 'CFLAGS_FOR_TARGET=-O2 -mcmodel=medlow' 'CXXFLAGS_FOR_TARGET=-O2-mcmodel=medlow' Thread model: posix Supported LTO compression algorithms: zlib gcc version 12.2.0 (g2ee5e430018)
[Bug c/110234] [RISCV] Improper endian encoding when using floats and doubles with -mbig-endian
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110234 --- Comment #1 from Branislav Brzak --- For "2 byte stores are also reflected in the elf file as well:" I wanted to include this: 8008 <_sdata>: 8008: cccd.2byte 0xcccd 800a: 3f8c.2byte 0x3f8c
[Bug rtl-optimization/92080] Missed CSE of _mm512_set1_epi8(c) with _mm256_set1_epi8(c)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92080
Richard Biener changed:
What|Removed |Added
CC||crazylht at gmail dot com
Blocks||53947
Component|middle-end |rtl-optimization
--- Comment #6 from Richard Biener ---
Similar when vectorizing
int a[4096];
void foo ()
{
for (int i = 1; i < 4095; ++i)
a[i] = 42;
}
the combination of peeling for alignment and the epilog yields on GIMPLE:
[local count: 10737416]:
MEM [(int *)&a + 4B] = { 42, 42, 42, 42, 42, 42, 42, 42 };
MEM [(int *)&a + 36B] = { 42, 42, 42, 42 };
MEM [(int *)&a + 52B] = { 42, 42 };
a[15] = 42;
ivtmp.28_59 = (unsigned long) &MEM [(void *)&a + 64B];
_1 = (unsigned long) &a;
_182 = _1 + 16320;
[local count: 75161909]:
# ivtmp.28_71 = PHI
_21 = (void *) ivtmp.28_71;
MEM [(int *)_21] = { 42, 42, 42, 42, 42, 42, 42, 42, 42, 42,
42, 42, 42, 42, 42, 42 };
ivtmp.28_65 = ivtmp.28_71 + 64;
if (ivtmp.28_65 != _182)
goto ; [85.71%]
else
goto ; [14.29%]
[local count: 21474835]:
MEM [(int *)&a + 16320B] = { 42, 42, 42, 42, 42, 42, 42, 42
};
MEM [(int *)&a + 16352B] = { 42, 42, 42, 42 };
MEM [(int *)&a + 16368B] = { 42, 42 };
a[4094] = 42;
return;
and that in turn causes a lot of redundant broadcasts from constants (via
GPRs):
foo:
.LFB0:
.cfi_startproc
movl$42, %eax
movq.LC2(%rip), %rcx
movl$42, %edx
movl$42, a+60(%rip)
vpbroadcastd%eax, %ymm0
vmovdqu %ymm0, a+4(%rip)
vpbroadcastd%eax, %xmm0
movl$a+64, %eax
vmovdqu %xmm0, a+36(%rip)
vpbroadcastd%edx, %zmm0
movq%rcx, a+52(%rip)
.L2:
vmovdqa32 %zmm0, (%rax)
subq$-128, %rax
vmovdqa32 %zmm0, -64(%rax)
cmpq$a+16320, %rax
jne .L2
vpbroadcastd%edx, %ymm0
movq%rcx, a+16368(%rip)
movl$42, a+16376(%rip)
vmovdqa %ymm0, a+16320(%rip)
vpbroadcastd%edx, %xmm0
vmovdqa %xmm0, a+16352(%rip)
vzeroupper
ret
as they are constant on GIMPLE any "CSE" we'd perform there would be undone
quickly by constant propagation. So it's only on RTL where the actual
broadcast is a non-constant operation that we can and should optimize this
somehow. Some kind of LCM to also handle earlier small but later bigger
broadcasts would be necessary here.
Referenced Bugs:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53947
[Bug 53947] [meta-bug] vectorizer missed-optimizations
[Bug middle-end/108410] x264 averaging loop not optimized well for avx512
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108410 --- Comment #9 from rguenther at suse dot de --- On Tue, 13 Jun 2023, crazylht at gmail dot com wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108410 > > --- Comment #8 from Hongtao.liu --- > > > Can x86 do this? We'd want to apply this to a scalar, so move ivtmp > > to xmm, apply pack_usat or as you say below, the non-existing us_trunc > > and then broadcast. > > I see, we don't have scalar version. Also vector instruction looks not very > fast. > > https://uops.info/html-instr/VPMOVSDB_XMM_XMM.html Uh, yeah. Well, Zen4 looks reasonable though latency could be better. Preliminary performance data also shows masked epilogues are a mixed bag. I'll finish off the implementation and then we'll see if we can selectively enable it for the profitable cases somehow.
[Bug testsuite/110230] new test case gcc.target/powerpc/pr109932-1.c in r14-1705-g2764335bd336f2 fails for 32 bits
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110230
--- Comment #2 from CVS Commits ---
The master branch has been updated by Kewen Lin :
https://gcc.gnu.org/g:16eb9d69079d769b2aa2c07ce54aca20f5547c14
commit r14-1776-g16eb9d69079d769b2aa2c07ce54aca20f5547c14
Author: Kewen Lin
Date: Tue Jun 13 03:04:54 2023 -0500
testsuite: Check int128 effective target for pr109932-{1,2}.c [PR110230]
This patch is to make newly added test cases pr109932-{1,2}.c
check int128 effective target to avoid unsupported type error
on 32-bit. I did hit this failure during testing and fixed
it, but made a stupid mistake not updating the local formatted
patch which was actually out of date.
PR testsuite/110230
PR target/109932
gcc/testsuite/ChangeLog:
* gcc.target/powerpc/pr109932-1.c: Adjust with int128 effective
target.
* gcc.target/powerpc/pr109932-2.c: Ditto.
[Bug target/109932] ICE in in extract_insn, at recog.cc:2791 on ppc64le with -mno-vsx
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109932
--- Comment #3 from CVS Commits ---
The master branch has been updated by Kewen Lin :
https://gcc.gnu.org/g:16eb9d69079d769b2aa2c07ce54aca20f5547c14
commit r14-1776-g16eb9d69079d769b2aa2c07ce54aca20f5547c14
Author: Kewen Lin
Date: Tue Jun 13 03:04:54 2023 -0500
testsuite: Check int128 effective target for pr109932-{1,2}.c [PR110230]
This patch is to make newly added test cases pr109932-{1,2}.c
check int128 effective target to avoid unsupported type error
on 32-bit. I did hit this failure during testing and fixed
it, but made a stupid mistake not updating the local formatted
patch which was actually out of date.
PR testsuite/110230
PR target/109932
gcc/testsuite/ChangeLog:
* gcc.target/powerpc/pr109932-1.c: Adjust with int128 effective
target.
* gcc.target/powerpc/pr109932-2.c: Ditto.
[Bug testsuite/110230] new test case gcc.target/powerpc/pr109932-1.c in r14-1705-g2764335bd336f2 fails for 32 bits
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110230 Kewen Lin changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #3 from Kewen Lin --- Should be fixed on trunk.
[Bug testsuite/109880] [14 regression] gcc.target/powerpc/fold-vec-extract-int.p8.c fails after r14-916-g9417b30499ce09
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109880 --- Comment #3 from CVS Commits --- The master branch has been updated by Ajit Kumar Agarwal : https://gcc.gnu.org/g:17714c08e9013b51cf8d04ac39f844d355c923f2 commit r14-1777-g17714c08e9013b51cf8d04ac39f844d355c923f2 Author: âAjit Kumar Agarwalâ Date: Fri May 19 02:30:44 2023 -0500 testsuite: Update powerpc test fold-vec-extract-int.p8.c Update powerpc tests with extra zero_extend removal with default ree pass. 2023-06-13 Ajit Kumar Agarwal gcc/testsuite/ChangeLog: PR testsuite/109880 * gcc.target/powerpc/fold-vec-extract-int.p8.c: Update test.
[Bug middle-end/110232] failure to constant fold VIEW_CONVERT_EXPR>(65534)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110232 --- Comment #1 from CVS Commits --- The master branch has been updated by Richard Biener : https://gcc.gnu.org/g:0f3d07e16fec7bea2fd033d9ec8ff08ea7effa39 commit r14-1779-g0f3d07e16fec7bea2fd033d9ec8ff08ea7effa39 Author: Richard Biener Date: Tue Jun 13 09:19:34 2023 +0200 middle-end/110232 - fix native interpret of vector The following fixes native interpretation of a buffer as boolean vector with bit-precision elements such as AVX512 vectors. The check whether the buffer covers the whole vector was broken for bit-precision elements and the following instead implements it based on the vector type size. PR middle-end/110232 * fold-const.cc (native_interpret_vector): Use TYPE_SIZE_UNIT to check whether the buffer covers the whole vector. * gcc.target/i386/pr110232.c: New testcase.
[Bug middle-end/110232] failure to constant fold VIEW_CONVERT_EXPR>(65534)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110232 Richard Biener changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED Known to work||14.0 --- Comment #2 from Richard Biener --- Fixed on trunk.
[Bug target/110235] New: Wrong use of us_truncate in SSE and AVX RTL representation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110235 Bug ID: 110235 Summary: Wrong use of us_truncate in SSE and AVX RTL representation Product: gcc Version: 14.0 Status: UNCONFIRMED Keywords: wrong-code Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: ktkachov at gcc dot gnu.org CC: uros at gcc dot gnu.org Target Milestone: --- Target: x86 After g:921b841350c4fc298d09f6c5674663e0f4208610 added constant-folding for SS_TRUNCATE and US_TRUNCATE some tests in i386.exp started failing: FAIL: gcc.target/i386/avx-vpackuswb-1.c execution test FAIL: gcc.target/i386/avx2-vpackssdw-2.c execution test FAIL: gcc.target/i386/avx2-vpackusdw-2.c execution test FAIL: gcc.target/i386/avx2-vpackuswb-2.c execution test FAIL: gcc.target/i386/sse2-packuswb-1.c execution test >From what I can gather from the documentation for intrinsics like _mm_packus_epi16 the operation they perform is not what we model as us_truncate in RTL. That is, they don't perform a truncation while treating their input as an unsigned value. Rather, they treat the input as a signed value and saturate it to the unsigned min and max of the narrow mode before truncation. In that regard they seem similar to the SQMOVUN instructions in aarch64. I think it'd be best to change the representation of those instructions to a truncating clamp operation, similar to g:b747f54a2a930da55330c2861cd1e344f67a88d9 in aarch64.
[Bug ipa/109886] UBSAN error: shift exponent 64 is too large for 64-bit type when compiling gcc.c-torture/compile/pr96796.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109886 Martin Jambor changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #14 from Martin Jambor --- (In reply to Andrew Macleod from comment #13) > Let me know if the buildbot likes that change :-) The buildbot seems happy now, thanks!
[Bug other/63426] [meta-bug] Issues found with -fsanitize=undefined
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63426 Bug 63426 depends on bug 109886, which changed state. Bug 109886 Summary: UBSAN error: shift exponent 64 is too large for 64-bit type when compiling gcc.c-torture/compile/pr96796.c https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109886 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED
[Bug target/108779] AARCH64 should add an option to change TLS register location to support EL1/EL2/EL3 system registers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108779 --- Comment #11 from CVS Commits --- The master branch has been updated by Kyrylo Tkachov : https://gcc.gnu.org/g:4389a2d2d0cc639cbeeb8453dc20bf315316d4e3 commit r14-1781-g4389a2d2d0cc639cbeeb8453dc20bf315316d4e3 Author: Kyrylo Tkachov Date: Tue Jun 13 10:13:55 2023 +0100 aarch64: Extend -mtp= arguments After discussing the -mtp= option with Arm's LLVM developers we'd like to extend the functionality of the option somewhat. First of all, there is another TPIDR register that can be used to read the thread pointer: TPIDRRO_EL0 (which can also be accessed by AArch32 under another name) so it makes sense to add -mtp=tpidrr0_el0. This makes the existing arguments el0, el1, el2, el3 somewhat inconsistent in their naming so this patch introduces the more "full" names tpidr_el0, tpidr_el1, tpidr_el2, tpidr_el3 and makes the above short names alias of these new ones. Long story short, we preserve backwards compatibility and add a new TPIDR register to access through -mtp that wasn't available previously. There is more relevant discussion of the options at https://reviews.llvm.org/D152433 if you're interested. Bootstrapped and tested on aarch64-none-linux-gnu. gcc/ChangeLog: PR target/108779 * config/aarch64/aarch64-opts.h (enum aarch64_tp_reg): Add AARCH64_TPIDRRO_EL0 value. * config/aarch64/aarch64.cc (aarch64_output_load_tp): Define. * config/aarch64/aarch64.opt (tpidr_el0, tpidr_el1, tpidr_el2, tpidr_el3, tpidrro_el3): New accepted values to -mtp=. * doc/invoke.texi (AArch64 Options): Document new -mtp= options. gcc/testsuite/ChangeLog: PR target/108779 * gcc.target/aarch64/mtp_5.c: New test. * gcc.target/aarch64/mtp_6.c: New test. * gcc.target/aarch64/mtp_7.c: New test. * gcc.target/aarch64/mtp_8.c: New test. * gcc.target/aarch64/mtp_9.c: New test.
[Bug libgomp/109837] [OpenMP] despite 'requires unified_address' there is segfault when 'is_device_ptr' is not used
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109837
--- Comment #4 from CVS Commits ---
The master branch has been updated by Tobias Burnus :
https://gcc.gnu.org/g:d5c58ad1ebaff924c2546df074174cffb128feb8
commit r14-1783-gd5c58ad1ebaff924c2546df074174cffb128feb8
Author: Tobias Burnus
Date: Tue Jun 13 11:27:47 2023 +0200
libgomp/testsuite: Add requires-unified-addr-1.{c,f90} [PR109837]
Add a testcase for 'omp requires unified_address' that is currently
supported
by all devices but was not tested for.
libgomp/
PR libgomp/109837
* testsuite/libgomp.c-c++-common/requires-unified-addr-1.c: New
test.
* testsuite/libgomp.fortran/requires-unified-addr-1.f90: New test.
[Bug preprocessor/80753] __has_include and __has_include_next taints subsequent I/O errors
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80753 Jakub Jelinek changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org --- Comment #6 from Jakub Jelinek --- Created attachment 55316 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55316&action=edit gcc14-pr80753.patch Untested fix.
[Bug libgomp/109837] [OpenMP] despite 'requires unified_address' there is segfault when 'is_device_ptr' is not used
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109837 Tobias Burnus changed: What|Removed |Added Resolution|--- |FIXED Status|UNCONFIRMED |RESOLVED --- Comment #5 from Tobias Burnus --- FIXED. Namely: * Code handling was correct, once the testcase was fix ... → See sollve_vv link in comment 0 and esp. in comment 2. * For GCN, unified_address support had to be enabled → trivial patch, see comment 3 * We did not have a testcase in libgomp → commit in comment 4 => All done → Close as FIXED.
[Bug rtl-optimization/110093] [12/13/14 Regression][avr] Move frenzy leading to code bloat
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110093 Georg-Johann Lay changed: What|Removed |Added CC||vmakarov at gcc dot gnu.org --- Comment #1 from Georg-Johann Lay --- CCing Vladimir. Maybe he has a clue. It reminds of PR90706 which should be fixed by now.
[Bug modula2/110126] Variables are reported as unused when only referenced by ASM statements
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110126
--- Comment #13 from Thorsten Otto ---
Just found a small problem: asm statements without any lists,
like in
ASM("");
now are warned about with "syntax warning, ':' missing"
[Bug target/110227] [13/14 Regression] gcc generates invalid AVX-512 code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110227 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #4 from Jakub Jelinek --- Looking at that commit, it also introduced weird formatting: return "vpcmpeqd \t %t0, %t0, %t0"; and return "vpcmpeqd \t %x0, %x0, %x0"; and return "vpcmpeqd \t %x0, %x0, %x0"; definitely shouldn't have the spaces around \t on either side. But sure, agree the alternative with BH constraint on source should use x rather than v constraint on destination.
[Bug rtl-optimization/101188] [postreload] Uses content of a clobbered register
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101188 --- Comment #16 from Georg-Johann Lay --- Created attachment 55317 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55317&action=edit Backport to v13 of Jeff's patch.
[Bug rtl-optimization/101188] [postreload] Uses content of a clobbered register
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101188 --- Comment #17 from Georg-Johann Lay --- Created attachment 55318 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55318&action=edit Reduced patch for v8 (handles only CLOBBERs, hence should be good enough for AVR).
[Bug target/110234] [RISCV] Improper endian encoding when using floats and doubles with -mbig-endian
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110234 --- Comment #2 from Andrew Pinski --- Note this looks like an assembler bug rather than a gcc bug. Assembler in your case comes from the binutils project who's bugzilla is located at https://sourceware.org/bugzilla.
[Bug target/110236] New: RFE: LoongArch: Supporting assembly output with register aliases in ELF ABI
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110236 Bug ID: 110236 Summary: RFE: LoongArch: Supporting assembly output with register aliases in ELF ABI Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: xry111 at gcc dot gnu.org Target Milestone: --- The assembly with register aliases is easier to read and there has been an RFE at https://github.com/loongson/gcc/pull/21. I guess we can add an option like "-mreg-name=[raw|elf]" to control the behavior, and keep -mreg-name=raw as the default to please test suites and the existing tools expecting the raw register names.
[Bug middle-end/110142] [14 Regression] x264 from SPECCPU 2017 miscompares from g:2f482a07365d9f4a94a56edd13b7f01b8f78b5a0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110142 avieira at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #4 from avieira at gcc dot gnu.org --- I believe that fixes the issue.
[Bug target/110234] [RISCV] Improper endian encoding when using floats and doubles with -mbig-endian
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110234 Xi Ruoyao changed: What|Removed |Added Resolution|--- |MOVED Status|UNCONFIRMED |RESOLVED CC||xry111 at gcc dot gnu.org --- Comment #3 from Xi Ruoyao --- Not a GCC bug. In this case GCC is only a wrapper of the assembler. GCC even does not know how to parse the assembly.
[Bug rtl-optimization/110237] New: gcc.dg/torture/pr58955-2.c is miscompiled by RTL scheduling after reload
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110237
Bug ID: 110237
Summary: gcc.dg/torture/pr58955-2.c is miscompiled by RTL
scheduling after reload
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: rtl-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: rguenth at gcc dot gnu.org
Target Milestone: ---
When compiling the testcase with fully masked AVX512 vectorization,
-march=znver4 --param=vect-partial-vector-usage=2 -fdiagnostics-plain-output
-O3 -fomit-frame-pointer -funroll-loops -fpeel-loops -ftracer
-finline-functions
RTL sched2 is presented with
(insn 38 35 39 3 (set (mem:V16SI (plus:DI (reg:DI 40 r12 [orig:90 _22 ] [90])
(const:DI (plus:DI (symbol_ref:DI ("b") [flags 0x2] )
(const_int -4 [0xfffc] [1 MEM
[(int *)vectp_b.12_28]+0 S64 A32])
(vec_merge:V16SI (reg:V16SI 21 xmm1 [118])
(mem:V16SI (plus:DI (reg:DI 40 r12 [orig:90 _22 ] [90])
(const:DI (plus:DI (symbol_ref:DI ("b") [flags 0x2]
)
(const_int -4 [0xfffc] [1 MEM
[(int *)vectp_b.12_28]+0 S64 A32])
(reg:HI 69 k1 [116])))
"/space/rguenther/src/gcc11queue/gcc/testsuite/gcc.dg/torture/pr58955-2.c":12:12
1942 {avx512f_storev16si_mask}
(expr_list:REG_DEAD (reg:HI 69 k1 [116])
(expr_list:REG_DEAD (reg:DI 40 r12 [orig:90 _22 ] [90])
(expr_list:REG_DEAD (reg:V16SI 21 xmm1 [118])
(nil)
...
(insn 41 39 42 3 (set (reg:CCZ 17 flags)
(compare:CCZ (mem/c:SI (const:DI (plus:DI (symbol_ref:DI ("b") [flags
0x2] )
(const_int 4 [0x4]))) [1 b[1]+0 S4 A32])
(const_int 1 [0x1])))
"/space/rguenther/src/gcc11queue/gcc/testsuite/gcc.dg/torture/pr58955-2.c":15:6
11 {*cmpsi_1}
(nil))
and it moves the masked store across the load of one of the destinations
elements:
- 32: xmm0:V16QI=vec_duplicate(bx:QI)
- REG_DEAD bx:QI
- 33: NOTE_INSN_DELETED
- 34: k1:HI=unspec[xmm0:V16QI,[`*.LC0'],0x6] 146
- REG_DEAD xmm0:V16QI
36: cx:SI=0x1
REG_EQUIV 0x1
+ 41: flags:CCZ=cmp([const(`b'+0x4)],0x1)
+ 32: xmm0:V16QI=vec_duplicate(bx:QI)
+ REG_DEAD bx:QI
35: xmm1:V16SI=vec_duplicate(cx:SI)
REG_DEAD cx:SI
REG_EQUIV const_vector
+ 34: k1:HI=unspec[xmm0:V16QI,[`*.LC0'],0x6] 146
+ REG_DEAD xmm0:V16QI
+ 39: [`a']=0x2
38:
[r12:DI+const(`b'-0x4)]=vec_merge(xmm1:V16SI,[r12:DI+const(`b'-0x4)],k1:HI)
REG_DEAD k1:HI
REG_DEAD r12:DI
REG_DEAD xmm1:V16SI
- 39: [`a']=0x2
- 41: flags:CCZ=cmp([const(`b'+0x4)],0x1)
the address of the masked store is computed oddly though:
14: r12:DI=dx:DI<<0x2+0x4
REG_DEAD dx:DI
and in the end the assembly contains
leaq4(,%rdx,4), %r12
...
cmpl$1, b+4(%rip)
...
vmovdqu32 %zmm1, b-4(%r12){%k1}
(%rdx is zero)
[Bug target/110227] [13/14 Regression] gcc generates invalid AVX-512 code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110227 Richard Biener changed: What|Removed |Added Priority|P3 |P2
[Bug target/110235] Wrong use of us_truncate in SSE and AVX RTL representation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110235 Richard Biener changed: What|Removed |Added CC||crazylht at gmail dot com Last reconfirmed||2023-06-13 Target|x86 |x86_64-*-* Ever confirmed|0 |1 Status|UNCONFIRMED |NEW --- Comment #1 from Richard Biener --- Confirmed (the FAILs)
[Bug libgcc/60939] AIX: exceptions not caught when calling function via pointer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60939 --- Comment #12 from Adam Swartz --- Thanks David. I think I got it working through the makefile with patterns, variables and some conditional logic. It didn't complain about command size, but having that as a backup is good to know. I would like to see this fixed. Our code broke when we upgraded our AIX system and had to upgrade the compiler recently. Figuring out the reason for the cores was a pain. Our case was not related to externs but to third level inheritance and templates. The try block was in main. I sent sample code to the AIX open source team but will add it here as well. I tried to turn off all gc (-bnogc) and that didn't work, so this is still error prone as new code gets added in. Thanks, Adam
[Bug libgcc/60939] AIX: exceptions not caught when calling function via pointer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60939 --- Comment #13 from Adam Swartz --- Created attachment 55319 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55319&action=edit InheritanceCase The shell script will compile things. OpenSource team said they had to change the -ggdb3 option. The program TestCreateByMethodV4 generates the error.
[Bug target/105617] [12/13/14 Regression] Slp is maybe too aggressive in some/many cases
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105617 --- Comment #20 from Mason --- Doh! You're right. I come from a background where overlapping/aliasing inputs are heresy, thus got blindsided :( This would be the optimal code, right? add4i: # rdi = dst, rsi = a, rdx = b movq 0(%rdx), %r8 movq 8(%rdx), %rax movq16(%rdx), %rcx movq24(%rdx), %rdx addq 0(%rsi), %r8 adcq 8(%rsi), %rax adcq16(%rsi), %rcx adcq24(%rsi), %rdx movq%r8, 0(%rdi) movq%rax, 8(%rdi) movq%rcx, 16(%rdi) movq%rdx, 24(%rdi) ret FWIW, trunk generates even nastier code for znver2: add4i: movq(%rdx), %rax addq(%rsi), %rax movq8(%rsi), %rcx adcq8(%rdx), %rcx movq16(%rsi), %r8 adcq16(%rdx), %r8 movq24(%rdx), %rdx adcq24(%rsi), %rdx vmovq %rax, %xmm2 vpinsrq $1, %rcx, %xmm2, %xmm0 vmovq %r8, %xmm1 vpinsrq $1, %rdx, %xmm1, %xmm1 vinserti128 $0x1, %xmm1, %ymm0, %ymm0 vmovdqu %ymm0, (%rdi) vzeroupper ret
[Bug c/110238] New: Incorrect "comparison between pointer and zero character constant" warning when comparing pointer to unsigned null pointer constant
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110238
Bug ID: 110238
Summary: Incorrect "comparison between pointer and zero
character constant" warning when comparing pointer to
unsigned null pointer constant
Product: gcc
Version: 13.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: nora at norasandler dot com
Target Milestone: ---
This warning looks like it's intended to catch comparisons to null character
constants (e.g. '\0') but is also triggered by a comparison to 0u. Comparing to
other null pointer constants (0, 0l, 0ul) doesn't trigger this warning.
Preprocessed source code
# 0 "compare_to_null.c"
# 0 ""
# 0 ""
# 1 "/usr/include/stdc-predef.h" 1 3 4
# 0 "" 2
# 1 "compare_to_null.c"
int main(void) {
int *x = 0;
return (x == 0u);
}
Compiler warning
==
$ gcc-13 a-compare_to_null.i
compare_to_null.c: In function ‘main’:
compare_to_null.c:3:15: warning: comparison between pointer and zero character
constant [-Wpointer-compare]
3 | return (x == 0u);
| ^~
compare_to_null.c:3:13: note: did you mean to dereference the pointer?
3 | return (x == 0u);
| ^
Version/system info
$ gcc -v -save-temps compare_to_null.c
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/11/lto-wrapper
OFFLOAD_TARGET_NAMES=nvptx-none:amdgcn-amdhsa
OFFLOAD_TARGET_DEFAULT=1
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu
11.3.0-1ubuntu1~22.04.1' --with-bugurl=file:///usr/share/doc/gcc-11/README.Bugs
--enable-languages=c,ada,c++,go,brig,d,fortran,objc,obj-c++,m2 --prefix=/usr
--with-gcc-major-version-only --program-suffix=-11
--program-prefix=x86_64-linux-gnu- --enable-shared --enable-linker-build-id
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix
--libdir=/usr/lib --enable-nls --enable-bootstrap --enable-clocale=gnu
--enable-libstdcxx-debug --enable-libstdcxx-time=yes
--with-default-libstdcxx-abi=new --enable-gnu-unique-object
--disable-vtable-verify --enable-plugin --enable-default-pie --with-system-zlib
--enable-libphobos-checking=release --with-target-system-zlib=auto
--enable-objc-gc=auto --enable-multiarch --disable-werror --enable-cet
--with-arch-32=i686 --with-abi=m64 --with-multilib-list=m32,m64,mx32
--enable-multilib --with-tune=generic
--enable-offload-targets=nvptx-none=/build/gcc-11-aYxV0E/gcc-11-11.3.0/debian/tmp-nvptx/usr,amdgcn-amdhsa=/build/gcc-11-aYxV0E/gcc-11-11.3.0/debian/tmp-gcn/usr
--without-cuda-driver --enable-checking=release --build=x86_64-linux-gnu
--host=x86_64-linux-gnu --target=x86_64-linux-gnu
--with-build-config=bootstrap-lto-lean --enable-link-serialization=2
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 11.3.0 (Ubuntu 11.3.0-1ubuntu1~22.04.1)
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-mtune=generic' '-march=x86-64'
'-dumpdir' 'a-'
/usr/lib/gcc/x86_64-linux-gnu/11/cc1 -E -quiet -v -imultiarch x86_64-linux-gnu
compare_to_null.c -mtune=generic -march=x86-64 -fpch-preprocess
-fasynchronous-unwind-tables -fstack-protector-strong -Wformat
-Wformat-security -fstack-clash-protection -fcf-protection -o
a-compare_to_null.i
ignoring nonexistent directory "/usr/local/include/x86_64-linux-gnu"
ignoring nonexistent directory "/usr/lib/gcc/x86_64-linux-gnu/11/include-fixed"
ignoring nonexistent directory
"/usr/lib/gcc/x86_64-linux-gnu/11/../../../../x86_64-linux-gnu/include"
#include "..." search starts here:
#include <...> search starts here:
/usr/lib/gcc/x86_64-linux-gnu/11/include
/usr/local/include
/usr/include/x86_64-linux-gnu
/usr/include
End of search list.
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-mtune=generic' '-march=x86-64'
'-dumpdir' 'a-'
/usr/lib/gcc/x86_64-linux-gnu/11/cc1 -fpreprocessed a-compare_to_null.i -quiet
-dumpdir a- -dumpbase compare_to_null.c -dumpbase-ext .c -mtune=generic
-march=x86-64 -version -fasynchronous-unwind-tables -fstack-protector-strong
-Wformat -Wformat-security -fstack-clash-protection -fcf-protection -o
a-compare_to_null.s
GNU C17 (Ubuntu 11.3.0-1ubuntu1~22.04.1) version 11.3.0 (x86_64-linux-gnu)
compiled by GNU C version 11.3.0, GMP version 6.2.1, MPFR version
4.1.0, MPC version 1.2.1, isl version isl-0.24-GMP
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
GNU C17 (Ubuntu 11.3.0-1ubuntu1~22.04.1) version 11.3.0 (x86_64-linux-gnu)
compiled by GNU C version 11.3.0, GMP version 6.2.1, MPFR version
4.1.0, MPC version 1.2.1, isl version isl-0.24-GMP
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: e13e2dc98bfa673227c4000e476a9388
compare_to_null.c: In function ‘main’:
compare_to_null.c:3:15: warning: comparison betwee
[Bug c/110238] [10/11/12/13/14 Regression] Incorrect "comparison between pointer and zero character constant" warning when comparing pointer to unsigned null pointer constant
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110238
Andrew Pinski changed:
What|Removed |Added
Target Milestone|--- |10.5
Ever confirmed|0 |1
Last reconfirmed||2023-06-13
Summary|Incorrect "comparison |[10/11/12/13/14 Regression]
|between pointer and zero|Incorrect "comparison
|character constant" warning |between pointer and zero
|when comparing pointer to |character constant" warning
|unsigned null pointer |when comparing pointer to
|constant|unsigned null pointer
||constant
Status|UNCONFIRMED |NEW
--- Comment #1 from Andrew Pinski ---
Confirmed, introduced with r7-5677-ga9342885b149 .
So I think the issue is in char_type_p we have:
```
static bool
char_type_p (tree type)
{
return (type == char_type_node
|| type == unsigned_char_type_node
|| type == signed_char_type_node
|| type == char16_type_node
|| type == char32_type_node);
}
```
In C, there is no distinct type for char32_type_node so it is the same as
unsigned here and it returns true for that case .
[Bug other/110239] New: [14 regression] std/format/functions/format.cc fails after r14-1648-g628ba410b9265d
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110239
Bug ID: 110239
Summary: [14 regression] std/format/functions/format.cc fails
after r14-1648-g628ba410b9265d
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: other
Assignee: unassigned at gcc dot gnu.org
Reporter: seurer at gcc dot gnu.org
Target Milestone: ---
g:628ba410b9265dbd4278c1f1b1fadf05348adef2, r14-1648-g628ba410b9265d
make -k check RUNTESTFLAGS="--target_board=unix'{-m32}'
conformance.exp=std/format/functions/format.cc"
FAIL: std/format/functions/format.cc execution test
# of expected passes1
# of unexpected failures1
This only happens for 32 bits on a big endian system.
/home/seurer/gcc/git/gcc-trunk/libstdc++-v3/testsuite/std/format/functions/format.cc:368:
void test_pointer(): Assertion 's == (str_int + ' ' + str_int + " 0x0")'
failed.
commit 628ba410b9265dbd4278c1f1b1fadf05348adef2 (HEAD)
Author: Jonathan Wakely
Date: Thu Jun 8 21:35:21 2023 +0100
libstdc++: Fix P2510R3 "Formatting pointers" [PR110149]
[Bug fortran/110224] Rejects valid: function reference with data pointer result as lhs in assignment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110224 anlauf at gcc dot gnu.org changed: What|Removed |Added Keywords||rejects-valid CC||pault at gcc dot gnu.org Status|UNCONFIRMED |NEW Ever confirmed|0 |1 Last reconfirmed||2023-06-13 --- Comment #1 from anlauf at gcc dot gnu.org --- Confirmed. Since it appears associate-related, CC'ing Paul as the expert.
[Bug fortran/86277] Presence of optional arguments not recognized for zero length arrays
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86277 --- Comment #33 from CVS Commits --- The master branch has been updated by Harald Anlauf : https://gcc.gnu.org/g:c1691509e5a8875f36c068a5ea101bf13f140948 commit r14-1795-gc1691509e5a8875f36c068a5ea101bf13f140948 Author: Harald Anlauf Date: Mon Jun 12 23:08:48 2023 +0200 Fortran: fix passing of zero-sized array arguments to procedures [PR86277] gcc/fortran/ChangeLog: PR fortran/86277 * trans-array.cc (gfc_trans_allocate_array_storage): When passing a zero-sized array with fixed (= non-dynamic) size, allocate temporary by the caller, not by the callee. gcc/testsuite/ChangeLog: PR fortran/86277 * gfortran.dg/zero_sized_14.f90: New test. * gfortran.dg/zero_sized_15.f90: New test. Co-authored-by: Mikael Morin
[Bug target/110240] New: Unnecessary register move in indexed swap routine
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110240
Bug ID: 110240
Summary: Unnecessary register move in indexed swap routine
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: tkoenig at gcc dot gnu.org
Target Milestone: ---
void swap (unsigned int * restrict a, unsigned int * restrict b)
{
if (a[b[0]] > a[b[1]])
{
unsigned int tmp = b[0];
b[0] = b[1];
b[1] = tmp;
}
}
$ gcc -O3 -S swap.c
gets me
swap:
.LFB0:
.cfi_startproc
movl(%rsi), %ecx
movl4(%rsi), %r8d
movq%rcx, %rax
movl(%rdi,%rcx,4), %ecx
cmpl%ecx, (%rdi,%r8,4)
jnb .L1
movl%r8d, (%rsi)
movl%eax, 4(%rsi)
.L1:
ret
.cfi_endproc
where the
movq%rcx, %rax
is unneeded, because rcs is not overwritten.
(It is probably also a zero-latency operation due to register renaming,
but still).
[Bug rtl-optimization/110240] Unnecessary register move in indexed swap routine
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110240
Andrew Pinski changed:
What|Removed |Added
Last reconfirmed||2023-06-13
Status|UNCONFIRMED |NEW
Component|target |rtl-optimization
Ever confirmed|0 |1
--- Comment #1 from Andrew Pinski ---
Confirmed (though it is not exactly a target specific issue).
REE transforms:
(insn 7 4 8 2 (set (reg:SI 0 ax [orig:82 _1 ] [82])
(mem:SI (reg/v/f:DI 4 si [orig:93 b ] [93]) [1 *b_13(D)+0 S4 A32]))
"/app/example.cpp":3:10 91 {*movsi_internal}
(nil))
(insn 8 7 9 2 (set (reg:SI 1 dx [orig:87 _6 ] [87])
(mem:SI (plus:DI (reg/v/f:DI 4 si [orig:93 b ] [93])
(const_int 4 [0x4])) [1 MEM[(unsigned int *)b_13(D) + 4B]+0 S4
A32])) "/app/example.cpp":3:20 91 {*movsi_internal}
(nil))
(insn 9 8 10 2 (set (reg:DI 2 cx [orig:94 _1 ] [94])
(zero_extend:DI (reg:SI 0 ax [orig:82 _1 ] [82])))
"/app/example.cpp":3:10 159 {*zero_extendsidi2}
(nil))
(insn 10 9 11 2 (set (reg:DI 36 r8 [orig:95 _6 ] [95])
(zero_extend:DI (reg:SI 1 dx [orig:87 _6 ] [87])))
"/app/example.cpp":3:20 159 {*zero_extendsidi2}
(nil))
Into:
(insn 7 4 28 2 (set (reg:DI 2 cx)
(zero_extend:DI (mem:SI (reg/v/f:DI 4 si [orig:93 b ] [93]) [1
*b_13(D)+0 S4 A32]))) "/app/example.cpp":3:10 159 {*zero_extendsidi2}
(nil))
(insn 28 7 8 2 (set (reg:DI 0 ax)
(reg:DI 2 cx)) "/app/example.cpp":3:10 -1
(nil))
(insn 8 28 29 2 (set (reg:DI 36 r8)
(zero_extend:DI (mem:SI (plus:DI (reg/v/f:DI 4 si [orig:93 b ] [93])
(const_int 4 [0x4])) [1 MEM[(unsigned int *)b_13(D) + 4B]+0
S4 A32]))) "/app/example.cpp":3:20 159 {*zero_extendsidi2}
(nil))
(insn 29 8 11 2 (set (reg:DI 1 dx)
(reg:DI 36 r8)) "/app/example.cpp":3:20 -1
(nil))
Which is good.
cprop_hardreg can copyprop the value of r8 into dx's usage and able to remove
insn29. But does not do the same for cx for ax, I didn't look into why.
This is why the only one mov and not 2.
[Bug fortran/110241] New: Redundant temporaries passing empty array constructors
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110241
Bug ID: 110241
Summary: Redundant temporaries passing empty array constructors
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: anlauf at gcc dot gnu.org
Target Milestone: ---
Found while working on pr86277:
program p
call sub ([real :: 42.]) ! Single temporary
call sub ([real ::]) ! Double temporary
contains
subroutine sub (arg)
real, intent(in), optional :: arg(:)
if (.not. present (arg)) stop 1
end
end
The dump-tree (at r14-1795-gc1691509e5a887) shows the following for the
first call:
{
static real(kind=4) A.4[1] = {4.2e+1};
struct array01_real(kind=4) parm.5;
parm.5.span = 4;
parm.5.dtype = {.elem_len=4, .rank=1, .type=3};
parm.5.dim[0].lbound = 1;
parm.5.dim[0].ubound = 1;
parm.5.dim[0].stride = 1;
parm.5.data = (void *) &A.4[0];
parm.5.offset = -1;
sub (&parm.5);
}
which is as expected, but for the second call:
{
struct array01_real(kind=4) atmp.6;
real(kind=4) A.7[0];
struct array01_real(kind=4) atmp.9;
real(kind=4) A.10[0];
typedef real(kind=4) [0];
atmp.6.dtype = {.elem_len=4, .rank=1, .type=3};
atmp.6.dim[0].stride = 1;
atmp.6.dim[0].lbound = 0;
atmp.6.dim[0].ubound = -1;
atmp.6.span = 4;
atmp.6.data = (void * restrict) &A.7;
atmp.6.offset = 0;
typedef real(kind=4) [0];
atmp.9.dtype = {.elem_len=4, .rank=1, .type=3};
atmp.9.dim[0].stride = 1;
atmp.9.dim[0].lbound = 0;
atmp.9.dim[0].ubound = -1;
atmp.9.span = 4;
atmp.9.data = (void * restrict) &A.10;
atmp.9.offset = 0;
{
integer(kind=8) S.11;
S.11 = 0;
while (1)
{
if (S.11 >= 0) goto L.2;
(*(real(kind=4)[0] * restrict) atmp.9.data)[S.11] =
(*(real(kind=4)[0] * restrict) atmp.6.data)[S.11];
S.11 = S.11 + 1;
}
L.2:;
}
sub (&atmp.9);
}
While this is at least correct code (as opposed to before the fix for pr86277),
it could be as simple as for the non-empty constructor.
(There's a patch attached to the other pr demonstrating that this can be
achieved for this code snippet).
[Bug fortran/86277] Presence of optional arguments not recognized for zero length arrays
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86277 --- Comment #34 from anlauf at gcc dot gnu.org --- The missed-optimization (duplicate temporaries) is now tracked in pr110241.
[Bug c++/110242] New: ICE on valid (decltype with lambda)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110242
Bug ID: 110242
Summary: ICE on valid (decltype with lambda)
Product: gcc
Version: 12.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: stevenxia990430 at gmail dot com
Target Milestone: ---
The following program reports an internal compiler error: error reporting
routines re-entered.
To quickly reproduce: https://gcc.godbolt.org/z/h4aG89rWT
```
#include
template
auto foo(const Tuple& t) -> decltype(([](auto&&... xs){return 0;})){
}
int main(){
const std::tuple t{1};
return foo([](){ return 0;})(t);
}
```
Note that this code when tested on clang-trunk successfully compiles.
[Bug c/110243] New: Wrong code at -O3 on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110243
Bug ID: 110243
Summary: Wrong code at -O3 on x86_64-linux-gnu
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: shaohua.li at inf dot ethz.ch
Target Milestone: ---
Since GCC-13, gcc at -O3 produces wrong code.
Compiler explorer: https://godbolt.org/z/jnroxhddY
$ cat a.c
#define X 11
char a;
long b = X;
int c[9][1];
unsigned d;
static long *e = &b, *f = &b;
int g() {
if (a && a <= '9')
return '0';
if (a)
return 10;
return -1;
}
int main() {
d = 0;
for (; (int)*f -(X-1) + d < 9; d++)
c[g() + (int)*f + ((int)*e - X) -(X-1) + d]
[0] = 0;
}
$
$ gcc-tk -O3 a.c &&./a.out
Segmentation fault
$
$ gcc-tk -O0 a.c &&./a.out
$
$ gcc-tk -fsanitize=address,undefined a.c &&./a.out
$
$ gcc-tk -v
Using built-in specs.
COLLECT_GCC=gcc-tk
COLLECT_LTO_WRAPPER=/zdata/shaoli/compilers/ccbuilder-compilers/gcc-bf470895905e9152424076d1630a9d2c60de023b/libexec/gcc/x86_64-pc-linux-gnu/14.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../configure --disable-multilib --disable-bootstrap
--enable-languages=c,c++
--prefix=/zdata/shaoli/compilers/ccbuilder-compilers/gcc-bf470895905e9152424076d1630a9d2c60de023b
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 14.0.0 20230612 (experimental) (GCC)
$
[Bug tree-optimization/110243] [13/14 Regression] Wrong code at -O3 on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110243 Andrew Pinski changed: What|Removed |Added Summary|Wrong code at -O3 on|[13/14 Regression] Wrong |x86_64-linux-gnu|code at -O3 on ||x86_64-linux-gnu Known to fail||13.1.0 Last reconfirmed||2023-06-13 Target Milestone|--- |13.2 Status|UNCONFIRMED |NEW Component|middle-end |tree-optimization Ever confirmed|0 |1 --- Comment #1 from Andrew Pinski --- Confirmed. I don't know if this is an IV-OPTs issue but turning off iv-opts fixes the issue ...
[Bug c/84890] Overly verbose notes for missing headers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84890 --- Comment #11 from CVS Commits --- The master branch has been updated by David Malcolm : https://gcc.gnu.org/g:7474c46cf2d3715fe23871671c756fd5f65bc225 commit r14-1798-g7474c46cf2d3715fe23871671c756fd5f65bc225 Author: David Malcolm Date: Tue Jun 13 17:42:47 2023 -0400 c/c++: use positive tone in missing header notes [PR84890] Quoting "How a computer should talk to people" (as quoted in "Concepts Error Messages for Humans"): "Various negative tones or actions are unfriendly: being manipulative, not giving a second chance, talking down, using fashionable slang, blaming. We must not seem to blame the person. We should avoid suggesting that the person is inadequate. Phrases like "you forgot" may seem harmless, but what if a computer said this to you four or five times in two minutes? Anyway, the person may disagree, so why risk offense?" gcc/c-family/ChangeLog: PR c/84890 * known-headers.cc (suggest_missing_header::~suggest_missing_header): Reword note to avoid negative tone of "forgetting". gcc/cp/ChangeLog: PR c/84890 * name-lookup.cc (missing_std_header::~missing_std_header): Reword note to avoid negative tone of "forgetting". gcc/testsuite/ChangeLog: PR c/84890 * g++.dg/cpp2a/srcloc3.C: Update expected message. * g++.dg/lookup/missing-std-include-2.C: Likewise. * g++.dg/lookup/missing-std-include-3.C: Likewise. * g++.dg/lookup/missing-std-include-6.C: Likewise. * g++.dg/lookup/missing-std-include.C: Likewise. * g++.dg/spellcheck-inttypes.C: Likewise. * g++.dg/spellcheck-stdint.C: Likewise. * g++.dg/spellcheck-stdlib.C: Likewise. * gcc.dg/spellcheck-inttypes.c: Likewise. * gcc.dg/spellcheck-stdbool.c: Likewise. * gcc.dg/spellcheck-stdint.c: Likewise. * gcc.dg/spellcheck-stdlib.c: Likewise. Signed-off-by: David Malcolm
[Bug c/84890] Overly verbose notes for missing headers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84890 David Malcolm changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #12 from David Malcolm --- Should be fixed on trunk for GCC 14 by the above patch.
[Bug c++/90342] Misleading #include system fixit when using an older C++ version
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90342 David Malcolm changed: What|Removed |Added Resolution|--- |FIXED CC||dmalcolm at gcc dot gnu.org Status|NEW |RESOLVED --- Comment #3 from David Malcolm --- This was fixed in r8-7704-ge1c7971b81abab.
[Bug c++/110164] Improve diagnostic for incomplete standard library types due to missing include
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110164 David Malcolm changed: What|Removed |Added Status|NEW |ASSIGNED CC||dmalcolm at gcc dot gnu.org --- Comment #2 from David Malcolm --- Thanks for filing this. I'm testing a patch for it.
[Bug middle-end/110233] [12/13/14 Regression] Wrong code at -Os on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110233 Andrew Pinski changed: What|Removed |Added Last reconfirmed||2023-06-14 Summary|Wrong code at -Os on|[12/13/14 Regression] Wrong |x86_64-linux-gnu|code at -Os on ||x86_64-linux-gnu Component|c |middle-end Status|UNCONFIRMED |NEW Known to work||11.3.0 Known to fail||12.1.0 Target Milestone|--- |12.4 Ever confirmed|0 |1 --- Comment #1 from Andrew Pinski --- Confirmed. -fno-ivopts fixes the runtime issue ...
[Bug c/65213] Extend -Wmissing-declarations to variables [i.e. add -Wmissing-variable-declarations]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65213 Eric Gallager changed: What|Removed |Added Keywords||patch URL||https://gcc.gnu.org/piperma ||il/gcc-patches/2023-June/62 ||1564.html --- Comment #3 from Eric Gallager --- A patch has been posted to the gcc-patches mailing list: https://gcc.gnu.org/pipermail/gcc-patches/2023-June/621564.html
[Bug middle-end/110233] [12/13/14 Regression] Wrong code at -Os on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110233 Andrew Pinski changed: What|Removed |Added CC||aldyh at gcc dot gnu.org --- Comment #2 from Andrew Pinski --- VRP2/DOM3 produces the wrong folding for some reason: Folding statement: _27 = b.6_9 * 2; Queued stmt for removal. Folds to: 2147483647 I don't uinderstand how it could get that from: # RANGE [irange] long unsigned int [0, 2147483647][18446744071562067968, +INF] _8 = (long unsigned intD.10) c.5_7; # VUSE <.MEM_18(D)> b.6_9 = bD.2751; # RANGE [irange] long unsigned int [0, 2147483647][18446744071562067968, +INF] _10 = (long unsigned intD.10) b.6_9; # RANGE [irange] long unsigned int [0, 4294967294][18446744069414584320, +INF] _11 = _8 + _10; # RANGE [irange] long unsigned int [0, 813160647][18446744065932777673, +INF] _12 = _11 + 18446744070227744969; if (_12 <= 2) goto ; [50.00%] else goto ; [50.00%] ;;succ: 3 [50.0% (guessed)] count:357878153 (estimated locally) (TRUE_VALUE,EXECUTABLE) ;;9 [50.0% (guessed)] count:357878153 (estimated locally) (FALSE_VALUE,EXECUTABLE) ;; basic block 3, loop depth 0, count 357878153 (estimated locally), maybe hot ;;prev block 2, next block 4, flags: (NEW, REACHABLE, VISITED) ;;pred: 2 [50.0% (guessed)] count:357878153 (estimated locally) (TRUE_VALUE,EXECUTABLE) _28 = b.6_9 * 2;
[Bug c++/110244] New: False error of vector memory leak
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110244
Bug ID: 110244
Summary: False error of vector memory leak
Product: gcc
Version: 12.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: gimira8592 at aramask dot com
Target Milestone: ---
Created attachment 55320
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55320&action=edit
the preprocessed file (*.i*) that triggers the bug, generated by adding
-save-temps
Version of GCC: (Ubuntu 12.2.0-17ubuntu1) 12.2.0
OS and Version: Ubuntu 23.04, Linux 6.2.0-20-generic
GCC configuration: -fanalyzer std=c++20
To trigger bug run this code
int main()
{
std::vector vec(2);
}
and when you try to compile it, you should see this error
leak of ‘vec.std::vector::.std::_Vector_base >::_M_impl.std::_Vector_base
>::_Vector_impl::.std::_Vector_base
>::_Vector_impl_data::_M_start’ [CWE-401] [-Werror=analyzer-malloc-leak]
Looks like a bug in GCC's static analyzer, because that code certainly does not
leak. Interestingly it only happens with C++20
It still happens with the latest GCC versions: https://godbolt.org/z/o6GbGcMaP
Apparently its trigger by the addition of constexpr to the ctor/dtor in C++20
(and beyond).
Apparently this error does not seem to occur with std::string but it do occur
with data type like int, double, long and char and fails to compile.
If you just create an uninitialized vector or default initialize with brace, it
will compile without any error but if you set it size or initialize with a
value then it will give memory leak error.
To show that this is related to constexpr on the ctor/dtor, you can #define
_GLIBCXX20_CONSTEXPR before #including in the C++20 version.
If you do that to effectively "define away" the constexpr in the C++20 version,
the static analyzer wont fail. Of course that is very much UB and pretty
dangerous (as you are actively meddling with the internals of the library and
the compilers assumptions), but it shows the point.
[Bug analyzer/110244] False error of vector leaking memory
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110244 Andrew Pinski changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |dmalcolm at gcc dot gnu.org Component|c++ |analyzer --- Comment #1 from Andrew Pinski --- It is currently know analyzer is not very good with C++ code So this is not suprising at all.
[Bug c++/71644] gcc 6.1 generates movaps for unaligned memory
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71644 rr7crecb3z at liamekaens dot com changed: What|Removed |Added CC||rr7crecb3z at liamekaens dot com --- Comment #1 from rr7crecb3z at liamekaens dot com --- 7 years and this bug is STILL "UNCONFIRMED". I'm here because I ran into this bug after building Python, using GCC 11.3.0. The reproduction program provided by jus...@gmx.li back in 2016 STILL reproduces the bug in GCC 11.3.0. Can't there just be a way to disable the use of the MOVAPS instruction entirely, without having to disable optimizations that don't have bugs? I'm sick and tired of dealing with this bug. GCC obviously will never be able to be trusted to use the MOVAPS instruction correctly.
[Bug c++/110245] New: constant evaluation fails with uninitialized union and default constructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110245
Bug ID: 110245
Summary: constant evaluation fails with uninitialized union and
default constructor
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: danakj at orodu dot net
Target Milestone: ---
```
struct Store {
constexpr Store() {}
union {
int i;
};
bool b = false;
};
struct C {
constexpr C() = default;
Store s;
};
int main() {
constexpr auto c = C(); //
}
```
This should compile but does not, GCC complains that it refers to an
incompletely initialized variable. Union members are not required to be active.
https://godbolt.org/z/G9vcosTG1
Reproduced on GCC trunk and GCC 11.
[Bug c++/110245] constant evaluation fails with uninitialized union and default constructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110245
--- Comment #1 from danakj at orodu dot net ---
Note that GCC has no problem with doing this constexpr construction if the
object is not stored as an lvalue.
```
struct Store {
constexpr Store() {}
union {
int i;
};
bool b = false;
};
struct C {
constexpr C() = default;
Store s;
};
int main() {
constexpr auto c = C(); // Fails.
constexpr auto b = C().s.b; // OK
}
```
https://godbolt.org/z/31MTenKoo
[Bug sanitizer/83780] False positive alignment error with -fsanitize=undefined with virtual base
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83780 --- Comment #5 from Andrew Pinski --- (In reply to Ivan Bodrov from comment #2) > I have reported the same bug for Clang: > https://bugs.llvm.org/show_bug.cgi?id=35902 > > Unlike GCC, Clang is also eager to generate unaligned "movaps" instructions, > crashing the program. Afaik GCC does not generate SSE instructions that > often, but I wonder if it can do something similar. Yes, see PR 71644 where that could happen.
[Bug c++/71644] gcc 6.1 generates movaps for unaligned memory
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71644 Andrew Pinski changed: What|Removed |Added Last reconfirmed||2023-06-14 Ever confirmed|0 |1 Status|UNCONFIRMED |NEW --- Comment #2 from Andrew Pinski --- Confirmed. PR 83780 has a related issue going on.
[Bug c++/97665] constexpr union array member incorrectly rejected as non-constexpr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97665 --- Comment #12 from Andrew Pinski --- (In reply to Jiang An from comment #11) > This looks like CWG issue 2558 (currently unresolved). > > https://cplusplus.github.io/CWG/issues/2558.html It was voted in a few months after this comment was added. But the original testcase has no scalars ...
[Bug c++/110245] constant evaluation fails with uninitialized union and default constructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110245 --- Comment #2 from Andrew Pinski --- So if I read: https://cplusplus.github.io/CWG/issues/2558.html there is still an open question about "Union types shall be initialized such that they have an active member in the result of a constant expression" but I am not 100% sure here.
[Bug other/110239] [14 regression] std/format/functions/format.cc fails after r14-1648-g628ba410b9265d
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110239 Jonathan Wakely changed: What|Removed |Added Last reconfirmed||2023-06-14 Assignee|unassigned at gcc dot gnu.org |redi at gcc dot gnu.org Status|UNCONFIRMED |ASSIGNED Ever confirmed|0 |1 Target Milestone|--- |14.0 Keywords||testsuite-fail
[Bug target/110235] [14 Regression] Wrong use of us_truncate in SSE and AVX RTL representation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110235 Andrew Pinski changed: What|Removed |Added Keywords||testsuite-fail Summary|Wrong use of us_truncate in |[14 Regression] Wrong use |SSE and AVX RTL |of us_truncate in SSE and |representation |AVX RTL representation Target Milestone|--- |14.0
[Bug tree-optimization/37916] [10/11/12/13/14 Regression] SSA names causing register pressure; unnecessarily many simultaneously "live" names.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=37916 Andrew Pinski changed: What|Removed |Added Status|ASSIGNED|NEW Assignee|hp at gcc dot gnu.org |unassigned at gcc dot gnu.org --- Comment #37 from Andrew Pinski --- (In reply to Hans-Peter Nilsson from comment #30) > Unassigning myself to belatedly celebrate the 10th anniversary of this PR. > I'm replacing with a reference to a patch (the start of a thread) that > claims to fix the problem. Thanks Michael, hope it gets an ok eventually! Looks like you forgot to change Assignee and then Richi came along and change the status back to assigned. I am going to fix both of that here.
[Bug modula2/110246] New: Using variables of type CHAR or BYTE as array index does not work
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110246
Bug ID: 110246
Summary: Using variables of type CHAR or BYTE as array index
does not work
Product: gcc
Version: 13.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: modula2
Assignee: gaius at gcc dot gnu.org
Reporter: ad...@tho-otto.de
Target Milestone: ---
In the following example:
IMPLEMENTATION MODULE foo;
FROM SYSTEM IMPORT BYTE;
VAR arr: ARRAY['A'..'Z'] OF INTEGER;
VAR ch: CHAR;
BEGIN
FOR ch := 'A' TO 'Z' DO arr[ch] := 0 END;
END foo.
I get error messages:
/usr/lib64/gcc/x86_64-suse-linux/13/m2/m2pim/COROUTINES.def:37:1: error: type
incompatibility, attempting to use a string ('_T38') when a CHAR is expected
/usr/lib64/gcc/x86_64-suse-linux/13/m2/m2pim/COROUTINES.def:37:1: error: type
incompatibility, attempting to use a string ('_T38') when a CHAR is expected
/usr/lib64/gcc/x86_64-suse-linux/13/m2/m2pim/COROUTINES.def:37:1: error: type
incompatibility, attempting to use a string ('_T38') when a CHAR is expected
/usr/lib64/gcc/x86_64-suse-linux/13/m2/m2pim/COROUTINES.def:37:1: error: type
incompatibility, attempting to use a string ('_T38') when a CHAR is expected
(note also the totally unrelated source line in the error message)
Changing the type of ch to BYTE i get instead:
/usr/lib64/gcc/x86_64-suse-linux/13/m2/m2pim/COROUTINES.def:37:1: error: left
operand ‘ch’ of type ‘BYTE’ is not allowed in binary expression +
[Bug tree-optimization/37916] [10/11/12/13/14 Regression] SSA names causing register pressure; unnecessarily many simultaneously "live" names.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=37916 --- Comment #38 from Andrew Pinski --- So for aarch64, I noticed that on the trunk, we no longer produce any stores to the stack (GCC 13 had a save/restore of x29 and x30; x29 is the fp). The difference is no longer using x30 as a register. I Have not looked why though. GCC 7 had saving also x19. I suspect that was some aarch64 specific change as x86_64 code generation looked around the same between GCC 13 and the trunk.
[Bug modula2/110246] Using variables of type CHAR or BYTE as array index does not work
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110246 --- Comment #1 from Thorsten Otto --- Edit: the problem seems to be caused by using a FOR loop. Changing it to a similar WHILE loop: ch := 'A'; WHILE ch <= 'Z' DO arr[ch] := 0; INC(ch); END; does work without problems.
[Bug middle-end/46555] [10/11/12/13/14 Regression] PHI RTL expansion leads to CSiBE regression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=46555 --- Comment #18 from Andrew Pinski --- (In reply to Richard Biener from comment #1) > Yep. That's one optimization that was removed (out-of-SSA did that) and > we thought of doing this reverse mergephi optimization as a separate pass > before expansion. make_forwarders_with_degenerate_phis in tree-ssa-dce.cc does basically (if I read the code correctly) that which was added by r12-5301-g045206450386 for PR 102880 which is why I am seeing it fixed for GCC 12 at -O2. And the reason why -O1 I still see the old PHI behavior.
[Bug middle-end/90094] better handling of x == LONG_MIN on x86-64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90094
Paul Eggert changed:
What|Removed |Added
CC||eggert at cs dot ucla.edu
--- Comment #3 from Paul Eggert ---
Slightly better is this equivalent:
unsigned f (long a)
{
return __builtin_sub_overflow (0, a, &a);
}
which gcc -O2 (or -Os) compiles into:
f: xor %eax, %eax
neg %rdi
seto%al
ret
which with GCC is one byte less machine code than the __builtin_sub_overflow(a,
1, &a) approach.
[Bug target/110235] [14 Regression] Wrong use of us_truncate in SSE and AVX RTL representation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110235 --- Comment #2 from Hongtao.liu --- FAIL: gcc.target/i386/avx2-vpackssdw-2.c execution test This one is about sign saturation which should match rtl SS_TRUNCATE.
[Bug other/110178] [14 regression] gfortran.dg/gomp/target-update-1.f90 fails after r14-1579-g4ede915d5dde93
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110178 Thomas Schwinge changed: What|Removed |Added Target|powerpc64le-linux-gnu | Resolution|--- |FIXED Status|UNCONFIRMED |RESOLVED CC||tschwinge at gcc dot gnu.org Build|powerpc64le-linux-gnu | URL||https://inbox.sourceware.or ||g/202306062250.356Mo6Qw3100 ||125 at shliclel4214 dot sh.intel.c ||om Host|powerpc64le-linux-gnu | Assignee|unassigned at gcc dot gnu.org |burnus at gcc dot gnu.org Keywords||openmp --- Comment #1 from Thomas Schwinge --- Fixed as part of commit r14-1736-g38944ec2a6fa108d24e5cfbb24c52020f9aa3015 "OpenMP: Cleanups related to the 'present' modifier".
[Bug target/110247] New: suboptimal code about `no_caller_saved_registers` on caller side
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110247
Bug ID: 110247
Summary: suboptimal code about `no_caller_saved_registers` on
caller side
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: lh_mouse at 126 dot com
Target Milestone: ---
Given:
(https://gcc.godbolt.org/z/xevzx56Y5)
```
int complex(int x, int y)
__attribute__((__no_caller_saved_registers__));
int test(int x, int y, int z)
{
return complex(x, y) + complex(y, z) + complex(z, x);
}
```
My understanding is that `__no_caller_saved_registers__` says no register will
be clobbered by `complex`, so it is not necessary for GCC to establish a stack
frame and push arguments there. This is gonna help a lot if the function will
be inlined.
Clang generates much better assembly but I wonder whether it is valid to assume
that arguments registers are also preserved, like
```
test:
push rcx; align %rsp
; %edi := x, %esi = y, %edx = z
call complex;
mov ecx, eax; %ecx = complex(x, y)
xchg edi, esi ; %edi = y
xchg esi, edx ; %esi = z, %edx = x
call complex;
add ecx, eax; %ecx += complex(y, z)
mov edi, esi; %edi = z
mov esi, edx; %esi = x
call complex;
add eax, ecx; %eax = %ecx + complex(z, x)
pop rcx
ret
```
