[Bug libstdc++/112934] excessive code for std::map::erase(key)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112934 Jonathan Wakely changed: What|Removed |Added URL||https://gcc.gnu.org/piperma ||il/gcc-patches/2024-March/6 ||47574.html --- Comment #1 from Jonathan Wakely --- Patch posted: https://gcc.gnu.org/pipermail/gcc-patches/2024-March/647574.html
[Bug tree-optimization/116812] [15 Regression] ICE on valid code at -O2 with "-fno-tree-dce -fno-tree-dse" on x86_64-linux-gnu: verify_flow_info failed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116812 Tamar Christina changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |tnfchris at gcc dot gnu.org Status|UNCONFIRMED |ASSIGNED Ever confirmed|0 |1 Last reconfirmed||2024-09-22 --- Comment #2 from Tamar Christina --- thanks, testing patch
[Bug target/116691] RISC-V: Unexpected auto-vectorization codegen in simple vectorization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116691 JuzheZhong changed: What|Removed |Added Resolution|--- |FIXED Status|UNCONFIRMED |RESOLVED --- Comment #4 from JuzheZhong --- Fixed on trunk.
[Bug tree-optimization/116578] vectorizer SLP transition issues / dependences
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116578 Bug 116578 depends on bug 116691, which changed state. Bug 116691 Summary: RISC-V: Unexpected auto-vectorization codegen in simple vectorization https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116691 What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED
[Bug libstdc++/111676] Race condition in std::ios::Init
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111676 Jonathan Wakely changed: What|Removed |Added URL||https://gcc.gnu.org/piperma ||il/gcc-patches/2024-Septemb ||er/663550.html Status|UNCONFIRMED |ASSIGNED Ever confirmed|0 |1 Assignee|unassigned at gcc dot gnu.org |redi at gcc dot gnu.org Target Milestone|--- |15.0 Last reconfirmed||2024-09-22 --- Comment #1 from Jonathan Wakely --- Patch posted: https://gcc.gnu.org/pipermail/gcc-patches/2024-September/663550.html
[Bug testsuite/116701] [15 Regression] gfortran.dg/write_check3.f90 suddenly fails for non-fd_truncate targets
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116701
--- Comment #5 from Hans-Peter Nilsson ---
(In reply to Hans-Peter Nilsson from comment #4)
> but if the test fails before the "close"-line is reached
> (consider the multiple "stop"-lines), it wouldn't help.
I think I'll do both: the added close-line has its merits not the least
aesthetically. Also, a
! { dg-final { remote_file target delete "fort.10" } }
(as applicable) needs to go in a lot more test-cases when reasoning as above,
so it serves better as a general clean-up.
(Many other "artefacts" are left in obj/gcc/testsuite/gfortran, but I'll leave
that to Someone Else.)
[Bug target/116799] [14/15 Regression] Miscompiled code on s390x at -O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116799 --- Comment #4 from James McCoy --- (In reply to Andrew Pinski from comment #3) > (In reply to James McCoy from comment #2) > > My initial bisect pointed to that, but I was using the Vim test suite as the > > good/bad check. > > > > I'm rerunning now with just the minimal reproduction to double check the > > results. My re-run bisect (using "./configure --enable-languages=c --disable-bootstrap" this time) is now pointing to r14-2675-gef28aadad6e. > I think you misunderstood, what I am saying is the x86 and s390x has the > same IR at the point at expand and therefor the problem is not with the > commit for PR 111294 itself but it is exposing an issue with something > further along in the compiler. (hence calling it a latent bug). Thanks for the explanation. I appreciate the extra context, as someone that doesn't work on gcc.
[Bug target/116800] std::simd: poor code generation of AVX512 fused multiply-add
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116800 Hongtao Liu changed: What|Removed |Added CC||liuhongt at gcc dot gnu.org --- Comment #2 from Hongtao Liu --- Adding additional option -mprefer-vector-width=512 or adjusting -march=icelake-server to -march=x86-64-v4 helps it
[Bug tree-optimization/115693] 8 std::byte std::array comparison potential missed optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115693
Levy Hsu changed:
What|Removed |Added
CC||admin at levyhsu dot com
--- Comment #7 from Levy Hsu ---
Looks like the problem is solved:
https://godbolt.org/z/Y7bn77bjG
#include
#include
#include
bool compare1(const std::array &p, std::array r)
{
return p == r;
}
bool compare2(const std::array &p, std::array r)
{
return p == r;
}
// same assembly if you use char instead of byte
bool compare3(const std::array &p, std::array r)
{
return std::bit_cast(p) == std::bit_cast(r);
}
compiled with trunk and --std=c++20 -O3 flags produces:
compare1(std::array const&, std::array):
cmp QWORD PTR [rdi], rsi
seteal
ret
compare2(std::array const&, std::array):
cmp QWORD PTR [rdi], rsi
seteal
ret
compare3(std::array const&, std::array):
cmp QWORD PTR [rdi], rsi
seteal
ret
[Bug target/115456] RISC-V: ICE: unrecognizable insn with march=rv64gcv_zvfhmin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115456 Jeffrey A. Law changed: What|Removed |Added CC||law at gcc dot gnu.org Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #8 from Jeffrey A. Law --- Fixed on the trunk and backported to gcc-14 release branch as well.
[Bug testsuite/116701] [15 Regression] gfortran.dg/write_check3.f90 suddenly fails for non-fd_truncate targets
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116701 --- Comment #3 from anlauf at gcc dot gnu.org --- I meant: diff --git a/gcc/testsuite/gfortran.dg/unsigned_22.f90 b/gcc/testsuite/gfortran.dg/unsigned_22.f90 index bc2f810238d..17ebb973cf1 100644 --- a/gcc/testsuite/gfortran.dg/unsigned_22.f90 +++ b/gcc/testsuite/gfortran.dg/unsigned_22.f90 @@ -22,4 +22,5 @@ program memain read (10,*,iostat=iostat,iomsg=iomsg) u if (iostat == 0) error stop 7 if (iomsg /= "Unsigned integer overflow while reading item 1 of list input") error stop 8 + close(10, status="delete") end program memain
[Bug tree-optimization/116812] New: ICE on valid code at -O2 with "-fno-tree-dce -fno-tree-dse" on x86_64-linux-gnu: verify_flow_info failed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116812
Bug ID: 116812
Summary: ICE on valid code at -O2 with "-fno-tree-dce
-fno-tree-dse" on x86_64-linux-gnu: verify_flow_info
failed
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: ---
[517] % 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.0/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.0 20240922 (experimental) (GCC)
[518] %
[518] % gcctk -O2 small.c; ./a.out
[519] %
[519] % gcctk -O2 -fno-tree-dce -fno-tree-dse small.c
small.c: In function ‘main’:
small.c:3:5: error: control flow in the middle of basic block 9
3 | int main() {
| ^~~~
small.c:3:5: error: true/false edge after a non-GIMPLE_COND in bb 9
small.c:3:5: error: true/false edge after a non-GIMPLE_COND in bb 9
during GIMPLE pass: slp
small.c:3:5: internal compiler error: verify_flow_info failed
0x25b5f05 internal_error(char const*, ...)
../../gcc-trunk/gcc/diagnostic-global-context.cc:517
0xc2f7bf verify_flow_info()
../../gcc-trunk/gcc/cfghooks.cc:287
0x1074b97 execute_function_todo
../../gcc-trunk/gcc/passes.cc:2113
0x107550e execute_todo
../../gcc-trunk/gcc/passes.cc:2155
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.
[520] %
[520] % cat small.c
int a, b, c, d, e, f[2], g, h;
int k(int j) { return 2 >> a ? 2 >> a : a; }
int main() {
int i;
for (; g; g = k(d = 0))
;
if (a)
b && h;
for (e = 0; e < 2; e++)
c = d & 1 ? d : 0;
for (i = 0; i < 2; i++)
f[i] = 0;
return 0;
}
[Bug tree-optimization/116812] [15 Regression] ICE on valid code at -O2 with "-fno-tree-dce -fno-tree-dse" on x86_64-linux-gnu: verify_flow_info failed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116812 Andrew Pinski changed: What|Removed |Added Target Milestone|--- |15.0 Keywords||ice-on-valid-code Summary|ICE on valid code at -O2|[15 Regression] ICE on |with "-fno-tree-dce |valid code at -O2 with |-fno-tree-dse" on |"-fno-tree-dce |x86_64-linux-gnu: |-fno-tree-dse" on |verify_flow_info failed |x86_64-linux-gnu: ||verify_flow_info failed CC||tnfchris at gcc dot gnu.org --- Comment #1 from Andrew Pinski --- This might be easier to debug than the ICE from D code.
[Bug testsuite/116701] [15 Regression] gfortran.dg/write_check3.f90 suddenly fails for non-fd_truncate targets
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116701 --- Comment #4 from Hans-Peter Nilsson --- (In reply to anlauf from comment #2) > Can you test if adding a line > > close(10, status="delete") > > before the > > end program memain > > fixes the issue? If so, such a fix is pre-approved; you can also ask Thomas. I considered that, and I'm pretty sure that'll help for the case at hand (the unsigned_22 test passes for the first run but fails subsequent runs for the same reason), but if the test fails before the "close"-line is reached (consider the multiple "stop"-lines), it wouldn't help.
[Bug target/111926] RISC-V: Use vsetvl insn replace csrr vlenb insn
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111926 Jeffrey A. Law changed: What|Removed |Added CC||law at gcc dot gnu.org --- Comment #4 from Jeffrey A. Law --- The thing to keep in mind here is that a reasonable uarch should provide efficient access to vlenb. It's an architectural constant. Using vsetvl to get this information also disturbs vl and vtype. So while this transformation may look like an improvement in isolation, it's probably not in real code. So if anyone ever implements this, it definitely needs to be a uarch triggered tuning option.
[Bug middle-end/111621] [RISC-V] Bad register allocation in vadd.vi may cause operational error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111621 Jeffrey A. Law changed: What|Removed |Added CC||law at gcc dot gnu.org Resolution|--- |INVALID Status|UNCONFIRMED |RESOLVED --- Comment #4 from Jeffrey A. Law --- Per c#3.
[Bug testsuite/116701] [15 Regression] gfortran.dg/write_check3.f90 suddenly fails for non-fd_truncate targets
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116701 --- Comment #6 from GCC Commits --- The master branch has been updated by Hans-Peter Nilsson : https://gcc.gnu.org/g:3f37c6f47cd50c99350e93ef0dab31f7dc6d213a commit r15-3782-g3f37c6f47cd50c99350e93ef0dab31f7dc6d213a Author: Hans-Peter Nilsson Date: Mon Sep 23 03:29:02 2024 +0200 testsuite/gfortran.dg/unsigned_22.f90: Add missing close with delete, PR116701 Without this patch, gfortran.dg/unsigned_22.f90 fails for non-effective-target fd_truncate targets, i.e. targets that don't support chsize or ftruncate. See also libgfortran/io/unix.c:raw_truncate. It passes on the first run, but leaves behind a file "fort.10" which is then picked up by subsequent runs, but since that file is to be rewritten, the libgfortran machinery tries to truncate it, which fails. The file always being left behind, is primarily because the test-case lacks a deleting close-statement, apparently accidentally. Incidentally, this "fort.10" artefact is also picked up by gfortran.dg/write_check3.f90 causing that test to fail too, observable as a regression for non-fd_truncate targets since the unsigned_22.f90 introduction. Also, when running e.g. the whole of gfortran.dg/dg.exp, the "fort.10" is later deleted by gfortran.dg/write_direct_eor.f90 (which regardlessly passes), erasing the clue of the cause of the write_check3 failure. Also, running just dg.exp=write_check3.f90 or manually repeating the commands in gfortran.log showed no error. N.B.: this close-statement will not help if unsigned_22 for some reason fails, executing one of the "stop" statements, but that's also the case for many other tests. PR testsuite/116701 * gfortran.dg/unsigned_22.f90: Add missing close with delete.
[Bug tree-optimization/116742] -Wuninitialized failed to issue uninitialized variable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116742 --- Comment #3 from xiaohuba2021 --- So is there any workaround or patch?
[Bug testsuite/116701] [15 Regression] gfortran.dg/write_check3.f90 suddenly fails for non-fd_truncate targets
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116701 Hans-Peter Nilsson changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #7 from Hans-Peter Nilsson --- I'm closing this but hope to soon submit follow-up patch adding that dg-final directive, and then I'll tag that with this PR.
[Bug target/55212] [SH] Switch to LRA
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212 --- Comment #308 from Oleg Endo --- (In reply to Kazumoto Kojima from comment #305) > (In reply to Oleg Endo from comment #304) > > I think this is a bit clearer, thanks! One more question > > > > (define_insn "block_lump_real" > > [(set (mem:BLK (match_operand:SI 2 "sfunc_arg0_reg" "=r,r")) > >(mem:BLK (match_operand:SI 3 "sfunc_arg1_reg" "=r,r"))) > >(use (match_operand:SI 0 "arith_reg_operand" "r,r")) > >(use (match_operand 1 "" "Z,Ccl")) > >(use (match_operand:SI 4 "sfunc_arg2_reg" "=r,r")) > > > >(use (reg:SI R4_REG))<< > >(use (reg:SI R5_REG))<< > >(use (reg:SI R6_REG))<< > > > >(clobber (match_dup 2)) > >(clobber (match_dup 3)) > >(clobber (match_dup 4)) > >(clobber (reg:SI PR_REG)) > > > > Is it possible to do '(use (match_dup 2)' and so on instead of having the > > hard regs in there? > > It isn't. When replacing hard reg with match_dup, it compiles our tiny > sfunc test to: > > foo: > mov.l r14,@-r15 ! 32[c=4 l=2] movsi_ie/8 > mov r4,r5 ! 23[c=4 l=2] movsi_ie/1 > sts.l pr,@-r15! 33[c=4 l=2] movsi_ie/10 > mov.w .L6,r1 ! 34[c=10 l=2] *movhi/0 > mov #0,r7 ! 16[c=4 l=2] movsi_ie/2 > mov.l .L4,r6 ! 29[c=10 l=2] movsi_ie/0 > sub r1,r15 ! 35[c=4 l=2] *subsi3_internal > mov r15,r14 ! 30[c=4 l=2] movsi_ie/1 > add #4,r14 ! 31[c=4 l=2] *addsi3_compact_lra/0 > jsr @r6 ! 12[c=1 l=2] block_lump_real_i4/0 > mov r14,r4 ! 9 [c=4 l=2] movsi_ie/1 > ... > .L6: > .short 260 > > which wrongly assigns r6 to the function address, for example. Thanks for confirming it. In this case, wouldn't it be better to explicitly mention the hard reg numbers everywhere, where they are involved? Otherwise the definitions are bara-bara all over the place. For example: (define_insn "block_lump_real" [(set (mem:BLK (match_operand:SI 2 "hard_reg_r4" "=r,r")) (mem:BLK (match_operand:SI 3 "hard_reg_r5" "=r,r"))) (use (match_operand:SI 0 "arith_reg_operand" "r,r")) (use (match_operand 1 "" "Z,Ccl")) (use (match_operand:SI 4 "hard_reg_r6" "=r,r")) (use (reg:SI R4_REG)) (use (reg:SI R5_REG)) (use (reg:SI R6_REG)) (clobber (match_dup 2)) (clobber (match_dup 3)) (clobber (match_dup 4)) (clobber (reg:SI PR_REG)) But actually, why are the register constraints "=r,r"? The insn only takes inputs, but those are declared as outputs. That looks wrong to me. Perhaps that's why the need for the seemingly superflous (use (reg:SI ... )?
[Bug target/113933] Switch pa to LRA
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113933 --- Comment #8 from John David Anglin --- Looks like there is a typo in the indirect_goto constraints and that causes the insn which loads "lab" to be deleted.
[Bug testsuite/116701] [15 Regression] gfortran.dg/write_check3.f90 suddenly fails for non-fd_truncate targets
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116701 --- Comment #2 from anlauf at gcc dot gnu.org --- (In reply to Hans-Peter Nilsson from comment #1) > The cause is that the unsigned_22 test (added in the named commit) leaves an > output file "fort.10", which is picked up by write_check3 which then calls > libgfortran raw_truncate. I guess the gfortran "unit-machinery" wants to > clear that file if it exists. > > Some option is needed to make the "fort.10" file name unique or something to > that effect in a way that it isn't picked up by write_check3. A dg- cleanup > function might do, perhaps one exists? A "git grep -w fort" in > testsuite/lib catches nothing though. Well observed. Can you test if adding a line close(10, status="delete") before the end program memain fixes the issue? If so, such a fix is pre-approved; you can also ask Thomas.
[Bug target/116592] illegal operands th.vsetvli zero,0,e32,m8 with -O2 -O3 when compiling for risc-v xtheadvector
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116592 Jeffrey A. Law changed: What|Removed |Added Resolution|--- |FIXED CC||law at gcc dot gnu.org Status|UNCONFIRMED |RESOLVED --- Comment #7 from Jeffrey A. Law --- Fixed on the trunk.
[Bug target/55212] [SH] Switch to LRA
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212 --- Comment #307 from John Paul Adrian Glaubitz --- (In reply to John Paul Adrian Glaubitz from comment #306) > (In reply to John Paul Adrian Glaubitz from comment #301) > > I can confirm that I can successfully perform a full native bootstrap with > > the following languages enabled: > > > > - c,c++,fortran,objc,obj-c++,m2 > > > > There were no segfaults or comparison failures either. > > > > I can also confirm that this branch fixes the problems reported in comment > > #271, comment #273 and comment #298. > > > > Last will be verifying that Go and Ada still work. > > > > This is a huge step forward so far. Congratulations! > > Ada and Go work fine, too. Let me test lto and jit. LTO and JIT build without issues, too.
[Bug target/116594] [meta-bug] xtheadvector brokeness
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116594 Bug 116594 depends on bug 116592, which changed state. Bug 116592 Summary: illegal operands th.vsetvli zero,0,e32,m8 with -O2 -O3 when compiling for risc-v xtheadvector https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116592 What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED
[Bug testsuite/116701] [15 Regression] gfortran.dg/write_check3.f90 suddenly fails for non-fd_truncate targets
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116701 Hans-Peter Nilsson changed: What|Removed |Added Component|target |testsuite --- Comment #1 from Hans-Peter Nilsson --- This is a testism. You'll only see this test failing when: - Testing for a non-fd_truncate target (usually a simulator that can't chsize or ftruncate, see the effective_target). - Also testing unsigned_22 in the same run. - Testing "serially" or "unlucky" with the parallel test run such that unsigned_22 has run before write_check3. The cause is that the unsigned_22 test (added in the named commit) leaves an output file "fort.10", which is picked up by write_check3 which then calls libgfortran raw_truncate. I guess the gfortran "unit-machinery" wants to clear that file if it exists. Some option is needed to make the "fort.10" file name unique or something to that effect in a way that it isn't picked up by write_check3. A dg- cleanup function might do, perhaps one exists? A "git grep -w fort" in testsuite/lib catches nothing though.
[Bug target/111926] RISC-V: Use vsetvl insn replace csrr vlenb insn
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111926 Andrew Waterman changed: What|Removed |Added CC||andrew at sifive dot com --- Comment #5 from Andrew Waterman --- FWIW, it _is_ an improvement on SiFive's in-order vector units--but only under the assumption that the values of vtype and vl were don't-cares, so that we won't end up needing to execute yet another vsetvli to restore them to their previous value. Jeff's of course right that this doesn't hold for all uarches, especially those that need to allocate new physical registers for vtype/vl.
[Bug ipa/116813] New: std::vector index check not optimized out with -O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116813
Bug ID: 116813
Summary: std::vector index check not optimized out with
-O2
Product: gcc
Version: 13.3.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: ipa
Assignee: unassigned at gcc dot gnu.org
Reporter: sjames at gcc dot gnu.org
Target Milestone: ---
At -O2 on trunk, we emit an unnecessary comparison for the bool indexing:
```
#include
int foo(int index) {
if (index < 0 || index > 4) {
return false;
}
std::vector p = {0, 1, 2, 3, 4, 5};
std::vector q = {true, false, true};
__builtin_printf("%d\n", q[0] == true);
return p[index];
}
```
At -O3, we don't. Note that the std::vector -D_GLIBCXX_ASSERTIONS wiring
is new in trunk. Clang always does it AFAICT?
[Bug target/55212] [SH] Switch to LRA
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212 --- Comment #309 from Kazumoto Kojima --- (In reply to Oleg Endo from comment #308) > Thanks for confirming it. In this case, wouldn't it be better to explicitly > mention the hard reg numbers everywhere, where they are involved? Otherwise > the definitions are bara-bara all over the place. For example: > > (define_insn "block_lump_real" > [(set (mem:BLK (match_operand:SI 2 "hard_reg_r4" "=r,r")) Sure. hard_reg_r[456] sounds better. > But actually, why are the register constraints "=r,r"? The insn only takes > inputs, but those are declared as outputs. That looks wrong to me. Perhaps > that's why the need for the seemingly superflous (use (reg:SI ... )? If "=" is removed, it doesn't work, unfortunately. It compiles our tiny case to foo: mov.l r14,@-r15 ! 32[c=4 l=2] movsi_ie/8 mov r4,r5 ! 23[c=4 l=2] movsi_ie/1 sts.l pr,@-r15! 33[c=4 l=2] movsi_ie/10 mov.w .L6,r1 ! 34[c=10 l=2] *movhi/0 mov #31,r6 ! 11[c=4 l=2] movsi_ie/2 mov.l .L4,r14 ! 29[c=10 l=2] movsi_ie/0 mov #0,r7 ! 16[c=4 l=2] movsi_ie/2 sub r1,r15 ! 35[c=4 l=2] *subsi3_internal mov r15,r4 ! 30[c=4 l=2] movsi_ie/1 jsr @r14! 12[c=1 l=2] block_lump_real_i4/0 add #4,r4 ! 31[c=4 l=2] *addsi3_compact_lra/0 mov.l .L5,r1 ! 27[c=10 l=2] movsi_ie/0 mov #0,r6 ! 17[c=4 l=2] movsi_ie/2 mov.l r4,@r15 ! 14[c=4 l=2] movsi_ie/8 which uses r4 as if it isn't clobbered. As mentioned in c#276, I assume that LRA doesn't handle the clobber reg pattern if that reg is recognized as the input reg, unless it's call_insn. It would have been nice if the pattern in c#276 had worked.
[Bug target/116814] New: [15 Regression] ICE on libjack2-1.9.22: in expand_fn_using_insn, at internal-fn.cc:263
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116814
Bug ID: 116814
Summary: [15 Regression] ICE on libjack2-1.9.22: in
expand_fn_using_insn, at internal-fn.cc:263
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: slyfox at gcc dot gnu.org
Target Milestone: ---
Initially observed ICE on libjack2-1.9.22 on gcc-master at
r15-3784-g4fc92480675bd0.
cvise reduced it down to the following:
$ cat JackMidiAsyncWaitQueue.cpp.cpp
unsigned long long GetTimeFromFrames(int);
unsigned long long GetMicroSeconds();
void DequeueEvent(unsigned frame) {
long long frame_time = GetTimeFromFrames(frame);
unsigned long long current_time = GetMicroSeconds();
DequeueEvent(frame_time < current_time ? 0 : frame_time - current_time);
}
gcc/xg++ -Bgcc -O2 -fPIC -c JackMidiAsyncWaitQueue.cpp.cpp -m32
during RTL pass: expand
JackMidiAsyncWaitQueue.cpp.cpp: In function 'void DequeueEvent(unsigned int)':
JackMidiAsyncWaitQueue.cpp.cpp:3:6: internal compiler error: in
expand_fn_using_insn, at internal-fn.cc:263
3 | void DequeueEvent(unsigned frame) {
| ^~~~
0x27b580d diagnostic_context::diagnostic_impl(rich_location*,
diagnostic_metadata const*, diagnostic_option_id, char const*, __va_list_tag
(*) [1], diagnostic_t)
???:0
0x27c4a3f internal_error(char const*, ...)
???:0
0x27b3994 fancy_abort(char const*, int, char const*)
???:0
0xf25ae5 expand_fn_using_insn(gcall*, insn_code, unsigned int, unsigned int)
???:0
0xf2a124 expand_direct_optab_fn(internal_fn, gcall*, optab_tag, unsigned int)
???:0
0xf2c87c expand_SAT_SUB(internal_fn, gcall*)
???:0
0xf3079d expand_internal_call(internal_fn, gcall*)
???:0
0xf307b7 expand_internal_call(gcall*)
???:0
0xc8f160 expand_gimple_stmt(gimple*)
???:0
0xc95099 expand_gimple_basic_block(basic_block_def*, bool)
???:0
0xc971b2 (anonymous namespace)::pass_expand::execute(function*)
???:0
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See
[Bug ipa/116813] std::vector index check not optimized out with -O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116813 --- Comment #1 from Sam James --- https://godbolt.org/z/4jMTb4fqv
[Bug target/116237] gcc does not accept -weak_framework without -Wl on macOS
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116237 --- Comment #4 from GCC Commits --- The releases/gcc-14 branch has been updated by Iain D Sandoe : https://gcc.gnu.org/g:b292b6b9e104c2418b4b19c8495fef9effe9369f commit r14-10702-gb292b6b9e104c2418b4b19c8495fef9effe9369f Author: Iain Sandoe Date: Mon Aug 5 13:19:28 2024 +0100 Darwin: Recognise -weak_framework in the driver [PR116237]. XCode compilers recognise the weak_framework linker option in the driver and forward it. This patch makes GCC adopt the same behaviour. PR target/116237 gcc/ChangeLog: * config/darwin.h (SUBTARGET_DRIVER_SELF_SPECS): Add a spec for weak_framework. * config/darwin.opt: Handle weak_framework driver option. Signed-off-by: Iain Sandoe (cherry picked from commit 4cec7bc79db52bae159c3c60a415e2aea48051d8)
[Bug tree-optimization/116808] Valgrind reports mismatched new/delete in value-range.h
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116808 --- Comment #2 from Andrew Pinski --- I think there is a dup around.
[Bug tree-optimization/116808] Valgrind reports mismatched new/delete in value-range.h
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116808 --- Comment #3 from Andrew Pinski --- Yes this is a dup of 109920. I wonder if that should be backported or this closed as won't fix since it is semi harmless.
[Bug tree-optimization/116808] Valgrind reports mismatched new/delete in value-range.h
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116808 Sam James changed: What|Removed |Added CC||aldyh at gcc dot gnu.org --- Comment #4 from Sam James --- It's no bother for me if we call it a dupe and leave it. I just noticed it by chance. aldy?
[Bug target/116809] Failure to build GCC on macOS 15 / Xcode 16 for Intel
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116809 Iain Sandoe changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |iains at gcc dot gnu.org --- Comment #2 from Iain Sandoe --- Created attachment 59176 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=59176&action=edit Patch under test Please could folks with access to macOS 15 on x86_64 - test this (I will test on the older boxes where it is more likely to be a problem,
[Bug target/116809] Failure to build GCC on macOS 15 / Xcode 16 for Intel
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116809 --- Comment #6 from Chris Jones --- and yes, we are also using your patches for Darwin at https://github.com/iains/gcc-14-branch
[Bug target/116809] Failure to build GCC on macOS 15 / Xcode 16 for Intel
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116809 --- Comment #7 from Iain Sandoe --- Created attachment 59177 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=59177&action=edit patch for GCC-14 (***untested) this is against the current darwin gcc-14 branch - it is completely untested.
[Bug target/116809] Failure to build GCC on macOS 15 / Xcode 16 for Intel
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116809 --- Comment #8 from Francois-Xavier Coudert --- (In reply to Iain Sandoe from comment #2) > Created attachment 59176 [details] > Patch under test Does not apply to upstream GCC. I think it needs "libgcc: limit to 11 from 11" https://github.com/iains/gcc-darwin-arm64/commit/1fa7e9c16c259be8d1e2110df5d317ca6ef69635 I've started a test of trunk with the two patches applied, on x86_64-apple-darwin24, and will report here. I'd argue that it makes a compelling case to push "libgcc: limit to 11 from 11" to trunk.
[Bug target/116809] Failure to build GCC on macOS 15 / Xcode 16 for Intel
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116809 --- Comment #9 from Iain Sandoe --- (In reply to Francois-Xavier Coudert from comment #8) > (In reply to Iain Sandoe from comment #2) > > Created attachment 59176 [details] > > Patch under test > > Does not apply to upstream GCC. I think it needs "libgcc: limit to 11 from > 11" > https://github.com/iains/gcc-darwin-arm64/commit/ > 1fa7e9c16c259be8d1e2110df5d317ca6ef69635 > > I've started a test of trunk with the two patches applied, on > x86_64-apple-darwin24, and will report here. I'd argue that it makes a > compelling case to push "libgcc: limit to 11 from 11" to trunk. yeah - that is pretty well-backed now .. let me test it individually. I'm limited at the moment because I'm already doing the weekly rebase build/test + limited hardware ( and even if I had more hardware limited enthusiasm for paying a higher electricity bill ;) )
[Bug libstdc++/116755] format and print functions prepend extra minus sign for min value of chrono duration type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116755 --- Comment #14 from GCC Commits --- The master branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:482e651f5750e4648ade90e32ed45b094538e7f8 commit r15-3774-g482e651f5750e4648ade90e32ed45b094538e7f8 Author: Jonathan Wakely Date: Wed Sep 18 17:20:29 2024 +0100 libstdc++: Fix formatting of most negative chrono::duration [PR116755] When formatting chrono::duration::min() we were causing undefined behaviour by trying to form the negative of the most negative value. If we convert negative durations with integer rep to the corresponding unsigned integer rep then we can safely represent all values. libstdc++-v3/ChangeLog: PR libstdc++/116755 * include/bits/chrono_io.h (formatter>::format): Cast negative integral durations to unsigned rep. * testsuite/20_util/duration/io.cc: Test the most negative integer durations.
[Bug libstdc++/116754] libstdc++ std::ranges::copy performance issue
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116754 --- Comment #2 from GCC Commits --- The master branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:83c6fe130a00c6c28cfffcc787a0a719966adfaf commit r15-3775-g83c6fe130a00c6c28cfffcc787a0a719966adfaf Author: Jonathan Wakely Date: Wed Sep 18 17:47:49 2024 +0100 libstdc++: Fix condition for ranges::copy to use memmove [PR116754] libstdc++-v3/ChangeLog: PR libstdc++/116754 * include/bits/ranges_algobase.h (__copy_or_move): Fix order of arguments to __memcpyable.
[Bug libstdc++/116802] Symbol `is` (non-standard) is user inside the library.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116802 --- Comment #11 from Jonathan Wakely --- The C++ standard has an index of names defined in the library (which includes "is") and can be used to check which names are reserved for use by the library.
[Bug target/116693] [RISC-V] @tlsdesc generates duplicate assembler labels
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116693 Jeffrey A. Law changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #4 from Jeffrey A. Law --- Fixed on the trunk.
[Bug target/113933] Switch pa to LRA
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113933 John David Anglin changed: What|Removed |Added Attachment #59163|0 |1 is obsolete|| --- Comment #7 from John David Anglin --- Created attachment 59178 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=59178&action=edit Patch This patch gets us to bootstrap on hppa-unknown-linux-gnu and hppa64-hp-hpux11.11. For the most part, I fixed the LRA crashes by adjusting pa_secondary_reload to prevent pa_emit_move_sequence from being called in situations where it just emitted an unmodified set. Without reg_equiv_mem, the operands were not being adjusted and the reload failed. I was not able to get SECONDARY_MEMORY_NEEDED to work properly on hppa64 target with lra. It never did copy via memory between general and floating-point registers. We ended up with an unrecognized insn if I allowed reloading pseudos during LRA. If I didn't allow them, we got a secondary reload overflow. So, I modified 64-bit SImode, SFmode, DImode and DFmode to do copy using the SP-40 slot in the frame marker. We have a bunch of regressions. For example, FAIL: gcc.dg/enum-alias-3.c (test for excess errors) FAIL: gcc.dg/non-local-goto-1.c execution test FAIL: gcc.dg/non-local-goto-2.c execution test FAIL: gcc.dg/pr49994-1.c (internal compiler error: in add_stores, at var-tracking.cc:5966) FAIL: gcc.dg/pr49994-1.c (test for excess errors) Don't know if the changes to pa_secondary_reload will work with legacy reload.
[Bug target/116237] gcc does not accept -weak_framework without -Wl on macOS
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116237 Iain Sandoe changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2024-09-22 Ever confirmed|0 |1 --- Comment #3 from Iain Sandoe --- fixed on trunk, leaving open for back ports
[Bug testsuite/112297] Failure of pr100936.c on x86_64-apple-darwin21
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112297 --- Comment #6 from Eric Gallager --- (In reply to GCC Commits from comment #5) > The releases/gcc-12 branch has been updated by Iain D Sandoe > : > > https://gcc.gnu.org/g:0eb6f8874047f7e7f13027aaac14d3de276c5e69 > > commit r12-10370-g0eb6f8874047f7e7f13027aaac14d3de276c5e69 > Author: Francois-Xavier Coudert > Date: Mon Dec 11 09:26:23 2023 +0100 > > Testsuite: restrict test to nonpic targets > > The test is currently failing on x86_64-apple-darwin. > > gcc/testsuite/ChangeLog: > > PR testsuite/112297 > * gcc.target/i386/pr100936.c: Require nonpic target. > > (cherry picked from commit 02f562484c17522d79a482ac702a5fa3c2dfdd10) This is about as far back as it can be backported, correct? OK to close now?
[Bug testsuite/112297] Failure of pr100936.c on x86_64-apple-darwin21
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112297 Francois-Xavier Coudert changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED Target Milestone|--- |12.5 --- Comment #7 from Francois-Xavier Coudert --- Correct!
[Bug target/116809] Failure to build GCC on macOS 15 / Xcode 16 for Intel
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116809 Francois-Xavier Coudert changed: What|Removed |Added Ever confirmed|0 |1 Last reconfirmed||2024-09-22 Target||x86_64-apple-darwin24 Host||x86_64-apple-darwin24 Status|UNCONFIRMED |NEW Build||x86_64-apple-darwin24
[Bug target/116809] Failure to build GCC on macOS 15 / Xcode 16 for Intel
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116809 --- Comment #1 from Iain Sandoe --- yeah.. the compiler will not (for some several revisions) actually refer to libgcc_s.1.dylib - it is only there to support existing built exes from older compilers. Probably dropping it after macOS 14 is the best option - I'll look at amending the libgcc config to fix this. I don't have a macOS 15 install yet - running out of suitable hardware that is not already busy
[Bug target/116809] Failure to build GCC on macOS 15 / Xcode 16 for Intel
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116809 Chris Jones changed: What|Removed |Added CC||jonesc at hep dot phy.cam.ac.uk --- Comment #3 from Chris Jones --- CN you prepare a version of the patch for the current gcc14 release ?
[Bug c/116810] New: tree-vect-slp.cc:3721:18: runtime error: insufficient space for an object of type 'bool'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116810 Bug ID: 116810 Summary: tree-vect-slp.cc:3721:18: runtime error: insufficient space for an object of type 'bool' Product: gcc Version: 15.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: dcb314 at hotmail dot com Target Milestone: --- I just tried a bootstrap build with ASAN & UBSAN switched on. I got: working $ grep "runtime error:" mk.out | head ../../trunk/gcc/tree-vect-slp.cc:3721:18: runtime error: store to address 0x7ffeccf7bec1 with insufficient space for an object of type 'bool' Source code is matches[1] = false; git blame says: 9aaedfc4146c gcc/tree-vect-slp.cc (Richard Biener 2024-07-05 10:35:08 +0200 3721) matches[1] = false; Configure script is: ../trunk/configure --prefix=$HOME/gcc/results.$DATE \ --disable-multilib \ --disable-werror \ --with-pkgversion=$HASH \ --with-build-config=bootstrap-asan \ --with-build-config=bootstrap-ubsan \ --enable-checking=yes \ --enable-languages=c,c++,fortran sed 's;-O2;-O2 -march=znver3 -fno-var-tracking-assignments;' < Makefile > Makefile.tmp diff Makefile Makefile.tmp mv Makefile.tmp Makefile Further detail: working $ grep -E "^Config|runtime error:" mk.out ... Configuring stage 2 in x86_64-pc-linux-gnu/libgcc ../../trunk/gcc/tree-vect-slp.cc:3721:18: runtime error: store to address 0x7ffeccf7bec1 with insufficient space for an object of type 'bool' ../../trunk/gcc/tree-vect-slp.cc:3721:18: runtime error: store to address 0x7e8ad741 with insufficient space for an object of type 'bool' ../../trunk/gcc/tree-vect-slp.cc:3721:18: runtime error: store to address 0x7ffd80152aa1 with insufficient space for an object of type 'bool' ../../trunk/gcc/tree-vect-slp.cc:3721:18: runtime error: store to address 0x7ffc3b71e521 with insufficient space for an object of type 'bool' ../../trunk/gcc/tree-vect-slp.cc:3721:18: runtime error: store to address 0x7ffc82548ee1 with insufficient space for an object of type 'bool' ../../trunk/gcc/tree-vect-slp.cc:3721:18: runtime error: store to address 0x7ffc67ddf881 with insufficient space for an object of type 'bool' ../../trunk/gcc/tree-vect-slp.cc:3721:18: runtime error: store to address 0x7ffd845cd581 with insufficient space for an object of type 'bool' Configuring stage 2 in x86_64-pc-linux-gnu/libgomp Configuring stage 2 in x86_64-pc-linux-gnu/libstdc++-v3 ../../trunk/gcc/tree-vect-slp.cc:3721:18: runtime error: store to address 0x7ffe25bff581 with insufficient space for an object of type 'bool' ../../trunk/gcc/tree-vect-slp.cc:3721:18: runtime error: store to address 0x7ffe599e5401 with insufficient space for an object of type 'bool' ../../trunk/gcc/tree-vect-slp.cc:3721:18: runtime error: store to address 0x7fff277997c1 with insufficient space for an object of type 'bool'
[Bug c/116810] tree-vect-slp.cc:3721:18: runtime error: insufficient space for an object of type 'bool'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116810 Sam James changed: What|Removed |Added CC||sjames at gcc dot gnu.org --- Comment #1 from Sam James --- (In reply to David Binderman from comment #0) > I just tried a bootstrap build with ASAN & UBSAN switched on. > > I got: > > working $ grep "runtime error:" mk.out | head > ../../trunk/gcc/tree-vect-slp.cc:3721:18: runtime error: store to address > 0x7ffeccf7bec1 with insufficient space for an object of type 'bool' > You might get some nicer output with: export UBSAN_OPTIONS=print_stacktrace=1:halt_on_error=0 (maybe changing 0 to 1 for halting depending on what you want) > Source code is > > matches[1] = false; > > git blame says: > > 9aaedfc4146c gcc/tree-vect-slp.cc (Richard Biener 2024-07-05 10:35:08 > +0200 3721) matches[1] = false; > > Configure script is: > > ../trunk/configure --prefix=$HOME/gcc/results.$DATE \ > --disable-multilib \ > --disable-werror \ > --with-pkgversion=$HASH \ > --with-build-config=bootstrap-asan \ > --with-build-config=bootstrap-ubsan \ Are you sure this works? autoconf usually says the last one wins. You may need --with-build-config="bootstrap-asan bootstrap-ubsan" instead.
[Bug c/116811] New: internal compiler error: verify_ssa failed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116811
Bug ID: 116811
Summary: internal compiler error: verify_ssa failed
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: yunboni at smail dot nju.edu.cn
Target Milestone: ---
Created attachment 59180
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=59180&action=edit
The preprocessed file when using -O3
When I compiled this code with -O2/O3 flag, it crashed:
```c
#include
int a, i;
uint8_t **j, **k;
long b(long unsigned c, int d) {
if (c == 0)
return 0;
long unsigned e = (c + d - 1) / d;
a = 0;
for (; a < e; a++)
;
return 0;
}
void f(int, int g, int h) { b(g, h); }
int32_t *l();
static uint64_t m(int32_t *, uint8_t, int32_t *);
int32_t *n();
static int16_t o() { int32_t *p = l(m(n(), **j, 0)); p = p; return 0;}
uint64_t m(int32_t *, uint8_t q, int32_t *) {
**k = i || q;
f(0, q - 1, q + 1);
return 0;
}
int main() { o(); }
```
The backtrace is:
0x24e1215 diagnostic_context::diagnostic_impl(rich_location*,
diagnostic_metadata const*, diagnostic_option_id, char const*, __va_list_tag
(*) [1], diagnostic_t)
???:0
0x24f48f5 internal_error(char const*, ...)
???:0
0x1348b6d verify_ssa(bool, bool)
???:0
Note: When I add type conversion on line 9 like: for (; a < (int)e; a++), it
didn't crash.
[Bug c/116811] [15 regression] internal compiler error: verify_ssa failed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116811
Sam James changed:
What|Removed |Added
Resolution|--- |DUPLICATE
Summary|internal compiler error:|[15 regression] internal
|verify_ssa failed |compiler error: verify_ssa
||failed
Keywords||ice-on-valid-code
CC||sjames at gcc dot gnu.org
Status|UNCONFIRMED |RESOLVED
--- Comment #1 from Sam James ---
```
/tmp/z.c: In function ‘main’:
/tmp/z.c:24:5: error: definition in block 6 does not dominate use in block 7
24 | int main() { o(); }
| ^~~~
for SSA_NAME: _18 in statement:
_11 = .SAT_ADD (_18, _35);
during GIMPLE pass: widening_mul
/tmp/z.c:24:5: internal compiler error: verify_ssa failed
0x59ad3daf998b internal_error(char const*, ...)
/usr/src/debug/sys-devel/gcc-15.0./gcc-15.0./gcc/diagnostic-global-context.cc:517
0x59ad3c634b44 verify_ssa(bool, bool) [clone .constprop.0]
/usr/src/debug/sys-devel/gcc-15.0./gcc-15.0./gcc/tree-ssa.cc:1203
0x59ad3dcd7b76 execute_function_todo
/usr/src/debug/sys-devel/gcc-15.0./gcc-15.0./gcc/passes.cc:2108
0x59ad3dcd7b76 do_per_function
/usr/src/debug/sys-devel/gcc-15.0./gcc-15.0./gcc/passes.cc:1700
0x59ad3dcd7b76 execute_todo
/usr/src/debug/sys-devel/gcc-15.0./gcc-15.0./gcc/passes.cc:2155
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See
[Bug tree-optimization/116795] [15 regression] ICE on valid code at -O3 on x86_64-linux-gnu: verify_ssa failed since r15-3708-g2545a1abb77bd6
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116795 Sam James changed: What|Removed |Added CC||yunboni at smail dot nju.edu.cn --- Comment #3 from Sam James --- *** Bug 116811 has been marked as a duplicate of this bug. ***
[Bug target/55212] [SH] Switch to LRA
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212 --- Comment #306 from John Paul Adrian Glaubitz --- (In reply to John Paul Adrian Glaubitz from comment #301) > I can confirm that I can successfully perform a full native bootstrap with > the following languages enabled: > > - c,c++,fortran,objc,obj-c++,m2 > > There were no segfaults or comparison failures either. > > I can also confirm that this branch fixes the problems reported in comment > #271, comment #273 and comment #298. > > Last will be verifying that Go and Ada still work. > > This is a huge step forward so far. Congratulations! Ada and Go work fine, too. Let me test lto and jit.
[Bug ipa/115033] [12/13 Regression] Incorrect optimization of by-reference closure fields by fre1 pass since r12-5113-gd70ef65692fced
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115033 --- Comment #24 from Sam James --- (In reply to Sam James from comment #23) > Honza, would you mind doing the older branches too? ... or I can if you're fine with it.
[Bug ipa/115033] [12/13 Regression] Incorrect optimization of by-reference closure fields by fre1 pass since r12-5113-gd70ef65692fced
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115033 --- Comment #23 from Sam James --- Honza, would you mind doing the older branches too?
[Bug target/116809] New: Failure to build GCC on macOS 15 / Xcode 16 for Intel
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116809 Bug ID: 116809 Summary: Failure to build GCC on macOS 15 / Xcode 16 for Intel Product: gcc Version: 15.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: fxcoudert at gcc dot gnu.org Target Milestone: --- The build fails during the compilation of the libgcc_s.1.dylib library with: :info:build Undefined symbols for architecture x86_64: :info:build "___deregister_frame_info", referenced from: :info:build -reexported_symbols_list command line option :info:build "___deregister_frame_info_bases", referenced from: :info:build -reexported_symbols_list command line option :info:build "___register_frame_info", referenced from: :info:build -reexported_symbols_list command line option :info:build "___register_frame_info_bases", referenced from: :info:build -reexported_symbols_list command line option :info:build "___register_frame_info_table", referenced from: :info:build -reexported_symbols_list command line option :info:build "___register_frame_info_table_bases", referenced from: :info:build -reexported_symbols_list command line option :info:build "___register_frame_table", referenced from: :info:build -reexported_symbols_list command line option :info:build ld: symbol(s) not found for architecture x86_64 :info:build collect2: error: ld returned 1 exit status :info:build make[3]: *** [libgcc_s.1.dylib] Error 1 These symbols are indeed gone from macOS 15's version of libunwind.dylib A possible work-around is simply to avoid building the old libgcc_s.1.dylib. It's only there for backward compatibility. The hack below does this: diff --git a/libgcc/config/i386/t-darwin b/libgcc/config/i386/t-darwin index 4c18da1efbf..0f61dd53d75 100644 --- a/libgcc/config/i386/t-darwin +++ b/libgcc/config/i386/t-darwin @@ -6,4 +6,4 @@ LIB2FUNCS_EXCLUDE = _fixtfdi _fixunstfdi _floatditf _floatunditf SHLIB_MAPFILES += $(srcdir)/config/i386/libgcc-darwin.ver # Build a legacy libgcc_s.1 -BUILD_LIBGCCS1 = YES +# BUILD_LIBGCCS1 = YES Probably we want to refine this patch, only skip libgcc_s.1.dylib on macOS 15 and later (and retain it on macOS versions where it actually built fine).
[Bug target/55212] [SH] Switch to LRA
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212 --- Comment #305 from Kazumoto Kojima --- (In reply to Oleg Endo from comment #304) > I think this is a bit clearer, thanks! One more question > > (define_insn "block_lump_real" > [(set (mem:BLK (match_operand:SI 2 "sfunc_arg0_reg" "=r,r")) > (mem:BLK (match_operand:SI 3 "sfunc_arg1_reg" "=r,r"))) >(use (match_operand:SI 0 "arith_reg_operand" "r,r")) >(use (match_operand 1 "" "Z,Ccl")) >(use (match_operand:SI 4 "sfunc_arg2_reg" "=r,r")) > >(use (reg:SI R4_REG))<< >(use (reg:SI R5_REG))<< >(use (reg:SI R6_REG))<< > >(clobber (match_dup 2)) >(clobber (match_dup 3)) >(clobber (match_dup 4)) >(clobber (reg:SI PR_REG)) > > Is it possible to do '(use (match_dup 2)' and so on instead of having the > hard regs in there? It isn't. When replacing hard reg with match_dup, it compiles our tiny sfunc test to: foo: mov.l r14,@-r15 ! 32[c=4 l=2] movsi_ie/8 mov r4,r5 ! 23[c=4 l=2] movsi_ie/1 sts.l pr,@-r15! 33[c=4 l=2] movsi_ie/10 mov.w .L6,r1 ! 34[c=10 l=2] *movhi/0 mov #0,r7 ! 16[c=4 l=2] movsi_ie/2 mov.l .L4,r6 ! 29[c=10 l=2] movsi_ie/0 sub r1,r15 ! 35[c=4 l=2] *subsi3_internal mov r15,r14 ! 30[c=4 l=2] movsi_ie/1 add #4,r14 ! 31[c=4 l=2] *addsi3_compact_lra/0 jsr @r6 ! 12[c=1 l=2] block_lump_real_i4/0 mov r14,r4 ! 9 [c=4 l=2] movsi_ie/1 ... .L6: .short 260 which wrongly assigns r6 to the function address, for example.
[Bug target/116809] Failure to build GCC on macOS 15 / Xcode 16 for Intel
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116809 --- Comment #4 from Iain Sandoe --- (In reply to Chris Jones from comment #3) > CN you prepare a version of the patch for the current gcc14 release ? I guess you tried applying the attached patch and it does not ? you mean for the Arm64 development branch - or for upstream releases/gcc-14? (I will do both of course - but testing on trunk first)
[Bug target/116809] Failure to build GCC on macOS 15 / Xcode 16 for Intel
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116809 --- Comment #5 from Chris Jones --- Correct, i could not get it to apply against gcc 14.2
[Bug target/116809] Failure to build GCC on macOS 15 / Xcode 16 for Intel
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116809
Mark Mentovai changed:
What|Removed |Added
CC||mark at moxienet dot com
--- Comment #10 from Mark Mentovai ---
The undefined symbols are things that libgcc_s.1 is trying to re-export from
libunwind via libSystem. None of those functions ever worked on any Apple OS.
They were present in Mac OS X 10.5 and 10.6, but broken. Since Mac OS X 10.7,
they’ve been no-ops. In macOS 15, they’ve been removed entirely. There are
other unwind functions, such as __{,de}register_frame, that remain in libunwind
and libSystem.
The no-op versions in libunwind since 10.7 (libunwind-30 is the version used in
10.7) can be seen at
https://github.com/apple-oss-distributions/libunwind/blob/libunwind-30/src/UnwindLevel1-gcc-ext.c#L220.
The modern version of that is
https://github.com/llvm/llvm-project/blob/b7a249d26fe61432050df470d23bdea417fda574/libunwind/src/UnwindLevel1-gcc-ext.c#L282.
Note that since
https://github.com/llvm/llvm-project/commit/5eb44df1b64dbd1a86b099128092a7fd2001c0ba,
these no-op functions are now only built if LIBUNWIND_ENABLE_FRAME_APIS is
enabled, and it’s off by default.
Similarly, these symbols were removed from llvm-libgcc in
https://github.com/llvm/llvm-project/commit/be91bd012123de835f64e10e677b24a7580b273c.
Because these functions were always non-working or non-functional, I’d be
surprised to find anyone in the wild referring to them on macOS, so it’s almost
certainly safe to remove them from libgcc_s.1 altogether without risking any
binary compatibility concern, as Apple themselves have done in macOS 15 and in
llvm-libgcc. This is my preferred option, as well as the simplest to implement.
If there’s any remaining concern that someone might be referencing those
symbols, it ought to be safe to implement them as either no-ops directly in
libgcc_s.1 or to implement them as code that delegates to the libunwind (via
libSystem) versions if present, and to function as a no-op otherwise. This is
the safest option, but I don’t believe that it’s necessary.
Eliminating libgcc_s.1 entirely runs the risk of breaking binary compatibility
with code built by older toolchains that may reference that library (while not
referencing the removed symbols from that library). I would tend to be more
cautious about that approach, especially if targeting a merge back to a stable
branch. But I haven’t done the research to determine how recently a toolchain
may have imposed a run-time dependency on this library.
[Bug target/116809] Failure to build GCC on macOS 15 / Xcode 16 for Intel
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116809 --- Comment #12 from Mark Mentovai --- Created attachment 59179 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=59179&action=edit Drop removed unwind symbols This implements what I referred to as my preferred option in comment 10. It should apply on the trunk and to all active branches.
[Bug target/116809] Failure to build GCC on macOS 15 / Xcode 16 for Intel
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116809 --- Comment #11 from Iain Sandoe --- Indeed, all of this is well-known; NOTE: there is no change proposed for any OS < macOS 15. We actually bumped our libgcc_s version some time ago because GCC has for a while now been pulling the unwinder directly from libSystem (or /usr/lib/libgcc_s.1.dylib on darwin9). So GCC will not (for several releases now) be emitting any reference to libgcc_s.1.dylib - and on darwin9 (which actually needs the installed /usr/lib/libgcc_s.1.dylib) as said, there's no change proposed To use the GCC legacy lib - you'd have to use DYLD_LIBRARY_PATH to force point to an installation - otherwise the installed version in /usr/lib would (and should) be used anyway .. My view is that we want to remove this sometime - like Apple, eventually "legacy" has to be "we no longer care" .. so my preference is to remove it - and if we should get fallout - then we can consider an alternate solution with an edited symbols list.
[Bug target/116809] Failure to build GCC on macOS 15 / Xcode 16 for Intel
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116809 --- Comment #13 from Mark Mentovai --- Comment 12 was a Bugzilla mid-air with comment 11. I’m not arguing against comment 11, just offering an option that worked for me. Been a while since I’ve used Bugzilla regularly, I forgot about these quaint mid-airs…
[Bug target/116809] Failure to build GCC on macOS 15 / Xcode 16 for Intel
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116809 --- Comment #14 from Iain Sandoe --- (In reply to Mark Mentovai from comment #12) > Created attachment 59179 [details] > Drop removed unwind symbols > > This implements what I referred to as my preferred option in comment 10. It > should apply on the trunk and to all active branches. as specified, I think this will break Darwin <= 9 (and maybe ppc on 10) which still look up the frame info. the long-term goal here is to simplify the GCC as much as possible - we have such limited resources - so any removal is a bonus. --- NP about the mid-airs :) it happens...
[Bug target/116715] RISC-V: Miscompile at -O2 with -march=rv64id_zbs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116715 Jeffrey A. Law changed: What|Removed |Added Ever confirmed|0 |1 Last reconfirmed||2024-09-22 Status|UNCONFIRMED |NEW
[Bug target/116111] RISC-V: 'd' extension allowed with -mabi=ilp32e
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116111 Jeffrey A. Law changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #4 from Jeffrey A. Law --- Fixed on the trunk.
[Bug target/113980] risc-v: unnecessary sign-extend after lw with volatile, and more
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113980 Jeffrey A. Law changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #2 from Jeffrey A. Law --- volatile inhibits all kinds of optimizations, in this case it inhibits our ability to combine instructions and eliminate the extension. It's unfortunate, but everything is behaving per design.
