[Bug target/111755] The built-in memset function in GCC inadvertently generates code like "vst1.8 {d8-d9}, [sp:64]", which assumes an 8-byte alignment on the stack pointer $sp, leading to alignment vi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111755 --- Comment #2 from Andrew Pinski --- Also can you attach the testcase where this happens? Please read https://gcc.gnu.org/bugs/ on what information we need.
[Bug target/111755] The built-in memset function in GCC inadvertently generates code like "vst1.8 {d8-d9}, [sp:64]", which assumes an 8-byte alignment on the stack pointer $sp, leading to alignment vi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111755 Andrew Pinski changed: What|Removed |Added Last reconfirmed||2023-10-10 Ever confirmed|0 |1 Status|UNCONFIRMED |WAITING --- Comment #1 from Andrew Pinski --- > which assumes an 8-byte alignment on the stack pointer $sp, leading to > alignment violations. Isn't that the ABI? What target is this for?
[Bug c/111755] New: The built-in memset function in GCC inadvertently generates code like "vst1.8 {d8-d9}, [sp:64]", which assumes an 8-byte alignment on the stack pointer $sp, leading to alignment vi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111755
Bug ID: 111755
Summary: The built-in memset function in GCC inadvertently
generates code like "vst1.8 {d8-d9}, [sp:64]", which
assumes an 8-byte alignment on the stack pointer $sp,
leading to alignment violations
Product: gcc
Version: 9.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: kuzume at axell dot co.jp
Target Milestone: ---
The built-in memset function in GCC inadvertently generates code like
"vst1.8 {d8-d9}, [sp:64]"
which assumes an 8-byte alignment on the stack pointer $sp, leading to
alignment violations.
While the issue can be temporarily circumvented using the -fno-builtin-memset
option to inhibit the use of the built-in functions, the stack pointer $sp is
4-byte aligned during C function calls. This might be a bug related to GCC's
built-in function handling.
By the way, the problem can also be resolved by generating assembly listings
without alignment specification, like "vst1.8 {d8-d9}, [sp]". Although, from an
alignment perspective, this is not the optimal performance solution.
[Bug rtl-optimization/111754] New: [14 Regression] ICE: in decompose, at rtl.h:2313 at -O
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111754
Bug ID: 111754
Summary: [14 Regression] ICE: in decompose, at rtl.h:2313 at -O
Product: gcc
Version: 14.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
Target: x86_64-pc-linux-gnu
Created attachment 56088
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56088=edit
reduced testcase
Compiler output:
$ x86_64-pc-linux-gnu-gcc -O testcase.c
during RTL pass: expand
testcase.c: In function 'foo':
testcase.c:14:10: internal compiler error: in decompose, at rtl.h:2313
14 | return bar ((F){9}, (F){});
| ^~~
0x7ea1ba wi::int_traits >::decompose(long*,
unsigned int, std::pair const&)
/repo/gcc-trunk/gcc/rtl.h:2313
0x7ea1ba wide_int_ref_storage::wide_int_ref_storage
>(std::pair const&)
/repo/gcc-trunk/gcc/wide-int.h:1030
0x7ea1ba generic_wide_int
>::generic_wide_int >(std::pair const&)
/repo/gcc-trunk/gcc/wide-int.h:788
0x7ea1ba poly_int<1u, generic_wide_int >
>::poly_int >(poly_int_full,
std::pair const&)
/repo/gcc-trunk/gcc/poly-int.h:453
0x7ea1ba poly_int<1u, generic_wide_int >
>::poly_int >(std::pair const&)
/repo/gcc-trunk/gcc/poly-int.h:439
0x7ea1ba wi::to_poly_wide(rtx_def const*, machine_mode)
/repo/gcc-trunk/gcc/rtl.h:2382
0x7ea1ba rtx_vector_builder::step(rtx_def*, rtx_def*) const
/repo/gcc-trunk/gcc/rtx-vector-builder.h:122
0x143d95b vector_builder::elt(unsigned int) const
/repo/gcc-trunk/gcc/vector-builder.h:254
0x143d841 rtx_vector_builder::build()
/repo/gcc-trunk/gcc/rtx-vector-builder.cc:73
0x107c7a1 const_vector_from_tree
/repo/gcc-trunk/gcc/expr.cc:13494
0x10856ce expand_expr_real_1(tree_node*, rtx_def*, machine_mode,
expand_modifier, rtx_def**, bool)
/repo/gcc-trunk/gcc/expr.cc:11066
0xf50792 expand_expr(tree_node*, rtx_def*, machine_mode, expand_modifier)
/repo/gcc-trunk/gcc/expr.h:310
0xf50792 expand_return
/repo/gcc-trunk/gcc/cfgexpand.cc:3809
0xf50792 expand_gimple_stmt_1
/repo/gcc-trunk/gcc/cfgexpand.cc:3918
0xf50792 expand_gimple_stmt
/repo/gcc-trunk/gcc/cfgexpand.cc:4044
0xf51106 expand_gimple_basic_block
/repo/gcc-trunk/gcc/cfgexpand.cc:6100
0xf5378e execute
/repo/gcc-trunk/gcc/cfgexpand.cc:6835
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.
$ x86_64-pc-linux-gnu-gcc -v
Using built-in specs.
COLLECT_GCC=/repo/gcc-trunk/binary-latest-amd64/bin/x86_64-pc-linux-gnu-gcc
COLLECT_LTO_WRAPPER=/repo/gcc-trunk/binary-trunk-r14-4521-20231009151152-g08d0f840dc7-checking-yes-rtl-df-extra-amd64/bin/../libexec/gcc/x86_64-pc-linux-gnu/14.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /repo/gcc-trunk//configure --enable-languages=c,c++
--enable-valgrind-annotations --disable-nls --enable-checking=yes,rtl,df,extra
--with-cloog --with-ppl --with-isl --build=x86_64-pc-linux-gnu
--host=x86_64-pc-linux-gnu --target=x86_64-pc-linux-gnu
--with-ld=/usr/bin/x86_64-pc-linux-gnu-ld
--with-as=/usr/bin/x86_64-pc-linux-gnu-as --disable-libstdcxx-pch
--prefix=/repo/gcc-trunk//binary-trunk-r14-4521-20231009151152-g08d0f840dc7-checking-yes-rtl-df-extra-amd64
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 14.0.0 20231009 (experimental) (GCC)
[Bug rtl-optimization/111753] New: [14 Regression] ICE: in extract_constrain_insn, at recog.cc:2692 insn does not satisfy its constraints: {*movsf_internal} with -O2 -mavx512bw -fno-tree-ter
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111753
Bug ID: 111753
Summary: [14 Regression] ICE: in extract_constrain_insn, at
recog.cc:2692 insn does not satisfy its constraints:
{*movsf_internal} with -O2 -mavx512bw -fno-tree-ter
Product: gcc
Version: 14.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
Target: x86_64-pc-linux-gnu
Created attachment 56087
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56087=edit
reduced testcase
Compiler output:
$ x86_64-pc-linux-gnu-gcc -O2 -mavx512bw -fno-tree-ter testcase.c
testcase.c: In function 'foo':
testcase.c:35:9: warning: division by zero [-Wdiv-by-zero]
35 | f32_0 /= 0;
| ^~
testcase.c:38:13: warning: division by zero [-Wdiv-by-zero]
38 | v256f32_0 /= 0;
| ^~
testcase.c:66:1: error: insn does not satisfy its constraints:
66 | }
| ^
(insn 713 222 227 2 (set (reg:SF 52 xmm16 [473])
(const_double:SF 0.0 [0x0.0p+0])) "testcase.c":45:13 160
{*movsf_internal}
(expr_list:REG_EQUAL (const_double:SF 0.0 [0x0.0p+0])
(nil)))
during RTL pass: cprop_hardreg
testcase.c:66:1: internal compiler error: in extract_constrain_insn, at
recog.cc:2692
0x7e2e60 _fatal_insn(char const*, rtx_def const*, char const*, int, char
const*)
/repo/gcc-trunk/gcc/rtl-error.cc:108
0x7e2ee7 _fatal_insn_not_found(rtx_def const*, char const*, int, char const*)
/repo/gcc-trunk/gcc/rtl-error.cc:118
0x7d359b extract_constrain_insn(rtx_insn*)
/repo/gcc-trunk/gcc/recog.cc:2692
0x13fdd85 copyprop_hardreg_forward_1
/repo/gcc-trunk/gcc/regcprop.cc:836
0x13ff199 execute
/repo/gcc-trunk/gcc/regcprop.cc:1423
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.
$ x86_64-pc-linux-gnu-gcc -v
Using built-in specs.
COLLECT_GCC=/repo/gcc-trunk/binary-latest-amd64/bin/x86_64-pc-linux-gnu-gcc
COLLECT_LTO_WRAPPER=/repo/gcc-trunk/binary-trunk-r14-4521-20231009151152-g08d0f840dc7-checking-yes-rtl-df-extra-amd64/bin/../libexec/gcc/x86_64-pc-linux-gnu/14.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /repo/gcc-trunk//configure --enable-languages=c,c++
--enable-valgrind-annotations --disable-nls --enable-checking=yes,rtl,df,extra
--with-cloog --with-ppl --with-isl --build=x86_64-pc-linux-gnu
--host=x86_64-pc-linux-gnu --target=x86_64-pc-linux-gnu
--with-ld=/usr/bin/x86_64-pc-linux-gnu-ld
--with-as=/usr/bin/x86_64-pc-linux-gnu-as --disable-libstdcxx-pch
--prefix=/repo/gcc-trunk//binary-trunk-r14-4521-20231009151152-g08d0f840dc7-checking-yes-rtl-df-extra-amd64
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 14.0.0 20231009 (experimental) (GCC)
[Bug middle-end/111752] New: -Wfree-nonheap-object (vec.h:347:10: warning: 'free' called on unallocated object 'dest_bbs') during bootstrap with LTO
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111752 Bug ID: 111752 Summary: -Wfree-nonheap-object (vec.h:347:10: warning: 'free' called on unallocated object 'dest_bbs') during bootstrap with LTO Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end Assignee: unassigned at gcc dot gnu.org Reporter: sjames at gcc dot gnu.org Target Milestone: --- I'm not sure this was always there - I think I would've noticed if it was a long-standing thing. I get this -Wfree-nonheap-object warning during bootstrap. I can reproduce it with: ``` ./configure --disable-analyzer --disable-bootstrap --disable-cet --disable-default-pie --disable-default-ssp --disable-fixincludes --disable-gcov --disable-libada --disable-libatomic --disable-libgomp --disable-libitm --disable-libquadmath --disable-libsanitizer --disable-libssp --disable-libstdcxx-pch --disable-libvtv --disable-lto --disable-multilib --disable-nls --disable-objc-gc --disable-systemtap --disable-werror --enable-languages=c,c++ --prefix=/tmp/bisect --without-isl --without-zstd --with-system-zlib --enable-bootstrap --enable-lto make BUILD_CONFIG=bootstrap-lto -j$(nproc) ``` I can only reproduce when building with bootstrap-lto. On trunk at r14-4523-gfb124f2a23e92b, I get this: ``` /home/sam/git/gcc/host-x86_64-pc-linux-gnu/prev-gcc/xg++ -B/home/sam/git/gcc/host-x86_64-pc-linux-gnu/prev-gcc/ -B/tmp/bisect/x86_64-pc-linux-gnu/bin/ -nostdinc++ -B/home/sam/git/gcc/prev-x86_64-pc-linux-gnu/ libstdc++-v3/src/.libs -B/home/sam/git/gcc/prev-x86_64-pc-linux-gnu/libstdc++-v3/libsupc++/.libs -I/home/sam/git/gcc/prev-x86_64-pc-linux-gnu/libstdc++-v3/include/x86_64-pc-linux-gnu -I/home/sam/git/gcc/pre v-x86_64-pc-linux-gnu/libstdc++-v3/include -I/home/sam/git/gcc/libstdc++-v3/libsupc++ -L/home/sam/git/gcc/prev-x86_64-pc-linux-gnu/libstdc++-v3/src/.libs -L/home/sam/git/gcc/prev-x86_64-pc-linux-gnu/libstdc+ +-v3/libsupc++/.libs -no-pie -g -O2 -fno-checking -flto=jobserver -frandom-seed=1 -DIN_GCC-fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wmis sing-format-attribute -Wconditionally-supported -Woverloaded-virtual -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -fno-common -DHAVE_CONFIG_H -no-pie -static-libstdc++ -static-libgcc -o cc1plus \ cp/cp-lang.o c-family/stub-objc.o cp/call.o cp/class.o cp/constexpr.o cp/constraint.o cp/coroutines.o cp/cp-gimplify.o cp/cp-objcp-common.o cp/cp-ubsan.o cp/cvt.o cp/contracts.o cp/cxx-pretty-print.o cp /decl.o cp/decl2.o cp/dump.o cp/error.o cp/except.o cp/expr.o cp/friend.o cp/init.o cp/lambda.o cp/lex.o cp/logic.o cp/mangle.o cp/mapper-client.o cp/mapper-resolver.o cp/method.o cp/module.o cp/name-lookup.o cp/optimize.o cp/parser.o cp/pt.o cp/ptree.o cp/rtti.o cp/search.o cp/semantics.o cp/tree.o cp/typeck.o cp/typeck2.o cp/vtable-class-hierarchy.o attribs.o c-family/c-common.o c-family/c-cppbuiltin.o c-family /c-dump.o c-family/c-format.o c-family/c-gimplify.o c-family/c-indentation.o c-family/c-lex.o c-family/c-omp.o c-family/c-opts.o c-family/c-pch.o c-family/c-ppoutput.o c-family/c-pragma.o c-family/c-pretty-pr int.o c-family/c-semantics.o c-family/c-ada-spec.o c-family/c-ubsan.o c-family/known-headers.o c-family/c-attribs.o c-family/c-warn.o c-family/c-spellcheck.o i386-c.o glibc-c.o cc1plus-checksum.o libbackend.a main.o libcommon-target.a libcommon.a ../libcpp/libcpp.a ../libdecnumber/libdecnumber.a ../libcody/libcody.a \ libcommon.a ../libcpp/libcpp.a ../libbacktrace/.libs/libbacktrace.a ../libiberty/libiberty.a ../libdecnumber/libdecnumber.a -lmpc -lmpfr -lgmp -rdynamic -lz ../.././gcc/spellcheck.cc: In function '_Z17get_edit_distancePKciS0_i.part.0': ../.././gcc/spellcheck.cc:71:61: warning: argument 1 value '18446744073709551615' exceeds maximum object size 9223372036854775807 [-Walloc-size-larger-than=] 71 | edit_distance_t *v_two_ago = new edit_distance_t[len_s + 1]; | ^ /home/sam/git/gcc/libstdc++-v3/libsupc++/new:133:26: note: in a call to allocation function 'operator new []' declared here 133 | _GLIBCXX_NODISCARD void* operator new[](std::size_t) _GLIBCXX_THROW (std::bad_alloc) | ^ ../.././gcc/spellcheck.cc:72:61: warning: argument 1 value '18446744073709551615' exceeds maximum object size 9223372036854775807 [-Walloc-size-larger-than=] 72 | edit_distance_t *v_one_ago = new edit_distance_t[len_s + 1]; | ^ /home/sam/git/gcc/libstdc++-v3/libsupc++/new:133:26: note: in a call to allocation function 'operator new []' declared here 133 | _GLIBCXX_NODISCARD void* operator new[](std::size_t) _GLIBCXX_THROW (std::bad_alloc) |
[Bug tree-optimization/111751] RISC-V: RVV unexpected vectorization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111751
--- Comment #7 from JuzheZhong ---
(In reply to Andrew Pinski from comment #6)
> (In reply to JuzheZhong from comment #5)
> > (In reply to Andrew Pinski from comment #4)
> > > The issue for aarch64 with SVE is that MASK_LOAD is not optimized:
> > >
> > > ic = "\x00\x03\x06\t\f\x0f\x12\x15\x18\x1b\x1e!$\'*-";
> > > ib = "\x00\x03\x06\t\f\x0f\x12\x15\x18\x1b\x1e!$\'*-";
> > > vect__1.7_9 = .MASK_LOAD (, 8B, { -1, -1, -1, -1, -1, -1, -1, -1, -1,
> > > -1, -1, -1, -1, -1, -1, -1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
> > > 0,
> > > ... });
> > > vect__2.10_35 = .MASK_LOAD (, 8B, { -1, -1, -1, -1, -1, -1, -1, -1,
> > > -1,
> > > -1, -1, -1, -1, -1, -1, -1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
> > > 0,
> > > ... });
> >
> > I don't ARM SVE has issues ...
>
> It does as I mentioned if you use -fno-vect-cost-model, you get the above
> issue which should be optimized really to a constant vector ...
After investigation:
I found it failed to recognize its CONST_VECTOR value in FRE
/* Visit a load from a reference operator RHS, part of STMT, value number it,
and return true if the value number of the LHS has changed as a result. */
static bool
visit_reference_op_load (tree lhs, tree op, gimple *stmt)
{
bool changed = false;
tree result;
vn_reference_t res;
tree vuse = gimple_vuse (stmt);
tree last_vuse = vuse;
result = vn_reference_lookup (op, vuse, default_vn_walk_kind, , true,
_vuse);
/* We handle type-punning through unions by value-numbering based
on offset and size of the access. Be prepared to handle a
type-mismatch here via creating a VIEW_CONVERT_EXPR. */
if (result
&& !useless_type_conversion_p (TREE_TYPE (result), TREE_TYPE (op)))
{
/* Avoid the type punning in case the result mode has padding where
the op we lookup has not. */
if (maybe_lt (GET_MODE_PRECISION (TYPE_MODE (TREE_TYPE (result))),
GET_MODE_PRECISION (TYPE_MODE (TREE_TYPE (op)
result = NULL_TREE;
The result is BLKmode, op is V16QImode
Then reach
/* Avoid the type punning in case the result mode has padding where
the op we lookup has not. */
if (maybe_lt (GET_MODE_PRECISION (TYPE_MODE (TREE_TYPE (result))),
GET_MODE_PRECISION (TYPE_MODE (TREE_TYPE (op)
result = NULL_TREE;
If I delete this code, RVV can optimize it.
Do you have any suggestion ?
This is my observation:
Breakpoint 6, visit_reference_op_load (lhs=0x768364c8, op=0x76874410,
stmt=0x76872640) at ../../../../gcc/gcc/tree-ssa-sccvn.cc:5740
5740 result = vn_reference_lookup (op, vuse, default_vn_walk_kind, ,
true, _vuse);
(gdb) c
Continuing.
Breakpoint 6, visit_reference_op_load (lhs=0x768364c8, op=0x76874410,
stmt=0x76872640) at ../../../../gcc/gcc/tree-ssa-sccvn.cc:5740
5740 result = vn_reference_lookup (op, vuse, default_vn_walk_kind, ,
true, _vuse);
(gdb) n
5746 && !useless_type_conversion_p (TREE_TYPE (result), TREE_TYPE
(op)))
(gdb) p debug (result)
"\x00\x03\x06\t\f\x0f\x12\x15\x18\x1b\x1e!$\'*-"
$9 = void
(gdb) p op->typed.type->type_common.mode
$10 = E_V16QImode
[Bug tree-optimization/111751] RISC-V: RVV unexpected vectorization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111751
--- Comment #6 from Andrew Pinski ---
(In reply to JuzheZhong from comment #5)
> (In reply to Andrew Pinski from comment #4)
> > The issue for aarch64 with SVE is that MASK_LOAD is not optimized:
> >
> > ic = "\x00\x03\x06\t\f\x0f\x12\x15\x18\x1b\x1e!$\'*-";
> > ib = "\x00\x03\x06\t\f\x0f\x12\x15\x18\x1b\x1e!$\'*-";
> > vect__1.7_9 = .MASK_LOAD (, 8B, { -1, -1, -1, -1, -1, -1, -1, -1, -1,
> > -1, -1, -1, -1, -1, -1, -1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
> > ... });
> > vect__2.10_35 = .MASK_LOAD (, 8B, { -1, -1, -1, -1, -1, -1, -1, -1, -1,
> > -1, -1, -1, -1, -1, -1, -1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
> > ... });
>
> I don't ARM SVE has issues ...
It does as I mentioned if you use -fno-vect-cost-model, you get the above issue
which should be optimized really to a constant vector ...
[Bug tree-optimization/111751] RISC-V: RVV unexpected vectorization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111751
--- Comment #5 from JuzheZhong ---
(In reply to Andrew Pinski from comment #4)
> The issue for aarch64 with SVE is that MASK_LOAD is not optimized:
>
> ic = "\x00\x03\x06\t\f\x0f\x12\x15\x18\x1b\x1e!$\'*-";
> ib = "\x00\x03\x06\t\f\x0f\x12\x15\x18\x1b\x1e!$\'*-";
> vect__1.7_9 = .MASK_LOAD (, 8B, { -1, -1, -1, -1, -1, -1, -1, -1, -1,
> -1, -1, -1, -1, -1, -1, -1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
> ... });
> vect__2.10_35 = .MASK_LOAD (, 8B, { -1, -1, -1, -1, -1, -1, -1, -1, -1,
> -1, -1, -1, -1, -1, -1, -1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
> ... });
I don't ARM SVE has issues ...
If we can choose fixed length vector mode to vectorize it, it will be well
optimized.
I think this is RISC-V target dependent issue.
[Bug tree-optimization/111751] RISC-V: RVV unexpected vectorization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111751
--- Comment #4 from Andrew Pinski ---
The issue for aarch64 with SVE is that MASK_LOAD is not optimized:
ic = "\x00\x03\x06\t\f\x0f\x12\x15\x18\x1b\x1e!$\'*-";
ib = "\x00\x03\x06\t\f\x0f\x12\x15\x18\x1b\x1e!$\'*-";
vect__1.7_9 = .MASK_LOAD (, 8B, { -1, -1, -1, -1, -1, -1, -1, -1, -1, -1,
-1, -1, -1, -1, -1, -1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, ... });
vect__2.10_35 = .MASK_LOAD (, 8B, { -1, -1, -1, -1, -1, -1, -1, -1, -1,
-1, -1, -1, -1, -1, -1, -1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, ...
});
[Bug tree-optimization/111751] RISC-V: RVV unexpected vectorization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111751 --- Comment #3 from Andrew Pinski --- If you add `-fno-vect-cost-model` to aarch64 compiling, then it uses SVE and does not optimize to just `return 0`.
[Bug tree-optimization/111751] RISC-V: RVV unexpected vectorization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111751 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2023-10-10 Ever confirmed|0 |1 --- Comment #2 from Andrew Pinski --- Confirmed.
[Bug tree-optimization/111751] RISC-V: RVV unexpected vectorization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111751 --- Comment #1 from Andrew Pinski --- AARCH64 did vectorize the code just using non-SVE which then allowed to be optimized too.
[Bug c/111751] New: RISC-V: RVV unexpected vectorization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111751
Bug ID: 111751
Summary: RISC-V: RVV unexpected vectorization
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: juzhe.zhong at rivai dot ai
Target Milestone: ---
#include
#define N 16
int main ()
{
int i;
char ia[N];
char ic[N] = {0,3,6,9,12,15,18,21,24,27,30,33,36,39,42,45};
char ib[N] = {0,3,6,9,12,15,18,21,24,27,30,33,36,39,42,45};
/* Not vectorizable, multiplication */
for (i = 0; i < N; i++)
{
ia[i] = ib[i] * ic[i];
}
/* check results: */
for (i = 0; i < N; i++)
{
if (ia[i] != (char) (ib[i] * ic[i]))
abort ();
}
return 0;
}
RVV GCC ASM:
main:
lui a5,%hi(.LANCHOR0)
addia5,a5,%lo(.LANCHOR0)
addisp,sp,-48
ld a4,0(a5)
ld a5,8(a5)
sd a5,8(sp)
sd a5,24(sp)
sd ra,40(sp)
addia5,sp,16
sd a4,0(sp)
sd a4,16(sp)
vsetivlizero,16,e8,m1,ta,ma
vle8.v v1,0(a5)
vle8.v v2,0(sp)
vmul.vv v1,v1,v2
vmv.x.s a5,v1
andia5,a5,0xff
bne a5,zero,.L2
vslidedown.vi v2,v1,1
li a4,9
vmv.x.s a5,v2
andia5,a5,0xff
bne a5,a4,.L2
vslidedown.vi v2,v1,2
li a4,36
vmv.x.s a5,v2
andia5,a5,0xff
bne a5,a4,.L2
vslidedown.vi v2,v1,3
li a4,81
vmv.x.s a5,v2
andia5,a5,0xff
bne a5,a4,.L2
vslidedown.vi v2,v1,4
li a4,144
vmv.x.s a5,v2
andia5,a5,0xff
bne a5,a4,.L2
vslidedown.vi v2,v1,5
li a4,225
vmv.x.s a5,v2
andia5,a5,0xff
bne a5,a4,.L2
vslidedown.vi v2,v1,6
li a4,68
vmv.x.s a5,v2
andia5,a5,0xff
bne a5,a4,.L2
vslidedown.vi v2,v1,7
li a4,185
vmv.x.s a5,v2
andia5,a5,0xff
bne a5,a4,.L2
vslidedown.vi v2,v1,8
li a4,64
vmv.x.s a5,v2
andia5,a5,0xff
bne a5,a4,.L2
vslidedown.vi v2,v1,9
li a4,217
vmv.x.s a5,v2
andia5,a5,0xff
bne a5,a4,.L2
vslidedown.vi v2,v1,10
li a4,132
vmv.x.s a5,v2
andia5,a5,0xff
bne a5,a4,.L2
vslidedown.vi v2,v1,11
li a4,65
vmv.x.s a5,v2
andia5,a5,0xff
bne a5,a4,.L2
vslidedown.vi v2,v1,12
li a4,16
vmv.x.s a5,v2
andia5,a5,0xff
bne a5,a4,.L2
vslidedown.vi v2,v1,13
li a4,241
vmv.x.s a5,v2
andia5,a5,0xff
bne a5,a4,.L2
vslidedown.vi v2,v1,14
li a4,228
vmv.x.s a5,v2
andia5,a5,0xff
bne a5,a4,.L2
vslidedown.vi v1,v1,15
li a4,233
vmv.x.s a5,v1
andia5,a5,0xff
bne a5,a4,.L2
ld ra,40(sp)
li a0,0
addisp,sp,48
jr ra
.L2:
callabort
ARM SVE GCC:
main:
mov w0, 0
ret
[Bug tree-optimization/111734] [14 Regression] wrong code with '-O3 -fno-inline-functions-called-once -fno-inline-small-functions -fno-omit-frame-pointer -fno-toplevel-reorder -fno-tree-fre'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111734
Andrew Pinski changed:
What|Removed |Added
Ever confirmed|0 |1
Summary|wrong code with '-O3|[14 Regression] wrong code
|-fno-inline-functions-calle |with '-O3
|d-once |-fno-inline-functions-calle
|-fno-inline-small-functions |d-once
|-fno-omit-frame-pointer |-fno-inline-small-functions
|-fno-toplevel-reorder |-fno-omit-frame-pointer
|-fno-tree-fre' |-fno-toplevel-reorder
||-fno-tree-fre'
Last reconfirmed||2023-10-10
Component|c |tree-optimization
Target Milestone|--- |14.0
Status|UNCONFIRMED |NEW
--- Comment #3 from Andrew Pinski ---
PRE does:
Processing block 0: BB2
Value numbering stmt = *m_1(D) =
RHS simplified to
No store match
Value numbering store *m_1(D) to
Setting value number of .MEM_3 to .MEM_
...
Starting insert iteration 1
Deleted redundant store *m_1(D) =
Removing dead stmt *m_1(D) =
Better reduced testcase:
```
struct a {};
struct {
unsigned b;
unsigned short c;
} d, f = {9, 1};
int e;
static void g(unsigned, __SIZE_TYPE__, int **m);
static void h() {
int *i =
g(0, (__SIZE_TYPE__)i, );
if (*i)
f = d;
}
void g(unsigned a, __SIZE_TYPE__ b, int **m) {
*m =
}
int main() {
h();
if (f.c != 1)
__builtin_abort();
}
```
[Bug target/111745] [14 Regression] ICE: in extract_insn, at recog.cc:2791 (unrecognizable insn) with -ffloat-store -mavx512fp16 -mavx512vl
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111745 Hongtao.liu changed: What|Removed |Added CC||crazylht at gmail dot com --- Comment #1 from Hongtao.liu --- Mine, I'll take a look.
[Bug tree-optimization/111738] incorrect code when PGO is enabled
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111738 --- Comment #3 from Anonymous --- (In reply to Richard Biener from comment #1) > I can't reproduce. Your git version is quite old, it translates to > r14-2634-g85da0b40538fb0 for me. It doesn't reproduce with r14-2282 either > though. > > Current is r14-4486-g873586ebc565b6 Hi, Richard. According to your suggestion, we have updated our gcc to the latest trunk as: $ gcc -v Using built-in specs. COLLECT_GCC=/root/gcc_set/202310092007/bin/gcc COLLECT_LTO_WRAPPER=/root/gcc_set/202310092007/libexec/gcc/x86_64-pc-linux-gnu/14.0.0/lto-wrapper Target: x86_64-pc-linux-gnu Configured with: ../gcc/configure --prefix=/root/gcc_set/202310092007 --with-gmp=/root/build_essential --with-mpfr=/root/build_essential --with-mpc=/root/build_essential --enable-languages=c,c++ --disable-multilib Thread model: posix Supported LTO compression algorithms: zlib gcc version 14.0.0 20231009 (experimental) (GCC) git version: dee55cf59ceea989f47e7605205c6644b27a1f78 Then, we compiled the same test program with/without PGO enabled and found that the results are inconsistent as: $ gcc -O3 -w -fprofile-generate=profile a.c -o a.out $ ./a.out 4 $ gcc -O3 -w -fprofile-use=profile -Wno-missing-profile -fprofile-correction a.c -o a.out $ ./a.out 32765
[Bug libstdc++/111747] Problem with large float list initialization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111747 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #1 from Andrew Pinski --- 32bit floating point has the following characteristics: Sign bit: 1 bit Exponent width: 8 bits Significand precision: 24 bits (23 explicitly stored) 5000 is 0x2faf080 which is more than 24bits in precision which means it cannot be represented exactly and when you start to add 1 to something which is greater than 0xf0 (which is what 1.67772e+07 is), the value stays the same and you start to lose precision.
[Bug tree-optimization/111750] Spurious -Warray-bounds warning when using member function pointers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111750 --- Comment #1 from Andrew Pinski --- > That this source produces a -Warray-bounds warning is somewhat surprising > since it contains no arrays, no array indexing, and no pointer arithmetic Well techincally there is pointer arithmetic because the pointer to member function could have a delta for the function call at `(c.*func)();` Also there is an "array" because all variables/decls are arrays in C++ with a size of 1 (that allows you do pass + 1 as the end for iterators). Anyways the problem here is the optimizer optimized into `(c.*func)();` but had not optimized the ::my_method part yet when the warning happened.
[Bug debug/111749] Kk
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111749 Andrew Pinski changed: What|Removed |Added Ever confirmed|0 |1 Status|UNCONFIRMED |WAITING Last reconfirmed||2023-10-10 --- Comment #1 from Andrew Pinski --- This bug has no information in it? Was that by accident?
[Bug middle-end/111743] shifts in bit field accesses don't combine with other shifts
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111743 --- Comment #6 from Andrew Pinski --- (In reply to Andi Kleen from comment #5) > config/i386/i386.h:#define SLOW_BYTE_ACCESS 0 > > You mean it doesn't define it? The default is 1. Anyways in this case I was wrong but defining it to 0 causes other issues.
[Bug middle-end/111743] shifts in bit field accesses don't combine with other shifts
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111743 --- Comment #5 from Andi Kleen --- config/i386/i386.h:#define SLOW_BYTE_ACCESS 0 You mean it doesn't define it?
[Bug tree-optimization/111750] New: Spurious -Warray-bounds warning when using member function pointers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111750
Bug ID: 111750
Summary: Spurious -Warray-bounds warning when using member
function pointers
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: abbeyj+gcc at gmail dot com
Target Milestone: ---
Created attachment 56086
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56086=edit
Reproducer
The source code below generates a -Warray-bounds warning which I believe is
incorrect. Compile with `g++ -c -Wall -O2`.
```
struct MyClass {
void my_method();
};
MyClass g;
void pre();
inline void FetchValue(MyClass& c, void(MyClass::*func)()) {
pre();
(c.*func)();
}
int get_int();
inline int Check() {
static const int ret = get_int();
return ret;
}
inline void ReadValue(MyClass& c, void(MyClass::*func)()) {
Check();
FetchValue(c, func);
}
void Main() {
ReadValue(g, ::my_method);
}
```
This produces:
```
In function 'void FetchValue(MyClass&, void (MyClass::*)())',
inlined from 'void ReadValue(MyClass&, void (MyClass::*)())' at
:23:15,
inlined from 'void Main()' at :27:14:
:11:14: warning: array subscript 'int (**)(...)[0]' is partly outside
array bounds of 'MyClass [1]' [-Warray-bounds=]
11 | (c.*func)();
| ~^~
: In function 'void Main()':
:5:9: note: object 'g' of size 1
5 | MyClass g;
| ^
```
Godbolt link: https://godbolt.org/z/6YsWd9xhr
That this source produces a -Warray-bounds warning is somewhat surprising since
it contains no arrays, no array indexing, and no pointer arithmetic. Small
changes such as removing the static variable or manually inlining a function
into its caller make the warning go away.
The earliest version that I've been able to reproduce this with is GCC 11.1 and
it still reproduces on the trunk version that's currently available on
godbolt.org.
[Bug debug/111749] New: Kk
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111749 Bug ID: 111749 Summary: Kk Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: debug Assignee: unassigned at gcc dot gnu.org Reporter: molono1386 at dixiser dot com Target Milestone: ---
[Bug c++/111748] New: GCC does not understand partial ordering between non-constrained and constrained templates for specialization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111748
Bug ID: 111748
Summary: GCC does not understand partial ordering between
non-constrained and constrained templates for
specialization
Product: gcc
Version: 13.1.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: jeanmichael.celerier at gmail dot com
Target Milestone: ---
Consider:
#include
template
void foo() { }
template
void foo() { }
template<>
void foo() { }
int main() { foo(); }
According to the answers I got in https://stackoverflow.com/questions/77261120/
GCC should be able to compile this code, yet it fails due to a supposed
ambiguity between
template
void foo() { }
and
template
void foo() { }
as the base of foo
[Bug tree-optimization/111519] [13/14 Regression] Wrong code at -O3 on x86_64-linux-gnu since r13-455-g1fe04c497d
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111519 --- Comment #2 from Roger Sayle --- Complicated. Things have gone wrong before the strlen pass which is given: _73 = e; _72 = *_73; ... *_73 = prephitmp_23; d = _72; Here the assignment to *_73 overwrites the value of f (at *e) which then invalidates the use of _72 resulting in the wrong value for d. But figuring out which pass is at fault (perhaps complete loop unrolling?) is tricky.
[Bug libstdc++/111747] New: Problem with large float list initialization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111747 Bug ID: 111747 Summary: Problem with large float list initialization Product: gcc Version: 11.4.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: oplata.kes1 at mail dot ru Target Milestone: --- Created attachment 56085 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56085=edit *ii file and output I create a vector on stack of 50 (or 500mln) floats equal to 1.0 and simply add them. The sum is not equal to 50 mln (or 5 billions). 5 mln of floats initizalize and sum fine. The command is g++ -v -save-temps gcc.cpp && ./a.out If it is a stack overflow, shouldn't the code fail with stack overflow error? If not, what is it? I use GCC 11.4.0 in Ubuntu 22.04 under WSL 2 (!)
[Bug tree-optimization/111715] Missed optimization in FRE because of weak TBAA
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111715 --- Comment #6 from Sam James --- I started hitting the original warning Jakub hit with 13.2.1 20231007 but I've not tried to figure out which backported change caused it to appear.
[Bug tree-optimization/111679] `(~a) | (a ^ b)` is not simplified to `~(a & b)`
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111679 Andrew Pinski changed: What|Removed |Added Keywords||patch URL||https://gcc.gnu.org/piperma ||il/gcc-patches/2023-October ||/632386.html --- Comment #2 from Andrew Pinski --- Patch posted: https://gcc.gnu.org/pipermail/gcc-patches/2023-October/632386.html
[Bug target/111746] [14 Regression] ICE: infinite recursion in try_split (emit-rtl.cc:3972) at -O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111746 Andrew Pinski changed: What|Removed |Added Target Milestone|--- |14.0
[Bug middle-end/111743] shifts in bit field accesses don't combine with other shifts
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111743 Andrew Pinski changed: What|Removed |Added See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=107601 --- Comment #4 from Andrew Pinski --- x86_64 defines SLOW_BYTE_ACCESS which caues some (if not all) of the issues here: ``` ;; _3 = bf.c; (insn 9 8 10 (parallel [ (set (reg:DI 106) (lshiftrt:DI (reg/v:DI 104 [ bf ]) (const_int 32 [0x20]))) (clobber (reg:CC 17 flags)) ]) "/app/example.cpp":5:58 -1 (nil)) (insn 10 9 0 (parallel [ (set (reg:HI 100 [ _3 ]) (and:HI (subreg:HI (reg:DI 106) 0) (const_int 1023 [0x3ff]))) (clobber (reg:CC 17 flags)) ]) "/app/example.cpp":5:58 -1 (nil)) ;; _4 = (unsigned int) _3; (insn 11 10 0 (set (reg:SI 101 [ _4 ]) (zero_extend:SI (reg:HI 100 [ _3 ]))) "/app/example.cpp":5:46 -1 (nil)) ``` Uses HImode (short) here due to SLOW_BYTE_ACCESS being defined rather than the SImode (int).
[Bug middle-end/111743] shifts in bit field accesses don't combine with other shifts
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111743
Andrew Pinski changed:
What|Removed |Added
Ever confirmed|0 |1
CC||pinskia at gcc dot gnu.org
Severity|normal |enhancement
Last reconfirmed||2023-10-09
Status|UNCONFIRMED |NEW
--- Comment #3 from Andrew Pinski ---
RTL wise we have:
Trying 6, 8 -> 9:
6: {r108:DI=r105:DI 0>>0x20;clobber flags:CC;}
REG_UNUSED flags:CC
8: {r110:SI=r108:DI#0&0x3ff;clobber flags:CC;}
REG_UNUSED flags:CC
REG_DEAD r108:DI
9: {r111:SI=r110:SI<<0x14;clobber flags:CC;}
REG_DEAD r110:SI
REG_UNUSED flags:CC
Failed to match this instruction:
(parallel [
(set (reg:SI 111)
(and:SI (ashift:SI (subreg:SI (zero_extract:DI (reg/v:DI 105 [ bf
])
(const_int 32 [0x20])
(const_int 32 [0x20])) 0)
(const_int 20 [0x14]))
(const_int 1072693248 [0x3ff0])))
(clobber (reg:CC 17 flags))
])
This should have been simplified.
Anyways bitfields have issues even on the gimple level as they are not lowered
until expand ...
[Bug fortran/67740] Wrong association status of allocatable character pointer in derived types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67740 --- Comment #10 from anlauf at gcc dot gnu.org --- (In reply to anlauf from comment #9) Addendum: > I was suspecting gfc_conv_variable as a possibly further place for a fix: > it has a loop over ref's that looks incomplete for REF_COMPONENT. I tried my version of a patch in that place, which worked for the testcases here but gave wrong code already for slightly more complex pointer assignments, like type(pointer_typec0_t) :: co, xo ... xo%data1 => co%data1 so let's go with your patch.
[Bug target/111745] [14 Regression] ICE: in extract_insn, at recog.cc:2791 (unrecognizable insn) with -ffloat-store -mavx512fp16 -mavx512vl
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111745 Andrew Pinski changed: What|Removed |Added Keywords||needs-bisection Target Milestone|--- |14.0
[Bug tree-optimization/111694] [13/14 Regression] Wrong behavior for signbit of negative zero when optimizing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111694 --- Comment #9 from Andrew Macleod --- (In reply to Andrew Macleod from comment #8) > (In reply to Alexander Monakov from comment #7) > > No backport for gcc-13 planned? > > mmm, didn't realize were we propagating floating point equivalences around > in 13. similar patch should work there Testing same patch on gcc13. will let it settle on trunk for a day or two first, then check it in if nothing shows up.which it shouldn't :-)
[Bug target/111746] New: [14 Regression] ICE: infinite recursion in try_split (emit-rtl.cc:3972) at -O2
--with-cloog --with-ppl --with-isl --with-sysroot=/usr/powerpc64le-unknown-linux-gnu --build=x86_64-pc-linux-gnu --host=x86_64-pc-linux-gnu --target=powerpc64le-unknown-linux-gnu --with-ld=/usr/bin/powerpc64le-unknown-linux-gnu-ld --with-as=/usr/bin/powerpc64le-unknown-linux-gnu-as --disable-libstdcxx-pch --prefix=/repo/gcc-trunk//binary-trunk-r14-4520-20231009121517-gb0892b1fc63-checking-yes-rtl-df-extra-powerpc64le Thread model: posix Supported LTO compression algorithms: zlib zstd gcc version 14.0.0 20231009 (experimental) (GCC) The build breaks at: $ make /bin/sh ../libtool --tag CC --tag disable-shared --mode=compile /repo/build-gcc-trunk-powerpc64le/./gcc/xgcc -B/repo/build-gcc-trunk-powerpc64le/./gcc/ -B/repo/gcc-trunk//binary-trunk-r14-4520-20231009121517-gb0892b1fc63-checking-yes-rtl-df-extra-powerpc64le/powerpc64le-unknown-linux-gnu/bin/ -B/repo/gcc-trunk//binary-trunk-r14-4520-20231009121517-gb0892b1fc63-checking-yes-rtl-df-extra-powerpc64le/powerpc64le-unknown-linux-gnu/lib/ -isystem /repo/gcc-trunk//binary-trunk-r14-4520-20231009121517-gb0892b1fc63-checking-yes-rtl-df-extra-powerpc64le/powerpc64le-unknown-linux-gnu/include -isystem /repo/gcc-trunk//binary-trunk-r14-4520-20231009121517-gb0892b1fc63-checking-yes-rtl-df-extra-powerpc64le/powerpc64le-unknown-linux-gnu/sys-include -DHAVE_CONFIG_H -I.. -I/repo/gcc-trunk/libstdc++-v3/../libiberty -I/repo/gcc-trunk/libstdc++-v3/../include -prefer-pic -D_GLIBCXX_SHARED -I/repo/build-gcc-trunk-powerpc64le/powerpc64le-unknown-linux-gnu/libstdc++-v3/include/powerpc64le-unknown-linux-gnu -I/repo/build-gcc-trunk-powerpc64le/powerpc64le-unknown-linux-gnu/libstdc++-v3/include -I/repo/gcc-trunk/libstdc++-v3/libsupc++-g -O2 -DIN_GLIBCPP_V3 -Wno-error -c cp-demangle.c libtool: compile: /repo/build-gcc-trunk-powerpc64le/./gcc/xgcc -B/repo/build-gcc-trunk-powerpc64le/./gcc/ -B/repo/gcc-trunk//binary-trunk-r14-4520-20231009121517-gb0892b1fc63-checking-yes-rtl-df-extra-powerpc64le/powerpc64le-unknown-linux-gnu/bin/ -B/repo/gcc-trunk//binary-trunk-r14-4520-20231009121517-gb0892b1fc63-checking-yes-rtl-df-extra-powerpc64le/powerpc64le-unknown-linux-gnu/lib/ -isystem /repo/gcc-trunk//binary-trunk-r14-4520-20231009121517-gb0892b1fc63-checking-yes-rtl-df-extra-powerpc64le/powerpc64le-unknown-linux-gnu/include -isystem /repo/gcc-trunk//binary-trunk-r14-4520-20231009121517-gb0892b1fc63-checking-yes-rtl-df-extra-powerpc64le/powerpc64le-unknown-linux-gnu/sys-include -DHAVE_CONFIG_H -I.. -I/repo/gcc-trunk/libstdc++-v3/../libiberty -I/repo/gcc-trunk/libstdc++-v3/../include -D_GLIBCXX_SHARED -I/repo/build-gcc-trunk-powerpc64le/powerpc64le-unknown-linux-gnu/libstdc++-v3/include/powerpc64le-unknown-linux-gnu -I/repo/build-gcc-trunk-powerpc64le/powerpc64le-unknown-linux-gnu/libstdc++-v3/include -I/repo/gcc-trunk/libstdc++-v3/libsupc++ -g -O2 -DIN_GLIBCPP_V3 -Wno-error -c cp-demangle.c -fPIC -DPIC -o cp-demangle.o xgcc: internal compiler error: Segmentation fault signal terminated program cc1 Please submit a full bug report, with preprocessed source (by using -freport-bug). See <https://gcc.gnu.org/bugs/> for instructions. make: *** [Makefile:970: cp-demangle.lo] Error 1
[Bug target/111745] New: [14 Regression] ICE: in extract_insn, at recog.cc:2791 (unrecognizable insn) with -ffloat-store -mavx512fp16 -mavx512vl
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111745 Bug ID: 111745 Summary: [14 Regression] ICE: in extract_insn, at recog.cc:2791 (unrecognizable insn) with -ffloat-store -mavx512fp16 -mavx512vl Product: gcc Version: 14.0 Status: UNCONFIRMED Keywords: ice-on-valid-code Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: zsojka at seznam dot cz Target Milestone: --- Host: x86_64-pc-linux-gnu Target: x86_64-pc-linux-gnu Created attachment 56083 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56083=edit reduced testcase Compiler output: $ x86_64-pc-linux-gnu-gcc -ffloat-store -mavx512fp16 -mavx512vl testcase.c testcase.c: In function 'foo': testcase.c:8:1: error: unrecognizable insn: 8 | } | ^ (insn 54 53 55 2 (set (reg:V8HF 136) (vec_concat:V8HF (mem:V4HF (plus:DI (reg/f:DI 93 virtual-stack-vars) (const_int -16 [0xfff0])) [1 S8 A64]) (reg:V4HF 139))) "testcase.c":7:5 -1 (nil)) during RTL pass: vregs testcase.c:8:1: internal compiler error: in extract_insn, at recog.cc:2791 0x7e765b _fatal_insn(char const*, rtx_def const*, char const*, int, char const*) /repo/gcc-trunk/gcc/rtl-error.cc:108 0x7e76d8 _fatal_insn_not_found(rtx_def const*, char const*, int, char const*) /repo/gcc-trunk/gcc/rtl-error.cc:116 0x7d63fd extract_insn(rtx_insn*) /repo/gcc-trunk/gcc/recog.cc:2791 0x10e7995 instantiate_virtual_regs_in_insn /repo/gcc-trunk/gcc/function.cc:1610 0x10e7995 instantiate_virtual_regs /repo/gcc-trunk/gcc/function.cc:1983 0x10e7995 execute /repo/gcc-trunk/gcc/function.cc:2030 Please submit a full bug report, with preprocessed source (by using -freport-bug). Please include the complete backtrace with any bug report. See <https://gcc.gnu.org/bugs/> for instructions. $ x86_64-pc-linux-gnu-gcc -v Using built-in specs. COLLECT_GCC=/repo/gcc-trunk/binary-latest-amd64/bin/x86_64-pc-linux-gnu-gcc COLLECT_LTO_WRAPPER=/repo/gcc-trunk/binary-trunk-r14-4520-20231009121517-gb0892b1fc63-checking-yes-rtl-df-extra-nobootstrap-amd64/bin/../libexec/gcc/x86_64-pc-linux-gnu/14.0.0/lto-wrapper Target: x86_64-pc-linux-gnu Configured with: /repo/gcc-trunk//configure --enable-languages=c,c++ --enable-valgrind-annotations --disable-nls --enable-checking=yes,rtl,df,extra --disable-bootstrap --with-cloog --with-ppl --with-isl --build=x86_64-pc-linux-gnu --host=x86_64-pc-linux-gnu --target=x86_64-pc-linux-gnu --with-ld=/usr/bin/x86_64-pc-linux-gnu-ld --with-as=/usr/bin/x86_64-pc-linux-gnu-as --disable-libstdcxx-pch --prefix=/repo/gcc-trunk//binary-trunk-r14-4520-20231009121517-gb0892b1fc63-checking-yes-rtl-df-extra-nobootstrap-amd64 Thread model: posix Supported LTO compression algorithms: zlib zstd gcc version 14.0.0 20231009 (experimental) (GCC)
[Bug middle-end/111743] shifts in bit field accesses don't combine with other shifts
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111743 --- Comment #2 from Andi Kleen --- Okay then it doesn't understand that SHL_signed and SHR_unsigned can be combined when one the values came from a shorter unsigned.
[Bug rtl-optimization/111744] New: Missed optimization when casting rdtsc into uint32_t and computing difference
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111744
Bug ID: 111744
Summary: Missed optimization when casting rdtsc into uint32_t
and computing difference
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: rtl-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: stefan.sakalik at gmail dot com
Target Milestone: ---
This is similar to https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92180 where
this code: https://godbolt.org/z/7W9nqTsjE
#include
#include
uint32_t rdtsc32() { return static_cast(__rdtsc()); }
uint64_t rdtsc_delta(uint64_t x) {
return rdtsc32() - rdtsc32();
}
Produces
rdtsc_delta(unsigned long):
rdtsc
mov rcx, rax
sal rdx, 32
or rcx, rdx
rdtsc
sub ecx, eax
mov rax, rcx
ret
as opposed to clang version
rdtsc_delta(unsigned long):
rdtsc
mov rcx, rax
rdtsc
sub ecx, eax
mov rax, rcx
ret
[Bug middle-end/111743] shifts in bit field accesses don't combine with other shifts
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111743 --- Comment #1 from Andrew Pinski --- Remember types smaller than int is prompted to int .
[Bug middle-end/111743] New: shifts in bit field accesses don't combine with other shifts
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111743
Bug ID: 111743
Summary: shifts in bit field accesses don't combine with other
shifts
Product: gcc
Version: 13.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: andi-gcc at firstfloor dot org
Target Milestone: ---
(not sure it's the middle-end, picked arbitrarily)
The following code
struct bf {
unsigned a : 10, b : 20, c : 10;
};
unsigned fbc(struct bf bf) { return bf.b | (bf.c << 20); }
generates:
movq%rdi, %rax
shrq$10, %rdi
shrq$32, %rax
andl$1048575, %edi
andl$1023, %eax
sall$20, %eax
orl %edi, %eax
ret
It doesn't understand that the shift right can be combined with the shift left.
Also not sure why the shift left is arithmetic (this should be all unsigned)
clang does the simplification which ends up one instruction shorter:
movl%edi, %eax
shrl$10, %eax
andl$1048575, %eax # imm = 0xF
shrq$12, %rdi
andl$1072693248, %edi # imm = 0x3FF0
orl %edi, %eax
retq
[Bug c++/111742] Misaligned generated code with MI using aligned virtual base
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111742 --- Comment #3 from Andrew Pinski --- Then it is a dup of bug 71644. *** This bug has been marked as a duplicate of bug 71644 ***
[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 CC||cuzdav at gmail dot com --- Comment #3 from Andrew Pinski --- *** Bug 111742 has been marked as a duplicate of this bug. ***
[Bug c++/111742] Misaligned generated code with MI using aligned virtual base
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111742
--- Comment #2 from Chris Uzdavinis ---
No, this is not a ubsan report.
Code *crashes* and I thought showing the UBsan warning was enough to
demonstrate it.
A minimal change to make the code crash instead of just report ubsan errors:
struct X {
void * a = nullptr;
void * b = nullptr;
};
struct alignas(16) AlignedData { };
struct A : virtual AlignedData {
int x = 0; // << add this
X xxx;
int& ref = x;// << and this
};
struct B : virtual AlignedData {};
struct Test : B, A {};
Test* t = new Test;
int main() {}
*** SEGFAULT ***
https://godbolt.org/z/f57vs7jxP
[Bug tree-optimization/111694] [13/14 Regression] Wrong behavior for signbit of negative zero when optimizing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111694 Andrew Macleod changed: What|Removed |Added Resolution|FIXED |--- Status|RESOLVED|REOPENED --- Comment #8 from Andrew Macleod --- (In reply to Alexander Monakov from comment #7) > No backport for gcc-13 planned? mmm, didn't realize were we propagating floating point equivalences around in 13. similar patch should work there
[Bug c/111741] gcc long double precision
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111741 --- Comment #3 from bernardwidynski at gmail dot com --- Thanks for the quick response. That explains it. On Mon, Oct 9, 2023 at 10:20 AM pinskia at gcc dot gnu.org < gcc-bugzi...@gcc.gnu.org> wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111741 > > Andrew Pinski changed: > >What|Removed |Added > > > Status|UNCONFIRMED |RESOLVED > Resolution|--- |INVALID > > --- Comment #2 from Andrew Pinski --- > 80bit is the full precission and that 80bits includes 1 bit sign bit, > 64bits > for the mantissa and 15bits for the exponent. > > So anything above 64bits will start to lose precission in the last digits. > > -- > You are receiving this mail because: > You reported the bug.
[Bug sanitizer/83780] False positive alignment error with -fsanitize=undefined with virtual base
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83780 Andrew Pinski changed: What|Removed |Added CC||cuzdav at gmail dot com --- Comment #6 from Andrew Pinski --- *** Bug 111742 has been marked as a duplicate of this bug. ***
[Bug c++/111742] Misaligned generated code with MI using aligned virtual base
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111742 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #1 from Andrew Pinski --- It is just a santizer issue. Dup of bug 83780. *** This bug has been marked as a duplicate of bug 83780 ***
[Bug c/111741] gcc long double precision
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111741 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #2 from Andrew Pinski --- 80bit is the full precission and that 80bits includes 1 bit sign bit, 64bits for the mantissa and 15bits for the exponent. So anything above 64bits will start to lose precission in the last digits.
[Bug c++/111742] New: Misaligned generated code with MI using aligned virtual base
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111742
Bug ID: 111742
Summary: Misaligned generated code with MI using aligned
virtual base
Product: gcc
Version: 13.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: cuzdav at gmail dot com
Target Milestone: ---
Generated code is misaligned (and crashes in slightly more complex code), in
trunk all the way back to gcc 8.1, when built in c++11 or higher, with O3.
(Linux, x86)
Complete code:
//
struct X {
void * a = nullptr;
void * b = nullptr;
};
struct alignas(16) AlignedData { };
struct A : virtual AlignedData {
X xxx;
};
struct B : virtual AlignedData {};
struct Test : B, A {};
Test* t = new Test;
int main() {}
//
Compiler Explorer demo:
https://godbolt.org/z/aodTdaedW
Running with UB-san reports this:
/app/example.cpp:14:8: runtime error: constructor call on misaligned address
0x0227f2b8 for type 'struct A', which requires 16 byte alignment
0x0227f2b8: note: pointer points here
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00
^
/app/example.cpp:8:8: runtime error: member access within misaligned address
0x0227f2b8 for type 'struct A', which requires 16 byte alignment
0x0227f2b8: note: pointer points here
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00
^
[Bug tree-optimization/111694] [13/14 Regression] Wrong behavior for signbit of negative zero when optimizing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111694 --- Comment #7 from Alexander Monakov --- No backport for gcc-13 planned?
[Bug c/111741] gcc long double precision
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111741 --- Comment #1 from bernardwidynski at gmail dot com --- Created attachment 56082 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56082=edit Output file
[Bug c/111741] New: gcc long double precision
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111741 Bug ID: 111741 Summary: gcc long double precision Product: gcc Version: 11.4.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: bernardwidynski at gmail dot com Target Milestone: --- Created attachment 56081 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56081=edit C program to compute sum of numbers 1, 2, 3, ... N It is my understanding the long double in gcc has 80 bits precision. I've run a simple program which shows that it is less than 80 bits precision. The numbers 1, 2, 3, ... N are summed and compared with N*(N+1)/2 For the case where N = 2^32, the sums compare correctly. For the case where N = 2^33, the sums are different. 2^33*(2^33-1)/2 is less than 80 bits in precision. Why doesn't the long double have the capacity for this computation? See attached program and output file. This was run on Cygwin64 using gcc version 11.4.0 on an Intel Core i7-9700
[Bug tree-optimization/111694] [13/14 Regression] Wrong behavior for signbit of negative zero when optimizing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111694 Andrew Macleod changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #6 from Andrew Macleod --- fixed
[Bug tree-optimization/111694] [13/14 Regression] Wrong behavior for signbit of negative zero when optimizing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111694 --- Comment #5 from CVS Commits --- The master branch has been updated by Andrew Macleod : https://gcc.gnu.org/g:b0892b1fc637fadf14d7016858983bc5776a1e69 commit r14-4520-gb0892b1fc637fadf14d7016858983bc5776a1e69 Author: Andrew MacLeod Date: Mon Oct 9 10:15:07 2023 -0400 Ensure float equivalences include + and - zero. A floating point equivalence may not properly reflect both signs of zero, so be pessimsitic and ensure both signs are included. PR tree-optimization/111694 gcc/ * gimple-range-cache.cc (ranger_cache::fill_block_cache): Adjust equivalence range. * value-relation.cc (adjust_equivalence_range): New. * value-relation.h (adjust_equivalence_range): New prototype. gcc/testsuite/ * gcc.dg/pr111694.c: New.
[Bug sanitizer/111736] Address sanitizer is not compatible with named address spaces
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111736
--- Comment #3 from Alexander Monakov ---
Sorry, the second half of my comment is confusing. To clarify, ASan works fine
for TLS data (the compiler knows that TLS base is at fs:0; libsanitizer uses
some hacks to initialize shadow for TLS anyway, so it seems explicit
registration is not needed).
The difference is, produces an address in the generic address space by using
the knowledge that fs:0 stores the segment base. For __seg_{fs,gs} that can't
be done, and is the offset w.r.t segment base.
[Bug target/111425] ia64: ICE in net/ipv4/fib_semantics.c:1621:1: internal compiler error: Segmentation fault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111425 --- Comment #8 from Tomáš Glozar --- It looks like somehow a value RTX with rt_cselib set to NULL gets into the hashmap: (gdb) f 1 #1 rtx_equal_for_cselib_1 (x=0x2674608, y=0x26747f8, memmode=memmode@entry=E_VOIDmode, depth=depth@entry=1) at ../../gcc/cselib.cc:963 963 cselib_val *e = canonical_cselib_val (CSELIB_VAL_PTR (x)); (gdb) p debug_rtx(x) (value:DI Program received signal SIGSEGV, Segmentation fault. 0x00a92f96 in rtx_writer::print_rtx_operand_code_0 (this=0x7fff64c0, in_rtx=0x2674608, idx=0) at ../../gcc/print-rtl.cc:318 318 fprintf (m_outfile, " %u:%u", val->uid, val->hash); Going one level up: (gdb) p debug_rtx(y) (subreg:SI (value/u:DI 264:376 @0x26747f8/0x2666068) 0) $1 = void (gdb) p debug_rtx(x) (subreg:SI (value:DI Program received signal SIGSEGV, Segmentation fault. Not sure how this is related to 5fc4d3e1837, as I understand it, it should only affect single-bit values, here it is a DI value. I am not familiar with the algorithm, so proceeding further in finding the cause it hard for me. Perhaps someone who knows the algorithm has an idea why that field is NULL.
[Bug debug/111740] New: Incorrect DWARF expression generated at specific live range
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111740 Bug ID: 111740 Summary: Incorrect DWARF expression generated at specific live range Product: gcc Version: 12.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: debug Assignee: unassigned at gcc dot gnu.org Reporter: king.chung at manchester dot ac.uk Target Milestone: --- Created attachment 56080 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56080=edit Source code The DWARF expression between the range 0x10984 to 0x1098c is not correct. The following is the variable I am trying to test: <5><76c>: Abbrev Number: 3 (DW_TAG_variable) <76d> DW_AT_name: (indirect string, offset: 0x436): tmp_level <771> DW_AT_decl_file : 1 <771> DW_AT_decl_line : 60 <772> DW_AT_decl_column : 17 <773> DW_AT_type: <0x641> <777> DW_AT_location: 0x1b4 (location list) 01b4 00010974 00010980 (DW_OP_reg12 (a2)) 01c7 00010980 00010984 (DW_OP_breg17 (a7): 0) 01db 00010984 0001098c (DW_OP_breg13 (a3): 0; DW_OP_breg16 (a6): 0; DW_OP_plus) 01f2 The following log of running the binary with GDB: +b *0x10984 Breakpoint 1 at 0x10984: file bfs.c, line 62. +continue Continuing. Breakpoint 1, 0x00010984 in bfs (nodes=nodes@entry=0x9af00, edges=edges@entry=0x9bf00, starting_node=, level=level@entry=0xa3f08 "\177\177\177\177\177\177\001", '\177' , level_counts=level_counts@entry=0xa4008) at bfs.c:62 +si +info registers a3 a6 a3 0xa3f08 671496 a6 0x6 6 +x 0xa3f08 0xa3f08:0x7f7f7f7f +x 0x6 0x6:Cannot access memory at address 0x6 +print tmp_level $1 = 1 '\001' By purely using the DWARF expression, the correct value of the variable could not be found manually. Interestingly, GDB is still able to compute a value despite the DWARF expression is not correct. This again uses the same file and binary from bug111680 and bug111716 with the same command. `riscv64-unknown-linux-gnu-gcc -static -O3 -Wall -Wno-unused-label -march=rv64imafd -g -fno-reorder-blocks -o bfs bfs.c local_support.c support.c harness.c`
[Bug tree-optimization/111738] incorrect code when PGO is enabled
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111738 --- Comment #2 from Anonymous --- (In reply to Richard Biener from comment #1) > I can't reproduce. Your git version is quite old, it translates to > r14-2634-g85da0b40538fb0 for me. It doesn't reproduce with r14-2282 either > though. > > Current is r14-4486-g873586ebc565b6 Thank you very much for providing the feedback. To ensure the later reported bugs can be reproduced, we will update our GCC version to the latest trunk.
[Bug tree-optimization/111739] incorrect code with PGO enabled
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111739 --- Comment #2 from Anonymous --- (In reply to Richard Biener from comment #1) > Confirmed with r14-4302 and also with the head of the GCC 13 branch. > > It helps if you can produce proper ISO C without implicit int and like. Thank you for confirming the bug. Moving forward, we will ensure that the code does not rely on implicit integer types.
[Bug sanitizer/111736] Address sanitizer is not compatible with named address spaces
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111736
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
--- Comment #2 from Alexander Monakov ---
Looks that way — even though __seg_gs AS is a subset of the generic AS, the
compiler has no way to find out the base of __seg_gs.
We already skip registering TLS data with ASan:
__thread int x;
int foo (void)
{
return x;
}
[Bug tree-optimization/111715] Missed optimization in FRE because of weak TBAA
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111715 Richard Biener changed: What|Removed |Added Resolution|--- |FIXED Known to fail||13.2.1 Keywords||alias, missed-optimization Known to work||14.0 Target Milestone|--- |14.0 Status|ASSIGNED|RESOLVED --- Comment #5 from Richard Biener --- Fixed on trunk.
[Bug tree-optimization/111715] Missed optimization in FRE because of weak TBAA
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111715 --- Comment #4 from CVS Commits --- The master branch has been updated by Richard Biener : https://gcc.gnu.org/g:11b8cf1685bb40af5b86653e492e350983025957 commit r14-4510-g11b8cf1685bb40af5b86653e492e350983025957 Author: Richard Biener Date: Mon Oct 9 13:05:10 2023 +0200 tree-optimization/111715 - improve TBAA for access paths with pun The following improves basic TBAA for access paths formed by C++ abstraction where we are able to combine a path from an address-taking operation with a path based on that access using a pun to avoid memory access semantics on the address-taking part. The trick is to identify the point the semantic memory access path starts which allows us to use the alias set of the outermost access instead of only that of the base of this path. PR tree-optimization/111715 * alias.cc (reference_alias_ptr_type_1): When we have a type-punning ref at the base search for the access path part that's still semantically valid. * gcc.dg/tree-ssa/ssa-fre-102.c: New testcase.
[Bug tree-optimization/111739] incorrect code with PGO enabled
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111739 Richard Biener changed: What|Removed |Added Keywords||wrong-code Last reconfirmed||2023-10-09 Status|UNCONFIRMED |NEW Ever confirmed|0 |1 --- Comment #1 from Richard Biener --- Confirmed with r14-4302 and also with the head of the GCC 13 branch. It helps if you can produce proper ISO C without implicit int and like.
[Bug tree-optimization/111738] incorrect code when PGO is enabled
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111738 --- Comment #1 from Richard Biener --- I can't reproduce. Your git version is quite old, it translates to r14-2634-g85da0b40538fb0 for me. It doesn't reproduce with r14-2282 either though. Current is r14-4486-g873586ebc565b6
[Bug tree-optimization/111739] New: incorrect code with PGO enabled
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111739
Bug ID: 111739
Summary: incorrect code with PGO enabled
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: iamanonymous.cs at gmail dot com
Target Milestone: ---
***
OS and Platform:
$ uname -a:
Linux ubuntu 4.15.0-213-generic #224-Ubuntu SMP Mon Jun 19 13:30:12 UTC 2023
x86_64 x86_64 x86_64 GNU/Linux
***
gcc version:
$ gcc -v
Using built-in specs.
COLLECT_GCC=/root/gcc_set/new_gcc/bin/gcc
COLLECT_LTO_WRAPPER=/root/gcc_set/new_gcc/libexec/gcc/x86_64-pc-linux-gnu/14.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc/configure --prefix=/root/gcc_set/new_gcc
--with-gmp=/root/build_essential --with-mpfr=/root/build_essential
--with-mpc=/root/build_essential --enable-languages=c,c++ --disable-multilib
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 14.0.0 20230719 (experimental) (GCC)
git version:85da0b40538fb0d17d89de1e7905984668e3dfef
***
Program:
$ cat a.c
c, d, e, a;
union {
int f;
short g
} h;
*j =
k(short l, short m) { return m == 0 || l && m == 1 ?: l / m; }
n(l) { return c == 0 ?: l / c; }
main() {
a = n(h.f++);
*j = 0;
int i = 0;
for (; i < 2; i++)
d = k(h.g || 0, 59376);
short *b =
*b ^= e;
printf("%d\n", h);
}
***
Command Lines:
# The profile directory is used to save profile information.
$ gcc -O3 -w -fprofile-generate=profile a.c -o a.out
$ ./a.out
0
$ gcc -O3 -w -fprofile-use=profile -Wno-missing-profile -fprofile-correction
a.c
-o a.out
$ ./a.out
1
We can found that, the output of the executable is incorrect when the profile
guided optimization is enabled.
[Bug c/111734] wrong code with '-O3 -fno-inline-functions-called-once -fno-inline-small-functions -fno-omit-frame-pointer -fno-toplevel-reorder -fno-tree-fre'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111734
--- Comment #2 from CTC <19373742 at buaa dot edu.cn> ---
A reduced testcase:
#include
#include
struct a {};
struct {
uint32_t b;
int16_t c;
} d, f = {9, 1};
int32_t e;
static int32_t *g();
static uint32_t h() {
int32_t *i =
struct a j;
g(j, i, );
if (*i)
f = d;
}
int32_t *g(uint32_t, int32_t, int32_t **m) {
int32_t *k =
*m = k;
}
int main() {
h();
printf("%d\n", f.c);
}
[Bug tree-optimization/111738] New: incorrect code when PGO is enabled
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111738
Bug ID: 111738
Summary: incorrect code when PGO is enabled
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: iamanonymous.cs at gmail dot com
Target Milestone: ---
***
OS and Platform:
$ uname -a:
Linux ubuntu 4.15.0-213-generic #224-Ubuntu SMP Mon Jun 19 13:30:12 UTC 2023
x86_64 x86_64 x86_64 GNU/Linux
***
gcc version:
$ gcc -v
Using built-in specs.
COLLECT_GCC=/root/gcc_set/new_gcc/bin/gcc
COLLECT_LTO_WRAPPER=/root/gcc_set/new_gcc/libexec/gcc/x86_64-pc-linux-gnu/14.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc/configure --prefix=/root/gcc_set/new_gcc
--with-gmp=/root/build_essential --with-mpfr=/root/build_essential
--with-mpc=/root/build_essential --enable-languages=c,c++ --disable-multilib
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 14.0.0 20230719 (experimental) (GCC)
git version:85da0b40538fb0d17d89de1e7905984668e3dfef
***
Program:
$ cat a.c
a = 4, b = 0, d = 0, e = 0, f = 0;
**c =
*g =
h() {
i();
if (f)
e = 0;
}
i() {
float j = 0;
int **k =
*k =
*g |= **c;
if (*g)
;
else {
long *l = d = (*l)++;
}
}
main() {
h();
printf("%d\n", a);
}
***
Command Lines:
# The profile directory is used to save profile information.
$ gcc -O3 -w -fprofile-generate=profile a.c -o a.out
$ ./a.out
4
$ gcc -O3 -w -fprofile-use=profile -Wno-missing-profile -fprofile-correction
a.c
-o a.out
$ ./a.out
32764
We can found that, the output of the executable is incorrect when the profile
guided optimization is enabled.
[Bug sanitizer/111736] Address sanitizer is not compatible with named address spaces
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111736 Richard Biener changed: What|Removed |Added Keywords||wrong-code --- Comment #1 from Richard Biener --- The "fix" is probably to not attempt to [K]ASAN any non-default address space access?
[Bug middle-end/111732] genmatch missed optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111732 --- Comment #2 from Richard Biener --- (In reply to Richard Biener from comment #1) > Created attachment 56079 [details] > start of a patch > > Start of a patch. Still has duplicate case values (dt tree insertion) and > missed for ID passing to the tail functions. Overall effect isn't too big - the biggest limitation is likely failure to factor outermost fors (or rather giving up on any delaying when the outermost match expression needs to be for-lowered rather than deciding on an operator basis).
[Bug c++/111737] New: Object holding a pointer to an uninitialized c-array not usable in a constant expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111737
Bug ID: 111737
Summary: Object holding a pointer to an uninitialized c-array
not usable in a constant expression
Product: gcc
Version: 13.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: benoit.labrique at endress dot com
Target Milestone: ---
Following code does not compile (see details below) as soon as there is an
indirection, in this case the function MakeBuffer().
This kind of construct is very common in the embedded world, where dynamic
memory allocation is not permitted. As in the code example, buffers of
different size can be passed to more generic functionality via a reference to
the base class "Collection", which is buffer-size agnostic.
// Compiled with -O2 -std=c++17
class Collection
{
protected:
constexpr Collection(void * iBuffer)
: m_buffer(iBuffer)
{
}
protected:
void * m_buffer = nullptr;
};
class Buffer final : public Collection
{
public:
explicit constexpr Buffer()
: Collection(m_buffer), m_buffer{0} // gcc doesn't like that m_buffer
is used before it is initialized. Using std::array instead won't work at all.
{
}
private:
intm_buffer[1];
};
namespace
{
inline constexpr auto MakeBuffer()
{
return Buffer();// C++17: shall definitively perform copy elision
}
constexpr Buffer VIA_MAKE_BUFFER = MakeBuffer();// Only gcc has a
problem with, neither clang nor msvc
constexpr Buffer VIA_BUFFER_CONSTRUCTOR = Buffer(); // Why is it now OK
for gcc here?
}
int main()
{
constexpr auto a = VIA_MAKE_BUFFER;
constexpr auto b = VIA_BUFFER_CONSTRUCTOR;
return 0;
}
https://godbolt.org/z/erPsooP4b
Compiling this code issues (ARM GCC 13.2 (or earlier)):
: In function 'int main()':
:38:24: error: the value of '{anonymous}::VIA_MAKE_BUFFER' is not
usable in a constant expression
38 | constexpr auto a = VIA_MAKE_BUFFER;
|^~~
:32:22: note: '{anonymous}::VIA_MAKE_BUFFER' used in its own
initializer
32 | constexpr Buffer VIA_MAKE_BUFFER = MakeBuffer();// Only gcc
has a problem with, neither clang nor msvc
| ^~~
Alternatively: on x86-64 GCC 13.2 (or earlier):
:32:51: error:
'Buffer{Collection{((void*)(&.Buffer::m_buffer))}, int [1]{0}}' is
not a constant expression
32 | constexpr Buffer VIA_MAKE_BUFFER = MakeBuffer();// Only gcc
has a problem with, neither clang nor msvc
|
[Bug middle-end/111732] genmatch missed optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111732 --- Comment #1 from Richard Biener --- Created attachment 56079 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56079=edit start of a patch Start of a patch. Still has duplicate case values (dt tree insertion) and missed for ID passing to the tail functions.
[Bug sanitizer/111736] New: Address sanitizer is not compatible with named address spaces
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111736
Bug ID: 111736
Summary: Address sanitizer is not compatible with named address
spaces
Product: gcc
Version: 12.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: sanitizer
Assignee: unassigned at gcc dot gnu.org
Reporter: ubizjak at gmail dot com
CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org,
jakub at gcc dot gnu.org, kcc at gcc dot gnu.org, marxin at
gcc dot gnu.org
Target Milestone: ---
>From [1], gcc is doing a KASAN check on a percpu address (when percpu access is
implemented using named address spaces). This is not a "real" address, just an
offset from the segment register.
The testcase
--cut here--
int __seg_gs m;
int foo (void)
{
return m;
}
--cut here--
does not show any special handling that would handle segment registers.
[1]
https://lore.kernel.org/lkml/CAHk-=wi6u-o1wdpoesuce6qo2oapu0hezaig0udou4l5cre...@mail.gmail.com/
[Bug debug/111735] New: incorrect BTF representation of forward-declared enums
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111735 Bug ID: 111735 Summary: incorrect BTF representation of forward-declared enums Product: gcc Version: 13.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: debug Assignee: unassigned at gcc dot gnu.org Reporter: gprocida at google dot com Target Milestone: --- The BTF_FWD_KIND node can only distinguish between struct and union types. (Non-standard) forward-declared enum types need to be represented in some different fashion. I queried this on LKML in July 2020 and was told that then current way to represent such types is as BTF_KIND_ENUM with vlen = 0. This is in fact what both Clang and pahole -J do. I think Clang produces slightly better output than pahole (leaving size as 0). test input: $ cat /tmp/xx.c enum Foo; enum Foo* foo; compilation command: $ gcc -gbtf -c /tmp/xx.c -o /tmp/xx.o unexpected output: $ bpftool btf dump file /tmp/xx.o format raw [1] FWD 'Foo' fwd_kind=struct [2] PTR '(anon)' type_id=1 [3] VAR 'foo' type_id=2, linkage=global [4] DATASEC '.bss' size=0 vlen=1 type_id=3 offset=0 size=8 (VAR 'foo') possible expected output (size=0): $ clang-15 -target bpf -g -c /tmp/xx.c -o /tmp/xx.o $ pahole -J /tmp/xx.o $ bpftool btf dump file /tmp/xx.o format raw | grep Foo [2] ENUM 'Foo' encoding=UNSIGNED size=0 vlen=0 other possible expected output (size=4): $ gcc -g -c /tmp/xx.c -o /tmp/xx.o $ pahole -J /tmp/xx.o $ bpftool btf dump file /tmp/xx.o format raw | grep Foo [1] ENUM 'Foo' encoding=UNSIGNED size=4 vlen=0 GCC version: Using built-in specs. COLLECT_GCC=gcc COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-linux-gnu/13/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='Debian 13.2.0-4' --with-bugurl=file:///usr/share/doc/gcc-13/README.Bugs --enable-languages=c,ada,c++,go,d,fortran,objc,obj-c++,m2 --prefix=/usr --with-gcc-major-version-only --program-suffix=-13 --program-prefix=x86_64-linux-gnu- --enable-shared --enable-linker-build-id --libexecdir=/usr/libexec --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-13-oyarai/gcc-13-13.2.0/debian/tmp-nvptx/usr,amdgcn-amdhsa=/build/gcc-13-oyarai/gcc-13-13.2.0/debian/tmp-gcn/usr --enable-offload-defaulted --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=28 Thread model: posix Supported LTO compression algorithms: zlib zstd gcc version 13.2.0 (Debian 13.2.0-4)
[Bug tree-optimization/111715] Missed optimization in FRE because of weak TBAA
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111715
--- Comment #3 from Richard Biener ---
Reduced testcase:
struct B {
struct { int len; } l;
long n;
};
struct A {
struct B elts[8];
};
static void
set_len (struct B *b, int len)
{
b->l.len = len;
}
static int
get_len (struct B *b)
{
return b->l.len;
}
int foo (struct A *a, int i, long *q)
{
set_len (>elts[i], 1);
*q = 2;
return get_len (>elts[i]);
}
with the patch we end up doing the following in FRE1. I think the path
based disambiguation is unaffected by assigning a different alias set.
int foo (struct A * a, int i, long int * q)
{
int D.2787;
- int _9;
:
MEM [(struct B *)a_3(D)].elts[i_4(D)].l.len = 1;
*q_7(D) = 2;
- _9 = MEM [(struct B *)a_3(D)].elts[i_4(D)].l.len;
- return _9;
+ return 1;
[Bug target/111677] arm64 build fails unrecognizable insn [REGRESSION]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111677 Gianfranco changed: What|Removed |Added Resolution|MOVED |--- Status|RESOLVED|UNCONFIRMED --- Comment #3 from Gianfranco --- Hello, after syncing gcc-13 with last fixes, the bug still occurs gcc-13 (13.2.0-5) unstable; urgency=medium . * Update to git 20231005 from the gcc-13 branch. - Fix PR tree-optimization/111331, PR tree-optimization/110386, PR target/21 (AArch64), PR tree-optimization/110315, PR target/111411 (AArch64), PR target/111412 (riscv), PR ada/110488, PR c++/111493, PR c++/111485, PR c++/99631, PR c++/111471, PR fortran/37336, PR fortran/111674, PR fortran/92586, PR fortran/68155, PR modula2/111510, PR libstdc++/111050, PR libstdc++/02, PR libstdc++/108046, PR libstdc++/111511, PR c++/111512, PR c++/111357. * Provide symlinks for the shared Modula-2 runtime libraries in the private gcc library directory. Closes: #1052008. * Install the static Modula-2 libraries. * Add autopkg test for Modula-2. * Don't assume that hppa64-linux-gnu has the sys/mman.h header, use the fallback for libgcov. * Update the libquadmath portions of the copyright file. Closes: #1052314. cd /<>/obj-aarch64-linux-gnu/bin/external/LibRaw-cmake && /usr/bin/c++ -DDT_HAVE_SIGNAL_TRACE -DGDK_DISABLE_DEPRECATED -DGDK_VERSION_MIN_REQUIRED=GDK_VERSION_3_24 -DGLIB_VERSION_MAX_ALLOWED=GLIB_VERSION_MIN_REQUIRED -DGLIB_VERSION_MIN_REQUIRED=GLIB_VERSION_2_56 -DGTK_DISABLE_DEPRECATED -DGTK_DISABLE_SINGLE_INCLUDES -DHAVE_CONFIG_H -DHAVE_GAME -DHAVE_GPHOTO2 -DHAVE_GRAPHICSMAGICK -DHAVE_ICU -DHAVE_IMATH -DHAVE_ISO_CODES -DHAVE_KWALLET -DHAVE_LIBEXIV2_WITH_ISOBMFF=1 -DHAVE_LIBHEIF=1 -DHAVE_LIBJXL -DHAVE_LIBRAW=1 -DHAVE_LIBSECRET -DHAVE_MAP -DHAVE_OPENCL -DHAVE_OPENEXR -DHAVE_OPENJPEG -DHAVE_OSMGPSMAP_110_OR_NEWER -DHAVE_OSMGPSMAP_NEWER_THAN_110 -DHAVE_PRINT -DHAVE_SQLITE_324_OR_NEWER -DHAVE_WEBP -DLIBRAW_NODLL -DSQLITE_CORE -DSQLITE_ENABLE_ICU -DUSE_COLORDGTK -DUSE_LUA -DUSE_ZLIB -D_RELEASE -D_XOPEN_SOURCE=700 -I/<>/obj-aarch64-linux-gnu/bin/external/LibRaw-cmake -I/<>/src/external/LibRaw-cmake -I/<>/src -I/<>/src/external/LuaAutoC -I/<>/src/external/LibRaw -isystem /<>/src/external -isystem /<>/src/external/OpenCL -isystem /usr/include/glib-2.0 -isystem /usr/lib/aarch64-linux-gnu/glib-2.0/include -isystem /usr/include/gtk-3.0 -isystem /usr/include/pango-1.0 -isystem /usr/include/harfbuzz -isystem /usr/include/freetype2 -isystem /usr/include/libpng16 -isystem /usr/include/libmount -isystem /usr/include/blkid -isystem /usr/include/fribidi -isystem /usr/include/cairo -isystem /usr/include/pixman-1 -isystem /usr/include/gdk-pixbuf-2.0 -isystem /usr/include/webp -isystem /usr/include/gio-unix-2.0 -isystem /usr/include/cloudproviders -isystem /usr/include/atk-1.0 -isystem /usr/include/at-spi2-atk/2.0 -isystem /usr/include/at-spi-2.0 -isystem /usr/include/dbus-1.0 -isystem /usr/lib/aarch64-linux-gnu/dbus-1.0/include -isystem /usr/include/libxml2 -isystem /usr/include/lensfun -isystem /usr/include/librsvg-2.0 -isystem /usr/include/json-glib-1.0 -isystem /usr/include/openjpeg-2.5 -isystem /usr/include/libsecret-1 -isystem /usr/include/GraphicsMagick -isystem /usr/include/lua5.4 -isystem /usr/include/osmgpsmap-1.0 -isystem /usr/include/libsoup-2.4 -isystem /usr/include/colord-1 -g -O2 -ffile-prefix-map=/<>=. -fstack-protector-strong -fstack-clash-protection -Wformat -Werror=format-security -mbranch-protection=standard -O3 -Wdate-time -D_FORTIFY_SOURCE=2 -Wall -Wformat -Wformat-security -Wshadow -Wtype-limits -Wvla -Wmaybe-uninitialized -Wno-unknown-pragmas -Wno-error=varargs -Wno-format-truncation -Wno-error=address-of-packed-member -fopenmp -mtune=generic -g -O3 -DNDEBUG -O3 -ffast-math -fno-finite-math-only -fexpensive-optimizations -std=c++17 -fPIC -fopenmp -w -MD -MT bin/external/LibRaw-cmake/CMakeFiles/raw_r.dir/__/LibRaw/src/write/apply_profile.cpp.o -MF CMakeFiles/raw_r.dir/__/LibRaw/src/write/apply_profile.cpp.o.d -o CMakeFiles/raw_r.dir/__/LibRaw/src/write/apply_profile.cpp.o -c /<>/src/external/LibRaw/src/write/apply_profile.cpp /<>/src/common/bilateral.c:468:6: warning: GCC does not currently support mixed size types for ‘simd’ functions 468 | void dt_bilateral_slice_to_output(const dt_bilateral_t *const b, | ^~~~ /<>/src/common/bilateral.c:420:6: warning: GCC does not currently support mixed size types for ‘simd’ functions 420 | void dt_bilateral_slice(const dt_bilateral_t *const b, | ^~ /<>/src/common/bilateral.c: In function ‘dt_bilateral_splat.simdclone.1’: /<>/src/common/bilateral.c:297:1: error: unrecognizable insn: 297 | } | ^ (insn 563 562 564 3 (set (mem/c:TF (plus:DI (reg/f:DI 31 sp) (const_int 512 [0x200])) [63
[Bug tree-optimization/111724] [Regression] Missed optimizations probably because of too early arithmetic optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111724 --- Comment #2 from Yi <652023330028 at smail dot nju.edu.cn> --- (In reply to Richard Biener from comment #1) > Yup, it's difficult. reassoc doesn't handle signed arithmetic, that's > usually the pass that optimizes association for invariant motion. Yes. This issue has the same result for 'unsigned'.
[Bug c/111734] wrong code with '-O3 -fno-inline-functions-called-once -fno-inline-small-functions -fno-omit-frame-pointer -fno-toplevel-reorder -fno-tree-fre'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111734 --- Comment #1 from CTC <19373742 at buaa dot edu.cn> --- Created attachment 56078 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56078=edit The compiler output
[Bug c/111734] New: wrong code with '-O3 -fno-inline-functions-called-once -fno-inline-small-functions -fno-omit-frame-pointer -fno-toplevel-reorder -fno-tree-fre'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111734 Bug ID: 111734 Summary: wrong code with '-O3 -fno-inline-functions-called-once -fno-inline-small-functions -fno-omit-frame-pointer -fno-toplevel-reorder -fno-tree-fre' Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: 19373742 at buaa dot edu.cn Target Milestone: --- Created attachment 56077 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56077=edit The preprocessed file *** OS and Platform: Ubuntu 20.04.4 LTS *** gcc version: $ gcc -v Using built-in specs. COLLECT_GCC=/home/ctc/gcc-releases/gcc-14/bin/gcc COLLECT_LTO_WRAPPER=/home/ctc/gcc-releases/gcc-14/libexec/gcc/x86_64-pc-linux-gnu/14.0.0/lto-wrapper Target: x86_64-pc-linux-gnu Configured with: ./configure --prefix=/home/cuisk/ctc/gcc-releases/gcc-14 --disable-multilib --enable-language=c,c++ Thread model: posix Supported LTO compression algorithms: zlib gcc version 14.0.0 20231008 (experimental) (GCC) *** Command Lines: $ /home/ctc/gcc-releases/gcc-14/bin/gcc -O3 -fno-inline-functions-called-once -fno-inline-small-functions -fno-omit-frame-pointer -fno-toplevel-reorder -fno-tree-fre -I /home/ctc/csmith/include/csmith-2.3.0/ a.c -o w $ ./w checksum = DD7E999B $ /home/ctc/gcc-releases/gcc-14/bin/gcc -I /home/ctc/csmith/include/csmith-2.3.0/ a.c -o w $ ./w checksum = A876723F
[Bug libgcc/111731] [13/14 regression] gcc_assert is hit at libgcc/unwind-dw2-fde.c#L291
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111731 Richard Biener changed: What|Removed |Added Target Milestone|--- |13.3 CC||tneumann at users dot sourceforge. ||net Keywords||wrong-code
[Bug libgcc/110956] [13/14 regression] gcc_assert is hit at gcc-13.2.0/libgcc/unwind-dw2-fde.c#L291 with some special library
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110956 --- Comment #13 from Richard Biener --- While this issue seems fixed(?), there's now a new one with the same symptom, not sure if we should dup and keep this one open?
[Bug tree-optimization/111724] [Regression] Missed optimizations probably because of too early arithmetic optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111724 Richard Biener changed: What|Removed |Added Last reconfirmed||2023-10-09 Ever confirmed|0 |1 Status|UNCONFIRMED |NEW --- Comment #1 from Richard Biener --- Yup, it's difficult. reassoc doesn't handle signed arithmetic, that's usually the pass that optimizes association for invariant motion.
[Bug target/111733] New: Emit inline SVE FSCALE instruction for ldexp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111733 Bug ID: 111733 Summary: Emit inline SVE FSCALE instruction for ldexp Product: gcc Version: 14.0 Status: UNCONFIRMED Keywords: missed-optimization Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: ktkachov at gcc dot gnu.org Target Milestone: --- Target: aarch64 Having noticed https://github.com/llvm/llvm-project/pull/67552 in LLVM GCC should be able to emit the SVE fscale instruction [1] to implement the ldexp standard function. There is already an ldexpm3 optab defined so it should be a relatively simple matter of wiring up the expander for TARGET_SVE [1] https://developer.arm.com/documentation/ddi0596/2021-12/SVE-Instructions/FSCALE--Floating-point-adjust-exponent-by-vector--predicated--?lang=en
[Bug debug/78685] -Og generates too many ""s
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78685
--- Comment #22 from Richard Biener ---
extern void abort (void);
int __attribute__((noipa)) foo ()
{
return 1;
}
int main()
{
int res = foo ();
if (res != 0)
abort ();
}
Asks for call clobbered registers associated with user variables to be
preserved around calls. In this case the value of 'res' ($eax on x86)
is no longer available when receiving SIGABRT, instead it's quickly
clobbered.
The more aggressive variant would be to force all user variables to the
stack (but then we still have to put saves around calls, in this case
it's similar to what Jakub says with uses after the call).
[Bug middle-end/111732] New: genmatch missed optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111732 Bug ID: 111732 Summary: genmatch missed optimization 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: --- For (for coss (BUILT_IN_COS BUILT_IN_COSF BUILT_IN_COSL) (for sins (BUILT_IN_SIN BUILT_IN_SINF BUILT_IN_SINL) (simplify (abs (sins (coss @0))) @0))) the cross product could be code generated more efficiently when we'd delay for substitution but we don't, because it's only implemented for (match ...) and not (simplify ...). Specifically handling ordering correctly is tricky (match is unordered). My original idea was to delay for lowering to decision tree insertion time (split upon a "conflict" with another pattern).
[Bug tree-optimization/98138] BB vect fail to SLP one case
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98138 --- Comment #14 from Richard Biener --- Btw, previous work is at refs/users/rguenth/heads/load-perm
[Bug target/88558] Inline lrint, lrintf
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88558 HaoChen Gui changed: What|Removed |Added CC||guihaoc at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |guihaoc at gcc dot gnu.org Resolution|--- |FIXED Status|UNCONFIRMED |RESOLVED --- Comment #3 from HaoChen Gui --- fixed.
[Bug target/88558] Inline lrint, lrintf
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88558 --- Comment #1 from CVS Commits --- The master branch has been updated by HaoChen Gui : https://gcc.gnu.org/g:5cbe235de6d5c2a04a3116c6b6e63a0e4b8da304 commit r14-4484-g5cbe235de6d5c2a04a3116c6b6e63a0e4b8da304 Author: Haochen Gui Date: Mon Oct 9 14:33:23 2023 +0800 rs6000: enable SImode in FP register on P7 gcc/ PR target/88558 * config/rs6000/rs6000.cc (rs6000_hard_regno_mode_ok_uncached): Enable SImode on FP registers for P7. * config/rs6000/rs6000.md (*movsi_internal1): Add fmr for SImode move between FP registers. Set attribute isa of stfiwx to "*" and attribute of stxsiwx to "p7".
[Bug target/106769] PPCLE: vec_extract(vector unsigned int) unnecessary rldicl after mfvsrwz
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106769 --- Comment #6 from CVS Commits --- The master branch has been updated by HaoChen Gui : https://gcc.gnu.org/g:c1e474785859c9630fcae19c8d2d606f5642c636 commit r14-4485-gc1e474785859c9630fcae19c8d2d606f5642c636 Author: Haochen Gui Date: Mon Oct 9 14:34:46 2023 +0800 rs6000: support 32bit inline lrint gcc/ PR target/88558 * config/rs6000/rs6000.md (lrintdi2): Remove TARGET_FPRND from insn condition. (lrintsi2): New insn pattern for 32bit lrint. gcc/testsuite/ PR target/106769 * gcc.target/powerpc/pr88558.h: New. * gcc.target/powerpc/pr88558-p7.c: New. * gcc.target/powerpc/pr88558-p8.c: New.
[Bug target/88558] Inline lrint, lrintf
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88558 --- Comment #2 from CVS Commits --- The master branch has been updated by HaoChen Gui : https://gcc.gnu.org/g:c1e474785859c9630fcae19c8d2d606f5642c636 commit r14-4485-gc1e474785859c9630fcae19c8d2d606f5642c636 Author: Haochen Gui Date: Mon Oct 9 14:34:46 2023 +0800 rs6000: support 32bit inline lrint gcc/ PR target/88558 * config/rs6000/rs6000.md (lrintdi2): Remove TARGET_FPRND from insn condition. (lrintsi2): New insn pattern for 32bit lrint. gcc/testsuite/ PR target/106769 * gcc.target/powerpc/pr88558.h: New. * gcc.target/powerpc/pr88558-p7.c: New. * gcc.target/powerpc/pr88558-p8.c: New.
[Bug tree-optimization/99395] s116 benchmark of TSVC is vectorized by clang and not by gcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99395 Richard Biener changed: What|Removed |Added Last reconfirmed|2021-03-05 00:00:00 |2023-10-9 --- Comment #7 from Richard Biener --- (In reply to JuzheZhong from comment #6) > Hi, Richi. > > Recently, I am evaluating TSVC performance of GCC: > > I found both RISC-V and aarch64 can SLP vectorize it: > > https://godbolt.org/z/ssvTxxjeT > > Both GCC-13 and trunk GCC can SLP it like LLVM (GCC-12 failed) but with > -fno-vect-cost-model. > > I suspect we should adjust Vector COST model (I don't think we should ajust > cost > model in target backend since LLVM by default vectorize such case). We are only vectorizing part of the scalar code. The CSE issue still exists, so is the resulting loop analysis issues.
