[Bug target/115042] New: valgrind test fails to compile on armv7
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115042
Bug ID: 115042
Summary: valgrind test fails to compile on armv7
Product: gcc
Version: 14.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: raj.khem at gmail dot com
Target Milestone: ---
Created attachment 58180
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58180=edit
testcase
Attached test comes from valgrind, it worked fine with gcc-13 but can not be
built with gcc-14 or trunk with -O0, if any other -O is used then it
compiles ok but valgrind uses -O0 for this given testcase.
arm-yoe-linux-gnueabi/arm-yoe-linux-gnueabi-gcc -mthumb -mfpu=neon
-mfloat-abi=hard -mcpu=cortex-a15 -no-pie -fno-PIE -O0 v6media.i -c
v6media.c:5905:40: error: 'asm' operand has impossible constraints or there are
not enough registers
5905 | TESTINST4("smlaltt r0, r1, r2, r3",
|^
...
[Bug middle-end/115037] Unused std::vector is not optimized away.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115037 Xi Ruoyao changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #7 from Xi Ruoyao --- . *** This bug has been marked as a duplicate of bug 109442 ***
[Bug libstdc++/109442] Dead local copy of std::vector not removed from function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109442 Xi Ruoyao changed: What|Removed |Added CC||hubicka at gcc dot gnu.org --- Comment #18 from Xi Ruoyao --- *** Bug 115037 has been marked as a duplicate of this bug. ***
[Bug rtl-optimization/115013] [15 Regression] LRA: PR114810 fix result in ICE in the RISC-V Vector
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115013 Jeffrey A. Law changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever confirmed|0 |1 Last reconfirmed||2024-05-10 --- Comment #3 from Jeffrey A. Law --- No worries Vlad. At least for my tester I've got the LRA patch reverted. So I'm getting regular test results. Thanks for diving in and for the review work on the Rivai's team on subreg tracking in the allocator.
[Bug libstdc++/88545] std::find compile to memchr in trivial random access cases (patch)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88545 Sam James changed: What|Removed |Added CC||sjames at gcc dot gnu.org --- Comment #1 from Sam James --- I realise this is many years later, but please send patches to the gcc-patches & libstdc++ mailing lists. Patches on BZ are just used to store WIPs/drafts.
[Bug libstdc++/115040] Missed optimization opportunity in std::find of std::vector elements
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115040 --- Comment #4 from Andrew Pinski --- (In reply to Sam James from comment #3) > (In reply to Andrew Pinski from comment #2) > > > clang lowers both the calls to (w)memchr > > > > Is that with libc++ or libstdc++? > > It's libc++. Checked locally too.. Then this is partly a dup of bug 88545
[Bug tree-optimization/115040] Missed optimization opportunity in std::find of std::vector elements
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115040 --- Comment #3 from Sam James --- (In reply to Andrew Pinski from comment #2) > > clang lowers both the calls to (w)memchr > > Is that with libc++ or libstdc++? It's libc++. Checked locally too..
[Bug tree-optimization/115040] Missed optimization opportunity in std::find of std::vector elements
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115040 --- Comment #2 from Andrew Pinski --- > clang lowers both the calls to (w)memchr Is that with libc++ or libstdc++?
[Bug tree-optimization/115040] Missed optimization opportunity in std::find of std::vector elements
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115040 Andrew Pinski changed: What|Removed |Added Severity|normal |enhancement
[Bug tree-optimization/115041] Missed optimization opportunity in std::find of std::vector elements
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115041 Sam James changed: What|Removed |Added Resolution|--- |DUPLICATE CC||sjames at gcc dot gnu.org Status|UNCONFIRMED |RESOLVED --- Comment #1 from Sam James --- Same code in 115040? *** This bug has been marked as a duplicate of bug 115040 ***
[Bug tree-optimization/115040] New: Missed optimization opportunity in std::find
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115040
Bug ID: 115040
Summary: Missed optimization opportunity in std::find
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: hiraditya at msn dot com
Target Milestone: ---
https://gcc.godbolt.org/z/s3hv15935
```
#include
#include
#include
bool find_epi8(const std::vector& v) {
return std::find(v.begin(), v.end(), 42) != v.end();
}
bool find_epi32(const std::vector& v) {
return std::find(v.begin(), v.end(), 42) != v.end();
}
```
$ gcc -O3 -ftree-vectorize -march=pantherlake
```
find_epi8(std::vector > const&):
mov rcx, QWORD PTR [rdi+8]
mov rdx, QWORD PTR [rdi]
mov rsi, rcx
sub rsi, rdx
mov rax, rsi
sar rax, 2
testrax, rax
jle .L2
lea rax, [rdx+rax*4]
jmp .L8
.L3:
cmp BYTE PTR [rdx+1], 42
je .L23
cmp BYTE PTR [rdx+2], 42
je .L24
cmp BYTE PTR [rdx+3], 42
je .L25
add rdx, 4
cmp rdx, rax
je .L26
.L8:
cmp BYTE PTR [rdx], 42
jne .L3
.L21:
cmp rcx, rdx
setne al
ret
.L26:
mov rsi, rcx
sub rsi, rdx
.L2:
cmp rsi, 2
je .L9
cmp rsi, 3
je .L10
cmp rsi, 1
je .L11
xor eax, eax
ret
.L10:
cmp BYTE PTR [rdx], 42
je .L21
add rdx, 1
.L9:
cmp BYTE PTR [rdx], 42
je .L21
add rdx, 1
.L11:
cmp BYTE PTR [rdx], 42
seteal
cmp rcx, rdx
setne dl
and eax, edx
ret
.L23:
add rdx, 1
cmp rcx, rdx
setne al
ret
.L24:
add rdx, 2
cmp rcx, rdx
setne al
ret
.L25:
add rdx, 3
cmp rcx, rdx
setne al
ret
find_epi32(std::vector > const&):
mov rcx, QWORD PTR [rdi+8]
mov rdx, QWORD PTR [rdi]
mov rax, rcx
sub rax, rdx
mov rsi, rax
sar rax, 4
sar rsi, 2
testrax, rax
jle .L28
sal rax, 4
add rax, rdx
jmp .L34
.L29:
cmp DWORD PTR [rdx+4], 42
je .L48
cmp DWORD PTR [rdx+8], 42
je .L49
cmp DWORD PTR [rdx+12], 42
je .L50
add rdx, 16
cmp rdx, rax
je .L51
.L34:
cmp DWORD PTR [rdx], 42
jne .L29
.L47:
cmp rcx, rdx
setne al
ret
.L51:
mov rsi, rcx
sub rsi, rdx
sar rsi, 2
.L28:
cmp rsi, 2
je .L35
cmp rsi, 3
je .L36
cmp rsi, 1
je .L37
xor eax, eax
ret
.L36:
cmp DWORD PTR [rdx], 42
je .L47
add rdx, 4
.L35:
cmp DWORD PTR [rdx], 42
je .L47
add rdx, 4
.L37:
cmp DWORD PTR [rdx], 42
seteal
cmp rcx, rdx
setne dl
and eax, edx
ret
.L48:
add rdx, 4
cmp rcx, rdx
setne al
ret
.L49:
add rdx, 8
cmp rcx, rdx
setne al
ret
.L50:
add rdx, 12
cmp rcx, rdx
setne al
ret
```
clang lowers both the calls to (w)memchr
--- Comment #1 from Sam James ---
*** Bug 115041 has been marked as a duplicate of this bug. ***
[Bug tree-optimization/115041] New: Missed optimization opportunity in std::find of std::vector elements
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115041
Bug ID: 115041
Summary: Missed optimization opportunity in std::find of
std::vector elements
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: hiraditya at msn dot com
Target Milestone: ---
https://gcc.godbolt.org/z/s3hv15935
```
#include
#include
#include
bool find_epi8(const std::vector& v) {
return std::find(v.begin(), v.end(), 42) != v.end();
}
bool find_epi32(const std::vector& v) {
return std::find(v.begin(), v.end(), 42) != v.end();
}
```
$ gcc -O3 -ftree-vectorize -march=pantherlake
```
find_epi8(std::vector > const&):
mov rcx, QWORD PTR [rdi+8]
mov rdx, QWORD PTR [rdi]
mov rsi, rcx
sub rsi, rdx
mov rax, rsi
sar rax, 2
testrax, rax
jle .L2
lea rax, [rdx+rax*4]
jmp .L8
.L3:
cmp BYTE PTR [rdx+1], 42
je .L23
cmp BYTE PTR [rdx+2], 42
je .L24
cmp BYTE PTR [rdx+3], 42
je .L25
add rdx, 4
cmp rdx, rax
je .L26
.L8:
cmp BYTE PTR [rdx], 42
jne .L3
.L21:
cmp rcx, rdx
setne al
ret
.L26:
mov rsi, rcx
sub rsi, rdx
.L2:
cmp rsi, 2
je .L9
cmp rsi, 3
je .L10
cmp rsi, 1
je .L11
xor eax, eax
ret
.L10:
cmp BYTE PTR [rdx], 42
je .L21
add rdx, 1
.L9:
cmp BYTE PTR [rdx], 42
je .L21
add rdx, 1
.L11:
cmp BYTE PTR [rdx], 42
seteal
cmp rcx, rdx
setne dl
and eax, edx
ret
.L23:
add rdx, 1
cmp rcx, rdx
setne al
ret
.L24:
add rdx, 2
cmp rcx, rdx
setne al
ret
.L25:
add rdx, 3
cmp rcx, rdx
setne al
ret
find_epi32(std::vector > const&):
mov rcx, QWORD PTR [rdi+8]
mov rdx, QWORD PTR [rdi]
mov rax, rcx
sub rax, rdx
mov rsi, rax
sar rax, 4
sar rsi, 2
testrax, rax
jle .L28
sal rax, 4
add rax, rdx
jmp .L34
.L29:
cmp DWORD PTR [rdx+4], 42
je .L48
cmp DWORD PTR [rdx+8], 42
je .L49
cmp DWORD PTR [rdx+12], 42
je .L50
add rdx, 16
cmp rdx, rax
je .L51
.L34:
cmp DWORD PTR [rdx], 42
jne .L29
.L47:
cmp rcx, rdx
setne al
ret
.L51:
mov rsi, rcx
sub rsi, rdx
sar rsi, 2
.L28:
cmp rsi, 2
je .L35
cmp rsi, 3
je .L36
cmp rsi, 1
je .L37
xor eax, eax
ret
.L36:
cmp DWORD PTR [rdx], 42
je .L47
add rdx, 4
.L35:
cmp DWORD PTR [rdx], 42
je .L47
add rdx, 4
.L37:
cmp DWORD PTR [rdx], 42
seteal
cmp rcx, rdx
setne dl
and eax, edx
ret
.L48:
add rdx, 4
cmp rcx, rdx
setne al
ret
.L49:
add rdx, 8
cmp rcx, rdx
setne al
ret
.L50:
add rdx, 12
cmp rcx, rdx
setne al
ret
```
clang lowers both the calls to (w)memchr
[Bug target/113578] Incorrect sign printed for -nan on RISC-V
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113578 Andrew Waterman changed: What|Removed |Added CC||andrew at sifive dot com --- Comment #7 from Andrew Waterman --- In the case of the M1, I don't think the problem is that the sign bit isn't making it to printf; I think printf is choosing not to print the sign. The ARMv8 fcvt instruction preserves the sign bit when converting NaNs (unless the processor is in default-NaN mode, which Mac OS does not seem to use).
[Bug tree-optimization/115026] [15 Regression] msp430-elf fails gcc.dg/pr66444.c with prange enabled
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115026 --- Comment #8 from Aldy Hernandez --- (In reply to Jeffrey A. Law from comment #7) > So what's the magic to re-enable prange? I can do that and spin a fresh > build. You could revert this patch: commit d7bb8eaade3cd3aa70715c8567b4d7b08098e699 (master, clean) Author: Aldy Hernandez Date: Fri May 10 00:29:13 2024 +0200 Revert: "Enable prange support." [PR114985] This reverts commit 36e877996936abd8bd08f8b1d983c8d1023a5842 until the IPA pass is fixed with regards to POINTER = POINTER POINTER.
[Bug fortran/115039] Statement function with inquiry refs rejected
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115039 anlauf at gcc dot gnu.org changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |anlauf at gcc dot gnu.org --- Comment #1 from anlauf at gcc dot gnu.org --- Submitted: https://gcc.gnu.org/pipermail/fortran/2024-May/060500.html
[Bug jit/110466] jit.dg FAILs on ppc64le
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110466 David Malcolm changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #12 from David Malcolm --- Should be fixed for GCC 13 (for the upcoming GCC 13.3) by the above patch.
[Bug driver/111700] ICE: SIGSEGV in needs_read_p (input.cc:598) with -fdiagnostics-format=sarif-file or -fdiagnostics-format=sarif-stderr on pre-processed input
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111700 David Malcolm changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #5 from David Malcolm --- Should be fixed by the above patch for GCC 13 for the upcoming GCC 13.3
[Bug middle-end/114348] Corrupt SARIF output on stderr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114348 David Malcolm changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #8 from David Malcolm --- Should be fixed on GCC 13 for the upcoming GCC 13.3 by the above patch. I'm not planning to backport this further; closing.
[Bug middle-end/115037] Unused std::vector is not optimized away.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115037 --- Comment #6 from Jonathan Wakely --- Yes
[Bug fortran/115039] Statement function with inquiry refs rejected
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115039 anlauf at gcc dot gnu.org changed: What|Removed |Added Priority|P3 |P4 Keywords||rejects-valid
[Bug fortran/115039] New: Statement function with inquiry refs rejected
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115039 Bug ID: 115039 Summary: Statement function with inquiry refs rejected Product: gcc Version: 15.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: --- As reported in: https://fortran-lang.discourse.group/t/real-and-imaginary-parts-of-complex-number/1113/18 an inquiry reference (%re, %im) is incorrectly reported as a recursive reference. Testcase: program testit implicit none complex :: x real:: img img(x) = x%im write (*, *) img((1.0,3.0) + (2.0,4.0)) end program testit Tentative fix: diff --git a/gcc/fortran/expr.cc b/gcc/fortran/expr.cc index 66edad58278..94ec2ce21dd 100644 --- a/gcc/fortran/expr.cc +++ b/gcc/fortran/expr.cc @@ -5500,7 +5546,8 @@ gfc_traverse_expr (gfc_expr *expr, gfc_symbol *sym, break; case REF_INQUIRY: - return true; + /* An inquiry_ref does not collide with a symbol. */ + return false; default: gcc_unreachable ();
[Bug tree-optimization/115026] [15 Regression] msp430-elf fails gcc.dg/pr66444.c with prange enabled
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115026 --- Comment #7 from Jeffrey A. Law --- So what's the magic to re-enable prange? I can do that and spin a fresh build.
[Bug fortran/102241] [PDT] ICE when declaring derived type with a parameterized derived type member
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102241 Oliver Jahn changed: What|Removed |Added CC||oliverjahn at proton dot me --- Comment #4 from Oliver Jahn --- Same error with gfortran 14.1.0 on x86_64-pc-linux-gnu. Not sure it helps, but I can get an error message instead of ICE if I use the pointer version of the t2 type in a module subroutine: MODULE mo TYPE t1(n) INTEGER, LEN :: n INTEGER :: a(n) END TYPE TYPE t2 TYPE(t1(1)), POINTER :: p_t1 END TYPE type(t1(1)), target :: t type(t2) :: pt CONTAINS SUBROUTINE SR pt%p_t1 => t END SUBROUTINE END MODULE gives mo.f90:17:8: 17 | pt%p_t1 => t |1 Error: Different types in pointer assignment at (1); attempted assignment of TYPE(Pdtt1) to TYPE(t1) and the same with deferred type parameter in t2.
[Bug middle-end/115037] Unused std::vector is not optimized away.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115037 Xi Ruoyao changed: What|Removed |Added See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=109442 CC||xry111 at gcc dot gnu.org --- Comment #5 from Xi Ruoyao --- Isn't this an exact dup of PR109442?
[Bug rtl-optimization/115021] [14/15 regression] unnecessary spill for vpternlog
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115021
--- Comment #2 from Roger Sayle ---
Here's a reduced test case that should be unaffected by the pending changes to
how V8QI shifts are expanded. Note that the final "t -= t4" is required to
convince the register allocator to "spill".
typedef signed char v16qi __attribute__ ((__vector_size__ (16)));
// sign-extend low 3 bits to a byte.
v16qi foo (v16qi x) {
v16qi t7 = (v16qi){7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7};
v16qi t4 = (v16qi){4,4,4,4,4,4,4,4,4,4,4,4,4,4,4,4};
v16qi t = x & t7;
t ^= t4;
t -= t4;
return t;
}
which produces:
foo:movl$67372036, %eax
vmovdqa %xmm0, %xmm2
vpbroadcastd%eax, %xmm1
movl$117901063, %eax
vpbroadcastd%eax, %xmm3
vmovdqa %xmm1, %xmm0
vmovdqa %xmm3, -24(%rsp)
vmovdqa -24(%rsp), %xmm4
vpternlogd $120, %xmm2, %xmm4, %xmm0
vpsubb %xmm1, %xmm0, %xmm0
ret
[Bug target/114942] [14/15 Regression] ICE on valid code at -O1 with "-fno-tree-sra -fno-guess-branch-probability": in extract_constrain_insn, at recog.cc:2713
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114942 --- Comment #6 from GCC Commits --- The master branch has been updated by Vladimir Makarov : https://gcc.gnu.org/g:9585317f0715699197b1313bbf939c6ea3c1ace6 commit r15-364-g9585317f0715699197b1313bbf939c6ea3c1ace6 Author: Vladimir N. Makarov Date: Fri May 10 09:15:50 2024 -0400 [PR114942][LRA]: Don't reuse input reload reg of inout early clobber operand The insn in question has the same reg in inout operand and input operand. The inout operand is early clobber. LRA reused input reload reg of the inout operand for the input operand which is wrong. It were a good decision if the inout operand was not early clobber one. The patch rejects the reuse for the PR test case. gcc/ChangeLog: PR target/114942 * lra-constraints.cc (struct input_reload): Add new member early_clobber_p. (get_reload_reg): Add new arg early_clobber_p, don't reuse input reload with true early_clobber_p member value, use the arg for new element of curr_insn_input_reloads. (match_reload): Assign false to early_clobber_p member. (process_addr_reg, simplify_operand_subreg, curr_insn_transform): Adjust get_reload_reg calls. gcc/testsuite/ChangeLog: PR target/114942 * gcc.target/i386/pr114942.c: New.
[Bug middle-end/113982] Poor codegen for 64-bit add with carry widening functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113982 Jakub Jelinek changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org Status|NEW |ASSIGNED --- Comment #7 from Jakub Jelinek --- Created attachment 58179 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58179=edit gcc15-pr113982.patch Untested fix.
[Bug middle-end/115037] Unused std::vector is not optimized away.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115037 --- Comment #4 from Andrew Pinski --- https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94293#c4
[Bug middle-end/115037] Unused std::vector is not optimized away.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115037 Andrew Pinski changed: What|Removed |Added See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=94294 --- Comment #3 from Andrew Pinski --- Pr 94294
[Bug ipa/114985] [15 regression] internal compiler error: in discriminator_fail during stage2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114985 --- Comment #16 from Martin Jambor --- I'll have look, hopefully on Monday.
[Bug middle-end/115037] Unused std::vector is not optimized away.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115037
Jan Hubicka changed:
What|Removed |Added
CC||jason at redhat dot com,
||jwakely at redhat dot com
--- Comment #2 from Jan Hubicka ---
I tried to look for duplicates, but did not find one.
However I think the first problem is that we do not optimize away the store of
1 to vector while clang does. I think this is because we do not believe we can
trust that delete operator is safe?
We get:
void test ()
{
int * test$D25839$_M_impl$D25146$_M_start;
struct vector test;
int * _61;
[local count: 1073741824]:
_61 = operator new (4);
[local count: 1063439392]:
*_61 = 1;
operator delete (_61, 4);
test ={v} {CLOBBER};
test ={v} {CLOBBER(eol)};
return;
[count: 0]:
:
test ={v} {CLOBBER};
resx 2
}
If we can not trust fact that operator delete is good, perhaps we can arrange
explicit clobber before calling it? I think it is up to std::vector to decide
what it will do with the stored array so in this case even instane oprator
delete has no right to expect that the data in vector will be sane :)
[Bug rtl-optimization/115021] [14/15 regression] unnecessary spill for vpternlog
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115021 Roger Sayle changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |roger at nextmovesoftware dot com Last reconfirmed||2024-05-10 CC||roger at nextmovesoftware dot com Ever confirmed|0 |1 Status|UNCONFIRMED |NEW --- Comment #1 from Roger Sayle --- I have a patch for x86 ternlog handling that changes the output for this testcase (without the pending change to optimize V8QI shifts) to: foo:movl$67372036, %eax vpsraw $5, %xmm0, %xmm0 vpbroadcastd%eax, %xmm1 vpternlogd $108, .LC0(%rip), %xmm1, %xmm0 vpsubb %xmm1, %xmm0, %xmm0 ret .align 16 .LC0: .byte 7 .byte 7 .byte 7 .byte 7 .byte 7 .byte 7 .byte 7 .byte 7 .byte 7 .byte 7 .byte 7 .byte 7 .byte 7 .byte 7 .byte 7 .byte 7 which at least doesn't construct the vector with a broadcast, and then "spill" it to the stack before reading it back from memory. I've no idea if this is optimal, but it's certainly better than the current "spill". I'm curious about what has changed to make this code (register allocation) regress since GCC 13. It was a patch of mine that changed broadcastb to broadcastd, but that shouldn't have affected reload/register preferencing.
[Bug c++/115038] New: ICE in seh_cfa_offset since 14.1.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115038
Bug ID: 115038
Summary: ICE in seh_cfa_offset since 14.1.0
Product: gcc
Version: 14.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: reiter.christoph at gmail dot com
Target Milestone: ---
Downstream issue: https://github.com/msys2/MINGW-packages/issues/20861
The following code using GCC 14.1.0 on Windows targeting x86_64-w64-mingw32:
```
// gcc -c -fno-omit-frame-pointer -O2 repro.cpp
template void b(a, a);
template void c(a, a, float);
float d;
void e() {
float f;
c(f, f, d);
b(0.0f, f);
}
```
results in
```
repro.cpp: In function 'void e()':
repro.cpp:8:1: internal compiler error: in seh_cfa_offset, at
config/i386/winnt.cc:1137
8 | }
| ^
```
* Replacing "-O2" with "-O1" fixes the issue
* Removing "-fno-omit-frame-pointer" fixes the issue
* Downgrading to GCC 13.2.0 fixes the issue
If there is any other information I can provide, let me know.
[Bug middle-end/115037] Unused std::vector is not optimized away.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115037 --- Comment #1 from Andrew Pinski --- This might be a dup of another bug which talks about the same thing.
[Bug tree-optimization/115034] Missed optimization: reduntant store of identical value in the slot
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115034 --- Comment #2 from XChy --- (In reply to Andrew Pinski from comment #1) > Note there is some memory model requirements here that I always forget if > this can happen or not. Hmm. Could you please provide some documents about the memory model of GCC or specific constraints about C language? The semantics of IR in the LLVM issue look good to me, since the store is non-volatile and non-atomic. But I'm not sure how it would be after lifting to C.
[Bug ipa/106935] [11/12/13/14/15 Regression] ICE in redirect_call_stmt_to_callee, at cgraph.cc:1505 since r10-5098-g9b14fc3326e08797
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106935 Martin Jambor changed: What|Removed |Added CC||hubicka at gcc dot gnu.org --- Comment #4 from Martin Jambor --- We hit an assert guarding that we have not already massaged call arguments before modifying them during call redirection as that would end up in wring code. We do that by looking first whether the decl in the statement is the same as the decl of the cgraph_edge callee and if not, if the node associated with the decl from the statement has any parameter adjustment info. The issue here is that we are in the process of inlining an artificial thunk, which calls to a cgraph_node clone with adjustments from its inception. That would normally not be a problem because of the first check above (both decls would be the same, we don't really redirect these calls, not even in this case). But the call is actually recursive, and so the decl from the call graph edge is one created by save_inline_function_body whereas the one in the statement is the original one. I guess we need to detect this particular situation.
[Bug middle-end/115037] New: Unused std::vector is not optimized away.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115037
Bug ID: 115037
Summary: Unused std::vector is not optimized away.
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: hubicka at gcc dot gnu.org
Target Milestone: ---
Compiling
#include
void
test()
{
std::vector test;
test.push_back (1);
}
leads to
_Z4testv:
.LFB1253:
.cfi_startproc
subq$8, %rsp
.cfi_def_cfa_offset 16
movl$4, %edi
call_Znwm
movl$4, %esi
movl$1, (%rax)
movq%rax, %rdi
addq$8, %rsp
.cfi_def_cfa_offset 8
jmp _ZdlPvm
while clang optimizes to:
_Z4testv: # @_Z4testv
.cfi_startproc
# %bb.0:
retq
[Bug middle-end/115036] New: division is not shortened based on value range
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115036
Bug ID: 115036
Summary: division is not shortened based on value range
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: hubicka at gcc dot gnu.org
Target Milestone: ---
For
long test(long a, long b)
{
if (a > 65535 || a < 0)
__builtin_unreachable ();
if (b > 65535 || b < 0)
__builtin_unreachable ();
return a/b;
}
we produce
test:
.LFB0:
.cfi_startproc
movq%rdi, %rax
cqto
idivq %rsi
ret
while clang does:
test: # @test
.cfi_startproc
# %bb.0:
movq%rdi, %rax
# kill: def $ax killed $ax killed $rax
xorl%edx, %edx
divw%si
movzwl %ax, %eax
retq
clang also by default adds 32bit divide path even when value range is not known
long test(long a, long b)
{
return a/b;
}
compiles as
test: # @test
.cfi_startproc
# %bb.0:
movq%rdi, %rax
movq%rdi, %rcx
orq %rsi, %rcx
shrq$32, %rcx
je .LBB0_1
# %bb.2:
cqto
idivq %rsi
retq
[Bug tree-optimization/115026] [15 Regression] msp430-elf fails gcc.dg/pr66444.c with prange enabled
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115026 Aldy Hernandez changed: What|Removed |Added Status|NEW |WAITING --- Comment #6 from Aldy Hernandez --- This fixes the PR, but since prange is currently disabled, let's keep it open until it's re-enabled.
[Bug tree-optimization/115035] New: Missed optimization: fold min/max in phi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115035
Bug ID: 115035
Summary: Missed optimization: fold min/max in phi
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: xxs_chy at outlook dot com
Target Milestone: ---
Godbolt link: https://godbolt.org/z/o489f6sj5
```
bool src(unsigned a, unsigned b, bool c) {
unsigned phi;
if(c) {
dummy();
phi = a < 6 ? a : 6;
} else {
phi = b;
}
return phi < 6;
}
```
can be folded to:
```
bool tgt(unsigned a, unsigned b, bool c) {
unsigned phi;
if(c) {
dummy();
phi = a;
} else {
phi = b;
}
return phi < 6;
}
```
[Bug tree-optimization/115026] [15 Regression] msp430-elf fails gcc.dg/pr66444.c with prange enabled
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115026 --- Comment #5 from GCC Commits --- The master branch has been updated by Aldy Hernandez : https://gcc.gnu.org/g:cbd420a1c3e2bb549dc83b53cc9a31aa6b23952c commit r15-363-gcbd420a1c3e2bb549dc83b53cc9a31aa6b23952c Author: Aldy Hernandez Date: Fri May 10 12:26:49 2024 +0200 [prange] Fix thinko in prange::update_bitmask() [PR115026] gcc/ChangeLog: PR tree-optimization/115026 * value-range.cc (prange::update_bitmask): Use operand bitmask.
[Bug tree-optimization/115033] Incorrect optimization of by-reference closure fields by fre1 pass
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115033 --- Comment #3 from Spenser --- (In reply to Andrew Pinski from comment #1) > Please attach the preprocessed source rather than just a snippet of code. Sorry about that. Thought I added it when submitting the report, but I think the file was too large. I've stripped out some of the dead code and reattached.
[Bug tree-optimization/115033] Incorrect optimization of by-reference closure fields by fre1 pass
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115033 Andrew Pinski changed: What|Removed |Added Ever confirmed|1 |0 Status|WAITING |UNCONFIRMED
[Bug tree-optimization/115034] Missed optimization: reduntant store of identical value in the slot
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115034 --- Comment #1 from Andrew Pinski --- Note there is some memory model requirements here that I always forget if this can happen or not.
[Bug tree-optimization/115033] Incorrect optimization of by-reference closure fields by fre1 pass
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115033 --- Comment #2 from Spenser --- Created attachment 58178 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58178=edit Pre-processed C++ reproducer
[Bug ipa/114985] [15 regression] internal compiler error: in discriminator_fail during stage2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114985 --- Comment #15 from Segher Boessenkool --- (In reply to Aldy Hernandez from comment #11) > I have reverted the prange enabling patch until the IPA pass is fixed. Thank you!
[Bug tree-optimization/115034] New: Missed optimization: reduntant store of identical value in the slot
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115034
Bug ID: 115034
Summary: Missed optimization: reduntant store of identical
value in the slot
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: xxs_chy at outlook dot com
Target Milestone: ---
Godbolt link: https://godbolt.org/z/fdxKaxGoj
```
int src(int* outl, bool c1, bool c2) {
int a;
*outl = 0;
if (c1)
if (c2) {
dummy();
return 0;
} else {
a = 1;
}
else {
// we don't need to assign a = 0
a = 0;
}
*outl = a;
return 0;
}
```
can be transformed into:
```
int tgt(int* outl, bool c1, bool c2) {
int a;
*outl = 0;
if (c1) {
if (c2) {
dummy();
return 0;
} else {
a = 1;
}
} else {
return 0;
}
*outl = 1;
return 0;
}
```
Because "*outl = 0" is known at the entry, the path "a = 0 -> *outl = 0" can be
cut off. That is, we can move "*outl = 1" into the path where c1 is true.
[Bug rtl-optimization/115013] [15 Regression] LRA: PR114810 fix result in ICE in the RISC-V Vector
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115013 Vladimir Makarov changed: What|Removed |Added CC||vmakarov at gcc dot gnu.org --- Comment #2 from Vladimir Makarov --- Sorry for troubles. I've started to work on this PR. ETA for the fix is Monday.
[Bug libstdc++/109822] Converting std::experimental::simd masks yields an error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109822 --- Comment #12 from Matthias Kretz (Vir) --- Fixed powerpc test failure on all branches.
[Bug libstdc++/110054] stdx::simd masked store should not use non-temporal store instruction
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110054 Matthias Kretz (Vir) changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #7 from Matthias Kretz (Vir) --- Fixed on all branches.
[Bug libstdc++/114750] converting load/store of simd fails compilation on ARM
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114750 Matthias Kretz (Vir) changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #7 from Matthias Kretz (Vir) --- Fixed on all branches.
[Bug libstdc++/114803] simd conversion to [[gnu::vector_size(N)]] type hits invalid code in experimental/bits/simd_builtin.h
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114803 Matthias Kretz (Vir) changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #6 from Matthias Kretz (Vir) --- Fixed on all branches.
[Bug libstdc++/114803] simd conversion to [[gnu::vector_size(N)]] type hits invalid code in experimental/bits/simd_builtin.h
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114803 --- Comment #5 from GCC Commits --- The releases/gcc-11 branch has been updated by Matthias Kretz : https://gcc.gnu.org/g:9e3663ba96df1315f53b4b488f4c2e63633c7b2f commit r11-11434-g9e3663ba96df1315f53b4b488f4c2e63633c7b2f Author: Matthias Kretz Date: Mon Apr 22 16:12:34 2024 +0200 libstdc++: Fix conversion of simd to vector builtin Signed-off-by: Matthias Kretz libstdc++-v3/ChangeLog: PR libstdc++/114803 * include/experimental/bits/simd_builtin.h (_SimdBase2::operator __vector_type_t): There is no __builtin() function in _SimdWrapper, instead use its conversion operator. * testsuite/experimental/simd/pr114803_vecbuiltin_cvt.cc: New test. (cherry picked from commit 7ef139146a8923a8719873ca3fdae175668e8d63)
[Bug libstdc++/114750] converting load/store of simd fails compilation on ARM
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114750 --- Comment #6 from GCC Commits --- The releases/gcc-11 branch has been updated by Matthias Kretz : https://gcc.gnu.org/g:fb2f4a191cc74b6ab2899798db8a59a9b2a3f23f commit r11-11431-gfb2f4a191cc74b6ab2899798db8a59a9b2a3f23f Author: Matthias Kretz Date: Wed Apr 17 09:11:25 2024 +0200 libstdc++: Avoid ill-formed types on ARM This resolves failing tests in check-simd. Signed-off-by: Matthias Kretz libstdc++-v3/ChangeLog: PR libstdc++/114750 * include/experimental/bits/simd_builtin.h (_SimdImplBuiltin::_S_load, _S_store): Fall back to copying scalars if the memory type cannot be vectorized for the target. (cherry picked from commit 0fc7f3c6adc8543f55ec35b309016d9d9c4ddd35)
[Bug libstdc++/109822] Converting std::experimental::simd masks yields an error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109822 --- Comment #11 from GCC Commits --- The releases/gcc-11 branch has been updated by Matthias Kretz : https://gcc.gnu.org/g:4190a95cb837c5d221d9c5677f49f3c7d4d5576f commit r11-11428-g4190a95cb837c5d221d9c5677f49f3c7d4d5576f Author: Matthias Kretz Date: Fri Jun 2 21:33:04 2023 +0200 libstdc++: Avoid vector casts while still avoiding PR90424 Signed-off-by: Matthias Kretz libstdc++-v3/ChangeLog: PR libstdc++/109822 * include/experimental/bits/simd_builtin.h (_S_store): Rewrite to avoid casts to other vector types. Implement store as succession of power-of-2 sized memcpy to avoid PR90424. (cherry picked from commit 9165ede56ababd6471e7a2ce4eab30f3d5129e14)
[Bug libstdc++/110054] stdx::simd masked store should not use non-temporal store instruction
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110054 --- Comment #6 from GCC Commits --- The releases/gcc-11 branch has been updated by Matthias Kretz : https://gcc.gnu.org/g:db0c654ae689e92d8ba0421815a820278b777b06 commit r11-11427-gdb0c654ae689e92d8ba0421815a820278b777b06 Author: Matthias Kretz Date: Fri Jun 2 13:44:22 2023 +0200 libstdc++: Replace use of incorrect non-temporal store The call to the base implementation sometimes didn't find a matching signature because the _Abi parameter of _SimdImpl* was "wrong" after conversion. It has to call into ::_SimdImpl instead of the current ABI tag's _SimdImpl. This also reduces the number of possible template instantiations. Signed-off-by: Matthias Kretz libstdc++-v3/ChangeLog: PR libstdc++/110054 * include/experimental/bits/simd_builtin.h (_S_masked_store): Call into deduced ABI's SimdImpl after conversion. * include/experimental/bits/simd_x86.h (_S_masked_store_nocvt): Don't use _mm_maskmoveu_si128. Use the generic fall-back implementation. Also fix masked stores without SSE2, which were not doing anything before. (cherry picked from commit 27e45b7597d6fb1a71927d658a0294797b720c0a)
[Bug tree-optimization/115033] Incorrect optimization of by-reference closure fields by fre1 pass
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115033 Andrew Pinski changed: What|Removed |Added Last reconfirmed||2024-05-10 Status|UNCONFIRMED |WAITING Ever confirmed|0 |1 --- Comment #1 from Andrew Pinski --- Please attach the preprocessed source rather than just a snippet of code.
[Bug tree-optimization/115033] New: Incorrect optimization of by-reference closure fields by fre1 pass
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115033
Bug ID: 115033
Summary: Incorrect optimization of by-reference closure fields
by fre1 pass
Product: gcc
Version: 12.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: sleepy.iron2888 at fastmail dot com
Target Milestone: ---
## Description
I am seeing a wrong answer produced by code involving a by-reference captured
boolean value in a lambda. The code looks like the following:
```cpp
// Compute result shape
bool resultIsStatic = true;
auto resultShape = llvm::map_to_vector(newShape, [&](int64_t size) {
// This branch is taken, but the update to resultIsStatic is not
// propagated to the usage outside of the lambda.
if (!inputIsStatic) {
resultIsStatic = false;
return ShapedType::kDynamic;
}
// do something else
});
// This branch is never taken
if (resultIsStatic) {
// do the right thing
return;
}
// do the wrong thing
return;
```
In the failing example, a lambda is mapped across a range of values, producing
a new vector-like container. During the map, the `resultIsStatic` value
captured by reference is updated in the lambda, and that updated value is not
reflected in the later usage of `resultIsStatic`.
## Analysis
The attached pre-processed source file is still large, so I just want to narrow
down where I think the problem is. The mal-optimization occurs in the
`inferReshapeExpandedType` function at the end of the pre-processed source
file.
Looking at the dumped IR, I believe the bug is introduced by the `fre1` pass. I
see between `ealias` and `fre1` that the branch on the value of
`resultIsStatic` is eliminated. This seems a likely cause for the bug I am
seeing, but I am not very familiar with GCC's IR.
## GCC Invocation
Full command producing the issue:
```
g++ -O2 -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 -Wundef -O2 -std=c++17 -fno-exceptions
-funwind-tables -fno-rtti -c
```
For reference, this bug is affecting parts of LLVM, the pull request with the
workaround and description of the problem can be found here:
https://github.com/llvm/llvm-project/pull/91521
## GCC -v and System Information
This bug is reproducible in GCC 12 and GCC 13. I was unable to reproduce in GCC
11.
The GCC versions below are taken from a NixOS machine used to reproduce the bug
and track it down. It also reproduces on Debian with GCC 12. I can provide that
information as well if it will be helpful.
GCC 12 `-v` output:
```
Using built-in specs.
COLLECT_GCC=/nix/store/7b2bbh09d569jb60j3vc5icjr3wdhw3m-gcc-12.3.0/bin/gcc
COLLECT_LTO_WRAPPER=/nix/store/7b2bbh09d569jb60j3vc5icjr3wdhw3m-gcc-12.3.0/libexec/gcc/x86_64-unknown-linux-gnu/12.3.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: ../gcc-12.3.0/configure
--prefix=/nix/store/-gcc-12.3.0
--with-gmp-include=/nix/store/-gmp-with-cxx-6.3.0-dev/include
--with-gmp-lib=/nix/store/-gmp-with-cxx-6.3.0/lib
--with-mpfr-include=/nix/store/-mpfr-4.2.1-dev/include
--with-mpfr-lib=/nix/store/-mpfr-4.2.1/lib
--with-mpc=/nix/store/-libmpc-1.3.1
--with-native-system-header-dir=/nix/store/-glibc-2.39-31-dev/include
--with-build-sysroot=/
--with-gxx-include-dir=/nix/store/-gcc-12.3.0/include/c++/12.3.0/
--program-prefix= --enable-lto --disable-libstdcxx-pch
--without-included-gettext --with-system-zlib --enable-static
--enable-languages=c,c++ --disable-multilib --enable-plugin
--with-isl=/nix/store/-isl-0.20
--disable-bootstrap --build=x86_64-unknown-linux-gnu
--host=x86_64-unknown-linux-gnu --target=x86_64-unknown-linux-gnu
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 12.3.0 (GCC)
```
GCC 13 `-v` output:
```
Using built-in specs.
COLLECT_GCC=/nix/store/9hgsinpfgyvsd92v0wlvmxv9wnaal68r-gcc-13.2.0/bin/gcc
COLLECT_LTO_WRAPPER=/nix/store/9hgsinpfgyvsd92v0wlvmxv9wnaal68r-gcc-13.2.0/libexec/gcc/x86_64-unknown-linux-gnu/13.2.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: ../gcc-13.2.0/configure
--prefix=/nix/store/-gcc-13.2.0
[Bug modula2/115032] gm2/iso/run/pass/packed.mod FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115032 --- Comment #1 from Rainer Orth --- The failure started on 20240205.
[Bug modula2/115032] New: gm2/iso/run/pass/packed.mod FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115032
Bug ID: 115032
Summary: gm2/iso/run/pass/packed.mod FAILs
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: modula2
Assignee: gaius at gcc dot gnu.org
Reporter: ro at gcc dot gnu.org
Target Milestone: ---
Target: sparc-sun-solaris2.11
The gm2/iso/run/pass/packed.mod test FAILs on Solaris/SPARC with a SEGV in
cc1gm2:
+FAIL: gm2/iso/run/pass/packed.mod compilation, {additional_flags= -O3
-fomit-fr
ame-pointer -finline-functions } timeout=60 (internal compiler error:
Segmentati
on Fault signal terminated program cc1gm2)
+FAIL: gm2/iso/run/pass/packed.mod compilation, {additional_flags= -O3
-fomit-fr
ame-pointer } timeout=60 (internal compiler error: Segmentation Fault signal
ter
minated program cc1gm2)
+FAIL: gm2/iso/run/pass/packed.mod compilation, {additional_flags= -Os }
timeout
=60 (internal compiler error: Segmentation Fault signal terminated program
cc1gm
2)
+UNRESOLVED: gm2/iso/run/pass/packed.mod execution, {additional_flags= -O3
-fomi
t-frame-pointer -finline-functions } timeout=60
+UNRESOLVED: gm2/iso/run/pass/packed.mod execution, {additional_flags= -O3
-fomi
t-frame-pointer } timeout=60
+UNRESOLVED: gm2/iso/run/pass/packed.mod execution, {additional_flags= -Os }
tim
eout=60
Thread 2 received signal SIGSEGV, Segmentation fault.
[Switching to Thread 1 (LWP 1)]
build_call_expr_loc_array (loc=0, fndecl=, n=1, argarray=0xffbfcd58)
at /vol/gcc/src/hg/master/local/gcc/tree.cc:10863
10863 tree fntype = TREE_TYPE (fndecl);
(gdb) bt
#0 build_call_expr_loc_array (loc=0, fndecl=, n=1,
argarray=0xffbfcd58) at /vol/gcc/src/hg/master/local/gcc/tree.cc:10863
#1 0x0133dcc0 in build_call_expr (fndecl=, n=1)
at /vol/gcc/src/hg/master/local/gcc/tree.cc:10913
#2 0x0115c788 in build_cltz_expr (src=,
leading=, define_at_zero=)
at /vol/gcc/src/hg/master/local/gcc/tree-ssa-loop-niter.cc:2290
#3 0x0116aadc in number_of_iterations_cltz_complement (exit=,
loop=0xfa814f80, code=, niter=0xffbfd0d0)
at /vol/gcc/src/hg/master/local/gcc/tree-ssa-loop-niter.cc:2542
#4 number_of_iterations_bitcount (loop=0xfa814f80, exit=,
code=, niter=0xffbfd0d0)
at /vol/gcc/src/hg/master/local/gcc/tree-ssa-loop-niter.cc:2628
#5 number_of_iterations_exit_assumptions (loop=0xfa814f80,
exit=, niter=0xffbfd0d0, at_stmt=,
every_iteration=, body=)
at /vol/gcc/src/hg/master/local/gcc/tree-ssa-loop-niter.cc:3168
#6 0x0116cd38 in number_of_iterations_exit (loop=0xfa814f80,
exit= 13)>, niter=0xffbfd0d0, warn=false,
every_iteration=false, body=0x26a9670)
at /vol/gcc/src/hg/master/local/gcc/tree-ssa-loop-niter.cc:3257
#7 estimate_numbers_of_iterations (loop=0xfa814f80)
at /vol/gcc/src/hg/master/local/gcc/tree-ssa-loop-niter.cc:4854
#8 0x01171908 in max_loop_iterations (loop=0xfa814f80, nit=0xffbfd190)
at /vol/gcc/src/hg/master/local/gcc/tree-ssa-loop-niter.cc:4939
#9 finite_loop_p (loop=0xfa814f80)
at /vol/gcc/src/hg/master/local/gcc/tree-ssa-loop-niter.cc:3377
#10 0x010f44f4 in find_obviously_necessary_stmts (aggressive=true)
at /vol/gcc/src/hg/master/local/gcc/tree-ssa-dce.cc:509
#11 perform_tree_ssa_dce (aggressive=)
at /vol/gcc/src/hg/master/local/gcc/tree-ssa-dce.cc:2013
#12 0x010f55b8 in tree_ssa_cd_dce ()
at /vol/gcc/src/hg/master/local/gcc/tree-ssa-dce.cc:2070
#13 (anonymous namespace)::pass_cd_dce::execute (this=0x23c9530)
at /vol/gcc/src/hg/master/local/gcc/tree-ssa-dce.cc:2153
#14 0x00df19fc in execute_one_pass (pass=)
at /vol/gcc/src/hg/master/local/gcc/passes.cc:2647
#15 0x00df2470 in execute_pass_list_1 (pass=)
at /vol/gcc/src/hg/master/local/gcc/passes.cc:2756
#16 0x00df2494 in execute_pass_list_1 (
pass=)
at /vol/gcc/src/hg/master/local/gcc/passes.cc:2757
#17 0x00df24e8 in execute_pass_list (fn=0xfa856168,
pass=)
at /vol/gcc/src/hg/master/local/gcc/passes.cc:2767
#18 0x00df30ac in do_per_function_toporder (
callback=0xdf24c8 ,
data=0x23c9070) at /vol/gcc/src/hg/master/local/gcc/passes.cc:1774
#19 0x00df3350 in do_per_function_toporder (
callback=0xdf24c8 ,
data=) at /vol/gcc/src/hg/master/local/gcc/passes.cc:1741
#20 execute_ipa_pass_list (pass=)
at /vol/gcc/src/hg/master/local/gcc/passes.cc:3101
#21 0x0092df34 in ipa_passes ()
at /vol/gcc/src/hg/master/local/gcc/cgraphunit.cc:2214
#22 symbol_table::compile (this=0xfa812000)
at /vol/gcc/src/hg/master/local/gcc/cgraphunit.cc:2337
#23 0x00931d8c in symbol_table::compile (this=0xfa812000)
at /vol/gcc/src/hg/master/local/gcc/cgraphunit.cc:2315
#24 symbol_table::finalize_compilation_unit (this=0xfa812000)
at /vol/gcc/src/hg/master/local/gcc/cgraphunit.cc:2589
#25 0x00f5bb9c in compile_file ()
at /vol/gcc/src/hg/master/local/gcc/toplev.cc:476
#26 0x00f5f5ac in do_compile ()
at
[Bug target/115028] [15 regression] gcc.target/i386/pr101950-2.c FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115028 Richard Biener changed: What|Removed |Added Keywords||testsuite-fail Target Milestone|--- |15.0
[Bug c++/115031] New: g++.dg/modules/pr99023_b.X FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115031 Bug ID: 115031 Summary: g++.dg/modules/pr99023_b.X FAILs Product: gcc Version: 15.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: ro at gcc dot gnu.org Target Milestone: --- Host: sparc-sun-solaris2.11 Target: sparc-sun-solaris2.11 Build: sparc-sun-solaris2.11 The g++.dg/modules/pr99023_b.X test FAILs on Solaris/SPARC when using a 32-bit-default compiler: FAIL: g++.dg/modules/pr99023_b.X -std=c++2a 1 blank line(s) in output FAIL: g++.dg/modules/pr99023_b.X -std=c++2a (test for excess errors) Excess errors: cc1plus: out of memory allocating 1048344 bytes after a total of 7913472 bytes Strangely, this doesn't happen with a 32-bit-default Solaris/x86 compiler. The failure (I haven't checked the specifics) goes back as far as 20210219.
[Bug tree-optimization/114998] [14 Regression] ICE on valid code at -O3 with "-fno-tree-dce" on x86_64-linux-gnu: Segmentation fault since r14-9767
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114998 Richard Biener changed: What|Removed |Added Summary|[14/15 Regression] ICE on |[14 Regression] ICE on |valid code at -O3 with |valid code at -O3 with |"-fno-tree-dce" on |"-fno-tree-dce" on |x86_64-linux-gnu: |x86_64-linux-gnu: |Segmentation fault since|Segmentation fault since |r14-9767|r14-9767 Known to work||15.0 --- Comment #6 from Richard Biener --- Fixed on trunk sofar.
[Bug tree-optimization/114998] [14/15 Regression] ICE on valid code at -O3 with "-fno-tree-dce" on x86_64-linux-gnu: Segmentation fault since r14-9767
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114998 --- Comment #5 from GCC Commits --- The master branch has been updated by Richard Biener : https://gcc.gnu.org/g:34d15a4d630a0d54eddb99bdab086c506e10dac5 commit r15-362-g34d15a4d630a0d54eddb99bdab086c506e10dac5 Author: Richard Biener Date: Fri May 10 14:19:49 2024 +0200 tree-optimization/114998 - use-after-free with loop distribution When loop distribution releases a PHI node of the original IL it can end up clobbering memory that's re-used when it upon releasing its RDG resets all stmt UIDs back to -1, even those that got released. The fix is to avoid resetting UIDs based on stmts in the RDG but instead reset only those still present in the loop. PR tree-optimization/114998 * tree-loop-distribution.cc (free_rdg): Take loop argument. Reset UIDs of stmts still in the IL rather than all stmts referenced from the RDG. (loop_distribution::build_rdg): Pass loop to free_rdg. (loop_distribution::distribute_loop): Likewise. (loop_distribution::transform_reduction_loop): Likewise. * gcc.dg/torture/pr114998.c: New testcase.
[Bug c++/115030] Constrained auto variable declaration with partial specialization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115030 --- Comment #2 from Seyed Sajad Kahani --- Created attachment 58177 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58177=edit a similar code that works, as a clue (clue_1.cc) Additionally, the problem will disappear by enclosing variable in a class (see attached clue.cc)
[Bug c++/115030] Constrained auto variable declaration with partial specialization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115030
--- Comment #1 from Seyed Sajad Kahani ---
Created attachment 58176
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58176=edit
report_2.cc, additional invalid code
Moreover, by replacing 'c' with A{} that makes it an invalid code (see
attached report_2.cc) will compile successfully.
[Bug target/115029] FFT computation performance regression, x86, between gcc-14 and gcc-13 on skylake platform
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115029 --- Comment #2 from Colin Ian King --- Created attachment 58175 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58175=edit gcc-14 disassembly
[Bug target/115029] FFT computation performance regression, x86, between gcc-14 and gcc-13 on skylake platform
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115029 --- Comment #1 from Colin Ian King --- Created attachment 58174 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58174=edit gcc-13 disassembly
[Bug c++/115030] New: Constrained auto variable declaration with partial specialization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115030
Bug ID: 115030
Summary: Constrained auto variable declaration with partial
specialization
Product: gcc
Version: 14.1.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: sska1377 at gmail dot com
Target Milestone: ---
Created attachment 58173
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58173=edit
the code
This is a simple valid code that uses a constrained auto placeholder that is
dependent on template parameters, in a partial specialization variable
template.
// report_1.cc
template
concept TheConcept = __is_same(T, U);
template
struct A {
};
template
char v = 'a';
template
TheConcept auto v> = 'c';
int main() {
v>;
return 0;
}
which fails with the following error:
$ g++ report_1.cc --std=c++20
report_1.cc: In instantiation of 'auto [requires ::TheConcept<,
T>] v >':
report_1.cc:15:3: required from here
15 | v>;
| ^~
report_1.cc:12:30: error: deduced initializer does not satisfy placeholder
constraints
12 | TheConcept auto v> = 'c';
| ^~~
report_1.cc:12:30: note: constraints not satisfied
report_1.cc:2:9: required for the satisfaction of 'TheConcept, T>], T>' [with auto [requires
::TheConcept<, T>] = char; T = A]
report_1.cc:2:22: note: 'char' is not the same as 'A'
2 | concept TheConcept = __is_same(T, U);
| ^~~
This has been tested using:
$ g++ -v
Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-pc-linux-gnu/14.1.1/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /build/gcc/src/gcc/configure
--enable-languages=ada,c,c++,d,fortran,go,lto,m2,objc,obj-c++,rust
--enable-bootstrap --prefix=/usr --libdir=/usr/lib --libexecdir=/usr/lib
--mandir=/usr/share/man --infodir=/usr/share/info
--with-bugurl=https://gitlab.archlinux.org/archlinux/packaging/packages/gcc/-/issues
--with-build-config=bootstrap-lto --with-linker-hash-style=gnu
--with-system-zlib --enable-__cxa_atexit --enable-cet=auto
--enable-checking=release --enable-clocale=gnu --enable-default-pie
--enable-default-ssp --enable-gnu-indirect-function --enable-gnu-unique-object
--enable-libstdcxx-backtrace --enable-link-serialization=1
--enable-linker-build-id --enable-lto --enable-multilib --enable-plugin
--enable-shared --enable-threads=posix --disable-libssp --disable-libstdcxx-pch
--disable-werror
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 14.1.1 20240507 (GCC)
[Bug target/115028] [15 regression] gcc.target/i386/pr101950-2.c FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115028 Rainer Orth changed: What|Removed |Added Target|i386-pc-solaris2.11 |i386-pc-solaris2.11, ||x86_64-pc-linux-gnu --- Comment #3 from Rainer Orth --- I'm seeing this on Linux/x86_64, too.
[Bug target/115029] New: FFT computation performance regression, x86, between gcc-14 and gcc-13 on skylake platform
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115029 Bug ID: 115029 Summary: FFT computation performance regression, x86, between gcc-14 and gcc-13 on skylake platform Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: colin.king at intel dot com Target Milestone: --- Created attachment 58172 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58172=edit reproducer source code I'm seeing a ~0.8-1.4% performance regression in gcc-14 compared to gcc-13, using gcc on Ubuntu 24.04 computing Fast Fourier Transforms on 4096 values. Versions: gcc version 13.2.0 (Ubuntu 13.2.0-23ubuntu4) gcc version 14.0.1 20240412 (experimental) [master r14-9935-g67e1433a94f] (Ubuntu 14-20240412-0ubuntu1) cking@skylake:~$ CFLAGS="" gcc-13 reproducer-fft.c -lm -O2 cking@skylake:~$ ./a.out 1927.23 fft ops per sec CFLAGS="" gcc-14 reproducer-fft.c -lm -O2 cking@skylake:~$ ./a.out 1906.73 fft ops per sec I did some analysis on 20 runs of each gcc-13 and gcc-14 runs I noted a ~0.44 percentage std.deviation jitter in my results, but it's clear that there gcc-14 build is always 0.8%-1.4% slower on my i7-6700 test machine, so I think this is a significant regression in performance to be reported. Attached is the reproducer. The original issue appeared when regression testing stress-ng cpu fft number stressor [1]. I've managed to extract the attached reproducer from the original code (see attached). Attached are the reproducer C source and disassembled object code. References: [1] https://github.com/ColinIanKing/stress-ng/blob/master/stress-cpu.c
[Bug middle-end/113982] Poor codegen for 64-bit add with carry widening functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113982 --- Comment #6 from Jakub Jelinek --- Note, since PR95853 we also recognize bool(r > ~0ULL) as the check rather than bool(r >> 64).
[Bug target/115028] [15 regression] gcc.target/i386/pr101950-2.c FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115028 --- Comment #2 from Rainer Orth --- Created attachment 58171 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58171=edit gcc-14 assembler input
[Bug target/115028] [15 regression] gcc.target/i386/pr101950-2.c FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115028 --- Comment #1 from Rainer Orth --- Created attachment 58170 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58170=edit trunk assembler input
[Bug target/115028] New: [15 regression] gcc.target/i386/pr101950-2.c FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115028 Bug ID: 115028 Summary: [15 regression] gcc.target/i386/pr101950-2.c FAILs Product: gcc Version: 15.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: ro at gcc dot gnu.org Target Milestone: --- Target: i386-pc-solaris2.11 Between 20240506 (80c03ac8041340b29325f86ed58ea8bd40a55b99) and 20240507 (bf10f0db20db1598157505b373098bc93c66b915), the 64-bit gcc.target/i386/pr101950-2.c test regressed on Solaris/x86: FAIL: gcc.target/i386/pr101950-2.c scan-assembler-times \\txor[ql]\\t 2 There are 3 instances of xor[ql] now instead of the expected two: xorq%rax, %rdi xorl%eax, %edi xorl%eax, %eax where the gcc-14 branch has xorq%rdi, %rax xorl%edi, %eax The additional one is from @@ -20,8 +20,9 @@ .LFB1: movl%edi, %eax sarl$31, %eax - xorl%edi, %eax - lzcntl %eax, %eax + xorl%eax, %edi + xorl%eax, %eax + lzcntl %edi, %eax subl$1, %eax ret .LFE1: I'm attaching both gcc-14 and trunk assembler output.
[Bug ipa/114985] [15 regression] internal compiler error: in discriminator_fail during stage2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114985 --- Comment #14 from Jan Hubicka --- So this is problem in ipa_value_range_from_jfunc? It is Maritn's code, I hope he will know why types are wrong here. Once can get type compatibility problem on mismatched declarations and LTO, but it seems that this testcase is single-file. So indeed this looks like a bug either in jump function construction or even earlier...
[Bug tree-optimization/115026] [15 Regression] msp430-elf fails gcc.dg/pr66444.c with prange enabled
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115026 Richard Biener changed: What|Removed |Added Summary|msp430-elf fails|[15 Regression] msp430-elf |gcc.dg/pr66444.c with |fails gcc.dg/pr66444.c with |prange enabled |prange enabled Version|unknown |15.0 Keywords||wrong-code Target Milestone|--- |15.0
[Bug c/115027] Missing warning: unused struct's with self-referential initialisers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115027 Richard Biener changed: What|Removed |Added Ever confirmed|0 |1 Status|UNCONFIRMED |NEW Last reconfirmed||2024-05-10 CC||hubicka at gcc dot gnu.org Blocks||89180 Keywords||diagnostic --- Comment #1 from Richard Biener --- I think this is more an IPA issue but of course in theory the C fronted could know it's parsing the initializer of 'f' when setting TREE_USED of 'f'. Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89180 [Bug 89180] [meta-bug] bogus/missing -Wunused warnings
[Bug c++/98529] [11/12/13/14/15 Regression] g++.dg/modules/stdio-1_a.H FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98529 --- Comment #9 from Rainer Orth --- I see it's a common issue on Solaris: instead of the expected Depset:0 decl entity:204 function_decl:'::fprintf' as found on Linux, we have Depset:0 decl entity:26 function_decl:'::std::printf' What's the best way to handle this: just allow for the alternative form in the scan-lang-dump?
[Bug c/115023] __builtin_assoc_barrier does not talk about contracting even though it prevents it too
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115023 --- Comment #2 from Richard Biener --- It's supposed to behave like parens in the Fortran standard, maybe they have good wording.
[Bug rtl-optimization/115021] [14/15 regression] unnecessary spill for vpternlog
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115021 Richard Biener changed: What|Removed |Added Target Milestone|--- |14.2 Priority|P3 |P2
[Bug target/115014] GCC generates incorrect instructions for addressing the data segment through EBP register
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115014 Richard Biener changed: What|Removed |Added Target||i?86-*-* --- Comment #13 from Richard Biener --- Yeah, the C standard only guarantees pointer-to-intptr_t roundtrip for unaltered values. I also think this request is too cumbersome to implement for little benefit.
[Bug tree-optimization/115011] [14/15 Regression] Missed optimization: (bool) (f ? 1: t) ==> 1 when bool t = (0 >= f) + x;
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115011 Richard Biener changed: What|Removed |Added Priority|P3 |P2
[Bug c/115027] New: Missing warning: unused struct's with self-referential initialisers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115027
Bug ID: 115027
Summary: Missing warning: unused struct's with self-referential
initialisers
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: dave at treblig dot org
Target Milestone: ---
It would be nice to generate a warning in the following case, which I tripped
over in the Linux kernel:
#include
struct foo {
struct foo *a;
};
static struct foo f = { };
int main()
{
printf("Hello\n");
}
Here 'f' is unused outside of it's initialiser, pointing to itself.
So technically used, but practically not.
In the Linux kernel, this corresponds to it's LIST_HEAD :
(from include/linux/list.h)
#define LIST_HEAD_INIT(name) { &(name), &(name) }
#define LIST_HEAD(name) \
struct list_head name = LIST_HEAD_INIT(name)
and I've just gone through and posted patches to remove a handful of
LIST_HEADs, some of which had been unused for many years.
It would be nice if the compiler told people instead.
[Bug target/115014] GCC generates incorrect instructions for addressing the data segment through EBP register
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115014
--- Comment #12 from Martin Doucha ---
(In reply to Alexander Monakov from comment #7)
> I think your report was misunderstood. Anyway, when EBP is not a frame
> pointer, I think the chances are low that it is derived from ESP. Would
> accurate placement of segment override prefixes be worth the effort compared
> to prefixing all EBP-relative accesses with DS override?
Expanding on my previous comment (#9), EBP should be preferred to address local
arrays and local variables allocated on the stack. Access to these variables
should not have the DS prefix in order to enforce the stack limit. But trying
to trace segment association through function calls that take a pointer and
return another is not worth the effort.
(In reply to Andrew Pinski from comment #10)
> int f(int *a)
> {
> int b;
> size_t t = (size_t)
> size_t t1 = (size_t)a;
> return *(int*)(((size_t))+(t-t1));
> }
>
> Is kinda of valid c but might fail with your definition.
I assume that you're trying to associate the value of pointer "a" with the
stack segment (but that should be ()+(t1-t) instead). As you've writtend it
with the type cast to size_t before adding and subtracting, GCC should just
drop any segment association because you're adding plain numbers, not doing
actual pointer arithmetic. Without the typecast (i.e. ()+(t1-t)), the result
of the pointer arithmetic is undefined according to C standard section 6.5.6
paragraph 8.
[Bug ipa/114985] [15 regression] internal compiler error: in discriminator_fail during stage2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114985 --- Comment #13 from ro at CeBiTec dot Uni-Bielefeld.DE --- > --- Comment #12 from Aldy Hernandez --- > Created attachment 58168 > --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58168=edit > proposed patch in testing I just tried bootstrapping on sparc-sun-solaris2.11 with this patch and commit 36e877996936abd8bd08f8b1d983c8d1023a5842 Author: Aldy Hernandez Date: Tue May 7 14:05:50 2024 +0200 Enable prange support. reapplied. It ICEs in stage 2: Unsupported operand combination in dispatch: RO_PII during IPA pass: inline In file included from /vol/gcc/src/hg/master/solaris/gcc/c/c-parser.cc:26971: ./gt-c-c-parser.h:94:2: internal compiler error: in discriminator_fail, at range-op.cc:205 94 | }; | ^ 0x218a05b range_op_handler::discriminator_fail(vrange const&, vrange const&, vrange const&) const /vol/gcc/src/hg/master/solaris/gcc/range-op.cc:205 0x218a313 range_op_handler::fold_range(vrange&, tree_node*, vrange const&, vrange const&, relation_trio) const /vol/gcc/src/hg/master/solaris/gcc/range-op.cc:229 0x3569d2f ipa_vr_operation_and_type_effects /vol/gcc/src/hg/master/solaris/gcc/ipa-cp.cc:1663 0x356a337 ipa_value_range_from_jfunc(vrange&, ipa_node_params*, cgraph_edge*, ipa_jump_func*, tree_node*) /vol/gcc/src/hg/master/solaris/gcc/ipa-cp.cc:1759 0x1e1cbef evaluate_properties_for_edge(cgraph_edge*, bool, unsigned int*, unsigned int*, ipa_auto_call_arg_values*, bool) /vol/gcc/src/hg/master/solaris/gcc/ipa-fnsummary.cc:684 0x1e4ea47 do_estimate_edge_size(cgraph_edge*) /vol/gcc/src/hg/master/solaris/gcc/ipa-inline-analysis.cc:337 0x1e4fcff estimate_edge_size(cgraph_edge*) /vol/gcc/src/hg/master/solaris/gcc/ipa-inline.h:79 0x1e4fdbb estimate_edge_growth(cgraph_edge*) /vol/gcc/src/hg/master/solaris/gcc/ipa-inline.h:100 0x1e4f033 do_estimate_growth_1 /vol/gcc/src/hg/master/solaris/gcc/ipa-inline-analysis.cc:436 0x1971d87 cgraph_node::call_for_symbol_and_aliases(bool (*)(cgraph_node*, void*), void*, bool) /vol/gcc/src/hg/master/solaris/gcc/cgraph.h:3429 0x1e4f2a7 estimate_growth(cgraph_node*) /vol/gcc/src/hg/master/solaris/gcc/ipa-inline-analysis.cc:474 0x359d46f inline_small_functions /vol/gcc/src/hg/master/solaris/gcc/ipa-inline.cc:2081 0x35a1083 ipa_inline /vol/gcc/src/hg/master/solaris/gcc/ipa-inline.cc:2850 0x35a24b3 execute /vol/gcc/src/hg/master/solaris/gcc/ipa-inline.cc:3248
[Bug target/115014] GCC generates incorrect instructions for addressing the data segment through EBP register
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115014
--- Comment #11 from Xi Ruoyao ---
(In reply to Andrew Pinski from comment #10)
> int f(int *a)
> {
> int b;
> size_t t = (size_t)
> size_t t1 = (size_t)a;
> return *(int*)(((size_t))+(t-t1));
> }
>
> Is kinda of valid c but might fail with your definition.
The result of integer-to-pointer conversion is implementation-defined, so it's
not necessarily valid if the implementation has segmented memory.
[Bug target/115014] GCC generates incorrect instructions for addressing the data segment through EBP register
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115014
--- Comment #10 from Andrew Pinski ---
int f(int *a)
{
int b;
size_t t = (size_t)
size_t t1 = (size_t)a;
return *(int*)(((size_t))+(t-t1));
}
Is kinda of valid c but might fail with your definition.
[Bug target/113578] Incorrect sign printed for -nan on RISC-V
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113578 --- Comment #6 from Jonathan Wakely --- (In reply to Joseph S. Myers from comment #2) > If a conversion from float to double (for passing in variable arguments) > occurs at runtime on RISC-V, that will produce a positive-signed NaN (that's > what the RISC-V floating-point instructions do). Cf. > https://sourceware.org/bugzilla/show_bug.cgi?id=29501 (for strfrom > functions). This seems to happen on Apple M1 chips too.
[Bug target/115014] GCC generates incorrect instructions for addressing the data segment through EBP register
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115014 --- Comment #9 from Martin Doucha --- (In reply to Andrew Pinski from comment #8) > Someone in theory could also use an offset from esp and run into a similar > failure. Well yes, but that would be an actual stack overflow and the whole point is to allow basic protection against that.
[Bug target/115014] GCC generates incorrect instructions for addressing the data segment through EBP register
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115014 --- Comment #8 from Andrew Pinski --- I didn't misunderstanding it. I just think it is not a valid request. Especially when it comes to it is only this special kvm kernel. Someone in theory could also use an offset from esp and run into a similar failure.
[Bug target/115014] GCC generates incorrect instructions for addressing the data segment through EBP register
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115014 Alexander Monakov changed: What|Removed |Added CC||amonakov at gcc dot gnu.org --- Comment #7 from Alexander Monakov --- I think your report was misunderstood. Anyway, when EBP is not a frame pointer, I think the chances are low that it is derived from ESP. Would accurate placement of segment override prefixes be worth the effort compared to prefixing all EBP-relative accesses with DS override?
[Bug tree-optimization/115004] [11/12/13/14/15 Regression] Missed optimization for Dead Code Elimination
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115004 Richard Biener changed: What|Removed |Added Target Milestone|--- |11.5 Known to work||8.1.0
[Bug target/115002] [14/15 regression] wide integer vector performance regression, x86, between gcc-14 and gcc-13 using target clones on skylake platform
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115002 Richard Biener changed: What|Removed |Added Keywords||missed-optimization Target Milestone|--- |14.2
[Bug tree-optimization/114998] [14/15 Regression] ICE on valid code at -O3 with "-fno-tree-dce" on x86_64-linux-gnu: Segmentation fault since r14-9767
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114998
--- Comment #4 from Richard Biener ---
Breakpoint 5, release_ssa_name_fn (fn=0x76be4000,
var=)
at ../../src/gcc-14-branch/gcc/tree-ssanames.cc:619
619 vec_safe_push (FREE_SSANAMES_QUEUE (fn), var);
(gdb) p v.m_vecpfx
$7 = {m_alloc = 127, m_using_auto_storage = 0, m_num = 4294967295}
The issue is that loop distribution removes stmts from the last partition
(with the original stmts in the IL), and during cleanup in free_rdg
sets stmt UIDs to -1 again, but also to stmts that were released.
The simplest fix I think is to not re-set UIDs in free_rdg.
[Bug tree-optimization/115026] msp430-elf fails gcc.dg/pr66444.c with prange enabled
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115026 --- Comment #4 from Aldy Hernandez --- Jeff, if you still have your tree around, could you try this patch? I'll queue it with the rest of patches I will push before enabling prange when the IPA issues are sorted out.
[Bug tree-optimization/115026] msp430-elf fails gcc.dg/pr66444.c with prange enabled
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115026 --- Comment #3 from Aldy Hernandez --- Created attachment 58169 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58169=edit proposed patch
[Bug tree-optimization/115026] msp430-elf fails gcc.dg/pr66444.c with prange enabled
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115026 --- Comment #2 from Aldy Hernandez --- OK, this is embarrassing. We are incorrectly folding a POINTER_PLUS_EXPR range operation: Folding statement: x_7 = 2048B + _2; -Queued stmt for removal. Folds to: 2062B +Queued stmt for removal. Folds to: 0B The reason is that the prange::update_bitmask() code is ignoring its operand and using the current bitmask. I have no idea how this bootstrapped *any* architecture. I suppose it needs a value/mask pair (0xe / 0x0) for the second operand that actually indicates a singleton. *shrug* Thanks for reporting this.
[Bug target/114981] [avr] Improve powi implementation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114981 Georg-Johann Lay changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Target Milestone|--- |14.2 Resolution|--- |FIXED --- Comment #7 from Georg-Johann Lay --- The float variant is tweaked in v14.2+ The double variant is supported since v13.3+ and v14.2+.
[Bug target/114981] [avr] Improve powi implementation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114981 --- Comment #6 from GCC Commits --- The releases/gcc-14 branch has been updated by Georg-Johann Lay : https://gcc.gnu.org/g:fcdd723779f9ad9af9638e11ffe56786de2d02ce commit r14-10194-gfcdd723779f9ad9af9638e11ffe56786de2d02ce Author: Georg-Johann Lay Date: Wed May 8 17:52:56 2024 +0200 AVR: target/114981 - Tweak __builtin_powif / __powisf2 Implement __powisf2 in assembly. PR target/114981 libgcc/ * config/avr/t-avr (LIB2FUNCS_EXCLUDE): Add _powisf2. (LIB1ASMFUNCS) [!avrtiny]: Add _powif. * config/avr/lib1funcs.S (mov4): New .macro. (L_powif, __powisf2) [!avrtiny]: New module and function. gcc/testsuite/ * gcc.target/avr/pr114981-powif.c: New test. (cherry picked from commit af64af69c3cc85dbe00c520651a54850bf5cadc1)
