[Bug target/118342] `a == 0 ? 32 : __builtin_ctz(a)` for Intel and AMD cores could be implemented even without BMI1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118342 Sam James changed: What|Removed |Added Last reconfirmed||2025-01-19 Status|UNCONFIRMED |NEW Ever confirmed|0 |1
[Bug middle-end/118554] New: Allow to specify the size of an inline asm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118554
Bug ID: 118554
Summary: Allow to specify the size of an inline asm
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: gjl at gcc dot gnu.org
Target Milestone: ---
Allowing the source code to specify the size of an inline asm would have the
following benefits at least:
1) Currently, the asm size may be overly pessimistic (i.e. too big) so that
branches that are crossing the asm see a branch offset larger than required.
This can result in sub-optimal code.
2) Better cost estimates for inlining decisions etc.
3) When the asm uses macros or pseudo instructions, the size heuristic may be
overly optimistic (i.e. too small), which may lead to errors from the assembler
when branches crossing the asm cannot span the actual offset.
4) Currently, even the size of an empty asm like __asm("" : "+r" (var)) is too
pessimistic.
One way to specify the size would be a new attribute like asm_len(size), where
size is an expression that must resolve to an integer known at compile time.
Using an attribute has the advantage that the code can query whether the
feature is available or not.
[Bug gcov-profile/118553] New: gcov misses coverage after calling vfork/exec
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118553 Bug ID: 118553 Summary: gcov misses coverage after calling vfork/exec Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: gcov-profile Assignee: unassigned at gcc dot gnu.org Reporter: roland.illig at gmx dot de Target Milestone: --- When a process calls vfork and exec, any further code coverage from the parent process is not recorded. Affected: - gcc 12 - gcc 13 - gcc 14 Not affected: - gcc 10 - calls to fork (instead of vfork) - calls to posix_spawn (instead of vfork) #! /bin/sh set -eu cat
[Bug fortran/81978] Passing component of a parameter array to a subroutine causes SIGBUS crash
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81978 anlauf at gcc dot gnu.org changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |anlauf at gcc dot gnu.org --- Comment #5 from anlauf at gcc dot gnu.org --- Submitted as RFC: https://gcc.gnu.org/pipermail/fortran/2025-January/061600.html
[Bug tree-optimization/118552] [15 regression] ICE on valid code at -O3 with "-fno-tree-ch -fno-tree-ccp -fno-tree-fre" on x86_64-linux-gnu: in check_loop_closed_ssa_def, at tree-ssa-loop-manip.cc:647
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118552 Sam James changed: What|Removed |Added Version|unknown |15.0 Target Milestone|--- |15.0 Summary|ICE on valid code at -O3|[15 regression] ICE on |with "-fno-tree-ch |valid code at -O3 with |-fno-tree-ccp |"-fno-tree-ch -fno-tree-ccp |-fno-tree-fre" on |-fno-tree-fre" on |x86_64-linux-gnu: in|x86_64-linux-gnu: in |check_loop_closed_ssa_def, |check_loop_closed_ssa_def, |at |at |tree-ssa-loop-manip.cc:647 |tree-ssa-loop-manip.cc:647 Keywords||ice-on-valid-code See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=114948
[Bug middle-end/118556] New: size of asm not outputed with -dP
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118556 Bug ID: 118556 Summary: size of asm not outputed with -dP Product: gcc Version: 15.0 Status: UNCONFIRMED Keywords: inline-asm Severity: normal Priority: P3 Component: middle-end Assignee: unassigned at gcc dot gnu.org Reporter: pinskia at gcc dot gnu.org Target Milestone: --- While working on PR 118411, I noticed the lengths (size) was not being outputed for inline-asm . If it was outputted it would have been even more obvious what the bug was.
[Bug rtl-optimization/118555] New: -fopt-info reporting of why decide_unroll_constant_iterations decides against unrolling could be improved
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118555 Bug ID: 118555 Summary: -fopt-info reporting of why decide_unroll_constant_iterations decides against unrolling could be improved Product: gcc Version: 15.0 Status: UNCONFIRMED Keywords: diagnostic Severity: normal Priority: P3 Component: rtl-optimization Assignee: unassigned at gcc dot gnu.org Reporter: tiborgyri at gmail dot com CC: tiborgyri at gmail dot com Target Milestone: --- When decide_unroll_constant_iterations runs it does emit a dump message to the terminal: --- dump_printf (MSG_NOTE, "considering unrolling loop with constant " "number of iterations\n"); --- and if it does decide to unroll, report_unroll issues a passed-optimization message, nicely attached to a source location: --- dump_printf_loc (metadata, locus.get_user_location (), "loop unrolled %d times", loop->lpt_decision.times); --- Unfortunately when decide_unroll_constant_iterations decides against unrolling no messages are emitted. There are sections like this in the code: --- if (dump_file) fprintf (dump_file, ";; Not considering loop, is too big\n"); --- but I think it would be a lot more useful if these would be emitted with dump_printf, or preferably with dump_printf_loc. I would also like to note that this fprintf (dump_file, ...) idiom is not documented at https://gcc.gnu.org/onlinedocs/gccint/Dump-types.html
[Bug c++/117061] Error on use of parameter in lambda outside function body
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117061
--- Comment #3 from eczbek.void at gmail dot com ---
Another test case: https://godbolt.org/z/98joW6saj
```
auto f = [x = 0] noexcept(noexcept(x)) { return x; };
```
:1:36: error: 'x' was not declared in this scope
1 | auto f = [x = 0] noexcept(noexcept(x)) { return x; };
|^
Compiler returned: 1
[Bug c++/118255] [12/13 Regression] Unnecessary error on variable shadowing for friend declaration inside template class with non-type parameter since r9-1493-g8945521a50a7dd
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118255
--- Comment #7 from GCC Commits ---
The releases/gcc-13 branch has been updated by Simon Martin
:
https://gcc.gnu.org/g:b5d697817bbbc3f40ed74950d287a2c253318d36
commit r13-9333-gb5d697817bbbc3f40ed74950d287a2c253318d36
Author: Simon Martin
Date: Sun Jan 5 10:36:47 2025 +0100
c++: Friend classes don't shadow enclosing template class paramater
[PR118255]
We currently reject the following code
=== code here ===
template struct S { friend class non_template; };
class non_template {};
S<0> s;
=== code here ===
While EDG agrees with the current behaviour, clang and MSVC don't (see
https://godbolt.org/z/69TGaabhd), and I believe that this code is valid,
since the friend clause does not actually declare a type, so it cannot
shadow anything. The fact that we didn't error out if the non_template
class was declared before S backs this up as well.
This patch fixes this by skipping the call to check_template_shadow for
hidden bindings.
PR c++/118255
gcc/cp/ChangeLog:
* name-lookup.cc (pushdecl): Don't call check_template_shadow
for hidden bindings.
gcc/testsuite/ChangeLog:
* g++.dg/lookup/pr99116-1.C: Adjust test expectation.
* g++.dg/template/friend84.C: New test.
(cherry picked from commit b5a069203fc074ab75d994c4a7e0f2db6a0a00fd)
[Bug middle-end/118556] size of asm not outputed with -dP
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118556 --- Comment #1 from Georg-Johann Lay --- For ordinary insns, it's enough to -dp to see code length (at least on a target that implements insn attribute "length"). So -dp should suffice.
[Bug target/115817] [AVR] Suboptimal code for zeroing SRAM byte from ISR
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115817 --- Comment #5 from Georg-Johann Lay --- (In reply to Dmytro Bagrii from comment #4) > gcc is smart enough not to initialize R1 when it is not used. Actually not. The decision whether __zero_reg__ is required in an ISR is worked out by the assembler, provided -mgas-isr-prologues is on (which is the default except for -O0 and -Og). Without help from the assembler, e.g. -mno-gas-isr-prologues, avr-gcc will assume that __zero_reg__ as always used (and that __tmp_reg__ is always clobbered) in a non-naked ISR, see PR20296 / PR81268. > I'm curious whether optimizer can make a branch for ISR > (i.e. __signal__) and check both variants: using EOR R1,R1 and using LDI Rd,0 LDI cannot be used since it only allows R16...R31. > I guess the decision to use __tmp_reg__ > instead of LDI for zero value > is made on a stage other than prologue/epilogue generation. Yes. That part of prologue / epilogue generation has been implemented in the assembler, see https://sourceware.org/bugzilla/show_bug.cgi?id=21683. Advantage is that it sees though inline asm.
[Bug middle-end/118554] Allow to specify the size of an inline asm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118554
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed||2025-01-19
Ever confirmed|0 |1
--- Comment #1 from Andrew Pinski ---
That is not a bad idea. Note for inlining, GCC does have already the inline
keyword which allows to ignore the computed size when it comes to inlining and
consider the inline-asm as 0.
> 4) Currently, even the size of an empty asm like __asm("" : "+r" (var)) is
> too pessimistic.
That already is handled by the inline keyword.
so `__asm inline("" : "+r" (var));`
Yes it is documented:
https://gcc.gnu.org/onlinedocs/gcc-14.2.0/gcc/Size-of-an-asm.html
The inline keyword was added in GCC 9 though not documented on the changes
page.
[Bug target/115817] [AVR] Suboptimal code for zeroing SRAM byte from ISR
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115817 --- Comment #6 from Dmytro Bagrii --- (In reply to Georg-Johann Lay from comment #5) Thank you for explanation. > LDI cannot be used since it only allows R16...R31. I meant do not treat 0 as a special value and use LDI R24,0x00 The same as for other values. Now I see it requires GCC to treat ISR code generation as a special case on another level, which is not implemented.
[Bug tree-optimization/118077] [15 Regression] ICE when building openimageio-2.5.13: oiioversion.h:127:28: internal compiler error: in single_succ_edge, at basic-block.h:332
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118077 --- Comment #8 from Andrew Pinski --- Created attachment 60209 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=60209&action=edit Patch which I am testing
[Bug ipa/117668] fold_marked_statements in tree-inline.cc does not purge the abnormal edges after folding
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117668 --- Comment #12 from Andrew Pinski --- Created attachment 60210 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=60210&action=edit Patch which I am testing
[Bug tree-optimization/118211] tree-vectorize: vectorize input.cc, find_end_of_line
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118211 Torbjorn SVENSSON changed: What|Removed |Added CC||azoff at gcc dot gnu.org --- Comment #10 from Torbjorn SVENSSON --- (In reply to GCC Commits from comment #4) > The master branch has been updated by Tamar Christina : > > https://gcc.gnu.org/g:68326d5d1a593dc0bf098c03aac25916168bc5a9 > > commit r15-6807-g68326d5d1a593dc0bf098c03aac25916168bc5a9 > Author: Alex Coplan > Date: Mon Mar 11 13:09:10 2024 + > > vect: Force alignment peeling to vectorize more early break loops > [PR118211] > > This allows us to vectorize more loops with early exits by forcing > peeling for alignment to make sure that we're guaranteed to be able to > safely read an entire vector iteration without crossing a page boundary. > > To make this work for VLA architectures we have to allow compile-time > non-constant target alignments. We also have to override the result of > the target's preferred_vector_alignment hook if it isn't a power-of-two > multiple of the TYPE_SIZE of the chosen vector type. > > gcc/ChangeLog: > > PR tree-optimization/118211 > PR tree-optimization/116126 > * tree-vect-data-refs.cc (vect_analyze_early_break_dependences): > Set need_peeling_for_alignment flag on read DRs instead of > failing vectorization. Punt on gathers. > (dr_misalignment): Handle non-constant target alignments. > (vect_compute_data_ref_alignment): If need_peeling_for_alignment > flag is set on the DR, then override the target alignment chosen > by the preferred_vector_alignment hook to choose a safe > alignment. > (vect_supportable_dr_alignment): Override > support_vector_misalignment hook if need_peeling_for_alignment > is set on the DR: in this case we must return > dr_unaligned_unsupported in order to force peeling. > * tree-vect-loop-manip.cc (vect_do_peeling): Allow prolog > peeling by a compile-time non-constant amount. > * tree-vectorizer.h (dr_vec_info): Add new flag > need_peeling_for_alignment. > > gcc/testsuite/ChangeLog: > > PR tree-optimization/118211 > PR tree-optimization/116126 > * gcc.dg/tree-ssa/cunroll-13.c: Don't vectorize. > * gcc.dg/tree-ssa/cunroll-14.c: Likewise. > * gcc.dg/unroll-6.c: Likewise. > * gcc.dg/tree-ssa/gen-vect-28.c: Likewise. > * gcc.dg/vect/vect-104.c: Expect to vectorize. > * gcc.dg/vect/vect-early-break_108-pr113588.c: Likewise. > * gcc.dg/vect/vect-early-break_109-pr113588.c: Likewise. > * gcc.dg/vect/vect-early-break_110-pr113467.c: Likewise. > * gcc.dg/vect/vect-early-break_3.c: Likewise. > * gcc.dg/vect/vect-early-break_65.c: Likewise. > * gcc.dg/vect/vect-early-break_8.c: Likewise. > * gfortran.dg/vect/vect-5.f90: Likewise. > * gfortran.dg/vect/vect-8.f90: Likewise. > * gcc.dg/vect/vect-switch-search-line-fast.c: > > Co-Authored-By: Tamar Christina This commit causes regression for arm-none-eabi: FAIL: gcc.dg/tree-ssa/predcom-8.c scan-tree-dump-not pcom "Invalid sum" FAIL: gcc.dg/vect/vect-early-break_65.c -flto -ffat-lto-objects scan-tree-dump-times vect "vectorized 1 loops" 1 FAIL: gcc.dg/vect/vect-early-break_65.c scan-tree-dump-times vect "vectorized 1 loops" 1 This is tested on r15-7014-g413985b632a.
[Bug middle-end/118554] Allow to specify the size of an inline asm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118554
--- Comment #2 from Georg-Johann Lay ---
(In reply to Andrew Pinski from comment #1)
> That already is handled by the inline keyword.
> so `__asm inline("" : "+r" (var));`
But that's /only/ for inlining, where a "minimal" size is assumed -- whatever
"minimal" means.
Also the size is not easy to verify since contrary to ordinary insns, the
assembly file won't show the size of the asm, not even whe compiled with -dP.
[Bug middle-end/118554] Allow to specify the size of an inline asm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118554 --- Comment #3 from Andrew Pinski --- (In reply to Georg-Johann Lay from comment #2) > Also the size is not easy to verify since contrary to ordinary insns, the > assembly file won't show the size of the asm, not even whe compiled with -dP. and yes I did notice the size was not being outputted with -dP for asm when I was working PR 118411 . I tought about trying to figure out how to get it outputted but I never got around to it.
[Bug c++/95505] [coroutines] ICE assert with get_return_object_on_allocation_failure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95505 --- Comment #8 from Jonathan Wakely --- (In reply to Iain Sandoe from comment #3) > So another possibility is to make the std::no throw_t type available and > just construct a temporary object of that type when doing the lookup. That seems preferable, to avoid a dependency on the extern symbol definition for std::nothrow.
[Bug gcov-profile/118442] -fprofile-generate wrongly adds instrumentation after musttail call
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118442 --- Comment #5 from Andrew Pinski --- (In reply to Andi Kleen from comment #4) > The problem seems to be that the call BB has an extra fallthrough edge to > the > basic block containing the return. Perhaps it should just have an EXIT edge > or not split the RETURN? (not sure if that is legal in GIMPLE) That comes from flow_call_edges_add, see gimple_flow_call_edges_add in tree-cfg.cc
[Bug c++/118255] [12/13/14 Regression] Unnecessary error on variable shadowing for friend declaration inside template class with non-type parameter since r9-1493-g8945521a50a7dd
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118255
--- Comment #6 from GCC Commits ---
The releases/gcc-14 branch has been updated by Simon Martin
:
https://gcc.gnu.org/g:b1f9fb0e133e9654caecb4a6b133ce559f21ca6a
commit r14-11226-gb1f9fb0e133e9654caecb4a6b133ce559f21ca6a
Author: Simon Martin
Date: Sun Jan 5 10:36:47 2025 +0100
c++: Friend classes don't shadow enclosing template class paramater
[PR118255]
We currently reject the following code
=== code here ===
template struct S { friend class non_template; };
class non_template {};
S<0> s;
=== code here ===
While EDG agrees with the current behaviour, clang and MSVC don't (see
https://godbolt.org/z/69TGaabhd), and I believe that this code is valid,
since the friend clause does not actually declare a type, so it cannot
shadow anything. The fact that we didn't error out if the non_template
class was declared before S backs this up as well.
This patch fixes this by skipping the call to check_template_shadow for
hidden bindings.
PR c++/118255
gcc/cp/ChangeLog:
* name-lookup.cc (pushdecl): Don't call check_template_shadow
for hidden bindings.
gcc/testsuite/ChangeLog:
* g++.dg/lookup/pr99116-1.C: Adjust test expectation.
* g++.dg/template/friend84.C: New test.
(cherry picked from commit b5a069203fc074ab75d994c4a7e0f2db6a0a00fd)
[Bug tree-optimization/118557] -Wstringop-overflow false positive for span on array/string_view due to the vectorizer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118557
Andrew Pinski changed:
What|Removed |Added
Keywords||missed-optimization
Status|UNCONFIRMED |NEW
Ever confirmed|0 |1
Last reconfirmed||2025-01-19
--- Comment #4 from Andrew Pinski ---
Couple of missed optimizations which is causing the vectorizer to decide to
over vectorize:
```
_15 = SR.26_4 + _21;
if (SR.26_4 != _15)
goto ; [89.00%]
else
goto ; [11.00%]
;;succ: 10 [89.0% ...
```
Should just be if (_21 != 0)
Note I change copy to be:
```static inline
void copy(span in, span out) {
auto f = in.begin();
auto o = out.begin();
auto s = in.size();
for(size_t t = 0; t < s; t++)
{
*o++ = *f++;
}
}
```
It works.
[Bug tree-optimization/118557] New: -Wstringop-overflow false positive for span on array/string_view
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118557 Bug ID: 118557 Summary: -Wstringop-overflow false positive for span on array/string_view Product: gcc Version: 15.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: vermaelen.wouter at gmail dot com Target Milestone: --- Hi, I am aware of bug#88443 which tracks a lot of other reports about Wstringop-overflow false positives. I checked several (but not all) of the linked bugs, but I couldn't decide if my report is a duplicate or not. I'll report it anyway. Feel free to dismiss if it is a duplicate. I did make some effort to make the test case as small as possible (while still keeping the origin recognizable). See here: https://godbolt.org/z/s3v8bMEoE The warning is triggered by the 2 calls to copy() on line 63 and 64. All other code is just support code. I'm reasonably sure this code is correct: * Line 63 copies at most 8 bytes from 'part1' into the first 8 bytes of 'array a', so the destination is valid and larger or equal to the source size. * Line 64 copies at most 3 bytes from 'part2' into the last 3 bytes of 'array a', so again the destination buffer is valid and large enough to hold the source. Lines 55-60 and 65 don't fundamentally change the copy behavior, but are somehow needed to trigger the problem. The warning message "warning: writing 8 bytes into a region of size 3" seems wrong to me. We never copy 8 bytes into a region of size 3. Could it be that the sizes of both copies somehow get mixed up?
[Bug rtl-optimization/118067] [15 Regression] ICE: in lra_split_hard_reg_for, at lra-assigns.cc:1860 (unable to find a register to spill) {*lshrhi3_1} with -O -fno-split-wide-types -mavx512f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118067 --- Comment #13 from GCC Commits --- The master branch has been updated by Uros Bizjak : https://gcc.gnu.org/g:7026436fb67854c7c83f0672ed0271c34d6e3d50 commit r15-7033-g7026436fb67854c7c83f0672ed0271c34d6e3d50 Author: Uros Bizjak Date: Sun Jan 19 20:23:20 2025 +0100 i386/testsuite: Fix gcc.target/i386/pr118067*.c tests These tests use int128 type, so require target int128 instead of ! ia32. Also, use -mtune= instead of deprecated -mcpu= to avoid compiler warning. PR rtl-optimization/118067 gcc/testsuite/ChangeLog: * gcc.target/i386/pr118067.c (dg-compile): Use target int128. * gcc.target/i386/pr118067-2.c (dg-compile): Ditto. (dg-options): Use -mtune= instead of deprecated -mcpu= option.
[Bug tree-optimization/118557] -Wstringop-overflow false positive for span on array/string_view
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118557 --- Comment #1 from Andrew Pinski --- Created attachment 60206 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=60206&action=edit testcase Next time please attach the testcase or put it inline instead of just linking to godbolt.
[Bug rtl-optimization/118067] [15 Regression] ICE: in lra_split_hard_reg_for, at lra-assigns.cc:1860 (unable to find a register to spill) {*lshrhi3_1} with -O -fno-split-wide-types -mavx512f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118067 Uroš Bizjak changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #14 from Uroš Bizjak --- Fixed, thanks!
[Bug tree-optimization/118557] -Wstringop-overflow false positive for span on array/string_view
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118557 --- Comment #2 from Andrew Pinski --- `-Wall -O3`
[Bug tree-optimization/118557] -Wstringop-overflow false positive for span on array/string_view due to the vectorizer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118557 Andrew Pinski changed: What|Removed |Added Summary|-Wstringop-overflow false |-Wstringop-overflow false |positive for span on|positive for span on |array/string_view |array/string_view due to ||the vectorizer --- Comment #3 from Andrew Pinski --- -fno-tree-vectorize hides the warning. The size of 8 gave me the hint that this was most likely the vectorizer.
[Bug tree-optimization/118557] -Wstringop-overflow false positive for span on array/string_view due to the vectorizer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118557 --- Comment #5 from Andrew Pinski --- ``` if (SR.27_27 == 0) goto ; [50.00%] else goto ; [50.00%] [local count: 59055800]: _23 = MIN_EXPR ; _16 = SR.28_25 + _23; if (SR.27_27 != 0) goto ; [89.00%] else goto ; [11.00%] ``` That is also missed.
[Bug rtl-optimization/56479] [lra][avr] Register allocator can't allocate two 4-byte variables into 8 registers for inline asm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56479 Georg-Johann Lay changed: What|Removed |Added Summary|Register allocator can't|[lra][avr] Register |allocate two 4-byte |allocator can't allocate |variables into 8 registers |two 4-byte variables into 8 |for inline asm on avr-gcc |registers for inline asm Keywords||rejects-valid --- Comment #3 from Georg-Johann Lay --- Also occurs with -mlra.
[Bug testsuite/113425] gcc.dg/fold-copysign-1.c fails on arm since g:7cbe41d35e6
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113425
Torbjorn SVENSSON changed:
What|Removed |Added
CC||azoff at gcc dot gnu.org
--- Comment #5 from Torbjorn SVENSSON ---
@Tamar: You can see the same fails with 14.2.Rel1 that is available for
download from the Arm webpage.
I see the following in my gcc.log for Cortex-A7 with -mfloat-abi=hard
-mfpu=nenon:
gcc.dg/fold-copysign-1.c: pattern found 0 times
FAIL: gcc.dg/fold-copysign-1.c scan-tree-dump-times cddce1 "__builtin_copysign"
1
gcc.dg/fold-copysign-1.c: pattern found 2 times
FAIL: gcc.dg/fold-copysign-1.c scan-tree-dump-times cddce1 "= ABS_EXPR" 1
And for Cortex-M3/4/7/33/55/85 and Cortex-A7 with -mfloat-abi=soft:
gcc.dg/fold-copysign-1.c: pattern found 0 times
FAIL: gcc.dg/fold-copysign-1.c scan-tree-dump-times cddce1 "= -" 1
gcc.dg/fold-copysign-1.c: pattern found 1 times
FAIL: gcc.dg/fold-copysign-1.c scan-tree-dump-times cddce1 "= ABS_EXPR" 2
Pardon me for perhaps a stupid side question, but what happens with the stack
in the "bar" function of this testcase?
bar:
@ args = 0, pretend = 0, frame = 0
@ frame_needed = 0, uses_anonymous_args = 0
@ link register save eliminated.
push{fp}@ 27[c=8 l=4] *push_multi
orr r1, r1, #-2147483648@ 12[c=4 l=4] *iorsi3_insn/0
ldr fp, [sp], #4@ 30[c=12 l=4] *thumb2_movsi_insn/5
bx lr @ 31[c=8 l=4] *thumb2_return
Lets say that there is an interrupt firing when PC points at the "orr"
instruction. Will "fp" have the right value after the handler returns or can it
get corrupted by the interrupt handler in that case? (I'm assuming the same SP
is used for both the execution of "bar" and the handler and that the handler
code does not have any stack corruption on its own.)
[Bug rtl-optimization/118067] [15 Regression] ICE: in lra_split_hard_reg_for, at lra-assigns.cc:1860 (unable to find a register to spill) {*lshrhi3_1} with -O -fno-split-wide-types -mavx512f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118067 --- Comment #15 from GCC Commits --- The releases/gcc-14 branch has been updated by Uros Bizjak : https://gcc.gnu.org/g:94338cdf59531edb9ac944011c95d777b113ae93 commit r14-11227-g94338cdf59531edb9ac944011c95d777b113ae93 Author: Uros Bizjak Date: Fri Dec 20 16:16:15 2024 +0100 i386: Disable SImode/DImode moves from/to mask regs without avx512bw [PR118067] SImode and DImode moves from/to mask registers are valid only with AVX512BW, so mark relevant alternatives in *movsi_internal and *movdi_internal as such. Even with the patch, the testcase still fails, but now with: pr118067.c: In function âfooâ: pr118067.c:13:1: internal compiler error: maximum number of generated reload insns per insn achieved (90) 13 | } | ^ 0x2c3b581 internal_error(char const*, ...) ../../git/gcc/gcc/diagnostic-global-context.cc:517 0xb68938 lra_constraints(bool) ../../git/gcc/gcc/lra-constraints.cc:5411 0xb51a0d lra(_IO_FILE*, int) ../../git/gcc/gcc/lra.cc:2449 0xaf9f4d do_reload ../../git/gcc/gcc/ira.cc:5977 0xafa462 execute ../../git/gcc/gcc/ira.cc:6165 PR target/118067 gcc/ChangeLog: * config/i386/i386.md (*movdi_internal): Disable alternatives from/to mask registers without AVX512BW. (*movsi_internal): Ditto. (cherry picked from commit 219ddae16f9d724baeff86934f8981aa5ef7b95f)
[Bug target/118558] New: csmith: another runtime error with march=znver3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118558 Bug ID: 118558 Summary: csmith: another runtime error with march=znver3 Product: gcc Version: 15.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: dcb314 at hotmail dot com Target Milestone: --- Created attachment 60207 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=60207&action=edit C source code The attached C source code, generated by csmith, does this: foundBugs $ ~/gcc/results/bin/gcc -w bug1076.c foundBugs $ ./a.out 1 | grep g_256 ...checksum after hashing g_256[i] : 991033EB ...checksum after hashing g_256[i] : 79991091 ...checksum after hashing g_256[i] : AB373C07 foundBugs $ ~/gcc/results/bin/gcc -w -O1 bug1076.c foundBugs $ ./a.out 1 | grep g_256 ...checksum after hashing g_256[i] : 991033EB ...checksum after hashing g_256[i] : 79991091 ...checksum after hashing g_256[i] : AB373C07 foundBugs $ ~/gcc/results/bin/gcc -w -O2 bug1076.c foundBugs $ ./a.out 1 | grep g_256 ...checksum after hashing g_256[i] : 991033EB ...checksum after hashing g_256[i] : 79991091 ...checksum after hashing g_256[i] : AB373C07 foundBugs $ ~/gcc/results/bin/gcc -w -O3 bug1076.c foundBugs $ ./a.out 1 | grep g_256 ...checksum after hashing g_256[i] : 991033EB ...checksum after hashing g_256[i] : 79991091 ...checksum after hashing g_256[i] : AB373C07 foundBugs $ ~/gcc/results/bin/gcc -w -O3 -march=znver3 bug1076.c foundBugs $ ./a.out 1 | grep g_256 ...checksum after hashing g_256[i] : D02808C8 ...checksum after hashing g_256[i] : 19CE3B74 ...checksum after hashing g_256[i] : 25043566 foundBugs $ Adding -march=znver3 seems to cause problems. I have a reduction running. The problem first seems to appear sometime before 20241218: foundBugs $ ~/gcc/results.20241218.asan.ubsan/bin/gcc -w -O3 bug1076.c foundBugs $ ./a.out 1 | grep g_256 ...checksum after hashing g_256[i] : 991033EB ...checksum after hashing g_256[i] : 79991091 ...checksum after hashing g_256[i] : AB373C07 foundBugs $ ~/gcc/results.20241218.asan.ubsan/bin/gcc -w -O3 -march=znver3 bug1076.c foundBugs $ ./a.out 1 | grep g_256 ...checksum after hashing g_256[i] : D02808C8 ...checksum after hashing g_256[i] : 19CE3B74 ...checksum after hashing g_256[i] : 25043566 foundBugs $
[Bug c++/118049] conflicting global module declaration
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118049 --- Comment #6 from furyusss at yahoo dot fr --- Awesome, thanks!
[Bug target/118558] csmith: another runtime error with march=znver3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118558 --- Comment #1 from David Binderman --- Created attachment 60208 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=60208&action=edit C source code Reduced C code.
[Bug target/102018] gcc.dg/torture/pr82692.c execution fails on arm cortex-m7
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102018 Torbjorn SVENSSON changed: What|Removed |Added CC||azoff at gcc dot gnu.org --- Comment #3 from Torbjorn SVENSSON --- The reason for the failure (AFAICT), is due to that vcmpe.f64 is used for -O1, -O2 and -O3 (-Ofast also does the same, but there is no test with it). For -O0 and -Os, vcmp.f64 is instead used. Assembly for -O1: foo: @ args = 0, pretend = 0, frame = 0 @ frame_needed = 0, uses_anonymous_args = 0 @ link register save eliminated. vcmpe.f64 d0, #0 @ 43[c=4 l=4] *cmpdf_trap_vfp/1 vmrsAPSR_nzcv, FPSCR@ 44[c=4 l=4] *movcc_vfp bls .L5 @ 11[c=16 l=2] arm_cond_branch vmov.f64d7, #1.0e+0 @ 45[c=4 l=4] *thumb2_movdf_vfp/2 vcmp.f64d0, d7 @ 41[c=4 l=4] *cmpdf_vfp/0 vmrsAPSR_nzcv, FPSCR@ 42[c=4 l=4] *movcc_vfp bgt .L5 @ 18[c=16 l=2] arm_cond_branch vmul.f64d0, d0, d0 @ 26[c=24 l=4] *muldf3_vfp bx lr @ 49[c=8 l=4] *thumb2_return .L5: vadd.f64d0, d0, d0 @ 21[c=16 l=4] *adddf3_vfp bx lr @ 39[c=8 l=4] *thumb2_return Assembly for -Os: foo: @ args = 0, pretend = 0, frame = 0 @ frame_needed = 0, uses_anonymous_args = 0 @ link register save eliminated. vcmp.f64d0, #0 @ 64[c=4 l=4] *cmpdf_vfp/1 vmrsAPSR_nzcv, FPSCR@ 65[c=4 l=4] *movcc_vfp bls .L2 @ 8 [c=16 l=2] arm_cond_branch vmov.f64d7, #1.0e+0 @ 13[c=4 l=4] *thumb2_movdf_vfp/2 vcmp.f64d0, d7 @ 62[c=4 l=4] *cmpdf_vfp/0 vmrsAPSR_nzcv, FPSCR@ 63[c=4 l=4] *movcc_vfp ble .L4 @ 15[c=16 l=2] arm_cond_branch .L2: vadd.f64d0, d0, d0 @ 18[c=4 l=4] *adddf3_vfp bx lr @ 60[c=8 l=4] *thumb2_return .L4: vmul.f64d0, d0, d0 @ 23[c=4 l=4] *muldf3_vfp bx lr @ 69[c=8 l=4] *thumb2_return The above was extracted from compiling using: arm-none-eabi-gcc pr82692.c -mthumb -march=armv7e-m+fp.dp -mtune=cortex-m7 -mfloat-abi=hard -mfpu=auto -S -o - -Os This bug is only present if -mtune=cortex-m7 or -mcpu=cortex-m7 is used. I suppose it has something to do with the cost model for Cortex-M7 as otherwise, Cortex-M4 would likely be affected too.
[Bug target/118558] csmith: another runtime error with march=znver3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118558 --- Comment #2 from Sam James --- Let me re-reduce it. UBSAN complains on the reduced one.
[Bug libstdc++/118559] New: [15 Regression] __array_rank is broken for clang so need workaround in libstdc++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118559 Bug ID: 118559 Summary: [15 Regression] __array_rank is broken for clang so need workaround in libstdc++ Product: gcc Version: 15.0 Status: UNCONFIRMED Keywords: rejects-valid Severity: normal Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: pinskia at gcc dot gnu.org Target Milestone: --- clang seems to have a broken __array_rank and I have no idea when it will be fixed but we should most likely disable the use of __array_rank in libstdc++ for clang until it is known that clang is fixed. See upstream clang bug https://github.com/llvm/llvm-project/issues/123498 for more details on it.
[Bug libstdc++/118559] [15 Regression] __array_rank is broken for clang so need workaround in libstdc++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118559 Andrew Pinski changed: What|Removed |Added Target Milestone|--- |15.0
[Bug middle-end/101521] -ftrapv should become something like -fsanitize=undefined -fsanitize-undefined-trap-on-error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101521 Hans-Peter Nilsson changed: What|Removed |Added CC||hp at gcc dot gnu.org --- Comment #5 from Hans-Peter Nilsson --- (In reply to Andrew Pinski from comment #0) > As mentioned a few times -ftrapv is broken in many cases it would be better > if it become something like -fsanitize=undefined > -fsanitize-undefined-trap-on-error. Wouldn't that require sanitizer support for the target?
[Bug middle-end/101521] -ftrapv should become something like -fsanitize=undefined -fsanitize-undefined-trap-on-error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101521 --- Comment #6 from Andrew Pinski --- (In reply to Hans-Peter Nilsson from comment #5) > (In reply to Andrew Pinski from comment #0) > > As mentioned a few times -ftrapv is broken in many cases it would be better > > if it become something like -fsanitize=undefined > > -fsanitize-undefined-trap-on-error. > > Wouldn't that require sanitizer support for the target? In the case of `-fsanitize-undefined-trap-on-error` does not require any sanitizer support as what was a sanitizer call just becomes a __builtin_trap call. It does require the target to have support for the trap optab or the support for the abort call but I think that is currently supported for all targets right now. The trap optab would definitely improve things if not already supported on the target too.
[Bug target/117688] [15 Regression] RISC-V: Wrong code for .SAT_SUB
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117688 --- Comment #6 from Li Pan --- Ack, looks like a code-gen issue for the risc-v backend, let me try to reproduce it from qemu and dev-board.
[Bug target/118560] New: [15 regression] ICE when building powerpc-unknown-linux-gnu cross-compiler
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118560
Bug ID: 118560
Summary: [15 regression] ICE when building
powerpc-unknown-linux-gnu cross-compiler
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Keywords: build, ice-on-valid-code
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: sjames at gcc dot gnu.org
Target Milestone: ---
Created attachment 60211
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=60211&action=edit
_sd_to_usi.i.xz
Last week's snapshot was fine.
```
$
/var/tmp/portage/cross-powerpc-unknown-linux-gnu/gcc-15.0.1_pre20250119/work/build/./gcc/cc1
-fpreprocessed ../../../build/powerpc-unknown-linux-gnu/libgcc/_sd_to_usi.i -O2
getchar fgetc_unlocked getc_unlocked getchar_unlocked putchar fputc_unlocked
putc_unlocked putchar_unlocked feof_unlocked ferror_unlocked sprintf vsprintf
snprintf vsnprintf fprintf printf vprintf vfprintf dprintf vdprintf fgets fread
fread_unlocked atoi atol atoll __bswap_16 __bswap_32 __bswap_64
__uint16_identity __uint32_identity __uint64_identity bsearch atof realpath
ptsname_r wctomb mbstowcs wcstombs bcopy bzero memcpy memmove memset
explicit_bzero strcpy stpcpy strncpy stpncpy strcat strncat strlcpy strlcat
dfp_binary_op d32_binary_op dfp_compare_op d32_compare_op
dfp_conversion_exceptions __dpd_fixunssdsi
Analyzing compilation unit
Performing interprocedural optimizations
<*free_lang_data> {heap 1296k} {heap 1296k}
{heap 1296k} {heap 1620k} {heap 2212k}
{heap 2212k} {heap 2212k}
{heap 2212k}Streaming LTO
{heap 2212k} {heap 2212k} {heap
2212k} {heap 2212k} {heap 2212k} {heap 2212k}
{heap 2212k} {heap 2212k} {heap 2212k} {heap
2212k} {heap 2212k} {heap 2212k}
{heap 2212k} {heap 2212k}Assembling functions:
__dpd_fixunssdsiduring RTL pass: reload
/var/tmp/portage/cross-powerpc-unknown-linux-gnu/gcc-15.0.1_pre20250119/work/gcc-15-20250119/libgcc/dfp-bit.c:
In function '__dpd_fixunssdsi':
/var/tmp/portage/cross-powerpc-unknown-linux-gnu/gcc-15.0.1_pre20250119/work/gcc-15-20250119/libgcc/dfp-bit.c:502:1:
internal compiler error: in rs6000_emit_move, at config/rs6000/rs6000.cc:11091
502 | }
| ^
0x7c31fde03546 __libc_start_call_main
../sysdeps/nptl/libc_start_call_main.h:58
0x7c31fde035f6 __libc_start_main_impl
../csu/libc-start.c:360
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See <https://bugs.gentoo.org/> for instructions.
```
---
```
$
/var/tmp/portage/cross-powerpc-unknown-linux-gnu/gcc-15.0.1_pre20250119/work/build/./gcc/xgcc
-v
Using built-in specs.
COLLECT_GCC=/var/tmp/portage/cross-powerpc-unknown-linux-gnu/gcc-15.0.1_pre20250119/work/build/./gcc/xgcc
Target: powerpc-unknown-linux-gnu
Configured with:
/var/tmp/portage/cross-powerpc-unknown-linux-gnu/gcc-15.0.1_pre20250119/work/gcc-15-20250119/configure
--host=x86_64-pc-linux-gnu --target=powerpc-unknown-linux-gnu
--build=x86_64-pc-linux-gnu --prefix=/usr
--bindir=/usr/x86_64-pc-linux-gnu/powerpc-unknown-linux-gnu/gcc-bin/15
--includedir=/usr/lib/gcc/powerpc-unknown-linux-gnu/15/include
--datadir=/usr/share/gcc-data/powerpc-unknown-linux-gnu/15
--mandir=/usr/share/gcc-data/powerpc-unknown-linux-gnu/15/man
--infodir=/usr/share/gcc-data/powerpc-unknown-linux-gnu/15/info
--with-gxx-include-dir=/usr/lib/gcc/powerpc-unknown-linux-gnu/15/include/g++-v15
--disable-silent-rules --disable-dependency-tracking
--with-python-dir=/share/gcc-data/powerpc-unknown-linux-gnu/15/python
--enable-languages=c,c++ --enable-obsolete --enable-secureplt --disable-werror
--with-system-zlib --disable-nls --disable-libunwind-exceptions
--enable-checking=yes,extra --with-bugurl=https://bugs.gentoo.org/
--with-pkgversion='Gentoo 15.0.1_pre20250119 p42' --with-gcc-major-version-only
--enable-libstdcxx-time --enable-lto --disable-libstdcxx-pch
--enable-poison-system-directories
--with-sysroot=/usr/powerpc-unknown-linux-gnu --disable-gcov
--disable-bootstrap --enable-__cxa_atexit --enable-clocale=gnu
--disable-multilib --disable-fixed-point --enable-targets=all --disable-libgomp
--disable-libssp --disable-libada --disable-systemtap
--enable-valgrind-annotations --disable-vtable-verify --disable-libvtv
--without-zstd --without-isl --disable-libsanitizer --enable-default-pie
--enable-host-pie --disable-host-bind-now --enable-default-ssp
--disable-fixincludes
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 15.0.1 20250119 (experimental) (Gentoo 15.0.1_pre20250119 p42)
```
[Bug target/118560] [15 regression] ICE when building powerpc-unknown-linux-gnu cross-compiler
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118560 Sam James changed: What|Removed |Added Target Milestone|--- |15.0
[Bug target/118510] [15 Regression][x86] ICE in extract_insn, at recog.cc:2869 with -mapxf since r15-5635-g1ff69000b50e8a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118510 --- Comment #3 from GCC Commits --- The master branch has been updated by Hongyu Wang : https://gcc.gnu.org/g:af4fb245e12f2dd8e2c32167c9acfaceb4b6af6a commit r15-7036-gaf4fb245e12f2dd8e2c32167c9acfaceb4b6af6a Author: Hongyu Wang Date: Fri Jan 17 09:04:17 2025 +0800 i386: Fix wrong insn generated by shld/shrd ndd split [PR118510] For shld/shrd_ndd_2 insn, the spiltter outputs wrong pattern that mixed parallel for clobber and set. Use register_operand as dest and ajdust output template to fix. gcc/ChangeLog: PR target/118510 * config/i386/i386.md (*x86_64_shld_ndd_2): Use register_operand for operand[0] and adjust the output template to directly generate ndd form shld pattern. (*x86_shld_ndd_2): Likewise. (*x86_64_shrd_ndd_2): Likewise. (*x86_shrd_ndd_2): Likewise. gcc/testsuite/ChangeLog: PR target/118510 * gcc.target/i386/pr118510.c: New test.
[Bug target/118538] throw not caught causing an seg fault rather than a `terminate called after throwing an instance of 'int'` message
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118538 --- Comment #14 from Matthias Klose --- I'll look at this when I'm back from traveling. 14.2.0-4ubuntu2~24.04 is based on the gcc-14 branch 7e0649ac0fab8e0673e3eba8d357f1a21463ae0f
[Bug target/118538] throw not caught causing an seg fault rather than a `terminate called after throwing an instance of 'int'` message
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118538
--- Comment #15 from Disservin ---
Here's a smaller reproduction btw
cat test.cpp && g++ -O0 -std=c++17 -Wall -Wextra -Wpedantic -Wuninitialized
-fno-strict-aliasing -fwrapv -g3 test.cpp && ./a.out
#include
class StreamParser {
public:
StreamParser(std::istream &stream) : stream_buffer(stream) {}
private:
class StreamBuffer {
private:
static constexpr ::size_t N = 1024;
public:
StreamBuffer(std::istream &stream) : stream_(stream) {}
private:
std::istream &stream_;
char buffer_[N * N];
};
StreamBuffer stream_buffer;
};
class Reader {
public:
Reader(const std::string , int ) {
std::ifstream file;
throw 42;
StreamParser parser(file);
}
};
int main() { auto reader = Reader("file", 1); }
test.cpp: In function ‘int main()’:
test.cpp:28:19: warning: variable ‘reader’ set but not used
[-Wunused-but-set-variable]
28 | int main() { auto reader = Reader("file", 1); }
| ^~
[1]1182995 segmentation fault (core dumped) ./a.out
[Bug target/118538] throw not caught causing an seg fault rather than a `terminate called after throwing an instance of 'int'` message
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118538 --- Comment #16 from Disservin --- Since the reproduction involves a fairly large array, I checked my configured stack size on the system, which is 8MiB. It also segfaults with a lower value for N like 800, but if I go down to like 500, I get the expected "terminate called.." ulimit -a -t: cpu time (seconds) unlimited -f: file size (blocks) unlimited -d: data seg size (kbytes) unlimited -s: stack size (kbytes) 8192 ...
[Bug tree-optimization/118552] New: ICE on valid code at -O3 with "-fno-tree-ch -fno-tree-ccp -fno-tree-fre" on x86_64-linux-gnu: in check_loop_closed_ssa_def, at tree-ssa-loop-manip.cc:647
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118552
Bug ID: 118552
Summary: ICE on valid code at -O3 with "-fno-tree-ch
-fno-tree-ccp -fno-tree-fre" on x86_64-linux-gnu: in
check_loop_closed_ssa_def, at
tree-ssa-loop-manip.cc:647
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: zhendong.su at inf dot ethz.ch
Target Milestone: ---
Compiler Explorer: https://godbolt.org/z/8bWreE4fa
Also see: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114948
[509] % gcctk -v
Using built-in specs.
COLLECT_GCC=gcctk
COLLECT_LTO_WRAPPER=/local/suz-local/software/local/gcc-trunk/libexec/gcc/x86_64-pc-linux-gnu/15.0.1/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc-trunk/configure --disable-bootstrap
--enable-checking=yes --prefix=/local/suz-local/software/local/gcc-trunk
--enable-sanitizers --enable-languages=c,c++ --disable-werror --enable-multilib
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 15.0.1 20250119 (experimental) (GCC)
[510] %
[510] % gcctk -O3 -fno-tree-ch -fno-tree-ccp -fno-tree-fre small.c
during GIMPLE pass: cunroll
small.c: In function ‘main’:
small.c:3:5: internal compiler error: in check_loop_closed_ssa_def, at
tree-ssa-loop-manip.cc:647
3 | int main() {
| ^~~~
0x26d8a36 internal_error(char const*, ...)
../../gcc-trunk/gcc/diagnostic-global-context.cc:517
0xac3734 fancy_abort(char const*, int, char const*)
../../gcc-trunk/gcc/diagnostic.cc:1722
0x9005f9 check_loop_closed_ssa_def
../../gcc-trunk/gcc/tree-ssa-loop-manip.cc:647
0x13f1804 check_loop_closed_ssa_bb
../../gcc-trunk/gcc/tree-ssa-loop-manip.cc:661
0x13f33fe verify_loop_closed_ssa(bool, loop*)
../../gcc-trunk/gcc/tree-ssa-loop-manip.cc:697
0x13f33fe verify_loop_closed_ssa(bool, loop*)
../../gcc-trunk/gcc/tree-ssa-loop-manip.cc:681
0x13d9e69 tree_unroll_loops_completely
../../gcc-trunk/gcc/tree-ssa-loop-ivcanon.cc:1623
0x13d9f05 execute
../../gcc-trunk/gcc/tree-ssa-loop-ivcanon.cc:1727
0x13d9f05 execute
../../gcc-trunk/gcc/tree-ssa-loop-ivcanon.cc:1717
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.
[511] %
[511] % cat small.c
volatile int a;
int b, c, d, e;
int main() {
int f = 1, g = 1;
h:
if (!d)
;
else {
int i = 1;
j:
e = 0;
for (; e < 3; e++) {
if (e)
for (; g < 2; g++) {
if (c)
return 0;
if (f)
goto j;
}
a;
if (i)
continue;
f = i = 0;
}
}
f = 2;
b++;
if (c)
goto h;
return 0;
}
[Bug rtl-optimization/118562] New: SEGV in late-combine (rtl_ssa::function_info::remove_use)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118562
Bug ID: 118562
Summary: SEGV in late-combine
(rtl_ssa::function_info::remove_use)
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: rtl-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: anton at ozlabs dot org
Target Milestone: ---
The following (creduced) testcase:
float b[2], c[2];
void d();
int e() {
int f, g;
float *h;
for (f = 0; f < 4; f++) {
g = e();
if (g)
d();
}
for (g = 0; g < 4; g++) {
c[0] = h[0] - b[0];
c[1] = h[1] - b[1];
d();
h += 1;
}
}
when built with:
riscv64-unknown-linux-gnu-gcc -O2 -march=rv64gv -c testcase.c
Hits a SEGV:
#0 rtl_ssa::function_info::remove_use (this=this@entry=0x4b22110,
use=0x4ac0a80)
at source/gcc/gcc/rtl-ssa/accesses.cc:1276
#1 0x02ec59e4 in rtl_ssa::function_info::change_insns (this=, changes=...)
at source/gcc/gcc/rtl-ssa/changes.cc:749
#2 0x02e6b47f in (anonymous namespace)::insn_combination::run
(this=0x7fffe1c0)
at source/gcc/gcc/late-combine.cc:453
#3 (anonymous namespace)::late_combine::combine_into_uses
(this=0x7fffe290, insn=,
cursor=0x4abe7f8) at source/gcc/gcc/late-combine.cc:684
#4 0x02e6bbd6 in (anonymous namespace)::late_combine::execute
(fn=, this=0x7fffe290)
at source/gcc/gcc/late-combine.cc:712
#5 (anonymous namespace)::pass_late_combine::execute (this=,
fn=)
at source/gcc/gcc/late-combine.cc:765
#6 0x012f53d2 in execute_one_pass (pass=0x495d120)
at source/gcc/gcc/passes.cc:2659
Compiler details:
Using built-in specs.
COLLECT_GCC=toolchain/bin/riscv64-unknown-linux-gnu-gcc
COLLECT_LTO_WRAPPER=toolchain/libexec/gcc/riscv64-unknown-linux-gnu/15.0.1/lto-wrapper
Target: riscv64-unknown-linux-gnu
Configured with: source/gcc/configure --target=riscv64-unknown-linux-gnu
--prefix=toolchain --with-sysroot=toolchain/sysroot --disable-nls
--disable-shared --disable-multilib --disable-threads --disable-libatomic
--disable-libgomp --disable-libquadmath --disable-libssp --disable-libvtv
--disable-bootstrap CFLAGS='-g -O'
Thread model: single
Supported LTO compression algorithms: zlib
gcc version 15.0.1 20250120 (experimental) (GCC)
[Bug rtl-optimization/118562] [15 Regression] SEGV in late-combine (rtl_ssa::function_info::remove_use)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118562
Andrew Pinski changed:
What|Removed |Added
Ever confirmed|0 |1
CC||rsandifo at gcc dot gnu.org
Summary|SEGV in late-combine|[15 Regression] SEGV in
|(rtl_ssa::function_info::re |late-combine
|move_use) |(rtl_ssa::function_info::re
||move_use)
Last reconfirmed||2025-01-20
Status|UNCONFIRMED |NEW
Target Milestone|--- |15.0
--- Comment #4 from Andrew Pinski ---
Confirmed.
This is related to frm (floating point rounding mode register):
trying to combine definition of r69 in:
67: frm:SI=frm:SI
into:
63: v1:V2SF={(unspec[const_vector,0x2,0x2,0x2,0x2,0x7,vl:SI,vtype:SI,frm:SI]
91)?v1:V2SF-v2:V2SF:unspec[zero:DI] 90}
REG_EQUIV [s3:DI]
successfully matched this instruction to pred_subv2sf:
(set (reg:V2SF 97 v1 [orig:148 vect__3.12_19 ] [148])
(if_then_else:V2SF (unspec:V2BI [
(const_vector:V2BI [
(const_int 1 [0x1]) repeated x2
])
(const_int 2 [0x2]) repeated x4
(const_int 7 [0x7])
(reg:SI 66 vl)
(reg:SI 67 vtype)
(reg:SI 69 frm)
] UNSPEC_VPREDICATE)
(minus:V2SF (reg:V2SF 97 v1 [orig:149 MEM
[(floatD.36 *)h_29 clique 1 base 1] ] [149])
(reg:V2SF 98 v2 [orig:150 MEM [(floatD.36
*)&bD.2797 clique 1 base 0] ] [150]))
(unspec:V2SF [
(reg:DI 0 zero)
] UNSPEC_VUNDEF)))
63: v1:V2SF={(unspec[const_vector,0x2,0x2,0x2,0x2,0x7,vl:SI,vtype:SI,frm:SI]
91)?v1:V2SF-v2:V2SF:unspec[zero:DI] 90}
REG_EQUIV [s3:DI]
successfully matched this instruction to pred_subv2sf:
(set (reg:V2SF 97 v1 [orig:148 vect__3.12_19 ] [148])
(if_then_else:V2SF (unspec:V2BI [
(const_vector:V2BI [
(const_int 1 [0x1]) repeated x2
])
(const_int 2 [0x2]) repeated x4
(const_int 7 [0x7])
(reg:SI 66 vl)
(reg:SI 67 vtype)
(reg:SI 69 frm)
] UNSPEC_VPREDICATE)
(minus:V2SF (reg:V2SF 97 v1 [orig:149 MEM
[(floatD.36 *)h_29 clique 1 base 1] ] [149])
(reg:V2SF 98 v2 [orig:150 MEM [(floatD.36
*)&bD.2797 clique 1 base 0] ] [150]))
(unspec:V2SF [
(reg:DI 0 zero)
] UNSPEC_VUNDEF)))
original cost = 0 + 4 + 4 (weighted: 31.99), replacement cost = 4 + 4
(weighted: 31.99); keeping replacement
verify found no changes in insn with uid = 63.
I am not sure if representing frm as a normal SI register is something which is
ok but I could be wrong.
[Bug tree-optimization/118552] [15 regression] ICE on valid code at -O3 with "-fno-tree-ch -fno-tree-ccp -fno-tree-fre" on x86_64-linux-gnu: in check_loop_closed_ssa_def, at tree-ssa-loop-manip.cc:647
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118552 Sam James changed: What|Removed |Added Ever confirmed|0 |1 Last reconfirmed||2025-01-20 Status|UNCONFIRMED |NEW --- Comment #1 from Sam James --- Confirmed.
[Bug tree-optimization/118558] [15 Regression] csmith: another runtime error with march=znver3 since r15-3467-g5df05de3d91775
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118558 Richard Biener changed: What|Removed |Added Priority|P3 |P1 Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org --- Comment #8 from Richard Biener --- Mine.
[Bug target/118561] ICE calling __builtin_lasx_xvpickve2gr_w with lasx disabled
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118561 Andrew Pinski changed: What|Removed |Added Keywords|needs-bisection |error-recovery Summary|[15 Regression] ICE calling |ICE calling |__builtin_lasx_xvpickve2gr_ |__builtin_lasx_xvpickve2gr_ |w with lasx disabled|w with lasx disabled --- Comment #1 from Andrew Pinski --- >t.c:5: confused by earlier errors, bailing out Is the ICE in GCC 14 due to --enable-checking=release which prints this out if there was an ICE after an error out. So this is NOT GCC 15 regression.
[Bug rtl-optimization/118562] SEGV in late-combine (rtl_ssa::function_info::remove_use)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118562 Andrew Pinski changed: What|Removed |Added Keywords||ice-on-valid-code --- Comment #1 from Andrew Pinski --- float *h; Is not initialized. Now I suspect in the original testcase it was though.
[Bug target/118558] csmith: another runtime error with march=znver3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118558 Andrew Pinski changed: What|Removed |Added Ever confirmed|0 |1 Status|UNCONFIRMED |NEW Last reconfirmed||2025-01-20 --- Comment #5 from Andrew Pinski --- Confirmed.
[Bug target/118558] csmith: another runtime error with march=znver3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118558 Andrew Pinski changed: What|Removed |Added Attachment #60208|0 |1 is obsolete|| --- Comment #4 from Andrew Pinski --- Created attachment 60212 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=60212&action=edit reduced testcase Fails with `-O3 -march=znver3` but works with `-O3`.
[Bug target/118558] csmith: another runtime error with march=znver3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118558 --- Comment #6 from Sam James --- -O2 -fno-vect-cost-model is enough
[Bug rtl-optimization/118562] SEGV in late-combine (rtl_ssa::function_info::remove_use)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118562 --- Comment #3 from Anton Blanchard --- Thanks Andrew, your fixed test case hits the fail.
[Bug target/118561] ICE calling __builtin_lasx_xvpickve2gr_w with lasx disabled
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118561
--- Comment #2 from chenglulu ---
test.c
```
int
test ()
{
return __builtin_loongarch_movfcsr2gr (0);
}
```
./gcc/cc1
[Bug tree-optimization/110919] [14/15 Regression] Dead Code Elimination Regression at -O3 since r14-1691-gbc5a2c2e793
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110919 --- Comment #11 from Andrew Pinski --- Created attachment 60214 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=60214&action=edit Better testcase
[Bug target/118561] ICE calling __builtin_lasx_xvpickve2gr_w with lasx disabled
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118561
--- Comment #3 from chenglulu ---
(In reply to chenglulu from comment #2)
> test.c
> ```
> int
> test ()
> {
> return __builtin_loongarch_movfcsr2gr (0);
> }
> ```
> ./gcc/cc1
$ ./gcc/cc1 test.c -o - -O2 -mfpu=none
The above test cases are experiencing the same issue.
[Bug gcov-profile/118553] [12/13/14 regression] gcov misses coverage after calling vfork/exec
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118553 Sam James changed: What|Removed |Added Known to work||15.0 Summary|[12/13/14/15 regression]|[12/13/14 regression] gcov |gcov misses coverage after |misses coverage after |calling vfork/exec |calling vfork/exec --- Comment #1 from Sam James --- Seems to work on trunk for me.
[Bug target/118561] ICE calling __builtin_lasx_xvpickve2gr_w with lasx disabled
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118561
--- Comment #4 from chenglulu ---
In the above test cases, target is always NULL_RTX. When an illegal built-in
call occurs, we return this NULL_RTX, but after returning, do not check whether
the returned value is NULL（eg:expr.cc +9858）, which leads to ICE.
Therefore, when an illegal built-in function call occurs, returning const0_rtx
can solve the problem.
I'm not sure if this modification is correct.
diff --git a/gcc/config/loongarch/loongarch-builtins.cc
b/gcc/config/loongarch/loongarch-builtins.cc
index 92d995a916a..6dd7201e6b9 100644
--- a/gcc/config/loongarch/loongarch-builtins.cc
+++ b/gcc/config/loongarch/loongarch-builtins.cc
@@ -3036,7 +3036,7 @@ loongarch_expand_builtin (tree exp, rtx target, rtx
subtarget ATTRIBUTE_UNUSED,
{
error_at (EXPR_LOCATION (exp),
"built-in function %qD is not enabled", fndecl);
- return target;
+ return target ? target : const0_rtx;
}
[Bug tree-optimization/110919] [14/15 Regression] Dead Code Elimination Regression at -O3 since r14-1691-gbc5a2c2e793
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110919 Andrew Pinski changed: What|Removed |Added Assignee|pinskia at gcc dot gnu.org |unassigned at gcc dot gnu.org Status|ASSIGNED|NEW --- Comment #12 from Andrew Pinski --- So what r14-1691-gbc5a2c2e793 does is correct. # RANGE [irange] unsigned int [0, 0][4, 4][+INF, +INF] unsigned intD.14 l_14(D) = lD.2821; vs before: # RANGE [irange] unsigned int [0, 0][4, +INF] unsigned intD.14 l_14(D) = lD.2821; This change causes: c_16 = (short int) l_14(D); if (c_16 == 0) goto ; [50.00%] else goto ; [50.00%] To be optimized to `goto ` because it is on the path where `l_14(D) != 0`. And then from: [local count: 628138967]: # iftmp.1_7 = PHI <1(3), 0(6)> We get: [local count: 628138968]: # iftmp.1_7 = PHI <_16(3), 0(5)> Which DOM is not able to jump thread ... If could copy `bb 6`, then it might be optimizable. the path along 5, gets optimized to false. The other path we have: ``` _16 = l_14(D) == 0; (iftmp.1_7) _4 = (int) iftmp.1_7; _6 = e; _19 = _4 == _6; _5 = ~iftmp.1_7; _20 = _6 != 0; _9 = _5 & _20; _3 = _9 & _19; ... ``` or ``` _20 = _6 != 0; _19 = _6 == (l_14(D) == 0 ? 1 : 0) _5 = l_14(D) != 0 _3 = _5 & _20 & _19; ``` `_5 & _19` simplifies down to `l_14(D) != 0` & _6 == 0` and that with `_6 != 0` gets you false. too. So I am thinking there is a missing jump thread here.
[Bug target/118561] New: [15 Regression] ICE calling __builtin_lasx_xvpickve2gr_w with lasx disabled
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118561
Bug ID: 118561
Summary: [15 Regression] ICE calling
__builtin_lasx_xvpickve2gr_w with lasx disabled
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: xry111 at gcc dot gnu.org
Target Milestone: ---
typedef int v8i32 __attribute__ ((vector_size (32), aligned (32)));
int
__lasx_xvpickve2gr_w (v8i32 _1)
{
return __builtin_lasx_xvpickve2gr_w (_1, 1);
}
With GCC 14.2:
t.c: In function '__lasx_xvpickve2gr_w':
t.c:5:10: error: built-in function '__builtin_lasx_xvpickve2gr_w' is not
enabled
5 | return __builtin_lasx_xvpickve2gr_w (_1, 1);
| ^~~~
t.c:5: confused by earlier errors, bailing out
With GCC 15:
t.c:5:10: error: built-in function '__builtin_lasx_xvpickve2gr_w' is not
enabled
5 | return __builtin_lasx_xvpickve2gr_w (_1, 1);
| ^~~~
during RTL pass: expand
t.c:5:10: internal compiler error: Segmentation fault
0x2b878fb internal_error(char const*, ...)
../../gcc/gcc/diagnostic-global-context.cc:517
0x1758aa2 crash_signal
../../gcc/gcc/toplev.cc:322
0x7f16503b788f ???
/home/xry111/sources/lfs/glibc-2.40/signal/../sysdeps/unix/sysv/linux/x86_64/libc_sigaction.c:0
0x1153597 expand_expr_real_2(separate_ops const*, rtx_def*, machine_mode,
expand_modifier)
../../gcc/gcc/expr.cc:9860
0x1161d36 expand_expr_real_1(tree_node*, rtx_def*, machine_mode,
expand_modifier, rtx_def**, bool)
../../gcc/gcc/expr.cc:12758
0x1151fd7 expand_expr_real(tree_node*, rtx_def*, machine_mode, expand_modifier,
rtx_def**, bool)
../../gcc/gcc/expr.cc:9521
0xf605a0 expand_expr(tree_node*, rtx_def*, machine_mode, expand_modifier)
../../gcc/gcc/expr.h:323
0x11455ed store_expr(tree_node*, rtx_def*, int, bool, bool)
../../gcc/gcc/expr.cc:6654
0x1144841 expand_assignment(tree_node*, tree_node*, bool)
../../gcc/gcc/expr.cc:6492
0xf91dec expand_call_stmt
../../gcc/gcc/cfgexpand.cc:3142
0xf95dea expand_gimple_stmt_1
../../gcc/gcc/cfgexpand.cc:4217
0xf9641b expand_gimple_stmt
../../gcc/gcc/cfgexpand.cc:4364
0xf96533 expand_gimple_tailcall
../../gcc/gcc/cfgexpand.cc:4410
0xf9ee21 expand_gimple_basic_block
../../gcc/gcc/cfgexpand.cc:6401
0xfa1516 execute
../../gcc/gcc/cfgexpand.cc:7176
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See
[Bug rtl-optimization/118562] SEGV in late-combine (rtl_ssa::function_info::remove_use)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118562 --- Comment #2 from Andrew Pinski --- Created attachment 60213 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=60213&action=edit New testcase without an uninitialized variable h in it
[Bug driver/18006] Please replace vfork() with fork()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=18006 --- Comment #6 from Andrew Pinski --- Note GCC will use posix_spawn if it is supported since GCC 14 (r14-5310-g879cf9ff45d940). THis is better than both fork/vfork followed by exec anyways.
[Bug gcov-profile/118553] gcov misses coverage after calling vfork/exec
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118553 Andrew Pinski changed: What|Removed |Added Summary|[12/13/14 regression] gcov |gcov misses coverage after |misses coverage after |calling vfork/exec |calling vfork/exec | Target Milestone|12.5|--- --- Comment #2 from Andrew Pinski --- There is a __gcov_fork but none for vfork There is no wrapper for posix_spawn either.
[Bug gcov-profile/118553] gcov misses coverage after calling vfork/exec
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118553 Andrew Pinski changed: What|Removed |Added Last reconfirmed||2025-01-20 Status|UNCONFIRMED |NEW Known to work|10.5.0, 15.0| Ever confirmed|0 |1 --- Comment #3 from Andrew Pinski --- I highly doubt this is a regression since there never has been a wrapper for vfork nor posix_spawn . The wrapper for fork was added in r0-57864-gd1c38823924506 . Note doing much anything besides exec after vfork is kinda of undefined IIRC.
[Bug target/118558] csmith: another runtime error with march=znver3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118558 --- Comment #3 from Andrew Pinski --- -fno-tree-loop-vectorize fixes it.
[Bug gcov-profile/118553] [12/13/14/15 regression] gcov misses coverage after calling vfork/exec
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118553 Sam James changed: What|Removed |Added Target Milestone|--- |12.5 Summary|gcov misses coverage after |[12/13/14/15 regression] |calling vfork/exec |gcov misses coverage after ||calling vfork/exec CC||hubicka at gcc dot gnu.org
[Bug target/117688] [15 Regression] RISC-V: Wrong code for .SAT_SUB
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117688 --- Comment #7 from Li Pan --- Reproduced and will prepare a fix patch for this.
[Bug tree-optimization/118505] [15 regression] aarch64: 25% regression in TSVC s258 since r15-3436-gb2b20b277988ab
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118505
Andrew Pinski changed:
What|Removed |Added
Status|ASSIGNED|WAITING
--- Comment #9 from Andrew Pinski ---
Looking into the initialization code of TSVC code:
real_t any=0.;
int frac = SET1D_RECIP_IDX;
if (!strcmp(name, "s258")) {
set_1d_array(a, LEN_1D, any,frac);
set_1d_array(b, LEN_1D,zero,unit);
set_1d_array(c, LEN_1D, any,frac);
set_1d_array(d, LEN_1D, any,frac);
set_1d_array(e, LEN_1D,zero,unit);
set_2d_array(aa, any,frac);
}
if (stride == SET1D_RECIP_IDX) {
for (int i = 0; i < length; i++) {
arr[i] = 1. / (real_t) (i+1);
}
This is definitely a bad benchmarking.
because ` if (a[i] > 0.)` is always true so spliting the path here is
cheats and was an accident it was happening in the first place
I am going to try one more thing of changing the benchmark to use both positive
and negative numbers. But I am suspecting this is just a bad benchmark.
That is change:
for (int i = 0; i < length; i++) {
arr[i] = 1. / (real_t) (i+1);
}
to be something like:
for (int i = 0; i < length; i++) {
arr[i] = 1. / (real_t) (i+1) * -(i&1);
}
[Bug tree-optimization/118505] [15 regression] aarch64: 25% regression in TSVC s258 since r15-3436-gb2b20b277988ab
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118505 --- Comment #11 from Dhruv Chawla --- (In reply to Andrew Pinski from comment #10) > Created https://github.com/UoB-HPC/TSVC_2/issues/8 for the issue in the > benchmarking code. Let's see what they say too. I think it is unlikely to get a reply, as the repository was last updated 10 years ago.
[Bug tree-optimization/118505] [15 regression] aarch64: 25% regression in TSVC s258 since r15-3436-gb2b20b277988ab
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118505 Andrew Pinski changed: What|Removed |Added See Also||https://github.com/UoB-HPC/ ||TSVC_2/issues/8 --- Comment #10 from Andrew Pinski --- Created https://github.com/UoB-HPC/TSVC_2/issues/8 for the issue in the benchmarking code. Let's see what they say too.
[Bug tree-optimization/118558] [15 Regression] csmith: another runtime error with march=znver3 since r15-3467-g5df05de3d91775
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118558 Sam James changed: What|Removed |Added Keywords|needs-bisection | CC||rguenth at gcc dot gnu.org Summary|[15 Regression] csmith: |[15 Regression] csmith: |another runtime error with |another runtime error with |march=znver3|march=znver3 since ||r15-3467-g5df05de3d91775 --- Comment #7 from Sam James --- r15-3467-g5df05de3d91775
[Bug target/118560] [15 regression] ICE when building powerpc-unknown-linux-gnu cross-compiler
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118560 --- Comment #2 from Sam James --- On this testcase at -O1 or -O0, it spends ages in RA (still running): 23.09% cc1 cc1 [.] spill_pseudos 20.35% cc1 cc1 [.] lra_create_live_ranges_1 7.91% cc1 cc1 [.] lra_constraints 4.86% cc1 cc1 [.] lra_assign 4.18% cc1 cc1 [.] base_pool_allocator::allocate 3.11% cc1 cc1 [.] bitmap_set_bit 2.84% cc1 cc1 [.] remove_some_program_points_and_update_live_ranges 2.68% cc1 cc1 [.] lra_spill 2.68% cc1 cc1 [.] lra_clear_live_ranges 2.26% cc1 cc1 [.] process_alt_operands 1.51% cc1 cc1 [.] may_trap_p_1 1.42% cc1 cc1 [.] eliminate_regs_in_insn 1.23% cc1 cc1 [.] mark_pseudo_dead 1.20% cc1 cc1 [.] update_lives 1.03% cc1 cc1 [.] resize_reg_info
[Bug tree-optimization/118558] [15 Regression] csmith: another runtime error with march=znver3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118558 Andrew Pinski changed: What|Removed |Added Component|target |tree-optimization Summary|csmith: another runtime |[15 Regression] csmith: |error with march=znver3 |another runtime error with ||march=znver3 Keywords||needs-bisection Target Milestone|--- |15.0
[Bug target/118560] [15 regression] ICE when building powerpc-unknown-linux-gnu cross-compiler
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118560
Sam James changed:
What|Removed |Added
CC||vmakarov at gcc dot gnu.org
--- Comment #1 from Sam James ---
Reduced:
```
struct {
_Decimal32 a;
} b;
void c(int, _Decimal32 d) {
c(1, 1);
b.a = d;
}
```
I also get a bunch of reload attempts exhausted in libgcc.
