[Bug target/111822] [12/13/14 Regression] during RTL pass: lr_shrinkage ICE: in operator[], at vec.h:910 with -O2 -m32 -flive-range-shrinkage -fno-dce -fnon-call-exceptions since r12-5301-g04520645038
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111822
Richard Biener changed:
What|Removed |Added
Keywords||wrong-code
Component|rtl-optimization|target
--- Comment #8 from Richard Biener ---
I think it's split1 doing wrong. We end up with
;; basic block 3, loop depth 0, count 118111600 (estimated locally, freq
1.), maybe hot
;; prev block 2, next block 4, flags: (NEW, HOT_PARTITION, RTL, MODIFIED)
;; pred: 2 [always] count:118111600 (estimated locally, freq 1.)
(FALLTHRU)
;; bb 3 artificial_defs: { }
;; bb 3 artificial_uses: { u-1(6){ }u-1(7){ }u-1(16){ }u-1(19){ }}
;; lr in
;; lr use
;; lr def
;; live in
;; live gen
;; live kill
(note 124 10 126 3 [bb 3] NOTE_INSN_BASIC_BLOCK)
(jump_insn 126 124 127 3 (set (pc)
(label_ref 125)) -1
(nil)
-> 125)
;; succ: 6 [always] count:118111600 (estimated locally, freq 1.)
;; lr out
;; live out
(barrier 127 126 84)
;; basic block 4, loop depth 0, count 0 (precise, freq 0.), probably never
executed
;; prev block 3, next block 5, flags: (REACHABLE, HOT_PARTITION, RTL,
MODIFIED)
;; pred:
;; bb 4 artificial_defs: { d-1(0){ }d-1(1){ }}
;; bb 4 artificial_uses: { u-1(6){ }u-1(7){ }u-1(16){ }u-1(19){ }}
;; lr in6 [bp] 7 [sp] 16 [argp] 19 [frame]
;; lr use 6 [bp] 7 [sp] 16 [argp] 19 [frame]
;; lr def 0 [ax] 1 [dx] 114 115
;; live in 6 [bp] 7 [sp] 16 [argp] 19 [frame]
;; live gen 0 [ax] 1 [dx] 114 115
;; live kill
(code_label/s 84 127 86 4 13 (nil) [1 uses])
(note 86 84 93 4 [bb 4] NOTE_INSN_BASIC_BLOCK)
(insn 93 86 85 4 (set (reg:SI 115)
(reg:SI 0 ax)) "t.ii":22:42 -1
(expr_list:REG_DEAD (reg:SI 0 ax)
so block 4 is unreachable. split1 does
102: r122:DI#0=vec_concat([r98:SI],0)
10: r102:DI#0=r122:DI#0
- REG_EH_REGION 0xd
124: NOTE_INSN_BASIC_BLOCK 3
that looks spurious, so possibly some other pass leaves around the dead EH.
Earlier this was
10: r102:DI=[r98:SI]
REG_EH_REGION 0xd
; pc falls through to BB 5
and STV2 changes this like
- 10: r102:DI=[r98:SI]
+ 102: r122:DI#0=vec_concat([r98:SI],0)
+ 10: r102:DI#0=r122:DI#0
REG_EH_REGION 0xd
; pc falls through to BB 5
failing to move EH (or refuse the lowering).
Thus a target issue, even wrong-code I think as we now fail to catch
a trap by the [r98:SI] load.
[Bug tree-optimization/114268] [14 Regression] 5% exec time regression in 454.calculix on Aarch64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114268 Richard Biener changed: What|Removed |Added Target Milestone|--- |14.0
[Bug tree-optimization/114269] [14 Regression] Multiple 3-27% exec time regressions of 434.zeusmp since r14-9193-ga0b1798042d033
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114269 Richard Biener changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org Target Milestone|--- |14.0 Last reconfirmed||2024-03-08 Ever confirmed|0 |1 --- Comment #1 from Richard Biener --- I will look if I can find a nice testcase for x86_64 here.
[Bug middle-end/105533] UBSAN: gcc/expmed.cc:3272:26: runtime error: signed integer overflow: -9223372036854775808 - 1 cannot be represented in type 'long int'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105533 --- Comment #13 from David Binderman --- Seems fixed to me. I built a bootstrap with ASAN and UBSAN for languages C, C++ and Fortran and changed the usual -O2 for -O3 -march=znver3 and the bootstrap passed. I hadn't realised a bootstrap was such a good test of the compiler.
[Bug middle-end/105533] UBSAN: gcc/expmed.cc:3272:26: runtime error: signed integer overflow: -9223372036854775808 - 1 cannot be represented in type 'long int'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105533 Jakub Jelinek changed: What|Removed |Added Resolution|--- |FIXED Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org Status|UNCONFIRMED |RESOLVED --- Comment #14 from Jakub Jelinek --- .
[Bug other/63426] [meta-bug] Issues found with -fsanitize=undefined
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63426 Bug 63426 depends on bug 105533, which changed state. Bug 105533 Summary: UBSAN: gcc/expmed.cc:3272:26: runtime error: signed integer overflow: -9223372036854775808 - 1 cannot be represented in type 'long int' https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105533 What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED
[Bug middle-end/114270] Integer multiplication on floating point constant with conversion back to integer is not optimized
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114270 Richard Biener changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2024-03-08 Ever confirmed|0 |1 --- Comment #2 from Richard Biener --- I think it makes sense to optimize for 1/power-of-two only. Whether an actual integer division instruction we could replace x * FP_CST with would be faster than int->FP, FP multiply, FP->int is questionable. But a shift very likely is. Special-casing just * 0.5 might also an option.
[Bug c++/113802] gcc rejects auto f(this auto self...) { }
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113802 --- Comment #3 from GCC Commits --- The master branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:3ecc5071797c4ceb6da67a6c2b2527a046091de2 commit r14-9384-g3ecc5071797c4ceb6da67a6c2b2527a046091de2 Author: Jakub Jelinek Date: Fri Mar 8 09:11:57 2024 +0100 c++: Fix up parameter pack diagnostics on xobj vs. varargs functions [PR113802] The simple presence of ellipsis as next token after the parameter declaration doesn't imply it is a parameter pack, it sometimes is, e.g. if its type is a pack, but sometimes is not and in that case it acts the same as if the next tokens were , ... instead of just ... The xobj param cannot be a function parameter pack though treats both the declarator->parameter_pack_p and token->type == CPP_ELLIPSIS as sufficient conditions for the error. The conditions for CPP_ELLIPSIS are done a little bit later in the same function and complex enough that IMHO shouldn't be repeated, on the other side for the declarator->parameter_pack_p case we clear that flag for xobj params for error recovery reasons. This patch just moves the diagnostics later (after the CPP_ELLIPSIS handling) and changes the error recovery behavior by pretending the this specifier didn't appear if an error is reported. 2024-03-08 Jakub Jelinek PR c++/113802 * parser.cc (cp_parser_parameter_declaration): Move the xobj_param_p pack diagnostics after ellipsis handling and if an error is reported, pretend this specifier didn't appear. Formatting fix. * g++.dg/cpp23/explicit-obj-diagnostics3.C (S0, S1, S2, S3, S4): Don't expect any diagnostics on f and fd member function templates, add similar templates with ...Selves instead of Selves as k and kd and expect diagnostics for those. Expect extra diagnostics in error recovery for g and gd member function templates.
[Bug debug/113918] Incomplete DWARF5 debug information for anonymous unions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113918 --- Comment #3 from GCC Commits --- The master branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:05109b1bd5ef4ee9d78fe17d4563889694a26d05 commit r14-9385-g05109b1bd5ef4ee9d78fe17d4563889694a26d05 Author: Jakub Jelinek Date: Fri Mar 8 09:14:32 2024 +0100 dwarf2out: Emit DW_AT_export_symbols on anon unions/structs [PR113918] DWARF5 added DW_AT_export_symbols both for use on inline namespaces (where we emit it), but also on anonymous unions/structs (and we didn't emit that attribute there). The following patch fixes it. 2024-03-08 Jakub Jelinek PR debug/113918 gcc/ * dwarf2out.cc (gen_field_die): Emit DW_AT_export_symbols on anonymous unions or structs for -gdwarf-5 or -gno-strict-dwarf. gcc/c/ * c-tree.h (c_type_dwarf_attribute): Declare. * c-objc-common.h (LANG_HOOKS_TYPE_DWARF_ATTRIBUTE): Redefine. * c-objc-common.cc: Include dwarf2.h. (c_type_dwarf_attribute): New function. gcc/cp/ * cp-objcp-common.cc (cp_type_dwarf_attribute): Return 1 for DW_AT_export_symbols on anonymous structs or unions. gcc/testsuite/ * c-c++-common/dwarf2/pr113918.c: New test.
[Bug rtl-optimization/38534] gcc 4.2.1 and above: No need to save called-saved registers in 'noreturn' function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=38534 --- Comment #46 from GCC Commits --- The master branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:a307a26e8b392ba65edfdae15489556b7701db81 commit r14-9387-ga307a26e8b392ba65edfdae15489556b7701db81 Author: Jakub Jelinek Date: Fri Mar 8 09:18:19 2024 +0100 i386: Guard noreturn no-callee-saved-registers optimization with -mnoreturn-no-callee-saved-registers [PR38534] The following patch hides the noreturn no_callee_saved_registers (except bp) optimization with a not enabled by default option. The reason is that most noreturn functions should be called just once in a program (unless they are recursive or invoke longjmp or similar, for exceptions we already punt), so it isn't that essential to save a few instructions in their prologue, but more importantly because it interferes with debugging. And unlike most other optimizations, doesn't actually make it harder to debug the given function, which can be solved by recompiling the given function if it is too hard to debug, but makes it harder to debug the callers of that noreturn function. Those can be from a different translation unit, different binary or even different package, so if e.g. glibc abort needs to use all of the callee saved registers (%rbx, %rbp, %r12, %r13, %r14, %r15), debugging any programs which abort will be harder because any DWARF expressions which use those registers will be optimized out, not just in the immediate caller, but in other callers as well until some frame restores a particular register from some stack slot. 2024-03-08 Jakub Jelinek PR target/38534 * config/i386/i386.opt (mnoreturn-no-callee-saved-registers): New option. * config/i386/i386-options.cc (ix86_set_func_type): Don't use TYPE_NO_CALLEE_SAVED_REGISTERS_EXCEPT_BP unless ix86_noreturn_no_callee_saved_registers is enabled. * doc/invoke.texi (-mnoreturn-no-callee-saved-registers): Document. * gcc.target/i386/pr38534-1.c: Add -mnoreturn-no-callee-saved-registers to dg-options. * gcc.target/i386/pr38534-2.c: Likewise. * gcc.target/i386/pr38534-3.c: Likewise. * gcc.target/i386/pr38534-4.c: Likewise. * gcc.target/i386/pr38534-5.c: Likewise. * gcc.target/i386/pr38534-6.c: Likewise. * gcc.target/i386/pr114097-1.c: Likewise. * gcc.target/i386/stack-check-17.c: Likewise.
[Bug fortran/114280] New: ASSOCIATE fails with inquiry references when selector function not yet parsed.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114280 Bug ID: 114280 Summary: ASSOCIATE fails with inquiry references when selector function not yet parsed. Product: gcc Version: 13.2.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: pault at gcc dot gnu.org Target Milestone: --- Fails identically back to 6.4.1 at least: implicit none type t real :: re end type t call foo contains subroutine foo () associate (x => bar1()) print *, x%im ! Has no IMPLICIT type end associate associate (x => bar1()) print *, x%re ! Invalid character in name end associate associate (x => bar2()) print *, x%re ! Invalid character in name end associate associate (x => bar3()) print *, x%len ! Has no IMPLICIT type end associate end complex function bar1 () bar1 = cmplx(-42., 1.) end type(t) function bar2 () bar2% re = 42. end character(8) function bar3 () bar3 = "Nice one!" end end Works if: (i) subroutine foo is placed after functions bar[1-3]; or (ii) if intrinsics real, imag and len are used instead of inquiry references and component 're' is renamed. This bug appears for the same reason as PR99065. Paul Paul
[Bug target/97367] powerpc64 g5 and cell optimizations result in .machine power7
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97367 --- Comment #5 from René Rebe --- latest version: https://svn.exactcode.de/t2/trunk/package/develop/gcc/hotfix-g5-power4.patch
[Bug debug/113918] Incomplete DWARF5 debug information for anonymous unions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113918 Jakub Jelinek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #4 from Jakub Jelinek --- Should be implemented now in GCC 14.
[Bug c++/113802] gcc rejects auto f(this auto self...) { }
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113802 Jakub Jelinek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #4 from Jakub Jelinek --- Should be fixed now.
[Bug middle-end/114270] Integer multiplication on floating point constant with conversion back to integer is not optimized
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114270 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #3 from Jakub Jelinek --- (In reply to Andrew Pinski from comment #1) > The rules for this to be done are a bit more complex than what is described > here. > > 1) Significand precision of the floating point type needs to be >= precision > of the integer type I'd also verify that minimum/maximum of the integer type are exactly representable in the floating point type, such that even limitations on exponent don't stand in a way.
[Bug target/97367] powerpc64 g5 and cell optimizations result in .machine power7
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97367 Sam James changed: What|Removed |Added CC||sjames at gcc dot gnu.org --- Comment #6 from Sam James --- Please send it to the ML with git-send-email.
[Bug tree-optimization/114281] New: [14 Regression] Multiple 2-10% exec time regressions of 465.tonto since r14-9193-ga0b1798042d033
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114281
Bug ID: 114281
Summary: [14 Regression] Multiple 2-10% exec time regressions
of 465.tonto since r14-9193-ga0b1798042d033
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: pheeck at gcc dot gnu.org
Blocks: 26163
Target Milestone: ---
Host: aarch64-gnu-linux, x86_64-linux
Target: aarch64-gnu-linux, x86_64-linux
Our LNT instance has detected that runtime of benchmark 465.tonto from the SPEC
2006 suite regressed on all of our machines (aarch64 ampere altra, intel
skylake, amd zen{2,3,4}) on most configurations by 2-10%.
One example: Zen4 -Ofast -flto -march=native (regressed by 10%)
https://lnt.opensuse.org/db_default/v4/SPEC/graph?plot.0=992.230.0
I've bisected the example configuration to r14-9193-ga0b1798042d033 (Richard
Biener: tree-optimization/114074 - CHREC multiplication and undefined
overflow).
There have been two other SPEC benchmarks regressions reported that also got
bisected to this commit -- pr114269, pr114238. I assume that all of these have
the same cause.
Referenced Bugs:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=26163
[Bug 26163] [meta-bug] missed optimization in SPEC (2k17, 2k and 2k6 and 95)
[Bug target/111822] [12/13/14 Regression] during RTL pass: lr_shrinkage ICE: in operator[], at vec.h:910 with -O2 -m32 -flive-range-shrinkage -fno-dce -fnon-call-exceptions since r12-5301-g04520645038
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111822 --- Comment #9 from Uroš Bizjak --- The offending insn is emitted in general_scalar_chain::convert_op due to preloading, but I have no idea how EH should be adjusted. There is another instance in timode_scalar_chain::convert_op. emit_insn_before (gen_rtx_SET (gen_rtx_SUBREG (vmode, tmp, 0), gen_gpr_to_xmm_move_src (vmode, *op)), insn);
[Bug tree-optimization/114281] [14 Regression] Multiple 2-10% exec time regressions of 465.tonto since r14-9193-ga0b1798042d033
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114281
Xi Ruoyao changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|--- |DUPLICATE
CC||xry111 at gcc dot gnu.org
--- Comment #1 from Xi Ruoyao ---
(In reply to Filip Kastl from comment #0)
> Our LNT instance has detected that runtime of benchmark 465.tonto from the
> SPEC 2006 suite regressed on all of our machines (aarch64 ampere altra,
> intel skylake, amd zen{2,3,4}) on most configurations by 2-10%.
>
> One example: Zen4 -Ofast -flto -march=native (regressed by 10%)
> https://lnt.opensuse.org/db_default/v4/SPEC/graph?plot.0=992.230.0
>
> I've bisected the example configuration to r14-9193-ga0b1798042d033 (Richard
> Biener: tree-optimization/114074 - CHREC multiplication and undefined
> overflow).
>
> There have been two other SPEC benchmarks regressions reported that also got
> bisected to this commit -- pr114269, pr114238. I assume that all of these
> have the same cause.
Please don't open more tickets unless you are assuming they do *not* have the
same cause.
*** This bug has been marked as a duplicate of bug 114269 ***
[Bug tree-optimization/114269] [14 Regression] Multiple 3-27% exec time regressions of 434.zeusmp since r14-9193-ga0b1798042d033
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114269 --- Comment #2 from Xi Ruoyao --- *** Bug 114281 has been marked as a duplicate of this bug. ***
[Bug middle-end/26163] [meta-bug] missed optimization in SPEC (2k17, 2k and 2k6 and 95)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=26163 Bug 26163 depends on bug 114281, which changed state. Bug 114281 Summary: [14 Regression] Multiple 2-10% exec time regressions of 465.tonto since r14-9193-ga0b1798042d033 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114281 What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE
[Bug tree-optimization/114151] [14 Regression] weird and inefficient codegen and addressing modes since r14-9193
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114151
--- Comment #16 from Richard Biener ---
(In reply to Andrew Macleod from comment #12)
>
> all VRP passes are the same now. so just schedule EVRP. in theory, you
> could schedule the fast vrp pass I added, but its not heavily tested... but
> you could try it. It doesnt do any back edges or switches (iirc), but does
> basic calculations in DOM order and exports/updates globals.
>
> NEXT_PASS (pass_fast_vrp)
When I just want to update global ranges what do I do? It looks like
VRP first and foremost calls range_of_stmt on each PHI and stmt in the
pre-fold hook. Does that update global ranges? It should at least
fill the cache so SCEV would pick up ranges, right?
So doing in the vectorizer sth like the following should get us the best
possible ranges? Ah, probably only global ranges since the SCEV query
itself would still lack context sensitive info (but as said we don't have
a good context we can easily use).
Would doing sth like below gain anything in addition to your proposed
patch (for context-less queries like those done in SCEV)?
@@ -1240,6 +1241,37 @@ pass_vectorize::execute (function *fun)
if (vect_loops_num <= 1)
return 0;
+ scev_reset ();
+ auto ranger = enable_ranger (fun);
+
+{
+ basic_block bb;
+ FOR_EACH_BB_FN (bb, fun)
+ {
+ for (auto gsi = gsi_start_phis (bb); !gsi_end_p (gsi); gsi_next
(&gsi))
+ {
+ tree name = gimple_range_ssa_p (PHI_RESULT (*gsi));
+ if (name)
+ {
+ Value_Range vr(TREE_TYPE (name));
+ ranger->range_of_stmt (vr, *gsi, name);
+ }
+ }
+ for (auto gsi = gsi_start_bb (bb); !gsi_end_p (gsi); gsi_next (&gsi))
+ {
+ gimple *s = *gsi;
+ if (is_gimple_debug (s))
+ continue;
+ tree type = gimple_range_type (s);
+ if (type)
+ {
+ Value_Range vr(type);
+ ranger->range_of_stmt (vr, s);
+ }
+ }
+ }
+}
+
[Bug fortran/110826] Fortran array of derived type with a pointer to function with dimensional arguments fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110826 Jonathan Wakely changed: What|Removed |Added Last reconfirmed||2024-03-08 Ever confirmed|0 |1 Keywords||ice-on-valid-code Status|UNCONFIRMED |NEW
[Bug tree-optimization/114281] [14 Regression] Multiple 2-10% exec time regressions of 465.tonto since r14-9193-ga0b1798042d033
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114281 --- Comment #2 from Filip Kastl --- > Please don't open more tickets unless you are assuming they do *not* have the > same cause. Alright, noted.
[Bug target/111822] [12/13/14 Regression] during RTL pass: lr_shrinkage ICE: in operator[], at vec.h:910 with -O2 -m32 -flive-range-shrinkage -fno-dce -fnon-call-exceptions since r12-5301-g04520645038
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111822 --- Comment #10 from Richard Biener --- The easiest fix would be to refuse applying STV to a insn that can_throw_internal () (that's an insn that has associated EH info). Updating in this case would require splitting the BB or at least moving the now no longer throwing insn to the next block (along the fallthru edge).
[Bug libstdc++/63400] [C++11]precision of std::chrono::high_resolution_clock
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63400 --- Comment #10 from Jonathan Wakely --- GetSystemTimePreciseAsFileTime gives UTC, so would need adjustment for leap seconds to turn it into a sys_time. That's doable though. Alternatively, we could use it to implement a high performance chrono::utc_clock, and then define system_clock::now() in terms of that. The standard specifies utc_clock::now() as: "Returns: from_sys(system_clock::now()), or a more accurate value of utc_time." Also, if Windows FILETIME is measured in UTC then chrono::file_clock should use that too. So we might want to use a custom implementation of chrono::file_clock for Windows.
[Bug libstdc++/63400] [C++11]precision of std::chrono::high_resolution_clock
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63400 --- Comment #11 from Jonathan Wakely --- (In reply to Jonathan Wakely from comment #8) > Is this still an issue in 2022? > > Using a mingw-w64 cross-compiler and running under Wine I get: > > CLOCK_REALTIME: 0,100 > CLOCK_MONOTONIC: 0,100 > > Is that just because I'm using Wine not real Windows? I still want an answer to this question though.
[Bug tree-optimization/114151] [14 Regression] weird and inefficient codegen and addressing modes since r14-9193
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114151 --- Comment #17 from Tamar Christina --- > So doing in the vectorizer sth like the following should get us the best > possible ranges? Ah, probably only global ranges since the SCEV query > itself would still lack context sensitive info (but as said we don't have > a good context we can easily use). > which reminds me.. I have been playing around with using ranger directly in the vectorizer. It looks like we get better ranges for the overwidening detection. It feels like using ranger.range_of_expr or similar would solve the problem that we don't currently get ranged for structural widening, i.e. https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102188
[Bug tree-optimization/114277] [11/12/13/14 Regression] Missed optimization: x*(x||b) => x
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114277 Richard Biener changed: What|Removed |Added Priority|P3 |P2
[Bug tree-optimization/114269] [14 Regression] Multiple 3-27% exec time regressions of 434.zeusmp since r14-9193-ga0b1798042d033
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114269
--- Comment #3 from Richard Biener ---
good (base) vs. bad (peak) on Zen2 with -Ofast -march=native shows
Samples: 654K of event 'cycles', Event count (approx.): 743149709374
Overhead Samples Command Shared Object Symbol
16.71%109793 zeusmp_peak.amd zeusmp_peak.amd64-m64-mine [.] hsmoc_
14.37% 94016 zeusmp_base.amd zeusmp_base.amd64-m64-mine [.] hsmoc_
8.82% 57979 zeusmp_peak.amd zeusmp_peak.amd64-m64-mine [.]
lorentz_
8.48% 55451 zeusmp_base.amd zeusmp_base.amd64-m64-mine [.]
lorentz_
4.84% 31575 zeusmp_peak.amd zeusmp_peak.amd64-m64-mine [.] momx3_
4.68% 30456 zeusmp_base.amd zeusmp_base.amd64-m64-mine [.] momx3_
4.08% 26675 zeusmp_peak.amd zeusmp_peak.amd64-m64-mine [.]
tranx3_
3.56% 23145 zeusmp_base.amd zeusmp_base.amd64-m64-mine [.]
tranx3_
for hsmoc_ it looks like a difference in transformations done:
-hsmoc.f:826:19: optimized: loop vectorized using 32 byte vectors
(there are a lot more missed vectorizations).
subroutine hsmoc ( emf1, emf2, emf3 )
integer is, ie, js, je, ks, ke
common /gridcomi/
& is, ie, js, je, ks, ke
integer in, jn, kn, ijkn
integer i , j , k
parameter(in = 128+5
&, jn = 128+5
&, kn = 128+5)
parameter(ijkn = 128+5)
real*8 emf1( in, jn, kn), emf2( in, jn, kn)
real*8 vint(ijkn), bint(ijkn)
do 199 j=js,je+1
do 59 i=is,ie
do 858 k=ks,ke+1
vint(k)= k
bint(k)= k
858 continue
do 58 k=ks,ke+1
emf1(i,j,k) = vint(k)
emf2(i,j,k) = bint(k)
58 continue
59 continue
199 continue
return
end
doesn't reproduce it though. The actual difference for the whole testcase
is of course failed data-ref analysis:
Creating dr for (*emf2_1966(D))[_402]
-analyze_innermost: success.
- base_address: emf2_1966(D)
- offset from base address: (ssizetype) sizetype) _1928 * 17689 +
(sizetype) j_2705 * 133) + (sizetype) i_2672) * 8)
- constant offset from base address: -142584
- step: 141512
- base alignment: 8
+analyze_innermost: hsmoc.f:828:72: missed: failed: evolution of offset is not
affine.
+ base_address:
+ offset from base address:
+ constant offset from base address:
+ step:
+ base alignment: 0
and then
hsmoc.f:826:19: note: === vect_analyze_data_ref_accesses ===
-hsmoc.f:826:19: missed: not consecutive access (*emf1_1964(D))[_402] = _403;
-hsmoc.f:826:19: note: using strided accesses
-hsmoc.f:826:19: missed: not consecutive access (*emf2_1966(D))[_402] = _404;
-hsmoc.f:826:19: note: using strided accesses
and we use gather and fail because of costs.
I suspect that relying on global ranges (that could save us here) is quite
fragile when there's a lot of other code around and thus opportunity for
random transforms "trashing" them.
Using the patch from PR114151 and enabling ranger during vectorization oddly
enough doesn't help (even when wiping the SCEV cache).
The odd thing is with the testcase above we get
Access function 0: (integer(kind=8)) {(((unsigned long) _30 * 17689 +
(unsigned long) _10) + (unsigned long) _66) + 18446744073709533793, +,
17689}_4;
where you can see some of the unsigned promotion being done, but we
still succeed.
As I'm lacking a smaller testcase right now it's difficult to understand why
we fail in one case but not the other.
[Bug libstdc++/114240] sys_days not being parsed with only a date in the stream
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114240 --- Comment #6 from Jonathan Wakely --- Actually the standard does support Howard's intended behaviour: "If the parse fails to decode a valid date, is.setstate(ios_base::failbit) is called and tp is not modified." It says "date", not "time point" or "UTC time" or anything like that.
[Bug target/114137] ICE when building lua-5.4.6 with -fharden-control-flow-redundancy on x86 (error: invalid rtl sharing found in the insn)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114137 --- Comment #6 from Alexandre Oliva --- Thanks for the report. Something's very rotten here. cfrvisited is an automatic variable, why oh why would we have GOTOFF unspecs for it?!? I'd be interested in a preprocessed testcase that will trigger the problem. Failing that, I suppose I could try to drive a remote debug session if you're up for it. If it is indeed something related with GC as suggested (and it sounds plausible), the exact details of when it hits will depend on local hardware details and not necessarily carry over to other machines.
[Bug tree-optimization/114074] [11/12/13 Regression] wrong code at -O1 and above on x86_64-linux-gnu since r8-343
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114074
--- Comment #10 from Richard Biener ---
Some thoughts on the CHREC folding, in the context of the many reported
optimization regressions.
We try to handle { a, +, b } * c as { a * c, +, b * c } and the issue is
cases of undefined overflow this exposes.
We have to make sure to not introduce undefined behavior that isn't there
- at the first evaluation (the first iteration) both expressions behave
the same with respect to overflow since it's a * c without any increment
- further evaluations will do ((a + b) + ... + b) * c before and
(a * c + b * c) + ... + b * c after the transform
- (a + b) + b doesn't necessarily behave the same as a + 2*b
I'm not sure we can, say, rely on a * c not invoking undefined overflow
since we do not know whether the expression will be evaluated at runtime
and whether SCEV analysis properly handles conditional execution in this
regard (it just follows the data dependence graph).
For the fix I've looked at the simplest part, when does (a + b) * c possibly
not overflow but a * c or b * c does? Only when a + b has smaller magnitude
than a or b which should mean a and b have to have opposite sign. Without
proving I think (a + b + b) * c vs. a * c + b * c + b * c doesn't add
anything, thus the addition can be ignored and just the multiplication matters.
When in the future maybe adding 'assumptions' to SCEV results we could
unconditionally do the simplification but register an appropriate
assumption that needs to hold (and which we could check at runtime).
At runtime it's probably enough to verify that b * c does not overflow,
the evaluation of a * c should be guarded.
[Bug middle-end/112938] ice with -fstrub=internal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112938 --- Comment #10 from Alexandre Oliva --- Thanks, yeah, I can duplicate the problem using the original testcase.
[Bug libstdc++/114279] utc_clock does not support leap seconds
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114279
Jonathan Wakely changed:
What|Removed |Added
Target Milestone|--- |13.3
Assignee|unassigned at gcc dot gnu.org |redi at gcc dot gnu.org
Ever confirmed|0 |1
Last reconfirmed||2024-03-08
Status|UNCONFIRMED |ASSIGNED
--- Comment #2 from Jonathan Wakely ---
Fix:
--- a/libstdc++-v3/include/bits/chrono_io.h
+++ b/libstdc++-v3/include/bits/chrono_io.h
@@ -2854,9 +2854,19 @@ namespace __detail
basic_string<_CharT, _Traits, _Alloc>* __abbrev = nullptr,
minutes* __offset = nullptr)
{
- sys_time<_Duration> __st;
- if (chrono::from_stream(__is, __fmt, __st, __abbrev, __offset))
- __tp = chrono::time_point_cast<_Duration>(utc_clock::from_sys(__st));
+ minutes __off{};
+ if (!__offset)
+ __offset = &__off;
+ using __format::_ChronoParts;
+ auto __need = _ChronoParts::_Year | _ChronoParts::_Month
+ | _ChronoParts::_Day | _ChronoParts::_TimeOfDay;
+ __detail::_Parser_t<_Duration> __p(__need);
+ if (__p(__is, __fmt, __abbrev, __offset))
+ {
+ auto __ut = utc_clock::from_sys(__p._M_sys_days) + __p._M_time
+ - *__offset;
+ __tp = chrono::time_point_cast<_Duration>(__ut);
+ }
return __is;
}
But we also need a change to the other from_stream overloads that are defined
in terms of utc_time, so that they don't allow 60s.
[Bug libstdc++/63400] [C++11]precision of std::chrono::high_resolution_clock
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63400 --- Comment #12 from Jonathan Wakely --- (In reply to Jonathan Wakely from comment #10) > GetSystemTimePreciseAsFileTime gives UTC, so would need adjustment for leap > seconds to turn it into a sys_time. That's doable though. Doable, but it would make calls to system_clock::now() slower, because converting UTC to system requires a lookup in the leap second table, and then adjusting the time. Another option would be to leave system_clock alone, but make utc_clock fast and precise on Windows, and make high_resolution_clock a separate type (not a typedef for system_clock) which happens to use the same implementation as utc_clock. > Also, if Windows FILETIME is measured in UTC then chrono::file_clock should > use that too. So we might want to use a custom implementation of > chrono::file_clock for Windows. And replace its from_sys/to_sys members with from_utc/to_utc.
[Bug target/110027] Misaligned vector store on detect_stack_use_after_return
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110027 --- Comment #9 from Chris Elrod --- > Interestingly this seems to be only reproducible on Arch Linux. Other gcc > 13.1.1 builds, Fedora for instance, seem to behave correctly. I haven't tried that reproducer on Fedora with gcc 13.2.1, which could have regressed since 13.1.1. However, the dup example in https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114276 does reproduce on Fedora with gcc-13.2.1 once you add extra compile flags `-std=c++23 -fstack-protector-strong`. I'll try the original reproducer later, it may be the case that adding/removing these flags fuzzes the alignment.
[Bug middle-end/114282] New: [OpenMP] Implicit mapping of function/procedure pointers should use 'firstprivate'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114282
Bug ID: 114282
Summary: [OpenMP] Implicit mapping of function/procedure
pointers should use 'firstprivate'
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Keywords: missed-optimization, openmp
Severity: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: burnus at gcc dot gnu.org
Target Milestone: ---
For C/C++ function pointers and Fortran dummy procedures / procedure pointers,
the assumption is that pointer is either pointing to the desired function
or it has the address of a function on the initial device with 'declare target
indirect'.
GCC produces for implicit mapping:
map(alloc:MEM[(char *)g] [len: 0]) map(firstprivate:g [pointer assign, bias:
0])
But a simple
map(firstprivate:g)
would do here.
Likewise for an explicit map, where there is also no need for a pointer
assignment.
NOTE: For Fortran, it might be that explicit 'map' clauses will get disallowed
per pending OpenMP specification Issue #3823, which is tracked elsewhere.
Trivial testcases (for more complex, see 'indirect' testcases inside GCC or
just add an explicit 'map' clause yourself):
void f(){
void (*g)();
#pragma omp target
g();
}
subroutine f(g)
procedure(), pointer :: g
!$omp target map(g)
call g()
!$omp end target
end
[Bug tree-optimization/114269] [14 Regression] Multiple 3-27% exec time regressions of 434.zeusmp since r14-9193-ga0b1798042d033
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114269
--- Comment #4 from Richard Biener ---
The following is a C testcase for a case where ranges will not help:
void foo (int *a, long js, long je, long is, long ie, long ks, long ke, long
xi, long xj)
{
for (long j = js; j < je; ++j)
for (long i = is; i < ie; ++i)
for (long k = ks; k < ke; ++k)
a[i + j*xi + k*xi*xj] = 5;
}
SCEV analysis result before/after shows issues. When you re-order the loops
so the fast increment goes innermost this doesn't make a difference for
vectorization though. In the order above we now require (emulated) gather
which with SSE didn't work out and previously we used strided stores.
The reason seems to be that when analyzing k*xi*xj the first multiply
yields
(long int) {(unsigned long) ks_21(D) * (unsigned long) xi_24(D), +, (unsigned
long) xi_24(D)}_3
but when then asking to fold the multiply by xj we fail as we run into
tree
chrec_fold_multiply (tree type,
tree op0,
tree op1)
{
...
CASE_CONVERT:
if (tree_contains_chrecs (op0, NULL))
return chrec_dont_know;
/* FALLTHRU */
but this case is somewhat odd as all other unhandled cases simply run into
fold_build2. This possibly means we'd never build other ops with
CHREC operands. This was added for PR42326.
I think we can handle sign-conversions from unsigned just fine, chrec_fold_plus
does such thing already (but it misses one case).
Doing this restores things to some extent.
I'm testing this as an intermediate step before considering reversion of the
change.
[Bug rtl-optimization/114278] ICE: in extract_bit_field_1, at expmed.cc:1838 with memmove, _BitInt() and -O2 -fno-tree-dce -fno-tree-dse -fno-tree-ccp -m32
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114278 --- Comment #1 from Jakub Jelinek --- This is execute_update_addresses_taken trying to drop address taken from a large/huge _BitInt variable and rewriting it back to SSA. That is undesirable when (cfun->curr_properties & PROP_gimple_lbitint) != 0, because we then no longer lower it again.
[Bug tree-optimization/112307] Segmentation fault with -O1 -fcode-hoisting
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112307 --- Comment #7 from Raffael Casagrande --- @Jonathan Wakely Thanks very much for the detailed analysis. But there is one point which I don't understand: > BUT, the self-referential pointer is set to the address of the range_ member > before the return value is copied, and so goes out of scope when that object > is copied via registers and then copied again into the automatic variable > in main(). I can't follow/understand how Next() is called before the return value is copied. If we look at the constructor of EnumeratorRange, we see that `enumerator_` is initialized before end_reached_. And afterwards the enumerator_ is not moved/copied anymore because of copy elision? This can be verified by adding some extra print statements to the copy/move constructor of Enumerator.
[Bug target/111822] [12/13/14 Regression] during RTL pass: lr_shrinkage ICE: in operator[], at vec.h:910 with -O2 -m32 -flive-range-shrinkage -fno-dce -fnon-call-exceptions since r12-5301-g04520645038
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111822 Uroš Bizjak changed: What|Removed |Added CC||liuhongt at gcc dot gnu.org --- Comment #11 from Uroš Bizjak --- (In reply to Richard Biener from comment #10) > The easiest fix would be to refuse applying STV to a insn that > can_throw_internal () (that's an insn that has associated EH info). Updating > in this case would require splitting the BB or at least moving the now > no longer throwing insn to the next block (along the fallthru edge). This would be simply: --cut here-- diff --git a/gcc/config/i386/i386-features.cc b/gcc/config/i386/i386-features.cc index 1de2a07ed75..90acb33db49 100644 --- a/gcc/config/i386/i386-features.cc +++ b/gcc/config/i386/i386-features.cc @@ -437,6 +437,10 @@ scalar_chain::add_insn (bitmap candidates, unsigned int insn_uid, && !HARD_REGISTER_P (SET_DEST (def_set))) bitmap_set_bit (defs, REGNO (SET_DEST (def_set))); + if (cfun->can_throw_non_call_exceptions + && can_throw_internal (insn)) +return false; + /* ??? The following is quadratic since analyze_register_chain iterates over all refs to look for dual-mode regs. Instead this should be done separately for all regs mentioned in the chain once. */ --cut here-- But I think, we could do better. Adding CC.
[Bug fortran/114283] New: [OpenMP] Dummy procedures/proc pointers and 'defaultmap', 'default', 'firstprivate' etc.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114283
Bug ID: 114283
Summary: [OpenMP] Dummy procedures/proc pointers and
'defaultmap', 'default', 'firstprivate' etc.
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Keywords: openmp
Severity: normal
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: burnus at gcc dot gnu.org
Target Milestone: ---
See also OpenMP specification Issue #3823 [and slightly related PR 114282].
There are two cases:
(A) Dummy procedures
IMHO those aren't variables and gfortran also rejects them when used in
firstprivate, map, shared etc. ("Object 'f1' is not a variable").
However, gfortran does complain with 'default(none)':
Error: 'f1' not specified in enclosing 'target'
Note: 'default(none)' does not diagnose it.
EXPECTED: There is no diagnosis for 'defaultmap(none)'.
(B) Procedure pointers
Here it is unclear whether it should be regarded as variable or not; gfortran
treats those as variables.
Depends on OpenMP specification Issue #3823.
It seems as if handling it as variable, but using 'firstprivate' as default for
implicit mapping makes most sense. – But also treating it as non-variable would
make sense.
[Bug target/111822] [12/13/14 Regression] during RTL pass: lr_shrinkage ICE: in operator[], at vec.h:910 with -O2 -m32 -flive-range-shrinkage -fno-dce -fnon-call-exceptions since r12-5301-g04520645038
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111822 --- Comment #12 from Richard Biener --- (In reply to Uroš Bizjak from comment #11) > (In reply to Richard Biener from comment #10) > > The easiest fix would be to refuse applying STV to a insn that > > can_throw_internal () (that's an insn that has associated EH info). > > Updating > > in this case would require splitting the BB or at least moving the now > > no longer throwing insn to the next block (along the fallthru edge). > > This would be simply: > > --cut here-- > diff --git a/gcc/config/i386/i386-features.cc > b/gcc/config/i386/i386-features.cc > index 1de2a07ed75..90acb33db49 100644 > --- a/gcc/config/i386/i386-features.cc > +++ b/gcc/config/i386/i386-features.cc > @@ -437,6 +437,10 @@ scalar_chain::add_insn (bitmap candidates, unsigned int > insn_uid, >&& !HARD_REGISTER_P (SET_DEST (def_set))) > bitmap_set_bit (defs, REGNO (SET_DEST (def_set))); > > + if (cfun->can_throw_non_call_exceptions that part shouldn't be necessary, can_throw_internal is cheap enough (but yes, unless STV handles calls it's correct) > + && can_throw_internal (insn)) > +return false; > + >/* ??? The following is quadratic since analyze_register_chain > iterates over all refs to look for dual-mode regs. Instead this > should be done separately for all regs mentioned in the chain once. */ > --cut here-- > > But I think, we could do better. Adding CC. We sure could, but I doubt it's too important? Maybe for Go/Ada.
[Bug target/114284] New: [14 Regression] arm: Load of volatile short gets miscompiled (loaded twice)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114284
Bug ID: 114284
Summary: [14 Regression] arm: Load of volatile short gets
miscompiled (loaded twice)
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: acoplan at gcc dot gnu.org
Target Milestone: ---
The following is a wrong code regression in GCC 14:
volatile short x;
short foo() {
return x;
}
with -march=armv8-m.base -O2 on the trunk we get:
foo:
movwr3, #:lower16:.LANCHOR0
movtr3, #:upper16:.LANCHOR0
ldrhr2, [r3]
movsr0, #0
ldrsh r0, [r3, r0]
bx lr
i.e. x is loaded twice, but with GCC 13 we get:
foo:
movwr3, #:lower16:.LANCHOR0
movtr3, #:upper16:.LANCHOR0
ldrhr0, [r3]
sxthr0, r0
bx lr
I suppose ideally we would have just one ldrsh, but the GCC 13 code is OK.
[Bug target/111822] [12/13/14 Regression] during RTL pass: lr_shrinkage ICE: in operator[], at vec.h:910 with -O2 -m32 -flive-range-shrinkage -fno-dce -fnon-call-exceptions since r12-5301-g04520645038
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111822 --- Comment #13 from Uroš Bizjak --- (In reply to Richard Biener from comment #12) > > But I think, we could do better. Adding CC. > > We sure could, but I doubt it's too important? Maybe for Go/Ada. Preloading stuff is simply loading from the same DImode address, so I'd think that EH_NOTE should be moved from the original insn to the new insn without much problems. Please note that on x86_32 split pass is later splitting DImode memory access to two SImode loads, this looks somehow harder problem as far as EH notes are concerned, as the one above. I'm not versed in this area, so I'll leave the fix to someone else.
[Bug target/114284] [14 Regression] arm: Load of volatile short gets miscompiled (loaded twice)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114284 Richard Biener changed: What|Removed |Added Target Milestone|--- |14.0 Priority|P3 |P1 --- Comment #1 from Richard Biener --- fold-mem-offsets pass?
[Bug target/111822] [12/13/14 Regression] during RTL pass: lr_shrinkage ICE: in operator[], at vec.h:910 with -O2 -m32 -flive-range-shrinkage -fno-dce -fnon-call-exceptions since r12-5301-g04520645038
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111822 Richard Biener changed: What|Removed |Added CC||ebotcazou at gcc dot gnu.org --- Comment #14 from Richard Biener --- (In reply to Uroš Bizjak from comment #13) > (In reply to Richard Biener from comment #12) > > > > But I think, we could do better. Adding CC. > > > > We sure could, but I doubt it's too important? Maybe for Go/Ada. > > Preloading stuff is simply loading from the same DImode address, so I'd > think that EH_NOTE should be moved from the original insn to the new insn > without much problems. > > Please note that on x86_32 split pass is later splitting DImode memory > access to two SImode loads, this looks somehow harder problem as far as EH > notes are concerned, as the one above. > > I'm not versed in this area, so I'll leave the fix to someone else. On RTL I'd defer to Eric here. Note for the correctness issue on branches I'd probably prefer the "simple" approach (unless a true solution turns out equally simple).
[Bug tree-optimization/114278] ICE: in extract_bit_field_1, at expmed.cc:1838 with memmove, _BitInt() and -O2 -fno-tree-dce -fno-tree-dse -fno-tree-ccp -m32
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114278 Jakub Jelinek changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org Ever confirmed|0 |1 Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2024-03-08 --- Comment #2 from Jakub Jelinek --- Created attachment 57654 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57654&action=edit gcc14-pr114278.patch Untested fix.
[Bug analyzer/114285] New: Use of uninitialized value when copying a struct field by field
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114285 Bug ID: 114285 Summary: Use of uninitialized value when copying a struct field by field Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: analyzer Assignee: dmalcolm at gcc dot gnu.org Reporter: bouanto at zoho dot com Target Milestone: --- Created attachment 57655 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57655&action=edit Reproducer for the bug Hi. Not sure if it's the same case as the other issues related to -Wanalyzer-use-of-uninitialized-value and I wanted to discuss this anyway. In rustc_codegen_gcc, I can get "use of uninitialized value" when using the Option type, which contains a value and whether there's a value or not. I tried to reproduce in C and I attached the reproducer. Not sure what we should do here. Copying the whole struct doesn't trigger any warning (should it?) and using memcpy doesn't fix the warning. Rust will sometimes copy uninitialized memory and I'd like to avoid disabling this specific warning. Should there be a dinstinction between copying uninitialized memory and using it? What are your thoughts on this? Thanks.
[Bug tree-optimization/114269] [14 Regression] Multiple 3-27% exec time regressions of 434.zeusmp since r14-9193-ga0b1798042d033
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114269
--- Comment #5 from GCC Commits ---
The master branch has been updated by Richard Biener :
https://gcc.gnu.org/g:018ddc86b928514d7dfee024dcdeb204d5dcdd61
commit r14-9391-g018ddc86b928514d7dfee024dcdeb204d5dcdd61
Author: Richard Biener
Date: Fri Mar 8 13:27:12 2024 +0100
tree-optimization/114269 - 434.zeusmp regression after SCEV analysis fix
The following addresses a performance regression caused by the recent
SCEV analysis fix with regard to folding multiplications and undefined
behavior on overflow. We do not handle (T) { a, +, b } * c but can
treat sign-conversions from unsigned by performing the multiplication
in the unsigned type. That's what we already do for additions (but
that misses one case that turns out important).
This fixes the 434.zeusmp regression for me.
PR tree-optimization/114269
PR tree-optimization/114074
* tree-chrec.cc (chrec_fold_plus_1): Handle sign-conversions
in the third CASE_CONVERT case as well.
(chrec_fold_multiply): Handle sign-conversions from unsigned
by performing the operation in the unsigned type.
[Bug tree-optimization/114074] [11/12/13 Regression] wrong code at -O1 and above on x86_64-linux-gnu since r8-343
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114074
--- Comment #11 from GCC Commits ---
The master branch has been updated by Richard Biener :
https://gcc.gnu.org/g:018ddc86b928514d7dfee024dcdeb204d5dcdd61
commit r14-9391-g018ddc86b928514d7dfee024dcdeb204d5dcdd61
Author: Richard Biener
Date: Fri Mar 8 13:27:12 2024 +0100
tree-optimization/114269 - 434.zeusmp regression after SCEV analysis fix
The following addresses a performance regression caused by the recent
SCEV analysis fix with regard to folding multiplications and undefined
behavior on overflow. We do not handle (T) { a, +, b } * c but can
treat sign-conversions from unsigned by performing the multiplication
in the unsigned type. That's what we already do for additions (but
that misses one case that turns out important).
This fixes the 434.zeusmp regression for me.
PR tree-optimization/114269
PR tree-optimization/114074
* tree-chrec.cc (chrec_fold_plus_1): Handle sign-conversions
in the third CASE_CONVERT case as well.
(chrec_fold_multiply): Handle sign-conversions from unsigned
by performing the operation in the unsigned type.
[Bug middle-end/26163] [meta-bug] missed optimization in SPEC (2k17, 2k and 2k6 and 95)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=26163 Bug 26163 depends on bug 114269, which changed state. Bug 114269 Summary: [14 Regression] Multiple 3-27% exec time regressions of 434.zeusmp since r14-9193-ga0b1798042d033 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114269 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED
[Bug tree-optimization/114269] [14 Regression] Multiple 3-27% exec time regressions of 434.zeusmp since r14-9193-ga0b1798042d033
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114269 Richard Biener changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #6 from Richard Biener --- For me this is fixed on Zen2 with -Ofast -march=native.
[Bug libstdc++/63400] [C++11]precision of std::chrono::high_resolution_clock
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63400 --- Comment #13 from Vadim Zeitlin --- (In reply to Jonathan Wakely from comment #11) > (In reply to Jonathan Wakely from comment #8) > > Is this still an issue in 2022? > > > > Using a mingw-w64 cross-compiler and running under Wine I get: > > > > CLOCK_REALTIME: 0,100 > > CLOCK_MONOTONIC: 0,100 > > > > Is that just because I'm using Wine not real Windows? > > I still want an answer to this question though. FWIW I can confirm that running the program above compiled with gcc-mingw-w64 12.2.0-14+25.2 from Debian 12 under Windows 10.0.19044.3803 produces exactly the same output.
[Bug tree-optimization/114238] [14 regression] Multiple 554.roms_r run-time regressions (4%-20%) since r14-9193-ga0b1798042d033
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114238 Richard Biener changed: What|Removed |Added Resolution|--- |FIXED Status|UNCONFIRMED |RESOLVED --- Comment #1 from Richard Biener --- r14-9391-g018ddc86b92851 fixed this on Zen2 for me as well.
[Bug middle-end/26163] [meta-bug] missed optimization in SPEC (2k17, 2k and 2k6 and 95)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=26163 Bug 26163 depends on bug 114238, which changed state. Bug 114238 Summary: [14 regression] Multiple 554.roms_r run-time regressions (4%-20%) since r14-9193-ga0b1798042d033 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114238 What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED
[Bug ipa/113996] [11/12/13/14 Regression] ICE with LTO at -O2 and above with some Ada code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113996 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org Priority|P1 |P2 --- Comment #4 from Jakub Jelinek --- Ada is not primary FE and this is not a recent regression.
[Bug tree-optimization/114151] [14 Regression] weird and inefficient codegen and addressing modes since r14-9193
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114151 --- Comment #18 from Richard Biener --- r14-9391-g018ddc86b92851 doesn't seem to make a difference for this aarch64 IVOPTs case. It might be that tree-affine.cc needs similar handling. I'm going to dig into that on Monday.
[Bug analyzer/114285] Use of uninitialized value when copying a struct field by field
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114285 --- Comment #1 from Richard Biener --- Given GCC considers memory to be initialized when you write to it and copying from A to B involves a write to B the uninit info would be lost if A is uninitialized. So IMO it's reasonable to diagnose a copy from uninitialized, at least unless you can fully analyze all possible uses of B (which, when B is memory is unlikely). Note that's not the analyzer-specific opinion but viewed from the -Wuninitialized implementation point of view.
[Bug target/114233] Newly-introduced pr113617.C test fails on Darwin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114233
--- Comment #6 from GCC Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:8263a4b6505f84973c2ed2fb8d4f2036ca335ff3
commit r14-9392-g8263a4b6505f84973c2ed2fb8d4f2036ca335ff3
Author: Jakub Jelinek
Date: Fri Mar 8 15:18:56 2024 +0100
testsuite: Fix up pr113617 test for darwin [PR113617]
The test attempts to link a shared library, and apparently Darwin doesn't
allow by default for shared libraries to contain undefined symbols.
The following patch just adds dummy definitions for the symbols, so that
the library no longer has any undefined symbols at least in my linux
testing.
Furthermore, for target { !shared } targets (like darwin until the it is
fixed in target-supports.exp), because we then link a program rather than
shared library, the patch also adds a dummy main definition so that it
can link.
2024-03-08 Jakub Jelinek
PR rtl-optimization/113617
PR target/114233
* g++.dg/other/pr113617.C: Define -DSHARED when linking with
-shared.
* g++.dg/other/pr113617-aux.cc: Add definitions for used methods
and
templates not defined elsewhere.
[Bug rtl-optimization/113617] [14 Regression] Symbol ... referenced in section `.data.rel.ro.local' of ...: defined in discarded section ... since r14-4944
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113617
--- Comment #27 from GCC Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:8263a4b6505f84973c2ed2fb8d4f2036ca335ff3
commit r14-9392-g8263a4b6505f84973c2ed2fb8d4f2036ca335ff3
Author: Jakub Jelinek
Date: Fri Mar 8 15:18:56 2024 +0100
testsuite: Fix up pr113617 test for darwin [PR113617]
The test attempts to link a shared library, and apparently Darwin doesn't
allow by default for shared libraries to contain undefined symbols.
The following patch just adds dummy definitions for the symbols, so that
the library no longer has any undefined symbols at least in my linux
testing.
Furthermore, for target { !shared } targets (like darwin until the it is
fixed in target-supports.exp), because we then link a program rather than
shared library, the patch also adds a dummy main definition so that it
can link.
2024-03-08 Jakub Jelinek
PR rtl-optimization/113617
PR target/114233
* g++.dg/other/pr113617.C: Define -DSHARED when linking with
-shared.
* g++.dg/other/pr113617-aux.cc: Add definitions for used methods
and
templates not defined elsewhere.
[Bug other/109668] 'python' vs. 'python3'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109668 --- Comment #5 from GCC Commits --- The master branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:64273a7e6bd8ba60058174d147521dd65d705637 commit r14-9393-g64273a7e6bd8ba60058174d147521dd65d705637 Author: Sam James Date: Fri Mar 8 15:24:20 2024 +0100 contrib: Improve dg-extract-results.sh's Python detection [PR109668] 'python' on some systems (e.g. SLES 15) might be Python 2. Prefer python3, then python, then python2 (as the script still tries to work there). PR other/109668 * dg-extract-results.sh: Check for python3 before python. Check for python2 last.
[Bug tree-optimization/112307] Segmentation fault with -O1 -fcode-hoisting
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112307 --- Comment #8 from Jonathan Wakely --- I explained this in PR 109945 comment 25 There is no guaranteed copy elision for objects with a trivial copy constructor and trivial (or deleted) destructor. The compiler is allowed to make temporary copies, to allow passing the object in registers (which has been what the ABI requires for decades longer than the guaranteed copy elision rules have existed). If you want to have self-referential pointers in your object then you need to ensure copies really are elided. And so it should not be trivially copyable, because that removes the guarantee of copy elision.
[Bug target/114284] [14 Regression] arm: Load of volatile short gets miscompiled (loaded twice) since r14-8319
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114284 Jakub Jelinek changed: What|Removed |Added Summary|[14 Regression] arm: Load |[14 Regression] arm: Load |of volatile short gets |of volatile short gets |miscompiled (loaded twice) |miscompiled (loaded twice) ||since r14-8319 Ever confirmed|0 |1 Last reconfirmed||2024-03-08 Status|UNCONFIRMED |NEW CC||jakub at gcc dot gnu.org --- Comment #2 from Jakub Jelinek --- No, started with r14-8319-g86de9b66480b710202a2898cf513db105d8c432f
[Bug tree-optimization/112307] Segmentation fault with -O1 -fcode-hoisting
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112307 --- Comment #9 from Jonathan Wakely --- Ironically, writing a user-provided (and so non-trivial) copy constructor which fixes up the self-referential pointer (or iterator, in your case) will restore guaranteed elision, and that copy constructor isn't actually used. But with a trivial copy constructor, your object gets copied, and the self-referential pointer gets invalidated because it points to a temporary that has gone out of scope, not to the final object after the copies are done.
[Bug libstdc++/63400] [C++11]precision of std::chrono::high_resolution_clock
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63400 --- Comment #14 from Jonathan Wakely --- Thanks! So does that mean mingw-w64 fixed the issue by improving the resolution of CLOCK_REALTIME? In that case, this bug could be closed WORKSFORME. Or maybe the testcase makes invalid assumptions and isn't really measuring what it thinks it's measuring? In any case, we might want to keep it open to track the suggestion of using GetSystemTimePreciseAsFileTime for utc_clock, as an enhancement.
[Bug libstdc++/63400] [C++11]precision of std::chrono::high_resolution_clock
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63400 --- Comment #15 from Jonathan Wakely --- (In reply to Jonathan Wakely from comment #14) > Or maybe the testcase makes invalid assumptions and isn't really measuring > what it thinks it's measuring? e.g. maybe clock_getres says 100ns even though the clocks aren't really that precise.
[Bug target/112548] [14 regression] 5% exec time regression in 429.mcf on AMD zen4 CPU (since r14-5076-g01c18f58d37865)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112548 --- Comment #7 from Robin Dapp --- I built executables with and without the commit (-Ofast -march=znver4 -flto). There is no difference so it must really be something that happens with PGO. I'd really need access to a zen4 box or the pgo executables at least.
[Bug analyzer/114286] New: ICE: in deref_rvalue, at analyzer/region-model.cc:2762 with _Atomic _BitInt() and -fanalyzer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114286 Bug ID: 114286 Summary: ICE: in deref_rvalue, at analyzer/region-model.cc:2762 with _Atomic _BitInt() and -fanalyzer Product: gcc Version: 14.0 Status: UNCONFIRMED Keywords: ice-on-valid-code Severity: normal Priority: P3 Component: analyzer Assignee: dmalcolm at gcc dot gnu.org Reporter: zsojka at seznam dot cz CC: jakub at gcc dot gnu.org Target Milestone: --- Host: x86_64-pc-linux-gnu Target: x86_64-pc-linux-gnu Created attachment 57656 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57656&action=edit reduced testcase Compiler output: $ x86_64-pc-linux-gnu-gcc -fanalyzer testcase.c during IPA pass: analyzer testcase.c: In function 'foo': testcase.c:5:3: internal compiler error: in deref_rvalue, at analyzer/region-model.cc:2762 5 | b; | ^ 0x8c81ff ana::region_model::deref_rvalue(ana::svalue const*, tree_node*, ana::region_model_context*, bool) const /repo/gcc-trunk/gcc/analyzer/region-model.cc:2762 0x192a209 ana::kf_atomic_load::impl_call_pre(ana::call_details const&) const /repo/gcc-trunk/gcc/analyzer/kf.cc:289 0x19464f7 ana::region_model::on_call_pre(gcall const*, ana::region_model_context*) /repo/gcc-trunk/gcc/analyzer/region-model.cc:1700 0x194a31a ana::region_model::on_stmt_pre(gimple const*, bool*, ana::region_model_context*) /repo/gcc-trunk/gcc/analyzer/region-model.cc:1337 0x1912190 ana::exploded_node::on_stmt(ana::exploded_graph&, ana::supernode const*, gimple const*, ana::program_state*, ana::uncertainty_t*, bool*, ana::path_context*) /repo/gcc-trunk/gcc/analyzer/engine.cc:1515 0x1914f2a ana::exploded_graph::process_node(ana::exploded_node*) /repo/gcc-trunk/gcc/analyzer/engine.cc:4125 0x1915e9a ana::exploded_graph::process_worklist() /repo/gcc-trunk/gcc/analyzer/engine.cc:3516 0x19185f5 ana::impl_run_checkers(ana::logger*) /repo/gcc-trunk/gcc/analyzer/engine.cc:6210 0x1919506 ana::run_checkers() /repo/gcc-trunk/gcc/analyzer/engine.cc:6301 0x1908158 execute /repo/gcc-trunk/gcc/analyzer/analyzer-pass.cc:87 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. $ x86_64-pc-linux-gnu-gcc -v Using built-in specs. COLLECT_GCC=/repo/gcc-trunk/binary-latest-amd64/bin/x86_64-pc-linux-gnu-gcc COLLECT_LTO_WRAPPER=/repo/gcc-trunk/binary-trunk-r14-9382-20240308082802-g0bd04d9ae2d-checking-yes-rtl-df-extra-nobootstrap-amd64/bin/../libexec/gcc/x86_64-pc-linux-gnu/14.0.1/lto-wrapper Target: x86_64-pc-linux-gnu Configured with: /repo/gcc-trunk//configure --enable-languages=c,c++ --enable-valgrind-annotations --disable-nls --enable-checking=yes,rtl,df,extra --disable-bootstrap --with-cloog --with-ppl --with-isl --build=x86_64-pc-linux-gnu --host=x86_64-pc-linux-gnu --target=x86_64-pc-linux-gnu --with-ld=/usr/bin/x86_64-pc-linux-gnu-ld --with-as=/usr/bin/x86_64-pc-linux-gnu-as --enable-libsanitizer --disable-libstdcxx-pch --prefix=/repo/gcc-trunk//binary-trunk-r14-9382-20240308082802-g0bd04d9ae2d-checking-yes-rtl-df-extra-nobootstrap-amd64 Thread model: posix Supported LTO compression algorithms: zlib zstd gcc version 14.0.1 20240308 (experimental) (GCC)
[Bug tree-optimization/114287] New: [13.2.1 Regression] 416.gamess in SPEC CPU 2006 miscompiled
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114287 Bug ID: 114287 Summary: [13.2.1 Regression] 416.gamess in SPEC CPU 2006 miscompiled Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: manolis.tsamis at vrull dot eu Target Milestone: --- On Linux/AArch64, 416.gamess from SPEC2006 is miscompiled: Contents of h2ocu2+.gradient.err Note: The following floating-point exceptions are signalling: IEEE_UNDERFLOW_FLAG STOP IN ABRT Contents of triazolium.err STOP IN ABRT When compiled with: -g -O2 -flto=32 -fno-strict-aliasing Compiles fine with GCC 13.2.1. GCC master built from commit d1b241b9506cdc0ebd3f43d12cf77d7c33271342, configured with: --enable-shared, --enable-threads=posix, --enable-checking=release, --enable-linker-build-id, --enable-plugin, --with-isl, --enable-lto
[Bug ipa/108802] [11/12/13/14 Regression] missed inlining of call via pointer to member function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108802 --- Comment #8 from Martin Jambor --- I have proposed an improved patch on the mailing list: https://inbox.sourceware.org/gcc-patches/ri6r0gkzvi4@virgil.suse.cz/T/#u
[Bug ipa/114254] [11/12/13/14 regression] Indirect inlining through C++ member pointers fails if the underlying class has a virtual function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114254 --- Comment #1 from Martin Jambor --- I have proposed a patch on the mailing list: https://inbox.sourceware.org/gcc-patches/ri6r0gkzvi4@virgil.suse.cz/T/#u
[Bug target/114288] New: [14 regression] ICE when building binutils-2.41 on hppa (extract_constrain_insn, at recog.cc:2713)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114288
Bug ID: 114288
Summary: [14 regression] ICE when building binutils-2.41 on
hppa (extract_constrain_insn, at recog.cc:2713)
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: sjames at gcc dot gnu.org
CC: danglin at gcc dot gnu.org
Target Milestone: ---
Created attachment 57657
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57657&action=edit
alpha.i.xz
```
hppa2.0-unknown-linux-gnu-gcc -DHAVE_CONFIG_H -I.
-I/var/tmp/portage/sys-devel/binutils-2.41-r3/work/binutils-2.41/gprof -DDEBUG
-I../bfd
-I/var/tmp/portage/sys-devel/binutils-2.41-r3/work/binutils-2.41/gprof/../include
-I/var/tmp/portage/sys-devel/binutils-2.41-r3/work/binutils-2.41/gprof/../bfd
-I.
-DLOCALEDIR="\"/usr/share/binutils-data/hppa2.0-unknown-linux-gnu/2.41/locale\""
-W -Wall -Wstrict-prototypes -Wmissing-prototypes -Wshadow
-Wstack-usage=262144 -O2 -pipe -march=2.0 -fdiagnostics-color=always
-frecord-gcc-switches -ggdb3 -Wno-error=implicit-function-declaration -c -o
alpha.o
/var/tmp/portage/sys-devel/binutils-2.41-r3/work/binutils-2.41/gprof/alpha.c
/var/tmp/portage/sys-devel/binutils-2.41-r3/work/binutils-2.41/gprof/alpha.c:
In function 'alpha_find_call':
/var/tmp/portage/sys-devel/binutils-2.41-r3/work/binutils-2.41/gprof/alpha.c:176:1:
error: insn does not satisfy its constraints:
176 | }
| ^
(insn 545 40 546 3 (set (reg:SI 22 %r22)
(reg/f:SI 259))
"/var/tmp/portage/sys-devel/binutils-2.41-r3/work/binutils-2.41/gprof/alpha.c":103:36
42 {*pa.md:2195}
(nil))
during RTL pass: postreload
/var/tmp/portage/sys-devel/binutils-2.41-r3/work/binutils-2.41/gprof/alpha.c:176:1:
internal compiler error: in extract_constrain_insn, at recog.cc:2713
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
See
[Bug target/114288] [14 regression] ICE when building binutils-2.41 on hppa (extract_constrain_insn, at recog.cc:2713)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114288 --- Comment #1 from Sam James --- 'gcc -c alpha.i -O2' is enough for me to reproduce.
[Bug debug/113777] ICE: in add_child_die_after, at dwarf2out.cc:5785 with -g -fsso-struct=big-endian and __attribute__((__hardbool__))
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113777 --- Comment #1 from Alexandre Oliva --- Eric, I think this is yours. It fails while trying to add a reversed version of the hbool type to the context of the struct, but the struct doesn't have children yet, and add_child_die_after requires the context to have children already. The assumption that the original, unreversed type was introduced in the same context doesn't hold.
[Bug target/114284] [14 Regression] arm: Load of volatile short gets miscompiled (loaded twice) since r14-8319
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114284 --- Comment #3 from Alex Coplan --- I think this has been fixed by r14-9379-ga0e945888d973fc1a4a9d2944aa7e96d2a4d7581
[Bug target/114284] [14 Regression] arm: Load of volatile short gets miscompiled (loaded twice) since r14-8319
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114284
--- Comment #4 from Jakub Jelinek ---
+propagating insn 6 into insn 8, replacing:
+(parallel [
+(set (reg:SI 114 [ ])
+(sign_extend:SI (subreg:HI (reg:SI 117 [ x ]) 0)))
+(clobber (scratch:SI))
+])
+successfully matched this instruction to thumb1_extendhisi2:
+(parallel [
+(set (reg:SI 114 [ ])
+(sign_extend:SI (mem/v/c:HI (reg/f:SI 115) [1 x+0 S2 A16])))
+(clobber (scratch:SI))
+])
I believe before that change we'd never propagate MEM/v, classify_result even
correctly explains why:
4) Creating new (mem/v)s is not correct, since DCE will not remove the old
ones.
But now that fwprop just ignores that or takes it as a slight hint, we get the
invalid change.
I'd actually say all the 4 reasons why it shouldn't be propagating MEMs should
result in don't actually propagate it rather than just a mere hint:
/* Allow (subreg (mem)) -> (mem) simplifications with the following
exceptions:
1) Propagating (mem)s into multiple uses is not profitable.
2) Propagating (mem)s across EBBs may not be profitable if the source EBB
runs less frequently.
3) Propagating (mem)s into paradoxical (subreg)s is not profitable.
4) Creating new (mem/v)s is not correct, since DCE will not remove the old
ones. */
and punt maybe also on propagating any other MEMs into insns.
Though, when check_mem is called, it is called only on the MEMs which are being
propagated, so not sure how to actually check it in there.
Doing
--- a/gcc/fwprop.cc
+++ b/gcc/fwprop.cc
@@ -211,6 +211,11 @@ fwprop_propagation::fwprop_propagation (insn_info
*use_insn,
bool
fwprop_propagation::check_mem (int old_num_changes, rtx mem)
{
+ if (MEM_VOLATILE_P (mem))
+{
+ failure_reason = "would propagate volatile MEM";
+ return false;
+}
if (!memory_address_addr_space_p (GET_MODE (mem), XEXP (mem, 0),
MEM_ADDR_SPACE (mem)))
{
doesn't really help, so perhaps I misunderstand what is check_mem used for.
[Bug libstdc++/63400] [C++11]precision of std::chrono::high_resolution_clock
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63400
--- Comment #16 from Vadim Zeitlin ---
(In reply to Jonathan Wakely from comment #15)
> (In reply to Jonathan Wakely from comment #14)
> > Or maybe the testcase makes invalid assumptions and isn't really measuring
> > what it thinks it's measuring?
>
> e.g. maybe clock_getres says 100ns even though the clocks aren't really that
> precise.
No, the clock is not precise. The original test case
int main() {
for (unsigned long long size = 1; size < 1000; size *= 10) {
auto start = std::chrono::high_resolution_clock::now();
std::vector v(size, 42);
auto end = std::chrono::high_resolution_clock::now();
auto elapsed = end - start;
std::cout << size << ": " << elapsed.count() << '\n';
}
}
outputs the following under Linux
% ./a.out
1: 436
10: 114
100: 80
1000: 1019
1: 9499
10: 104850
100: 686436
and this under Windows:
% ./a.exe
1: 1000
10: 0
100: 0
1000: 1000
1: 9000
10: 69000
100: 523000
[Bug target/113915] [14 regression] glibc's _dl_find_object_update_1 miscompiled for armv7a since r14-4365-g0731889c026bfe
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113915 --- Comment #16 from GCC Commits --- The master branch has been updated by Wilco Dijkstra : https://gcc.gnu.org/g:5119c7927c70b02ab9768b30f40564480f556432 commit r14-9394-g5119c7927c70b02ab9768b30f40564480f556432 Author: Wilco Dijkstra Date: Fri Mar 8 15:01:15 2024 + ARM: Fix builtin-bswap-1.c test [PR113915] On Thumb-2 the use of CBZ blocks conditional execution, so change the test to compare with a non-zero value. gcc/testsuite/ChangeLog: PR target/113915 * gcc.target/arm/builtin-bswap.x: Fix test to avoid emitting CBZ.
[Bug target/114284] [14 Regression] arm: Load of volatile short gets miscompiled (loaded twice) since r14-8319
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114284 --- Comment #5 from Jakub Jelinek --- (In reply to Alex Coplan from comment #3) > I think this has been fixed by > r14-9379-ga0e945888d973fc1a4a9d2944aa7e96d2a4d7581 Maybe the volatile MEM case yes, but I don't see how it would avoid the undesirable MEM propagation when it is used multiple times, across EBBs or into paradoxical subregs.
[Bug analyzer/114285] Use of uninitialized value when copying a struct field by field
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114285 --- Comment #2 from David Malcolm --- (In reply to Antoni from comment #0) > Created attachment 57655 [details] > Reproducer for the bug [...] > I tried to reproduce in C and I attached the reproducer. Trunk with -fanalyzer: https://godbolt.org/z/847M165zf
[Bug c++/114275] using std::thread within a templated function in a module fails to compile
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114275
--- Comment #3 from Patrick Palka ---
PR105320 seems similar.
Another maybe related testcase:
$ cat testcase.C
export module M;
template struct A {
template friend struct B;
};
A a;
template struct B { };
$ cat testcase.C | g++ -fmodules-ts -x c++ -
:6:27: error: cannot declare ‘struct B< >’ in a
different module
:3:34: note: declared here
:1:8: warning: not writing module ‘M’ due to errors
[Bug tree-optimization/112307] Segmentation fault with -O1 -fcode-hoisting
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112307 --- Comment #10 from Raffael Casagrande --- (In reply to Jonathan Wakely from comment #9) Thanks very much! I missed the part with the trivial copy constructor and learned again an important lesson. That explains why it works when I defined the copy constructors manually.
[Bug target/114288] [14 regression] ICE when building binutils-2.41 on hppa (extract_constrain_insn, at recog.cc:2713)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114288 Jeffrey A. Law changed: What|Removed |Added Priority|P3 |P4 CC||law at gcc dot gnu.org
[Bug tree-optimization/114287] [13.2.1 Regression] 416.gamess in SPEC CPU 2006 miscompiled
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114287 Jeffrey A. Law changed: What|Removed |Added Priority|P3 |P1 CC||law at gcc dot gnu.org
[Bug target/114059] ICE in extract_insn, at recog.cc:2812 | sme2 vs -fsanitize=address -mtrack-speculation -fharden-control-flow-redundancy
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114059 --- Comment #1 from Alexandre Oliva --- ISTM that -fharden-control-flow-redundancy is only instrumental to trigger the latent problem, but the real problem is in the back end: aarch64_restore_za emits a aarch64_cbnedi1 unconditionally, but insn aarch64_cb1 is disabled on aarch64_track_speculation, which the test uses.
[Bug analyzer/114286] ICE: in deref_rvalue, at analyzer/region-model.cc:2762 with _Atomic _BitInt() and -fanalyzer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114286 Jeffrey A. Law changed: What|Removed |Added CC||law at gcc dot gnu.org Priority|P3 |P1
[Bug fortran/114280] ASSOCIATE fails with inquiry references when selector function not yet parsed.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114280 Jeffrey A. Law changed: What|Removed |Added CC||law at gcc dot gnu.org Priority|P3 |P4
[Bug tree-optimization/114278] ICE: in extract_bit_field_1, at expmed.cc:1838 with memmove, _BitInt() and -O2 -fno-tree-dce -fno-tree-dse -fno-tree-ccp -m32
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114278 Jeffrey A. Law changed: What|Removed |Added CC||law at gcc dot gnu.org Priority|P3 |P1
[Bug c++/114275] using std::thread within a templated function in a module fails to compile
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114275 Jeffrey A. Law changed: What|Removed |Added CC||law at gcc dot gnu.org Priority|P3 |P2
[Bug ipa/114274] ICE: tree check: expected block, have ggc_freed in inlining_chain_to_json, at optinfo-emit-json.cc:284 with -fsave-optimization-record
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114274 Jeffrey A. Law changed: What|Removed |Added Priority|P3 |P1 CC||law at gcc dot gnu.org
[Bug tree-optimization/110540] [14 Regression] Dead Code Elimination Regression since r14-1163-gd8b058d3ca4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110540 Jeffrey A. Law changed: What|Removed |Added Priority|P3 |P2 CC||law at gcc dot gnu.org
[Bug tree-optimization/110538] [14 Regression] Dead Code Elimination Regression since r14-368-ge1366a7e4ce
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110538 Jeffrey A. Law changed: What|Removed |Added CC||law at gcc dot gnu.org Priority|P3 |P2
[Bug tree-optimization/110503] [13/14 Regression] Dead Code Elimination Regression at -O3 since r13-322-g7f04b0d786e
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110503 Jeffrey A. Law changed: What|Removed |Added CC||law at gcc dot gnu.org Priority|P3 |P2
[Bug tree-optimization/110502] [14 Regression] Dead Code Elimination Regression at -Os since r14-1656-g55fcaa9a8bd
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110502 Jeffrey A. Law changed: What|Removed |Added CC||law at gcc dot gnu.org Priority|P3 |P2
[Bug tree-optimization/110458] [14 Regression] -Warray-bounds=2 new false positive
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110458 Jeffrey A. Law changed: What|Removed |Added Priority|P3 |P2 CC||law at gcc dot gnu.org
[Bug tree-optimization/110414] [14 Regression] Dead Code Elimination Regression since r14-1127-g9e2017ae6ac
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110414 Jeffrey A. Law changed: What|Removed |Added CC||law at gcc dot gnu.org Priority|P3 |P2
[Bug target/113790] [14 Regression][riscv64] ICE in curr_insn_transform, at lra-constraints.cc:4294 since r14-4944-gf55cdce3f8dd85
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113790 Vladimir Makarov changed: What|Removed |Added CC||vmakarov at gcc dot gnu.org --- Comment #1 from Vladimir Makarov --- I've reproduced it and started to work on it. I hope to fix it today or on Monday.
[Bug tree-optimization/110361] [13/14 Regression] Missed Dead Code Elimination when using __builtin_unreachable since r13-2020-g16b013c9d9b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110361 Jeffrey A. Law changed: What|Removed |Added Priority|P3 |P2 CC||law at gcc dot gnu.org
