[Bug rtl-optimization/106707] New: [13 Regression] ICE: in cselib_record_set, at cselib.cc:2687 with -Oz -g -fno-cprop-registers -fno-dce
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106707 Bug ID: 106707 Summary: [13 Regression] ICE: in cselib_record_set, at cselib.cc:2687 with -Oz -g -fno-cprop-registers -fno-dce Product: gcc Version: 13.0 Status: UNCONFIRMED Keywords: ice-on-valid-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 Created attachment 53487 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53487=edit reduced testcase Compiler output: $ x86_64-pc-linux-gnu-gcc -Oz -g -fno-cprop-registers -fno-dce testcase.c during RTL pass: vartrack testcase.c: In function 'foo': testcase.c:15:1: internal compiler error: in cselib_record_set, at cselib.cc:2687 15 | } | ^ 0x6b5068 cselib_record_set /repo/gcc-trunk/gcc/cselib.cc:2687 0xef574c cselib_record_set /repo/gcc-trunk/gcc/cselib.cc:3011 0xef574c cselib_record_sets /repo/gcc-trunk/gcc/cselib.cc:3016 0xef7a86 cselib_process_insn(rtx_insn*) /repo/gcc-trunk/gcc/cselib.cc:3139 0x16ebde0 vt_initialize /repo/gcc-trunk/gcc/var-tracking.cc:10284 0x16f1c23 variable_tracking_main_1 /repo/gcc-trunk/gcc/var-tracking.cc:10512 0x16f1ddb variable_tracking_main() /repo/gcc-trunk/gcc/var-tracking.cc:10565 0x16f1ddb execute /repo/gcc-trunk/gcc/var-tracking.cc:10602 Please submit a full bug report, with preprocessed source (by using -freport-bug). Please include the complete backtrace with any bug report. See <https://gcc.gnu.org/bugs/> for instructions. $ x86_64-pc-linux-gnu-gcc -v Using built-in specs. COLLECT_GCC=/repo/gcc-trunk/binary-latest-amd64/bin/x86_64-pc-linux-gnu-gcc COLLECT_LTO_WRAPPER=/repo/gcc-trunk/binary-trunk-r13-2130-20220821001633-gd6a39c25c05-checking-yes-rtl-df-extra-amd64/bin/../libexec/gcc/x86_64-pc-linux-gnu/13.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 --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-r13-2130-20220821001633-gd6a39c25c05-checking-yes-rtl-df-extra-amd64 Thread model: posix Supported LTO compression algorithms: zlib zstd gcc version 13.0.0 20220821 (experimental) (GCC)
[Bug tree-optimization/106687] [13 Regression] Wrong code with -O2 since r13-438-gcf2141a0c640fc9b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106687 Martin Liška changed: What|Removed |Added Summary|[13 Regression] Wrong code |[13 Regression] Wrong code |with -O2|with -O2 since ||r13-438-gcf2141a0c640fc9b CC||aldyh at gcc dot gnu.org, ||amacleod at redhat dot com, ||marxin at gcc dot gnu.org --- Comment #2 from Martin Liška --- Started with r13-438-gcf2141a0c640fc9b.
[PATCH (pushed)] analyzer: add missing final keyword
Fixes the following clang warning:
gcc/analyzer/region-model.cc:5096:8: warning: 'subclass_equal_p' overrides a
member function but is not marked 'override' [-Winconsistent-missing-override]
gcc/analyzer/ChangeLog:
* region-model.cc: Add missing final keyword.
---
gcc/analyzer/region-model.cc | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/gcc/analyzer/region-model.cc b/gcc/analyzer/region-model.cc
index ec29be259b5..5a64c00ef14 100644
--- a/gcc/analyzer/region-model.cc
+++ b/gcc/analyzer/region-model.cc
@@ -5093,7 +5093,7 @@ public:
return "float_as_size_arg_diagnostic";
}
- bool subclass_equal_p (const pending_diagnostic ) const
+ bool subclass_equal_p (const pending_diagnostic ) const final override
{
return same_tree_p (m_arg, ((const float_as_size_arg &) other).m_arg);
}
--
2.37.2
[PATCH] Add __m128bf16/__m256bf16/__m512bf16 type for bf16 abi test
Hi all,
This patch added __m128bf16/__m256bf16/__m512bf16 type in testcases.
BRs,
Haochen
gcc/testsuite/ChangeLog:
* gcc.target/x86_64/abi/bf16/bf16-helper.h:
Add _m128bf16/m256bf16/_m512bf16.
* gcc.target/x86_64/abi/bf16/m512bf16/bf16-zmm-check.h:
Include bf16-helper.h.
---
gcc/testsuite/gcc.target/x86_64/abi/bf16/bf16-helper.h| 4
.../gcc.target/x86_64/abi/bf16/m512bf16/bf16-zmm-check.h | 1 +
2 files changed, 5 insertions(+)
diff --git a/gcc/testsuite/gcc.target/x86_64/abi/bf16/bf16-helper.h
b/gcc/testsuite/gcc.target/x86_64/abi/bf16/bf16-helper.h
index 83d89fcf62c..e090a7254f4 100644
--- a/gcc/testsuite/gcc.target/x86_64/abi/bf16/bf16-helper.h
+++ b/gcc/testsuite/gcc.target/x86_64/abi/bf16/bf16-helper.h
@@ -1,3 +1,7 @@
+typedef __bf16 __m128bf16 __attribute__((__vector_size__(16),
__aligned__(16)));
+typedef __bf16 __m256bf16 __attribute__((__vector_size__(32),
__aligned__(32)));
+typedef __bf16 __m512bf16 __attribute__((__vector_size__(64),
__aligned__(64)));
+
typedef union
{
float f;
diff --git a/gcc/testsuite/gcc.target/x86_64/abi/bf16/m512bf16/bf16-zmm-check.h
b/gcc/testsuite/gcc.target/x86_64/abi/bf16/m512bf16/bf16-zmm-check.h
index 8379fcfaf8c..9cd39b878dd 100644
--- a/gcc/testsuite/gcc.target/x86_64/abi/bf16/m512bf16/bf16-zmm-check.h
+++ b/gcc/testsuite/gcc.target/x86_64/abi/bf16/m512bf16/bf16-zmm-check.h
@@ -1,4 +1,5 @@
#include
+#include "../bf16-helper.h"
static void do_test (void);
--
2.18.1
Re: [PATCH] Add ABI test for __bf16 type
On Mon, Aug 22, 2022 at 9:02 AM Hongtao Liu wrote: > > On Sat, Aug 20, 2022 at 1:31 AM H.J. Lu wrote: > > > > On Thu, Aug 18, 2022 at 5:56 PM Hongtao Liu via Gcc-patches > > wrote: > > > > > > On Thu, Aug 18, 2022 at 3:36 PM Haochen Jiang via Gcc-patches > > > wrote: > > > > > > > > Hi all, > > > > > > > > This patch aims to add bf16 abi test after the whole __bf16 type is > > > > added. > > > > > > > > Regtested on x86_64-pc-linux-gnu. Ok for trunk? > > > Ok. > > > > All BF16 ABI tests failed due to missing __m128bf16/__m256bf16/__m512bf16. > > When will __bf16 types be added? > It should be already in the trunk. Oh, __m128bf16/__m256bf16/__m512bf16 is not added to the trunk. > > > > > > > > > > BRs, > > > > Haochen > > > > > > > > gcc/testsuite/ChangeLog: > > > > > > > > * gcc.target/x86_64/abi/bf16/abi-bf16.exp: New test. > > > > * gcc.target/x86_64/abi/bf16/args.h: Ditto. > > > > * gcc.target/x86_64/abi/bf16/asm-support.S: Ditto. > > > > * gcc.target/x86_64/abi/bf16/bf16-check.h: Ditto. > > > > * gcc.target/x86_64/abi/bf16/bf16-helper.h: Ditto. > > > > * gcc.target/x86_64/abi/bf16/defines.h: Ditto. > > > > * gcc.target/x86_64/abi/bf16/m256bf16/abi-bf16-ymm.exp: Ditto. > > > > * gcc.target/x86_64/abi/bf16/m256bf16/args.h: Ditto. > > > > * gcc.target/x86_64/abi/bf16/m256bf16/asm-support.S: Ditto. > > > > * gcc.target/x86_64/abi/bf16/m256bf16/bf16-ymm-check.h: Ditto. > > > > * gcc.target/x86_64/abi/bf16/m256bf16/test_m256_returning.c: > > > > Ditto. > > > > * gcc.target/x86_64/abi/bf16/m256bf16/test_passing_m256.c: > > > > Ditto. > > > > * gcc.target/x86_64/abi/bf16/m256bf16/test_passing_structs.c: > > > > Ditto. > > > > * gcc.target/x86_64/abi/bf16/m256bf16/test_passing_unions.c: > > > > Ditto. > > > > * gcc.target/x86_64/abi/bf16/m256bf16/test_varargs-m256.c: > > > > Ditto. > > > > * gcc.target/x86_64/abi/bf16/m512bf16/abi-bf16-zmm.exp: Ditto. > > > > * gcc.target/x86_64/abi/bf16/m512bf16/args.h: Ditto. > > > > * gcc.target/x86_64/abi/bf16/m512bf16/asm-support.S: Ditto. > > > > * gcc.target/x86_64/abi/bf16/m512bf16/bf16-zmm-check.h: Ditto. > > > > * gcc.target/x86_64/abi/bf16/m512bf16/test_m512_returning.c: > > > > Ditto. > > > > * gcc.target/x86_64/abi/bf16/m512bf16/test_passing_m512.c: > > > > Ditto. > > > > * gcc.target/x86_64/abi/bf16/m512bf16/test_passing_structs.c: > > > > Ditto. > > > > * gcc.target/x86_64/abi/bf16/m512bf16/test_passing_unions.c: > > > > Ditto. > > > > * gcc.target/x86_64/abi/bf16/m512bf16/test_varargs-m512.c: > > > > Ditto. > > > > * gcc.target/x86_64/abi/bf16/macros.h: Ditto. > > > > * > > > > gcc.target/x86_64/abi/bf16/test_3_element_struct_and_unions.c: Ditto. > > > > * gcc.target/x86_64/abi/bf16/test_basic_alignment.c: Ditto. > > > > * gcc.target/x86_64/abi/bf16/test_basic_array_size_and_align.c: > > > > Ditto. > > > > * gcc.target/x86_64/abi/bf16/test_basic_returning.c: Ditto. > > > > * gcc.target/x86_64/abi/bf16/test_basic_sizes.c: Ditto. > > > > * > > > > gcc.target/x86_64/abi/bf16/test_basic_struct_size_and_align.c: Ditto. > > > > * gcc.target/x86_64/abi/bf16/test_basic_union_size_and_align.c: > > > > Ditto. > > > > * gcc.target/x86_64/abi/bf16/test_m128_returning.c: Ditto. > > > > * gcc.target/x86_64/abi/bf16/test_passing_floats.c: Ditto. > > > > * gcc.target/x86_64/abi/bf16/test_passing_m128.c: Ditto. > > > > * gcc.target/x86_64/abi/bf16/test_passing_structs.c: Ditto. > > > > * gcc.target/x86_64/abi/bf16/test_passing_unions.c: Ditto. > > > > * gcc.target/x86_64/abi/bf16/test_struct_returning.c: Ditto. > > > > * gcc.target/x86_64/abi/bf16/test_varargs-m128.c: Ditto. > > > > > > > > -- > > H.J. > > > > -- > BR, > Hongtao -- BR, Hongtao
Re: [PATCH] Add ABI test for __bf16 type
On Sat, Aug 20, 2022 at 1:31 AM H.J. Lu wrote: > > On Thu, Aug 18, 2022 at 5:56 PM Hongtao Liu via Gcc-patches > wrote: > > > > On Thu, Aug 18, 2022 at 3:36 PM Haochen Jiang via Gcc-patches > > wrote: > > > > > > Hi all, > > > > > > This patch aims to add bf16 abi test after the whole __bf16 type is added. > > > > > > Regtested on x86_64-pc-linux-gnu. Ok for trunk? > > Ok. > > All BF16 ABI tests failed due to missing __m128bf16/__m256bf16/__m512bf16. > When will __bf16 types be added? It should be already in the trunk. > > > > > > > BRs, > > > Haochen > > > > > > gcc/testsuite/ChangeLog: > > > > > > * gcc.target/x86_64/abi/bf16/abi-bf16.exp: New test. > > > * gcc.target/x86_64/abi/bf16/args.h: Ditto. > > > * gcc.target/x86_64/abi/bf16/asm-support.S: Ditto. > > > * gcc.target/x86_64/abi/bf16/bf16-check.h: Ditto. > > > * gcc.target/x86_64/abi/bf16/bf16-helper.h: Ditto. > > > * gcc.target/x86_64/abi/bf16/defines.h: Ditto. > > > * gcc.target/x86_64/abi/bf16/m256bf16/abi-bf16-ymm.exp: Ditto. > > > * gcc.target/x86_64/abi/bf16/m256bf16/args.h: Ditto. > > > * gcc.target/x86_64/abi/bf16/m256bf16/asm-support.S: Ditto. > > > * gcc.target/x86_64/abi/bf16/m256bf16/bf16-ymm-check.h: Ditto. > > > * gcc.target/x86_64/abi/bf16/m256bf16/test_m256_returning.c: > > > Ditto. > > > * gcc.target/x86_64/abi/bf16/m256bf16/test_passing_m256.c: Ditto. > > > * gcc.target/x86_64/abi/bf16/m256bf16/test_passing_structs.c: > > > Ditto. > > > * gcc.target/x86_64/abi/bf16/m256bf16/test_passing_unions.c: > > > Ditto. > > > * gcc.target/x86_64/abi/bf16/m256bf16/test_varargs-m256.c: Ditto. > > > * gcc.target/x86_64/abi/bf16/m512bf16/abi-bf16-zmm.exp: Ditto. > > > * gcc.target/x86_64/abi/bf16/m512bf16/args.h: Ditto. > > > * gcc.target/x86_64/abi/bf16/m512bf16/asm-support.S: Ditto. > > > * gcc.target/x86_64/abi/bf16/m512bf16/bf16-zmm-check.h: Ditto. > > > * gcc.target/x86_64/abi/bf16/m512bf16/test_m512_returning.c: > > > Ditto. > > > * gcc.target/x86_64/abi/bf16/m512bf16/test_passing_m512.c: Ditto. > > > * gcc.target/x86_64/abi/bf16/m512bf16/test_passing_structs.c: > > > Ditto. > > > * gcc.target/x86_64/abi/bf16/m512bf16/test_passing_unions.c: > > > Ditto. > > > * gcc.target/x86_64/abi/bf16/m512bf16/test_varargs-m512.c: Ditto. > > > * gcc.target/x86_64/abi/bf16/macros.h: Ditto. > > > * gcc.target/x86_64/abi/bf16/test_3_element_struct_and_unions.c: > > > Ditto. > > > * gcc.target/x86_64/abi/bf16/test_basic_alignment.c: Ditto. > > > * gcc.target/x86_64/abi/bf16/test_basic_array_size_and_align.c: > > > Ditto. > > > * gcc.target/x86_64/abi/bf16/test_basic_returning.c: Ditto. > > > * gcc.target/x86_64/abi/bf16/test_basic_sizes.c: Ditto. > > > * gcc.target/x86_64/abi/bf16/test_basic_struct_size_and_align.c: > > > Ditto. > > > * gcc.target/x86_64/abi/bf16/test_basic_union_size_and_align.c: > > > Ditto. > > > * gcc.target/x86_64/abi/bf16/test_m128_returning.c: Ditto. > > > * gcc.target/x86_64/abi/bf16/test_passing_floats.c: Ditto. > > > * gcc.target/x86_64/abi/bf16/test_passing_m128.c: Ditto. > > > * gcc.target/x86_64/abi/bf16/test_passing_structs.c: Ditto. > > > * gcc.target/x86_64/abi/bf16/test_passing_unions.c: Ditto. > > > * gcc.target/x86_64/abi/bf16/test_struct_returning.c: Ditto. > > > * gcc.target/x86_64/abi/bf16/test_varargs-m128.c: Ditto. > > > > -- > H.J. -- BR, Hongtao
Re: New/improved warning option for padding bytes
On Fri, Aug 19, 2022 at 6:13 AM Jonas Rahlf via Gcc wrote: > > As a firmware developer I would appreciate a warning option about padding > bytes, but only for such cases where you can reduce the number of padding > bytes by rearranging the fields. > > The current -Wpadded warns about all padding bytes, which is annoying. > > The concept sounds simple: you rearrange all fields from large to small and > check if the size changed. > > The goal is to more easily optimize RAM/flash in space constrained systems. > > Jonas That sounds like bug 52981: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52981
[Bug rtl-optimization/106705] constant prop is not undone for switches
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106705 Andrew Pinski changed: What|Removed |Added Severity|normal |enhancement --- Comment #2 from Andrew Pinski --- RTL GCSE is not doing its job for switch tables ... I suspect it never has done that though. Unless we do high and low gimple where low gimple also handles constant costs better
[Bug rtl-optimization/106705] constant prop is not undone for switches
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106705 --- Comment #1 from Andrew Pinski --- Note the cost for constant loading usually is expensive which is why this case is usually ignored ... It is more costly on in-order chips though, especially RISCV where constant forming takes 3 instructions while on most take 2 (or 1 on some).
[Bug target/106694] Redundant move instructions in ARM SVE intrinsics use cases
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106694 --- Comment #6 from JuzheZhong --- (In reply to Andrew Pinski from comment #5) > (In reply to JuzheZhong from comment #4) > > No. I am not saying the issue of "movprfx". I am saying the issue of the > > redundant "mov" instructions.: > > mov z5.d, z24.d > > mov z4.d, z25.d > > mov z3.d, z26.d > > mov z2.d, z27.d > > > > > > This is the issue that "subreg" didn't propagate across the basic block. > > Oh ld4 issue. I thought there was another bug filed against that. The > problem is even without SVE too IIR. Recently, I found LLVM optimize this kind of issues. This "subreg" issues are handled by register coalescing. I wonder if there is someone can implement this. Besides, I am working on pushing codes of RVV support to RISC-V support. I have done register coalescing for RVV and open source them in RISC-V foundation repo. I don't whether my register coalescing is appropriate to push upstream: https://github.com/riscv-collab/riscv-gcc/blob/riscv-gcc-rvv-next/gcc/ira-coalesce.cc If this is not appropriate to the global codes. I will try to make it inside RISC-V port withou changing ira.cc.
[Bug target/106694] Redundant move instructions in ARM SVE intrinsics use cases
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106694 --- Comment #5 from Andrew Pinski --- (In reply to JuzheZhong from comment #4) > No. I am not saying the issue of "movprfx". I am saying the issue of the > redundant "mov" instructions.: > mov z5.d, z24.d > mov z4.d, z25.d > mov z3.d, z26.d > mov z2.d, z27.d > > > This is the issue that "subreg" didn't propagate across the basic block. Oh ld4 issue. I thought there was another bug filed against that. The problem is even without SVE too IIRC.
[Bug lto/106706] Enabling LTO causes incorrect calculation in in_csum()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106706
Andrew Pinski changed:
What|Removed |Added
Resolution|--- |INVALID
Status|UNCONFIRMED |RESOLVED
--- Comment #2 from Andrew Pinski ---
This is an obvious C/C++ aliasing violation.
ipv4_phdr_t ipv4_phdr;
...
in_csum(({ ( uint16_t *) (_phdr); }), sizeof(ipv4_phdr), 0,
>ipv4_csum);
inside in_csum:
uint16_t
in_csum(const uint16_t *addr, size_t len, uint32_t csum, uint32_t *acc)
while (nleft > 1) {
csum += *addr++;
You need to use either -fno-strict-aliasing or you need to mark the argument
addr in in_csum as may_alias.
[Bug target/106694] Redundant move instructions in ARM SVE intrinsics use cases
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106694
--- Comment #4 from JuzheZhong ---
(In reply to Andrew Pinski from comment #1)
> This is backend issue:
> //(insn 27 31 28 (set (reg/v:VNx2DI 37 v5 [orig:98 v0 ] [98])
> //(unspec:VNx2DI [
> //(reg:VNx2BI 68 p0 [orig:105 pg ] [105])
> //(plus:VNx2DI (mult:VNx2DI (reg/v:VNx2DI 37 v5 [orig:98 v0
> ] [98])
> //(reg/v:VNx2DI 33 v1 [orig:96 v18 ] [96]))
> //(reg/v:VNx2DI 32 v0 [orig:97 v19 ] [97]))
> //(const_vector:VNx2DI repeat [
> //(const_int 0 [0])
> //])
> //] UNSPEC_SEL)) "/app/example.c":15:14 7415
> {*cond_fmavnx2di_any}
> // (nil))
> movprfx z5.d, p0/z, z5.d // 27 [c=4 l=8]
> *cond_fmavnx2di_any/2
> mad z5.d, p0/m, z1.d, z0.d
No. I am not saying the issue of "movprfx". I am saying the issue of the
redundant "mov" instructions.:
mov z5.d, z24.d
mov z4.d, z25.d
mov z3.d, z26.d
mov z2.d, z27.d
This is the issue that "subreg" didn't propagate across the basic block.
gcc-13-20220821 is now available
Snapshot gcc-13-20220821 is now available on https://gcc.gnu.org/pub/gcc/snapshots/13-20220821/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 13 git branch with the following options: git://gcc.gnu.org/git/gcc.git branch master revision d6a39c25c05c6ed5df8ce49eda719d17e40e29bb You'll find: gcc-13-20220821.tar.xz Complete GCC SHA256=527b22c4a7d6d6314805a6685d9f521cf8c638dc3618f938722dcfea711ae1d8 SHA1=acc0dd9aaa38c1bffa882a377bde0461d89cdac5 Diffs from 13-20220814 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-13 link is updated and a message is sent to the gcc list. Please do not use a snapshot before it has been announced that way.
[Bug lto/106706] Enabling LTO causes incorrect calculation in in_csum()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106706 --- Comment #1 from Quentin Armitage --- Created attachment 53486 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53486=edit Tar file containing the generated .i files and make.log
[Bug lto/106706] New: Enabling LTO causes incorrect calculation in in_csum()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106706 Bug ID: 106706 Summary: Enabling LTO causes incorrect calculation in in_csum() Product: gcc Version: 12.1.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: lto Assignee: unassigned at gcc dot gnu.org Reporter: quentin at armitage dot org.uk CC: marxin at gcc dot gnu.org Target Milestone: --- First of all, many apologies for not producing a small test case - I couldn't find a simple example to demonstrate the issue. The problem is that in_csum() (in lib/utils.c) returns an incorrect value when the first call of in_csum() is inlined in vrrp_build_vrrp_v3() (in keepalived/vrrp/vrrp.c). It appears then when the first call of in_csum() is inlined, the wrong value of the addr parameter is used. This can be observed with the following log output: Calling in_csum, 0x10a 0x300 added 0x5629 to get 0x5629 added 0x0 to get 0x5629 added 0x903d to get 0xe666 added 0x5c2e to get 0x14294 added 0x5629 to get 0x198bd added 0x1000 to get 0x1a8bd Calling in_csum, 0x3331 0x265 added 0x3331 to get 0x1dbee added 0x265 to get 0x1de53 added 0x6400 to get 0x24253 added 0x0 to get 0x24253 added 0x7f to get 0x242d2 added 0xf00 to get 0x251d2 added 0x2d15 to get 0x27ee7 added 0x2be to get 0x281a5 The two 16 bit values printed after "Calling in_csum" are the first two values that should be included in the checksum calculation, and the values after added are the values being added to the checksum. In the first call of in_csum (inlined) the first two values at 0x10 and 0x300, but the first two values output in in_csum() do not match. In the second call to in_csum() (not inlined), it can be seen that the values match. I have tried changing log_message(LOG_INFO, "added 0x%x to get 0x%x", addr[-1], csum); to log_message(LOG_INFO, "addr %p added 0x%x to get 0x%x", addr, addr[-1], csum); in in_csum() to see what value is being used for addr, but doing so stops the problem occurring. When LTO is not enabled, the equivalent to to debug output above is a follows (and these are the correct values): Calling in_csum, 0x10a 0x300 added 0x10a to get 0x10a added 0x300 to get 0x40a added 0x10a to get 0x514 added 0x100 to get 0x614 added 0x7000 to get 0x7614 added 0x1000 to get 0x8614 Calling in_csum, 0x3331 0x265 added 0x3331 to get 0xb945 added 0x265 to get 0xbbaa added 0x6400 to get 0x11faa added 0x0 to get 0x11faa added 0x7f to get 0x12029 added 0xf00 to get 0x12f29 added 0x2d15 to get 0x15c3e added 0x2be to get 0x15efc This problem has been seen with GCC 11.2 (Ubuntu 22.04), GCC 12.1.1 (Fedora 36), GCC 11.3.1 (Fedora 34), GCC 12.1.1 (Fedora 37) and GCC 12.2.1 (Fedora 38 - Rawhide). The problem does not occur when LTO is not enabled, nor with clang (with or without LTO). The problem also does not occur if in_csum() has __attribute__((noinline)). The output below and attached files were generated on Fedora 34 using gcc 11.3.1. The attached tar file contains the .i files and make.log, the full log of building keepalived. The output of gcc -v -save-temps when compiling lib/utils.c is: Using built-in specs. COLLECT_GCC=gcc OFFLOAD_TARGET_NAMES=nvptx-none OFFLOAD_TARGET_DEFAULT=1 Target: x86_64-redhat-linux Configured with: ../configure --enable-bootstrap --enable-languages=c,c++,fortran,objc,obj-c++,ada,go,d,lto --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --with-bugurl=http://bugzilla.redhat.com/bugzilla --enable-shared --enable-threads=posix --enable-checking=release --enable-multilib --with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions --enable-gnu-unique-object --enable-linker-build-id --with-gcc-major-version-only --with-linker-hash-style=gnu --enable-plugin --enable-initfini-array --with-isl=/builddir/build/BUILD/gcc-11.3.1-20220421/obj-x86_64-redhat-linux/isl-install --enable-offload-targets=nvptx-none --without-cuda-driver --enable-gnu-indirect-function --enable-cet --with-tune=generic --with-arch_32=i686 --build=x86_64-redhat-linux Thread model: posix Supported LTO compression algorithms: zlib zstd gcc version 11.3.1 20220421 (Red Hat 11.3.1-2) (GCC) COLLECT_GCC_OPTIONS='-D' 'HAVE_CONFIG_H' '-I' '.' '-D' '_GNU_SOURCE' '-v' '-save-temps' '-D' '_GNU_SOURCE' '-g' '-g' '-O2' '-flto=auto' '-v' '-save-temps' '-Wall' '-Wextra' '-Wunused' '-Wstrict-prototypes' '-Wabsolute-value' '-Waddress-of-packed-member' '-Walloca' '-Walloc-zero' '-Warith-conversion' '-Warray-bounds=2' '-Wattribute-alias=2' '-Wbad-function-cast' '-Wc11-c2x-compat' '-Wcast-align' '-Wcast-qual' '-Wdate-time' '-Wdisabled-optimization' '-Wdouble-promotion' '-Wduplicated-branches' '-Wduplicated-cond' '-Wfloat-conversion' '-Wfloat-equal' '-Wformat-overflow=1' '-Wformat-signedness' '-Wformat-truncation=1' '-Wframe-larger-than=5120' '-Wimplicit-fallthrough=3' '-Winit-self' '-Winline' '-Winvalid-pch' '-Wjump-misses-init' '-Wlogical-op'
[Bug tree-optimization/106705] New: Expensive constant load replicated throughout switch statement
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106705
Bug ID: 106705
Summary: Expensive constant load replicated throughout switch
statement
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: macro at orcam dot me.uk
Target Milestone: ---
Given code like:
#define do_sd(a, b, c) do { b[c] = a; } while (0)
void sd(unsigned len, unsigned long *mem)
{
const unsigned long val = 2415920512;
switch (len) {
case 7:
do_sd(val, mem, -7);
case 6:
do_sd(val, mem, -6);
case 5:
do_sd(val, mem, -5);
case 4:
do_sd(val, mem, -4);
case 3:
do_sd(val, mem, -3);
case 2:
do_sd(val, mem, -2);
case 1:
do_sd(val, mem, -1);
}
}
(reduced from code using an out-of-tree intrinsic for a vendor-specific
machine instruction) we get 64-bit assembly at -O2 with a constant load
replicated across all the switch cases, terribly suboptimal.
E.g. for RISC-V this gets compiled to:
.text
.align 1
.globl sd
.type sd, @function
sd:
li a5,7
bgtua0,a5,.L1
lui a5,%hi(.L4)
addia5,a5,%lo(.L4)
sllia0,a0,2
add a0,a0,a5
lw a5,0(a0)
jr a5
.section.rodata
.align 2
.align 2
.L4:
.word .L1
.word .L10
.word .L9
.word .L8
.word .L7
.word .L6
.word .L5
.word .L3
.text
.L3:
li a5,9
sllia5,a5,28
addia5,a5,1408
sd a5,-56(a1)
.L5:
li a5,9
sllia5,a5,28
addia5,a5,1408
sd a5,-48(a1)
.L6:
li a5,9
sllia5,a5,28
addia5,a5,1408
sd a5,-40(a1)
.L7:
li a5,9
sllia5,a5,28
addia5,a5,1408
sd a5,-32(a1)
.L8:
li a5,9
sllia5,a5,28
addia5,a5,1408
sd a5,-24(a1)
.L9:
li a5,9
sllia5,a5,28
addia5,a5,1408
sd a5,-16(a1)
.L10:
li a5,9
sllia5,a5,28
addia5,a5,1408
sd a5,-8(a1)
.L1:
ret
.size sd, .-sd
and similarly e.g. for Alpha:
[...]
$L3:
lda $1,9($31)
sll $1,28,$1
lda $1,1408($1)
stq $1,-56($17)
$L5:
lda $1,9($31)
sll $1,28,$1
lda $1,1408($1)
stq $1,-48($17)
[...]
MIPS:
[...]
.L3:
li $2,18874368 # 0x120
daddiu $2,$2,11
dsll$2,$2,7
sd $2,-56($5)
.L5:
li $2,18874368 # 0x120
daddiu $2,$2,11
dsll$2,$2,7
sd $2,-48($5)
[...]
POWER:
[...]
.L3:
lis 9,0x9000
ori 9,9,0x580
rldicl 9,9,0,32
std 9,-56(4)
.L5:
lis 9,0x9000
ori 9,9,0x580
rldicl 9,9,0,32
std 9,-48(4)
[...]
or x86 even:
[...]
.L3:
movl$2415920512, %eax
movq%rax, -56(%rsi)
.L5:
movl$2415920512, %eax
movq%rax, -48(%rsi)
[...]
I understand this is due forward constant propagation, and it used to
be possible to circumvent it at least at -Os by disabling several of
the tree passess (with GCC 9 this has been originally discovered with),
but apparently not anymore. Not that it would be useful for regular
compilations. In that case good RISC-V code was produced (except for
some needless sign-extensions, etc. coming from -Os inefficiency):
.text
.align 1
.globl sd
.type sd, @function
sd:
addiw a0,a0,-1
sext.w a4,a0
li a5,6
bgtua4,a5,.L1
sllia0,a0,32
lui a5,%hi(.L4)
addia5,a5,%lo(.L4)
srlia0,a0,30
add a0,a0,a5
lw a4,0(a0)
li a5,9
sllia5,a5,28
addia5,a5,1408
jr a4
.section.rodata
.align 2
.align 2
.L4:
.word .L10
.word .L9
.word .L8
.word .L7
.word .L6
.word .L5
.word .L3
.text
.align 2
.L3:
sd a5,-56(a1)
.align 2
.L5:
sd a5,-48(a1)
.align 2
.L6:
sd a5,-40(a1)
.align 2
.L7:
sd a5,-32(a1)
.align 2
.L8:
sd a5,-24(a1)
.align 2
.L9:
sd a5,-16(a1)
.align 2
.L10:
sd a5,-8(a1)
.align 2
.L1:
ret
.size sd, .-sd
[Bug analyzer/106703] during IPA pass: analyzer ICE: error reporting routines re-entered. with -fanalyzer -fsanitize-address-use-after-scope -fsanitize=kernel-address -fdiagnostics-format=sarif-stderr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106703
David Malcolm changed:
What|Removed |Added
Last reconfirmed||2022-08-21
Ever confirmed|0 |1
Status|UNCONFIRMED |NEW
--- Comment #1 from David Malcolm ---
Crash happens here due to filename being NULL:
642 sarif_builder::make_artifact_location_object (const char *filename)
643 {
644 json::object *artifact_loc_obj = new json::object ();
645
646 /* "uri" property (SARIF v2.1.0 section 3.4.3). */
647 artifact_loc_obj->set ("uri", new json::string (filename));
due to:
#4 0x01f26ba5 in sarif_builder::make_artifact_location_object
(this=this@entry=0x2c0c8b0, loc=loc@entry=2147483651) at
../../src/gcc/diagnostic-format-sarif.cc:630
630 return make_artifact_location_object (LOCATION_FILE (loc));
where:
(gdb) p /x loc
$3 = 0x8003
(gdb) p line_table->location_adhoc_data_map.data[3]
$4 = {locus = 0, src_range = {m_start = 0, m_finish = 0}, data =
0x7fffea1ee420}
i.e. UNKNOWN_LOCATION wrapped with inlining information.
[Bug target/106704] [12/13 Regression] avx intrinsic no generating vblendvps instruction with -mavx
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106704 Jakub Jelinek changed: What|Removed |Added Target Milestone|--- |12.3 Status|UNCONFIRMED |NEW Summary|avx intrinsic no generating |[12/13 Regression] avx |vblendvps instruction with |intrinsic no generating |-mavx |vblendvps instruction with ||-mavx CC||jakub at gcc dot gnu.org, ||liuhongt at gcc dot gnu.org Ever confirmed|0 |1 Priority|P3 |P2 Last reconfirmed||2022-08-21 --- Comment #1 from Jakub Jelinek --- Started with r12-1834-g28560c6d4043d8f6ac570f35fb84e952e9c719fe
Re: Ping [PATCH V2] libcpp: Optimize #pragma once with a hash table [PR58770]
On Fri, 2022-08-19 at 13:27 -0700, Paul Hollinsky wrote:
> Hi all,
>
> Would love some feedback on this patch!
>
> Thanks,
> Paul
Hi Paul. Sorry for not getting back to you before. I'm listed as a
libcpp maintainer, but this happens to be a part of libcpp I've not
looked at (I'm mostly just familiar with location_t management).
FWIW, the patch seems sane to me, though I have one concern: does it
work with precompiled headers? (given that PCH is implemented by
taking a snapshot of the gc heap and reconstructing it on load, it thus
tends to be an annoying source of bugs when trying the kind of cleanup
this patch is doing).
Sorry to not look be able to look at things in more detail (I'm
travelling)
Hope this is constructive
Dave
>
> On Mon, Aug 01, 2022 at 05:18:40AM +, Paul Hollinsky wrote:
> > Rather than traversing the all_files linked list for every include,
> > this factors out the quick idempotency checks (modification time
> > and size) to be the keys in a hash table so we can find matching
> > files quickly.
> >
> > The hash table value type is a linked list, in case more than one
> > file matches the quick check.
> >
> > The table is only built if a once-only file is seen, so include
> > guard performance is not affected.
> >
> > My laptop would previously complete Ricardo's benchmark from the
> > PR in ~1.1s using #pragma once, and ~0.35s using include guards.
> >
> > After this change, both benchmarks now complete in ~0.35s. I did
> > have to randomize the modification dates on the benchmark headers
> > so the files did not all end up in the same hash table list, but
> > that would likely not come up outside of the contrived benchmark.
> >
> > I bootstrapped and ran the testsuite on x86_64 Darwin, as well as
> > ppc64le and aarch64 Linux.
> >
> > libcpp/ChangeLog:
> >
> > PR preprocessor/58770
> > * internal.h: Add hash table for #pragma once
> > * files.cc: Optimize #pragma once with the hash table
> >
> > Signed-off-by: Paul Hollinsky
> > ---
> > libcpp/files.cc | 116
> > +++---
> > libcpp/internal.h | 3 ++
> > 2 files changed, 112 insertions(+), 7 deletions(-)
> >
> > diff --git a/libcpp/files.cc b/libcpp/files.cc
> > index 24208f7b0f8..d4ffd77578e 100644
> > --- a/libcpp/files.cc
> > +++ b/libcpp/files.cc
> > @@ -167,6 +167,33 @@ struct file_hash_entry_pool
> > struct cpp_file_hash_entry pool[FILE_HASH_POOL_SIZE];
> > };
> >
> > +/* A set of attributes designed to quickly identify obviously
> > different files
> > + in a hashtable. Just in case there are collisions, we still
> > maintain a
> > + list. These sub-lists can then be checked for #pragma once
> > rather than
> > + interating through all_files. */
> > +struct file_quick_idempotency_attrs
> > +{
> > + file_quick_idempotency_attrs(const _cpp_file *f)
> > + : mtime(f->st.st_mtime), size(f->st.st_size) {}
> > +
> > + time_t mtime;
> > + off_t size;
> > +
> > + static hashval_t hash (/* _cpp_file* */ const void *p);
> > +};
> > +
> > +/* Sub-list of very similar files kept in a hashtable to check for
> > #pragma
> > + once. */
> > +struct file_sublist
> > +{
> > + _cpp_file *f;
> > + file_sublist *next;
> > +
> > + static int eq (/* _cpp_file* */ const void *p,
> > + /* file_sublist* */ const void *q);
> > + static void del (/* file_sublist* */ void *p);
> > +};
> > +
> > static bool open_file (_cpp_file *file);
> > static bool pch_open_file (cpp_reader *pfile, _cpp_file *file,
> > bool *invalid_pch);
> > @@ -849,17 +876,17 @@ has_unique_contents (cpp_reader *pfile,
> > _cpp_file *file, bool import,
> > if (!pfile->seen_once_only)
> > return true;
> >
> > - /* We may have read the file under a different name. Look
> > - for likely candidates and compare file contents to be sure.
> > */
> > - for (_cpp_file *f = pfile->all_files; f; f = f->next_file)
> > + /* We may have read the file under a different name. We've kept
> > + similar looking files in this lists under this hash table, so
> > + check those more thoroughly. */
> > + void* ent = htab_find(pfile->pragma_once_files, file);
> > + for (file_sublist *e = static_cast (ent); e; e =
> > e->next)
> > {
> > + _cpp_file *f = e->f;
> > if (f == file)
> > continue; /* It'sa me! */
> >
> > - if ((import || f->once_only)
> > - && f->err_no == 0
> > - && f->st.st_mtime == file->st.st_mtime
> > - && f->st.st_size == file->st.st_size)
> > + if ((import || f->once_only) && f->err_no == 0)
> > {
> > _cpp_file *ref_file;
> >
> > @@ -895,6 +922,38 @@ has_unique_contents (cpp_reader *pfile,
> > _cpp_file *file, bool import,
> > return true;
> > }
> >
> > +/* Add the given file to the #pragma once table so it can be
> > + quickly identified and excluded the next time it's seen. */
> > +static void
> >
[Bug c/106704] New: avx intrinsic no generating vblendvps instruction with -mavx
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106704
Bug ID: 106704
Summary: avx intrinsic no generating vblendvps instruction with
-mavx
Product: gcc
Version: 12.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: mindmark at gmail dot com
Target Milestone: ---
I'm getting some really strange code generation on x86_64 when using the
_mm256_blendv_ps intrinsic in gcc 12 with just the -mavx flag.
https://godbolt.org/z/YbEK4nvEd
It should generate a single vblendvps instruction, but instead creates a lot of
branchy scaler code.
gcc 11 doesn't appear to exhibit this behavior.
Also using -mavx2 on gcc 12 generates the single instruction, just not -mavx
for whatever reason.
#include
__m256 bend_stuff( __m256 a, __m256 b, __m256 mask)
{
return _mm256_blendv_ps(a, b, mask);
}
gcc -O2 -mavx -c blend.c -masm=intel -S -o out.s
in GCC 12 it generates:
bend_stuff:
vmovd eax, xmm2
vmovaps ymm3, ymm0
vmovdqa xmm4, xmm2
testeax, eax
jns .L3
vmovaps xmm0, xmm1
.L3:
vpextrd eax, xmm4, 1
vshufps xmm9, xmm3, xmm3, 85
testeax, eax
jns .L5
vshufps xmm9, xmm1, xmm1, 85
.L5:
vpextrd eax, xmm4, 2
vunpckhps xmm5, xmm3, xmm3
testeax, eax
jns .L7
vunpckhps xmm5, xmm1, xmm1
.L7:
vpextrd eax, xmm4, 3
vshufps xmm7, xmm3, xmm3, 255
testeax, eax
jns .L9
vshufps xmm7, xmm1, xmm1, 255
.L9:
vextractf128xmm2, ymm2, 0x1
vextractf128xmm4, ymm3, 0x1
vmovd eax, xmm2
testeax, eax
jns .L11
vextractf128xmm4, ymm1, 0x1
.L11:
vextractf128xmm8, ymm3, 0x1
vpextrd eax, xmm2, 1
vshufps xmm8, xmm8, xmm8, 85
testeax, eax
jns .L13
vextractf128xmm8, ymm1, 0x1
vshufps xmm8, xmm8, xmm8, 85
.L13:
vextractf128xmm6, ymm3, 0x1
vpextrd eax, xmm2, 2
vunpckhps xmm6, xmm6, xmm6
testeax, eax
jns .L15
vextractf128xmm6, ymm1, 0x1
vunpckhps xmm6, xmm6, xmm6
.L15:
vextractf128xmm3, ymm3, 0x1
vpextrd eax, xmm2, 3
vshufps xmm3, xmm3, xmm3, 255
testeax, eax
jns .L17
vextractf128xmm1, ymm1, 0x1
vshufps xmm3, xmm1, xmm1, 255
.L17:
vunpcklps xmm6, xmm6, xmm3
vunpcklps xmm4, xmm4, xmm8
vunpcklps xmm5, xmm5, xmm7
vunpcklps xmm0, xmm0, xmm9
vmovlhpsxmm4, xmm4, xmm6
vmovlhpsxmm0, xmm0, xmm5
vinsertf128 ymm0, ymm0, xmm4, 0x1
ret
in GCC 11.3 it generates:
bend_stuff:
vblendvps ymm0, ymm0, ymm1, ymm2
ret
[Bug c/106702] [11 Regression] ICE with LTO: internal compiler error: tree code ‘c_maybe_const_expr’ is not supported in LTO streams
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106702 Andrew Pinski changed: What|Removed |Added Ever confirmed|0 |1 Last reconfirmed||2022-08-21 Status|UNCONFIRMED |NEW --- Comment #1 from Andrew Pinski --- Confirmed. a Regression from GCC 10.
[Bug c/106702] [11 Regression] ICE with LTO: internal compiler error: tree code ‘c_maybe_const_expr’ is not supported in LTO streams
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106702 Andrew Pinski changed: What|Removed |Added Keywords||needs-bisection Target Milestone|--- |11.4 Known to work||12.1.0 Summary|ICE with LTO: internal |[11 Regression] ICE with |compiler error: tree code |LTO: internal compiler |‘c_maybe_const_expr’ is not |error: tree code |supported in LTO streams|‘c_maybe_const_expr’ is not ||supported in LTO streams Known to fail||11.1.0, 11.3.0
[Bug target/90088] 3 ops LEA should be avoided on Intel CPUs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90088 dingd changed: What|Removed |Added CC||ntysdd at qq dot com --- Comment #7 from dingd --- Hi, I just encouter the same "problem". (Actually am surprised by clang "missing" this simple optimization) As of 2022, gcc and clang still choose to emit different instructions. Are there any conclusions?
[Bug analyzer/106703] New: during IPA pass: analyzer ICE: error reporting routines re-entered. with -fanalyzer -fsanitize-address-use-after-scope -fsanitize=kernel-address -fdiagnostics-format=sarif-s
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106703 Bug ID: 106703 Summary: during IPA pass: analyzer ICE: error reporting routines re-entered. with -fanalyzer -fsanitize-address-use-after-scope -fsanitize=kernel-address -fdiagnostics-format=sarif-stderr --param=asan-stack=1 Product: gcc Version: 13.0 Status: UNCONFIRMED Keywords: ice-on-valid-code Severity: normal Priority: P3 Component: analyzer Assignee: dmalcolm at gcc dot gnu.org Reporter: zsojka at seznam dot cz Target Milestone: --- Host: x86_64-pc-linux-gnu Created attachment 53485 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53485=edit reduced testcase Compiler output: $ x86_64-pc-linux-gnu-gcc -fanalyzer -fsanitize-address-use-after-scope -fsanitize=kernel-address -fdiagnostics-format=sarif-stderr --param=asan-stack=1 testcase.c during IPA pass: analyzer internal compiler error: error reporting routines re-entered. 0xd28147 json::string::string(char const*) /repo/gcc-trunk/gcc/json.cc:191 0xd28147 json::string::string(char const*) /repo/gcc-trunk/gcc/json.cc:189 0x2614c7b sarif_builder::make_artifact_location_object(char const*) /repo/gcc-trunk/gcc/diagnostic-format-sarif.cc:647 0x26167a9 sarif_builder::make_artifact_location_object(unsigned int) /repo/gcc-trunk/gcc/diagnostic-format-sarif.cc:630 0x26167a9 sarif_builder::maybe_make_physical_location_object(unsigned int) /repo/gcc-trunk/gcc/diagnostic-format-sarif.cc:604 0x26168df sarif_builder::make_location_object(rich_location const&, logical_location const*) /repo/gcc-trunk/gcc/diagnostic-format-sarif.cc:557 0x2617c23 sarif_builder::make_result_object(diagnostic_context*, diagnostic_info*, diagnostic_t) /repo/gcc-trunk/gcc/diagnostic-format-sarif.cc:397 0x26180bd sarif_builder::end_diagnostic(diagnostic_context*, diagnostic_info*, diagnostic_t) /repo/gcc-trunk/gcc/diagnostic-format-sarif.cc:248 0x26180bd sarif_builder::end_diagnostic(diagnostic_context*, diagnostic_info*, diagnostic_t) /repo/gcc-trunk/gcc/diagnostic-format-sarif.cc:233 0x26180bd sarif_end_diagnostic /repo/gcc-trunk/gcc/diagnostic-format-sarif.cc:1479 0x260e245 diagnostic_report_diagnostic(diagnostic_context*, diagnostic_info*) /repo/gcc-trunk/gcc/diagnostic.cc:1557 0x260e987 diagnostic_impl /repo/gcc-trunk/gcc/diagnostic.cc:1712 0x260f657 internal_error(char const*, ...) /repo/gcc-trunk/gcc/diagnostic.cc:2112 0xd2720d fancy_abort(char const*, int, char const*) /repo/gcc-trunk/gcc/diagnostic.cc:2211 0xd28147 json::string::string(char const*) /repo/gcc-trunk/gcc/json.cc:191 0xd28147 json::string::string(char const*) /repo/gcc-trunk/gcc/json.cc:189 0x2614c7b sarif_builder::make_artifact_location_object(char const*) /repo/gcc-trunk/gcc/diagnostic-format-sarif.cc:647 0x26167a9 sarif_builder::make_artifact_location_object(unsigned int) /repo/gcc-trunk/gcc/diagnostic-format-sarif.cc:630 0x26167a9 sarif_builder::maybe_make_physical_location_object(unsigned int) /repo/gcc-trunk/gcc/diagnostic-format-sarif.cc:604 0x2616ab7 sarif_builder::make_location_object(diagnostic_event const&) /repo/gcc-trunk/gcc/diagnostic-format-sarif.cc:576 Please submit a full bug report, with preprocessed source (by using -freport-bug). Please include the complete backtrace with any bug report. See <https://gcc.gnu.org/bugs/> for instructions. $ x86_64-pc-linux-gnu-gcc -v Using built-in specs. COLLECT_GCC=/repo/gcc-trunk/binary-latest-amd64/bin/x86_64-pc-linux-gnu-gcc COLLECT_LTO_WRAPPER=/repo/gcc-trunk/binary-trunk-r13-2130-20220821001633-gd6a39c25c05-checking-yes-rtl-df-extra-nobootstrap-amd64/bin/../libexec/gcc/x86_64-pc-linux-gnu/13.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-r13-2130-20220821001633-gd6a39c25c05-checking-yes-rtl-df-extra-nobootstrap-amd64 Thread model: posix Supported LTO compression algorithms: zlib zstd gcc version 13.0.0 20220821 (experimental) (GCC)
[Bug lto/106702] New: ICE with LTO: internal compiler error: tree code ‘c_maybe_const_expr’ is not supported in LTO streams
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106702
Bug ID: 106702
Summary: ICE with LTO: internal compiler error: tree code
‘c_maybe_const_expr’ is not supported in LTO streams
Product: gcc
Version: 11.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: lto
Assignee: unassigned at gcc dot gnu.org
Reporter: muecker at gwdg dot de
CC: marxin at gcc dot gnu.org
Target Milestone: ---
I get this with 11.3.0 but not with 12.
https://godbolt.org/z/6Esa3jhh9
$ gcc-11 --version
gcc-11 (Debian 11.3.0-5) 11.3.0
Copyright (C) 2021 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
$ cat test.c
extern void bar(int M, int N, float S[(N > M) ? M : N]);
void foo(int M, int N)
{
bar(M, N, 0);
}
$ gcc-11 -I ../src/ -flto test.c
during IPA pass: modref
test.c:8:1: internal compiler error: tree code ‘c_maybe_const_expr’ is not
supported in LTO streams
8 | }
| ^
0x7fa316e01209 __libc_start_call_main
../sysdeps/nptl/libc_start_call_main.h:58
0x7fa316e012bb __libc_start_main_impl
../csu/libc-start.c:389
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See for instructions.
[Bug target/106701] New: s390: Compiler does not take into account number range limitation to avoid subtract from immediate
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106701
Bug ID: 106701
Summary: s390: Compiler does not take into account number range
limitation to avoid subtract from immediate
Product: gcc
Version: 11.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: jens.seifert at de dot ibm.com
Target Milestone: ---
unsigned long long subfic(unsigned long long a)
{
if (a > 15) __builtin_unreachable();
return 15 - a;
}
With clang on x86 subtract from immediate gets translated to xor:
_Z6subficy: # @_Z6subficy
mov rax, rdi
xor rax, 15
ret
Platforms like 390 and x86 which have no subtract from immediate would benefit
from this optimization:
gcc currently generates:
_Z6subficy:
lghi%r1,15
sgr %r1,%r2
lgr %r2,%r1
br %r14
