[Bug fortran/109209] [13 regression] erroneous error on assignment of alloctables
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109209 Paul Thomas changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #18 from Paul Thomas --- Fixed! Thanks for the report. Paul
[Bug fortran/109206] [13 Regression] gcc/fortran/class.cc:2768:14: runtime error: load of value 4139789424, which is not a valid value for type 'bt' since r13-6747-gd7caf313525a46
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109206 Paul Thomas changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #3 from Paul Thomas --- Fixed! Thanks for the report. Paul
[Bug d/109221] std.math.floor, core.math.ldexp, std.math.poly poor inlining
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109221 Hongtao.liu changed: What|Removed |Added CC||crazylht at gmail dot com --- Comment #5 from Hongtao.liu --- (In reply to Andrew Pinski from comment #4) > With -ffast-math -mfpmath=387,sse (or -mavx512f instead of -mfpmath=387 as > there is a avx512f instruction too) added, ldexp gets inlined. Note, vscaless accept a float32 operand for exp which is int32 in ldexpf, there maybe some precision loss to convert an int32 to float32, that's why Ofast is needed here.
[Bug c++/109227] New: coroutines: ICE in tree check: expected record_type or union_type or qual_union_type, have array_type in build_special_member_call, at cp/call.cc:11067
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109227
Bug ID: 109227
Summary: coroutines: ICE in tree check: expected record_type or
union_type or qual_union_type, have array_type in
build_special_member_call, at cp/call.cc:11067
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: marxin at gcc dot gnu.org
CC: avi at scylladb dot com, iains at gcc dot gnu.org, jason at
gcc dot gnu.org
Target Milestone: ---
It's probably similar to PR98056 and it's reduced from ScyllaDB:
$ g++ bad.cc -c -std=gnu++20
bad.cc: In member function ‘future, utils::exception_container_throw_policy> >
cql3::statements::indexed_table_select_statement::do_execute_base_query(cql3::query_processor&,
std::vector&&, service::query_state&, const
{anonymous}::query_options&, gc_clock::time_point, lw_shared_ptr) const’:
bad.cc:273:1: warning: no return statement in function returning non-void
[-Wreturn-type]
273 | }
| ^
bad.cc: In instantiation of
‘cql3::statements::indexed_table_select_statement::do_execute_base_query(cql3::query_processor&,
std::vector&&, service::query_state&, const
{anonymous}::query_options&, gc_clock::time_point, lw_shared_ptr) const:: [with auto:1 =
cql3::statements::primary_key]’:
bad.cc:39:11: required from ‘void std::__invoke(_Callable, _Args ...) [with
_Callable =
cql3::statements::indexed_table_select_statement::do_execute_base_query(cql3::query_processor&,
std::vector&&, service::query_state&, const
{anonymous}::query_options&, gc_clock::time_point, lw_shared_ptr) const::; _Args =
{cql3::statements::primary_key}]’
bad.cc:67:11: required from ‘void std::invoke(_Callable, _Args ...) [with
_Callable =
cql3::statements::indexed_table_select_statement::do_execute_base_query(cql3::query_processor&,
std::vector&&, service::query_state&, const
{anonymous}::query_options&, gc_clock::time_point, lw_shared_ptr) const::; _Args =
{cql3::statements::primary_key}]’
bad.cc:158:16: required from ‘auto coroutine::lambda::operator()(Args
...) [with Args = {cql3::statements::primary_key}; Func =
cql3::statements::indexed_table_select_statement::do_execute_base_query(cql3::query_processor&,
std::vector&&, service::query_state&, const
{anonymous}::query_options&, gc_clock::time_point, lw_shared_ptr) const::]’
bad.cc:10:39: required from ‘struct std::__result_of_impl&&, service::query_state&, const
{anonymous}::query_options&, gc_clock::time_point, lw_shared_ptr) const:: >,
cql3::statements::primary_key>’
bad.cc:16:8: required from ‘struct
std::__invoke_result&&, service::query_state&, const
{anonymous}::query_options&, gc_clock::time_point, lw_shared_ptr) const:: >,
cql3::statements::primary_key>’
bad.cc:83:56: required from ‘void futurize_invoke(Func, Args ...) [with Func
=
coroutine::lambda&&, service::query_state&, const
{anonymous}::query_options&, gc_clock::time_point, lw_shared_ptr) const:: >; Args =
{cql3::statements::primary_key}]’
bad.cc:240:18: required from ‘void utils::result_map_reduce(Iterator,
Iterator, Mapper, Reducer) [with Iterator =
__normal_iterator; Mapper =
coroutine::lambda&&, service::query_state&, const
{anonymous}::query_options&, gc_clock::time_point, lw_shared_ptr) const:: >; Reducer = void
(*)()]’
bad.cc:259:27: required from here
bad.cc:271:11: internal compiler error: tree check: expected record_type or
union_type or qual_union_type, have array_type in build_special_member_call, at
cp/call.cc:11067
271 | }),
| ^
0x87916a tree_check_failed(tree_node const*, char const*, int, char const*,
...)
/home/marxin/Programming/gcc/gcc/tree.cc:8881
0x96c34b tree_check3(tree_node*, char const*, int, char const*, tree_code,
tree_code, tree_code)
/home/marxin/Programming/gcc/gcc/tree.h:3580
0x95f539 build_special_member_call(tree_node*, tree_node*, vec**, tree_node*, int, int)
/home/marxin/Programming/gcc/gcc/cp/call.cc:11067
0x9c16a7 maybe_promote_temps
/home/marxin/Programming/gcc/gcc/cp/coroutines.cc:3146
0x9c16a7 await_statement_walker
/home/marxin/Programming/gcc/gcc/cp/coroutines.cc:3757
0x149b05d walk_tree_1(tree_node**, tree_node* (*)(tree_node**, int*, void*),
void*, hash_set >*,
tree_node* (*)(tree_node**, int*, tree_node* (*)(tree_node**, int*, void*),
void*, hash_set >*))
/home/marxin/Programming/gcc/gcc/tree.cc:11327
0x9c1198 await_statement_walker
/home/marxin/Programming/gcc/gcc/cp/coroutines.cc:3428
0x149b05d walk_tree_1(tree_node**, tree_node* (*)(tree_node**, int*, void*),
void*, hash_set >*,
tree_node* (*)(tree_node**, int*, tree_node* (*)(tree_node**, int*, void*),
void*, hash_set >*))
/home/marxin/Programming/gcc/gcc/tree.cc:11327
0x9c129c await_statement_walker
/home/marxin/Programming/gcc/gcc/cp/coroutines.cc:3417
0x149b0
[Bug c++/109227] coroutines: ICE in tree check: expected record_type or union_type or qual_union_type, have array_type in build_special_member_call, at cp/call.cc:11067
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109227 Martin Liška changed: What|Removed |Added See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=98056 Ever confirmed|0 |1 Status|UNCONFIRMED |NEW Last reconfirmed||2023-03-21
[Bug tree-optimization/109215] [13 Regression] wrong warning: array subscript 0 is outside the bounds of an interior zero-length array ‘struct lock_class_key[3]’
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109215 Richard Biener changed: What|Removed |Added Priority|P3 |P1
[Bug fortran/109216] Wrong behaviour explained in -fno-underscoring documentation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109216 --- Comment #3 from Richard Biener --- Fixed?
[Bug driver/109217] failure statically linking shared lib
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109217 Richard Biener changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever confirmed|0 |1 Component|target |driver Last reconfirmed||2023-03-21 --- Comment #3 from Richard Biener --- -static-pie is now marked as the negative of -shared, so it works with that (the later cancelling out the earlier). It isn't handled that way for -static vs. -shared, not sure if we can use Negative() with multiple options.
[Bug c++/109227] coroutines: ICE in tree check: expected record_type or union_type or qual_union_type, have array_type in build_special_member_call, at cp/call.cc:11067
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109227 --- Comment #1 from Avi Kivity --- Did you forget to attach bad.cc?
[Bug tree-optimization/109219] [12/13 Regression] csmith: ice in vect_slp_analyze_node_operations_1, at tree-vect-slp.cc:5954
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109219 Richard Biener changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org Priority|P3 |P2 Status|NEW |ASSIGNED --- Comment #2 from Richard Biener --- I will have a look - the representative looks out-of sync: t.c:4:1: note: node 0x41d6f00 (max_nunits=8, refcnt=1) vector(8) unsigned short t.c:4:1: note: op template: _68 = _70 + 65535; t.c:4:1: note: stmt 0 patt_20 = _68 - patt_23; t.c:4:1: note: stmt 1 patt_77 = _9 - patt_101; t.c:4:1: note: children 0x41d7340 0x41d7098
[Bug driver/109217] failure statically linking shared lib
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109217 --- Comment #4 from Stas Sergeev --- (In reply to Richard Biener from comment #3) > -static-pie is now marked as the negative of -shared, so it works with that > (the later cancelling out the earlier). It isn't handled that way for > -static vs. -shared, not sure if we can use Negative() with multiple options. So could you please suggest the exact command line that works? I tried: $ LC_ALL=C cc -Wall -o libmain.so main.c -shared -static-pie /usr/bin/ld: /usr/lib/gcc/x86_64-linux-gnu/12/../../../x86_64-linux-gnu/rcrt1.o: in function `_start': (.text+0x1b): undefined reference to `main' collect2: error: ld returned 1 exit status So obviously -static-pie just indeed, as you say, cancels -shared. Is there any -static-solib or alike, to produce the solib at the end?
[Bug tree-optimization/109170] [13 Regression] New glibc warning: open_catalog.c:86:16: error: pointer ‘old_buf’ may be used after ‘realloc’ [-Werror=use-after-free] since r13-6707-g0a07bfad12530bca
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109170 Richard Biener changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #6 from Richard Biener --- Fixed.
[Bug tree-optimization/109170] [13 Regression] New glibc warning: open_catalog.c:86:16: error: pointer ‘old_buf’ may be used after ‘realloc’ [-Werror=use-after-free] since r13-6707-g0a07bfad12530bca
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109170 --- Comment #5 from CVS Commits --- The master branch has been updated by Richard Biener : https://gcc.gnu.org/g:5f413dc41ee4f8bc3a0fc295f98b75dceae52fa8 commit r13-6773-g5f413dc41ee4f8bc3a0fc295f98b75dceae52fa8 Author: Richard Biener Date: Fri Mar 17 13:14:49 2023 +0100 tree-optimization/109170 - bogus use-after-free with __builtin_expect The following adds a missing range-op for __builtin_expect which helps -Wuse-after-free to detect the case a realloc original pointer is used when the result was NULL. The implementation should handle all argument one pass-through builtins we handle in the fnspec machinery, but that's defered to GCC 14. The gcc.dg/tree-ssa/ssa-lim-21.c testcase needs adjustment because for (int j = 0; j < m; j++) if (__builtin_expect (m, 0)) for (int i = 0; i < m; i++) is now correctly optimized to a unconditional jump by EVRP - m cannot be zero when the outer loop is entered. I've adjusted the outer loop to iterate 'n' times which makes us apply store-motion to 'count' and 'q->data1' but only out of the inner loop and as expected not apply store motion to 'q->data' at all. The gcc.dg/predict-20.c testcase relies on broken behavior of profile estimation when trying to handle __builtin_expect values flowing into PHI nodes. I have opened PR109210 and removed the expected matching from the testcase. PR tree-optimization/109170 * gimple-range-op.cc (cfn_pass_through_arg1): New. (gimple_range_op_handler::maybe_builtin_call): Handle __builtin_expect via cfn_pass_through_arg1. * gcc.dg/Wuse-after-free-pr109170.c: New testcase. * gcc.dg/tree-ssa/ssa-lim-21.c: Adjust. * gcc.dg/predict-20.c: Likewise.
[Bug middle-end/104075] bogus/missing -Wuse-after-free
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104075 Bug 104075 depends on bug 109170, which changed state. Bug 109170 Summary: [13 Regression] New glibc warning: open_catalog.c:86:16: error: pointer ‘old_buf’ may be used after ‘realloc’ [-Werror=use-after-free] since r13-6707-g0a07bfad12530bca https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109170 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED
[Bug c++/109227] coroutines: ICE in tree check: expected record_type or union_type or qual_union_type, have array_type in build_special_member_call, at cp/call.cc:11067
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109227 --- Comment #2 from Martin Liška --- Created attachment 54717 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54717&action=edit test-case
[Bug tree-optimization/109213] [13 Regression] -Os generates significantly more code since r13-723
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109213 Jakub Jelinek changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2023-03-21 CC||jakub at gcc dot gnu.org Ever confirmed|0 |1 Keywords|needs-bisection | Summary|[13 Regression] -Os |[13 Regression] -Os |generates significantly |generates significantly |more code |more code since r13-723 --- Comment #5 from Jakub Jelinek --- This changed with r13-723-g1adf11822bd48f4d65156b7642514630c08c4d00
[Bug c/109228] New: warning: implicit declaration of function '__riscv_vlenb'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109228
Bug ID: 109228
Summary: warning: implicit declaration of function
'__riscv_vlenb'
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: malat at debian dot org
Target Milestone: ---
On riscv64 I am getting the following error with gcc-13:
% cat t.c
#include
unsigned long test_vlenb(void) {
return __riscv_vlenb();
}
Leads to:
% LIBRARY_PATH=/usr/lib/gcc-snapshot/lib /usr/lib/gcc-snapshot/bin/gcc
-march=rv64gcv1p0 -c -v t.c
Using built-in specs.
COLLECT_GCC=/usr/lib/gcc-snapshot/bin/gcc
Target: riscv64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian 20230315-1'
--with-bugurl=file:///usr/share/doc/gcc-snapshot/README.Bugs
--enable-languages=c,ada,c++,go,d,fortran,objc,obj-c++,m2,rust
--prefix=/usr/lib/gcc-snapshot --with-gcc-major-version-only --program-prefix=
--enable-shared --enable-linker-build-id --disable-nls --enable-bootstrap
--enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes
--with-default-libstdcxx-abi=new --enable-gnu-unique-object --disable-libitm
--disable-libquadmath --disable-libquadmath-support --enable-plugin
--with-system-zlib --enable-libphobos-checking=release
--with-target-system-zlib=auto --enable-objc-gc=auto --enable-multiarch
--disable-werror --disable-multilib --with-arch=rv64gc --with-abi=lp64d
--enable-checking=yes --build=riscv64-linux-gnu --host=riscv64-linux-gnu
--target=riscv64-linux-gnu --with-build-config=bootstrap-lto-lean
--enable-link-serialization=2
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 13.0.1 20230315 (experimental) [master r13-6680-ga9ae16db8cb]
(Debian 20230315-1)
COLLECT_GCC_OPTIONS='-march=rv64gcv1p0' '-c' '-v' '-mabi=lp64d'
'-misa-spec=20191213'
'-march=rv64imafdc_v1p0_zicsr_zifencei_zve32f_zve32x_zve64d_zve64f_zve64x_zvl128b_zvl32b_zvl64b'
/usr/lib/gcc-snapshot/libexec/gcc/riscv64-linux-gnu/13/cc1 -quiet -v
-imultilib . -imultiarch riscv64-linux-gnu t.c -quiet -dumpbase t.c
-dumpbase-ext .c -march=rv64gcv1p0 -mabi=lp64d -misa-spec=20191213
-march=rv64imafdc_v1p0_zicsr_zifencei_zve32f_zve32x_zve64d_zve64f_zve64x_zvl128b_zvl32b_zvl64b
-version -o /tmp/ccJgYXea.s
GNU C17 (Debian 20230315-1) version 13.0.1 20230315 (experimental) [master
r13-6680-ga9ae16db8cb] (riscv64-linux-gnu)
compiled by GNU C version 13.0.1 20230315 (experimental) [master
r13-6680-ga9ae16db8cb], GMP version 6.2.1, MPFR version 4.2.0, MPC version
1.3.1, isl version isl-0.25-GMP
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
ignoring nonexistent directory "/usr/local/include/riscv64-linux-gnu"
ignoring nonexistent directory
"/usr/lib/gcc-snapshot/lib/gcc/riscv64-linux-gnu/13/include-fixed/riscv64-linux-gnu"
ignoring nonexistent directory
"/usr/lib/gcc-snapshot/lib/gcc/riscv64-linux-gnu/13/include-fixed"
ignoring nonexistent directory
"/usr/lib/gcc-snapshot/lib/gcc/riscv64-linux-gnu/13/../../../../riscv64-linux-gnu/include"
#include "..." search starts here:
#include <...> search starts here:
/usr/lib/gcc-snapshot/lib/gcc/riscv64-linux-gnu/13/include
/usr/local/include
/usr/lib/gcc-snapshot/include
/usr/include/riscv64-linux-gnu
/usr/include
End of search list.
Compiler executable checksum: 81700f2a313a464c1070ea0a35a4372b
t.c: In function 'test_vlenb':
t.c:4:10: warning: implicit declaration of function '__riscv_vlenb'; did you
mean '__riscv_vlm_v_b1'? [-Wimplicit-function-declaration]
4 | return __riscv_vlenb();
| ^
| __riscv_vlm_v_b1
COLLECT_GCC_OPTIONS='-march=rv64gcv1p0' '-c' '-v' '-mabi=lp64d'
'-misa-spec=20191213'
'-march=rv64imafdc_v1p0_zicsr_zifencei_zve32f_zve32x_zve64d_zve64f_zve64x_zvl128b_zvl32b_zvl64b'
as -v --traditional-format -march=rv64gcv1p0
-march=rv64imafdc_v1p0_zicsr_zifencei_zve32f_zve32x_zve64d_zve64f_zve64x_zvl128b_zvl32b_zvl64b
-mabi=lp64d -misa-spec=20191213 -o t.o /tmp/ccJgYXea.s
GNU assembler version 2.40 (riscv64-linux-gnu) using BFD version (GNU Binutils
for Debian) 2.40
COMPILER_PATH=/usr/lib/gcc-snapshot/libexec/gcc/riscv64-linux-gnu/13/:/usr/lib/gcc-snapshot/libexec/gcc/riscv64-linux-gnu/13/:/usr/lib/gcc-snapshot/libexec/gcc/riscv64-linux-gnu/:/usr/lib/gcc-snapshot/lib/gcc/riscv64-linux-gnu/13/:/usr/lib/gcc-snapshot/lib/gcc/riscv64-linux-gnu/
LIBRARY_PATH=/usr/lib/gcc-snapshot/lib/:/usr/lib/gcc-snapshot/lib/gcc/riscv64-linux-gnu/13/:/lib/riscv64-linux-gnu/:/lib/:/usr/lib/riscv64-linux-gnu/:/usr/lib/
COLLECT_GCC_OPTIONS='-march=rv64gcv1p0' '-c' '-v' '-mabi=lp64d'
'-misa-spec=20191213'
'-march=rv64imafdc_v1p0_zicsr_zifencei_zve32f_zve32x_zve64d_zve64f_zve64x_zvl128b_zvl32b_zvl64b'
[Bug libstdc++/109229] New: std::exclusive_scan narrows to initial value
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109229
Bug ID: 109229
Summary: std::exclusive_scan narrows to initial value
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: gnu-bugzilla at ribizel dot de
Target Milestone: ---
Take the following piece of code:
```
#include
#include
#include
#include
#include
int main() {
std::vector vec{1LL << 32, 0};
std::exclusive_scan(vec.begin(), vec.end(), vec.begin(), 0);
std::cout << vec[0] << '\n';
std::cout << vec[1] << '\n';
}
```
I would expect this to output 0 and 1LL<<32, but it outputs 0, 0, because T in
std::exclusive_scan is deduced as int, which is the computational type that
will be used in exclusive_scan. Not sure if this is a library or standard
defect, but I think this is pretty bug-prone otherwise. Other standard library
implementations have the same issue, see
https://github.com/NVIDIA/thrust/issues/1896 and
https://github.com/llvm/llvm-project/issues/61575.
[Bug tree-optimization/109176] [13 Regression] internal compiler error: in to_constant, at poly-int.h:504
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109176
--- Comment #6 from Jakub Jelinek ---
Reduced testcase:
#pragma GCC aarch64 "arm_sve.h"
svbool_t
foo (svint8_t a, svint8_t b, svbool_t c)
{
svbool_t d = svcmplt_s8 (svptrue_pat_b8 (SV_ALL), a, b);
return svsel_b (d, c, d);
}
[Bug target/55295] [SH] Add support for fipr instruction
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55295 Luke Benstead changed: What|Removed |Added CC||kazade at gmail dot com --- Comment #14 from Luke Benstead --- Was there a particular reason why this patch wasn't merged? It would be really cool to see GCC generate fipr like it does fsrra etc. Is there anything I can do to help?
[Bug target/55295] [SH] Add support for fipr instruction
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55295 --- Comment #15 from Oleg Endo --- It's been too long since I've looked into it. Maybe some middle-end parts got more suitable over the time, but it was difficult to make it generate the fipr instruction automatically due to the reasons stated above.
[Bug tree-optimization/109176] [13 Regression] internal compiler error: in to_constant, at poly-int.h:504
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109176
--- Comment #7 from Richard Biener ---
(In reply to Jakub Jelinek from comment #5)
> Before veclower2 we had/have
> _7 = ba_5(D) < a_6(D);
> _8 = svnand_b_z (_7, _7, _7);
> _9 = VEC_COND_EXPR <_7, _8, _7>;
> where _7/_8/_9 are all __SVBool_t.
> Before the r11-1445 changes, the VEC_COND_EXPR would be left untouched,
> because
> expand_vec_cond_expr_p (__SVBool_t, __SVBool_t, SSA_NAME) is true on aarch64.
> Now it doesn't, because _7 def_stmt is a comparison, and so
> expand_vec_cond_expr_p (__SVBool_t, VNx16QI, LT_EXPR).
> --- gcc/tree-vect-generic.cc.jj 2023-03-12 22:36:06.356178068 +0100
> +++ gcc/tree-vect-generic.cc 2023-03-20 16:31:03.321831866 +0100
> @@ -1063,6 +1063,12 @@ expand_vector_condition (gimple_stmt_ite
>return true;
> }
>
> + if (!TYPE_VECTOR_SUBPARTS (type).is_constant ()
> + && VECTOR_BOOLEAN_TYPE_P (type)
> + && VECTOR_BOOLEAN_TYPE_P (TREE_TYPE (a))
> + && expand_vec_cond_expr_p (type, TREE_TYPE (a), TREE_CODE (a)))
> +return true;
> +
>/* Handle vector boolean types with bitmasks. If there is a comparison
> and we can expand the comparison into the vector boolean bitmask,
> or otherwise if it is compatible with type, we can transform
> basically restores the behaviour here for the SVE boolean types and makes it
> compile.
> Because otherwise, unless this would be solvable by the AVX512 "Handle
> vector boolean types with bitmasks." code the non-constant vector elts cases
> will always ICE in the following code, int nunits =
> nunits_for_known_piecewise_op (type);
> requires constant TYPE_VECTOR_SUBPARTS and the code really isn't prepared to
> handle anything non-constant.
OK, so expand_vec_cond_expr_p does
bool
expand_vec_cond_expr_p (tree value_type, tree cmp_op_type, enum tree_code code)
{
machine_mode value_mode = TYPE_MODE (value_type);
machine_mode cmp_op_mode = TYPE_MODE (cmp_op_type);
if (VECTOR_BOOLEAN_TYPE_P (cmp_op_type)
&& get_vcond_mask_icode (TYPE_MODE (value_type),
TYPE_MODE (cmp_op_type)) != CODE_FOR_nothing)
return true;
first. I think vector lowering should always check the original 'a'
if it is a mask, like with the following, there's no good reason to
special-case this just for VL vectors
diff --git a/gcc/tree-vect-generic.cc b/gcc/tree-vect-generic.cc
index 519a824ec72..c957c9aa7a9 100644
--- a/gcc/tree-vect-generic.cc
+++ b/gcc/tree-vect-generic.cc
@@ -1040,6 +1040,10 @@ expand_vector_condition (gimple_stmt_iterator *gsi,
bitmap dce_ssa_names)
tree_code code = TREE_CODE (a);
gassign *assign = NULL;
+ if (VECTOR_BOOLEAN_TYPE_P (TREE_TYPE (a))
+ && expand_vec_cond_expr_p (type, TREE_TYPE (a), ERROR_MARK))
+return true;
+
if (code == SSA_NAME)
{
assign = dyn_cast (SSA_NAME_DEF_STMT (a));
@@ -1053,14 +1057,14 @@ expand_vector_condition (gimple_stmt_iterator *gsi,
bitmap dce_ssa_names)
comp_inner_type = TREE_TYPE (TREE_TYPE (a1));
comp_width = vector_element_bits_tree (TREE_TYPE (a1));
}
-}
- if (expand_vec_cond_expr_p (type, TREE_TYPE (a1), code)
- || (integer_all_onesp (b) && integer_zerop (c)
- && expand_vec_cmp_expr_p (type, TREE_TYPE (a1), code)))
-{
- gcc_assert (TREE_CODE (a) == SSA_NAME || TREE_CODE (a) == VECTOR_CST);
- return true;
+ if (expand_vec_cond_expr_p (type, TREE_TYPE (a1), code)
+ || (integer_all_onesp (b) && integer_zerop (c)
+ && expand_vec_cmp_expr_p (type, TREE_TYPE (a1), code)))
+ {
+ gcc_assert (TREE_CODE (a) == SSA_NAME || TREE_CODE (a) ==
VECTOR_CST);
+ return true;
+ }
}
/* Handle vector boolean types with bitmasks. If there is a comparison
[Bug tree-optimization/109215] [13 Regression] wrong warning: array subscript 0 is outside the bounds of an interior zero-length array ‘struct lock_class_key[3]’
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109215
--- Comment #7 from CVS Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:03041e0361cbdd7f541f2f39060759aad866ed58
commit r13-6782-g03041e0361cbdd7f541f2f39060759aad866ed58
Author: Jakub Jelinek
Date: Tue Mar 21 11:06:20 2023 +0100
tree: Fix up component_ref_sam_type handling of arrays of 0 sized elements
[PR109215]
Our documentation sadly talks about elt_type arr[0]; as zero-length arrays,
not arrays with zero elements. Unfortunately, those aren't the only arrays
which can have zero size, the same size can be also result of zero-length
element, like in GNU C struct whatever {} or in GNU C/C++ if the element
type is [0] array or combination thereof (dunno if Ada doesn't allow
something similar too). One can't do much with them, taking address of
their elements, (no-op) copying of the elements in and out. But they
behave differently from arr[0] arrays e.g. in that using non-zero indexes
in them (as long as they are within bounds as for normal arrays) is valid.
I think this naming inaccuracy resulted in Martin designing
special_array_member in an inconsistent way, mixing size zero array members
with array members of one or two or more elements and then using the
size zero interchangeably with zero elements.
The following patch changes that (but doesn't do any
documentation/diagnostics renaming, as this is really a corner case),
such that int_0/trail_0 for consistency is just about [0] arrays
plus [] for the latter, not one or more zero sized elements case.
The testcase has one xfailed case for where perhaps in later GCC versions
we could add extra code to handle it, for some reason we don't diagnose
out of bounds accesses for the zero sized elements cases. It will be
harder because e.g. FRE will canonicalize &var.fld[0] and &var.fld[10]
to just one of them because they are provably the same address.
But the important thing is to fix this regression (where we warn on
completely valid code in the Linux kernel). Anyway, for further work
on this we don't really need any extra help from special_array_member,
all code can just check integer_zerop (TYPE_SIZE_UNIT (TREE_TYPE (type))),
it doesn't depend on the position of the members etc.
2023-03-21 Jakub Jelinek
PR tree-optimization/109215
* tree.h (enum special_array_member): Adjust comments for int_0
and trail_0.
* tree.cc (component_ref_sam_type): Clear zero_elts if memtype
has zero sized element type and the array has variable number of
elements or constant one or more elements.
(component_ref_size): Adjust comments, formatting fix.
* gcc.dg/Wzero-length-array-bounds-3.c: New test.
[Bug tree-optimization/109215] [13 Regression] wrong warning: array subscript 0 is outside the bounds of an interior zero-length array ‘struct lock_class_key[3]’
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109215 Jakub Jelinek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #8 from Jakub Jelinek --- Fixed.
[Bug fortran/109206] [13 Regression] gcc/fortran/class.cc:2768:14: runtime error: load of value 4139789424, which is not a valid value for type 'bt' since r13-6747-gd7caf313525a46
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109206 --- Comment #4 from Martin Liška --- > This was plain carelessness on my part. Heh, I would call it a natural fallout of software development. Anyway, thanks for the fix.
[Bug c++/43144] Possible ADL bug in GCC 4.4.1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=43144 Jonathan Wakely changed: What|Removed |Added Resolution|--- |WORKSFORME Status|UNCONFIRMED |RESOLVED --- Comment #3 from Jonathan Wakely --- Closing then, thanks.
[Bug ada/109212] Ada "for" expression generates gcc error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109212 --- Comment #3 from Vishaal Awasthi --- Thanks for the quick check. Do I need to do anything on this bug report to close it?
[Bug fortran/109216] Wrong behaviour explained in -fno-underscoring documentation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109216 Raoul Hidalgo Charman changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #4 from Raoul Hidalgo Charman --- Yep, thanks for the quick response!
[Bug libstdc++/109229] std::exclusive_scan narrows to initial value
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109229 --- Comment #1 from Jonathan Wakely --- This is how all standard algorithms that take an initial value work.
[Bug c/109228] warning: implicit declaration of function '__riscv_vlenb'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109228 Kito Cheng changed: What|Removed |Added CC||kito at gcc dot gnu.org --- Comment #1 from Kito Cheng --- Thanks for report! we definitely missed that...
[Bug tree-optimization/109176] [13 Regression] internal compiler error: in to_constant, at poly-int.h:504
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109176
--- Comment #8 from Jakub Jelinek ---
(In reply to Richard Biener from comment #7)
> --- a/gcc/tree-vect-generic.cc
> +++ b/gcc/tree-vect-generic.cc
> @@ -1040,6 +1040,10 @@ expand_vector_condition (gimple_stmt_iterator *gsi,
> bitmap dce_ssa_names)
>tree_code code = TREE_CODE (a);
>gassign *assign = NULL;
>
> + if (VECTOR_BOOLEAN_TYPE_P (TREE_TYPE (a))
> + && expand_vec_cond_expr_p (type, TREE_TYPE (a), ERROR_MARK))
> +return true;
> +
>if (code == SSA_NAME)
> {
>assign = dyn_cast (SSA_NAME_DEF_STMT (a));
Ok, the above LGTM.
> @@ -1053,14 +1057,14 @@ expand_vector_condition (gimple_stmt_iterator *gsi,
> bitmap dce_ssa_names)
> comp_inner_type = TREE_TYPE (TREE_TYPE (a1));
> comp_width = vector_element_bits_tree (TREE_TYPE (a1));
> }
> -}
>
> - if (expand_vec_cond_expr_p (type, TREE_TYPE (a1), code)
> - || (integer_all_onesp (b) && integer_zerop (c)
> - && expand_vec_cmp_expr_p (type, TREE_TYPE (a1), code)))
> -{
> - gcc_assert (TREE_CODE (a) == SSA_NAME || TREE_CODE (a) == VECTOR_CST);
> - return true;
> + if (expand_vec_cond_expr_p (type, TREE_TYPE (a1), code)
> + || (integer_all_onesp (b) && integer_zerop (c)
> + && expand_vec_cmp_expr_p (type, TREE_TYPE (a1), code)))
> + {
> + gcc_assert (TREE_CODE (a) == SSA_NAME || TREE_CODE (a) ==
> VECTOR_CST);
> + return true;
> + }
> }
>
>/* Handle vector boolean types with bitmasks. If there is a comparison
Is the second hunk because the verifier now requires that first argument of
VEC_COND_EXPR is always is_gimple_val and so it will be never tcc_comparison?
I don't understand the assert after the change though, this is in code guarded
with
code == SSA_NAME, so TREE_CODE (a) == SSA_NAME is always true.
If TREE_CODE (a) == VECTOR_CST, then it could return true without lowering only
in the
first hunk.
Are you going to test the patch (with the assert removed?)?
Not really sure about the testcase, perhaps the #c6 one in
gcc.target/aarch64/sve/pr109176.c with
/* PR tree-optimization/109176 */
/* { dg-do compile } */
/* { dg-options "-O2 -march=armv8.2-a+sve" } */
at the start added? Or #pragma GCC aarch64 "arm_sve.h" line replaced with
#include as well?
[Bug modula2/109125] [13 regression] SIGBUS in m2pim_ldtoa_ldtoa
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109125 --- Comment #11 from ro at CeBiTec dot Uni-Bielefeld.DE --- > --- Comment #10 from CVS Commits --- > The master branch has been updated by Gaius Mulley : > > https://gcc.gnu.org/g:f231bca93ca92f6fd55de6fbe4bf8935f9ec558a > > commit r13-6719-gf231bca93ca92f6fd55de6fbe4bf8935f9ec558a > Author: Gaius Mulley > Date: Thu Mar 16 20:41:20 2023 + > > PR modula2/109125 SIGBUS in m2pim_ldtoa_ldtoa Just to confirm: this patch fixes the last of the SIGBUS failures. Thanks!
[Bug tree-optimization/109192] [13 Regression] timeout with -O3 since r13-5579
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109192 --- Comment #8 from Richard Biener --- (In reply to Andrew Macleod from comment #7) > Created attachment 54716 [details] > proposed patch > > This is due to the latter part of the specified patch. We normally > terminate outgoing range calculations once the LHS has reverted to VARYING > as we won't learn anything new. > > The original patch modified this such that if there was a relation present, > we continued calculating as the relation may provide new information, as per > the original PR. > > The problem exposed in this PR is that the presence of a relation doesn't > mean that relation can actually affect the range. This PR shows many > relations, none of which are relevant, and with the quadratic nature of the > path query, it makes things quite bad. > > The attached patch is in testing. It adds a check to determine if the > relation can affect the outgoing range or not by checking if the operands > are used in the calculation or not. If they are not in the definition > chain, they can have no impact, and we stop the attempt. Sounds reasonable without knowing all the details in the implementation. How does it affect compile-times on the testcase?
[Bug libstdc++/109229] std::exclusive_scan narrows to initial value
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109229 --- Comment #2 from Tobias Ribizel --- I agree, but that doesn't make it less bug-prone IMO, with the narrowing conversion happening deep inside the exclusive_scan implementation (-Wnarrowing doesn't pick it up). Something similar like common_type> would be much safer.
[Bug tree-optimization/109176] [13 Regression] internal compiler error: in to_constant, at poly-int.h:504
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109176 --- Comment #9 from Jakub Jelinek --- Oh, and one more thing, why the second hunk isn't inside of the if (assign && ) body, but after it? If we haven't updated code, then it will never succeed with code = SSA_NAME unless the first hunk already returned true.
[Bug libstdc++/109229] std::exclusive_scan narrows to initial value
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109229 --- Comment #3 from Jonathan Wakely --- e.g. https://en.cppreference.com/w/cpp/algorithm/accumulate is clear that the accumulator has the same type as the init parameter, and there's even a caveat about it: https://en.cppreference.com/w/cpp/algorithm/accumulate#Common_mistakes
[Bug libstdc++/109229] std::exclusive_scan narrows to initial value
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109229
--- Comment #4 from Jonathan Wakely ---
Maybe we could do this:
--- a/libstdc++-v3/include/std/numeric
+++ b/libstdc++-v3/include/std/numeric
@@ -483,12 +483,16 @@ namespace __detail
_OutputIterator __result, _Tp __init,
_BinaryOperation __binary_op)
{
- while (__first != __last)
+ if (__first != __last)
{
- auto __v = __init;
- __init = __binary_op(__init, *__first);
- ++__first;
- *__result++ = std::move(__v);
+ auto __sum = __binary_op(__init, *__first);
+ *__result++ = std::move(__init);
+ while (++__first != __last)
+ {
+ auto __tmp = __sum;
+ __sum = __binary_op(__sum, *__first);
+ *__result++ = std::move(__tmp);
+ }
}
return __result;
}
We'd need something similar for inclusive_scan, reduce etc.
But I don't think this is actually allowed by the standard. It clearly lists
the forms allowed when invoking the summation operator, and binary_op(sum,
*first) isn't one of them.
The reason for the requirement that the result of the summation operation can
be converted to T is precisely so that the summation can be done in that type.
[Bug tree-optimization/109219] [12/13 Regression] csmith: ice in vect_slp_analyze_node_operations_1, at tree-vect-slp.cc:5954 since r13-1106-g8c2733e16ec1c0cd
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109219 Martin Liška changed: What|Removed |Added Summary|[12/13 Regression] csmith: |[12/13 Regression] csmith: |ice in |ice in |vect_slp_analyze_node_opera |vect_slp_analyze_node_opera |tions_1, at |tions_1, at |tree-vect-slp.cc:5954 |tree-vect-slp.cc:5954 since ||r13-1106-g8c2733e16ec1c0cd Keywords|needs-bisection | CC||marxin at gcc dot gnu.org --- Comment #3 from Martin Liška --- Started with r13-1106-g8c2733e16ec1c0cd (and it's backported to gcc-12 branch).
[Bug libstdc++/109229] std::exclusive_scan narrows to initial value
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109229 --- Comment #5 from Jonathan Wakely --- (In reply to Tobias Ribizel from comment #2) > Something similar like common_type invoke_result> would be much safer. No, there's no requirement that those types have a common type. You can have two types which are valid inputs to the binary operator, but which cannot be converted to each other.
[Bug tree-optimization/109176] [13 Regression] internal compiler error: in to_constant, at poly-int.h:504
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109176
--- Comment #10 from ktkachov at gcc dot gnu.org ---
For the testcase, having it in gcc.target/aarch64/sve as
/* { dg-options "-O2" } */
#include
svbool_t
foo (svint8_t a, svint8_t b, svbool_t c)
{
svbool_t d = svcmplt_s8 (svptrue_pat_b8 (SV_ALL), a, b);
return svsel_b (d, c, d);
}
would be fine.
[Bug libstdc++/109229] std::exclusive_scan narrows to initial value
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109229 --- Comment #6 from Jonathan Wakely --- Ah yes, this issue is the subject of https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p0571r2.html#intermediate_unordered which is waiting for a new revision from the author.
[Bug target/109228] warning: implicit declaration of function '__riscv_vlenb'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109228 --- Comment #2 from Mathieu Malaterre --- For later reference: * https://github.com/riscv-non-isa/rvv-intrinsic-doc/pull/216/files
[Bug ipa/81323] IPA-VRP doesn't handle return values
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81323 --- Comment #7 from Aldy Hernandez --- (In reply to Andrew Macleod from comment #6) > (In reply to Jakub Jelinek from comment #4) > > Or the ranger could do it itself, similarly to how it handles .ASSUME, but > > without actually querying anything but the global range of the return value > > if any. Though, doing that in the range means that we won't know ranges of > > functions which with LTO are in a different partition, while doing it as IPA > > optimization could allow even that to work. > > Aldy has been doing some IPA/LTO related cleanup with ranges... Hopefully we > can get this all connected next release. I'm sitting on a patchset for GCC 14 that will revamp all the range handling in ipa-*.* to be less ad-hoc, and use generic ranges (vrange even, so type-agnostic). The plan is to integrate this with the internal range storage used by IPA (currently pairs of wide ints or value_range's) so that IPA at least has the infrastructure to handle generic ranges. Some discussion upstream is still needed, but the general idea should be feasible for GCC 14. It will be up to the IPA maintainers to handle floats/etc internally though.
[Bug tree-optimization/109230] New: [13 Regression] Maybe wrong code for opus package on aarch64 since r13-4122-g1bc7efa948f751
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109230 Bug ID: 109230 Summary: [13 Regression] Maybe wrong code for opus package on aarch64 since r13-4122-g1bc7efa948f751 Product: gcc Version: 13.0 Status: UNCONFIRMED Keywords: wrong-code Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: marxin at gcc dot gnu.org CC: tnfchris at gcc dot gnu.org Target Milestone: --- Host: aarch64-linux-gnu Target: aarch64-linux-gnu The package build fails here: https://build.opensuse.org/package/live_build_log/openSUSE:Factory:ARM/opus/standard/aarch64 [ 214s] FAIL: celt/tests/test_unit_mdct [ 214s] === [ 214s] [ 214s] nfft=32 inverse=0,snr = 17.104167 [ 214s] ** poor snr: 17.104167 ** [ 214s] nfft=32 inverse=1,snr = 20.102683 [ 214s] ** poor snr: 20.102683 ** [ 214s] nfft=256 inverse=0,snr = 138.489354 [ 214s] nfft=256 inverse=1,snr = 137.974696 [ 214s] nfft=512 inverse=0,snr = 7.811854 [ 214s] ** poor snr: 7.811854 ** [ 214s] nfft=512 inverse=1,snr = 7.850219 [ 214s] ** poor snr: 7.850219 ** [ 214s] nfft=1024 inverse=0,snr = 136.654582 [ 214s] nfft=1024 inverse=1,snr = 136.537410 [ 214s] nfft=2048 inverse=0,snr = 9.257344 [ 214s] ** poor snr: 9.257344 ** [ 214s] nfft=2048 inverse=1,snr = 10.914094 [ 214s] ** poor snr: 10.914094 ** [ 214s] nfft=36 inverse=0,snr = 137.555495 [ 214s] nfft=36 inverse=1,snr = 139.119054 [ 214s] nfft=40 inverse=0,snr = 134.266617 [ 214s] nfft=40 inverse=1,snr = 137.088788 [ 214s] nfft=60 inverse=0,snr = 135.700513 [ 214s] nfft=60 inverse=1,snr = 139.498130 [ 214s] nfft=120 inverse=0,snr = 136.557198 [ 214s] nfft=120 inverse=1,snr = 139.409077 [ 214s] nfft=240 inverse=0,snr = 136.620940 [ 214s] nfft=240 inverse=1,snr = 137.494083 [ 214s] nfft=480 inverse=0,snr = 7.290223 [ 214s] ** poor snr: 7.290223 ** [ 214s] nfft=480 inverse=1,snr = 10.126481 [ 214s] ** poor snr: 10.126481 ** [ 214s] nfft=960 inverse=0,snr = 136.037327 [ 214s] nfft=960 inverse=1,snr = 137.196856 [ 214s] nfft=1920 inverse=0,snr = 8.653704 [ 214s] ** poor snr: 8.653704 ** [ 214s] nfft=1920 inverse=1,snr = 9.472643 [ 214s] ** poor snr: 9.472643 ** [ 214s] FAIL celt/tests/test_unit_mdct (exit status: 1) and it's since the revision r13-4122-g1bc7efa948f751.
[Bug tree-optimization/109219] [12/13 Regression] csmith: ice in vect_slp_analyze_node_operations_1, at tree-vect-slp.cc:5954 since r13-1106-g8c2733e16ec1c0cd
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109219 --- Comment #4 from Richard Biener --- (In reply to Richard Biener from comment #2) > I will have a look - the representative looks out-of sync: > > t.c:4:1: note: node 0x41d6f00 (max_nunits=8, refcnt=1) vector(8) unsigned > short > t.c:4:1: note: op template: _68 = _70 + 65535; > t.c:4:1: note: stmt 0 patt_20 = _68 - patt_23; > t.c:4:1: note: stmt 1 patt_77 = _9 - patt_101; > t.c:4:1: note: children 0x41d7340 0x41d7098 Thinking about it, the representative STMT_SLP_TYPE isn't really relevant for anything and we shouldn't check it from SLP code. The only valid case is for loop vect to check whether a stmt is relevant for it.
[Bug tree-optimization/109230] [13 Regression] Maybe wrong code for opus package on aarch64 since r13-4122-g1bc7efa948f751
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109230 --- Comment #1 from Tamar Christina --- That patch only fixed the bootstrap, in any case I'm on holidays so have asked someone else to look.
[Bug tree-optimization/109230] [13 Regression] Maybe wrong code for opus package on aarch64 since r13-4122-g1bc7efa948f751
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109230 --- Comment #2 from Martin Liška --- And the same happens for glm package: https://build.opensuse.org/package/live_build_log/openSUSE:Factory:ARM/glm/standard/aarch64 [ 95s] The following tests FAILED: [ 95s]168 - test-gtx_dual_quaternion (Failed) That also started with the mentioned revision.
[Bug target/55295] [SH] Add support for fipr instruction
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55295 --- Comment #16 from Luke Benstead --- OK so perhaps adding __builtin_sh_fipr is a good first step?
[Bug target/55295] [SH] Add support for fipr instruction
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55295 --- Comment #17 from Oleg Endo --- (In reply to Luke Benstead from comment #16) > OK so perhaps adding __builtin_sh_fipr is a good first step? Yeah, you can try and see if it produces any useful results for you.
[Bug target/29776] result of ffs/clz/ctz/popcount/parity are already sign-extended
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=29776
--- Comment #25 from Adam Warner ---
Documenting a workaround I've found for the unnecessary sign extension. I'm
still perplexed at the improbability of this appearing to work!
workaround_bsr_sign_extension.c:
#include
uint64_t bsr_u64(uint64_t a) {
if (sizeof(unsigned long) == 8) return 63 - __builtin_clzl(a);
if (sizeof(unsigned long long) == 8) return 63 - __builtin_clzll(a);
}
uint64_t bsr_u64_alt(uint64_t a) {
if (sizeof(unsigned long) == 8) return UINT64_C(63) - __builtin_clzl(a);
if (sizeof(unsigned long long) == 8) return UINT64_C(63) -
__builtin_clzll(a);
}
int main(void) {return 0;}
$ gcc -O3 workaround_bsr_sign_extension.c && objdump -d -m i386:x86-64:intel
a.out|less
Relevant output:
1140 :
1140: 48 0f bd c7 bsrrax,rdi
1144: 48 98 cdqe
1146: c3 ret
1147: 66 0f 1f 84 00 00 00nopWORD PTR [rax+rax*1+0x0]
114e: 00 00
1150 :
1150: 48 0f bd c7 bsrrax,rdi
1154: c3 ret
In the alternative implementation the superfluous 32- to 64-bit sign extension
instruction CDQE is no longer generated.
[Bug fortran/109223] parameters for a type on IMPLICIT do not work. For example: IMPLICIT TYPE(REAL(KIND=REAL128)) fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109223 --- Comment #4 from urbanjost at comcast dot net --- User-defined types work and as I read the ISO standard are supported, and TYPE(REAL) works; it is only when a parameter is added that it fails; nvfortran fails for user-defined type declared below it but it works with one defined via a USE from a module; while gfortran allows the type to be defined after the use, but I consider that a nvfortran bug myself. Rereading the spec "type" and "type arguments" could be interpreted as meaning just something like "REAL(KIND=QP) (A)" which does work, but I do not see where the excludes "TYPE(REAL(QP))", particularly since "TYPE(REAL)" and all other type declaration syntax appears to work? program testit use, intrinsic :: iso_fortran_env, only : real_kinds,sp=>real32,dp=>real64,qp=>real128 implicit type(null) (a) implicit type(real) (f) implicit real(dp) (d) !implicit type(real(kind=qp)) (c) ! <== OK in a declaration, error in IMPLICIT type null end type null ! the syntax works for a declaration type(real) :: float_default type(real(kind=sp)) :: float type(real(kind=dp)) :: long type(real(kind=qp)) :: quad end program testit
[Bug libstdc++/108178] Filesystem::copy_file can't copy from /proc on Linux machines
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108178 Jonathan Wakely changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |redi at gcc dot gnu.org --- Comment #5 from Jonathan Wakely --- I have a patch for GCC 14 stage 1.
[Bug tree-optimization/109176] [13 Regression] internal compiler error: in to_constant, at poly-int.h:504
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109176 --- Comment #11 from Jakub Jelinek --- Created attachment 54718 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54718&action=edit gcc13-pr109176.patch Full untested patch.
[Bug tree-optimization/109176] [13 Regression] internal compiler error: in to_constant, at poly-int.h:504
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109176 --- Comment #12 from Richard Biener --- (In reply to Jakub Jelinek from comment #11) > Created attachment 54718 [details] > gcc13-pr109176.patch > > Full untested patch. LGTM
[Bug testsuite/108898] [13 Regression] Test introduced by r13-6278-g3da77f217c8b2089ecba3eb201e727c3fcdcd19d failed on i386
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108898
--- Comment #5 from CVS Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:b49aedf6aed4911c8473738a88e839703f51386d
commit r13-6784-gb49aedf6aed4911c8473738a88e839703f51386d
Author: Jakub Jelinek
Date: Tue Mar 21 13:28:50 2023 +0100
testsuite: Fix up vect-simd-clone1[678]*.c tests [PR108898]
As mentioned in the PR, vect-simd-clone-1[678]{,f}.c tests FAIL on
x86_64-linux with -m64/-march=cascadelake or -m32/-march=cascadelake,
there are 3 matches for the calls rather than expected two.
As suggested by Richi, this patch changes those tests to use
--param vect-epilogues-nomask=0 such that it is more predictable on how
many calls will show up. In the non-[a-f] suffixed tests, the
scan-tree-dump-times patterns were expecting 2 for non-aarch64 and 3 for
aarch64, which is a puzzle for me, because vect_simd_clones effective
target is apparently never true on aarch64 (just on x86 in some cases and
on amdgcn; perhaps something to change for GCC14, but I guess too late
for stage4). That said, I have looked at aarch64 dumps and see only 2
calls with --param vect-epilogues-nomask=0 and 3 with --param
vect-epilogues-nomask=1 or without it, so I have tweaked those to always
expect the same thing. Another thing is some tests uselessly had
-fdump-tree-optimized in dg-options even when they don't scan anything
there.
Tested on x86_64-linux with
make -j32 -k check-gcc
RUNTESTFLAGS="vect.exp=gcc.dg/vect/vect-simd-clone-*.c \
--target_board='unix{-m64/-march=x86-64,-m64/-march=cascadelake,-m32/-march=i686,-m32/-march=cascadelake}'"
and aarch64-linux (where all tests are UNSUPPORTED before/after).
2023-03-21 Jakub Jelinek
PR testsuite/108898
* gcc.dg/vect/vect-simd-clone-16.c: Add --param
vect-epilogues-nomask=0
to dg-additional-options. Always expect just 2 foo.simdclone
calls.
* gcc.dg/vect/vect-simd-clone-16f.c: Add
--param vect-epilogues-nomask=0 to dg-additional-options.
* gcc.dg/vect/vect-simd-clone-17.c: Likewise. Always expect just 2
foo.simdclone calls.
* gcc.dg/vect/vect-simd-clone-17d.c: Remove -fdump-tree-optimized
from
dg-additional-options.
* gcc.dg/vect/vect-simd-clone-17e.c: Likewise.
* gcc.dg/vect/vect-simd-clone-17f.c: Likewise. Add
--param vect-epilogues-nomask=0 to dg-additional-options.
* gcc.dg/vect/vect-simd-clone-18.c: Add --param
vect-epilogues-nomask=0
to dg-additional-options. Always expect just 2 foo.simdclone
calls.
* gcc.dg/vect/vect-simd-clone-18f.c: Add
--param vect-epilogues-nomask=0 to dg-additional-options.
[Bug testsuite/108898] [13 Regression] Test introduced by r13-6278-g3da77f217c8b2089ecba3eb201e727c3fcdcd19d failed on i386
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108898 Jakub Jelinek changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED CC||jakub at gcc dot gnu.org --- Comment #6 from Jakub Jelinek --- Should be fixed now.
[Bug tree-optimization/109184] [10/11/12/13 Regression] csmith: 2017 bug with -floop-interchange
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109184
--- Comment #13 from Richard Biener ---
Testcase with just the essential stuff.
static int g_1731[7] = { 42, 0, 0, 0, 0, 0, 42 };
void __attribute__((noipa)) foo ()
{
int l_1930[5] = { 0, };
for (int i = 0; i < 15; ++i)
for (int j = 4; (j >= 1); j -= 1)
#pragma GCC unroll 0
for (int k = 0; (k <= 4); k += 1)
g_1731[(j + 1)] = --l_1930[k];
}
int main()
{
foo ();
if (g_1731[0] != 42
|| g_1731[1] != 0 || g_1731[2] != -60 || g_1731[3] != -59
|| g_1731[4] != -58 || g_1731[5] != -57
|| g_1731[6] != 42)
__builtin_abort ();
return 0;
}
The innermost loop body then is
[local count: 894749066]:
# k_26 = PHI
# ivtmp_23 = PHI
_1 = l_1930[k_26];
_2 = _1 + -1;
l_1930[k_26] = _2;
g_1731[_6] = _2;
k_17 = k_26 + 1;
ivtmp_21 = ivtmp_23 - 1;
if (ivtmp_21 != 0)
one should note that for data dependence analysis we'd usually need to
treat scalars (in this case SSA names) as arrays of the size of the
whole nest iteration domain and the dependences would be between
statements, not reads/writes. So the above is
_1 = l_1930[k_26];
_2[i] = _1 + -1;
l_1930[k_26] = _2[i];
g_1731[_6] = _2[i];
then and when we interchange the loop we suddenly need two different
_2[] elements and when eliminating _2[] there's a dependence between
the l_1930 store and the implied load from a different iteration.
Note that when l_1930[k] wouldn't be stored to g_1731[j+1] the
interchange would be of course valid and we do not want to break
that case.
[Bug d/109231] New: [13 regression] Comparison failure in libphobos/libdruntime/rt/util/typeinfo.o
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109231 Bug ID: 109231 Summary: [13 regression] Comparison failure in libphobos/libdruntime/rt/util/typeinfo.o Product: gcc Version: 13.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: d Assignee: ibuclaw at gdcproject dot org Reporter: ro at gcc dot gnu.org Target Milestone: --- Host: sparc-sun-solaris2.11 Target: sparc-sun-solaris2.11 Build: sparc-sun-solaris2.11 Between 20230317 (2bb71424636fba7944b36b1689e9df22a53f1a3f) and 20230320 (fbd50e867e6a782c7b56c9727bf7e1e74dae4b94), Solaris/SPARC bootstrap broke with a comparison failure: Comparing stages 2 and 3 Bootstrap comparison failure! sparc-sun-solaris2.11/libphobos/libdruntime/rt/util/.libs/typeinfo.o differs sparc-sun-solaris2.11/libphobos/libdruntime/rt/util/typeinfo.o differs make[2]: *** [Makefile:32772: compare] Error 1 For some reason, this only happens when using gas, not with the native as. elfcmp shows *** section: [244].text._D2rt4util8typeinfo__T20TypeInfoArrayGenericTfTfZQBb7compareMxFIPvIQdZi: data information differs --- : _D2rt4util8typeinfo__T20TypeInfoArrayGenericTfTfZQBb7compareMxFIPvIQdZi() < 0x40:+0x40: 83 aa 4a a8 fcmpes%fcc1, %f9, %f8 > 0x40:+0x40: 81 aa 4a a8 fcmpes%fcc0, %f9, %f8 *** section: [245].text._D2rt4util8typeinfo__T20TypeInfoArrayGenericTdTdZQBb7compareMxFIPvIQdZi: data information differs --- : _D2rt4util8typeinfo__T20TypeInfoArrayGenericTdTdZQBb7compareMxFIPvIQdZi() < 0x34:+0x34: 81 aa 0a 48 fcmpd %fcc0, %d8, %d8 > 0x34:+0x34: 83 aa 0a 48 fcmpd %fcc1, %d8, %d8 *** section: [246].text._D2rt4util8typeinfo__T20TypeInfoArrayGenericTEQBsQBs7utility17__c_complex_floatTQBjZQCk7compareMxFIPvIQdZi: data information differs --- : _D2rt4util8typeinfo__T20TypeInfoArrayGenericTEQBsQBs7utility17__c_complex_floatTQBjZQCk7compareMxFIPvIQdZi() < 0x3c:+0x3c: 87 aa 0a 28 fcmps %fcc3, %f8, %f8 > 0x3c:+0x3c: 81 aa 0a 28 fcmps %fcc0, %f8, %f8 *** section: [247].text._D2rt4util8typeinfo__T20TypeInfoArrayGenericTEQBsQBs7utility18__c_complex_doubleTQBkZQCl7compareMxFIPvIQdZi: data information differs --- : _D2rt4util8typeinfo__T20TypeInfoArrayGenericTEQBsQBs7utility18__c_complex_doubleTQBkZQCl7compareMxFIPvIQdZi() < 0x3c:+0x3c: 83 aa 0a 48 fcmpd %fcc1, %d8, %d8 > 0x3c:+0x3c: 85 aa 0a 48 fcmpd %fcc2, %d8, %d8 *** section: [248].text._D2rt4util8typeinfo__T15TypeInfoGenericTfTfZQw7compareMxFNaNbNeIPvIQdZi: data information differs --- : _D2rt4util8typeinfo__T15TypeInfoGenericTfTfZQw7compareMxFNaNbNeIPvIQdZi() < 0x8:+0x8: 87 aa 0a 28 fcmps %fcc3, %f8, %f8 > 0x8:+0x8: 81 aa 0a 28 fcmps %fcc0, %f8, %f8 *** section: [249].text._D2rt4util8typeinfo__T15TypeInfoGenericTdTdZQw7compareMxFNaNbNeIPvIQdZi: data information differs --- : _D2rt4util8typeinfo__T15TypeInfoGenericTdTdZQw7compareMxFNaNbNeIPvIQdZi() < 0x8:+0x8: 85 aa 0a 48 fcmpd %fcc2, %d8, %d8 > 0x8:+0x8: 87 aa 0a 48 fcmpd %fcc3, %d8, %d8 *** section: [250].text._D2rt4util8typeinfo__T15TypeInfoGenericTEQBnQBn7utility17__c_complex_floatTQBjZQCf7compareMxFNaNbNeIPvIQdZi: data information differs --- : _D2rt4util8typeinfo__T15TypeInfoGenericTEQBnQBn7utility17__c_complex_floatTQBjZQCf7compareMxFNaNbNeIPvIQdZi() < 0x8:+0x8: 83 aa 0a 28 fcmps %fcc1, %f8, %f8 > 0x8:+0x8: 85 aa 0a 28 fcmps %fcc2, %f8, %f8 *** section: [251].text._D2rt4util8typeinfo__T15TypeInfoGenericTEQBnQBn7utility18__c_complex_doubleTQBkZQCg7compareMxFNaNbNeIPvIQdZi: data information differs --- : _D2rt4util8typeinfo__T15TypeInfoGenericTEQBnQBn7utility18__c_complex_doubleTQBkZQCg7compareMxFNaNbNeIPvIQdZi() < 0x8:+0x8: 87 aa 0a 48 fcmpd %fcc3, %d8, %d8 > 0x8:+0x8: 81 aa 0a 48 fcmpd %fcc0, %d8, %d8 *** section: [284].text._D4core8internal5array8equality__T8__equalsTxE2rt4util7utility17__c_complex_floatTxQBmZQCbFNaNbNiNfMAxQCfMQgZb: data information differs --- : _D4core8internal5array8equality__T8__equalsTxE2rt4util7utility17__c_complex_floatTxQBmZQCbFNaNbNiNfMAxQCfMQgZb() < 0x44:+0x44: 85 aa 4a 28 fcmps %fcc2, %f9, %f8 > 0x44:+0x44: 87 aa 4a 28 fcmps %fcc3, %f9, %f8 *** section: [287].text._D4core8internal5array8equality__T8__equalsTxE2rt4util7utility18__c_complex_doubleTxQBnZQCcFNaNbNiNfMAxQCgMQgZb: data information differs --- : _D4core8internal5array8equality__T8__equalsTxE2rt4util7utility18__c_complex_doubleTxQBnZQCcFNaNbNiNfMAxQCgMQgZb() < 0x44:+0x44: 81 aa 8a 48 fcmpd %fcc0, %d10, %d8 > 0x44:+0x44: 83 aa 8a 48 fcmpd %fcc1, %d10, %d8 *** section: [295].text._D4core8internal4hash__T13coalesceFloatTfZQsFNaNbNiNfxfZf: data information differs --- : _D4core8internal4hash__T13coalesceFloatTfZQsFNaNbNiNfxfZf() < 0x28:+0x28
[Bug d/109231] [13 regression] Comparison failure in libphobos/libdruntime/rt/util/typeinfo.o
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109231 Rainer Orth changed: What|Removed |Added Target Milestone|--- |13.0
[Bug testsuite/108898] [13 Regression] Test introduced by r13-6278-g3da77f217c8b2089ecba3eb201e727c3fcdcd19d failed on i386
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108898
--- Comment #7 from CVS Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:49a8bce43cdc1d1b48efa5eeb2a4097cfca1dc22
commit r13-6785-g49a8bce43cdc1d1b48efa5eeb2a4097cfca1dc22
Author: Jakub Jelinek
Date: Tue Mar 21 13:42:51 2023 +0100
testsuite: Remove obsolete comments [PR108898]
On Tue, Mar 21, 2023 at 12:35:19PM +, Andrew Stubbs wrote:
> > /* Ensure the the in-branch simd clones are used on targets that
support them.
> > Some targets use another call for the epilogue loops. */
> > -/* { dg-final { scan-tree-dump-times {[\n\r] [^\n]* = foo\.simdclone}
2 "vect" { target { ! aarch64*-*-* } } } } */
> > -/* { dg-final { scan-tree-dump-times {[\n\r] [^\n]* = foo\.simdclone}
3 "vect" { target aarch64*-*-* } } } */
> > +/* { dg-final { scan-tree-dump-times {[\n\r] [^\n]* = foo\.simdclone}
2 "vect" } } */
>
> I suppose those comments are now obsolete.
Oops, fixed thusly.
2023-03-21 Jakub Jelinek
PR testsuite/108898
* gcc.dg/vect/vect-simd-clone-16.c: Remove parts of comment
mentioning
epilogue loops.
* gcc.dg/vect/vect-simd-clone-17.c: Likewise.
* gcc.dg/vect/vect-simd-clone-18.c: Likewise.
[Bug d/109231] [13 regression] Comparison failure in libphobos/libdruntime/rt/util/typeinfo.o
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109231 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #1 from Jakub Jelinek --- Is that with -g vs. non--g? Could be NEXT_INSN vs. next_nondebug_insn in combine_reload_insn.
[Bug d/109231] [13 regression] Comparison failure in libphobos/libdruntime/rt/util/typeinfo.o
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109231 --- Comment #2 from ro at CeBiTec dot Uni-Bielefeld.DE --- > --- Comment #1 from Jakub Jelinek --- > Is that with -g vs. non--g? > Could be NEXT_INSN vs. next_nondebug_insn in combine_reload_insn. No, it's just -fno-checking in stage 2 vs -fchecking=1 in stage 3, no other changes.
[Bug tree-optimization/109219] [12/13 Regression] csmith: ice in vect_slp_analyze_node_operations_1, at tree-vect-slp.cc:5954 since r13-1106-g8c2733e16ec1c0cd
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109219 --- Comment #5 from CVS Commits --- The master branch has been updated by Richard Biener : https://gcc.gnu.org/g:26adc870e3675591050f37edab46850b97a3c122 commit r13-6786-g26adc870e3675591050f37edab46850b97a3c122 Author: Richard Biener Date: Tue Mar 21 12:49:36 2023 +0100 tree-optimization/109219 - avoid looking at STMT_SLP_TYPE The following avoids looking at STMT_SLP_TYPE apart from the only place needing it - transform and analysis of non-SLP loop stmts. In particular it doesn't have a reliable meaning on SLP representatives which are also passed as stmt_vinfo to vectorizable_* routines. The proper way to check in those is to look for the slp_node argument instead. PR tree-optimization/109219 * tree-vect-loop.cc (vectorizable_reduction): Check slp_node, not STMT_SLP_TYPE. * tree-vect-stmts.cc (vectorizable_condition): Likewise. * tree-vect-slp.cc (vect_slp_analyze_node_operations_1): Remove assertion on STMT_SLP_TYPE. * gcc.dg/torture/pr109219.c: New testcase.
[Bug c++/109232] New: Using deduced return type in an unevaluated context leads to codegen
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109232
Bug ID: 109232
Summary: Using deduced return type in an unevaluated context
leads to codegen
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: rs2740 at gmail dot com
Target Milestone: ---
auto begin(auto&& r) {
return r.begin();
}
namespace {
struct R {
int* begin();
};
}
static_assert(__is_same(decltype(begin(R())), int*));
int main() {}
Even though ::begin is only used in an unevaluated context, GCC at -O0
generates code for begin, leading to a warning and a failure to link
(https://gcc.godbolt.org/z/cdajoP7f3):
:10:14: warning: 'int* {anonymous}::R::begin()' used but never defined
10 | int* begin();
| ^
/opt/compiler-explorer/gcc-trunk-20230320/bin/../lib/gcc/x86_64-linux-gnu/13.0.1/../../../../x86_64-linux-gnu/bin/ld:
/tmp/cc7gqEhh.o: in function `auto begin<(anonymous namespace)::R&>((anonymous
namespace)::R&)':
:2: undefined reference to `(anonymous namespace)::R::begin()'
collect2: error: ld returned 1 exit status
Execution build compiler returned: 1
[Bug tree-optimization/109230] [13 Regression] Maybe wrong code for opus package on aarch64 since r13-4122-g1bc7efa948f751
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109230 Richard Biener changed: What|Removed |Added Target Milestone|--- |13.0
[Bug c++/109232] Using deduced return type in an unevaluated context leads to codegen
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109232 Richard Biener changed: What|Removed |Added Keywords||link-failure --- Comment #1 from Richard Biener --- maybe it's implementation defined or unspecified whether instantiation happens?
[Bug tree-optimization/109213] [13 Regression] -Os generates significantly more code since r13-723
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109213 Richard Biener changed: What|Removed |Added CC||hubicka at gcc dot gnu.org --- Comment #6 from Richard Biener --- t.c:26:5: missed: not inlinable: main/7 -> m/6, --param large-stack-frame-growth limit reached and after the DSE: IPA function summary for main/7 inlinable global time: 38.636364 self size: 11 global size: 11 min size: 8 self stack: 0 global stack:0 IPA function summary for m/6 inlinable global time: 86.705545 self size: 22 global size: 22 min size: 19 self stack: 264 global stack:264 vs. IPA function summary for main/7 inlinable global time: 42.636364 self size: 14 global size: 14 min size: 11 self stack: 40 global stack:40 without the DSE. And we apply the limit in a quite complicated way in caller_growth_limits, changing mains stack size to 1 or 4 doesn't help, so it isn't a totally arbitrary special-casing of zero caller stack size. I'm leaning towards a WONTFIX or reclassify as non-regression. The bug is definitely not that we now do more DSE, the pre-existing bug might be that we take the absolute size of the caller stack into account.
[Bug c/109233] New: warning: array subscript 5 is above array bounds of ‘struct tg3_napi[5]’
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109233 Bug ID: 109233 Summary: warning: array subscript 5 is above array bounds of ‘struct tg3_napi[5]’ Product: gcc Version: 13.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: ubizjak at gmail dot com Target Milestone: --- There is another bogus array bounds warning when compiling linux in: drivers/net/ethernet/broadcom/tg3.c: In function ‘tg3_init_one’: drivers/net/ethernet/broadcom/tg3.c:17787:51: error: array subscript 5 is above array bounds of ‘struct tg3_napi[5]’ [-Werror=array-bounds=] 17787 | struct tg3_napi *tnapi = &tp->napi[i]; | ^~~ In file included from drivers/net/ethernet/broadcom/tg3.c:72: drivers/net/ethernet/broadcom/tg3.h:3203:41: note: while referencing ‘napi’ 3203 | struct tg3_napi napi[TG3_IRQ_MAX_VECS]; | ^~~~ drivers/net/ethernet/broadcom/tg3.c:17787:51: error: array subscript 5 is above array bounds of ‘struct tg3_napi[5]’ [-Werror=array-bounds=] 17787 | struct tg3_napi *tnapi = &tp->napi[i]; | ^~~ drivers/net/ethernet/broadcom/tg3.h:3203:41: note: while referencing ‘napi’ 3203 | struct tg3_napi napi[TG3_IRQ_MAX_VECS]; | ^~~~ cc1: all warnings being treated as errors
[Bug c/109233] warning: array subscript 5 is above array bounds of ‘struct tg3_napi[5]’
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109233 --- Comment #1 from Uroš Bizjak --- Created attachment 54719 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54719&action=edit Preprocessed file -O2 -Warray-bounds: In function ‘tg3_init_one’, inlined from ‘tg3_init_one’ at drivers/net/ethernet/broadcom/tg3.c:17542:12: drivers/net/ethernet/broadcom/tg3.c:17787:37: warning: array subscript 5 is above array bounds of ‘struct tg3_napi[5]’ [-Warray-bounds=] In file included from drivers/net/ethernet/broadcom/tg3.c:72: drivers/net/ethernet/broadcom/tg3.h: In function ‘tg3_init_one’: drivers/net/ethernet/broadcom/tg3.h:3203:18: note: while referencing ‘napi’ In function ‘tg3_init_one’, inlined from ‘tg3_init_one’ at drivers/net/ethernet/broadcom/tg3.c:17542:12: drivers/net/ethernet/broadcom/tg3.c:17787:37: warning: array subscript 5 is above array bounds of ‘struct tg3_napi[5]’ [-Warray-bounds=] drivers/net/ethernet/broadcom/tg3.h: In function ‘tg3_init_one’: drivers/net/ethernet/broadcom/tg3.h:3203:18: note: while referencing ‘napi’
[Bug d/109231] [13 regression] Comparison failure in libphobos/libdruntime/rt/util/typeinfo.o
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109231 --- Comment #3 from Jakub Jelinek --- Can you find out the gdc and d21 invocation lines for those 2 cases? I've tried to test it using a cross-compiler: /usr/src/gcc/objs4/gcc/d21 ../../../../libphobos/libdruntime/rt/util/typeinfo.d -quiet -dumpdir rt/util/.libs/ -dumpbase typeinfo.d -dumpbase-ext .d -g -O2 -Wall -version -fchecking=1 -fversion=Shared -frelease -ffunction-sections -fdata-sections -fpreview=dip1000 -fpreview=fieldwise -fpreview=dtorfields -fPIC -fversion=Shared -iprefix /home/jakub/src/gcc/obj62/gcc/../lib/gcc/x86_64-pc-linux-gnu/13.0.1/ -isystem /home/jakub/src/gcc/obj62/./gcc/include -isystem /home/jakub/src/gcc/obj62/./gcc/include-fixed -nostdinc -isystem /usr/local/x86_64-pc-linux-gnu/include -isystem /usr/local/x86_64-pc-linux-gnu/sys-include -I ../../../../libphobos/libdruntime -I . -v -o /tmp/typeinfo.s1 /usr/src/gcc/objs4/gcc/d21 ../../../../libphobos/libdruntime/rt/util/typeinfo.d -quiet -dumpdir rt/util/.libs/ -dumpbase typeinfo.d -dumpbase-ext .d -g -O2 -Wall -version -fno-checking -fversion=Shared -frelease -ffunction-sections -fdata-sections -fpreview=dip1000 -fpreview=fieldwise -fpreview=dtorfields -fPIC -fversion=Shared -iprefix /home/jakub/src/gcc/obj62/gcc/../lib/gcc/x86_64-pc-linux-gnu/13.0.1/ -isystem /home/jakub/src/gcc/obj62/./gcc/include -isystem /home/jakub/src/gcc/obj62/./gcc/include-fixed -nostdinc -isystem /usr/local/x86_64-pc-linux-gnu/include -isystem /usr/local/x86_64-pc-linux-gnu/sys-include -I ../../../../libphobos/libdruntime -I . -v -o /tmp/typeinfo.s2 /usr/src/gcc/objs4/gcc/d21 ../../../../libphobos/libdruntime/rt/util/typeinfo.d -quiet -dumpdir rt/util/.libs/ -dumpbase typeinfo.d -dumpbase-ext .d -O2 -Wall -version -fno-checking -fversion=Shared -frelease -ffunction-sections -fdata-sections -fpreview=dip1000 -fpreview=fieldwise -fpreview=dtorfields -fPIC -fversion=Shared -iprefix /home/jakub/src/gcc/obj62/gcc/../lib/gcc/x86_64-pc-linux-gnu/13.0.1/ -isystem /home/jakub/src/gcc/obj62/./gcc/include -isystem /home/jakub/src/gcc/obj62/./gcc/include-fixed -nostdinc -isystem /usr/local/x86_64-pc-linux-gnu/include -isystem /usr/local/x86_64-pc-linux-gnu/sys-include -I ../../../../libphobos/libdruntime -I . -v -o /tmp/typeinfo.s3 but don't see assembly differences in any of that. objs4/gcc/d21 is ../configure --target sparc-sun-solaris2.12 (but I'm playing with stuff in x86_64-linux libdruntime tree because I have no idea what all d21 needs...).
[Bug c/109233] warning: array subscript 5 is above array bounds of ‘struct tg3_napi[5]’
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109233
--- Comment #2 from Uroš Bizjak ---
As can be seen from the preprocessed file, tp->irq_max is set to:
tp->irq_max = 1;
or
tp->irq_max = (4 + 1);
and the compilation warns in tg3_init_one at:
for (i = 0; i < tp->irq_max; i++) {
struct tg3_napi *tnapi = &tp->napi[i];
[Bug tree-optimization/109192] [13 Regression] timeout with -O3 since r13-5579
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109192 --- Comment #9 from CVS Commits --- The master branch has been updated by Andrew Macleod : https://gcc.gnu.org/g:0963cb5fde158cce986523a90fa9edc51c881f31 commit r13-6787-g0963cb5fde158cce986523a90fa9edc51c881f31 Author: Andrew MacLeod Date: Mon Mar 20 16:11:12 2023 -0400 Terminate GORI calculations if a relation is not relevant. We currently allow VARYING lhs GORI calculations to continue if there is a relation present in the hope it will eventually better refine a result. This adds a check that the relation is relevant to the outgoing range calculation first. If it is not relevant, stop calculating. PR tree-optimization/109192 * gimple-range-gori.cc (gori_compute::compute_operand_range): Terminate gori calculations if a relation is not relevant. * value-relation.h (value_relation::set_relation): Allow equality between op1 and op2 if they are the same.
[Bug tree-optimization/109192] [13 Regression] timeout with -O3 since r13-5579
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109192 Andrew Macleod changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #10 from Andrew Macleod --- fixed.
[Bug tree-optimization/109192] [13 Regression] timeout with -O3 since r13-5579
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109192 --- Comment #11 from Richard Biener --- (In reply to Richard Biener from comment #6) > On a fast machine compile eventually finishes and a time-report looks like > > dominator optimization : 156.84 ( 52%) 0.00 ( 0%) 156.86 ( > 52%) 112k ( 1%) > backwards jump threading : 145.15 ( 48%) 0.00 ( 0%) 145.15 ( > 48%)70k ( 0%) > TOTAL : 302.15 0.02302.19 > 16M With the fix in it's now dominator optimization : 0.01 ( 4%) 0.00 ( 0%) 0.00 ( 0%) 112k ( 1%) backwards jump threading : 0.00 ( 0%) 0.00 ( 0%) 0.04 ( 13%) 70k ( 0%) Thanks a lot (for reporting and for fixing)
[Bug c/109234] New: gcc refuses compilation with implausible error when using -fprofile-arcs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109234 Bug ID: 109234 Summary: gcc refuses compilation with implausible error when using -fprofile-arcs Product: gcc Version: 12.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: konstantin.priesnitz at de dot bosch.com Target Milestone: --- Command: touch empty.c gcc -save-temps=obj -fprofile-arcs -pthread -c empty.c Result: cc1: error: unknown profile update method ‘prefer-atomic-fasynchronous-unwind-tables’ cc1: note: valid arguments to ‘-fprofile-update=’ are: atomic prefer-atomic single Expected: Running without error. gcc version: $ gcc -v Using built-in specs. COLLECT_GCC=gcc COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/12/lto-wrapper OFFLOAD_TARGET_NAMES=nvptx-none:amdgcn-amdhsa OFFLOAD_TARGET_DEFAULT=1 Target: x86_64-linux-gnu Configured with: ../src/configure -v --with-pkgversion='Ubuntu 12.2.0-3ubuntu1' --with-bugurl=file:///usr/share/doc/gcc-12/README.Bugs --enable-languages=c,ada,c++,go,d,fortran,objc,obj-c++,m2 --prefix=/usr --with-gcc-major-version-only --program-suffix=-12 --program-prefix=x86_64-linux-gnu- --enable-shared --enable-linker-build-id --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --libdir=/usr/lib --enable-nls --enable-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-12-U8K4Qv/gcc-12-12.2.0/debian/tmp-nvptx/usr,amdgcn-amdhsa=/build/gcc-12-U8K4Qv/gcc-12-12.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 Thread model: posix Supported LTO compression algorithms: zlib zstd gcc version 12.2.0 (Ubuntu 12.2.0-3ubuntu1)
[Bug driver/109234] gcc refuses compilation with implausible error when using -fprofile-arcs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109234 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2023-03-21 Ever confirmed|0 |1 --- Comment #1 from Andrew Pinski --- Works on the trunk. This looks to be a bug in Ubuntu's compiler so you should report it to them really since that is where you got the binary.
[Bug d/109231] [13 regression] Comparison failure in libphobos/libdruntime/rt/util/typeinfo.o
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109231 --- Comment #4 from ro at CeBiTec dot Uni-Bielefeld.DE --- "jakub at gcc dot gnu.org" writes: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109231 > > --- Comment #3 from Jakub Jelinek --- > Can you find out the gdc and d21 invocation lines for those 2 cases? sure (with -v -save-temps added): * stage 2, -fno-checking: /var/gcc/regression/master/11.4-gcc-gas/build/./gcc/gdc -B/var/gcc/regression/master/11.4-gcc-gas/build/./gcc/ -B/vol/gcc/sparc-sun-solaris2.11/bin/ -B/vol/gcc/sparc-sun-solaris2.11/lib/ -isystem /vol/gcc/sparc-sun-solaris2.11/include -isystem /vol/gcc/sparc-sun-solaris2.11/sys-include -fno-checking -fversion=Shared -Wall -frelease -ffunction-sections -fdata-sections -O2 -g -fpreview=dip1000 -fpreview=fieldwise -fpreview=dtorfields -nostdinc -I /vol/gcc/src/hg/master/local/libphobos/libdruntime -I . -c /vol/gcc/src/hg/master/local/libphobos/libdruntime/rt/util/typeinfo.d -v -save-temps -fPIC -fversion=Shared -o rt/util/.libs/typeinfo.o /var/gcc/regression/master/11.4-gcc-gas/build/./gcc/d21 /vol/gcc/src/hg/master/local/libphobos/libdruntime/rt/util/typeinfo.d -quiet -dumpdir rt/util/.libs/ -dumpbase typeinfo.d -dumpbase-ext .d -mcpu=v9 -g -O2 -Wall -version -fno-checking -fversion=Shared -frelease -ffunction-sections -fdata-sections -fpreview=dip1000 -fpreview=fieldwise -fpreview=dtorfields -fPIC -fversion=Shared -iprefix /var/gcc/regression/master/11.4-gcc-gas/build/gcc/../lib/gcc/sparc-sun-solaris2.11/13.0.1/ -isystem /var/gcc/regression/master/11.4-gcc-gas/build/./gcc/include -isystem /var/gcc/regression/master/11.4-gcc-gas/build/./gcc/include-fixed -nostdinc -isystem /vol/gcc/sparc-sun-solaris2.11/include -isystem /vol/gcc/sparc-sun-solaris2.11/sys-include -I /vol/gcc/src/hg/master/local/libphobos/libdruntime -I . -v -o rt/util/.libs/typeinfo.s * stage 3, -fchecking=1 /var/gcc/regression/master/11.4-gcc-gas/build/./gcc/gdc -B/var/gcc/regression/master/11.4-gcc-gas/build/./gcc/ -B/vol/gcc/sparc-sun-solaris2.11/bin/ -B/vol/gcc/sparc-sun-solaris2.11/lib/ -isystem /vol/gcc/sparc-sun-solaris2.11/include -isystem /vol/gcc/sparc-sun-solaris2.11/sys-include -fchecking=1 -fversion=Shared -Wall -frelease -ffunction-sections -fdata-sections -O2 -g -fpreview=dip1000 -fpreview=fieldwise -fpreview=dtorfields -nostdinc -I /vol/gcc/src/hg/master/local/libphobos/libdruntime -I . -c /vol/gcc/src/hg/master/local/libphobos/libdruntime/rt/util/typeinfo.d -fPIC -fversion=Shared -o rt/util/typeinfo.o -v -save-temps /var/gcc/regression/master/11.4-gcc-gas/build/./gcc/d21 /vol/gcc/src/hg/master/local/libphobos/libdruntime/rt/util/typeinfo.d -quiet -dumpdir rt/util/ -dumpbase typeinfo.d -dumpbase-ext .d -mcpu=v9 -g -O2 -Wall -version -fchecking=1 -fversion=Shared -frelease -ffunction-sections -fdata-sections -fpreview=dip1000 -fpreview=fieldwise -fpreview=dtorfields -fPIC -fversion=Shared -iprefix /var/gcc/regression/master/11.4-gcc-gas/build/gcc/../lib/gcc/sparc-sun-solaris2.11/13.0.1/ -isystem /var/gcc/regression/master/11.4-gcc-gas/build/./gcc/include -isystem /var/gcc/regression/master/11.4-gcc-gas/build/./gcc/include-fixed -nostdinc -isystem /vol/gcc/sparc-sun-solaris2.11/include -isystem /vol/gcc/sparc-sun-solaris2.11/sys-include -I /vol/gcc/src/hg/master/local/libphobos/libdruntime -I . -v -o rt/util/typeinfo. > I've tried to test it using a cross-compiler: It might be that this is hard to reproduce in a cross: as I mentioned, the failure only happens with gas natively and I'm uncertain if the configure tests distinguishing those two all work properly in a cross. FWIW, I'm currently running a reghunt to identify the culprit. However, a single step takes 1h25...
[Bug driver/109234] gcc refuses compilation with implausible error when using -fprofile-arcs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109234 --- Comment #2 from Jakub Jelinek --- Are you sure this isn't some Ubuntu customization? Can't reproduce with 12.2.1 20230320 nor 12.1.1 20220507 (Red Hat 12.1.1-1).
[Bug c++/109232] Using deduced return type in an unevaluated context leads to codegen
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109232 --- Comment #2 from Andrew Pinski --- clang does not emit the function but does emit the warning ...
[Bug tree-optimization/109230] [13 Regression] Maybe wrong code for opus package on aarch64 since r13-4122-g1bc7efa948f751
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109230 avieira at gcc dot gnu.org changed: What|Removed |Added CC||avieira at gcc dot gnu.org --- Comment #3 from avieira at gcc dot gnu.org --- Hi Martin, what options do you build these tests with?
[Bug tree-optimization/109230] [13 Regression] Maybe wrong code for opus package on aarch64 since r13-4122-g1bc7efa948f751
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109230 Tobias Burnus changed: What|Removed |Added CC||burnus at gcc dot gnu.org --- Comment #4 from Tobias Burnus --- (In reply to avieira from comment #3) > Hi Martin, what options do you build these tests with? Clicking on the link for the glm package (and then "download logfile") shows for instance the following (I have not checked whether a certain fine is compiled differently): /usr/bin/c++ -I/home/abuild/rpmbuild/BUILD/glm-0.9.9.8 -mbranch-protection=standard -O2 -Wall -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=3 -fstack-protector-strong -funwind-tables -fasynchronous-unwind-tables -fstack-clash-protection -Werror=return-type -flto=auto -g -fPIC -fno-strict-aliasing -O2 -g -DNDEBUG -O2 -Wno-long-long -MD
[Bug target/109137] [12/13 regression] Compiling ffmpeg with -m32 on x86_64-pc-linux-gnu hangs on libavcodec/h264_cabac.c since r12-9086-g489c81db7d4f75
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109137 --- Comment #15 from Vladimir Makarov --- I've reproduced hanging up but for the particular commit. I also reproduced internal compiler error on the current master. I'll try to fix the both problems on this week.
[Bug fortran/109223] parameters for a type on IMPLICIT do not work. For example: IMPLICIT TYPE(REAL(KIND=REAL128)) fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109223 --- Comment #5 from kargl at gcc dot gnu.org --- (In reply to urbanjost from comment #4) > User-defined types work and as I read the ISO standard are supported, and > TYPE(REAL) works; it is only when a parameter is added that it fails; > nvfortran fails for user-defined type declared below it but it works with > one defined via a USE from a module; while gfortran allows the type to be > defined after the use, > but I consider that a nvfortran bug myself. Ah, yeah, you're right. I failed to follow the EBNF in R864. It seems that gfortran is getting tripped up with the character following the basic type name, ie., the kind selector part.
[Bug c++/106890] [10/11/12/13 Regression] virtual inheritance triggers compiler error when instatiating derived class with in-class initialization since r8-2709-g12659e10c7820071
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106890 --- Comment #2 from CVS Commits --- The trunk branch has been updated by Jason Merrill : https://gcc.gnu.org/g:041a164ec9b467f9ac2f15980f83f17e3f8ea150 commit r13-6788-g041a164ec9b467f9ac2f15980f83f17e3f8ea150 Author: Jason Merrill Date: Sat Mar 18 08:27:26 2023 -0400 c++: DMI in template with virtual base [PR106890] When parsing a default member init we just build a CONVERT_EXPR for converting to a virtual base, and then expand that into the more complex form when we actually use the DMI in a constructor. But that wasn't working for the template case where we are considering the conversion at the point that the constructor needs the DMI instantiation, so it seemed like we were in a constructor already. And then when the other constructor tries to reuse the instantiation, it sees uses of the first constructor's parameters, and dies. So ensure that we get the CONVERT_EXPR in this case, too. PR c++/106890 gcc/cp/ChangeLog: * init.cc (maybe_instantiate_nsdmi_init): Don't leave current_function_decl set to a constructor. gcc/testsuite/ChangeLog: * g++.dg/cpp0x/nsdmi-template25.C: New test.
[Bug d/109231] [13 regression] Comparison failure in libphobos/libdruntime/rt/util/typeinfo.o
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109231 --- Comment #5 from Jakub Jelinek --- (In reply to r...@cebitec.uni-bielefeld.de from comment #4) > It might be that this is hard to reproduce in a cross: as I mentioned, > the failure only happens with gas natively and I'm uncertain if the > configure tests distinguishing those two all work properly in a cross. Could you then also attach auto-host.h ?
[Bug d/109231] [13 regression] Comparison failure in libphobos/libdruntime/rt/util/typeinfo.o
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109231 --- Comment #6 from Rainer Orth --- Created attachment 54720 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54720&action=edit sparc-sun-solaris2.11 auto-host.h
[Bug c++/109235] New: nodiscard attribute ignored with deduction guide
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109235 Bug ID: 109235 Summary: nodiscard attribute ignored with deduction guide Product: gcc Version: 12.2.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: t...@bang-olufsen.dk Target Milestone: --- I have tried implementing std::experimental::scope_exit and since this is a RAII object, I marked it with [[nodiscard]] to ensure all instances are assigned to a variable. It appears, however, that GCC ignores the nodiscard attribute when a deduction guide is present. See this Godbolt link for an example: https://godbolt.org/z/v9e8dqW1o Notice how Clang correctly flags the problem.
[Bug c/109236] New: [avr] Invalid code of signed 16-bit compare optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109236
Bug ID: 109236
Summary: [avr] Invalid code of signed 16-bit compare
optimization
Product: gcc
Version: 12.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: gandalf at winds dot org
Target Milestone: ---
I'm seeing incorrect code when -O1 or higher is used on AVR (atmega1284p). The
compiler generates code that compares "x" to "y", instead of performing the
subtraction and comparing against 0. This subtraction matters since "x" and "y"
are signed 16-bit variables, and the math in the expression "x-y <= 0" stays as
16-bit in AVR (as opposed to being promoted to 32-bit ints in e.g. x86).
gcc -v:
Using built-in specs.
Reading specs from /usr/local/avr/lib/gcc/avr/12.2.0/device-specs/specs-avr2
COLLECT_GCC=avr-gcc
COLLECT_LTO_WRAPPER=/usr/local/avr/libexec/gcc/avr/12.2.0/lto-wrapper
Target: avr
Configured with: ../configure --target=avr --prefix=/usr/local/avr
--disable-nls --enable-languages=c --disable-bootstrap --disable-libssp
Thread model: single
Supported LTO compression algorithms: zlib zstd
gcc version 12.2.0 (GCC)
Sample code:
_Bool compare(short x, short y)
{
return (x-y <= 0);
}
Compiled using: gcc -O1 -mmcu=atmega1284p -c -o test.o test.c
ASM result:
:
0: 9c 01 movwr18, r24
2: 81 e0 ldi r24, 0x01 ; 1
4: 62 17 cp r22, r18< X compared directly to Y;
no subtraction
6: 73 07 cpc r23, r19
8: 04 f4 brge.+0 ; 0xa
a: 80 e0 ldi r24, 0x00 ; 0
000c <.L2>:
c: 08 95 ret
I instead expect to see a subtraction between r22:23 and r18:19, then a compare
against r1 (zero).
The following testcase causes an incorrect computation:
compare(-30737, 24799) returns 1 on AVR; expected 0. (-30737 - (24799)) as
signed 16-bit = 1, which is not <= 0.
For the record, changing the function to "return ((short)(x-y) <= 0)" produces
the same incorrect code.
Compiling the function without optimization correctly returns 0.
It's possible other signed variable sizes besides 16-bit have the same problem,
but I did not test this.
[Bug c++/109235] nodiscard attribute ignored with deduction guide
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109235 --- Comment #1 from Andrew Pinski --- Created attachment 54721 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54721&action=edit Full testcase with -std=c++20 Please attach the testcase next time or put it inline and not just a link to godbolt .
[Bug c++/109235] nodiscard attribute ignored on temporary created
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109235
Andrew Pinski changed:
What|Removed |Added
Keywords||diagnostic
Ever confirmed|0 |1
Status|UNCONFIRMED |NEW
Last reconfirmed||2023-03-21
Summary|nodiscard attribute ignored |nodiscard attribute ignored
|with deduction guide|on temporary created
--- Comment #2 from Andrew Pinski ---
This has nothing to do with deduction guides either.
Reduced testcase:
```
struct [[nodiscard]] scope_exit {
scope_exit(int);
};
int main()
{
scope_exit{0};
}
```
[Bug tree-optimization/109230] [13 Regression] Maybe wrong code for opus package on aarch64 since r13-4122-g1bc7efa948f751
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109230 --- Comment #5 from Martin Liška --- Steps to reproduce: $ wget https://archive.mozilla.org/pub/opus/opus-1.3.1.tar.gz $ tar xvzf opus-1.3.1.tar.gz $ cd opus-1.3.1/ $ ./configure $ make -j32 && make -j32 check So it fails even with default options that are: -g -O2 -fvisibility=hidden -D_FORTIFY_SOURCE=2 -W -Wall -Wextra -Wcast-align -Wnested-externs -Wshadow -Wstrict-prototypes
[Bug c++/109235] nodiscard attribute on class not copied to the constructors
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109235 Andrew Pinski changed: What|Removed |Added Summary|nodiscard attribute ignored |nodiscard attribute on |on temporary created|class not copied to the ||constructors --- Comment #3 from Andrew Pinski --- If we move the nodiscard to the constructor, GCC errors out correctly.
[Bug c++/109235] nodiscard attribute on class not copied to the constructors
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109235 --- Comment #4 from Andrew Pinski --- (In reply to Andrew Pinski from comment #3) > If we move the nodiscard to the constructor, GCC errors out correctly. That is true even on the original testcase.
[Bug c++/95454] type-level nodiscard not applied to constructors
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95454 Andrew Pinski changed: What|Removed |Added Resolution|--- |DUPLICATE Status|UNCONFIRMED |RESOLVED --- Comment #4 from Andrew Pinski --- Dup of bug 85973. *** This bug has been marked as a duplicate of bug 85973 ***
[Bug c++/85973] [[nodiscard]] shall emit a warning for unused anonymous variable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85973 Andrew Pinski changed: What|Removed |Added CC||johelegp at gmail dot com --- Comment #1 from Andrew Pinski --- *** Bug 95454 has been marked as a duplicate of this bug. ***
[Bug c++/109235] nodiscard attribute on class not copied to the constructors
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109235 Andrew Pinski changed: What|Removed |Added Resolution|--- |DUPLICATE Status|NEW |RESOLVED --- Comment #5 from Andrew Pinski --- Dup of bug 85973. *** This bug has been marked as a duplicate of bug 85973 ***
[Bug c++/85973] [[nodiscard]] shall emit a warning for unused anonymous variable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85973 Andrew Pinski changed: What|Removed |Added CC||t...@bang-olufsen.dk --- Comment #2 from Andrew Pinski --- *** Bug 109235 has been marked as a duplicate of this bug. ***
[Bug c++/85973] [[nodiscard]] on class shall emit a warning for unused anonymous variable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85973
Andrew Pinski changed:
What|Removed |Added
Last reconfirmed||2023-03-21
Ever confirmed|0 |1
Summary|[[nodiscard]] shall emit a |[[nodiscard]] on class
|warning for unused |shall emit a warning for
|anonymous variable |unused anonymous variable
Status|UNCONFIRMED |NEW
--- Comment #3 from Andrew Pinski ---
Reduced testcase:
```
struct [[nodiscard]] scope_exit {
scope_exit(int);
};
int main()
{
scope_exit{0};
}
```
Note if we move the attribute to the constructor, then GCC will error out.
[Bug tree-optimization/109230] [13 Regression] Maybe wrong code for opus package on aarch64 since r13-4122-g1bc7efa948f751
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109230
--- Comment #6 from avieira at gcc dot gnu.org ---
Thanks!
My initial investigation has lead me to think the change is being caused at
vrp2, which is the only time the pattern gets triggered with -O2, the tree
before the pass (at the place where the transformation happens):
vect__83.466_787 = VEC_PERM_EXPR ;
vect__87.467_786 = vect__81.462_791 * vect__83.466_787;
vect__91.469_784 = vect__84.458_794 - vect__87.467_786;
vect__88.468_785 = vect__84.458_794 + vect__87.467_786;
_783 = VEC_PERM_EXPR ;
...
vect__96.470_782 = vect__95.450_800 - _783;
after the pass:
vect__83.466_787 = VEC_PERM_EXPR ;
vect__87.467_786 = vect__83.466_787 * vect__81.462_791;
vect__91.469_784 = vect__84.458_794 - vect__87.467_786;
vect__88.468_785 = vect__87.467_786 + vect__84.458_794;
_756 = VIEW_CONVERT_EXPR(vect__87.467_786);
_755 = -_756;
_739 = VIEW_CONVERT_EXPR(_755);
_783 = _739 + vect__84.458_794;
...
vect__96.470_782 = vect__95.450_800 - _783;
So before we had:
_783 = the first element of vect_88 and the second element of vect__91
these are respectively
vect__88 = vect__84 + vect__87
vect__91 = vect__84 - vect__87
so _783 = {vect__84[0] + vect__87[0], vect__84[1] - vect__87[1]}
after the pass
_783 = _739 + vect__84
This is where I don't know if I'm reading the optimization correctly, but it
says all 'even' lanes are negated, does that mean we end up with:
_739 = { -vect__87[0] , vect__87[1]}
if so then that's why we have a wrong result as you want to negate lane 1 not
0. Otherwise if lane 1 is the one that gets negated then it should be OK as
you'd get:
so _783 = { vect__87[0] + vect__84[0], -vect__87[1] + vect__84[1] }
Now obviously that's assuming -a + b == b - a (not sure if that's true with
floating point errors etc)
[Bug d/109231] [13 regression] Comparison failure in libphobos/libdruntime/rt/util/typeinfo.o
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109231 --- Comment #7 from Jakub Jelinek --- No luck reproducing this using a cross. So, could you please attach -fdump-tree-optimized -da dumps from both runs? Also, check if you are using the same d21 binary, another possibility might be miscompiled d21.
