[Bug target/109977] [14 Regression] ICE: output_operand: incompatible floating point / vector register operand for '%d' at -Og
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109977 --- Comment #2 from Andrew Pinski --- Introduced by r14-215-g85279b0bddc1c5 .
[Bug target/109977] [14 Regression] ICE: output_operand: incompatible floating point / vector register operand for '%d' at -Og
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109977
Andrew Pinski changed:
What|Removed |Added
Target Milestone|--- |14.0
Host|x86_64-pc-linux-gnu |
Last reconfirmed||2023-05-26
Ever confirmed|0 |1
Status|UNCONFIRMED |NEW
--- Comment #1 from Andrew Pinski ---
(insn 12 11 13 (set (mem/c:V2DF (plus:DI (reg/f:DI 31 sp)
(const_int 16 [0x10])) [1 w+0 S16 A128])
(vec_duplicate:V2DF (reg:DF 0 x0 [orig:95 v ] [95])))
"/app/example.cpp":12:5 1392 {aarch64_simd_stpv2df}
(expr_list:REG_DEAD (reg:DF 0 x0 [orig:95 v ] [95])
(nil)))
(define_insn "aarch64_simd_stp"
[(set (match_operand:VP_2E 0 "aarch64_mem_pair_lanes_operand" "=Umn,Umn")
(vec_duplicate:VP_2E (match_operand: 1 "register_operand"
"w,r")))]
"TARGET_SIMD"
"@
stp\\t%1, %1, %y0
stp\\t%1, %1, %y0"
[(set_attr "type" "neon_stp, store_")]
)
;; For scalar usage of vector/FP registers, widening
(define_mode_attr vw [(V8QI "w") (V16QI "w")
(V4HI "w") (V8HI "w")
(V2SI "w") (V4SI "w")
(DI "x") (V2DI "x")
(V2SF "s") (V4SF "s")
(V2DF "d")])
Most likely should be using vwcore instead:
;; Corresponding core element mode for each vector mode. This is a
;; variation on mapping FP modes to GP regs.
(define_mode_attr vwcore [(V8QI "w") (V16QI "w")
(V4HI "w") (V8HI "w")
(V2SI "w") (V4SI "w")
(DI "x") (V2DI "x")
(V4HF "w") (V8HF "w")
(V4BF "w") (V8BF "w")
(V2SF "w") (V4SF "w")
(V2DF "x")
(VNx16QI "w") (VNx8QI "w") (VNx4QI "w") (VNx2QI "w")
(VNx8HI "w") (VNx4HI "w") (VNx2HI "w")
(VNx8HF "w") (VNx4HF "w") (VNx2HF "w")
(VNx8BF "w") (VNx4BF "w") (VNx2BF "w")
(VNx4SI "w") (VNx2SI "w")
(VNx4SF "w") (VNx2SF "w")
(VNx2DI "x")
(VNx2DF "x")])
[Bug target/109971] [14 regression] Several powerpc64 vector test cases fail after r14-1242-gf574e2dfae7905
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109971 --- Comment #6 from JuzheZhong --- >> With decrement IV, the optimized IR actually becomes better, it also aligns >> >>with our discussion here: >> https://gcc.gnu.org/pipermail/gcc-patches/2023->>April/615629.html (Thanks >> for the improvement!) Oh, I see. It seems that my patch is overall beneficial to PowerPC? That's what I want since I want my patch can not only help RVV but also other targets. >>It exposes something inefficient at -O2, it seems we can teach cunroll >>further >>about this kind of new sequence. Ok, we can optimize it for decrement IV in the future. >>If you meant to disable decrement IV on Power (but now actually enable it unexpectedly), then probably we can just keep it (not disabling), for Power >>we >>mainly adopt --param=vect-partial-vector-usage=1, it shouldn't be >>affected, for >>--param=vect-partial-vector-usage=2, it does generate better >>code sequence for >>most cases and we can improve the remaining worse one >>gradually. I am not meant to disable decrement IV on Power. Actually, I really hope Power can reuse the flow that I build for RVV. It makes things more meaningful. If it works for power and it seems to improve power codegen in most cases, I'd like to see power enable it by default. Then we can optimize it togther. Thanks a lot for your information.
[Bug target/109971] [14 regression] Several powerpc64 vector test cases fail after r14-1242-gf574e2dfae7905
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109971
Kewen Lin changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed||2023-05-26
--- Comment #5 from Kewen Lin ---
(In reply to JuzheZhong from comment #4)
> (In reply to Kewen Lin from comment #3)
> > I'll take a look first.
>
> Thanks a lot. I am sorry for causing such issue to you.
Never mind! Some failures can't be even caught by normal testings, or not
responsible by the culprit patch itself but just exposed by it instead.
As your comment #c2, it seems that you want to disable this on Power (and s390)
for now? (It's disabled for s390 apparently since it has
LOOP_VINFO_PARTIAL_LOAD_STORE_BIAS 1 always).
After some checkings, I found that:
1) for failures on p9-vec-length-full-{1,2,6}.c, the root cause is that the
main loop becomes neat and rtl pass bbro is able to duplicate it, the expected
counts on vector with length instructions change accordingly, I think they are
test issues.
With decrement IV, the optimized IR actually becomes better, it also aligns
with our discussion here:
https://gcc.gnu.org/pipermail/gcc-patches/2023-April/615629.html (Thanks for
the improvement!)
For example on full-1.c int8_t type:
[local count: 75161909]:
# vectp_a_int8_t.4_18 = PHI
# vectp_b_int8_t.8_8 = PHI
# vectp_c_int8_t.14_26 = PHI
# ivtmp_29 = PHI
# loop_len_16 = PHI <_34(5), 16(2)>
vect__1.6_13 = .LEN_LOAD (vectp_a_int8_t.4_18, 8B, loop_len_16, 0);
vect__2.7_12 = VIEW_CONVERT_EXPR(vect__1.6_13);
vect__3.10_22 = .LEN_LOAD (vectp_b_int8_t.8_8, 8B, loop_len_16, 0);
vect__4.11_23 = VIEW_CONVERT_EXPR(vect__3.10_22);
vect__5.12_24 = vect__2.7_12 + vect__4.11_23;
vect__6.13_25 = VIEW_CONVERT_EXPR(vect__5.12_24);
.LEN_STORE (vectp_c_int8_t.14_26, 8B, loop_len_16, vect__6.13_25, 0);
vectp_a_int8_t.4_17 = vectp_a_int8_t.4_18 + 16;
vectp_b_int8_t.8_7 = vectp_b_int8_t.8_8 + 16;
vectp_c_int8_t.14_27 = vectp_c_int8_t.14_26 + 16;
ivtmp_30 = ivtmp_29 + 16;
_32 = MIN_EXPR ;
_33 = 127 - _32;
_34 = MIN_EXPR <_33, 16>;
if (ivtmp_30 <= 126)
goto ; [85.71%]
else
goto ; [14.29%]
vs.
[local count: 75161909]:
# vectp_a_int8_t.4_18 = PHI
# vectp_b_int8_t.8_8 = PHI
# vectp_c_int8_t.14_26 = PHI
# ivtmp_29 = PHI
loop_len_16 = MIN_EXPR ;
vect__1.6_13 = .LEN_LOAD (vectp_a_int8_t.4_18, 8B, loop_len_16, 0);
vect__2.7_12 = VIEW_CONVERT_EXPR(vect__1.6_13);
vect__3.10_22 = .LEN_LOAD (vectp_b_int8_t.8_8, 8B, loop_len_16, 0);
vect__4.11_23 = VIEW_CONVERT_EXPR(vect__3.10_22);
vect__5.12_24 = vect__2.7_12 + vect__4.11_23;
vect__6.13_25 = VIEW_CONVERT_EXPR(vect__5.12_24);
.LEN_STORE (vectp_c_int8_t.14_26, 8B, loop_len_16, vect__6.13_25, 0);
vectp_a_int8_t.4_17 = vectp_a_int8_t.4_18 + 16;
vectp_b_int8_t.8_7 = vectp_b_int8_t.8_8 + 16;
vectp_c_int8_t.14_27 = vectp_c_int8_t.14_26 + 16;
ivtmp_30 = ivtmp_29 - loop_len_16;
if (ivtmp_30 != 0)
goto ; [85.71%]
else
goto ; [14.29%]
2) for failure on p9-vec-length-full-7.c ({u,}int8_t), the IR difference causes
cunroll not to unroll the loop further, so IR has some differences during
optimized dumpings:
[local count: 18146240]:
MEM [(signed char *)_int8_t + 16B] = { 15, 16, 17,
18, 19, 20, 21, 22, 23, 24, 25, 26, 27, 28, 29, 30 };
MEM [(signed char *)_int8_t + 32B] = { 31, 32, 33,
34, 35, 36, 37, 38, 39, 40, 41, 42, 43, 44, 45, 46 };
.LEN_STORE ( [(void *)_int8_t + 48B], 128B, 11, { 47, 48,
49, 50, 51, 52, 53, 54, 55, 56, 57, 58, 59, 60, 61, 62 }, 0); [tail call]
return;
vs.
[local count: 72584963]:
# vect_vec_iv_.6_50 = PHI <_51(5), { 15, 16, 17, 18, 19, 20, 21, 22, 23, 24,
25, 26, 27, 28, 29, 30 }(4)>
# ivtmp_57 = PHI
# ivtmp.12_11 = PHI
loop_len_55 = MIN_EXPR ;
_51 = vect_vec_iv_.6_50 + { 16, 16, 16, 16, 16, 16, 16, 16, 16, 16, 16, 16,
16, 16, 16, 16 };
_5 = (void *) ivtmp.12_11;
_14 = [(signed char *)_5];
.LEN_STORE (_14, 128B, loop_len_55, vect_vec_iv_.6_50, 0);
ivtmp_58 = ivtmp_57 - loop_len_55;
ivtmp.12_22 = ivtmp.12_11 + 16;
if (ivtmp_58 != 0)
goto ; [75.00%]
else
goto ; [25.00%]
It exposes something inefficient at -O2, it seems we can teach cunroll further
about this kind of new sequence.
If you meant to disable decrement IV on Power (but now actually enable it
unexpectedly), then probably we can just keep it (not disabling), for Power we
mainly adopt --param=vect-partial-vector-usage=1, it shouldn't be affected, for
--param=vect-partial-vector-usage=2, it does generate better code sequence for
most cases and we can improve the remaining worse one gradually.
[Bug target/109977] New: [14 Regression] ICE: output_operand: incompatible floating point / vector register operand for '%d' at -Og
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109977 Bug ID: 109977 Summary: [14 Regression] ICE: output_operand: incompatible floating point / vector register operand for '%d' at -Og Product: gcc Version: 14.0 Status: UNCONFIRMED Keywords: ice-on-valid-code Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: zsojka at seznam dot cz Target Milestone: --- Host: x86_64-pc-linux-gnu Target: aarch64-unknown-linux-gnu Created attachment 55161 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55161=edit reduced testcase Compiler output: $ aarch64-unknown-linux-gnu-gcc -Og testcase.c during RTL pass: final testcase.c: In function 'foo': testcase.c:14:1: internal compiler error: output_operand: incompatible floating point / vector register operand for '%d' 14 | } | ^ 0xe12aff output_operand_lossage(char const*, ...) /repo/gcc-trunk/gcc/final.cc:3190 0xe12cc5 output_operand(rtx_def*, int) /repo/gcc-trunk/gcc/final.cc:3632 0xe13a90 output_asm_insn(char const*, rtx_def**) /repo/gcc-trunk/gcc/final.cc:3525 0xe1889b output_asm_insn(char const*, rtx_def**) /repo/gcc-trunk/gcc/final.cc:3421 0xe1889b final_scan_insn_1 /repo/gcc-trunk/gcc/final.cc:2841 0xe18bbb final_scan_insn(rtx_insn*, _IO_FILE*, int, int, int*) /repo/gcc-trunk/gcc/final.cc:2887 0xe18df4 final_1 /repo/gcc-trunk/gcc/final.cc:1979 0xe19a68 rest_of_handle_final /repo/gcc-trunk/gcc/final.cc:4240 0xe19a68 execute /repo/gcc-trunk/gcc/final.cc:4318 Please submit a full bug report, with preprocessed source (by using -freport-bug). Please include the complete backtrace with any bug report. See <https://gcc.gnu.org/bugs/> for instructions. $ aarch64-unknown-linux-gnu-gcc -v Using built-in specs. COLLECT_GCC=/repo/gcc-trunk/binary-latest-aarch64/bin/aarch64-unknown-linux-gnu-gcc COLLECT_LTO_WRAPPER=/repo/gcc-trunk/binary-trunk-r14-1235-20230525094833-g0d1e0d7433c-checking-yes-rtl-df-extra-aarch64/bin/../libexec/gcc/aarch64-unknown-linux-gnu/14.0.0/lto-wrapper Target: aarch64-unknown-linux-gnu Configured with: /repo/gcc-trunk//configure --enable-languages=c,c++ --enable-valgrind-annotations --disable-nls --enable-checking=yes,rtl,df,extra --with-cloog --with-ppl --with-isl --with-sysroot=/usr/aarch64-unknown-linux-gnu --build=x86_64-pc-linux-gnu --host=x86_64-pc-linux-gnu --target=aarch64-unknown-linux-gnu --with-ld=/usr/bin/aarch64-unknown-linux-gnu-ld --with-as=/usr/bin/aarch64-unknown-linux-gnu-as --disable-libstdcxx-pch --prefix=/repo/gcc-trunk//binary-trunk-r14-1235-20230525094833-g0d1e0d7433c-checking-yes-rtl-df-extra-aarch64 Thread model: posix Supported LTO compression algorithms: zlib zstd gcc version 14.0.0 20230525 (experimental) (GCC)
[Bug c++/85944] Address of temporary at global scope not considered constexpr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85944 --- Comment #11 from Andrew Pinski --- *** Bug 109976 has been marked as a duplicate of this bug. ***
[Bug libstdc++/109976] error: is not a constant expression in std::equal() with _GLIBCXX_DEBUG
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109976 Andrew Pinski changed: What|Removed |Added Resolution|--- |DUPLICATE Status|UNCONFIRMED |RESOLVED See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=106212 --- Comment #1 from Andrew Pinski --- Dup of bug 85944 (via PR 106212). *** This bug has been marked as a duplicate of bug 85944 ***
[Bug libstdc++/109976] New: error: is not a constant expression in std::equal() with _GLIBCXX_DEBUG
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109976
Bug ID: 109976
Summary: error: is not a constant expression in std::equal()
with _GLIBCXX_DEBUG
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: ed at catmur dot uk
Target Milestone: ---
#define _GLIBCXX_DEBUG
#include
#include
constexpr bool f(std::string const& l, std::string const& r) {
return std::equal(l.data(), l.data() + l.size(), r.data(), r.data() +
r.size());
}
constexpr bool b = f("aa", "aa");
In file included from c++/14.0.0/debug/stl_iterator.h:32,
from c++/14.0.0/bits/stl_iterator.h:3004,
from c++/14.0.0/bits/stl_algobase.h:67,
from c++/14.0.0/algorithm:60,
from :2:
:7:21: in 'constexpr' expansion of
'f(std::__cxx11::basic_string(((const char*)"aa"),
std::allocator()), std::__cxx11::basic_string(((const char*)"aa"),
std::allocator()))'
:5:22: in 'constexpr' expansion of 'std::equal((& l)->std::__cxx11::basic_string::data(), ((&
l)->std::__cxx11::basic_string::data() + ((sizetype)(&
l)->std::__cxx11::basic_string::size())), (&
r)->std::__cxx11::basic_string::data(), ((&
r)->std::__cxx11::basic_string::data() + ((sizetype)(&
r)->std::__cxx11::basic_string::size('
c++/14.0.0/bits/stl_algobase.h:1679:7: in 'constexpr' expansion of
'__gnu_debug::__valid_range(__first1, __last1)'
c++/14.0.0/debug/helper_functions.h:257:31: in 'constexpr' expansion of
'__gnu_debug::__valid_range_aux(__first, __last, (_Integral(),
_Integral()))'
c++/14.0.0/debug/helper_functions.h:189:31: in 'constexpr' expansion of
'__gnu_debug::__valid_range_aux(__first, __last,
(std::__iterator_category(__first), std::iterator_traits::iterator_category()))'
c++/14.0.0/debug/helper_functions.h:176:19: in 'constexpr' expansion of
'__gnu_debug::__valid_range_aux(__first, __last,
(std::input_iterator_tag(), std::input_iterator_tag()))'
c++/14.0.0/debug/helper_functions.h:136:20: error: '(((const
char*)(&.std::__cxx11::basic_string::.std::__cxx11::basic_string_M_local_buf)) == 0)' is not a constant expression
136 | { return __ptr == 0; }
| ~~^~~~
This appears to be caused by bug 109975, but I'm filing separately since it
may be possible to fix in library.
The code is accepted if _GLIBCXX_DEBUG is not defined, since
__gnu_debug::__valid_range is not checked.
[Bug c++/85944] Address of temporary bound to a function parameter at global scope not considered constexpr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85944 Andrew Pinski changed: What|Removed |Added CC||ed at catmur dot uk --- Comment #10 from Andrew Pinski --- *** Bug 109975 has been marked as a duplicate of this bug. ***
[Bug c++/55004] [meta-bug] constexpr issues
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55004 Bug 55004 depends on bug 109975, which changed state. Bug 109975 Summary: error: '(((int*)(&.X::a)) != 0)' is not a constant expression https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109975 What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE
[Bug c++/109975] error: '(((int*)(&.X::a)) != 0)' is not a constant expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109975 Andrew Pinski changed: What|Removed |Added Resolution|--- |DUPLICATE Status|UNCONFIRMED |RESOLVED --- Comment #1 from Andrew Pinski --- Dup of bug 85944. *** This bug has been marked as a duplicate of bug 85944 ***
[Bug c++/109975] New: error: '(((int*)(&.X::a)) != 0)' is not a constant expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109975
Bug ID: 109975
Summary: error: '(((int*)(&.X::a)) != 0)' is not a
constant expression
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: ed at catmur dot uk
Target Milestone: ---
struct X { int a[1]; };
constexpr bool b = (X{}.a != 0);
:7:27: error: '(((int*)(&.X::a)) != 0)' is not a constant
expression
7 | constexpr bool b = (X{}.a != 0);
|~~~^
AFAICT this does not fall foul of anything in [expr.const]. Other compilers
accept, with a tautological-compare warning in the case of clang.
Similar to bug 71962, but this happens without enabling sanitizer.
[Bug target/109974] New: RISCV: RVV VSETVL Pass ICE in SLP auto-vectorization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109974
Bug ID: 109974
Summary: RISCV: RVV VSETVL Pass ICE in SLP auto-vectorization
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: pan2.li at intel dot com
Target Milestone: ---
Created attachment 55160
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55160=edit
Reproduce source file
Given the below example code with build option " -march=rv64gcv_zbb -O3
--param=riscv-autovec-preference=fixed-vlmax".
#include
void __attribute__((noinline, noclone))
func (int8_t *__restrict x, int64_t *__restrict y, int n)
{
for (int i = 0, j = 0; i < n; i++, j +=2 )
{
x[i + 0] += 1;
y[j + 0] += 1;
y[j + 1] += 2;
}
}
It will trigger one ICE during RTL pass: vsetvl.
.file "test.c"
.option nopic
.attribute arch,
"rv64i2p1_m2p0_a2p1_f2p2_d2p2_c2p0_v1p0_zicsr2p0_zifencei2p0_zbb1p0_zve32f1p0_zve32x1p0_zve64d1p0_zve64f1p0_zve64x1p0_zvl128b1p0_zvl32b1p0_zvl64b1p0"
.attribute unaligned_access, 0
.attribute stack_align, 16
.text
during RTL pass: vsetvl
test.c: In function ‘func’:
test.c:12:1: internal compiler error: in source_equal_p, at
config/riscv/riscv-vsetvl.cc:1141
12 | }
| ^
0x1cd6902 source_equal_p
/home/pli/repos/gcc/reference/riscv-gnu-toolchain/gcc/__BUILD_RISC-V/../gcc/config/riscv/riscv-vsetvl.cc:1141
0x1cd7c59 riscv_vector::avl_info::single_source_equal_p(riscv_vector::avl_info
const&) const
/home/pli/repos/gcc/reference/riscv-gnu-toolchain/gcc/__BUILD_RISC-V/../gcc/config/riscv/riscv-vsetvl.cc:1658
0x1cd7f01 riscv_vector::avl_info::operator==(riscv_vector::avl_info const&)
const
/home/pli/repos/gcc/reference/riscv-gnu-toolchain/gcc/__BUILD_RISC-V/../gcc/config/riscv/riscv-vsetvl.cc:1722
0x1cd8fe0
riscv_vector::vector_insn_info::compatible_avl_p(riscv_vector::vl_vtype_info
const&) const
/home/pli/repos/gcc/reference/riscv-gnu-toolchain/gcc/__BUILD_RISC-V/../gcc/config/riscv/riscv-vsetvl.cc:2010
0x1cd6ce4 incompatible_avl_p
/home/pli/repos/gcc/reference/riscv-gnu-toolchain/gcc/__BUILD_RISC-V/../gcc/config/riscv/riscv-vsetvl.cc:1199
0x1ce453b
riscv_vector::demands_cond::dual_incompatible_p(riscv_vector::vector_insn_info
const&, riscv_vector::vector_insn_info const&) const
/home/pli/repos/gcc/reference/riscv-gnu-toolchain/gcc/__BUILD_RISC-V/../gcc/config/riscv/riscv-vsetvl.h:491
0x1cd8e36
riscv_vector::vector_insn_info::compatible_p(riscv_vector::vector_insn_info
const&) const
/home/pli/repos/gcc/reference/riscv-gnu-toolchain/gcc/__BUILD_RISC-V/../gcc/config/riscv/riscv-vsetvl.cc:1983
0x1cdbf13 pass_vsetvl::compute_local_backward_infos(rtl_ssa::bb_info const*)
/home/pli/repos/gcc/reference/riscv-gnu-toolchain/gcc/__BUILD_RISC-V/../gcc/config/riscv/riscv-vsetvl.cc:2819
0x1ce188b pass_vsetvl::lazy_vsetvl()
/home/pli/repos/gcc/reference/riscv-gnu-toolchain/gcc/__BUILD_RISC-V/../gcc/config/riscv/riscv-vsetvl.cc:4542
0x1ce1b40 pass_vsetvl::execute(function*)
/home/pli/repos/gcc/reference/riscv-gnu-toolchain/gcc/__BUILD_RISC-V/../gcc/config/riscv/riscv-vsetvl.cc:4601
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See
[Bug middle-end/56439] extra register moves for global register and local register variables
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56439
Andrew Pinski changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
||a/show_bug.cgi?id=43491
--- Comment #11 from Andrew Pinski ---
here is a nice reduced testcase:
```
typedef unsigned short uint16_t;
register uint16_t r4 asm ("r4");
register uint16_t r6 asm ("r6");
uint16_t pllExec(void)
{
r4 += r6;
return r4>>8;
};
```
See bug 43491 comment #12 for some analysis of this issue really.
[Bug target/56439] [avr] unnecessary spill for global and local register variables
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56439 Andrew Pinski changed: What|Removed |Added CC||NickParker at Eaton dot com --- Comment #10 from Andrew Pinski --- *** Bug 65082 has been marked as a duplicate of this bug. ***
[Bug middle-end/65082] Wasted cycles when using a register based varible
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65082 Andrew Pinski changed: What|Removed |Added Resolution|--- |DUPLICATE Status|NEW |RESOLVED --- Comment #7 from Andrew Pinski --- Same as PR 56439. *** This bug has been marked as a duplicate of bug 56439 ***
[Bug target/109971] [14 regression] Several powerpc64 vector test cases fail after r14-1242-gf574e2dfae7905
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109971 --- Comment #4 from JuzheZhong --- (In reply to Kewen Lin from comment #3) > I'll take a look first. Thanks a lot. I am sorry for causing such issue to you.
[Bug target/109610] [14 regression] gcc.target/powerpc/dform-3.c fails after r14-172-g0368d169492017
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109610 --- Comment #14 from Hongtao.liu --- Fixed for GCC14.
[Bug rtl-optimization/109858] [14 Regression] r14-172 caused some SPEC2017 bmk to degrade on Power
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109858 --- Comment #11 from CVS Commits --- The master branch has been updated by hongtao Liu : https://gcc.gnu.org/g:4fb66b2329319e9b47e89200d613b6f741a114fc commit r14-1252-g4fb66b2329319e9b47e89200d613b6f741a114fc Author: liuhongt Date: Tue May 16 10:36:16 2023 +0800 Only use NO_REGS in cost calculation when !hard_regno_mode_ok for GENERAL_REGS and mode. r14-172-g0368d169492017 replaces GENERAL_REGS with NO_REGS in cost calculation when the preferred register class are not known yet. It regressed powerpc PR109610 and PR109858, it looks too aggressive to use NO_REGS when mode can be allocated with GENERAL_REGS. The patch takes a step back, still use GENERAL_REGS when hard_regno_mode_ok for mode and GENERAL_REGS, otherwise uses NO_REGS. gcc/ChangeLog: PR target/109610 PR target/109858 * ira-costs.cc (scan_one_insn): Only use NO_REGS in cost calculation when !hard_regno_mode_ok for GENERAL_REGS and mode, otherwise still use GENERAL_REGS.
[Bug target/109610] [14 regression] gcc.target/powerpc/dform-3.c fails after r14-172-g0368d169492017
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109610 --- Comment #13 from CVS Commits --- The master branch has been updated by hongtao Liu : https://gcc.gnu.org/g:4fb66b2329319e9b47e89200d613b6f741a114fc commit r14-1252-g4fb66b2329319e9b47e89200d613b6f741a114fc Author: liuhongt Date: Tue May 16 10:36:16 2023 +0800 Only use NO_REGS in cost calculation when !hard_regno_mode_ok for GENERAL_REGS and mode. r14-172-g0368d169492017 replaces GENERAL_REGS with NO_REGS in cost calculation when the preferred register class are not known yet. It regressed powerpc PR109610 and PR109858, it looks too aggressive to use NO_REGS when mode can be allocated with GENERAL_REGS. The patch takes a step back, still use GENERAL_REGS when hard_regno_mode_ok for mode and GENERAL_REGS, otherwise uses NO_REGS. gcc/ChangeLog: PR target/109610 PR target/109858 * ira-costs.cc (scan_one_insn): Only use NO_REGS in cost calculation when !hard_regno_mode_ok for GENERAL_REGS and mode, otherwise still use GENERAL_REGS.
[Bug middle-end/65082] Wasted cycles when using a register based varible
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65082 --- Comment #6 from Andrew Pinski --- See bug 43491 comment #12 for some analysis of this issue really.
[Bug middle-end/65082] Wasted cycles when using a register based varible
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65082
Andrew Pinski changed:
What|Removed |Added
Status|WAITING |NEW
--- Comment #5 from Andrew Pinski ---
Reduced testcase:
```
typedef unsigned short uint16_t;
register uint16_t r4 asm ("r4");
register uint16_t r6 asm ("r6");
uint16_t pllExec(void)
{
r4 += r6;
return r4>>8;
};
```
We get:
mov r24,r4
mov r25,r5
add r24,r6
adc r25,r7
mov r4,r24
mov r5,r25
mov r24,r25
ldi r25,0
[Bug rtl-optimization/36884] ifcvt poor optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=36884 Andrew Pinski changed: What|Removed |Added See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=109907 --- Comment #8 from Andrew Pinski --- I think the biggest issue now is: ``` ;; _6 = _2 >= 0; (insn 10 7 11 (set (reg:HI 48) (not:HI (reg:HI 44 [ _2 ]))) "/app/example.cpp":6:3 -1 (nil)) (insn 11 10 12 (set (reg:HI 49) (lshiftrt:HI (reg:HI 48) (const_int 15 [0xf]))) "/app/example.cpp":6:3 -1 (nil)) (insn 12 11 0 (set (reg:QI 45 [ _6 ]) (subreg:QI (reg:HI 49) 0)) "/app/example.cpp":6:3 -1 (nil)) ``` If this was expanded instead using the bit select. I had noticed a similar thing in PR 109907 too.
[Bug target/109971] [14 regression] Several powerpc64 vector test cases fail after r14-1242-gf574e2dfae7905
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109971 Kewen Lin changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |linkw at gcc dot gnu.org CC||linkw at gcc dot gnu.org --- Comment #3 from Kewen Lin --- I'll take a look first.
[Bug rtl-optimization/52396] Gcc failed to hoist loop invariant GOT load out of loop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52396 Andrew Pinski changed: What|Removed |Added Known to fail||5.4.0, 6.4.0, 7.5.0 Target Milestone|--- |8.0 Known to work||4.5.4, 4.6.4, 8.2.0 Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #2 from Andrew Pinski --- IV-OPTS does the correct thing for GCC 8+.
[Bug middle-end/10050] ifcvt is not smart enough
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=10050 Andrew Pinski changed: What|Removed |Added Component|rtl-optimization|middle-end --- Comment #11 from Andrew Pinski --- Note for func2 we get: if (flag.0_2 != 0) goto ; [50.00%] else goto ; [50.00%] [local count: 536870912]: pretmp_18 = *a_10(D); pretmp_20 = MEM[(int *)a_10(D) + 4B]; goto ; [100.00%] [local count: 536870913]: *a_10(D) = _9; MEM[(int *)a_10(D) + 4B] = _1; [local count: 1073741824]: # prephitmp_19 = PHI # prephitmp_21 = PHI the conditional stores are correct if not supplying -fallow-store-data-races . Now GCC does not optimize this even with -fallow-store-data-races but maybe it could.
[Bug target/109973] [13/14 Regression] Wrong code for AVX2 since 13.1 by combining VPAND and VPTEST
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109973 Andrew Pinski changed: What|Removed |Added Target Milestone|--- |13.2 Summary|Wrong code for AVX2 since |[13/14 Regression] Wrong |13.1 by combining VPAND and |code for AVX2 since 13.1 by |VPTEST |combining VPAND and VPTEST Keywords||wrong-code --- Comment #2 from Andrew Pinski --- The patch which introduced the failure is all in the x86_64 backend so it is target issue. r13-2006-ga56c1641e9d25e
[Bug rtl-optimization/109973] Wrong code for AVX2 since 13.1 by combining VPAND and VPTEST
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109973 --- Comment #1 from Benji Smith --- Created attachment 55159 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55159=edit A compressed preprocessed minimal repro of the VPAND/VPTEST issue
[Bug middle-end/38264] tree_forwarder_block_p says no to first basic block
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=38264 --- Comment #4 from Andrew Pinski --- (In reply to Andrew Pinski from comment #3) > Confirmed. > The code looks slightly different now as find_edge has been inlined and > merged with checking for eh edges. Which was done with r0-95726-g1d65f45cfaefa0 . The code is still there today. I am not sure if this issue still applies, almost 15 years after it was filed.
[Bug rtl-optimization/109973] New: Wrong code for AVX2 since 13.1 by combining VPAND and VPTEST
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109973
Bug ID: 109973
Summary: Wrong code for AVX2 since 13.1 by combining VPAND and
VPTEST
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: rtl-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: benjsith at gmail dot com
Target Milestone: ---
The following code is a minimal repro of the issue, when compiled with `gcc -O1
-mavx2`:
#include
int do_stuff(__m256i Y0, __m256i Y1, __m128i X2) {
__m256i And01 = _mm256_and_si256(Y0, Y1);
int TestResult = _mm256_testc_si256(And01, And01);
return TestResult;
}
I have also attached the preprocessed version of that minimal repro
12.3 produces the following assembly
vpand ymm0, ymm0, ymm1 ; < missing in 13.1
mov eax, 0
vptest ymm0, ymm0
setbal
ret
While 13.1 generates:
mov eax, 0
vptest ymm0, ymm1
setbal
ret
Note that as of 13.1, the VPAND is removed, and just the VPTEST remains.
However, this is incorrect because _mm256_testc_si256 returns the results of
the Carry Flag, which is based on the bitwise AND of the second operand and the
bitwise NOT of the first operand, meaning these two can't be combined like that
for this intrinsic
Here is a Godbolt link showing the issue with a full execution case:
https://godbolt.org/z/x9or4WEWh
This issue is present in 12.3 but not 13.1. A bisect shows that it was most
likely introduced in a56c1641e9d25e46059168e811b4a2f185f07b6b
I have confirmed that this issue is still present on the latest trunk,
8d2fa90a41567670d2dbd4918d19d21d9bec4a8f
-O0 on trunk will also return the correct result
For triage/priority purposes: this bug was not found in manually written code,
but instead from a fuzzer meant to test SIMD codegen
PS: This is my first bug on the GCC tracker, so if I've done anything wrong let
me know. I marked it as in "rtl-optimization" though I'm not sure if that's
correct
[Bug tree-optimization/21827] unroll misses simple elimination - works with manual unroll
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=21827 Andrew Pinski changed: What|Removed |Added Known to work||6.1.0 Known to fail||5.5.0 --- Comment #12 from Andrew Pinski --- Looks like the testcase in comment #5 is fixed for GCC 6+.
[Bug testsuite/109951] [14 Regression] libgomp, testsuite: non-native multilib c++ tests fail on Darwin.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109951 --- Comment #5 from Iain Sandoe --- Since AFAICT, there is only one piece of Darwin-specific code in the libgomp TCL (which adds -shared-libgcc), I would expect the base phenomenon to be the same on Linux. What is not obvious there is why it seems to work in that case (unless it's just Darwin's linker being 'picky').
[Bug testsuite/109951] [14 Regression] libgomp, testsuite: non-native multilib c++ tests fail on Darwin.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109951
--- Comment #4 from Iain Sandoe ---
(In reply to Thomas Schwinge from comment #3)
> Looking at your "test x86_64 multilib on i686" case.
The situation is simply mirrored for an x86_64 host with an i686 non-native
lib.
> First, is my understanding correct, that 'GXX_UNDER_TEST'
> 'i686-apple-darwin9/libgomp/testsuite/site.exp' does contain the correct
> flags/paths for the default ("native", "i686") multilib, but incorrect for
> the other ("non-native", "x86_64") multilib?
Yes, this information is in a section included from "libgomp-site-extra.exp"
## Begin content included from file libgomp-site-extra.exp. Do not modify. ##
set GXX_UNDER_TEST {/scratch/10-5-leo/gcc-master/./gcc/xg++
-B/scratch/10-5-leo/gcc-master/./gcc/ -nostdinc++ -funconfigured-libstdc++-v3
-L/scratch/10-5-leo/gcc-master/i686-apple-darwin9/libstdc++-v3/src
-L/scratch/10-5-leo/gcc-master/i686-apple-darwin9/libstdc++-v3/src/.libs
-L/scratch/10-5-leo/gcc-master/i686-apple-darwin9/libstdc++-v3/libsupc++/.libs
-B/opt/iains/i686-apple-darwin9/gcc-14-0-0p/i686-apple-darwin9/bin/
-B/opt/iains/i686-apple-darwin9/gcc-14-0-0p/i686-apple-darwin9/lib/ -isystem
/opt/iains/i686-apple-darwin9/gcc-14-0-0p/i686-apple-darwin9/include -isystem
/opt/iains/i686-apple-darwin9/gcc-14-0-0p/i686-apple-darwin9/sys-include
-fchecking=1}
^^^ yes this is correct for the native mlib, and wrong arch for the non-native.
## End content included from file libgomp-site-extra.exp. ##
> Conversely, would
> 'i686-apple-darwin9/x86_64/libgomp/testsuite/site.exp' contain the correct
> flags/paths for the other ("non-native", "x86_64") multilib? (..., but that
> latter file is never used, always the former 'site.exp'; similar to my
> "Indeed there is some confusion there" comment in
> --
> but that one's benign, in contrast to your case).
Actually, there is no site.exp in that dir. There is a
"libgomp-site-extra.exp" which does contain the correct paths.
set GXX_UNDER_TEST {/scratch/10-5-leo/gcc-master/./gcc/xg++
-B/scratch/10-5-leo/gcc-master/./gcc/ -nostdinc++ -funconfigured-libstdc++-v3
-L/scratch/10-5-leo/gcc-master/i686-apple-darwin9/x86_64/libstdc++-v3/src
-L/scratch/10-5-leo/gcc-master/i686-apple-darwin9/x86_64/libstdc++-v3/src/.libs
-L/scratch/10-5-leo/gcc-master/i686-apple-darwin9/x86_64/libstdc++-v3/libsupc++/.libs
-B/opt/iains/i686-apple-darwin9/gcc-14-0-0p/i686-apple-darwin9/bin/
-B/opt/iains/i686-apple-darwin9/gcc-14-0-0p/i686-apple-darwin9/lib/ -isystem
/opt/iains/i686-apple-darwin9/gcc-14-0-0p/i686-apple-darwin9/include -isystem
/opt/iains/i686-apple-darwin9/gcc-14-0-0p/i686-apple-darwin9/sys-include
-fchecking=1 -m64}
^^^ Yes, this looks correct for testing the non-native x86_64 lib.
> Second, do you not have similar confusion in 'GCC_UNDER_TEST' and
> 'GFORTRAN_UNDER_TEST' flags/paths?
No. the confusion does not arise in either of those cases, since they do not
hardwire "-L" paths for the runtime libraries (I guess that they expect those
to be added by the consumer - which [I *think*] libgomp would do correctly).
Of course, there might be some other subtlety - that has just not yet surfaced.
> (May help me to attach all the relevant 'site.exp' files.)
I will sort that out tomorrow (if needed) - I've pasted in the relevant pieces
for the GXX_UNDER_TEST above.
> Third, see Maciej's Subversion r279708 (Git commit
> c8e759b4215ba4b376c9d468aeffe163b3d520f0) "libgomp/test: Fix compilation for
> build sysroot", followed by Git commit
> 749bd22ddc50b5112e5ed506ffef7249bf8e6fb3 "libgomp/test: Remove a build
> sysroot fix regression" (for libgomp, and similarly other commits for a
> number of (but not all?) other GCC target libraries). This is what started
> capturing 'CC' for test-time use as 'GCC_UNDER_TEST', and this is what in
> recent commit 11f4d483600b5788a3d1cf1527e838e4a7ed1455 "libgomp testsuite:
I do not yet understand any of this ^^ ( hopefully, I will not need to :) )
> As appropriate, use the 'gcc', 'g++', 'gfortran' driver [PR91884]" I've then
> extended for 'CXX': 'GXX_UNDER_TEST', 'FC': 'GFORTRAN_UNDER_TEST'. I
> however don't understand yet the original intent of his change; in my
> understanding, and as has been the case before, we'd just get
> 'GCC_UNDER_TEST' etc. populated by 'find_gcc' etc.
The principle seems reasonable, the issue is that it's currently not telling
the truth (i.e. it is _not_ the G**_UNDER_TEST) when the testing is in the
non-native multilib,
=
I am also somewhat puzzled by what conditions I need to take advantage of the
parallel running?
Darwin has /usr/bin/getconf and AFAICT the number of cpus is reported OK both
at runtime and during config, but it seems to be determined to run a single
process.
[Bug tree-optimization/109801] -Wmaybe-uninitialized warning with -O1 on move constructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109801
--- Comment #8 from Andrew Pinski ---
(In reply to Scott Zhong from comment #7)
> If I understand you correctly, the following example should produce an
> uninitialized variable diagnostics and the fact that it doesn't means it is
> a bug in the compiler?
No because that is all code that can be considered dead.
If you instead had:
```
#include
class table
{
public:
table()
: size_(0) {}
table(table&& other) {
std::swap(size_, other.size_);
}
~table();
private:
int size_;
};
int main()
{
table container(std::move(table()));
return (0);
}
```
GCC will warn correctly. as GCC does not know that ~table does not touch size_
at all.
[Bug tree-optimization/109801] -Wmaybe-uninitialized warning with -O1 on move constructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109801
--- Comment #7 from Scott Zhong ---
(In reply to rguent...@suse.de from comment #6)
> > Am 25.05.2023 um 20:24 schrieb pinskia at gcc dot gnu.org
> > :
> >
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109801
> >
> > --- Comment #5 from Andrew Pinski ---
> > (In reply to Scott Zhong from comment #4)
> >> The move constructor "steals" resources rather than make copies of them,
> >> and
> >> leave the argument in some valid but otherwise indeterminate state. It is
> >> reasonable that size_ is not initialized in the context of a move
> >> constructor.
>
> Maybe, but you still copy an uninitialized variable so the diagnostic is
> correct.
If I understand you correctly, the following example should produce an
uninitialized variable diagnostics and the fact that it doesn't means it is a
bug in the compiler?
#include
class table
{
public:
table()
: size_(0) {}
table(table&& other) {
std::swap(size_, other.size_);
}
~table() {}
private:
int size_;
};
int main()
{
table container(std::move(table()));
return (0);
}
[Bug target/109972] New: RISC-V: Could use umodsi3/udivsi3/divsi3 libcalls for 32-bit division/remainder on RV64 without M extension
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109972
Bug ID: 109972
Summary: RISC-V: Could use umodsi3/udivsi3/divsi3 libcalls for
32-bit division/remainder on RV64 without M extension
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: craig.topper at gmail dot com
Target Milestone: ---
There's an opportunity to improve code size for 32-bit division and remainder
on RV64 without the M extension.
Currently gcc calls the umoddi3/udivdi3/divdi3 functions by zero/sign extending
the operands. In the case of the unsigned functions this requires two shifts to
zero the upper bits. For signed, it's two sext.w if the operands are not
already sign extended.
All 3 functions are followed by a sext.w if the result needs be sign extended.
libgcc contains umodsi3/udivsi3/divsi3 functions that handle the zero extending
of inputs and sign extending the result. Internally they call the di3 functions
to do the computation. These functions could be used to reduce code size at the
caller.
There is no signed modsi3 function in libgcc. Probably because umoddi3(sext(X),
sext(Y)) is guaranteed to produce a result that is sign extended. gcc seems to
not know this and still emits a sext.w after the call to umoddi3.
godbolt https://godbolt.org/z/ax3Khc6cM
unsigned divu(unsigned x, unsigned y) {
return x / y;
}
unsigned remu(unsigned x, unsigned y) {
return x % y;
}
int div(int x, int y) {
return x / y;
}
int rem(int x, int y) {
return x % y;
}
[Bug target/109971] [14 regression] Several powerpc64 vector test cases fail after r14-1242-gf574e2dfae7905
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109971 --- Comment #2 from JuzheZhong --- It seems this condition: + /* If we're vectorizing a loop that uses length "controls" and + can iterate more than once, we apply decrementing IV approach + in loop control. */ + if (LOOP_VINFO_CAN_USE_PARTIAL_VECTORS_P (loop_vinfo) + && !LOOP_VINFO_LENS (loop_vinfo).is_empty () + && LOOP_VINFO_PARTIAL_LOAD_STORE_BIAS (loop_vinfo) == 0 + && !(LOOP_VINFO_NITERS_KNOWN_P (loop_vinfo) + && known_le (LOOP_VINFO_INT_NITERS (loop_vinfo), + LOOP_VINFO_VECT_FACTOR (loop_vinfo +LOOP_VINFO_USING_DECREMENTING_IV_P (loop_vinfo) = true; dit not disable decrement IV in powerPC. Sorry for creating this issue since I only tested on X86. Should I add target hook for decrement IV? I am waiting for Richard's comments.
[Bug target/109971] [14 regression] Several powerpc64 vector test cases fail after r14-1242-gf574e2dfae7905
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109971 --- Comment #1 from JuzheZhong --- It seems this condition: + /* If we're vectorizing a loop that uses length "controls" and + can iterate more than once, we apply decrementing IV approach + in loop control. */ + if (LOOP_VINFO_CAN_USE_PARTIAL_VECTORS_P (loop_vinfo) + && !LOOP_VINFO_LENS (loop_vinfo).is_empty () + && LOOP_VINFO_PARTIAL_LOAD_STORE_BIAS (loop_vinfo) == 0 + && !(LOOP_VINFO_NITERS_KNOWN_P (loop_vinfo) + && known_le (LOOP_VINFO_INT_NITERS (loop_vinfo), + LOOP_VINFO_VECT_FACTOR (loop_vinfo +LOOP_VINFO_USING_DECREMENTING_IV_P (loop_vinfo) = true; dit not disable decrement IV in powerPC. Sorry for creating this issue since I only tested on X86. Should I add target hook for decrement IV? I am waiting for Richard's comments.
[Bug target/109971] New: [14 regression] Several powerpc64 vector test cases fail after r14-1242-gf574e2dfae7905
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109971 Bug ID: 109971 Summary: [14 regression] Several powerpc64 vector test cases fail after r14-1242-gf574e2dfae7905 Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: seurer at gcc dot gnu.org Target Milestone: --- Created attachment 55158 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55158=edit diff of assembler output between r14-1241 and r14-1242 g:f574e2dfae79055f16d0c63cc12df24815d8ead6, r14-1242-gf574e2dfae7905 make -k check-gcc RUNTESTFLAGS="powerpc.exp=gcc.target/powerpc/p9-vec-length-full-1.c" FAIL: gcc.target/powerpc/p9-vec-length-full-1.c scan-assembler-times \\mlxvl\\M 20 FAIL: gcc.target/powerpc/p9-vec-length-full-1.c scan-assembler-times \\mstxvl\\M 10 # of expected passes5 # of unexpected failures2 There are a few others, too: FAIL: gcc.target/powerpc/p9-vec-length-full-2.c scan-assembler-times mlxvlM 20 FAIL: gcc.target/powerpc/p9-vec-length-full-2.c scan-assembler-times mstxvlM 10 FAIL: gcc.target/powerpc/p9-vec-length-full-6.c scan-assembler-times mlxvlM 10 FAIL: gcc.target/powerpc/p9-vec-length-full-6.c scan-assembler-times mstxvlM 10 FAIL: gcc.target/powerpc/p9-vec-length-full-7.c scan-assembler-times mstxvlM 12 There are hundreds of assembler code differences caused by the commit. Diff file attached. commit f574e2dfae79055f16d0c63cc12df24815d8ead6 (HEAD, refs/bisect/bad) Author: Ju-Zhe Zhong Date: Thu May 25 22:42:35 2023 +0800 VECT: Add decrement IV iteration loop control by variable amount support
[Bug testsuite/109951] [14 Regression] libgomp, testsuite: non-native multilib c++ tests fail on Darwin.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109951
Thomas Schwinge changed:
What|Removed |Added
CC||macro at orcam dot me.uk
Status|UNCONFIRMED |NEW
Last reconfirmed||2023-05-25
Ever confirmed|0 |1
--- Comment #3 from Thomas Schwinge ---
Iain, sorry for this; let's track this down.
Looking at your "test x86_64 multilib on i686" case.
First, is my understanding correct, that 'GXX_UNDER_TEST'
'i686-apple-darwin9/libgomp/testsuite/site.exp' does contain the correct
flags/paths for the default ("native", "i686") multilib, but incorrect for the
other ("non-native", "x86_64") multilib? Conversely, would
'i686-apple-darwin9/x86_64/libgomp/testsuite/site.exp' contain the correct
flags/paths for the other ("non-native", "x86_64") multilib? (..., but that
latter file is never used, always the former 'site.exp'; similar to my "Indeed
there is some confusion there" comment in
-- but
that one's benign, in contrast to your case).
Second, do you not have similar confusion in 'GCC_UNDER_TEST' and
'GFORTRAN_UNDER_TEST' flags/paths?
(May help me to attach all the relevant 'site.exp' files.)
Third, see Maciej's Subversion r279708 (Git commit
c8e759b4215ba4b376c9d468aeffe163b3d520f0) "libgomp/test: Fix compilation for
build sysroot", followed by Git commit 749bd22ddc50b5112e5ed506ffef7249bf8e6fb3
"libgomp/test: Remove a build sysroot fix regression" (for libgomp, and
similarly other commits for a number of (but not all?) other GCC target
libraries). This is what started capturing 'CC' for test-time use as
'GCC_UNDER_TEST', and this is what in recent commit
11f4d483600b5788a3d1cf1527e838e4a7ed1455 "libgomp testsuite: As appropriate,
use the 'gcc', 'g++', 'gfortran' driver [PR91884]" I've then extended for
'CXX': 'GXX_UNDER_TEST', 'FC': 'GFORTRAN_UNDER_TEST'. I however don't
understand yet the original intent of his change; in my understanding, and as
has been the case before, we'd just get 'GCC_UNDER_TEST' etc. populated by
'find_gcc' etc.
[Bug target/49263] SH Target: underutilized "TST #imm, R0" instruction
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49263 --- Comment #40 from Oleg Endo --- (In reply to Alexander Klepikov from comment #39) > > I'm sorry, but .md lang is too complicated for me. Yeah, it looks alien at first sight. But it's where a lot of things happen w.r.t. instruction selection. > It looks like with optimization enabled it converts bitwise AND to right > shift and then optimizes again. But SH4 has 'shad' and 'shad' can be > optimized to 'tst'. And SH2E has libcall instead of dynamic shift and libcll > cannot be converted. It seems that very first optimization spoils things. > > But when we have numerous 'shar' instructions, optimization joins the game > again and converts them to 'tst'. Yes, something like this is what I remember happening there. I'll try to look into the issue with your test cases and see if it's possible to add some patterns to catch those. BTW, have you tried it on a more recent GCC? There have also been some optimizations in the middle-end (a bit more backend independent) for this kind of thing. > You are absolutely right, the code will be larger when we do right shifts. > But there's situations when you can't use library. For exmple, SH7055 engine > control unit can barely contain the program. The library just won't fit. Have you tried to use whole program optimization via -flto and -ffunction-sections? It should be able to strip out all unnecessary library functions.
[Bug c/109970] New: -Wstringop-overflow should work with parameter forward declarations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109970
Bug ID: 109970
Summary: -Wstringop-overflow should work with parameter forward
declarations
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: muecker at gwdg dot de
Target Milestone: ---
For bar I get the expected warning but not for foo.
void bar(int x, char buf[x]);
void foo(int x; char buf[x], int x);
int main()
{
char buf[10];
bar(11, buf);
foo(buf, 11);
}
https://godbolt.org/z/zhzr43c55
[Bug fortran/109948] [13/14 Regression] ICE(segfault) in gfc_expression_rank() from gfc_op_rank_conformable()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109948 --- Comment #7 from anlauf at gcc dot gnu.org --- Some more digging: in the case when ref->u.ar.as is NULL, it appears that e->symtree->n.sym->assoc->target->ref->u.ar.as is properly set.
[Bug target/109933] __atomic_test_and_set is broken for BIG ENDIAN riscv targets
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109933 --- Comment #12 from Rory Bolt --- (In reply to Patrick O'Neill from comment #11) > I can confirm that your fix does *not* break the testsuite on little endian. > > We also recently added inline subword atomics to GCC 13, will this code also > need to change for big endian? > > Trunk: > https://gcc.gnu.org/git/?p=gcc.git;a=blob;f=gcc/config/riscv/riscv.cc; > h=09fc9e5d95e611f94bc05b4851fef6f50a651c28;hb=HEAD#l7439 > > GCC-13 branch: > https://gcc.gnu.org/git/?p=gcc.git;a=blob;f=gcc/config/riscv/riscv.cc; > h=5f44f6dc5c9c4ad2416e4195570473ab49c2e535; > hb=6506590e70e57ed8d7fb68ab9443e31c31208fb0#l7146 It looks like the same patch will be required there...
[Bug tree-optimization/109801] -Wmaybe-uninitialized warning with -O1 on move constructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109801 --- Comment #6 from rguenther at suse dot de --- > Am 25.05.2023 um 20:24 schrieb pinskia at gcc dot gnu.org > : > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109801 > > --- Comment #5 from Andrew Pinski --- > (In reply to Scott Zhong from comment #4) >> The move constructor "steals" resources rather than make copies of them, and >> leave the argument in some valid but otherwise indeterminate state. It is >> reasonable that size_ is not initialized in the context of a move >> constructor. Maybe, but you still copy an uninitialized variable so the diagnostic is correct.
[Bug c/108896] provide "element_count" attribute to give more context to __builtin_dynamic_object_size() and -fsanitize=bounds
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108896 Nick Desaulniers changed: What|Removed |Added CC||ndesaulniers at google dot com --- Comment #46 from Nick Desaulniers --- RFC: https://discourse.llvm.org/t/rfc-enforcing-bounds-safety-in-c-fbounds-safety/70854
[Bug target/109174] incorrect intrinsic signature for AVX-512 srai*
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109174 Andrew Pinski changed: What|Removed |Added Resolution|--- |FIXED Target Milestone|--- |14.0 Status|UNCONFIRMED |RESOLVED --- Comment #4 from Andrew Pinski --- Fixed.
[Bug target/109173] incorrect intrinsic signature for _mm_srai_epi64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109173 Andrew Pinski changed: What|Removed |Added Target Milestone|--- |14.0 Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #9 from Andrew Pinski --- Fixed.
[Bug fortran/109948] [13/14 Regression] ICE(segfault) in gfc_expression_rank() from gfc_op_rank_conformable()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109948 anlauf at gcc dot gnu.org changed: What|Removed |Added CC||pault at gcc dot gnu.org --- Comment #6 from anlauf at gcc dot gnu.org --- (In reply to Rimvydas (RJ) from comment #5) > (In reply to anlauf from comment #4) > > Can you check if this works for you? > > This patch allows to avoid issue on all other associate use cases (tried on > gcc-13 branch). > > However it is a bit suspicious that using variable name abbreviations (to > dig out arrays from deeply nested types) is enough to change how the > internal gfc_array_ref is populated. ICE was triggered only on patterns > involving first using abbreviated name indexed access (like k(1)) followed > by any operation involving whole array. I agree that this patch is a band-aid, possibly for some latent issue. The suspect patch may have affected the order of resolution. Note that replacing in the reduced testcase in comment#3: associate(k=>k_2d) by associate(k=>k_2d(:)) avoids the ICE and gives identical code for gcc-12 .. gcc-14. In fact, the array-spec seems properly set. I've added Paul in CC, who is more familiar with the associate construct.
[Bug c++/109966] [13/14 Regression] ICE in implify_var_or_parm_decl, à gimplify.cc:3058
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109966
--- Comment #4 from Andrew Pinski ---
(In reply to Marek Polacek from comment #3)
Slightly more reduced (removing the template):
```
struct k {
k(const char *);
};
struct M {
k name;
int j = 42;
int default_value = j;
};
struct S {
M arr[3]{M{""}, {""}, {""}};
} o;
```
[Bug target/109933] __atomic_test_and_set is broken for BIG ENDIAN riscv targets
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109933 --- Comment #11 from Patrick O'Neill --- I can confirm that your fix does *not* break the testsuite on little endian. We also recently added inline subword atomics to GCC 13, will this code also need to change for big endian? Trunk: https://gcc.gnu.org/git/?p=gcc.git;a=blob;f=gcc/config/riscv/riscv.cc;h=09fc9e5d95e611f94bc05b4851fef6f50a651c28;hb=HEAD#l7439 GCC-13 branch: https://gcc.gnu.org/git/?p=gcc.git;a=blob;f=gcc/config/riscv/riscv.cc;h=5f44f6dc5c9c4ad2416e4195570473ab49c2e535;hb=6506590e70e57ed8d7fb68ab9443e31c31208fb0#l7146
[Bug tree-optimization/109801] -Wmaybe-uninitialized warning with -O1 on move constructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109801
--- Comment #5 from Andrew Pinski ---
(In reply to Scott Zhong from comment #4)
> The move constructor "steals" resources rather than make copies of them, and
> leave the argument in some valid but otherwise indeterminate state. It is
> reasonable that size_ is not initialized in the context of a move
> constructor.
>
> If you define body to the constructor and destructor for the class list, the
> warning goes away, which has nothing to do with size_ being initialized or
> not.
>
> template
> class list
> {
> public:
> list() {}
> ~list() {}
> };
Because if you don't have the define then the calls might clobber some other
memory ...
[Bug tree-optimization/109801] -Wmaybe-uninitialized warning with -O1 on move constructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109801
--- Comment #4 from Scott Zhong ---
The move constructor "steals" resources rather than make copies of them, and
leave the argument in some valid but otherwise indeterminate state. It is
reasonable that size_ is not initialized in the context of a move constructor.
If you define body to the constructor and destructor for the class list, the
warning goes away, which has nothing to do with size_ being initialized or not.
template
class list
{
public:
list() {}
~list() {}
};
[Bug middle-end/109967] [10/11/12/13/14 Regression] Wrong code at -O2 on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109967
Andrew Pinski changed:
What|Removed |Added
Summary|Wrong code at -O2 on|[10/11/12/13/14 Regression]
|x86_64-linux-gnu|Wrong code at -O2 on
||x86_64-linux-gnu
Target Milestone|--- |10.5
Known to work||6.1.0
Known to fail||7.1.0
--- Comment #2 from Andrew Pinski ---
The problem is the Partition code in expand.
Without the ={0,0}, we get:
Partition 1: size 20 align 16
g f
With we get:
Partition 1: size 20 align 16
g
Partition 0: size 16 align 16
f
[Bug middle-end/109967] Wrong code at -O2 on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109967 Andrew Pinski changed: What|Removed |Added Target||x86_64-linux-gnu --- Comment #1 from Andrew Pinski --- So if I initialize f the code works. Note the gimple level code looks the same.
[Bug c/108896] provide "element_count" attribute to give more context to __builtin_dynamic_object_size() and -fsanitize=bounds
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108896 --- Comment #45 from qinzhao at gcc dot gnu.org --- the first version of the patches were submitted to upstream today for discussion: https://gcc.gnu.org/pipermail/gcc-patches/2023-May/619708.html https://gcc.gnu.org/pipermail/gcc-patches/2023-May/619709.html https://gcc.gnu.org/pipermail/gcc-patches/2023-May/619710.html https://gcc.gnu.org/pipermail/gcc-patches/2023-May/619711.html
[Bug rtl-optimization/82931] Missing Optimization for Bit-Transfer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82931 Georg-Johann Lay changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #8 from Georg-Johann Lay --- Should work in v12.4 and v13.2+.
[Bug target/49263] SH Target: underutilized "TST #imm, R0" instruction
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49263 --- Comment #39 from Alexander Klepikov --- > The tst insn is mainly formed by the combine pass, which relies on certain > insn patterns and combinations thereof. See also sh.md, around line 530. I'm sorry, but .md lang is too complicated for me. > You can look at the debug output with the -fdump-rtl-all option to see > what's happening in the RTL passes. It looks like with optimization enabled it converts bitwise AND to right shift and then optimizes again. But SH4 has 'shad' and 'shad' can be optimized to 'tst'. And SH2E has libcall instead of dynamic shift and libcll cannot be converted. It seems that very first optimization spoils things. But when we have numerous 'shar' instructions, optimization joins the game again and converts them to 'tst'. > What your patch is doing is to make it not emit the ashrsi3_n insn for > constant shifts altogether? I guess it will make code that actually needs > those real shifts larger, as it will always emit the whole shift stitching > sequence. That might be a good thing or not. You are absolutely right, the code will be larger when we do right shifts. But there's situations when you can't use library. For exmple, SH7055 engine control unit can barely contain the program. The library just won't fit.
[Bug modula2/109969] Linking large project causes an ICE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109969 Gaius Mulley changed: What|Removed |Added Ever confirmed|0 |1 Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2023-05-25 --- Comment #1 from Gaius Mulley --- I've yet to reproduce the ICE as reported - but certainly see a problem with GetToken which fails to obtain the first token in a definition module for a large project.
[Bug target/104327] [12 Regression] Inlining error on s390x since r12-1039
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104327 --- Comment #13 from CVS Commits --- The releases/gcc-12 branch has been updated by Georg-Johann Lay : https://gcc.gnu.org/g:0537c71aa7ef88c4ffe754cf7af81e346273b079 commit r12-9655-g0537c71aa7ef88c4ffe754cf7af81e346273b079 Author: Georg-Johann Lay Date: Tue May 23 14:54:12 2023 +0200 target/104327: Allow more inlining between different optimization levels. avr-common.cc introduces the following options that are set depending on optimization level: -mgas-isr-prologues, -mmain-is-OS-task and -fsplit-wide-types-early. The inliner thinks that different options disallow cross-optimization inlining, so provide can_inline_p. gcc/ PR target/104327 * config/avr/avr.cc (avr_can_inline_p): New static function. (TARGET_CAN_INLINE_P): Define to that function.
[Bug rtl-optimization/82931] Missing Optimization for Bit-Transfer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82931 --- Comment #7 from CVS Commits --- The releases/gcc-12 branch has been updated by Georg-Johann Lay : https://gcc.gnu.org/g:4d39f68b891ed2ac7aca5ef24119f50976b84c22 commit r12-9654-g4d39f68b891ed2ac7aca5ef24119f50976b84c22 Author: Georg-Johann Lay Date: Thu May 25 19:02:34 2023 +0200 target/82931: Make a pattern more generic to match more bit-transfers. There is already a pattern in avr.md that matches single-bit transfers from one register to another one, but it only handled bit 0 of 8-bit registers. This change makes that pattern more generic so it matches more of similar single-bit transfers. gcc/ PR target/82931 * config/avr/avr.md (*movbitqi.0): Rename to *movbit.0-6. Handle any bit position and use mode QISI. * config/avr/avr.cc (avr_rtx_costs_1) [IOR]: Return a cost of 2 insns for bit-transfer of respective style. gcc/testsuite/ PR target/82931 * gcc.target/avr/pr82931.c: New test.
[Bug target/104327] [12 Regression] Inlining error on s390x since r12-1039
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104327 --- Comment #12 from CVS Commits --- The releases/gcc-13 branch has been updated by Georg-Johann Lay : https://gcc.gnu.org/g:6506590e70e57ed8d7fb68ab9443e31c31208fb0 commit r13-7378-g6506590e70e57ed8d7fb68ab9443e31c31208fb0 Author: Georg-Johann Lay Date: Tue May 23 14:54:12 2023 +0200 target/104327: Allow more inlining between different optimization levels. avr-common.cc introduces the following options that are set depending on optimization level: -mgas-isr-prologues, -mmain-is-OS-task and -fsplit-wide-types-early. The inliner thinks that different options disallow cross-optimization inlining, so provide can_inline_p. gcc/ PR target/104327 * config/avr/avr.cc (avr_can_inline_p): New static function. (TARGET_CAN_INLINE_P): Define to that function.
[Bug modula2/109969] New: Linking large project causes an ICE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109969 Bug ID: 109969 Summary: Linking large project causes an ICE Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: modula2 Assignee: gaius at gcc dot gnu.org Reporter: gaius at gcc dot gnu.org Target Milestone: --- As reported on the gm2 mailing list - linking a large project 80k lines causes an ICE. Brief analysis also highlights a bug in M2LexBuf_OpenSource and GetToken (which sets currenttoken to eoftok) even though the definition module contains correct code. I suspect that fixing this bug will also fix PR 108344 (both reference GetToken - which is due for a re-write).
[Bug target/104327] [12 Regression] Inlining error on s390x since r12-1039
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104327 --- Comment #11 from CVS Commits --- The master branch has been updated by Georg-Johann Lay : https://gcc.gnu.org/g:66cc0cb0f44f17049f61af6755043999c4fa5a24 commit r14-1245-g66cc0cb0f44f17049f61af6755043999c4fa5a24 Author: Georg-Johann Lay Date: Tue May 23 14:54:12 2023 +0200 target/104327: Allow more inlining between different optimization levels. avr-common.cc introduces the following options that are set depending on optimization level: -mgas-isr-prologues, -mmain-is-OS-task and -fsplit-wide-types-early. The inliner thinks that different options disallow cross-optimization inlining, so provide can_inline_p. gcc/ PR target/104327 * config/avr/avr.cc (avr_can_inline_p): New static function. (TARGET_CAN_INLINE_P): Define to that function.
[Bug rtl-optimization/82931] Missing Optimization for Bit-Transfer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82931 --- Comment #6 from CVS Commits --- The releases/gcc-13 branch has been updated by Georg-Johann Lay : https://gcc.gnu.org/g:a499ab08d18eff4ca9c079cafaee0708d2bcbf20 commit r13-7377-ga499ab08d18eff4ca9c079cafaee0708d2bcbf20 Author: Georg-Johann Lay Date: Thu May 25 19:02:34 2023 +0200 target/82931: Make a pattern more generic to match more bit-transfers. There is already a pattern in avr.md that matches single-bit transfers from one register to another one, but it only handled bit 0 of 8-bit registers. This change makes that pattern more generic so it matches more of similar single-bit transfers. gcc/ PR target/82931 * config/avr/avr.md (*movbitqi.0): Rename to *movbit.0-6. Handle any bit position and use mode QISI. * config/avr/avr.cc (avr_rtx_costs_1) [IOR]: Return a cost of 2 insns for bit-transfer of respective style. gcc/testsuite/ PR target/82931 * gcc.target/avr/pr82931.c: New test.
[Bug target/100811] Consider not omitting frame pointers by default on targets with many registers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100811 --- Comment #9 from Jakub Jelinek --- Why? It should be enabled by default only if it is effectively mandated by the ABI and/or doesn't affect performance at all (and is actually useful in functions that don't need it like functions with alloca/VLAs; see the PowerPC case).
[Bug target/100811] Consider not omitting frame pointers by default on targets with many registers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100811 --- Comment #8 from AK --- Should we enable frame-pointers by default for RISCV64 as well?
[Bug fortran/103794] ICE in gfc_check_reshape, at fortran/check.c:4727
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103794 anlauf at gcc dot gnu.org changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #4 from anlauf at gcc dot gnu.org --- Fixed for gcc-14. Closing. Thanks for the report!
[Bug fortran/104350] ICE in gfc_array_dimen_size(): Bad dimension
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104350 anlauf at gcc dot gnu.org changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #5 from anlauf at gcc dot gnu.org --- Fixed for gcc-14. Closing. Thanks for the report!
[Bug rtl-optimization/82931] Missing Optimization for Bit-Transfer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82931 --- Comment #5 from CVS Commits --- The master branch has been updated by Georg-Johann Lay : https://gcc.gnu.org/g:ff0a6900700636ac4c7f40b88490a20d19a68db3 commit r14-1244-gff0a6900700636ac4c7f40b88490a20d19a68db3 Author: Georg-Johann Lay Date: Thu May 25 19:02:34 2023 +0200 target/82931: Make a pattern more generic to match more bit-transfers. There is already a pattern in avr.md that matches single-bit transfers from one register to another one, but it only handled bit 0 of 8-bit registers. This change makes that pattern more generic so it matches more of similar single-bit transfers. gcc/ PR target/82931 * config/avr/avr.md (*movbitqi.0): Rename to *movbit.0-6. Handle any bit position and use mode QISI. * config/avr/avr.cc (avr_rtx_costs_1) [IOR]: Return a cost of 2 insns for bit-transfer of respective style. gcc/testsuite/ PR target/82931 * gcc.target/avr/pr82931.c: New test.
[Bug tree-optimization/109968] False Warning stringop-overread at -O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109968
--- Comment #3 from Andrew Pinski ---
(In reply to Andrew Pinski from comment #2)
> Reduced testcase without -fsanitize=address:
Sorry missed one undefined type.
Here is the corrected reduced testcase:
```
extern int write1 (int __fd, const void *__buf, int __n)
__attribute__ ((__access__ (__read_only__, 2, 3)));
typedef struct {
struct {
int b;
int c;
} s2;
} S;
void f1(int *a);
int f(S *s )
{
int err;
f1(>s2.b);
err = write1( 1, (const void *)&(s->s2), 6);
return err;
}
```
[Bug tree-optimization/109968] False Warning stringop-overread at -O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109968
Andrew Pinski changed:
What|Removed |Added
Summary|False Warning |False Warning
|stringop-overread when -O2 |stringop-overread at -O2
|and -fsanitize=address used |
--- Comment #2 from Andrew Pinski ---
Reduced testcase without -fsanitize=address:
extern int write1 (int __fd, const void *__buf, size_t __n)
__attribute__ ((__access__ (__read_only__, 2, 3)));
typedef struct {
struct {
int b;
int c;
} s2;
} S;
void f1(int *a);
int f(S *s )
{
int err;
f1(>s2.b);
err = write1( 1, (const void *)&(s->s2), 6);
return err;
}
[Bug target/109933] __atomic_test_and_set is broken for BIG ENDIAN riscv targets
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109933 --- Comment #10 from Rory Bolt --- Tested and verified on little endian too.
[Bug c/109956] GCC reserves 9 bytes for struct s { int a; char b; char t[]; } x = {1, 2, 3};
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109956
--- Comment #12 from Martin Uecker ---
The C standard says "However, when a . (or -> ) operator has a left operand
that is (a pointer to) a structure with a flexible array member and the right
operand names that member, it behaves as if that member were replaced with the
longest array (with the same element type) that would not make the structure
larger than the object being accessed;"
This would imply that also for GCC not all elements can be accessed in the
following structure without invoking UB. For x86_64 'x' has 11 bytes (for clang
9) but a struct with replacement array actually needs 12.
struct foo { int a; short b; char t[]; } x = { .t = { 1, 2, 3 } };
// x has 11 bytes
struct bar { int a; short b; char t[3]; }; // 12 bytes
One can argue that this does not matter for an extension and maybe the C
standard should not be read in this way as itself also contains an example
using the sizeof() + n * sizeof() rule which implies that this amount of
storage is enough for n elements.
But the question is what programmers should use when using memcpy of statically
initialized structs which have a FAM? sizeof() + n * sizeof() works for GCC
but not for clang. sizeof(struct bar) works for neither. One can use
MAX(sizeof(struct foo, offsetof(struct foo, t) + n * sizeof(char)) but I have
not seen anybody use it.
[Bug target/100811] Consider not omitting frame pointers by default on targets with many registers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100811
--- Comment #7 from Florian Weimer ---
(In reply to Jakub Jelinek from comment #6)
> I think aarch64 defaults to -fno-omit-frame-pointer anyway.
> /* Disable fomit-frame-pointer by default. */
> { OPT_LEVELS_ALL, OPT_fomit_frame_pointer, NULL, 0 },
It's required by some (all?) AArch64 ABIs, certainly on GNU/Linux.
[Bug target/100811] Consider not omitting frame pointers by default on targets with many registers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100811
--- Comment #6 from Jakub Jelinek ---
I think aarch64 defaults to -fno-omit-frame-pointer anyway.
/* Disable fomit-frame-pointer by default. */
{ OPT_LEVELS_ALL, OPT_fomit_frame_pointer, NULL, 0 },
[Bug target/100811] Consider not omitting frame pointers by default on targets with many registers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100811 --- Comment #5 from Andrew Pinski --- (In reply to AK from comment #4) > On AArch64 (typically mobile platforms) app developers typically would > enable frame pointers by default because it helps with crash reporting. s/AArch64 (typically mobile platforms)/phone\tablet/ Because aarch64 is also used for servers and network applicances too.
[Bug tree-optimization/109968] False Warning stringop-overread when -O2 and -fsanitize=address used
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109968 --- Comment #1 from Andrew Pinski --- From https://gcc.gnu.org/onlinedocs/gcc-13.1.0/gcc/Instrumentation-Options.html#index-fsanitize_003daddress : Note that sanitizers tend to increase the rate of false positive warnings, most notably those around -Wmaybe-uninitialized. We recommend against combining -Werror and [the use of] sanitizers.
[Bug c++/109966] [13/14 Regression] ICE in implify_var_or_parm_decl, à gimplify.cc:3058
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109966
--- Comment #3 from Marek Polacek ---
// PR c++/109966
struct M;
template struct __array_traits {
typedef M _Type[_Nm];
};
template struct array {
typename __array_traits<_Nm>::_Type _M_elems;
};
struct basic_string_view {
basic_string_view(const char *);
};
struct M {
basic_string_view name;
int j = 42;
int default_value = j;
};
struct S {
array<3> arr{M{""}, {""}, {""}};
} o;
[Bug c/109968] New: False Warning stringop-overread when -O2 and -fsanitize=address used
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109968 Bug ID: 109968 Summary: False Warning stringop-overread when -O2 and -fsanitize=address used Product: gcc Version: 13.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: davekelly13 at gmail dot com Target Milestone: --- Created attachment 55157 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55157=edit Preprocessed source gcc-13 -O2 -fsanitize=address --save-temps x.c -S x.c: In function ‘f’: x.c:17:15: warning: ‘write’ reading 6 bytes from a region of size 4 [-Wstringop-overread] 17 | err = write( 1, (const void *)&(s->s2), 6); | ^~~~ x.c:5:21: note: source object ‘b’ of size 4 5 | int b; | ^ In file included from x.c:1: /usr/include/unistd.h:378:16: note: in a call to function ‘write’ declared with attribute ‘access (read_only, 2, 3)’ 378 | extern ssize_t write (int __fd, const void *__buf, size_t __n) __wur |^ Preprocessed source attached. Removing the "if ( s->s2.b == 1 ) return 0;" resolves the issue. 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-17ubuntu1' --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-Pa930Z/gcc-12-12.2.0/debian/tmp-nvptx/usr,amdgcn-amdhsa=/build/gcc-12-Pa930Z/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-17ubuntu1)
[Bug target/100811] Consider not omitting frame pointers by default on targets with many registers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100811 AK changed: What|Removed |Added CC||hiraditya at msn dot com --- Comment #4 from AK --- On AArch64 (typically mobile platforms) app developers typically would enable frame pointers by default because it helps with crash reporting.
[Bug libstdc++/109947] std::expected monadic operations do not support move-only error types yet
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109947 Jonathan Wakely changed: What|Removed |Added Status|RESOLVED|SUSPENDED Resolution|INVALID |--- Ever confirmed|0 |1 Last reconfirmed||2023-05-25 --- Comment #7 from Jonathan Wakely --- I've created https://cplusplus.github.io/LWG/issue3938 for this, let's see where that goes.
[Bug libstdc++/109965] rename 'Modules' to 'Categories' in tree-view of doxygen-generated libstdc++ documentation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109965 --- Comment #4 from Jonathan Wakely --- (In reply to Saifi Khan from comment #2) > Short of re-compiling the doxygen code with string literal changed to > "Components" i can't seem to find any other way. Well if nothing else works, we can just use sed on the generated pages. (In reply to Saifi Khan from comment #3) > The file modified is > /opt/gcc/src/libstdc++-v3/doc/doxygen/DoxygenLayout.xml It needs to be in the directory where doxygen is run, or pointed to by the LAYOUT_FILE config in doc/doxygen/user.cfg.in
[Bug tree-optimization/109791] -Wstringop-overflow warning with -O3 and _GLIBCXX_USE_CXX11_ABI=0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109791 --- Comment #16 from Andrew Pinski --- (In reply to Richard Biener from comment #15) > Created attachment 55155 [details] > patch unfolding such PHIs > > Updated PHI unfolding patch. Tests fine besides mentioned diagnostic > regressions. I was looking into doing the opposite in forwprop but maybe I can skip addresses.
[Bug libstdc++/109965] rename 'Modules' to 'Categories' in tree-view of doxygen-generated libstdc++ documentation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109965 --- Comment #3 from Saifi Khan --- Trying the 'custom' layout approach that you suggested. The file modified is /opt/gcc/src/libstdc++-v3/doc/doxygen/DoxygenLayout.xml
[Bug libstdc++/109965] rename 'Modules' to 'Categories' in tree-view of doxygen-generated libstdc++ documentation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109965 --- Comment #2 from Saifi Khan --- Yes, you are right. Doxygen has 'Modules' hard-coded everywhere in the code as they have used the word as an organizing principle. It starts with enum Kind defined in LayoutNavEntry https://raw.githubusercontent.com/doxygen/doxygen/master/src/layout.h All the string-literals related to usage of word 'Modules' are hard-coded in this file. https://raw.githubusercontent.com/doxygen/doxygen/master/src/translator_en.h Modules Modules List Modules Index There are additional entries with regard to the usage of the term in Fortran which may be skipped. There are multiple translator files on a per-language (human spoken language) basis. Short of re-compiling the doxygen code with string literal changed to "Components" i can't seem to find any other way.
[Bug c++/109966] [13/14 Regression] ICE in implify_var_or_parm_decl, à gimplify.cc:3058
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109966 Marek Polacek changed: What|Removed |Added CC||mpolacek at gcc dot gnu.org Keywords|needs-bisection | Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |mpolacek at gcc dot gnu.org --- Comment #2 from Marek Polacek --- Oy, started with r13-765: commit 1b661f3f5e712c951e774b3b91fffe4dac734cc7 Author: Marek Polacek Date: Tue Apr 26 15:52:00 2022 -0400 c++: ICE with temporary of class type in DMI [PR100252]
[Bug c/109967] New: Wrong code at -O2 on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109967
Bug ID: 109967
Summary: Wrong code at -O2 on x86_64-linux-gnu
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: shaohua.li at inf dot ethz.ch
Target Milestone: ---
For the following code, gcc trunk at -O2 emits the wrong code. This seems to be
a long latent bug since GCC-7 (I tried gcc-7.4 on compiler explorer, which
still emits the wrong result.)
Compiler explorer: https://godbolt.org/z/YGeWedWq7
$ cat a.c
int printf(const char *, ...);
int a, c;
int main() {
long f[2];
int e = 0;
for (; e < 2; e++) {
{
char g[20];
char *b = g;
int d = 48, e = 0;
while (d && e < 5)
b[e++] = d /= 10;
c = e;
}
f[c - 2 + e] = 1;
}
a = f[0];
printf("%d\n", a);
}
$
$ gcc-tk -O0 a.c && ./a.out
1
$ gcc-tk -O2 a.c && ./a.out
4
$
$ gcc-tk -v
Using built-in specs.
COLLECT_GCC=gcc-tk
COLLECT_LTO_WRAPPER=/zdata/shaoli/compilers/ccbuilder-compilers/gcc-8d5f050dabbf6dd3b992c3b46661848dbcf30d9e/libexec/gcc/x86_64-pc-linux-gnu/14.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../configure --disable-multilib --disable-bootstrap
--enable-languages=c,c++
--prefix=/zdata/shaoli/compilers/ccbuilder-compilers/gcc-8d5f050dabbf6dd3b992c3b46661848dbcf30d9e
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 14.0.0 20230523 (experimental) (GCC)
$
[Bug target/99195] Optimise away vec_concat of 64-bit AdvancedSIMD operations with zeroes in aarch64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99195 --- Comment #17 from CVS Commits --- The master branch has been updated by Kyrylo Tkachov : https://gcc.gnu.org/g:560bb845321f5ad039a318a081b0e88d9900f5cb commit r14-1241-g560bb845321f5ad039a318a081b0e88d9900f5cb Author: Kyrylo Tkachov Date: Thu May 25 15:00:16 2023 +0100 aarch64: PR target/99195 Annotate complex FP patterns for vec-concat-zero This patch annotates the complex add and mla patterns for vec-concat-zero. Testing showed an interesting bug in our MD patterns where they were defined to match: (plus:VHSDF (match_operand:VHSDF 1 "register_operand" "0") (unspec:VHSDF [(match_operand:VHSDF 2 "register_operand" "w") (match_operand:VHSDF 3 "register_operand" "w") (match_operand:SI 4 "const_int_operand" "n")] FCMLA)) but the canonicalisation rules for PLUS require the more "complex" operand to be first so during combine when the new substituted patterns were attempted to be formed combine/recog would try to match: (plus:V2SF (unspec:V2SF [ (reg:V2SF 100) (reg:V2SF 101) (const_int 0 [0]) ] UNSPEC_FCMLA270) (reg:V2SF 99)) instead. This patch fixes the operands of the PLUS RTX in these patterns. Similar patterns for the dot-product instructions already used the right order. Bootstrapped and tested on aarch64-none-linux-gnu and aarch64_be-none-elf. gcc/ChangeLog: PR target/99195 * config/aarch64/aarch64-simd.md (aarch64_fcadd): Rename to... (aarch64_fcadd): ... This. Fix canonicalization of PLUS operands. (aarch64_fcmla): Rename to... (aarch64_fcmla): ... This. Fix canonicalization of PLUS operands. (aarch64_fcmla_lane): Rename to... (aarch64_fcmla_lane): ... This. Fix canonicalization of PLUS operands. (aarch64_fcmla_laneqv4hf): Rename to... (aarch64_fcmla_laneqv4hf): ... This. Fix canonicalization of PLUS operands. (aarch64_fcmlaq_lane): Fix canonicalization of PLUS operands. gcc/testsuite/ChangeLog: PR target/99195 * gcc.target/aarch64/simd/pr99195_9.c: New test.
[Bug middle-end/24639] [meta-bug] bug to track all Wuninitialized issues
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=24639 Bug 24639 depends on bug 109801, which changed state. Bug 109801 Summary: -Wmaybe-uninitialized warning with -O1 on move constructor https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109801 What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID
[Bug tree-optimization/109801] -Wmaybe-uninitialized warning with -O1 on move constructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109801
Richard Biener changed:
What|Removed |Added
Resolution|--- |INVALID
CC||rguenth at gcc dot gnu.org
Status|UNCONFIRMED |RESOLVED
--- Comment #3 from Richard Biener ---
I see
[local count: 966367642]:
MEM[(struct __as_base &)] ={v} {CLOBBER};
MEM[(struct _Vector_impl_data *)] ={v} {CLOBBER};
MEM[(struct _Vector_impl_data *)]._M_start = _42;
MEM[(struct _Vector_impl_data *)]._M_finish = __cur_30;
MEM[(struct _Vector_impl_data *)]._M_end_of_storage = _37;
MEM[(struct _Vector_impl_data *)]._M_start = 0B;
MEM[(struct _Vector_impl_data *)]._M_finish = 0B;
MEM[(struct _Vector_impl_data *)]._M_end_of_storage = 0B;
_7 = MEM[(type &) + 24]; <-- we diagnose this load
MEM[(int &) + 24] = 0;
MEM[(int &) + 24] = _7;
that looks like the std::swap (size_, other.size_) going wrong. Or well,
obviously size_ isn't initialized when
table(table&& other) {
std::swap(buckets_, other.buckets_);
std::swap(size_, other.size_);
}
is run, only other.size_ is. So it's entirely your fault I think.
[Bug libstdc++/109965] rename 'Modules' to 'Categories' in tree-view of doxygen-generated libstdc++ documentation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109965 Jonathan Wakely changed: What|Removed |Added Last reconfirmed||2023-05-25 Status|UNCONFIRMED |NEW Ever confirmed|0 |1 --- Comment #1 from Jonathan Wakely --- This is Doxygen's terminology, not ours: https://www.doxygen.nl/manual/grouping.html#modules It might be possible to retitle it from "Modules" using a custom layout: https://www.doxygen.nl/manual/customize.html#layout
[Bug c++/105541] [12 Regression] ICE: Segmentation fault when template lambda in requires-clause
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105541 Patrick Palka changed: What|Removed |Added CC||egor.pugin at gmail dot com --- Comment #8 from Patrick Palka --- *** Bug 103212 has been marked as a duplicate of this bug. ***
[Bug c++/103212] requires expression with lambda inside causes a parse error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103212 Patrick Palka changed: What|Removed |Added Status|NEW |RESOLVED Keywords|needs-bisection | Resolution|--- |DUPLICATE CC||ppalka at gcc dot gnu.org --- Comment #4 from Patrick Palka --- Fully fixed for GCC 12.2+ by the fixes for PR101677 / PR105541 it seems. This is close enough to a dup of the latter. *** This bug has been marked as a duplicate of bug 105541 ***
[Bug target/109964] auto-vectorization of shift ignores integral promotions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109964 --- Comment #4 from rsandifo at gcc dot gnu.org --- (In reply to Richard Biener from comment #3) > So the bug in the vectorizer is that it does > > t.ii:14:5: note: can narrow to signed:16 without loss of precision: _31 = > 1 >> _30; > t.ii:14:5: note: only the low 16 bits of _30 are significant > > while that's correct that's not the proper constraint to check for in > vect_recog_over_widening_pattern I think. That has code to deal with > overflow for plus/minus/mult but no defense against shifts > (that's also not a vect_truncatable_operation_p, so maybe it should simply > check that) Like you say, vect_truncatable_operation_p already checks for operations for which truncation is distributive. But the function is supposed to handle other cases too. E.g. I think the current code is correct for division. But yeah, right shifts are an awkward case, because the defined range of the second operand is much smaller than the range of the type, and yet the defined range depends on the range of the type. Sorry for not thinking about that at the time.
[Bug target/109800] [11/12/13/14 Regression] arm: ICE (segfault) loading double with -mpure-code -mbig-endian
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109800 --- Comment #1 from CVS Commits --- The master branch has been updated by Alex Coplan : https://gcc.gnu.org/g:f5298d9969b4fa34ff3aecd54b9630e22b2984a5 commit r14-1239-gf5298d9969b4fa34ff3aecd54b9630e22b2984a5 Author: Alex Coplan Date: Thu May 25 13:34:46 2023 +0100 arm: Fix ICE due to infinite splitting [PR109800] In r11-966-g9a182ef9ee011935d827ab5c6c9a7cd8e22257d8 we introduce a simplification to emit_move_insn that attempts to simplify moves of the form: (set (subreg:M1 (reg:M2 ...)) (constant C)) where M1 and M2 are of equal mode size. That is problematic for the splitter vfp.md:no_literal_pool_df_immediate in the arm backend, which tries to pun an lvalue DFmode pseudo into DImode and assign a constant to it with emit_move_insn, as the new transformation simply undoes this, and we end up splitting indefinitely. This patch changes things around in the arm backend so that we use a DImode temporary (instead of DFmode) and first load the DImode constant into the pseudo, and then pun the pseudo into DFmode as an rvalue in a reg -> reg move. I believe this should be semantically equivalent but avoids the pathalogical behaviour seen in the PR. gcc/ChangeLog: PR target/109800 * config/arm/arm.md (movdf): Generate temporary pseudo in DImode instead of DFmode. * config/arm/vfp.md (no_literal_pool_df_immediate): Rather than punning an lvalue DFmode pseudo into DImode, use a DImode pseudo and pun it into DFmode as an rvalue. gcc/testsuite/ChangeLog: PR target/109800 * gcc.target/arm/pure-code/pr109800.c: New test.
[Bug c++/109966] [13/14 Regression] ICE in implify_var_or_parm_decl, à gimplify.cc:3058
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109966
Richard Biener changed:
What|Removed |Added
Known to work||12.3.0
Summary|[13.1 Regression] ICE in|[13/14 Regression] ICE in
|implify_var_or_parm_decl, à |implify_var_or_parm_decl, à
|gimplify.cc:3058|gimplify.cc:3058
Target Milestone|--- |13.2
Priority|P3 |P2
Last reconfirmed||2023-05-25
Ever confirmed|0 |1
Status|UNCONFIRMED |NEW
Known to fail||13.1.0
Keywords||ice-on-valid-code,
||needs-bisection
--- Comment #1 from Richard Biener ---
#include
#include
template
struct MpvOptionBoundedScalar {
std::string_view name;
T default_value = 0;
T cur_value = default_value;
};
struct OptionHolder {
std::array, 3> video_zoom_options = {
MpvOptionBoundedScalar{"video-zoom", 0},
MpvOptionBoundedScalar{"video-pan-x", 0},
MpvOptionBoundedScalar{"video-pan-y", 0},
};
};
OptionHolder o;
[Bug c++/109966] New: [13.1 Regression] ICE in implify_var_or_parm_decl, à gimplify.cc:3058
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109966 Bug ID: 109966 Summary: [13.1 Regression] ICE in implify_var_or_parm_decl, à gimplify.cc:3058 Product: gcc Version: 13.1.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: averne381 at gmail dot com Target Milestone: --- Created attachment 55156 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55156=edit Preprocessed reproduction The attached code results in an ICE. It compiled and worked as expected in gcc12. I've tried to reduce as much as I could, but I'm still not sure what causes the issue, sorry for being vague. Godbolt: https://godbolt.org/z/7ndKThnx6 System: gcc version 13.1.1, on arch linux x86_64 Thanks in advance.
[Bug tree-optimization/109791] -Wstringop-overflow warning with -O3 and _GLIBCXX_USE_CXX11_ABI=0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109791 Richard Biener changed: What|Removed |Added Assignee|rguenth at gcc dot gnu.org |unassigned at gcc dot gnu.org Status|ASSIGNED|NEW
[Bug tree-optimization/109791] -Wstringop-overflow warning with -O3 and _GLIBCXX_USE_CXX11_ABI=0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109791 Richard Biener changed: What|Removed |Added Attachment #55047|0 |1 is obsolete|| --- Comment #15 from Richard Biener --- Created attachment 55155 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55155=edit patch unfolding such PHIs Updated PHI unfolding patch. Tests fine besides mentioned diagnostic regressions.
