[Bug tree-optimization/111355] [14 Regression] ICE on valid code at -O1 and above: in lower_bound, at value-range.h:1078
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111355
--- Comment #3 from CVS Commits ---
The master branch has been updated by Jiu Fu Guo :
https://gcc.gnu.org/g:4d80863d7f93c0a839d1fe5dc59be83153e89110
commit r14-4192-g4d80863d7f93c0a839d1fe5dc59be83153e89110
Author: Jiufu Guo
Date: Wed Sep 20 11:11:58 2023 +0800
check undefine_p for one more vr
The root cause of PR111355 and PR111482 is missing to check if vr0
is undefined_p before call vr0.lower_bound.
In the pattern "(X + C) / N",
(if (INTEGRAL_TYPE_P (type)
&& get_range_query (cfun)->range_of_expr (vr0, @0))
(if (...)
(plus (op @0 @2) { wide_int_to_tree (type, plus_op1 (c)); })
(if (TYPE_UNSIGNED (type) && c.sign_mask () < 0 ...
&& wi::geu_p (vr0.lower_bound (), -c))
In "(if (...)", there is code to prevent vr0's undefined_p,
But in the "else" part, vr0's undefined_p is not checked before
"wi::geu_p (vr0.lower_bound (), -c)".
PR tree-optimization/111355
gcc/ChangeLog:
* match.pd ((X + C) / N): Update pattern.
gcc/testsuite/ChangeLog:
* gcc.dg/pr111355.c: New test.
[Bug tree-optimization/111495] [14 regression] ICE in lower_bound, at value-range.h:1078 when building LLVM 17.0.1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111495 --- Comment #1 from Sam James --- Created attachment 55956 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55956=edit reduced.ii Attached minimised reproducer fails with -O3, works with -O2, per original.
[Bug modula2/111510] New: Modula-2 runtime ICE on arm-linux-gnueabihf: iso/RTentity.mod:245:in findChildAndParent has caused internal runtime error, RTentity is either corrupt or the module storage ha
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111510 Bug ID: 111510 Summary: Modula-2 runtime ICE on arm-linux-gnueabihf: iso/RTentity.mod:245:in findChildAndParent has caused internal runtime error, RTentity is either corrupt or the module storage has not been initialized yet Product: gcc Version: 13.2.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: modula2 Assignee: gaius at gcc dot gnu.org Reporter: doko at gcc dot gnu.org Target Milestone: --- seen with current gcc-13 branch, that used to work with GCC 12 before (although M2 was not yet merged at this time). running a simple HelloWorld.mod on arm-linux-gnueabihf fails with: 2746s autopkgtest [17:26:10]: test libgm2-link: [--- 2748s build: OK 2748s libm2cor.so.18 => /lib/arm-linux-gnueabihf/libm2cor.so.18 (0xf7eec000) 2748s libm2pim.so.18 => /lib/arm-linux-gnueabihf/libm2pim.so.18 (0xf7ec8000) 2748s libm2iso.so.18 => /lib/arm-linux-gnueabihf/libm2iso.so.18 (0xf7ea1000) 2748s libstdc++.so.6 => /lib/arm-linux-gnueabihf/libstdc++.so.6 (0xf7cf6000) 2748s libgcc_s.so.1 => /lib/arm-linux-gnueabihf/libgcc_s.so.1 (0xf7cdc000) 2748s libc.so.6 => /lib/arm-linux-gnueabihf/libc.so.6 (0xf7bac000) 2748s /lib/ld-linux-armhf.so.3 (0xf7eff000) 2748s libm.so.6 => /lib/arm-linux-gnueabihf/libm.so.6 (0xf7b6a000) 2748s ../../../../src/libgm2/libm2iso/../../gcc/m2/gm2-libs-iso/RTentity.mod:245:in findChildAndParent has caused internal runtime error, RTentity is either corrupt or the module storage has not been initialized yet 2749s autopkgtest [17:26:13]: test libgm2-link: ---]
[Bug target/111450] RISC-V: Missed optimized for strided load/store with stride = element width
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111450 --- Comment #1 from CVS Commits --- The master branch has been updated by Li Xu : https://gcc.gnu.org/g:47065ff360292c683670efb96df4b61f57dc1d9a commit r14-4190-g47065ff360292c683670efb96df4b61f57dc1d9a Author: xuli Date: Thu Sep 21 03:04:56 2023 + RISC-V: Optimized for strided load/store with stride == element width[PR111450] When stride == element width, vlsse should be optimized into vle.v. vsse should be optimized into vse.v. PR target/111450 gcc/ChangeLog: * config/riscv/constraints.md (c01): const_int 1. (c02): const_int 2. (c04): const_int 4. (c08): const_int 8. * config/riscv/predicates.md (vector_eew8_stride_operand): New predicate for stride operand. (vector_eew16_stride_operand): Ditto. (vector_eew32_stride_operand): Ditto. (vector_eew64_stride_operand): Ditto. * config/riscv/vector-iterators.md: New iterator for stride operand. * config/riscv/vector.md: Add stride = element width constraint. gcc/testsuite/ChangeLog: * gcc.target/riscv/rvv/base/pr111450.c: New test.
[Bug tree-optimization/111456] [14 Regression] Dead Code Elimination Regression since r14-3719-gb34f3736356
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111456 Andrew Pinski changed: What|Removed |Added URL||https://gcc.gnu.org/piperma ||il/gcc-patches/2023-Septemb ||er/631065.html Keywords||patch --- Comment #6 from Andrew Pinski --- Patch posted: https://gcc.gnu.org/pipermail/gcc-patches/2023-September/631065.html
[Bug ipa/108007] [11/12/13/14 Regression] wrong code at -Os and above with "-fno-dce -fno-tree-dce" on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108007 --- Comment #14 from Andrew Pinski --- *** Bug 111507 has been marked as a duplicate of this bug. ***
[Bug c/111507] Floating point exception with '-O3'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111507 Andrew Pinski changed: What|Removed |Added Resolution|--- |DUPLICATE Status|UNCONFIRMED |RESOLVED --- Comment #2 from Andrew Pinski --- _13 = removed_return.111_34(D) % _12; _14 = (long int) _13; _15 = -2446 % _14; Same issue as PR 108007 . *** This bug has been marked as a duplicate of bug 108007 ***
[Bug ipa/108007] [11/12/13/14 Regression] wrong code at -Os and above with "-fno-dce -fno-tree-dce" on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108007 --- Comment #13 from Andrew Pinski --- *** Bug 111509 has been marked as a duplicate of this bug. ***
[Bug c/111509] Floating point exception with '-O3 -fno-dce -fno-inline-small-functions -fno-tree-dce -fno-tree-dominator-opts -fno-tree-dse'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111509 Andrew Pinski changed: What|Removed |Added Resolution|--- |DUPLICATE Status|UNCONFIRMED |RESOLVED --- Comment #2 from Andrew Pinski --- _145 = (unsigned int) removed_return.91_186(D); _146 = 1365587247 % _145; Same issue as PR 108007. *** This bug has been marked as a duplicate of bug 108007 ***
[Bug ipa/108007] [11/12/13/14 Regression] wrong code at -Os and above with "-fno-dce -fno-tree-dce" on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108007 --- Comment #12 from Andrew Pinski --- *** Bug 111508 has been marked as a duplicate of this bug. ***
[Bug c/111508] Floating point exception with '-O3 -fno-dce -fno-early-inlining -fno-tree-dce -fno-tree-dse'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111508 Andrew Pinski changed: What|Removed |Added Resolution|--- |DUPLICATE Status|UNCONFIRMED |RESOLVED --- Comment #2 from Andrew Pinski --- Same issue as PR 108007 . *** This bug has been marked as a duplicate of bug 108007 ***
[Bug c/111509] Floating point exception with '-O3 -fno-dce -fno-inline-small-functions -fno-tree-dce -fno-tree-dominator-opts -fno-tree-dse'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111509 --- Comment #1 from CTC <19373742 at buaa dot edu.cn> --- Created attachment 55955 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55955=edit The compiler output
[Bug c/111509] New: Floating point exception with '-O3 -fno-dce -fno-inline-small-functions -fno-tree-dce -fno-tree-dominator-opts -fno-tree-dse'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111509 Bug ID: 111509 Summary: Floating point exception with '-O3 -fno-dce -fno-inline-small-functions -fno-tree-dce -fno-tree-dominator-opts -fno-tree-dse' 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 55954 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55954=edit The preprocessed file *** OS and Platform: Ubuntu 20.04.4 LTS *** gcc version: $ gcc -v Using built-in specs. COLLECT_GCC=/home/cuisk/ctc/gcc-releases/gcc-14/bin/gcc COLLECT_LTO_WRAPPER=/home/cuisk/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 20230917 (experimental) (GCC) *** Command Lines: $ gcc -I /home/csmith/include/csmith-2.3.0 -O3 -fno-dce -fno-inline-small-functions -fno-tree-dce -fno-tree-dominator-opts -fno-tree-dse a.c -o work 2> ge.out $ ./work Floating point exception (core dumped)
[Bug c/111508] Floating point exception with '-O3 -fno-dce -fno-early-inlining -fno-tree-dce -fno-tree-dse'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111508 --- Comment #1 from CTC <19373742 at buaa dot edu.cn> --- Created attachment 55953 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55953=edit The compiler output
[Bug c/111508] New: Floating point exception with '-O3 -fno-dce -fno-early-inlining -fno-tree-dce -fno-tree-dse'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111508 Bug ID: 111508 Summary: Floating point exception with '-O3 -fno-dce -fno-early-inlining -fno-tree-dce -fno-tree-dse' 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 55952 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55952=edit The preprocessed file *** OS and Platform: Ubuntu 20.04.4 LTS *** gcc version: $ gcc -v Using built-in specs. COLLECT_GCC=/home/cuisk/ctc/gcc-releases/gcc-14/bin/gcc COLLECT_LTO_WRAPPER=/home/cuisk/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 20230917 (experimental) (GCC) *** Command Lines: $ gcc -I /home/csmith/include/csmith-2.3.0 -O3 -fno-dce -fno-early-inlining -fno-tree-dce -fno-tree-dse -save-temps a.c -o fails2 2> fe.out $ ./fails2 Floating point exception (core dumped)
[Bug c/111507] Floating point exception with '-O3'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111507 --- Comment #1 from CTC <19373742 at buaa dot edu.cn> --- Created attachment 55951 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55951=edit The compiler output
[Bug c/111507] New: Floating point exception with '-O3'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111507 Bug ID: 111507 Summary: Floating point exception with '-O3' Product: gcc Version: 13.2.1 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 55950 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55950=edit The preprocessed file *** OS and Platform: Ubuntu 20.04.4 LTS *** gcc version: $ gcc -v Using built-in specs. COLLECT_GCC=/home/cuisk/ctc/gcc-releases/gcc-13/bin/gcc COLLECT_LTO_WRAPPER=/home/cuisk/ctc/gcc-releases/gcc-13/libexec/gcc/x86_64-pc-linux-gnu/13.2.1/lto-wrapper Target: x86_64-pc-linux-gnu Configured with: ./configure --prefix=/home/cuisk/ctc/gcc-releases/gcc-13 --disable-multilib --enable-language=c,c++ Thread model: posix Supported LTO compression algorithms: zlib gcc version 13.2.1 20230916 (GCC) *** Command Lines: $ gcc -I /home/ctc/csmith/include/csmith-2.3.0 -O3 -fno-dce -fno-forward-propagate -fno-inline-functions-called-once -fno-inline-small-functions -fno-ipa-reference-addressable -fno-rerun-cse-after-loop -fno-tree-dce -fno-tree-dse a.c -o fails 2>tmp.out $ ./fails Floating point exception (core dumped)
[Bug c/111506] New: RISC-V: Failed to vectorize conversion from INT64 -> _Float16
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111506
Bug ID: 111506
Summary: RISC-V: Failed to vectorize conversion from INT64 ->
_Float16
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
void foo (int64_t *__restrict a, _Float16 * b, int n)
{
for (int i = 0; i < n; i++) {
b[i] = (_Float16)a[i];
}
}
-march=rv64gcv_zvfh_zfh -O3 -fno-trapping-math -fopt-info-vec-missed
-march=rv64gcv_zvfh_zfh -O3 -ffast-math -fopt-info-vec-missed
:5:23: missed: couldn't vectorize loop
:6:27: missed: not vectorized: no vectype for stmt: _4 = *_3;
scalar_type: int64_t
Compiler returned: 0
https://godbolt.org/z/orevoq7E1
Consider LLVM can vectorize with -fno-trapping-math.
However, LLVM can not vectorize when -ftrapping-math.
So, we need an explicit patterns from INT64 -> _Float16 with
!flag_trapping_math
[Bug tree-optimization/106164] (a > b) & (a >= b) does not get optimized until reassoc1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106164
--- Comment #21 from Andrew Pinski ---
(In reply to Andrew Pinski from comment #18)
> I think the only thing left is supporting floating point.
Another testcase for integer but with a nop_conversion:
```
int f(int a)
{
unsigned b = a;
int t = (b >= 3);
return t | (a == 0);
}
```
Without the nop_conversion, the pattern:
/* y == XXX_MIN || x < y --> x <= y - 1 */
(simplify
(bit_ior:c (eq:s @1 min_value) (lt:cs @0 @1))
(if (INTEGRAL_TYPE_P (TREE_TYPE (@1))
&& TYPE_OVERFLOW_WRAPS (TREE_TYPE (@1)))
(le @0 (minus @1 { build_int_cst (TREE_TYPE (@1), 1); }
Hits.
I will look into supporting the case where there is a nop_conversion for the @0
in the lt ...
[Bug tree-optimization/111456] [14 Regression] Dead Code Elimination Regression since r14-3719-gb34f3736356
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111456 --- Comment #5 from Andrew Pinski --- Just a quick note, --param=logical-op-non-short-circuit=0 also allows the missed optimization to no longer to be missed.
[Bug c++/111504] compare operator not defined for recursive data types on C++20
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111504
--- Comment #2 from Xiang Gao ---
(In reply to Andrew Pinski from comment #1)
> Fails for the same reason with clang (both with libstdc++ and libc++)
>
> Are you sure this is valid C++ 20 code?
I am not 100% sure, but my understanding is, for the SFINAE in
inline constexpr bool operator<(const DT& x, const DT& y)
The first condition
hasLessThan::value
is just hasLessThan::value, which should be true, and (true
|| anything) is always true.
So the condition in SFINAE should be easily evaluated as true. So the operator<
for DynamicType should be defined.
And if operator< is defined, then the operator<=> of std::vector
should also be defined. This can be validated by changing the definition of
operator< by only keeping the first condition:
template <
typename DT,
typename = std::enable_if_t<
(hasLessThan::value)>>
inline constexpr bool operator<(const DT& x, const DT& y) {
// implementation omitted
return true;
}
and then both g++ and clang++ will pass.
I do observe the same error on clang, but this https://cpp.sh/ seems to compile
without problem on C++20.
[Bug middle-end/111505] Asan (address-sanitizer) bootstrap fails since r14-4003-geaa8e8541349df
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111505
Andrew Pinski changed:
What|Removed |Added
Target Milestone|--- |14.0
Keywords||GC
Component|bootstrap |middle-end
--- Comment #1 from Andrew Pinski ---
Hmm:
from gtype-desc.cc:
{
_n_trees[0].signed_type,
1 * (NUM_INT_N_ENTS),
sizeof (int_n_trees[0]),
_ggc_mx_tree_node,
_pch_nx_tree_node
},
{
_n_trees[0].unsigned_type,
1 * (NUM_INT_N_ENTS),
sizeof (int_n_trees[0]),
_ggc_mx_tree_node,
_pch_nx_tree_node
},
That looks wrong ...
[Bug bootstrap/111505] New: Asan (address-sanitizer) bootstrap fails since r14-4003-geaa8e8541349df
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111505 Bug ID: 111505 Summary: Asan (address-sanitizer) bootstrap fails since r14-4003-geaa8e8541349df Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap Assignee: unassigned at gcc dot gnu.org Reporter: jamborm at gcc dot gnu.org CC: dmalcolm at gcc dot gnu.org, fkastl at suse dot cz Blocks: 86656 Target Milestone: --- Host: x86_64-linux-gnu Target: x86_64-linux-gnu Bootstrapping with active address sanitizer fails at the beginning of stage 3 since r14-4003-geaa8e8541349df (ggc, jit: forcibly clear GTY roots in jit). To reproduce, use --with-build-config=bootstrap-asan at configure time, for example: ../src/configure --prefix=/home/user/install/prefix --enable-languages=c,c++ --enable-checking=release --enable-host-shared --disable-multilib --with-build-config=bootstrap-asan and run make (and wait). At least one failure happens during configure script run of libiberty, which fails with "C compiler cannot create executables" and the corresponding config.log contains the following ASAN errors: configure:3470: /home/mjambor/gcc/mine/b-obj/./prev-gcc/xgcc -B/home/mjambor/gcc/mine/b-obj/./prev-gcc/ -B/home/mjambor/gcc/mine/inst/x86_64-pc-linux-gnu/bin/ -B/home/mjambor/gcc/mine/inst/x86_64-pc-linux-gnu/bin/ -B/home/mjambor/gcc/mine/inst/x86_64-pc-linux-gnu/lib/ -isystem /home/mjambor/gcc/mine/inst/x86_64-pc-linux-gnu/include -isystem /home/mjambor/gcc/mine/inst/x86_64-pc-linux-gnu/sys-include -fchecking=1 -o conftest -g -O2 -fchecking=1 -fsanitize=address -static-libstdc++ -static-libgcc -fsanitize=address -static-libasan -B/home/mjambor/gcc/mine/b-obj/prev-x86_64-pc-linux-gnu/libsanitizer/ -B/home/mjambor/gcc/mine/b-obj/prev-x86_64-pc-linux-gnu/libsanitizer/asan/ -B/home/mjambor/gcc/mine/b-obj/prev-x86_64-pc-linux-gnu/libsanitizer/asan/.libs conftest.c >&5 = ==2683==ERROR: AddressSanitizer: global-buffer-overflow on address 0x0718d4d0 at pc 0x007cd234 bp 0x7ffdc15756e0 sp 0x7ffdc1574ea0 WRITE of size 16 at 0x0718d4d0 thread T0 #0 0x7cd233 in __interceptor_memset /home/mjambor/gcc/mine/src/libsanitizer/sanitizer_common/sanitizer_common_interceptors.inc:847 #1 0x12151ab in ggc_common_finalize() /home/mjambor/gcc/mine/src/gcc/ggc-common.cc:1311 #2 0x1dad8ef in toplev::finalize() /home/mjambor/gcc/mine/src/gcc/toplev.cc:2354 #3 0x796732 in main /home/mjambor/gcc/mine/src/gcc/main.cc:42 #4 0x7f74182281af in __libc_start_call_main (/lib64/libc.so.6+0x281af) (BuildId: 7729cbd8376d2b42276cc2cc10693449ff810847) #5 0x7f7418228278 in __libc_start_main@@GLIBC_2.34 (/lib64/libc.so.6+0x28278) (BuildId: 7729cbd8376d2b42276cc2cc10693449ff810847) #6 0x797e84 in _start ../sysdeps/x86_64/start.S:115 0x0718d4d0 is located 48 bytes before global variable 'int_n_enabled_p' defined in '/home/mjambor/gcc/mine/src/gcc/tree.cc:234:6' (0x718d500) of size 1 0x0718d4d0 is located 0 bytes after global variable 'int_n_trees' defined in '/home/mjambor/gcc/mine/src/gcc/tree.cc:235:22' (0x718d4c0) of size 16 SUMMARY: AddressSanitizer: global-buffer-overflow /home/mjambor/gcc/mine/src/libsanitizer/sanitizer_common/sanitizer_common_interceptors.inc:847 in __interceptor_memset Shadow bytes around the buggy address: 0x0718d200: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x0718d280: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x0718d300: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x0718d380: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x0718d400: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 =>0x0718d480: 00 00 00 00 f9 f9 f9 f9 00 00[f9]f9 f9 f9 f9 f9 0x0718d500: 01 f9 f9 f9 f9 f9 f9 f9 00 00 00 00 00 00 00 00 0x0718d580: 00 00 00 00 00 00 00 00 00 00 00 f9 f9 f9 f9 f9 0x0718d600: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x0718d680: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x0718d700: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 Shadow byte legend (one shadow byte represents 8 application bytes): Addressable: 00 Partially addressable: 01 02 03 04 05 06 07 Heap left redzone: fa Freed heap region: fd Stack left redzone: f1 Stack mid redzone: f2 Stack right redzone: f3 Stack after return: f5 Stack use after scope: f8 Global redzone: f9 Global init order: f6 Poisoned by user:f7 Container overflow: fc Array cookie:ac Intra object redzone:bb ASan internal: fe Left alloca redzone: ca Right alloca redzone:cb ==2683==ABORTING [...] configure:3708: /home/mjambor/gcc/mine/b-obj/./prev-gcc/xgcc
[Bug c++/111504] compare operator not defined for recursive data types on C++20
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111504 --- Comment #1 from Andrew Pinski --- Fails for the same reason with clang (both with libstdc++ and libc++) Are you sure this is valid C++ 20 code?
[Bug preprocessor/90400] _Pragma not always expanded in the right location within macros
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90400 Lewis Hyatt changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #10 from Lewis Hyatt --- Marking it fixed now that the testcase is added.
[Bug preprocessor/61474] ICE (segfault) in preprocessor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61474 Lewis Hyatt changed: What|Removed |Added CC||lhyatt at gcc dot gnu.org Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED Target Milestone|--- |14.0 --- Comment #4 from Lewis Hyatt --- Thanks for the testcase, this is fixed for GCC 14.
[Bug preprocessor/90400] _Pragma not always expanded in the right location within macros
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90400 --- Comment #9 from CVS Commits --- The master branch has been updated by Lewis Hyatt : https://gcc.gnu.org/g:d8e08ba9396b1f7da50011468f260250b7afaab7 commit r14-4186-gd8e08ba9396b1f7da50011468f260250b7afaab7 Author: Lewis Hyatt Date: Fri Aug 25 15:57:19 2023 -0400 testsuite: Add test for already-fixed issue with _Pragma expansion [PR90400] The PR was fixed by r12-5454. Since the fix was somewhat incidental, although related, add a testcase from PR90400 too before closing it out. gcc/testsuite/ChangeLog: PR preprocessor/90400 * c-c++-common/cpp/pr90400.c: New test.
[Bug preprocessor/61474] ICE (segfault) in preprocessor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61474 --- Comment #3 from CVS Commits --- The master branch has been updated by Lewis Hyatt : https://gcc.gnu.org/g:601dbf2a799f691688dfe78250b5bea2717b5b5e commit r14-4185-g601dbf2a799f691688dfe78250b5bea2717b5b5e Author: Lewis Hyatt Date: Fri Sep 15 13:31:51 2023 -0400 libcpp: Fix ICE on #include after a line marker directive [PR61474] As noted in the PR, GCC will segfault if a file name is first seen in a linemarker directive, and then later seen in a normal #include. This is because the fake include process adds the file to the cache with a null PATH member. The normal #include finds this file in the cache and then attempts to use the null PATH. Resolve by adding the file to the cache with a unique starting directory, so that the fake entry will only be found by a subsequent fake include, not by a real one. libcpp/ChangeLog: PR preprocessor/61474 * files.cc (_cpp_find_file): Set DONT_READ to TRUE for fake include files. (_cpp_fake_include): Pass a unique cpp_dir* address so the fake file will not be found when looked up for real. gcc/testsuite/ChangeLog: PR preprocessor/61474 * c-c++-common/cpp/pr61474-2.h: New test. * c-c++-common/cpp/pr61474.c: New test. * c-c++-common/cpp/pr61474.h: New test.
[Bug c++/111504] New: compare operator not defined for recursive data types on C++20
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111504
Bug ID: 111504
Summary: compare operator not defined for recursive data types
on C++20
Product: gcc
Version: 13.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: xgao at nvidia dot com
Target Milestone: ---
Related bug: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111316
The following code works on C++17 but not C++20:
#include
#include
#include
template
static auto hasLessThanHelper(int)
-> decltype(std::declval() < std::declval(), std::true_type{});
template
static auto hasLessThanHelper(long) -> std::false_type;
template
struct hasLessThan : decltype(hasLessThanHelper(0)) {};
struct DynamicType {
using T1 = int64_t;
using T2 = std::vector;
};
template <
typename DT,
typename = std::enable_if_t<
(hasLessThan::value ||
hasLessThan::value ||
hasLessThan::value ||
hasLessThan::value)>>
inline constexpr bool operator<(const DT& x, const DT& y) {
// implementation omitted
return true;
}
int main() {
using DT = DynamicType;
// This assert works on C++17, but fails on C++20
static_assert(hasLessThan, std::vector>::value);
}
[Bug middle-end/111502] Suboptimal unaligned 2/4-byte memcpy on strict-align targets
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111502 --- Comment #6 from Andrew Waterman --- Ack, I misunderstood your earlier message. You're of course right that the load/load/shift/or sequence is preferable to the load/load/store/store/load sequence, on just about any practical implementation. That the memcpy version is optimized less optimally does seem to be disjoint from the issue Andrew mentioned.
[Bug fortran/111503] New: Issues with POINTER, OPTIONAL, CONTIGUOUS dummy arguments
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111503 Bug ID: 111503 Summary: Issues with POINTER, OPTIONAL, CONTIGUOUS dummy arguments Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: anlauf at gcc dot gnu.org Target Milestone: --- The following code shows an issue that popped up while looking at pr55978: program test implicit none integer, pointer, contiguous :: p(:) => null() print *, is_contiguous (p) call one (p) ! accepted call one ()! accepted (but see pr55978 comment#19) call one (null()) ! rejected, but accepted by NAG, Intel call one (null(p)) ! rejected by NAG, accepted by Intel contains subroutine one (x) integer, pointer, optional, contiguous, intent(in) :: x(:) ! integer, optional, contiguous, intent(in) :: x(:) ! accepted end subroutine one end Intel accepts the code as-is. NAG complains that NULL(p) is not contiguous: Error: pr11.f90, line 8: Argument X (no. 1) of ONE is a CONTIGUOUS pointer, but the actual argument NULL(P) is not simply contiguous I guess that NAG is correct here, and Intel does not properly diagnose. gfortran is maybe overly "cautious" and gives: pr11.f90:7:12: 7 | call one (null()) ! rejected, but accepted by NAG, Intel |1 Error: Actual argument to contiguous pointer dummy 'x' at (1) must be simply contiguous pr11.f90:8:12: 8 | call one (null(p)) ! rejected by NAG, accepted by Intel |1 Error: Actual argument to contiguous pointer dummy 'x' at (1) must be simply contiguous As - in the current context - null() is equivalent to an absent actual argument, I wonder whether we should relax our checks and follow NAG and Intel.
[Bug middle-end/111502] Suboptimal unaligned 2/4-byte memcpy on strict-align targets
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111502 --- Comment #5 from Lasse Collin --- If I understood correctly, PR 50417 is about wishing that GCC would infer that a pointer given to memcpy has alignment higher than one. In my examples the alignment of the uint8_t *b argument is one and thus byte-by-byte access is needed (if the target processor doesn't have fast unaligned access, determined from -mtune and -mno-strict-align). My report is about the instruction sequence used for the byte-by-byte access. Omitting the stack pointer manipulation and return instruction, this is bytes16: lbu a5,1(a0) lbu a0,0(a0) sllia5,a5,8 or a0,a5,a0 And copy16: lbu a4,0(a0) lbu a5,1(a0) sb a4,14(sp) sb a5,15(sp) lhu a0,14(sp) Is the latter as good code as the former? If yes, then this report might be invalid and I apologize for the noise. PR 50417 includes a case where a memcpy(a, b, 4) generates an actual call to memcpy, so that is the same detail as the -Os case in my first message. Calling memcpy instead of expanding it inline saves six bytes in RV64C. On ARM64 with -Os -mstrict-align the call doesn't save space: bytes32: ldrbw1, [x0] ldrbw2, [x0, 1] orr x2, x1, x2, lsl 8 ldrbw1, [x0, 2] ldrbw0, [x0, 3] orr x1, x2, x1, lsl 16 orr w0, w1, w0, lsl 24 ret copy32: stp x29, x30, [sp, -32]! mov x1, x0 mov x2, 4 mov x29, sp add x0, sp, 28 bl memcpy ldr w0, [sp, 28] ldp x29, x30, [sp], 32 ret And ARM64 with -O2 -mstrict-align, shuffing via stack is longer too: bytes32: ldrbw4, [x0] ldrbw2, [x0, 1] ldrbw1, [x0, 2] ldrbw3, [x0, 3] orr x2, x4, x2, lsl 8 orr x0, x2, x1, lsl 16 orr w0, w0, w3, lsl 24 ret copy32: sub sp, sp, #16 ldrbw3, [x0] ldrbw2, [x0, 1] ldrbw1, [x0, 2] ldrbw0, [x0, 3] strbw3, [sp, 12] strbw2, [sp, 13] strbw1, [sp, 14] strbw0, [sp, 15] ldr w0, [sp, 12] add sp, sp, 16 ret ARM64 with -mstrict-align might be a contrived example in practice though.
[Bug fortran/107716] Getting negative values with NINT when using doubleprecision values in range on i386
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107716 --- Comment #6 from Steve Kargl --- On Wed, Sep 20, 2023 at 07:07:37PM +, mikael at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107716 > > --- Comment #5 from Mikael Morin --- > (In reply to kargl from comment #4) > > What the heck does "RESOLVED MOVED"? > > I think it means this PR is not a gcc bug and the problem is tracked on some > other project's bug tracker (it is "moved" there). > > Not sure where else the problem is tracked in this case. > Thanks, Mikael. After a bit of duck-duck-go, I've come to a similar conclusion. <$0.02> If a url/pointer to where the bug is actually tracked is not available, this status should not be used. It is useless. I'll also note that if one clicks on the 'status:' label a list of stati (statuses?) and their meaining can be found. MOVED is not among the list.
[Bug target/111500] [arm-none-eabi-gcc] / suboptimal optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111500
--- Comment #2 from Luke ---
(In reply to Andrew Pinski from comment #1)
> Can you attach (compilible) examples code for each issue? Really these
> should be filed seperately too.
do u mean, i should file 3 further bug reports?
i try examples for artifact #1 first...
is it right like this?
example code for artifact #1a:
// "cmp" follows the "subs" immediately
__attribute((noinline)) void artiSUBS() {
for (int i=100; i>0; i--)
200017ec: 2364movsr3, #100; 0x64
*(volatile int*)0xE000E014 = i;
200017ee: 4a03ldr r2, [pc, #12] ; (200017fc)
200017f0: 6013str r3, [r2, #0]
for (int i=100; i>0; i--)
200017f2: 3b01subsr3, #1
200017f4: 2b00cmp r3, #0
200017f6: d1fbbne.n 200017f0
}
200017f8: 4770bx lr
200017fa: 46c0nop
200017fc: e000e014
example code for artifact #1b:
// gcc tends to do the "i--" too early; "ldr" does not touch flags
// maybe because it hopes to get beneficial pipeline effects at loop entry?
__attribute((noinline)) void artiSUBS() {
200017ec: 2364movsr3, #100; 0x64
for (int i=100; i>0; i--)
(void) *(volatile int*)0xE000E014;
200017ee: 4a03ldr r2, [pc, #12] ; (200017fc)
200017f0: 3b01subsr3, #1
200017f2: 6811ldr r1, [r2, #0]
for (int i=100; i>0; i--)
200017f4: 2b00cmp r3, #0
200017f6: d1fbbne.n 200017f0
}
200017f8: 4770bx lr
200017fa: 46c0nop
200017fc: e000e014
[Bug fortran/107716] Getting negative values with NINT when using doubleprecision values in range on i386
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107716 Mikael Morin changed: What|Removed |Added CC||mikael at gcc dot gnu.org --- Comment #5 from Mikael Morin --- (In reply to kargl from comment #4) > What the heck does "RESOLVED MOVED"? I think it means this PR is not a gcc bug and the problem is tracked on some other project's bug tracker (it is "moved" there). Not sure where else the problem is tracked in this case.
[Bug middle-end/111502] Suboptimal unaligned 2/4-byte memcpy on strict-align targets
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111502 Andrew Pinski changed: What|Removed |Added Depends on||50417 --- Comment #4 from Andrew Pinski --- See pr 50417 Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=50417 [Bug 50417] [11/12/13/14 regression]: memcpy with known alignment
[Bug middle-end/111502] Suboptimal unaligned 2/4-byte memcpy on strict-align targets
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111502 Andrew Pinski changed: What|Removed |Added Component|target |middle-end --- Comment #3 from Andrew Pinski --- This is a dup of this bug. Basically memcpy is not changed into an unaligned load ..
[Bug target/111502] Suboptimal unaligned 2/4-byte memcpy on strict-align targets
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111502 --- Comment #2 from Lasse Collin --- Byte access by default is good when the compiler doesn't know if unaligned is fast on the target processor. There is no disagreement here. What I suspect is a bug is the instruction sequence used for byte access in copy16 and copy32 cases. copy16 uses 2 * lbu + 2 * sb + 1 * lhu, that is, five memory operations to load an unaligned 16-bit integer. copy32 uses 4 * lbu + 4 * sb + 1 * lw, that is, nine memory operations to load a 32-bit integer. bytes16 needs two memory operations and bytes32 needs four. Clang generates this kind of code from both bytesxx and copyxx.
[Bug fortran/107716] Getting negative values with NINT when using doubleprecision values in range on i386
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107716 --- Comment #4 from kargl at gcc dot gnu.org --- What the heck does "RESOLVED MOVED"?
[Bug tree-optimization/111502] Suboptimal unaligned 2/4-byte memcpy on strict-align targets
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111502 Andrew Waterman changed: What|Removed |Added CC||andrew at sifive dot com --- Comment #1 from Andrew Waterman --- This isn't actually a bug. Quoting the RVA profile spec, "misaligned loads and stores might execute extremely slowly"--which is code for the possibility that they might be trapped and emulated, taking hundreds of clock cycles apiece. So the default behavior of emitting byte accesses is best when generating generic code. (Of course, when tuning for a particular microarchitecture, the shorter code sequence may be emitted.)
[Bug tree-optimization/111502] New: Suboptimal unaligned 2/4-byte memcpy on strict-align targets
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111502
Bug ID: 111502
Summary: Suboptimal unaligned 2/4-byte memcpy on strict-align
targets
Product: gcc
Version: 13.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: lasse.collin at tukaani dot org
Target Milestone: ---
I was playing with RISC-V GCC 12.2.0 from Arch Linux. I noticed
inefficient-looking assembly output in code that uses memcpy to access 32-bit
unaligned integers. I tried Godbolt with 16/32-bit integers and seems that the
same weirdness happens with RV32 & RV64 with GCC 13.2.0 and trunk, and also on
a few other targets. (Clang's output looks OK.)
For a little endian target:
#include
#include
uint32_t bytes16(const uint8_t *b)
{
return (uint32_t)b[0]
| ((uint32_t)b[1] << 8);
}
uint32_t copy16(const uint8_t *b)
{
uint16_t v;
memcpy(, b, sizeof(v));
return v;
}
riscv64-linux-gnu-gcc -march=rv64gc -O2 -mtune=size
bytes16:
lhu a0,0(a0)
ret
copy16:
lhu a0,0(a0)
ret
That looks good because -mno-strict-align is the default.
After omitting -mtune=size, unaligned access isn't used (the output is the same
as with -mstrict-align):
riscv64-linux-gnu-gcc -march=rv64gc -O2
bytes16:
lbu a5,1(a0)
lbu a0,0(a0)
sllia5,a5,8
or a0,a5,a0
ret
copy16:
lbu a4,0(a0)
lbu a5,1(a0)
addisp,sp,-16
sb a4,14(sp)
sb a5,15(sp)
lhu a0,14(sp)
addisp,sp,16
jr ra
bytes16 looks good but copy16 is weird: the bytes are copied to an aligned
location on stack and then loaded back.
On Godbolt it happens with GCC 13.2.0 on RV32, RV64, ARM64 (but only if using
-mstrict-align), MIPS64EL, and SPARC & SPARC64 (comparison needs big endian
bytes16). For ARM64 and MIPS64EL the oldest GCC on Godbolt is GCC 5.4 and the
same thing happens with that too.
32-bit reads with -O2 behave similarly. With -Os a call to memcpy is emitted
for copy32 but not for bytes32.
#include
#include
uint32_t bytes32(const uint8_t *b)
{
return (uint32_t)b[0]
| ((uint32_t)b[1] << 8)
| ((uint32_t)b[2] << 16)
| ((uint32_t)b[3] << 24);
}
uint32_t copy32(const uint8_t *b)
{
uint32_t v;
memcpy(, b, sizeof(v));
return v;
}
riscv64-linux-gnu-gcc -march=rv64gc -O2
bytes32:
lbu a4,1(a0)
lbu a3,0(a0)
lbu a5,2(a0)
lbu a0,3(a0)
sllia4,a4,8
or a4,a4,a3
sllia5,a5,16
or a5,a5,a4
sllia0,a0,24
or a0,a0,a5
sext.w a0,a0
ret
copy32:
lbu a2,0(a0)
lbu a3,1(a0)
lbu a4,2(a0)
lbu a5,3(a0)
addisp,sp,-16
sb a2,12(sp)
sb a3,13(sp)
sb a4,14(sp)
sb a5,15(sp)
lw a0,12(sp)
addisp,sp,16
jr ra
riscv64-linux-gnu-gcc -march=rv64gc -Os
bytes32:
lbu a4,1(a0)
lbu a5,0(a0)
sllia4,a4,8
or a4,a4,a5
lbu a5,2(a0)
lbu a0,3(a0)
sllia5,a5,16
or a5,a5,a4
sllia0,a0,24
or a0,a0,a5
sext.w a0,a0
ret
copy32:
addisp,sp,-32
mv a1,a0
li a2,4
addia0,sp,12
sd ra,24(sp)
callmemcpy@plt
ld ra,24(sp)
lw a0,12(sp)
addisp,sp,32
jr ra
I probably cannot test any proposed fixes but I hope this report is still
useful. Thanks!
[Bug c++/111493] [concepts] multidimensional subscript operator inside requires is broken
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111493 --- Comment #2 from Chris Elrod --- Note that it also shows up in gcc-13. I put gcc-14 as the version to indicate that I confirmed it is still a problem on latest trunk. Not sure what the policy is on which version we should report.
[Bug middle-end/111483] [14 Regression] ICE in to_sreal, at profile-count.cc:472
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111483 Andrew Pinski changed: What|Removed |Added Resolution|--- |DUPLICATE Status|NEW |RESOLVED --- Comment #3 from Andrew Pinski --- Dup of bug 111054. *** This bug has been marked as a duplicate of bug 111054 ***
[Bug middle-end/111054] [14 Regression] ICE: in to_sreal, at profile-count.cc:472 with -O3 -fno-guess-branch-probability
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111054 Andrew Pinski changed: What|Removed |Added CC||19373742 at buaa dot edu.cn --- Comment #3 from Andrew Pinski --- *** Bug 111483 has been marked as a duplicate of this bug. ***
[Bug c++/103524] [meta-bug] modules issue
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103524 Bug 103524 depends on bug 104993, which changed state. Bug 104993 Summary: [modules] Missing diagnostic when exporting using-directive https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104993 What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED
[Bug c++/104993] [modules] Missing diagnostic when exporting using-directive
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104993 Johel Ernesto Guerrero Peña changed: What|Removed |Added Resolution|--- |FIXED Status|UNCONFIRMED |RESOLVED --- Comment #1 from Johel Ernesto Guerrero Peña --- > [module.interface]p3s1 says > > An exported declaration that is not a module-import-declaration shall > > declare at least one name. Removed by "DR20: Meaningful exports P2615R0".
[Bug target/111501] RISC-V: non-optimal casting when shifting
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111501 Andrew Pinski changed: What|Removed |Added CC||pinskia at gcc dot gnu.org --- Comment #2 from Andrew Pinski --- I think there might be a dup of this bug already. Also with zbb, GCC gets: srlia0,a0,32 zext.h a0,a0 ret
[Bug target/111501] RISC-V: non-optimal casting when shifting
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111501 palmer at gcc dot gnu.org changed: What|Removed |Added Last reconfirmed||2023-09-20 Keywords||missed-optimization Status|UNCONFIRMED |NEW Component|c |target Ever confirmed|0 |1 CC||palmer at gcc dot gnu.org, ||vineetg at gcc dot gnu.org --- Comment #1 from palmer at gcc dot gnu.org --- Adding Vineet.
[Bug c++/111496] Optimizer issue when reinitializing an object of a standard-layout class with a trivial copy constructor and a trivial destructor but with padding bytes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111496
Andrew Pinski changed:
What|Removed |Added
Summary|Optimizer issue when|Optimizer issue when
|reinitializing an object of |reinitializing an object of
|a standard-layout class |a standard-layout class
|with a trivial copy |with a trivial copy
|constructor and a trivial |constructor and a trivial
|destructor |destructor but with padding
||bytes
--- Comment #1 from Andrew Pinski ---
So your class examples all have padding in it (which you can get a warning with
-Wpadded ).
Once you remove the padding (via adding another field at the end):
```
int b[4] = {};
char* p = {};
int x = {};
int t = {};
```
The code gets better.
So the big question should padding bytes should be copied or not ...
[Bug target/110751] RISC-V: Suport undefined value that allows VSETVL PASS use TA/MA
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110751 --- Comment #42 from CVS Commits --- The master branch has been updated by Robin Dapp : https://gcc.gnu.org/g:27282dc0931484c31fa391772499d878afcc746a commit r14-4179-g27282dc0931484c31fa391772499d878afcc746a Author: Juzhe-Zhong Date: Wed Sep 20 22:58:49 2023 +0800 internal-fn: Support undefined rtx for uninitialized SSA_NAME[PR110751] According to PR: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110751 As Richard and Richi suggested, we recognize uninitialized SSA_NAME and convert it into SCRATCH rtx if the target predicate allows SCRATCH. It can help to reduce redundant data move instructions of targets like RISC-V. Bootstrap and Regression on x86 passed. gcc/ChangeLog: PR target/110751 * internal-fn.cc (expand_fn_using_insn): Support undefined rtx value. * optabs.cc (maybe_legitimize_operand): Ditto. (can_reuse_operands_p): Ditto. * optabs.h (enum expand_operand_type): Ditto. (create_undefined_input_operand): Ditto.
[Bug c/111501] New: RISC-V: non-optimal casting when shifting
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111501
Bug ID: 111501
Summary: RISC-V: non-optimal casting when shifting
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: charlie at rivosinc dot com
Target Milestone: ---
Created attachment 55949
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55949=edit
tar file of -save-temps output
I would expect the first to be able to compile into the second:
unsigned int do_shift(unsigned long csum)
{
return (unsigned short)(csum >> 32);
}
unsigned int do_shift2(unsigned long csum)
{
return (csum << 16) >> 48;
}
However, the asm output is instead:
do_shift:
srlia0,a0,32
sllia0,a0,48
srlia0,a0,48
ret
do_shift2:
sllia0,a0,16
srlia0,a0,48
ret
These are the same so the first should be able to be compiled into the second.
[Bug target/111500] [arm-none-eabi-gcc] / suboptimal optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111500 Andrew Pinski changed: What|Removed |Added Component|c |target Status|UNCONFIRMED |WAITING Ever confirmed|0 |1 Keywords||missed-optimization Target||arm Last reconfirmed||2023-09-20 --- Comment #1 from Andrew Pinski --- Can you attach (compilible) examples code for each issue? Really these should be filed seperately too.
[Bug c++/111471] Incorrect NTTP printing in the error messages
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111471 --- Comment #2 from CVS Commits --- The master branch has been updated by Patrick Palka : https://gcc.gnu.org/g:75c4b0cde4835b45350da0a5cd82f1d1a0a7a2f1 commit r14-4178-g75c4b0cde4835b45350da0a5cd82f1d1a0a7a2f1 Author: Patrick Palka Date: Wed Sep 20 12:09:36 2023 -0400 c++: improve class NTTP object pretty printing [PR111471] 1. Move class NTTP object pretty printing to a more general spot in the pretty printer, so that we always print its value instead of its (mangled) name even when it appears outside of a template argument list. 2. Print the type of an class NTTP object alongside its CONSTRUCTOR value, like dump_expr would have done. 3. Don't print const VIEW_CONVERT_EXPR wrappers for class NTTPs. PR c++/111471 gcc/cp/ChangeLog: * cxx-pretty-print.cc (cxx_pretty_printer::expression) : Handle class NTTP objects by printing their type and value. : Strip const VIEW_CONVERT_EXPR wrappers for class NTTPs. (pp_cxx_template_argument_list): Don't handle class NTTP objects here. gcc/testsuite/ChangeLog: * g++.dg/concepts/diagnostic19.C: New test.
[Bug target/111481] MacOS, linker issues with Xcode 15
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111481 Iain Sandoe changed: What|Removed |Added Resolution|--- |INVALID Status|UNCONFIRMED |RESOLVED --- Comment #4 from Iain Sandoe --- (In reply to Eric Gallager from comment #3) > (In reply to simon from comment #2) (this is not a GCC bug AFAIK - but for the sake of information) > > A fix for the Ada issue is to link with the classic linker: > > > > $ gnatmake hello -largs -Wl,-ld_classic > > gcc -c hello.adb > > gnatbind -x hello.ali > > gnatlink hello.ali -Wl,-ld_classic > > $ you really need to configure the toolchain with "--with-ld=/path/to/ld-classic" NOTE: AFAIU, the ld bug is reportedly fixed "upstrean" and will appear in some future dot release go Xcode 15. At present, I'd just suggest sticking with 14.3. > This is annoying how Apple is reusing the name `ld_classic` for something > new, after it previously referred to something else... Indeed, it is for those of us supporting older Darwin.
[Bug target/111481] MacOS, linker issues with Xcode 15
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111481 Eric Gallager changed: What|Removed |Added CC||egallager at gcc dot gnu.org, ||iains at gcc dot gnu.org --- Comment #3 from Eric Gallager --- (In reply to simon from comment #2) > A fix for the Ada issue is to link with the classic linker: > > $ gnatmake hello -largs -Wl,-ld_classic > gcc -c hello.adb > gnatbind -x hello.ali > gnatlink hello.ali -Wl,-ld_classic > $ This is annoying how Apple is reusing the name `ld_classic` for something new, after it previously referred to something else...
[Bug c++/111499] std::vector less operator< doesn't compile with optimization due to __builtin_memcmp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111499 --- Comment #4 from Jonathan Wakely --- (In reply to Michal Lachowicz from comment #2) > N.B. Bug exists on current release gcc 13.2 Yes, but you're still not using the devel/omp/gcc-12 branch from Git.
[Bug c++/111499] std::vector less operator< doesn't compile with optimization due to __builtin_memcmp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111499 --- Comment #3 from Jonathan Wakely --- The only reason it doesn't compile is because you explicitly told the compiler to make it not compile. This is just a warning, not an error.
[Bug c++/111499] std::vector less operator< doesn't compile with optimization due to __builtin_memcmp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111499 --- Comment #2 from Michal Lachowicz --- N.B. Bug exists on current release gcc 13.2 https://godbolt.org/z/zeKbhPY4r
[Bug c++/111499] std::vector less operator< doesn't compile with optimization due to __builtin_memcmp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111499 --- Comment #1 from Jonathan Wakely --- N.B. the version is 12.2.0, you're not using the devel/omp/gcc-12 branch in Git.
[Bug c/111500] New: [arm-none-eabi-gcc] / suboptimal optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111500
Bug ID: 111500
Summary: [arm-none-eabi-gcc] / suboptimal optimization
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: gnu.arne at wgboome dot org
Target Milestone: ---
Hi!
For my STM32G030K6T I need thumb2 machine code.
arm-none-eabi-gcc can convert my C code quite nicely.
When I inspected the resulting disassembled machine code, I found some funny
artifacts.
Is it worth making minimal source code and/or that corresponding
"preprocessed file *.i*"?
I mean: Is somebody able/willing to do something about it?
Here are the 4 artifacts (when using "-O3 -g"):
1.
a "subs r2, #1" instruction is followed by a "cmp r2, #0 / bne.n" instruction,
although the "subs" already leaves the zero flag properly, doesn't it?
2.
a "b.n" instruction jumps to a "bx lr" instruction, although both have the same
length... i mean: instead of "b.n" it could have written "bx lr"...
3.
a "uxth r2, r2" is followed by a "strh r2, [r3]", although "strh" doesn't look
at the high half-word of r2, does it?
4.
when i use single bits in a struct (e. g.: "struct A { int a:1; int b:7; }"),
gcc reserves 16 bytes on the stack and sometimes writes into this area, without
ever reading from there... when i do it myself with "struct A { int ab; }" and
"if (S.ab&128)..." and "if (S.ab&127)..." then it doesnt touch the stack...
Thx.
Bye.
[Bug middle-end/111497] [11/12/13/14 Regression] ICE building mariadb on i686 since r8-470
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111497 --- Comment #3 from Jakub Jelinek --- When comparing RTL dump files between r247719 and r247721, ira dump is pretty much the same (just printed compiler pointers in the dump change), while reload dump has lots of changes including this pseudo in the debug insn.
[Bug c++/111499] New: std::vector less operator< doesn't compile with optimalisation due to __builtin_memcmp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111499
Bug ID: 111499
Summary: std::vector less operator< doesn't compile
with optimalisation due to __builtin_memcmp
Product: gcc
Version: og12 (devel/omp/gcc-12)
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: mlachowicz at outlook dot com
Target Milestone: ---
Hi,
Would like to report bug in std::vector less operator.
version of GCC: gcc 12.2, gcc 12.3, gcc 13.1, gcc 13.2
GNU C++20 (GCC) version 12.2.0 (x86_64-unknown-linux-gnu)
compiled by GNU C version 12.2.0, GMP version 6.2.1, MPFR version 4.2.0,
MPC version 1.3.1, isl version isl-0.20-GMP
system type: (not related to system)
the options given when GCC was configured/built: (not related)
the complete command line that triggers the bug:
g++ -Werror -std=c++20 -O1 f.cpp
the compiler output (error messages, warnings, etc.):
In file included from
/opt/compiler-explorer/gcc-12.2.0/include/c++/12.2.0/vector:60,
from :1:
In function 'constexpr decltype (__comp((* __first1), (* __first2)))
std::lexicographical_compare_three_way(_InputIter1, _InputIter1, _InputIter2,
_InputIter2, _Comp) [with _InputIter1 = __gnu_cxx::__normal_iterator >; _InputIter2 =
__gnu_cxx::__normal_iterator >;
_Comp = __detail::_Synth3way]',
inlined from 'constexpr std::__detail::__synth3way_t<_T1>
std::operator<=>(const vector<_Tp, _Alloc>&, const vector<_Tp, _Alloc>&) [with
_Tp = unsigned char; _Alloc = allocator]' at
/opt/compiler-explorer/gcc-12.2.0/include/c++/12.2.0/bits/stl_vector.h:2056:52,
inlined from 'bool f(const std::vector&)' at :6:12:
/opt/compiler-explorer/gcc-12.2.0/include/c++/12.2.0/bits/stl_algobase.h:1843:41:
error: 'int __builtin_memcmp(const void*, const void*, long unsigned int)'
specified bound [9223372036854775808, 18446744073709551615] exceeds maximum
object size 9223372036854775807 [-Werror=stringop-overread]
1843 | = __builtin_memcmp(&*__first1, &*__first2, __len)
<=> 0;
| ^~~
cc1plus: all warnings being treated as errors
Compiler returned: 1
Complete set of source files (see below):
https://godbolt.org/z/rzznsffne
#include
bool f(const std::vector )
{
std::vector w;
return v < w;
}
int main () {}
Other:
Bug exists only for unsigned char. Doesn't exist for signed char.
Bug exists only with -O1 option. Doesn't exist with -O0.
Let me know if you need more detailed information.
Kind regards,
Michał
[Bug tree-optimization/111498] New: 951% profile quality regression between g:93996cfb308ffc63 (2023-09-18 03:40) and g:95d2ce05fb32e663 (2023-09-19 03:22)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111498 Bug ID: 111498 Summary: 951% profile quality regression between g:93996cfb308ffc63 (2023-09-18 03:40) and g:95d2ce05fb32e663 (2023-09-19 03:22) Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: hubicka at gcc dot gnu.org Target Milestone: --- This is seen here on tramp3d -fprofile-use -fprofile-report https://lnt.opensuse.org/db_default/v4/CPP/graph?plot.0=463.976.7 Looking at patches in range it may be: commit d45ddc2c04e471d0dcee016b6edacc00b8341b16 Author: Richard Biener Date: Thu Sep 14 13:06:51 2023 +0200 tree-optimization/111294 - backwards threader PHI costing
[Bug middle-end/111497] [11/12/13/14 Regression] ICE building mariadb on i686 since r8-470
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111497 Jakub Jelinek changed: What|Removed |Added CC||rsandifo at gcc dot gnu.org --- Comment #2 from Jakub Jelinek --- Though, there are no differences in -fdump-tree-optimized-vops-alias-details dump, so it might be some glitch in our bisect seed. The neighboring r8-469-g8ffa3150d30b90a11aba7d7b revision looks much more related.
[Bug middle-end/111497] [11/12/13/14 Regression] ICE building mariadb on i686 since r8-470
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111497
--- Comment #1 from Jakub Jelinek ---
Testcase:
class A;
struct B { const char *b1; int b2; };
struct C : B { C (const char *x, int y) { b1 = x; b2 = y; } };
struct D : C { D (B x) : C (x.b1, x.b2) {} };
struct E { E (A *); };
struct F : E { D f1, f2, f3, f4, f5, f6; F (A *, const B &, const B &, const B
&); };
struct G : F { G (A *, const B &, const B &, const B &); };
struct H { int h; };
struct I { H i; };
struct J { I *j; };
struct A : J {};
inline F::F (A *x, const B , const B , const B )
: E(x), f1(y), f2(z), f3(w), f4(y), f5(z), f6(w) {}
G::G (A *x, const B , const B , const B ) : F(x, y, z, w)
{
H *h = >j->i;
if (h)
h->h++;
}
[Bug middle-end/111497] [11/12/13/14 Regression] ICE building mariadb on i686 since r8-470
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111497 Jakub Jelinek changed: What|Removed |Added Ever confirmed|0 |1 Priority|P3 |P2 CC||vmakarov at gcc dot gnu.org Status|UNCONFIRMED |NEW Last reconfirmed||2023-09-20 Target Milestone|--- |11.5
[Bug middle-end/111497] New: [11/12/13/14 Regression] ICE building mariadb on i686 since r8-470
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111497 Bug ID: 111497 Summary: [11/12/13/14 Regression] ICE building mariadb on i686 since r8-470 Product: gcc Version: 13.2.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end Assignee: unassigned at gcc dot gnu.org Reporter: jakub at gcc dot gnu.org Target Milestone: --- The following testcase ICEs on x86_64-linux with -m32 -march=i686 -mtune=generic -fPIC -O2 -g starting with r8-470-g973dfbb4a63ba7c580e4 The error is: during RTL pass: pro_and_epilogue item.ii: In constructor ‘G::G(A*, const B&, const B&, const B&)’: item.ii:19:1: internal compiler error: in find_oldest_value_reg, at regcprop.cc:465 19 | } | ^ 0x10304d0 find_oldest_value_reg ../../gcc/regcprop.cc:465 0x10307eb replace_oldest_value_reg ../../gcc/regcprop.cc:512 0x1030fe0 replace_oldest_value_addr ../../gcc/regcprop.cc:671 0x10311c3 replace_oldest_value_mem ../../gcc/regcprop.cc:704 and it is apparently due to LRA leaving a reference to a pseudo register in a DEBUG_INSN: (debug_insn 28 27 29 2 (var_location:SI x (mem/f:SI (reg:SI 110) [1 *y_10(D).b1+0 S4 A32])) "item.ii":4:39 -1 (nil)) in *.reload dump and forward. Vlad, could you please have a look?
[Bug ipa/108007] [11/12/13/14 Regression] wrong code at -Os and above with "-fno-dce -fno-tree-dce" on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108007 Martin Jambor changed: What|Removed |Added CC||19373742 at buaa dot edu.cn --- Comment #11 from Martin Jambor --- *** Bug 111490 has been marked as a duplicate of this bug. ***
[Bug ipa/111490] [12/13/14 Regression] runtime Segmentation fault with '-O3 -fno-dce -fno-tree-dce -fno-tree-dse -fno-tree-sink'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111490 Martin Jambor changed: What|Removed |Added Resolution|--- |DUPLICATE Status|NEW |RESOLVED --- Comment #5 from Martin Jambor --- This is a duplicate or PR108007 (which has a patch pending review). *** This bug has been marked as a duplicate of bug 108007 ***
[Bug target/103100] [11/12/13/14 Regression] unaligned access generated with memset or {} and -O2 -mstrict-align
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103100 --- Comment #24 from Wilco --- Patch to avoid emitting unaligned LDP/STP with -mstrict-align: https://gcc.gnu.org/pipermail/gcc-patches/2023-September/631022.html
[Bug c++/111496] New: Optimizer issue when reinitializing an object of a standard-layout class with a trivial copy constructor and a trivial destructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111496
Bug ID: 111496
Summary: Optimizer issue when reinitializing an object of a
standard-layout class with a trivial copy constructor
and a trivial destructor
Product: gcc
Version: 13.2.1
URL: https://godbolt.org/z/hf8qf6qan
Status: UNCONFIRMED
Keywords: ABI, missed-optimization
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: rogerio.souza at gmail dot com
Target Milestone: ---
Host: x86_64
Created attachment 55948
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55948=edit
Teste case to reproduce the optimization issue
In some cases, reinitializing an object of a standard-layout class with a
trivial copy constructor and a trivial destructor needs something more complex
than *this={} if this line is in a hot cycle. For some reason, gcc creates an
new object on stack which is copied to the target location.
Well, it's literally what *this={} should do, but I expected the compiler to
elide the copying.
Calling the destructor explicitly and reconstructing the object with a
placement new gives the desired code without the extra copying, but looks kinda
ugly.
The issue seems to be present in gcc9, gcc12, and gcc13, but different contents
the class trigger the generation of inferior code. Clang seems to produce the
shortest and the fastest code for this kind of operation.
Using -Os makes the compiler generate the improved binary code. Also replacing
"[[gnu::used]] void reset() { *this = {}; }" per "[[gnu::used]] void reset() {
A2 a2; *this = a2; }" improved the binary code generated.
The reproducible example is available at:
https://godbolt.org/z/hf8qf6qan
Source code:
#include
struct A {
[[gnu::used]] void reset() { *this = A(); }
private:
int b[4] = {};
char* p = {};
int x = {};
};
struct A2 {
[[gnu::used]] void reset() { *this = {}; }
private:
int b[4] = {};
char* p = {};
int x = {};
};
struct A3 {
[[gnu::used]] void reset() {
this->~A3();
new(this) A3;
}
private:
int b[4] = {};
char* p = {};
int x = {};
};
-
Regards,
Rogerio
[Bug c++/111493] [concepts] multidimensional subscript operator inside requires is broken
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111493 Patrick Palka changed: What|Removed |Added Ever confirmed|0 |1 CC||ppalka at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |ppalka at gcc dot gnu.org Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2023-09-20 --- Comment #1 from Patrick Palka --- Confirmed.
[Bug tree-optimization/111495] [14 regression] ICE in lower_bound, at value-range.h:1078 when building LLVM 17.0.1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111495 Richard Biener changed: What|Removed |Added Target Milestone|--- |14.0
[Bug tree-optimization/111495] New: [14 regression] ICE in lower_bound, at value-range.h:1078 when building LLVM 17.0.1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111495 Bug ID: 111495 Summary: [14 regression] ICE in lower_bound, at value-range.h:1078 when building LLVM 17.0.1 Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: sjames at gcc dot gnu.org Target Milestone: --- Created attachment 55947 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55947=edit InstructionSimplify.cpp.ii ``` Using built-in specs. COLLECT_GCC=gcc COLLECT_LTO_WRAPPER=/usr/libexec/gcc/aarch64-unknown-linux-gnu/14/lto-wrapper Target: aarch64-unknown-linux-gnu Configured with: /var/tmp/portage/sys-devel/gcc-14.0.0./work/gcc-14.0.0./configure --host=aarch64-unknown-linux-gnu --build=aarch64-unknown-linux-gnu --prefix=/usr --bindir=/usr/aarch64-unknown-linux-gnu/gcc-bin/14 --includedir=/usr/lib/gcc/aarch64-unknown-linux-gnu/14/include --datadir=/usr/share/gcc-data/aarch64-unknown-linux-gnu/14 --mandir=/usr/share/gcc-data/aarch64-unknown-linux-gnu/14/man --infodir=/usr/share/gcc-data/aarch64-unknown-linux-gnu/14/info --with-gxx-include-dir=/usr/lib/gcc/aarch64-unknown-linux-gnu/14/include/g++-v14 --disable-silent-rules --disable-dependency-tracking --with-python-dir=/share/gcc-data/aarch64-unknown-linux-gnu/14/python --enable-languages=c,c++,fortran --enable-obsolete --enable-secureplt --disable-werror --with-system-zlib --enable-nls --without-included-gettext --disable-libunwind-exceptions --enable-checking=yes,extra,rtl --with-bugurl=https://bugs.gentoo.org/ --with-pkgversion='Gentoo 14.0.0 p, commit d0b55776a4e1d2f293db5ba0e4a04aefed055ec4' --with-gcc-major-version-only --enable-libstdcxx-time --enable-lto --disable-libstdcxx-pch --enable-shared --enable-threads=posix --enable-__cxa_atexit --enable-clocale=gnu --disable-multilib --disable-fixed-point --enable-libgomp --disable-libssp --disable-libada --disable-cet --disable-systemtap --disable-valgrind-annotations --disable-vtable-verify --disable-libvtv --with-zstd --without-isl --enable-default-pie --enable-host-pie --disable-host-bind-now --enable-default-ssp Thread model: posix Supported LTO compression algorithms: zlib zstd gcc version 14.0.0 20230920 (experimental) 2e36eedb244badaaf2a70388071115c851b8db9b (Gentoo 14.0.0 p, commit d0b55776a4e1d2f293db5ba0e4a04aefed055ec4) ``` ``` FAILED: lib/Analysis/CMakeFiles/LLVMAnalysis.dir/InstructionSimplify.cpp.o /usr/bin/aarch64-unknown-linux-gnu-g++ -D_GNU_SOURCE -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS -I/var/tmp/portage/sys-devel/llvm-17.0.1/work/llvm_build-.arm64/lib/Analysis -I/var/tmp/portage/sys-devel/llvm-17.0.1/work/llvm/lib/Analysis -I/var/tmp/portage/sys-devel/llvm-17.0.1/work/llvm_build-.arm64/include -I/var/tmp/portage/sys-devel/llvm-17.0.1/work/llvm/include -DNDEBUG -O3 -pipe -mcpu=native -fdiagnostics-color=always -ggdb3 -fPIC -fno-semantic-interposition -fvisibility-inlines-hidden -Werror=date-time -fno-lifetime-dse -Wall -Wextra -Wno-unused-parameter -Wwrite-strings -Wcast-qual -Wno-missing-field-initializers -pedantic -Wno-long-long -Wimplicit-fallthrough -Wno-maybe-uninitialized -Wno-nonnull -Wno-class-memaccess -Wno-redundant-move -Wno-pessimizing-move -Wno-noexcept-type -Wdelete-non-virtual-dtor -Wsuggest-override -Wno-comment -Wno-misleading-indentation -Wctad-maybe-unsupported -fdiagnostics-color -ffunction-sections -fdata-sections -std=c++17 -fdiagnostics-color=always -MD -MT lib/Analysis/CMakeFiles/LLVMAnalysis.dir/InstructionSimplify.cpp.o -MF lib/Analysis/CMakeFiles/LLVMAnalysis.dir/InstructionSimplify.cpp.o.d -o lib/Analysis/CMakeFiles/LLVMAnalysis.dir/InstructionSimplify.cpp.o -c /var/tmp/portage/sys-devel/llvm-17.0.1/work/llvm/lib/Analysis/InstructionSimplify.cpp during GIMPLE pass: vrp /var/tmp/portage/sys-devel/llvm-17.0.1/work/llvm/lib/Analysis/InstructionSimplify.cpp: In function ‘llvm::Value* simplifyInstructionWithOperands(llvm::Instruction*, llvm::ArrayRef, const llvm::SimplifyQuery&, unsigned int)’: /var/tmp/portage/sys-devel/llvm-17.0.1/work/llvm/lib/Analysis/InstructionSimplify.cpp:6809:15: internal compiler error: in lower_bound, at value-range.h:1078 6809 | static Value *simplifyInstructionWithOperands(Instruction *I, | ^~~ 0xae7fa197 irange::lower_bound(unsigned int) const /usr/src/debug/sys-devel/gcc-14.0.0./gcc-14.0.0./gcc/value-range.h:1078 0xae7fa197 gimple_simplify_EXACT_DIV_EXPR(gimple_match_op*, gimple**, tree_node* (*)(tree_node*), code_helper, tree_node*, tree_node*, tree_node*) /usr/src/debug/sys-devel/gcc-14.0.0./build/gcc/gimple-match-2.cc:8278 0xadcbc307 gimple_resimplify2 /usr/src/debug/sys-devel/gcc-14.0.0./gcc-14.0.0./gcc/gimple-match-exports.cc:1001 0xadcbcf2f gimple_simplify(gimple*, gimple_match_op*,
[Bug target/111411] [14 regression] ICE when building opus-1.4, unrecognizable insn with -fstack-protector-strong
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111411 Richard Sandiford changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #15 from Richard Sandiford --- Fixed for GCC 12+.
[Bug target/111411] [14 regression] ICE when building opus-1.4, unrecognizable insn with -fstack-protector-strong
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111411 --- Comment #14 from CVS Commits --- The releases/gcc-12 branch has been updated by Richard Sandiford : https://gcc.gnu.org/g:74f99f1adc696f446115f36974a3f94f66294a53 commit r12-9886-g74f99f1adc696f446115f36974a3f94f66294a53 Author: Richard Sandiford Date: Wed Sep 20 11:13:20 2023 +0100 aarch64: Fix loose ldpstp check [PR111411] aarch64_operands_ok_for_ldpstp contained the code: /* One of the memory accesses must be a mempair operand. If it is not the first one, they need to be swapped by the peephole. */ if (!aarch64_mem_pair_operand (mem_1, GET_MODE (mem_1)) && !aarch64_mem_pair_operand (mem_2, GET_MODE (mem_2))) return false; But the requirement isn't just that one of the accesses must be a valid mempair operand. It's that the lower access must be, since that's the access that will be used for the instruction operand. gcc/ PR target/111411 * config/aarch64/aarch64.cc (aarch64_operands_ok_for_ldpstp): Require the lower memory access to a mem-pair operand. gcc/testsuite/ PR target/111411 * gcc.dg/rtl/aarch64/pr111411.c: New test. (cherry picked from commit 2d38f45bcca62ca0c7afef4b579f82c5c2a01610)
[Bug target/111411] [14 regression] ICE when building opus-1.4, unrecognizable insn with -fstack-protector-strong
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111411 --- Comment #13 from CVS Commits --- The releases/gcc-13 branch has been updated by Richard Sandiford : https://gcc.gnu.org/g:4bb1ae3c13ce4fb72129229de66f5ffbcd45fe4c commit r13-7827-g4bb1ae3c13ce4fb72129229de66f5ffbcd45fe4c Author: Richard Sandiford Date: Wed Sep 20 11:07:50 2023 +0100 aarch64: Fix loose ldpstp check [PR111411] aarch64_operands_ok_for_ldpstp contained the code: /* One of the memory accesses must be a mempair operand. If it is not the first one, they need to be swapped by the peephole. */ if (!aarch64_mem_pair_operand (mem_1, GET_MODE (mem_1)) && !aarch64_mem_pair_operand (mem_2, GET_MODE (mem_2))) return false; But the requirement isn't just that one of the accesses must be a valid mempair operand. It's that the lower access must be, since that's the access that will be used for the instruction operand. gcc/ PR target/111411 * config/aarch64/aarch64.cc (aarch64_operands_ok_for_ldpstp): Require the lower memory access to a mem-pair operand. gcc/testsuite/ PR target/111411 * gcc.dg/rtl/aarch64/pr111411.c: New test. (cherry picked from commit 2d38f45bcca62ca0c7afef4b579f82c5c2a01610)
[Bug tree-optimization/111494] Signed overflow introduced by vectorizer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111494 Richard Biener changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org Last reconfirmed||2023-09-20 Blocks||53947 Ever confirmed|0 |1 Keywords||wrong-code Status|UNCONFIRMED |ASSIGNED --- Comment #1 from Richard Biener --- Huh, confirmed. I _thought_ I fixed that at some point ... Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53947 [Bug 53947] [meta-bug] vectorizer missed-optimizations
[Bug tree-optimization/111489] [12/13 Regression] Incorrect "-Wmaybe-uninitialized" warning from GCC 13.2.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111489 Richard Biener changed: What|Removed |Added Known to fail||12.3.0, 13.2.0 Summary|Incorrect |[12/13 Regression] |"-Wmaybe-uninitialized" |Incorrect |warning from GCC 13.2.0 |"-Wmaybe-uninitialized" ||warning from GCC 13.2.0 Known to work||11.3.0, 14.0 Priority|P3 |P2 Target Milestone|--- |12.4 --- Comment #6 from Richard Biener --- Fixed on trunk sofar.
[Bug tree-optimization/111489] Incorrect "-Wmaybe-uninitialized" warning from GCC 13.2.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111489 --- Comment #4 from CVS Commits --- The master branch has been updated by Richard Biener : https://gcc.gnu.org/g:b8a2a12464d25c45a51c14a025e8e2d3ca8ebeb0 commit r14-4170-gb8a2a12464d25c45a51c14a025e8e2d3ca8ebeb0 Author: Richard Biener Date: Wed Sep 20 08:40:34 2023 +0200 tree-optimization/111489 - turn uninit limits to params The following turns MAX_NUM_CHAINS and MAX_CHAIN_LEN to params which allows to experiment with raising them. For the testcase in PR111489 raising MAX_CHAIN_LEN from 5 to 8 avoids the bogus diagnostics at -O2, at -O3 we need a MAX_CHAIN_LEN of 6. PR tree-optimization/111489 * doc/invoke.texi (--param uninit-max-chain-len): Document. (--param uninit-max-num-chains): Likewise. * params.opt (-param=uninit-max-chain-len=): New. (-param=uninit-max-num-chains=): Likewise. * gimple-predicate-analysis.cc (MAX_NUM_CHAINS): Define to param_uninit_max_num_chains. (MAX_CHAIN_LEN): Define to param_uninit_max_chain_len. (uninit_analysis::init_use_preds): Avoid VLA. (uninit_analysis::init_from_phi_def): Likewise. (compute_control_dep_chain): Avoid using MAX_CHAIN_LEN in template parameter. --- Comment #5 from CVS Commits --- The master branch has been updated by Richard Biener : https://gcc.gnu.org/g:daf175e8170c18f59cc42c916005698437446272 commit r14-4171-gdaf175e8170c18f59cc42c916005698437446272 Author: Richard Biener Date: Wed Sep 20 08:44:43 2023 +0200 tree-optimization/111489 - raise --param uninit-max-chain-len to 8 This raises --param uninit-max-chain-len to avoid a bogus diagnostic for the large testcase in PR111489. PR tree-optimization/111489 * params.opt (-param uninit-max-chain-len=): Raise default to 8. * gcc.dg/uninit-pr111489.c: New testcase.
[Bug tree-optimization/111494] New: Signed overflow introduced by vectorizer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111494
Bug ID: 111494
Summary: Signed overflow introduced by vectorizer
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: kristerw at gcc dot gnu.org
Target Milestone: ---
The vectorizer changes the order of additions when vectorizing the loop below,
but it is not changing the arithmetic to be unsigned, so it introduces new
signed overflows that were not in the original program.
int a[32];
int foo(int n) {
int sum = 0;
for (int i = 0; i < n; i++)
sum += a[i];
return sum;
}
[Bug c++/111493] New: [concepts] multidimensional subscript operator inside requires is broken
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111493
Bug ID: 111493
Summary: [concepts] multidimensional subscript operator inside
requires is broken
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: elrodc at gmail dot com
Target Milestone: ---
Two example programs:
> #include
> constexpr auto foo(const auto , int i, int j)
> requires(requires(decltype(A) a, int ii) { a[ii, ii]; }) {
>return A[i, j];
> }
> constexpr auto foo(const auto , int i, int j) {
>return A + i + j;
> }
> static_assert(foo(2,3,4) == 9);
> #include
> template
> concept CartesianIndexable = requires(T t, int i) {
>{ t[i, i] } -> std::convertible_to;
> };
> static_assert(!CartesianIndexable);
These result in errors of the form
error: invalid types 'const int[int]' for array subscript
Here is godbolt for reference: https://godbolt.org/z/WE66nY8zG
The invalid subscript should result in the `requires` failing, not an error.
[Bug c++/111392] Implement omp::decl attribute support for C++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111392 Jakub Jelinek changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #3 from Jakub Jelinek --- Implemented now.
[Bug tree-optimization/111489] Incorrect "-Wmaybe-uninitialized" warning from GCC 13.2.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111489 Richard Biener changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org Status|NEW |ASSIGNED
[Bug c++/111392] Implement omp::decl attribute support for C++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111392 --- Comment #2 from CVS Commits --- The master branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:04b2fb5bb644f172879a02e8374ad50b669e3d6d commit r14-4167-g04b2fb5bb644f172879a02e8374ad50b669e3d6d Author: Jakub Jelinek Date: Wed Sep 20 08:43:02 2023 +0200 openmp: Add omp::decl attribute support [PR111392] This patch adds support for (so far C++) omp::decl attribute. For declare simd and declare variant directives it is essentially another spelling of omp::decl, except per discussions it is not allowed inside of omp::sequence attribute. For threadprivate, declare target, allocate and later groupprivate directives it should appertain to variable (or for declare target also function definitions and) declarations and where in normal syntax one specifies a list of variables (or variables and functions), either as argument of the directive or clause argument, such argument is not specified and implied to be the variable it applies to. 2023-09-20 Jakub Jelinek PR c++/111392 gcc/ * attribs.cc (decl_attributes): Don't warn on omp::directive attribute on vars or function decls if -fopenmp or -fopenmp-simd. gcc/c-family/ * c-omp.cc (c_omp_directives): Add commented out groupprivate directive entry. gcc/cp/ * parser.h (struct cp_lexer): Add in_omp_decl_attribute member. * cp-tree.h (cp_maybe_parse_omp_decl): Declare. * parser.cc (cp_parser_handle_statement_omp_attributes): Diagnose omp::decl attribute on statements. Adjust diagnostic wording for omp::decl. (cp_parser_omp_directive_args): Add DECL_P argument, set TREE_PUBLIC to it on the DEFERRED_PARSE tree. (cp_parser_omp_sequence_args): Adjust caller. (cp_parser_std_attribute): Handle omp::decl attribute. (cp_parser_omp_var_list): If parser->lexer->in_omp_decl_attribute don't expect any arguments, instead create clause or TREE_LIST for that decl. (cp_parser_late_parsing_omp_declare_simd): Adjust diagnostic wording for omp::decl. (cp_maybe_parse_omp_decl): New function. (cp_parser_omp_declare_target): If parser->lexer->in_omp_decl_attribute and first token isn't name or comma invoke cp_parser_omp_var_list. * decl2.cc (cplus_decl_attributes): Adjust diagnostic wording for omp::decl. Handle omp::decl on declarations. * name-lookup.cc (finish_using_directive): Adjust diagnostic wording for omp::decl. gcc/testsuite/ * g++.dg/gomp/attrs-19.C: New test. * g++.dg/gomp/attrs-20.C: New test. * g++.dg/gomp/attrs-21.C: New test. libgomp/ * libgomp.texi: Mark decl attribute was added to the C++ attribute syntax as implemented.
[Bug tree-optimization/111489] Incorrect "-Wmaybe-uninitialized" warning from GCC 13.2.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111489
Richard Biener changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed||2023-09-20
Ever confirmed|0 |1
--- Comment #3 from Richard Biener ---
(In reply to Andrew Pinski from comment #1)
> 159 -> 58: one_pred = NOT (iftmp.32_490 != 0)
> ((NOT (iftmp.32_490 != 0)))
> After normalization [USE]:
> _419 = (int) pg_version_168;
> is conditional on:
> ((NOT (iftmp.32_490 != 0)))
>
>
> While the define was:
> After normalization [DEF]:
> pg_version_168 = PHI iftmp.13_491(35)>
> is conditional on:
> ((flags_262(D) == 2))
The issue is really
MAX_CHAIN_LEN exceeded: 6
init_use_preds: dep_chain incomplete, using conservative approximation
init_from_control_deps [USE] {{}}:
TRUE (empty)
at -O2. At -O3 we manage to get a slightly less complex CFG but still run
into this limit. Raising MAX_CHAIN_LEN to 8 (up from 5) avoids the diagnostic.
[Bug c/90293] New function attribute: expect_return
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90293
--- Comment #4 from Zev Weiss ---
I have no idea about the relative ease of implementation, but might it at least
partially suffice for the compiler to propagate the information provided by
__builtin_expect() beyond the expression it appears in?
So for the examples above, something like:
bool debug = false;
bool DebugModeEnabled()
{
__builtin_expect(debug, false);
return debug;
}
bool IsErrorCode(int code)
{
__builtin_expect(code < 0, 0);
return code < 0;
}
int CreateSocket()
{
int fd = socket(...);
__builtin_expect(fd == -1, 0);
return fd;
}
I suppose it would have the disadvantage of not appearing in header file
declarations and thus (absent LTO) not being available to other translation
units, though for critical things you could work around that reasonably easily
by putting a tiny wrapper with the __builtin_expect() in an inline function in
the header.
[Bug target/111488] ICE ion riscv gcc.dg/vect/vect-126.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111488 --- Comment #3 from CVS Commits --- The trunk branch has been updated by Lehua Ding : https://gcc.gnu.org/g:d024a31a09d18d2586769602205a60ff3afe568c commit r14-4166-gd024a31a09d18d2586769602205a60ff3afe568c Author: Lehua Ding Date: Wed Sep 20 13:35:16 2023 +0800 RISC-V: Fixed ICE caused by missing operand This ICE appears in GCC compiled with -O2 flags. PR target/111488 gcc/ChangeLog: * config/riscv/autovec-opt.md: Add missed operand.
[Bug debug/111409] Invalid .debug_macro.dwo macro information for split DWARF
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111409 --- Comment #2 from CVS Commits --- The master branch has been updated by Richard Biener : https://gcc.gnu.org/g:80048aa13a6b55d2be485000840a4e1c8b57d8e7 commit r14-4165-g80048aa13a6b55d2be485000840a4e1c8b57d8e7 Author: Omar Sandoval Date: Wed Sep 13 23:41:22 2023 -0700 debug/111409 - don't generate COMDAT macro sections for split DWARF Split DWARF files aren't processed by the linker, so DW_MACRO_import offsets aren't relocated and the .debug_macro.dwo sections aren't deduplicated and merged. There's no clear way for this to work for split DWARF, so disable it. gcc/ChangeLog: PR debug/111409 * dwarf2out.cc (output_macinfo): Don't call optimize_macinfo_range if dwarf_split_debug_info. gcc/testsuite/ChangeLog: PR debug/111409 * gcc.dg/pr111409.c: New test.
[Bug target/111486] [14 Regression] ICE: in require, at machmode.h:313 with -O2 -march=rv64iv
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111486 Richard Biener changed: What|Removed |Added Target Milestone|--- |14.0
