[Bug tree-optimization/94043] [9 Regression] ICE in superloop_at_depth, at cfgloop.c:78
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94043 Richard Biener changed: What|Removed |Added Priority|P3 |P2 Known to work||10.0 Summary|[9/10 Regression] ICE in|[9 Regression] ICE in |superloop_at_depth, at |superloop_at_depth, at |cfgloop.c:78|cfgloop.c:78 Status|RESOLVED|ASSIGNED Resolution|FIXED |--- --- Comment #20 from Richard Biener --- Re-open. It's marked as broken in GCC 9 so a backport is in oder (if the issue really reproduces there).
[Bug c++/42633] hinting gcc that restricted pointer dont alias with members of structs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=42633 Richard Biener changed: What|Removed |Added Known to fail||4.6.4 Known to work||4.7.0 Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #6 from Richard Biener --- It's already fixed, since GCC 4.7.
[Bug middle-end/49774] [meta-bug] restrict qualification aliasing issues
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49774 Bug 49774 depends on bug 42633, which changed state. Bug 42633 Summary: hinting gcc that restricted pointer dont alias with members of structs https://gcc.gnu.org/bugzilla/show_bug.cgi?id=42633 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED
[Bug tree-optimization/94427] 456.hmmer is 8-17% slower when compiled at -Ofast than with GCC 9
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94427 --- Comment #2 from Richard Biener --- The hot/cold thing smells like PR90911 btw. The cmov thing you identified is PR91154 which was fixed for archs that can do the required SSE min/max operation which is SSE 4.1 IIRC. It also is then a "duplicate" of the (various?) bugs about to-cmov-or-not-to-cmov where the microarchitectural details are unclear. So I fear with just SSE2 we can't do anything here but apply yet another heuristic special to hmmer that will likely hurt another case (there are corresponding bugs asking for _more_ cmov...). One of my first patches was to notice the special constant for the max/min operation and not do conditional move expansion (plus prevent later RTL ifcvt to apply with the same heuristics).
[Bug tree-optimization/94043] [9/10 Regression] ICE in superloop_at_depth, at cfgloop.c:78
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94043 Kewen Lin changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #19 from Kewen Lin --- should be fixed on trunk now.
[Bug tree-optimization/94043] [9/10 Regression] ICE in superloop_at_depth, at cfgloop.c:78
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94043 --- Comment #18 from CVS Commits --- The master branch has been updated by Kewen Lin : https://gcc.gnu.org/g:bd0f22a8d5caea8905f38ff1fafce31c1b7d33ad commit r10-7491-gbd0f22a8d5caea8905f38ff1fafce31c1b7d33ad Author: Kewen Lin Date: Tue Mar 31 22:48:46 2020 -0500 Fix PR94043 by making vect_live_op generate lc-phi As PR94043 shows, my commit r10-4524 exposed one issue in vectorizable_live_operation, which inserts one extra BB before the single exit, leading unexpected operand expansion and unexpected loop depth assertion. As Richi suggested, this patch is to teach vectorizable_live_operation to generate loop closed phi for vec_lhs, it looks like: loop; # lhs' = PHI => loop; # vec_lhs' = PHI new_tree = BIT_FIELD_REF ; lhs' = new_tree; I noticed that there are some SLP cases that have same lhs and vec_lhs but different offsets, which can make us have more PHIs for the same vec_lhs there. But I think it would be fine since only one of them is actually live, the others should be eliminated by the following dce. So the patch doesn't check whether there is one phi for vec_lhs, just create one directly instead. Bootstrapped/regtested on powerpc64le-linux-gnu (LE) P8. 2020-04-01 Kewen Lin gcc/ChangeLog PR tree-optimization/94043 * tree-vect-loop.c (vectorizable_live_operation): Generate loop-closed phi for vec_lhs and use it for lane extraction. gcc/testsuite/ChangeLog PR tree-optimization/94043 * gfortran.dg/graphite/vect-pr94043.f90: New test.
[Bug c++/94205] [8/9/10 Regression] ICE in cxx_eval_constant_expression with 'this'-capturing lambda inside an NSDMI since r8-1251
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94205 --- Comment #3 from CVS Commits --- The master branch has been updated by Jason Merrill : https://gcc.gnu.org/g:76f09260b7eccd6c3cfa3dcf3c22897fe12a8065 commit r10-7490-g76f09260b7eccd6c3cfa3dcf3c22897fe12a8065 Author: Jason Merrill Date: Tue Mar 31 17:34:47 2020 -0400 c++: Fix DMI with lambda 'this' capture [PR94205] We represent 'this' in a default member initializer with a PLACEHOLDER_EXPR. Normally in constexpr evaluation when we encounter one it refers to ctx->ctor, but when we're creating a temporary of class type, that replaces ctx->ctor, so a PLACEHOLDER_EXPR that refers to the type of the member being initialized needs to be replaced before that happens. gcc/cp/ChangeLog 2020-03-31 Jason Merrill PR c++/94205 * constexpr.c (cxx_eval_constant_expression) [TARGET_EXPR]: Call replace_placeholders. * typeck2.c (store_init_value): Fix arguments to fold_non_dependent_expr.
[Bug other/1] Test of new GCC GNATS db.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=1 --- Comment #6 from CVS Commits --- The releases/gcc-9 branch has been updated by GCC Administrator : https://gcc.gnu.org/g:2594e9a069698d99ac5a012f3189288e19a5094b commit r9-8428-g2594e9a069698d99ac5a012f3189288e19a5094b Author: GCC Administrator Date: Wed Apr 1 00:17:49 2020 + Daily bump.
[Bug other/1] Test of new GCC GNATS db.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=1 --- Comment #5 from CVS Commits --- The releases/gcc-8 branch has been updated by GCC Administrator : https://gcc.gnu.org/g:bfdb0a856a157dadfa127b77ac794d0d175c18c4 commit r8-10155-gbfdb0a856a157dadfa127b77ac794d0d175c18c4 Author: GCC Administrator Date: Wed Apr 1 00:17:16 2020 + Daily bump.
[Bug other/1] Test of new GCC GNATS db.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=1 --- Comment #4 from CVS Commits --- The master branch has been updated by GCC Administrator : https://gcc.gnu.org/g:73dd051894b8293d35ea1c436fa408c404b80813 commit r10-7488-g73dd051894b8293d35ea1c436fa408c404b80813 Author: GCC Administrator Date: Wed Apr 1 00:16:38 2020 + Daily bump.
[Bug fortran/94348] gfortran 8/9 reject module procedure definition in same module as function interface
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94348 --- Comment #6 from Damian Rouson --- Thanks, Tobias!
[Bug target/87583] error: unrecognizable insn on ppc64le
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87583 Carl Love changed: What|Removed |Added Status|NEW |RESOLVED CC||carll at gcc dot gnu.org Resolution|--- |FIXED --- Comment #8 from Carl Love --- The issue was fixed with a patch to mainline, backported to GCC 8 and 9
[Bug target/93819] PPC64 builtin vec_rlnm() argument order is wrong.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93819 Carl Love changed: What|Removed |Added Status|RESOLVED|CLOSED --- Comment #8 from Carl Love --- Closing
[Bug target/93819] PPC64 builtin vec_rlnm() argument order is wrong.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93819 Carl Love changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #7 from Carl Love --- Patch submitted to mainline and backported to gcc 9 and 8.
[Bug tree-optimization/94427] 456.hmmer is 8-17% slower when compiled at -Ofast than with GCC 9
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94427 --- Comment #1 from Martin Jambor --- OK, so it turns out the identified commit only allows us to shoot ourselves in the foot - and there one too few branches, not too many. The hottest loop, consuming most of the time is: Percent Instructions 0.03 │ fb0:┌─+add -0x8(%r9,%rcx,4),%eax 5.03 │ │ mov %eax,-0x4(%r13,%rcx,4) 2.48 │ │ mov -0x8(%r8,%rcx,4),%esi 0.02 │ │ add -0x8(%rdx,%rcx,4),%esi 0.06 │ │ cmp %eax,%esi 4.49 │ │ cmovge %esi,%eax 17.17 │ │ mov %ecx,%esi 0.03 │ │ cmp $0xc521974f,%eax 3.50 │ │ cmovl %ebx,%eax <--- this used to be a branch 21.84 │ │ mov %eax,-0x4(%r13,%rcx,4) 3.88 │ │ add $0x1,%rcx 0.00 │ │ cmp %rdi,%rcx 0.04 │ └──jne fb0 where the marked conditional move was a branch one revision before, because, after fwprop3 the IL looked like: [local count: 955630217]: # cstore_281 = PHI <[fast_algorithms.c:142:53] sc_223(14), [fast_algorithms.c:142:53] cstore_249(15)> [fast_algorithms.c:142:49] MEM [(void *)_72] = cstore_281; [fast_algorithms.c:143:13] _78 = [fast_algorithms.c:143:13] *_72; [fast_algorithms.c:143:10] if (_78 < -987654321) goto ; [50.00%] else goto ; [50.00%] [local count: 477815109]: [local count: 955630217]: # cstore_250 = PHI <[fast_algorithms.c:143:33] -987654321(16), [fast_algorithms.c:143:33] cstore_281(17)> [fast_algorithms.c:143:29] MEM [(void *)_72] = cstore_250; The aforementioned revision turned this into more optimized code: [local count: 955630217]: # cstore_281 = PHI <[fast_algorithms.c:142:53] sc_223(14), [fast_algorithms.c:142:53] _73(15)> [fast_algorithms.c:143:10] if (cstore_281 < -987654321) goto ; [50.00%] else goto ; [50.00%] [local count: 477815109]: [local count: 955630217]: # cstore_250 = PHI <[fast_algorithms.c:143:33] -987654321(16), [fast_algorithms.c:143:33] cstore_281(17)> [fast_algorithms.c:143:29] MEM [(void *)_72] = cstore_250; Which then phiopt3 changed to: cstore_248 = MAX_EXPR ; [fast_algorithms.c:143:29] MEM [(void *)_72] = cstore_248; and expander apparently always expands MAX_EXPR into a conditional move if it can(?). When I hacked phiopt not to do the transformation for - ehm - any GIMPLE_COND statement originating from source line 143, I recovered the original run-time of the benchmark. On both AMD and Intel.
[Bug d/90136] [d] Merge UDAs between function prototype and definitions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90136 Iain Buclaw changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #6 from Iain Buclaw --- Done.
[Bug d/90136] [d] Merge UDAs between function prototype and definitions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90136 --- Comment #5 from CVS Commits --- The master branch has been updated by Iain Buclaw : https://gcc.gnu.org/g:013fca64fc17ba646c3564eab52fac50f0751188 commit r10-7487-g013fca64fc17ba646c3564eab52fac50f0751188 Author: Iain Buclaw Date: Thu Apr 18 09:50:56 2019 +0200 d: Merge UDAs between function prototype and definitions (PR90136) This change fixes the symbol merging in get_symbol_decl to also consider prototypes. This allows the ability to set user defined attributes on the prototype of a function, which then get applied to the definition, if found later in the compilation. The lowering of UDAs to GCC attributes has been commonized into a single function called apply_user_attributes. gcc/d/ChangeLog: PR d/90136 * d-attribs.cc: Include dmd/attrib.h. (build_attributes): Redeclare as static. (apply_user_attributes): New function. * d-tree.h (class UserAttributeDeclaration): Remove. (build_attributes): Remove. (apply_user_attributes): Declare. (finish_aggregate_type): Remove attrs argument. * decl.cc (get_symbol_decl): Merge declaration prototypes with definitions. Use apply_user_attributes. * modules.cc (layout_moduleinfo_fields): Remove last argument to finish_aggregate_type. * typeinfo.cc (layout_classinfo_interfaces): Likewise. * types.cc (layout_aggregate_members): Likewise. (finish_aggregate_type): Remove attrs argument. (TypeVisitor::visit (TypeEnum *)): Use apply_user_attributes. (TypeVisitor::visit (TypeStruct *)): Remove last argument to finish_aggregate_type. Use apply_user_attributes. (TypeVisitor::visit (TypeClass *)): Likewise. gcc/testsuite/ChangeLog: PR d/90136 * gdc.dg/pr90136a.d: New test. * gdc.dg/pr90136b.d: New test. * gdc.dg/pr90136c.d: New test.
[Bug c++/18] bad ctor/dtor call ordering
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=18 --- Comment #8 from CVS Commits --- The master branch has been updated by Iain Buclaw : https://gcc.gnu.org/g:013fca64fc17ba646c3564eab52fac50f0751188 commit r10-7487-g013fca64fc17ba646c3564eab52fac50f0751188 Author: Iain Buclaw Date: Thu Apr 18 09:50:56 2019 +0200 d: Merge UDAs between function prototype and definitions (PR90136) This change fixes the symbol merging in get_symbol_decl to also consider prototypes. This allows the ability to set user defined attributes on the prototype of a function, which then get applied to the definition, if found later in the compilation. The lowering of UDAs to GCC attributes has been commonized into a single function called apply_user_attributes. gcc/d/ChangeLog: PR d/90136 * d-attribs.cc: Include dmd/attrib.h. (build_attributes): Redeclare as static. (apply_user_attributes): New function. * d-tree.h (class UserAttributeDeclaration): Remove. (build_attributes): Remove. (apply_user_attributes): Declare. (finish_aggregate_type): Remove attrs argument. * decl.cc (get_symbol_decl): Merge declaration prototypes with definitions. Use apply_user_attributes. * modules.cc (layout_moduleinfo_fields): Remove last argument to finish_aggregate_type. * typeinfo.cc (layout_classinfo_interfaces): Likewise. * types.cc (layout_aggregate_members): Likewise. (finish_aggregate_type): Remove attrs argument. (TypeVisitor::visit (TypeEnum *)): Use apply_user_attributes. (TypeVisitor::visit (TypeStruct *)): Remove last argument to finish_aggregate_type. Use apply_user_attributes. (TypeVisitor::visit (TypeClass *)): Likewise. gcc/testsuite/ChangeLog: PR d/90136 * gdc.dg/pr90136a.d: New test. * gdc.dg/pr90136b.d: New test. * gdc.dg/pr90136c.d: New test.
[Bug c++/94205] [8/9/10 Regression] ICE in cxx_eval_constant_expression with 'this'-capturing lambda inside an NSDMI since r8-1251
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94205
--- Comment #2 from Jason Merrill ---
C++14 version that goes back to the introduction of C++14 constexpr in GCC 5:
struct S
{
struct A
{
S *p;
constexpr A(S* p): p(p) {}
constexpr operator int() { p->a = 5; return 6; }
};
int a = A(this);
};
constexpr S s = {};
#define SA(X) static_assert((X),#X)
SA(s.a == 6);
[Bug sanitizer/91203] __asan_set_error_report_callback has no effect on leak messages
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91203 qinzhao at gcc dot gnu.org changed: What|Removed |Added CC||qinzhao at gcc dot gnu.org --- Comment #4 from qinzhao at gcc dot gnu.org --- (In reply to Martin Liška from comment #2)> > You are right, LSAN does not provide such a callback. Please create an > upstream feature request here: > https://github.com/google/sanitizers/issues > the feature request has been filed more than half year ago. I am wondering whether any patch has been delivered or not?
[Bug sanitizer/92589] heuristic to avoid flexible array members too liberal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92589 --- Comment #8 from Kees Cook --- Created attachment 48153 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48153&action=edit updated PoC
[Bug sanitizer/92589] heuristic to avoid flexible array members too liberal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92589 --- Comment #7 from Kees Cook --- (In reply to Kees Cook from comment #6) > (In reply to Jakub Jelinek from comment #4) > > (In reply to Kees Cook from comment #2) > > > Is there anything to enforce a strict "only consider empty array size as > > > flexible array member" mode? This is an unfortunate weakening of the array > > > bounds checker as there are plenty of structures that have a fixed-size > > > array as the final member. > > > > There is -fsanitize=bounds-strict. > > This is too strict: it doesn't allow flexible arrays ([]) either. I'd like > something that ignores _only_ flexible arrays and fails on all other > trailing arrays beyond their size. Oops, sorry, my PoC was testing the corner cases, not the correct cases. -fsanitize=bounds-strict _does_ work (though I'd rather it disallowed [0], but I'll live): $ gcc -Wall -g3 -fsanitize=bounds-strict -fsanitize-undefined-trap-on-error -o bounds-gcc bounds.c $ ./bounds-gcc abc flex (should always be okay): ok (no trap!) zero (should be okay, treated as flex): ok (no trap!) one (should fail): Illegal instruction (core dumped)
[Bug sanitizer/92589] heuristic to avoid flexible array members too liberal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92589 --- Comment #6 from Kees Cook --- (In reply to Jakub Jelinek from comment #4) > (In reply to Kees Cook from comment #2) > > Is there anything to enforce a strict "only consider empty array size as > > flexible array member" mode? This is an unfortunate weakening of the array > > bounds checker as there are plenty of structures that have a fixed-size > > array as the final member. > > There is -fsanitize=bounds-strict. This is too strict: it doesn't allow flexible arrays ([]) either. I'd like something that ignores _only_ flexible arrays and fails on all other trailing arrays beyond their size.
[Bug c++/42633] hinting gcc that restricted pointer dont alias with members of structs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=42633 Eyal Rozenberg changed: What|Removed |Added CC||eyalroz at technion dot ac.il --- Comment #5 from Eyal Rozenberg --- This bug is marked assigned, and there's a patch, but 10 years have passed. Torben, Richard - ping.
[Bug rtl-optimization/90214] UBSAN: signed integer overflow: 162675373468811328 - -9060696663385964544 cannot be represented in type 'long int'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90214 --- Comment #2 from Jonathan Wakely --- This is a ubsan error in GCC when GCC is built with ubsan. It's useless to test on godbolt, because their GCC builds are not built with ubsan.
[Bug target/92665] [AArch64] low lanes select not optimized out for vmlal intrinsics
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92665 --- Comment #7 from Sebastian Pop --- Hi Andrew, have you committed the fix for this?
[Bug c++/94205] [8/9/10 Regression] ICE in cxx_eval_constant_expression with 'this'-capturing lambda inside an NSDMI since r8-1251
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94205 Jason Merrill changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |jason at gcc dot gnu.org Status|NEW |ASSIGNED
[Bug c++/90711] [9/10 Regression] Failing SFINAE from unrelated struct since r9-6794
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90711 Jason Merrill changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #5 from Jason Merrill --- Fixed for 9.4/10.
[Bug target/93819] PPC64 builtin vec_rlnm() argument order is wrong.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93819 --- Comment #6 from CVS Commits --- The releases/gcc-8 branch has been updated by Carl Love : https://gcc.gnu.org/g:9d9d5382765785afbd114e9b9f253a602871a047 commit r8-10154-g9d9d5382765785afbd114e9b9f253a602871a047 Author: Carl Love Date: Tue Mar 31 12:45:34 2020 -0500 rs6000: vec_rlnm fix to make builtin work according to ABI Backport from mainline: commit e97929e20b2f52e6cfc046c1302324d1b24d95e3 Author: Carl Love Date: Wed Mar 25 18:33:37 2020 -0500 gcc/ChangeLog PR target/93819 * gcc/config/rs6000/altivec.h: Fixed swapped arguments for vec_rlnm define.
[Bug target/87583] error: unrecognizable insn on ppc64le
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87583 --- Comment #7 from CVS Commits --- The releases/gcc-8 branch has been updated by Carl Love : https://gcc.gnu.org/g:bfb0e282e3dacb7c72f78b9b546b36a6fcc534e8 commit r8-10153-gbfb0e282e3dacb7c72f78b9b546b36a6fcc534e8 Author: Carl Love Date: Tue Mar 31 11:53:47 2020 -0500 rs6000 Add command line and builtin compatibility check 2020-03-31 Carl Love backport of mainline commit commit 68dd57808f7c0147acdb5ca72c88ff655afcb0ce Author: Carl Love Date: Fri Mar 20 18:15:05 2020 -0500 whith change log typo fixed. PR target/87583 * gcc/config/rs6000/rs6000.c (rs6000_option_override_internal): Add check for TARGET_FPRND for Power 7 or newer.
[Bug tree-optimization/94427] New: 456.hmmer is 8-17% slower when compiled at -Ofast than with GCC 9
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94427 Bug ID: 94427 Summary: 456.hmmer is 8-17% slower when compiled at -Ofast than with GCC 9 Product: gcc Version: 10.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: jamborm at gcc dot gnu.org CC: rguenth at gcc dot gnu.org Blocks: 26163 Target Milestone: --- Host: x86_64-linux Target: x86_64-linux SPECINT 2006 benchmark 456.hmmer runs 18% slower on AMD Zen2 CPUs, 15% on AMD Zen1 CPUs and 8% on Intel Cascade Lake server CPUs when built with trunk (revision 26b3e568a60) and just -Ofast (so with generic march/mtune) than when compiled wth GCC 9. Bisecting the regression leads to commit: commit 14ec49a7537004633b7fff859178cbebd288ca1d Author: Richard Biener Date: Tue Jul 2 07:35:23 2019 + re PR tree-optimization/58483 (missing optimization opportunity for const std::vector compared to std::array) 2019-07-02 Richard Biener PR tree-optimization/58483 * tree-ssa-scopedtables.c (avail_expr_hash): Use OEP_ADDRESS_OF for MEM_REF base hashing. (equal_mem_array_ref_p): Likewise for base comparison. * gcc.dg/tree-ssa/ssa-dom-cse-8.c: New testcase. From-SVN: r272922 Collected profiles are weird, almost the other way round I would expect them to be, because the *slow* version spends less time in cold section - but both spend IMHO too much time there. The following data were collected on AMD Zen2 but those from Intel are similar in this regard. What is different is that on Intel perf stat reports doubling of branch misses - and because it has older perf it does not report front/back-end stalls. Before the aforementioned revision: Performance counter stats for 'numactl -C 0 -l specinvoke': 163360.87 msec task-clock:u #0.992 CPUs utilized 0 context-switches:u#0.000 K/sec 0 cpu-migrations:u #0.000 K/sec 7639 page-faults:u #0.047 K/sec 525635661818 cycles:u # 809847511 stalled-cycles-frontend:u #0.15% frontend cycles idle (83.35%) 299331255326 stalled-cycles-backend:u # 56.95% backend cycles idle (83.30%) 1757801907547 instructions:u#3.34 insn per cycle #0.17 stalled cycles per insn (83.34%) 133496985084 branches:u# 817.191 M/sec (83.35%) 682351923 branch-misses:u #0.51% of all branches (83.31%) 164.659685804 seconds time elapsed 163.32542 seconds user 0.022183000 seconds sys # Samples: 637K of event 'cycles:u' # Event count (approx.): 527143782584 # # Overhead Samples Shared ObjectSymbol # ... # 58.43%372284 hmmer_peak.mine-std-gen [.] P7Viterbi 35.12%223887 hmmer_peak.mine-std-gen [.] P7Viterbi.cold 2.59% 16418 hmmer_peak.mine-std-gen [.] FChoose 2.51% 15906 hmmer_peak.mine-std-gen [.] sre_random At the aforementioned revision: Performance counter stats for 'numactl -C 0 -l specinvoke': 191483.84 msec task-clock:u #0.994 CPUs utilized 0 context-switches:u#0.000 K/sec 0 cpu-migrations:u #0.000 K/sec 7639 page-faults:u #0.040 K/sec 622159384711 cycles:u # 817604010 stalled-cycles-frontend:u #0.13% frontend cycles idle (83.31%) 439972264588 stalled-cycles-backend:u # 70.72% backend cycles idle (83.34%) 1707838992202 instructions:u#2.75 insn per cycle #0.26 stalled cycles per insn (83.35%) 91309384910 branches:u# 476.852 M/sec (83.32%) 655463713 branch-misses:u #0.72% of all branches (83.33%) 192.564513355 seconds time elapsed 191.443774000 seconds user 0.023978000 seconds sys # Samples: 752K of event 'cycles:u' # Event count (approx.): 622947549968 # # Overhead Samples Shared Object Symbol # # 83.68%629645 hmmer_peak.small-std-gen [.] P7Viterbi 10.84% 81591 hmm
[Bug rtl-optimization/90214] UBSAN: signed integer overflow: 162675373468811328 - -9060696663385964544 cannot be represented in type 'long int'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90214 Nicholas Krause changed: What|Removed |Added CC||xerofoify at gmail dot com --- Comment #1 from Nicholas Krause --- I've tried this on godbolt for gcc 9.1, gcc 9.2 and gcc 9.3. I've also tried this on trunk from a recent build and it does not occur anymore. Seems to be fixed now. Does this still occur for you, Martin as it does now occur for me on x86 or power?
[Bug d/94424] [D] Alignment holes can in structs can still end up with non-zero data
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94424 Iain Buclaw changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #2 from Iain Buclaw --- Done.
[Bug c++/90711] [9/10 Regression] Failing SFINAE from unrelated struct since r9-6794
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90711 --- Comment #4 from CVS Commits --- The releases/gcc-9 branch has been updated by Jason Merrill : https://gcc.gnu.org/g:0e66150084aa217811a5c45fb15e98d7ed3e8839 commit r9-8427-g0e66150084aa217811a5c45fb15e98d7ed3e8839 Author: Jason Merrill Date: Mon Mar 30 16:09:43 2020 -0400 c++: Fix comparison of fn() and ns::fn() [PR90711] The resolution of CWG issue 1321 clarified that when deciding whether two expressions involving template parameters are equivalent, two dependent function calls where the function is named with an unqualified-id are considered to be equivalent if the name is the same, even if unqualified lookup finds different sets of functions. We were wrongly treating qualified-ids the same way, so that EXISTS and test::EXISTS were considered to be equivalent even though they are looking up the name in different scopes. This also causes a mangling bug, but I don't think it's safe to fix that for GCC 10; this patch just fixes the comparison. gcc/cp/ChangeLog 2020-03-30 Jason Merrill PR c++/90711 * tree.c (cp_tree_equal) [CALL_EXPR]: Compare KOENIG_LOOKUP_P. (called_fns_equal): Check DECL_CONTEXT.
[Bug d/94424] [D] Alignment holes can in structs can still end up with non-zero data
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94424 --- Comment #1 from CVS Commits --- The master branch has been updated by Iain Buclaw : https://gcc.gnu.org/g:e8e0acbaa38ed57b4cbf9e60556f78a059ba2c0b commit r10-7482-ge8e0acbaa38ed57b4cbf9e60556f78a059ba2c0b Author: Iain Buclaw Date: Tue Mar 31 18:18:32 2020 +0200 d: Use memset to fill alignment holes with zeroes. This patch removes the manual insertion of padding for fields in constructed struct literals, and instead uses memset() on the declaration being initialized. When compiling optimized builds, the intent is usually missed, and alignment holes end up with non-zero values in them anyway. gcc/d/ChangeLog: PR d/94424 * d-codegen.cc (build_alignment_field): Remove. (build_struct_literal): Don't insert alignment padding. * expr.cc (ExprVisitor::visit (AssignExp *)): Call memset before assigning struct literals. gcc/testsuite/ChangeLog: PR d/94424 * gdc.dg/pr94424.d: New test.
[Bug target/93819] PPC64 builtin vec_rlnm() argument order is wrong.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93819 --- Comment #5 from CVS Commits --- The releases/gcc-9 branch has been updated by Carl Love : https://gcc.gnu.org/g:02a201f7158b4d2d2b937ff3b37640126ce936d2 commit r9-8426-g02a201f7158b4d2d2b937ff3b37640126ce936d2 Author: Carl Love Date: Tue Mar 31 11:41:26 2020 -0500 rs6000: vec_rlnm fix to make builtin work according to ABI Backport from mainline: commit e97929e20b2f52e6cfc046c1302324d1b24d95e3 Author: Carl Love Date: Wed Mar 25 18:33:37 2020 -0500 gcc/ChangeLog PR target/93819 * gcc/config/rs6000/altivec.h: Fixed swapped arguments for vec_rlnm define.
[Bug target/87583] error: unrecognizable insn on ppc64le
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87583 --- Comment #6 from CVS Commits --- The releases/gcc-9 branch has been updated by Carl Love : https://gcc.gnu.org/g:8ab40918a3b6b9093930193fe8900d738858e75f commit r9-8425-g8ab40918a3b6b9093930193fe8900d738858e75f Author: Carl Love Date: Tue Mar 31 11:30:00 2020 -0500 rs6000: Add command line and builtin compatibility check 2020-03-31 Carl Love backport of mainline commit commit 68dd57808f7c0147acdb5ca72c88ff655afcb0ce Author: Carl Love Date: Fri Mar 20 18:15:05 2020 -0500 whith change log typo fixed. PR target/87583 * gcc/config/rs6000/rs6000.c (rs6000_option_override_internal): Add check for TARGET_FPRND for Power 7 or newer.
[Bug c/92507] False positives with -Wsign-compare
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92507 Michał Mirosław changed: What|Removed |Added CC||mirq-gccboogs at rere dot qmqm.pl --- Comment #4 from Michał Mirosław --- Created attachment 48152 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48152&action=edit testcase A simple testcase.
[Bug c++/94422] [9 Regression] static_cast from std::array operator[] to enum class
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94422 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org, ||jason at gcc dot gnu.org --- Comment #3 from Jakub Jelinek --- Started with r9-8323-gb4e53e9b3c963b1c0fe9637618dec8042764f599
[Bug target/89096] [8/9/10 regression] AIX 7 linker rejects _.ro_ sections by default
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89096 --- Comment #27 from Andrew Paprocki --- 60 second reproduction steps: $ curl -O https://ftp.pcre.org/pub/pcre/pcre-8.42.tar.gz $ tar zxvf pcre-8.42.tar.gz && cd pcre-8.42 $ CC="gcc-7" \ CXX="g++-7" \ CFLAGS="-maix32 -pthread" \ CXXFLAGS="-maix32 -pthread" \ LDFLAGS="-Wl,-bsvr4" \ ./configure && make -j It will fail: ld: 0711-308 SEVERE ERROR: Object pcre_stringpiece_unittest-pcre_stringpiece_unittest.o, csect <_pcrestringpieceunittest.ro_> The csect is part of the .text section. ld: 0711-308 SEVERE ERROR: Object pcre_scanner_unittest-pcre_scanner_unittest.o, csect <_pcrescannerunittest.ro_> The csect is part of the .text section. collect2: error: ld returned 12 exit status collect2: error: ld returned 12 exit status ld: 0711-308 SEVERE ERROR: Object pcrecpp_unittest-pcrecpp_unittest.o, csect <_pcrecppunittest.ro_> The csect is part of the .text section. collect2: error: ld returned 12 exit status
[Bug c++/94426] [10 Regression] ICE in mangle_decl with -flto
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94426 Jakub Jelinek changed: What|Removed |Added Target Milestone|--- |10.0
[Bug c++/94426] New: [10 Regression] ICE in mangle_decl with -flto
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94426
Bug ID: 94426
Summary: [10 Regression] ICE in mangle_decl with -flto
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: jakub at gcc dot gnu.org
Target Milestone: ---
The following testcase ICEs in mangle_decl with -O2 -flto starting with
r10-7403-g517f5356bb0ca717f51e937be880e38a828edbf7, before that it has been
rejected.
template struct b { static constexpr int c = a; };
template using d = b;
template auto ad() -> decltype(0);
struct m { d())> e; };
struct n : m { typedef decltype(e) ab; };
template using aj = int;
class C { void q(); int bq; };
template using bz = typename by::bz;
namespace ca {
struct r { template using bz = cc; };
template using cd = bz;
namespace ce {
struct s { template s(bj); };
struct t { bool c; };
t ci(void *, s);
}
template aj cl;
template bool f;
template constexpr bool destructible = n::ab ::c;
template constexpr bool cp = destructible;
template constexpr bool cq = cp;
template constexpr bool copyable = cq;
template constexpr bool cr = copyable;
}
namespace cs {
using namespace ca;
namespace ce {
template using da = cy;
}
template using da = ce::da<>;
template
bool db = ca::ce::ci(nullptr, [](auto g) -> decltype(cl>>)
{}).c;
template constexpr bool dd = cr;
template constexpr bool de = dd;
template constexpr bool h = de;
template constexpr bool df = h;
template bool dj = db;
namespace ce {
template struct H;
}
template using dn = ce::H;
template constexpr bool i = df;
struct {
template
auto operator()(cx, j, cc, k) -> cd && dj, cc>>>
{ while (1); }
template
void operator()(l, cc p2, k u) { (*this)(0, 0, p2, u); }
} o;
}
int p;
void C::q() { cs::o(bq, p, [] {}); }
[Bug target/89096] [8/9/10 regression] AIX 7 linker rejects _.ro_ sections by default
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89096 --- Comment #26 from Andrew Paprocki --- Just re-summarizing now for 2020 since there have been a few twists and turns and distractions. This issue has nothing to do with CMake, -brtl, or -bexpall linker flags. This issue only occurs when GCC is told to pass the -bsvr4 linker flag, because the application wishes to use multiple -R parameters as documented in the man page (see comment 14). When that occurs, the error in this ticket happens. The already applied patches to GCC mentioned throughout the bug do not change any behavior -- it still fails to link. David, can you or someone on the linker team determine if this is an issue with the GCC side of things, or it is simply a bug in the linker? It is difficult for an outsider to determine if this is purely on the linker side or if GCC is not conforming somehow to what the linker expects.
[Bug target/94417] -fcf-protection -mcmodel=large/-mforce-indirect-call is broken
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94417 H.J. Lu changed: What|Removed |Added Target Milestone|--- |10.0 URL||https://gcc.gnu.org/piperma ||il/gcc-patches/2020-March/5 ||42984.html Keywords||patch --- Comment #3 from H.J. Lu --- A patch is posted at https://gcc.gnu.org/pipermail/gcc-patches/2020-March/542984.html
[Bug c++/94414] only `--` gives constexpr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94414 Patrick Palka changed: What|Removed |Added CC||ppalka at gcc dot gnu.org --- Comment #3 from Patrick Palka --- It looks the memoization that's performed in filter_view::begin() is interfering with optimization in the first testcase.
[Bug target/94420] [8/9/10 Regression] ICE error: insn does not satisfy its constraints
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94420 --- Comment #9 from Segher Boessenkool --- diff --git a/gcc/config/rs6000/rs6000.md b/gcc/config/rs6000/rs6000.md index dcccb03..11ab745 100644 --- a/gcc/config/rs6000/rs6000.md +++ b/gcc/config/rs6000/rs6000.md @@ -10311,7 +10311,8 @@ (define_insn "*largetoc_low_aix" (define_insn_and_split "*tocref" [(set (match_operand:P 0 "gpc_reg_operand" "=b") (match_operand:P 1 "small_toc_ref" "R"))] - "TARGET_TOC" + "TARGET_TOC +&& legitimate_constant_pool_address_p (operands[1], QImode, false)" "la %0,%a1" "&& TARGET_CMODEL != CMODEL_SMALL && reload_completed" [(set (match_dup 0) (high:P (match_dup 1))) This works on the testcase fine; regression testing now.
[Bug d/94425] New: [D] Consider always settings ASM_VOLATILE_P on asm statements
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94425
Bug ID: 94425
Summary: [D] Consider always settings ASM_VOLATILE_P on asm
statements
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: d
Assignee: ibuclaw at gdcproject dot org
Reporter: ibuclaw at gdcproject dot org
Target Milestone: ---
Currently, the following have equivalents with the c-family front-ends.
asm { ""; } -> asm __volatile__ ("");
asm pure { ""; } -> asm ("");
In the case of 'asm pure' the result can be cached, with duplicated statements
being DCE'd. This happens in the std.math unittests when compiling with -O2.
The example below distils what the test looks like after inlining. The last
asm statement is removed, and the first result is reused, which produces wrong
run-time results. The use of 'asm pure' is in line with expectations however,
particularly as the getters are 'pure' in the D sense.
Either will have to say that every asm statement is volatile, or will have to
apply a stricter condition.
In C, asm statements without output operands are automatically considered
volatile, but that won't help us here.
---
import core.stdc.fenv;
enum ROUNDING_MASK = FE_TONEAREST|FE_DOWNWARD|FE_UPWARD|FE_TOWARDZERO;
void main()
{
uint newMode = FE_DOWNWARD;
fexcept_t oldState;
asm pure
{
"fstcw %0;" : "=m" (oldState);
}
fexcept_t newState = cast(fexcept_t)((oldState & (-1 - ROUNDING_MASK))
| (newMode & ROUNDING_MASK));
asm
{
"fclex; fldcw %0;" : : "m" (newState);
}
uint mxcsr;
asm
{
"stmxcsr %0" : "=m" (mxcsr);
}
mxcsr &= ~(ROUNDING_MASK << 3);
mxcsr |= (newState & ROUNDING_MASK) << 3;
mxcsr &= ~(FE_ALL_EXCEPT << 7);
mxcsr |= (newState & FE_ALL_EXCEPT) << 7;
asm
{
"ldmxcsr %0" : : "m" (mxcsr);
}
fexcept_t contState;
asm pure
{
"fstcw %0;" : "=m" (contState);
}
assert(cast(uint)(contState & ROUNDING_MASK) == FE_DOWNWARD);
}
[Bug target/94420] [8/9/10 Regression] ICE error: insn does not satisfy its constraints
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94420 Segher Boessenkool changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |segher at gcc dot gnu.org --- Comment #8 from Segher Boessenkool --- I put it in the insn condition, testing it now.
[Bug target/94420] [8/9/10 Regression] ICE error: insn does not satisfy its constraints
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94420 Segher Boessenkool changed: What|Removed |Added Keywords|ice-on-invalid-code |ice-on-valid-code --- Comment #7 from Segher Boessenkool --- But okay, let's call it valid code, it doesn't actually *do* anything with the undefined value in this example :-)
[Bug c++/94034] [10 Regression] Broken diagnostic: 'result_decl' not supported by dump_expr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94034 Patrick Palka changed: What|Removed |Added CC||ppalka at gcc dot gnu.org --- Comment #3 from Patrick Palka --- Paolo, would you happen to be working on this PR still?
[Bug target/94420] [8/9/10 Regression] ICE error: insn does not satisfy its constraints
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94420 --- Comment #6 from Jakub Jelinek --- So shouldn't predicate on that operand verify the same thing as the constraint does (or insn condition)?
[Bug target/94420] [8/9/10 Regression] ICE error: insn does not satisfy its constraints
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94420 --- Comment #5 from Segher Boessenkool --- It is undefined behaviour to access such a register in any way -- sure, you *can* inspect it, there just is no guarantee at all what value you will get. It still is a useful thing to do in debug code and the like, of course.
[Bug target/94420] [8/9/10 Regression] ICE error: insn does not satisfy its constraints
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94420 --- Comment #4 from Segher Boessenkool --- cprop1 has done LOCAL COPY-PROP: Replacing reg 2 in insn 7 with reg 118 which is wrong: the insn isn't valid after that. But there is nothing that expresses that, the "R" constraint "just" becomes unsatisfiable.
[Bug fortran/94397] [10 Regression] the compiler consider "type is( real(kind(1.)) )" as a syntax error since r10-7369-gc38daa7976886a59
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94397 --- Comment #5 from kargl at gcc dot gnu.org --- (In reply to markeggleston from comment #4) > The compilation error reported is due this change in PR93484: > > --- a/gcc/fortran/match.c > +++ b/gcc/fortran/match.c > @@ -,9 +,9 @@ gfc_match_type_spec (gfc_typespec *ts) > > found: > > - m = gfc_match_init_expr (&e); > + m = gfc_match_expr (&e); > > Changing it back causes test cases ISO_Fortran_binding_11.f90 and > pr78033.f90 to fail. > > If "kind=" is found gfc_match_init_expr (&e) should be used and when it is > not gfc_match_expr (&e). > > I'm checking a suitable test case and will have a patch ready soon. The patch in comment #3 likely is the correct patch. When in the specification part of a scoping unit, the above change is needed to distinguish REAL(kind(1.)) from REAL(1.1, kind(1.)). In the former, we have a type and kind(1.) must be an initialization expression (see comment 3 or 4 lines down). In the latter case, we have the intrinsic subprogram, and simply return MATCH_NO or MATCH_ERROR. -- steve
[Bug d/94424] New: [D] Alignment holes can in structs can still end up with non-zero data
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94424
Bug ID: 94424
Summary: [D] Alignment holes can in structs can still end up
with non-zero data
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: d
Assignee: ibuclaw at gdcproject dot org
Reporter: ibuclaw at gdcproject dot org
Target Milestone: ---
Example is a test that passes with -O0, but fails at -O2.
@safe unittest
{
struct C
{
ubyte i;
this(ubyte i) { this.i = i; }
}
auto c1 = C(1);
auto c2 = C(2);
assert(__cmp([c1, c1][], [c2, c2][]) < 0);
assert(__cmp([c2, c2], [c1, c1]) > 0);
assert(__cmp([c2, c2], [c2, c1]) > 0);
}
This happens despite the front-end attempting to do a best effort to plug all
holes with zeroes.
[Bug tree-optimization/94398] ICE: in vectorizable_load, at tree-vect-stmts.c:9173
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94398 --- Comment #5 from CVS Commits --- The master branch has been updated by Richard Sandiford : https://gcc.gnu.org/g:f14b41d27124601284347a10d496362c8b4b8e1c commit r10-7481-gf14b41d27124601284347a10d496362c8b4b8e1c Author: Felix Yang Date: Tue Mar 31 16:41:56 2020 +0800 vect: ICE: in vectorizable_load, at tree-vect-stmts.c:9173 [PR94398] In the testcase for PR94398, we're trying to compute: alignment_support_scheme = vect_supportable_dr_alignment (first_dr_info, false); gcc_assert (alignment_support_scheme); even for VMAT_GATHER_SCATTER, which always accesses individual elements. Here we should set alignment_support_scheme to dr_unaligned_supported the gather/scatter case instead of calling vect_supportable_dr_alignment. 2020-03-31 Felix Yang gcc/ PR tree-optimization/94398 * tree-vect-stmts.c (vectorizable_store): Instead of calling vect_supportable_dr_alignment, set alignment_support_scheme to dr_unaligned_supported for gather-scatter accesses. (vectorizable_load): Likewise. gcc/testsuite/ PR tree-optimization/94398 * gcc.target/aarch64/pr94398.c: New test.
[Bug c++/92878] Parenthesized aggregate initialization doesn't work in a new-expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92878 --- Comment #11 from CVS Commits --- The master branch has been updated by Ville Voutilainen : https://gcc.gnu.org/g:e06cde870edc7ec21736145b6857565d4b2f0e85 commit r10-7480-ge06cde870edc7ec21736145b6857565d4b2f0e85 Author: Ville Voutilainen Date: Sat Feb 22 22:40:26 2020 +0200 Library-side tests for parenthesized aggregate init PR c++/92878 PR c++/92947 * testsuite/20_util/allocator_traits/members/92878_92947.cc: New. * testsuite/20_util/any/assign/92878_92947.cc: Likewise. * testsuite/20_util/any/cons/92878_92947.cc: Likewise. * testsuite/20_util/is_constructible/92878_92947.cc: Likewise. * testsuite/20_util/optional/assignment/92878_92947.cc: Likewise. * testsuite/20_util/optional/cons/92878_92947.cc: Likewise. * testsuite/20_util/pair/cons/92878_92947.cc: Likewise. * testsuite/20_util/shared_ptr/creation/92878_92947.cc: Likewise. * testsuite/20_util/specialized_algorithms/construct_at/92878_92947.cc: Likewise. * testsuite/20_util/unique_ptr/creation/92878_92947.cc: Likewise. * testsuite/20_util/uses_allocator/92878_92947.cc: Likewise. * testsuite/20_util/variant/92878_92947.cc: Likewise. * testsuite/23_containers/deque/modifiers/emplace/92878_92947.cc: Likewise. * testsuite/23_containers/forward_list/modifiers/92878_92947.cc: Likewise. * testsuite/23_containers/list/modifiers/emplace/92878_92947.cc: Likewise. * testsuite/23_containers/map/modifiers/emplace/92878_92947.cc: Likewise. * testsuite/23_containers/multimap/modifiers/emplace/92878_92947.cc: Likewise. * testsuite/23_containers/multiset/modifiers/emplace/92878_92947.cc: Likewise. * testsuite/23_containers/priority_queue/92878_92947.cc: Likewise. * testsuite/23_containers/queue/92878_92947.cc: Likewise. * testsuite/23_containers/set/modifiers/emplace/92878_92947.cc: Likewise. * testsuite/23_containers/stack/92878_92947.cc: Likewise. * testsuite/23_containers/unordered_map/modifiers/92878_92947.cc: Likewise. * testsuite/23_containers/unordered_multimap/modifiers/92878_92947.cc: Likewise. * testsuite/23_containers/unordered_multiset/modifiers/92878_92947.cc: Likewise. * testsuite/23_containers/unordered_set/modifiers/92878_92947.cc: Likewise. * testsuite/23_containers/vector/modifiers/emplace/92878_92947.cc: Likewise.
[Bug c++/92947] Parenthesized aggregate initialization doesn't work with the library types it's supposed to work with
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92947 --- Comment #8 from CVS Commits --- The master branch has been updated by Ville Voutilainen : https://gcc.gnu.org/g:e06cde870edc7ec21736145b6857565d4b2f0e85 commit r10-7480-ge06cde870edc7ec21736145b6857565d4b2f0e85 Author: Ville Voutilainen Date: Sat Feb 22 22:40:26 2020 +0200 Library-side tests for parenthesized aggregate init PR c++/92878 PR c++/92947 * testsuite/20_util/allocator_traits/members/92878_92947.cc: New. * testsuite/20_util/any/assign/92878_92947.cc: Likewise. * testsuite/20_util/any/cons/92878_92947.cc: Likewise. * testsuite/20_util/is_constructible/92878_92947.cc: Likewise. * testsuite/20_util/optional/assignment/92878_92947.cc: Likewise. * testsuite/20_util/optional/cons/92878_92947.cc: Likewise. * testsuite/20_util/pair/cons/92878_92947.cc: Likewise. * testsuite/20_util/shared_ptr/creation/92878_92947.cc: Likewise. * testsuite/20_util/specialized_algorithms/construct_at/92878_92947.cc: Likewise. * testsuite/20_util/unique_ptr/creation/92878_92947.cc: Likewise. * testsuite/20_util/uses_allocator/92878_92947.cc: Likewise. * testsuite/20_util/variant/92878_92947.cc: Likewise. * testsuite/23_containers/deque/modifiers/emplace/92878_92947.cc: Likewise. * testsuite/23_containers/forward_list/modifiers/92878_92947.cc: Likewise. * testsuite/23_containers/list/modifiers/emplace/92878_92947.cc: Likewise. * testsuite/23_containers/map/modifiers/emplace/92878_92947.cc: Likewise. * testsuite/23_containers/multimap/modifiers/emplace/92878_92947.cc: Likewise. * testsuite/23_containers/multiset/modifiers/emplace/92878_92947.cc: Likewise. * testsuite/23_containers/priority_queue/92878_92947.cc: Likewise. * testsuite/23_containers/queue/92878_92947.cc: Likewise. * testsuite/23_containers/set/modifiers/emplace/92878_92947.cc: Likewise. * testsuite/23_containers/stack/92878_92947.cc: Likewise. * testsuite/23_containers/unordered_map/modifiers/92878_92947.cc: Likewise. * testsuite/23_containers/unordered_multimap/modifiers/92878_92947.cc: Likewise. * testsuite/23_containers/unordered_multiset/modifiers/92878_92947.cc: Likewise. * testsuite/23_containers/unordered_set/modifiers/92878_92947.cc: Likewise. * testsuite/23_containers/vector/modifiers/emplace/92878_92947.cc: Likewise.
[Bug target/94420] [8/9/10 Regression] ICE error: insn does not satisfy its constraints
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94420 --- Comment #3 from Jakub Jelinek --- I'm not sure about the invalid, of course if one uses a global register var for a fixed reg and stores something into it, then it is clearly UB, but this case is ont about changing it, just inspecting, and I believe users use both global and local register vars for various fixed regs quite often, whether it is a stack pointer, hard frame pointer, _GLOBAL_OFFSET_TABLE_ etc.
[Bug target/94420] [8/9/10 Regression] ICE error: insn does not satisfy its constraints
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94420 --- Comment #2 from Segher Boessenkool --- Reserving a register that already *is* reserved (by the ABI) is undefined, of course. But we shouldn't ICE.
[Bug target/93720] [10 Regression] vector creation from two parts of two vectors produces TBL rather than ins
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93720 Dmitrij Pochepko changed: What|Removed |Added CC||dpochepk at gmail dot com --- Comment #11 from Dmitrij Pochepko --- Is it still under development/improvement?
[Bug middle-end/94423] [10 Regression] ICE in replace_uses_by with -O2 -fsanitize=object-size since r10-6332
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94423 --- Comment #3 from Richard Biener --- Oh, and yes, you cannot replace a SSA use in a PHI on an abnormal edge with an invariant because you have no where to insert the copy.
[Bug middle-end/94423] [10 Regression] ICE in replace_uses_by with -O2 -fsanitize=object-size since r10-6332
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94423 --- Comment #2 from Richard Biener --- Comment on attachment 48151 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48151 gcc10-pr94423.patch If one replaces a SSA_NAME_OCCURS_IN_ABNORMAL_PHI def with another SSA name one has to set SSA_NAME_OCCURS_IN_ABNORMAL_PHI on it. I suppose lhs is released afterwards?
[Bug middle-end/94423] [10 Regression] ICE in replace_uses_by with -O2 -fsanitize=object-size since r10-6332
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94423 --- Comment #1 from Jakub Jelinek --- Created attachment 48151 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48151&action=edit gcc10-pr94423.patch So, either we can avoid calling replace_uses_by for the lhs SSA_NAMEs used in abnormal PHIs as this untested patch does, or perhaps could teach replace_uses_by to allow replacing such SSA_NAMEs with gimple min invariants. Though, not sure if that would be ok.
[Bug middle-end/94423] [10 Regression] ICE in replace_uses_by with -O2 -fsanitize=object-size since r10-6332
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94423 Richard Biener changed: What|Removed |Added Priority|P3 |P1
[Bug c++/94422] [9 Regression] static_cast from std::array operator[] to enum class
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94422 Richard Biener changed: What|Removed |Added Target Milestone|--- |9.4 Priority|P3 |P2
[Bug target/94420] [8/9/10 Regression] ICE error: insn does not satisfy its constraints
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94420 Jakub Jelinek changed: What|Removed |Added Last reconfirmed||2020-03-31 Ever confirmed|0 |1 CC||jakub at gcc dot gnu.org Status|UNCONFIRMED |NEW Summary|ICE error: insn does not|[8/9/10 Regression] ICE |satisfy its constraints |error: insn does not ||satisfy its constraints Target Milestone|--- |8.5 --- Comment #1 from Jakub Jelinek --- With additional -fno-common it is quite old regression.
[Bug ipa/94271] [8/9 Regression] lto1: error: two or more sections for .gnu.lto_fast_clamp.default.9.564bf999b130b5e since r8-1461-g871cc215f7507cbe
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94271 Martin Liška changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #7 from Martin Liška --- I tent to close it as I'm not planning any backports, target_clones is quite a fragile feature.
[Bug middle-end/94423] [10 Regression] ICE in replace_uses_by with -O2 -fsanitize=object-size since r10-6332
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94423 Jakub Jelinek changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org Last reconfirmed||2020-03-31 Status|UNCONFIRMED |ASSIGNED Ever confirmed|0 |1 Keywords||ice-on-valid-code Target Milestone|--- |10.0
[Bug middle-end/94423] New: [10 Regression] ICE in replace_uses_by with -O2 -fsanitize=object-size since r10-6332
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94423
Bug ID: 94423
Summary: [10 Regression] ICE in replace_uses_by with -O2
-fsanitize=object-size since r10-6332
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: jakub at gcc dot gnu.org
Target Milestone: ---
void foo (void);
typedef struct { long buf[22]; } jmp_buf[1];
extern int sigsetjmp (jmp_buf, int) __attribute__ ((__nothrow__));
jmp_buf buf;
void
bar (int *c)
{
while (*c)
foo ();
while (*c)
sigsetjmp (buf, 0);
}
ICEs with -O2 -fsanitize=object-size starting with
r10-6332-g0de349f108d963219bd59aa374a68c15355236be
[Bug tree-optimization/59859] [meta-bug] GRAPHITE issues
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59859 Bug 59859 depends on bug 70390, which changed state. Bug 70390 Summary: [8/9/10 Regression] internal compiler error: in copy_loop_close_phi_args, at graphite-isl-ast-to-gimple.c:2114 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70390 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED
[Bug tree-optimization/70390] [8/9/10 Regression] internal compiler error: in copy_loop_close_phi_args, at graphite-isl-ast-to-gimple.c:2114
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70390 Martin Liška changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED CC||marxin at gcc dot gnu.org --- Comment #18 from Martin Liška --- I can confirm it works with the following releases: 8.1.0 (406c2abec3f998e9)(02 May 2018 10:13): [took: 0.435s] result: OK 8.2.0 (ddeb81e76461fc00)(26 Jul 2018 09:47): [took: 0.424s] result: OK 8.3.0 (4c44b708f11eec6f)(22 Feb 2019 14:20): [took: 0.439s] result: OK 8.4.0 (8cd3bffead2ed1d1)(04 Mar 2020 08:30): [took: 0.429s] result: OK 9.1.0 (c8913260b0756f97)(03 May 2019 07:59): [took: 0.434s] result: OK 9.2.0 (a0c06cc27d2146b7)(12 Aug 2019 09:38): [took: 0.448s] result: OK 9.3.0 (4212a6a3e44f8704)(12 Mar 2020 11:08): [took: 0.432s] result: OK and current master and gcc version 7.5.0 (SUSE Linux) is fine. Please reopen if still valid.
[Bug c++/94422] [9/10 Regression] static_cast from std::array operator[] to enum class
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94422
Jonathan Wakely changed:
What|Removed |Added
Summary|[9 Regression] static_cast |[9/10 Regression]
|from std::array operator[] |static_cast from std::array
|to enum class |operator[] to enum class
Known to fail||10.0
--- Comment #2 from Jonathan Wakely ---
Reduced:
// { dg-options "-std=gnu++17" }
template
struct array
{
T data[N];
constexpr T& operator[](unsigned n) { return data[n]; }
};
enum class EnumC : signed char { Forward = 1, Backward = -1 };
array buf;
template
struct S {
void foo() { auto const cast_to_enum{static_cast(buf[0])}; }
};
S s;
[Bug c++/94422] [9 Regression] static_cast from std::array operator[] to enum class
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94422 Jonathan Wakely changed: What|Removed |Added Keywords||ice-on-valid-code Ever confirmed|0 |1 Last reconfirmed||2020-03-31 Known to work||9.2.0 Summary|static_cast from std::array |[9 Regression] static_cast |operator[] to enum class|from std::array operator[] ||to enum class Known to fail||9.3.0 Status|UNCONFIRMED |NEW --- Comment #1 from Jonathan Wakely --- You didn't say what gcc options you're using, and since this only happens with C++17 or C++20 (not the default options) that's not very helpful. Confirmed for -std=gnu++17
[Bug target/92626] [9/10 Regression] Performance regression in compress-rar on CLX server
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92626 Jakub Jelinek changed: What|Removed |Added Resolution|--- |INVALID Status|WAITING |RESOLVED --- Comment #7 from Jakub Jelinek --- Yes.
[Bug target/92626] [9/10 Regression] Performance regression in compress-rar on CLX server
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92626 Martin Liška changed: What|Removed |Added CC||marxin at gcc dot gnu.org --- Comment #6 from Martin Liška --- I tend to close this as invalid. Jakub?
[Bug target/87222] ICE in setup_reg_classes, at reginfo.c:1027
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87222 --- Comment #1 from Martin Liška --- May I please ping this?
[Bug c++/94422] New: static_cast from std::array to enum class
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94422
Bug ID: 94422
Summary: static_cast from std::array to enum class
Product: gcc
Version: 9.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: vincent.hamp at higaski dot at
Target Milestone: ---
static_cast from std::array operator[] to an enum class inside a template class
produces an unexpected expression error. It seems that error is only present in
9.3, 9.2 and trunk work.
#include
#include
enum class EnumC : int8_t { Forward = 1, Backward = -1 };
std::array buf;
template
struct S {
void foo() { auto const cast_to_enum{static_cast(buf[0])}; }
};
S s;
[Bug libstdc++/94418] Please make reverse_iterator nothrow constructible when possible
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94418 --- Comment #3 from Jonathan Wakely --- (Adding the noexcept-specifier *should* be harmless, but it seems every time we use one of the is_constructible traits something breaks).
[Bug target/94413] auto-vectorization of isfinite raises FP exception
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94413 --- Comment #3 from Richard Biener --- in expand_vec_cond_expr_p there is if (VECTOR_BOOLEAN_TYPE_P (cmp_op_type) && get_vcond_mask_icode (TYPE_MODE (value_type), TYPE_MODE (cmp_op_type)) != CODE_FOR_nothing) return true; which doesn't bother to look at 'code' (though here we don't have VECTOR_BOOLEAN_TYPE_P). For the other cases we build test RTL and check insn operand predicates.
[Bug target/94368] [9 Regression] ICE in final_scan_insn_1, at final.c:3074(error: could not split insn) on aarch64-linux-gnu since r9-3744
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94368 Jakub Jelinek changed: What|Removed |Added Summary|[9/10 Regression] ICE in|[9 Regression] ICE in |final_scan_insn_1, at |final_scan_insn_1, at |final.c:3074(error: could |final.c:3074(error: could |not split insn) on |not split insn) on |aarch64-linux-gnu since |aarch64-linux-gnu since |r9-3744 |r9-3744 --- Comment #8 from Jakub Jelinek --- Fixed on the trunk so far.
[Bug middle-end/94412] [8/9 Regression] wrong code with vectors
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94412 Jakub Jelinek changed: What|Removed |Added Summary|[8/9/10 Regression] wrong |[8/9 Regression] wrong code |code with vectors |with vectors --- Comment #7 from Jakub Jelinek --- Fixed on the trunk so far.
[Bug rtl-optimization/94344] [9 Regression] Rotate pattern not recognized anymore
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94344 Jakub Jelinek changed: What|Removed |Added Summary|[9/10 Regression] Rotate|[9 Regression] Rotate |pattern not recognized |pattern not recognized |anymore |anymore --- Comment #7 from Jakub Jelinek --- Fixed on the trunk. Probably inappropriate for 9.x.
[Bug c++/94414] only `--` gives constexpr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94414 --- Comment #2 from Jonathan Wakely --- Right, this has nothing to do with constexpr. The contfilt view is not a constant expression, so nothing you do with it will be constant evaluated, so whether it's constexpr is irrelevant.
[Bug target/94368] [9/10 Regression] ICE in final_scan_insn_1, at final.c:3074(error: could not split insn) on aarch64-linux-gnu since r9-3744
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94368 --- Comment #7 from CVS Commits --- The master branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:a27c534794dbe3530acae3427d2c58f937f1b050 commit r10-7472-ga27c534794dbe3530acae3427d2c58f937f1b050 Author: Jakub Jelinek Date: Tue Mar 31 11:08:22 2020 +0200 aarch64: Fix up aarch64_compare_and_swaphi pattern [PR94368] The following testcase ICEs in final_scan_insn_1. The problem is in the @aarch64_compare_and_swaphi define_insn_and_split, since 9 it uses aarch64_plushi_operand predicate for the "expected value" operand, which allows either 0..0xfff constants or 0x1000..0xf000 constants (i.e. HImode values which when zero extended are either 0..0xfff or (0..0xfff) << 12). The problem is that RA doesn't care about predicates, it honors just constraints and the used constraint on the operand is n, which means any HImode CONST_SCALAR_INT. In the testcase LRA thus propagates the -1 value into the insn. This is a define_insn_and_split which requires mandatory split. But during split2 pass, we check the predicate (and don't check constraints), which fails and thus we don't split it and during final ICE because the mandatory splitting didn't happen. The following patch fixes it by adding a matching constraint to the predicate and using it. 2020-03-31 Jakub Jelinek PR target/94368 * config/aarch64/constraints.md (Uph): New constraint. * config/aarch64/atomics.md (cas_short_expected_imm): New mode attr. (@aarch64_compare_and_swap): Use it instead of n in operand 2's constraint. * gcc.dg/pr94368.c: New test.
[Bug middle-end/94412] [8/9/10 Regression] wrong code with vectors
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94412 --- Comment #6 from CVS Commits --- The master branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:1dcffc8ddc48f0b45d3d0d2f763ef5870560eb9a commit r10-7471-g1dcffc8ddc48f0b45d3d0d2f763ef5870560eb9a Author: Jakub Jelinek Date: Tue Mar 31 11:06:43 2020 +0200 fold-const: Fix division folding with vector operands [PR94412] The following testcase is miscompiled since 4.9, we treat unsigned vector types as if they were signed and "optimize" negations across it. 2020-03-31 Marc Glisse Jakub Jelinek PR middle-end/94412 * fold-const.c (fold_binary_loc) : Use ANY_INTEGRAL_TYPE_P instead of INTEGRAL_TYPE_P. * gcc.c-torture/execute/pr94412.c: New test. Co-authored-by: Marc Glisse
[Bug libstdc++/94418] Please make reverse_iterator nothrow constructible when possible
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94418 Jonathan Wakely changed: What|Removed |Added Last reconfirmed||2020-03-31 Target Milestone|--- |11.0 Ever confirmed|0 |1 Status|UNCONFIRMED |NEW --- Comment #2 from Jonathan Wakely --- I already prepared a patch doing this last week when finishing the C++20 support for reverse_iterator, but it's not suitable for master this close to the GCC 10 release. I'll do it for GCC 11.
[Bug tree-optimization/94403] Missed optimization bswap
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94403 --- Comment #4 from CVS Commits --- The master branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:5ea39b2412269d208bb6ebd78303815957bd4f70 commit r10-7470-g5ea39b2412269d208bb6ebd78303815957bd4f70 Author: Jakub Jelinek Date: Tue Mar 31 11:04:32 2020 +0200 store-merging: Allow enums during bswap recognition [PR94403] The following testcase is optimized with char/unsigned char/signed char, but not with std::byte. The following patch fixes that. Didn't use INTEGRAL_TYPE_P because bswapping bools is just too weird. 2020-03-31 Jakub Jelinek PR tree-optimization/94403 * gimple-ssa-store-merging.c (verify_symbolic_number_p): Allow also ENUMERAL_TYPE lhs_type. * g++.dg/tree-ssa/pr94403.C: New test.
[Bug rtl-optimization/94344] [9/10 Regression] Rotate pattern not recognized anymore
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94344 --- Comment #6 from CVS Commits --- The master branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:56f0b32476c0c261c8e08525f9e47fe87492447a commit r10-7469-g56f0b32476c0c261c8e08525f9e47fe87492447a Author: Jakub Jelinek Date: Tue Mar 31 11:02:47 2020 +0200 forwprop: Pattern recognize more rotates [PR94344] The following patch adjusts simplify_rotate to recognize more rotates, basically we allow even some same precision integral -> integral conversions, with the requirement that the RSHIFT_EXPR operand has to be done in unsigned type (i.e. logical right shift), so that we compensate for the combiner no longer being able to simplify those into rotates on some targets. 2020-03-31 Jakub Jelinek PR rtl-optimization/94344 * tree-ssa-forwprop.c (simplify_rotate): Handle also same precision conversions, either on both operands of |^+ or just one. Handle also extra same precision conversion on RSHIFT_EXPR first operand provided RSHIFT_EXPR is performed in unsigned type. * gcc.dg/pr94344.c: New test.
[Bug target/94413] auto-vectorization of isfinite raises FP exception
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94413 Jakub Jelinek changed: What|Removed |Added Ever confirmed|0 |1 Status|UNCONFIRMED |NEW Last reconfirmed||2020-03-31
[Bug target/94413] auto-vectorization of isfinite raises FP exception
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94413
Jakub Jelinek changed:
What|Removed |Added
Ever confirmed|1 |0
Status|NEW |UNCONFIRMED
Last reconfirmed|2020-03-31 00:00:00 |
CC||jakub at gcc dot gnu.org,
||uros at gcc dot gnu.org
--- Comment #2 from Jakub Jelinek ---
Somewhat modified testcase:
typedef float f4 __attribute__((vector_size (16)));
f4
isfinite(f4 x) {
union U { float f[4]; f4 v; } u, v;
u.v = x;
v.v = (f4) {};
int i;
for (i = 0; i < 4; ++i) v.f[i] = __builtin_isfinite(u.f[i]) ? 1.f : 0.f;
return v.v;
}
aborts already since r0-82110-g0c8d3c2b0852bf0eca1413c311fc3d2a9d3c1ade.
Though, in *.optimized dump it is
_2 = ABS_EXPR <_1>;
if (_2 u> 3.4028234663852885981170418348451692544e+38)
for scalar version which works fine and
vect__2.8_33 = ABS_EXPR ;
vect_iftmp.9_37 = VEC_COND_EXPR {
3.4028234663852885981170418348451692544e+38,
3.4028234663852885981170418348451692544e+38,
3.4028234663852885981170418348451692544e+38,
3.4028234663852885981170418348451692544e+38 }, { 0.0, 0.0, 0.0, 0.0 }, {
1.0e+0, 1.0e+0, 1.0e+0, 1.0e+0 }>;
for vector which doesn't, so it looks like a backend problem. For AVX we could
use vcmpnlt_uqps, but for < AVX there is no such insn.
[Bug fortran/94386] [10 Regression] FAIL: gfortran.dg/pr93365.f90
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94386 --- Comment #9 from Paul Thomas --- > > These were both clean builds run on a powerpc64 power8 LE machine. > > The patch committed to fix(?) PR94246 reverted the code that fixed > PR93665 and PR93600 without removing the now failing testcases and > re-opening the now unfixed PR93665 and PR93600. %len and %kind > need to be special cased. See, Oh, I don't know maybe the removed > comments in the diff. Aaaah! OK, this a sign of my complete and utter incompetence with using git. Could somebody please point me to the prescription for fixing this? g:7d57570b0658b8c1b8a97dafa53dfd4ab4bd3f65, r10-7444 points to my intended commit and nothing else. I would also like to know how I could have done this since git normally complains vociferously if I try to violate HEAD by doing things in the wrong order. Est mea maxima culpa, sed nescio quomodo me fecit ... Paul
[Bug rtl-optimization/94421] [memory free] bug related to predication speculative schedule
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94421 --- Comment #3 from otcmaf --- (In reply to Andrew Pinski from comment #1) > change_spec_dep_to_hard is called from two places: > * in sched_analyze_insn, it is conditionalized on (current_sched_info->flags > & DO_SPECULATION) already. > * in update_dep, it is conditionalized on if was_spec was true and if no > longer dep_spec_p (dep) is true. > > dep_spec_p is true when current_sched_info->flags & DO_SPECULATION is true > (or when a few other cases. > > But DEP_STATUS (dep) can only be SPECULATIVE when current_sched_info->flags > & DO_SPECULATION is true. > > So If anything you could in theory put an assert there for > current_sched_info->flags & DO_SPECULATION and get the same effect if I read > the code correctly. In our case, the compile bug is called from function update_dep. Variable was_spec is true, dep_spec_p (dep) is false, current_sched_info->flags & DO_SPECULATION is zero, DEP_STATUS (dep) & SPECULATIVE is zero. So in this case, we should avoid to free the memory of spec_dependency_cache. 1191 if (was_spec && !dep_spec_p (dep)) 1192/* The old dep was speculative, but now it isn't. */ 1193change_spec_dep_to_hard (sd_it); 1194 (gdb) p was_spec $11 = true (gdb) p dep_spec_p (dep) $12 = false (gdb) p current_sched_info->flags & DO_SPECULATION $13 = 0 (gdb) p DEP_STATUS (dep) & SPECULATIVE $14 = 0 (gdb) p !dep_spec_p (dep) $15 = true
[Bug rtl-optimization/94421] [memory free] bug related to predication speculative schedule
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94421 otcmaf changed: What|Removed |Added CC||xuemaosheng at huawei dot com --- Comment #2 from otcmaf --- In our case, the compile bug is called from function update_dep. Variable was_spec is true, dep_spec_p (dep) is false, current_sched_info->flags & DO_SPECULATION is zero, DEP_STATUS (dep) & SPECULATIVE is zero. So in this case, we should avoid to free the memory of spec_dependency_cache. 1191 if (was_spec && !dep_spec_p (dep)) 1192/* The old dep was speculative, but now it isn't. */ 1193change_spec_dep_to_hard (sd_it); 1194 (gdb) p was_spec $11 = true (gdb) p dep_spec_p (dep) $12 = false (gdb) p current_sched_info->flags & DO_SPECULATION $13 = 0 (gdb) p DEP_STATUS (dep) & SPECULATIVE $14 = 0 (gdb) p !dep_spec_p (dep) $15 = true
[Bug rtl-optimization/94421] [memory free] bug related to predication speculative schedule
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94421 --- Comment #1 from Andrew Pinski --- change_spec_dep_to_hard is called from two places: * in sched_analyze_insn, it is conditionalized on (current_sched_info->flags & DO_SPECULATION) already. * in update_dep, it is conditionalized on if was_spec was true and if no longer dep_spec_p (dep) is true. dep_spec_p is true when current_sched_info->flags & DO_SPECULATION is true (or when a few other cases. But DEP_STATUS (dep) can only be SPECULATIVE when current_sched_info->flags & DO_SPECULATION is true. So If anything you could in theory put an assert there for current_sched_info->flags & DO_SPECULATION and get the same effect if I read the code correctly.
[Bug libstdc++/94418] Please make reverse_iterator nothrow constructible when possible
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94418 Richard Biener changed: What|Removed |Added Severity|normal |enhancement Component|c++ |libstdc++ Version|unknown |10.0
[Bug middle-end/49774] [meta-bug] restrict qualification aliasing issues
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49774 Bug 49774 depends on bug 94416, which changed state. Bug 94416 Summary: passing a restricted pointer to a function can be assumed not to modify an accessed object https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94416 What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE
[Bug tree-optimization/94416] passing a restricted pointer to a function can be assumed not to modify an accessed object
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94416 Richard Biener changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Blocks||49774 Resolution|--- |DUPLICATE --- Comment #1 from Richard Biener --- I think there's a duplicate somewhere. We currently cannot encode "restrict" into the "accesses" implied by a call. Note there's slight complication when g (b) eventually recurses into 'f' passing this 'b' as 'a'. Recursion makes the interpretation of the lexically defined restrict concept a bit weird. So I think this bug can be closed as duplicate of the "restrict and calls" bug. *** This bug has been marked as a duplicate of bug 89479 *** Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49774 [Bug 49774] [meta-bug] restrict qualification aliasing issues
[Bug tree-optimization/89479] __restrict on a pointer ignored when disambiguating against a call
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89479 Richard Biener changed: What|Removed |Added CC||msebor at gcc dot gnu.org --- Comment #9 from Richard Biener --- *** Bug 94416 has been marked as a duplicate of this bug. ***
[Bug sanitizer/94307] Provide a way to declare the *SAN exception handler -fsanitize-undefined-trap-on-error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94307
--- Comment #6 from Martin Liška ---
(In reply to Kees Cook from comment #5)
> Hi! I recently learned that Clang has -fsanitizer-minimal-runtime that is
> very close to what I was expecting to use:
>
> https://bugs.llvm.org/show_bug.cgi?id=45295
Looking at the implementation, you'll still have to implement ~50 entry points:
#define HANDLER_RECOVER(name, msg) \
INTERFACE void __ubsan_handle_##name##_minimal() { \
if (!report_this_error(__builtin_return_address(0))) return; \
message("ubsan: " msg "\n"); \
}
#define HANDLER_NORECOVER(name, msg) \
INTERFACE void __ubsan_handle_##name##_minimal_abort() { \
message("ubsan: " msg "\n"); \
abort_with_message("ubsan: " msg); \
}
#define HANDLER(name, msg) \
HANDLER_RECOVER(name, msg) \
HANDLER_NORECOVER(name, msg)
HANDLER(type_mismatch, "type-mismatch")
HANDLER(alignment_assumption, "alignment-assumption")
HANDLER(add_overflow, "add-overflow")
HANDLER(sub_overflow, "sub-overflow")
HANDLER(mul_overflow, "mul-overflow")
HANDLER(negate_overflow, "negate-overflow")
HANDLER(divrem_overflow, "divrem-overflow")
HANDLER(shift_out_of_bounds, "shift-out-of-bounds")
HANDLER(out_of_bounds, "out-of-bounds")
HANDLER_RECOVER(builtin_unreachable, "builtin-unreachable")
HANDLER_RECOVER(missing_return, "missing-return")
HANDLER(vla_bound_not_positive, "vla-bound-not-positive")
HANDLER(float_cast_overflow, "float-cast-overflow")
HANDLER(load_invalid_value, "load-invalid-value")
HANDLER(invalid_builtin, "invalid-builtin")
HANDLER(function_type_mismatch, "function-type-mismatch")
HANDLER(implicit_conversion, "implicit-conversion")
HANDLER(nonnull_arg, "nonnull-arg")
HANDLER(nonnull_return, "nonnull-return")
HANDLER(nullability_arg, "nullability-arg")
HANDLER(nullability_return, "nullability-return")
HANDLER(pointer_overflow, "pointer-overflow")
HANDLER(cfi_check_fail, "cfi-check-fail")
>
> That is close to what you're already suggesting. Would it be possible to do
> the same thing? That way the kernel can have just one "not the full debug
> details" handler.
Well, it can be possible to implement the same. But I would like to see first a
kernel discussion to happen. You can prepare a patch that will utilize clang
and their -fsanitizer-minimal-runtime and sent it to Kernel mailing list. Would
it be possible?
>
> Thanks for looking at this!
