[Bug target/84564] New: error: unable to find a register to spill with -mforce-indirect-call
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84564
Bug ID: 84564
Summary: error: unable to find a register to spill with
-mforce-indirect-call
Product: gcc
Version: unknown
Status: UNCONFIRMED
Keywords: ice-on-valid-code
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: marxin at gcc dot gnu.org
CC: ak at gcc dot gnu.org
Target Milestone: ---
Host: x86_64-unknown-linux-gnu
Target: i586-linux-gnu
Starting from r254560, we ICE on:
$ cat ./subsumption.i
int a, b;
int h (void);
static int c (int d, int f, int g)
{
while (a)
h () && c (d, f, g);
}
int x;
int i (void) { int e = c (x, b, e); }
$ gcc ./subsumption.i -O2 -mforce-indirect-call -c -m32
./subsumption.i: In function ‘i’:
./subsumption.i:9:1: error: unable to find a register to spill
int i (void) { int e = c (x, b, e); }
^~~
./subsumption.i:9:1: error: this is the insn:
(call_insn/j 9 18 10 2 (set (reg:SI 0 ax)
(call (mem:QI (reg/f:SI 92 [91]) [0 c S1 A8])
(const_int 0 [0]))) "./subsumption.i":9 693 {*sibcall_value}
(expr_list:REG_DEAD (reg/f:SI 92 [91])
(expr_list:REG_DEAD (reg:SI 2 cx)
(expr_list:REG_DEAD (reg:SI 1 dx)
(expr_list:REG_CALL_DECL (symbol_ref:SI ("c") [flags 0x3]
)
(expr_list:REG_EH_REGION (const_int 0 [0])
(nil))
(expr_list:SI (use (reg:SI 0 ax))
(expr_list:SI (use (reg:SI 1 dx))
(expr_list:SI (use (reg:SI 2 cx))
(nil)
during RTL pass: reload
./subsumption.i:9:1: internal compiler error: in assign_by_spills, at
lra-assigns.c:1470
0x5b93a6 _fatal_insn(char const*, rtx_def const*, char const*, int, char
const*)
../../gcc/rtl-error.c:108
0xa48099 assign_by_spills
../../gcc/lra-assigns.c:1470
0xa48aa6 lra_assign()
../../gcc/lra-assigns.c:1664
0xa44134 lra(_IO_FILE*)
../../gcc/lra.c:2475
0x9f8561 do_reload
../../gcc/ira.c:5465
0x9f8561 execute
../../gcc/ira.c:5649
[Bug target/84564] error: unable to find a register to spill with -mforce-indirect-call
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84564 Martin Liška changed: What|Removed |Added Last reconfirmed||2018-2-26 Target Milestone|--- |8.0 Known to fail||8.0
[Bug target/84565] New: ICE in extract_insn, at recog.c:2304
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84565 Bug ID: 84565 Summary: ICE in extract_insn, at recog.c:2304 Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: marxin at gcc dot gnu.org CC: amker at gcc dot gnu.org Target Milestone: --- Host: x86_64-unknown-linux-gnu Target: aarch64-linux-gnu Following ICEs: $ aarch64-linux-gnu-gfortran /home/marxin/Programming/gcc/gcc/testsuite/gfortran.dg/errnocheck_1.f90 -mlow-precision-sqrt -funsafe-math-optimizations -c /home/marxin/Programming/gcc/gcc/testsuite/gfortran.dg/errnocheck_1.f90:7:0: end subroutine Error: unrecognizable insn: (insn 8 7 9 2 (set (reg:DI 93) (neg:DI (eq:DI (reg:DF 90 [ _1 ]) (const_double:DF 0.0 [0x0.0p+0] "/home/marxin/Programming/gcc/gcc/testsuite/gfortran.dg/errnocheck_1.f90":6 -1 (nil)) during RTL pass: vregs /home/marxin/Programming/gcc/gcc/testsuite/gfortran.dg/errnocheck_1.f90:7:0: internal compiler error: in extract_insn, at recog.c:2304 0x5b09bd _fatal_insn(char const*, rtx_def const*, char const*, int, char const*) .././../gcc/rtl-error.c:108 0x5b09dc _fatal_insn_not_found(rtx_def const*, char const*, int, char const*) .././../gcc/rtl-error.c:116 0xb98c87 extract_insn(rtx_insn*) .././../gcc/recog.c:2304 0x93ea31 instantiate_virtual_regs_in_insn .././../gcc/function.c:1599 0x93ea31 instantiate_virtual_regs .././../gcc/function.c:1969 0x93ea31 execute .././../gcc/function.c:2018
[Bug target/84565] ICE in extract_insn, at recog.c:2304 on aarch64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84565 Martin Liška changed: What|Removed |Added Target Milestone|--- |8.0 Summary|ICE in extract_insn, at |ICE in extract_insn, at |recog.c:2304|recog.c:2304 on aarch64 Known to fail||8.0
[Bug rtl-optimization/84566] New: error: qsort comparator not anti-commutative: -1, -1 on aarch64 in sched1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84566 Bug ID: 84566 Summary: error: qsort comparator not anti-commutative: -1, -1 on aarch64 in sched1 Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: rtl-optimization Assignee: unassigned at gcc dot gnu.org Reporter: marxin at gcc dot gnu.org CC: amonakov at gcc dot gnu.org Target Milestone: --- Host: x86_64-unknown-linux-gnu Target: aarch64-linux-gnu Following ICEs: $ aarch64-linux-gnu-g++ /home/marxin/Programming/gcc/gcc/testsuite/g++.old-deja/g++.other/crash15.C /dev/null -mcpu=cortex-a35 -O2 -fselective-scheduling /home/marxin/Programming/gcc/gcc/testsuite/g++.old-deja/g++.other/crash15.C: In function ‘void test05()’: /home/marxin/Programming/gcc/gcc/testsuite/g++.old-deja/g++.other/crash15.C:43:1: error: qsort comparator not anti-commutative: -1, -1 } ^ during RTL pass: sched1 /home/marxin/Programming/gcc/gcc/testsuite/g++.old-deja/g++.other/crash15.C:43:1: internal compiler error: qsort checking failed 0x5e693a qsort_chk_error .././../gcc/vec.c:201 0x15781dd qsort_chk(void*, unsigned long, unsigned long, int (*)(void const*, void const*)) .././../gcc/vec.c:255 0xd77de4 vec<_expr*, va_heap, vl_embed>::qsort(int (*)(void const*, void const*)) .././../gcc/vec.h:1054 0xd77de4 vec<_expr*, va_heap, vl_ptr>::qsort(int (*)(void const*, void const*)) .././../gcc/vec.h:1816 0xd77de4 fill_vec_av_set .././../gcc/sel-sched.c:3953 0xd78df3 fill_ready_list .././../gcc/sel-sched.c:4027 0xd78df3 find_best_expr .././../gcc/sel-sched.c:4387 0xd78df3 fill_insns .././../gcc/sel-sched.c:5544 0xd7af80 schedule_on_fences .././../gcc/sel-sched.c:7361 0xd7af80 sel_sched_region_2 .././../gcc/sel-sched.c:7499 0xd7d4b1 sel_sched_region_1 .././../gcc/sel-sched.c:7541 0xd7d4b1 sel_sched_region(int) .././../gcc/sel-sched.c:7642 0xd7da99 run_selective_scheduling() .././../gcc/sel-sched.c:7718 0xd5a45d rest_of_handle_sched .././../gcc/sched-rgn.c:3715 0xd5a45d execute .././../gcc/sched-rgn.c:3825
[Bug tree-optimization/84567] New: ICE in vectorize_fold_left_reduction, at tree-vect-loop.c:6224
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84567 Bug ID: 84567 Summary: ICE in vectorize_fold_left_reduction, at tree-vect-loop.c:6224 Product: gcc Version: unknown Status: UNCONFIRMED Keywords: ice-on-valid-code Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: marxin at gcc dot gnu.org CC: amker at gcc dot gnu.org, richard.sandiford at linaro dot org Target Milestone: --- Host: x86_64-unknown-linux-gnu Target: aarch64-linux-gnu Following ICEs: $ aarch64-linux-gnu-gcc /home/marxin/Programming/gcc/gcc/testsuite/gcc.dg/torture/pr82473.c /dev/null -ftrapv -O3 during GIMPLE pass: vect /home/marxin/Programming/gcc/gcc/testsuite/gcc.dg/torture/pr82473.c: In function ‘zz’: /home/marxin/Programming/gcc/gcc/testsuite/gcc.dg/torture/pr82473.c:5:1: internal compiler error: in vectorize_fold_left_reduction, at tree-vect-loop.c:6224 zz (int x9, short int gt) ^~ 0xe4facc vectorize_fold_left_reduction .././../gcc/tree-vect-loop.c:6223 0xe4facc vectorizable_reduction(gimple*, gimple_stmt_iterator*, gimple**, _slp_tree*, _slp_instance*) .././../gcc/tree-vect-loop.c:7375 0xe42a17 vect_transform_stmt(gimple*, gimple_stmt_iterator*, bool*, _slp_tree*, _slp_instance*) .././../gcc/tree-vect-stmts.c:9521 0xe6ace8 vect_schedule_slp_instance .././../gcc/tree-vect-slp.c:4187 0xe6b474 vect_schedule_slp(vec_info*) .././../gcc/tree-vect-slp.c:4256 0xe51b35 vect_transform_loop(_loop_vec_info*) .././../gcc/tree-vect-loop.c:8881 0xe723f3 vectorize_loops() .././../gcc/tree-vectorizer.c:740
[Bug tree-optimization/84567] ICE in vectorize_fold_left_reduction, at tree-vect-loop.c:6224
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84567 Martin Liška changed: What|Removed |Added Last reconfirmed||2018-2-26 Target Milestone|--- |8.0 Known to fail||8.0
[Bug gcov-profile/84548] [8 regression] gcov ICE in process_file, at gcov.c:1154
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84548 Martin Liška changed: What|Removed |Added Priority|P3 |P1 Status|ASSIGNED|WAITING Known to work||8.0 Target Milestone|--- |8.0 Known to fail||7.2.0 --- Comment #3 from Martin Liška --- So I can really confirm that. There're 2 functions starting on the same line & column: gcov-dump -l x.gcno | grep _ZN24CryptDefaultProviderTest15addTestsToSuiteERN7CppUnit27TestSuiteBuilderContextBaseE x.gcno: 0100: 52:FUNCTION ident=851573668, lineno_checksum=0x94de0233, cfg_checksum=0xb3ccce62, `_ZN24CryptDefaultProviderTest15addTestsToSuiteERN7CppUnit27TestSuiteBuilderContextBaseE' /home/dimhen/src/CSPbuild/CSP/unittest/CpCapi20UnitTest/CryptDefaultProviderTest.h:18:5:20 gcov-dump -l x.gcno | grep _ZN24CryptDefaultProviderTest14getTestNamer__Ev x.gcno: 0100: 42:FUNCTION ident=106335, lineno_checksum=0x6adcbc1d, cfg_checksum=0x44818b72, `_ZN24CryptDefaultProviderTest14getTestNamer__Ev' /home/dimhen/src/CSPbuild/CSP/unittest/CpCapi20UnitTest/CryptDefaultProviderTest.h:18:5:18 It would really help me if you could attach pre-processed source file (using -E option).
[Bug c++/84533] [7/8 Regression] ICE with duplicate enum value
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84533 Paolo Carlini changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2018-02-26 Assignee|unassigned at gcc dot gnu.org |paolo.carlini at oracle dot com Ever confirmed|0 |1 --- Comment #1 from Paolo Carlini --- Mine.
[Bug gcov-profile/28564] gcov fails to store the absolute path to the source files
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=28564 Martin Liška changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |marxin at gcc dot gnu.org Target Milestone|--- |9.0 --- Comment #3 from Martin Liška --- Then let me do that in GCC 9.
[Bug target/82862] [8 Regression] SPEC CPU2006 465.tonto performance regression with r253975 (up to 40% drop for particular loop)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82862 Richard Biener changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |FIXED --- Comment #9 from Richard Biener --- Fixed.
[Bug libgomp/84466] [8 regression] libgomp.graphite/force-parallel-8.c fails starting with r257723
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84466 Richard Biener changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org Target Milestone|--- |8.0 --- Comment #2 from Richard Biener --- Mine.
[Bug tree-optimization/84567] ICE in vectorize_fold_left_reduction, at tree-vect-loop.c:6224
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84567 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #1 from Jakub Jelinek --- Dup of PR83965?
[Bug tree-optimization/84567] ICE in vectorize_fold_left_reduction, at tree-vect-loop.c:6224
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84567 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #2 from Martin Liška --- Dup. *** This bug has been marked as a duplicate of bug 83965 ***
[Bug tree-optimization/83965] [8 Regression] ICE in vectorize_fold_left_reduction, at tree-vect-loop.c:6154
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83965 --- Comment #5 from Martin Liška --- *** Bug 84567 has been marked as a duplicate of this bug. ***
[Bug target/84521] [8 Regression] aarch64: Frame-pointer corruption with __builtin_setjmp/__builtin_longjmp and -fomit-frame-pointer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84521 --- Comment #15 from Ramana Radhakrishnan --- Author: ramana Date: Mon Feb 26 09:25:21 2018 New Revision: 257984 URL: https://gcc.gnu.org/viewcvs?rev=257984&root=gcc&view=rev Log: [Patch AArch64] Turn on frame pointer / partial fix for PR84521 This fixes a GCC-8 regression that we accidentally switched off frame pointers in the AArch64 backend when changing the defaults in the common parts of the code. This breaks an ABI decision that was made in GCC at the dawn of the port with respect to having a frame pointer at all times. If we really want to turn this off lets have a discussion around that separately. For now turn this back on and I believe this will leave PR84521 latent again with -fomit-frame-pointer and (hopefully) make the ruby issue go away. I'm asking Sudi to pick that up. Bootstrapped and regression tested on AArch64-none-linux-gnu but I see one regression in gcc.c-torture/execute/960419-2.c which needs to be looked at next (PR84528, thanks Kyrill). Ok to put in and then look at PR84528 ? 2018-02-26 Ramana Radhakrishnan PR target/84521 * common/config/aarch64/aarch64-common.c (aarch_option_optimization_table[]): Switch off fomit-frame-pointer 2018-02-26 Ramana Radhakrishnan PR target/84521 * gcc.target/aarch64/lr_free_2.c: Revert changes in r254814 disabling -fomit-frame-pointer by default. * gcc.target/aarch64/spill_1.c: Likewise. * gcc.target/aarch64/test_frame_11.c: Likewise. * gcc.target/aarch64/test_frame_12.c: Likewise. * gcc.target/aarch64/test_frame_13.c: Likewise. * gcc.target/aarch64/test_frame_14.c: Likewise. * gcc.target/aarch64/test_frame_15.c: Likewise. * gcc.target/aarch64/test_frame_3.c: Likewise. * gcc.target/aarch64/test_frame_5.c: Likewise. * gcc.target/aarch64/test_frame_9.c: Likewise. Modified: trunk/gcc/ChangeLog trunk/gcc/common/config/aarch64/aarch64-common.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.target/aarch64/lr_free_2.c trunk/gcc/testsuite/gcc.target/aarch64/spill_1.c trunk/gcc/testsuite/gcc.target/aarch64/test_frame_11.c trunk/gcc/testsuite/gcc.target/aarch64/test_frame_12.c trunk/gcc/testsuite/gcc.target/aarch64/test_frame_13.c trunk/gcc/testsuite/gcc.target/aarch64/test_frame_14.c trunk/gcc/testsuite/gcc.target/aarch64/test_frame_15.c trunk/gcc/testsuite/gcc.target/aarch64/test_frame_3.c trunk/gcc/testsuite/gcc.target/aarch64/test_frame_5.c trunk/gcc/testsuite/gcc.target/aarch64/test_frame_9.c
[Bug c/84229] A valid code rejected with -flto
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84229 Richard Biener changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Version|unknown |8.0.1 Resolution|--- |FIXED --- Comment #6 from Richard Biener --- So fixed? I agree that IPA mucking with functions relying on inlining (all functions with __builtin_va_arg_pack_* stuff are supposed to be always_inline!) is pointless. Of course at the time of IPA those functions should already be inlined everywhere and we shouldn't end up emitting their bodies un-inlined. In fact the bodies should have been reclaimed and not entered IPA? Of course if it is "IPA" SRA then yeah, that should simply ignore all always-inline functions anyway.
[Bug rtl-optimization/83327] Spilling into hard regs not taken into account in lra liveness analysis
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83327 --- Comment #11 from Tom de Vries --- (In reply to Vladimir Makarov from comment #10) > Any news about the patch testing on MIPS. It would be nice to move forward > with the PR. Pinged Matthew here: https://gcc.gnu.org/ml/gcc-patches/2018-02/msg01392.html
[Bug c/84229] A valid code rejected with -flto
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84229 --- Comment #7 from Jan Hubicka --- I am not sure it is really fixed. We no longer ICE, howeverw we need backporting to release branches and also I think we miss fortification whenever we fail to inline (that is with -Os). I have some patches to inline more of these fortify wrappers, but still not all of them.
[Bug fortran/32957] C/Fortran interoperability and -fdefault-integer-8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=32957 --- Comment #6 from dominiq at gcc dot gnu.org --- Author: dominiq Date: Mon Feb 26 09:55:39 2018 New Revision: 257985 URL: https://gcc.gnu.org/viewcvs?rev=257985&root=gcc&view=rev Log: 2018-02-26 Dominique d'Humieres PR fortran/32957 * gfortran.dg/c_f_pointer_shape_tests_2.f03: Use explicit KIND c_int. * gfortran.dg/c_f_pointer_shape_tests_4.f03: Likewise. * gfortran.dg/c_funloc_tests_3.f03: Likewise. * gfortran.dg/c_loc_test.f90: Likewise. * gfortran.dg/c_loc_tests_2.f03: Likewise. * gfortran.dg/proc_decl_17.f90: Likewise. * gfortran.dg/proc_ptr_8.f90: Likewise. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gfortran.dg/c_f_pointer_shape_tests_2.f03 trunk/gcc/testsuite/gfortran.dg/c_f_pointer_shape_tests_4.f03 trunk/gcc/testsuite/gfortran.dg/c_funloc_tests_3.f03 trunk/gcc/testsuite/gfortran.dg/c_loc_test.f90 trunk/gcc/testsuite/gfortran.dg/c_loc_tests_2.f03 trunk/gcc/testsuite/gfortran.dg/proc_decl_17.f90 trunk/gcc/testsuite/gfortran.dg/proc_ptr_8.f90
[Bug libstdc++/84568] New: libstdc++-v3 configure checks for atomic operations fail on riscv
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84568 Bug ID: 84568 Summary: libstdc++-v3 configure checks for atomic operations fail on riscv Product: gcc Version: 8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: sch...@linux-m68k.org Target Milestone: --- Target: riscv*-*-* checking for atomic builtins for bool... no checking for atomic builtins for short... no checking for atomic builtins for int... yes checking for atomic builtins for long long... yes configure: WARNING: No native atomic operations are provided for this platform. configure: WARNING: They will be faked using a mutex. configure: WARNING: Performance of certain classes will degrade as a result. This is due to -latomic not being linked in.
[Bug libstdc++/84568] libstdc++-v3 configure checks for atomic operations fail on riscv
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84568 Andreas Schwab changed: What|Removed |Added Target Milestone|--- |8.0
[Bug c/84229] A valid code rejected with -flto
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84229 --- Comment #8 from rguenther at suse dot de --- On Mon, 26 Feb 2018, hubicka at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84229 > > --- Comment #7 from Jan Hubicka --- > I am not sure it is really fixed. We no longer ICE, howeverw we need > backporting to release branches and also I think we miss fortification > whenever > we fail to inline (that is with -Os). I have some patches to inline more of > these fortify wrappers, but still not all of them. The fortify wrappers are all extern inline __attribute__((gnu_inline)). The glibc ones, that is.
[Bug c/84229] A valid code rejected with -flto
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84229 --- Comment #9 from Jan Hubicka --- > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84229 > > --- Comment #8 from rguenther at suse dot de --- > On Mon, 26 Feb 2018, hubicka at gcc dot gnu.org wrote: > > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84229 > > > > --- Comment #7 from Jan Hubicka --- > > I am not sure it is really fixed. We no longer ICE, howeverw we need > > backporting to release branches and also I think we miss fortification > > whenever > > we fail to inline (that is with -Os). I have some patches to inline more of > > these fortify wrappers, but still not all of them. > > The fortify wrappers are all extern inline __attribute__((gnu_inline)). > The glibc ones, that is. Well, the bug did reproduce for me on firefox build where we did not early inline fortify wrapper for open and later we tried to be smart to clone it for common parameters. Honza
[Bug c++/84556] C++17, lambda, OpenMP simd: sorry, unimplemented: unexpected AST
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84556 --- Comment #1 from Jakub Jelinek --- Author: jakub Date: Mon Feb 26 10:18:31 2018 New Revision: 257986 URL: https://gcc.gnu.org/viewcvs?rev=257986&root=gcc&view=rev Log: PR c++/84556 * g++.dg/gomp/pr84556.C: New test. * g++.dg/vect/pr84556.cc: New test. Added: trunk/gcc/testsuite/g++.dg/gomp/pr84556.C trunk/gcc/testsuite/g++.dg/vect/pr84556.cc Modified: trunk/gcc/testsuite/ChangeLog
[Bug c++/84556] C++17, lambda, OpenMP simd: sorry, unimplemented: unexpected AST
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84556 --- Comment #2 from Jakub Jelinek --- Fixed by r257820 on the trunk already.
[Bug c++/84430] [7 Regression] ICE with #pragma omp simd in lambda
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84430 Jakub Jelinek changed: What|Removed |Added CC||bisqwit at iki dot fi --- Comment #5 from Jakub Jelinek --- *** Bug 84556 has been marked as a duplicate of this bug. ***
[Bug gcov-profile/84548] [8 regression] gcov ICE in process_file, at gcov.c:1154
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84548 --- Comment #4 from Dmitry G. Dyachenko --- Created attachment 43502 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43502&action=edit preproccessed src file
[Bug c++/84556] C++17, lambda, OpenMP simd: sorry, unimplemented: unexpected AST
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84556 Jakub Jelinek changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||jakub at gcc dot gnu.org Resolution|--- |DUPLICATE --- Comment #3 from Jakub Jelinek --- Dup. *** This bug has been marked as a duplicate of bug 84430 ***
[Bug c/84229] A valid code rejected with -flto
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84229
--- Comment #10 from rguenther at suse dot de ---
On Mon, 26 Feb 2018, hubicka at ucw dot cz wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84229
>
> --- Comment #9 from Jan Hubicka ---
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84229
> >
> > --- Comment #8 from rguenther at suse dot de ---
> > On Mon, 26 Feb 2018, hubicka at gcc dot gnu.org wrote:
> >
> > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84229
> > >
> > > --- Comment #7 from Jan Hubicka ---
> > > I am not sure it is really fixed. We no longer ICE, howeverw we need
> > > backporting to release branches and also I think we miss fortification
> > > whenever
> > > we fail to inline (that is with -Os). I have some patches to inline more
> > > of
> > > these fortify wrappers, but still not all of them.
> >
> > The fortify wrappers are all extern inline __attribute__((gnu_inline)).
> > The glibc ones, that is.
>
> Well, the bug did reproduce for me on firefox build where we did not early
> inline fortify wrapper for open and later we tried to be smart to clone it
> for common parameters.
I thought we now force all always-inline inlining to happen during
early inlining? So I wonder how this happened...
For me open is (with -D_FORTIFY_SOURCE=2)
extern __inline __attribute__ ((__always_inline__)) __attribute__
((__gnu_inline__)) __attribute__ ((__artificial__)) int
open (const char *__path, int __oflag, ...)
{
if (__builtin_va_arg_pack_len () > 1)
__open_too_many_args ();
if (__builtin_constant_p (__oflag))
{
if __oflag) & 0100) != 0 || ((__oflag) & (02000 | 020))
== (02000 | 020)) && __builtin_va_arg_pack_len () < 1)
{
__open_missing_mode ();
return __open_2 (__path, __oflag);
}
return __open_alias (__path, __oflag, __builtin_va_arg_pack ());
}
if (__builtin_va_arg_pack_len () < 1)
return __open_2 (__path, __oflag);
return __open_alias (__path, __oflag, __builtin_va_arg_pack ());
}
but of course also declared before that as
extern int open (const char *__file, int __oflag, ...) __attribute__
((__nonnull__ (1)));
so I wonder how the firefox issue manifests itself exactly...
[Bug rtl-optimization/83327] Spilling into hard regs not taken into account in lra liveness analysis
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83327 mpf at gcc dot gnu.org changed: What|Removed |Added CC||mpf at gcc dot gnu.org --- Comment #12 from mpf at gcc dot gnu.org --- (In reply to Tom de Vries from comment #11) > (In reply to Vladimir Makarov from comment #10) > > Any news about the patch testing on MIPS. It would be nice to move forward > > with the PR. > > Pinged Matthew here: https://gcc.gnu.org/ml/gcc-patches/2018-02/msg01392.html Hi Tom, Sorry for my general lack of engagement I'm struggling to do much at all to support the community at the moment. I have set off a couple of builds to target MIPS16; I don't have any recipe for bootstrapping with MIPS16 enabled so the most efficient way I can give some assurance is just the GCC testsuite run cross compiled with a simulator. I've started two build of GCC without and with the patch and will aim to report back on the testsuite runs as soon as I can. Matthew
[Bug rtl-optimization/84566] error: qsort comparator not anti-commutative: -1, -1 on aarch64 in sched1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84566 --- Comment #1 from Alexander Monakov --- Sorry, I cannot reproduce this. I've built a cross-compiler from today's trunk via 'configure --target aarch64-linux-gnu && make all-gcc' (i.e. just to cc1plus, no binutils etc.) and it doesn't abort. If possible please add 'g++ -v' output, svn revision, and any other info that can help me reproduce the issue.
[Bug rtl-optimization/84566] error: qsort comparator not anti-commutative: -1, -1 on aarch64 in sched1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84566 --- Comment #2 from Alexander Monakov --- Bah, built a wrong branch, not the trunk. I'll recheck later, sorry for the noise.
[Bug c++/84569] New: g++ -g -O3 consumes all memory
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84569 Bug ID: 84569 Summary: g++ -g -O3 consumes all memory Product: gcc Version: 6.4.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: jorrit at jorrit dot de Target Milestone: --- Created attachment 43503 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43503&action=edit reduced test case Compiling the attached reduced test-case with -g -O3 eats more than 14G memory (at which point I killed the compilation). Compiling with -g -O2 or with -g -O3 -fno-var-tracking works fine. This bug behaves similar to https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77844 and was triggered the same of our unit tests, except that the reduced test of 77844 does not trigger with g++ 6.3. Bug triggers with: - g++ (Ubuntu 5.4.1-2ubuntu1~16.04) 5.4.1 20160904 from Ubuntu 16.04.3 - g++ (Debian 6.3.0-18+deb9u1) 6.3.0 20170516 from Debian stretch - g++ (GCC) 6.4.0 from https://hub.docker.com/_/gcc/ (:6.4) Bug does not trigger with: - g++-7 (Ubuntu 7.2.0-1ubuntu1~16.04) 7.2.0 from http://ppa.launchpad.net/ubuntu-toolchain-r/test/ubuntu xenial/main - g++ (GCC) 7.3.0 from https://hub.docker.com/_/gcc/ (:latest) See also: - The corresponding bug in our gitlab https://gitlab.dune-project.org/core/dune-common/issues/115 - The old, similar GCC bug https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77844 - The bug in our gitlab corresponding to the old GCC bug https://gitlab.dune-project.org/flyspray/FS/issues/1668
[Bug gcov-profile/84548] [8 regression] gcov ICE in process_file, at gcov.c:1154
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84548 Dmitry G. Dyachenko changed: What|Removed |Added Attachment #43502|0 |1 is obsolete|| --- Comment #5 from Dmitry G. Dyachenko --- Created attachment 43504 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43504&action=edit pre-processed src file sorry, correct file now
[Bug gcov-profile/84548] [8 regression] gcov ICE in process_file, at gcov.c:1154
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84548 --- Comment #6 from Martin Liška --- Ok, and please can you attach full command line how you invoke that?
[Bug gcov-profile/84548] [8 regression] gcov ICE in process_file, at gcov.c:1154
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84548 --- Comment #7 from Dmitry G. Dyachenko --- g++ -DHAVE_CONFIG_H -I. -I/home/dimhen/src/CSPbuild/CSP/unittest/CpCapi20UnitTest -I../../.. -I/home/dimhen/src/CSPbuild -I/home/dimhen/src/CSPbuild/CSP/src/include -I/home/dimhen/src/CSPbuild/shared/include -I/home/dimhen/src/CSPbuild/shared/include/atl -I/home/dimhen/src/CSPbuild/reader/include -I/home/dimhen/src/CSPbuild/CSP/capilite -I /usr/local/cppunit-1.13.2/8/debug/include/ -I/usr/local/include -DDEBUG -DUNIX -DLINUX -DENABLE_VALGRIND_CHECKING -Wall -Wno-deprecated-declarations -Wno-multistatement-macros -Wno-error=stringop-overflow -Wno-error=stringop-truncation -Wno-error=cast-function-type -Wrestrict -Wno-comment -Wno-unknown-pragmas -Wredundant-decls -Wpointer-arith -Wmissing-declarations -Wmissing-include-dirs -Wlogical-op -Wreturn-local-addr -Wunused-const-variable=1 -Wextra -Wno-missing-braces -Wno-missing-field-initializers -Werror -fchecking -std=c++98 -Wno-c++1z-compat -g -DNO_ASN1_RT_REDUNDANT -D_COMPACT -fvar-tracking -fvar-tracking-assignments -fno-common -O0 --coverage -fprofile-abs-path -pipe -DARITHM64 -m64 -fchecking -std=c++98 -Wno-c++1z-compat -Woverloaded-virtual -Wabi -MT cpcapi20suite.o -MD -MP -MF .deps/cpcapi20suite.Tpo -c -o cpcapi20suite.o /home/dimhen/src/CSPbuild/CSP/unittest/CpCapi20UnitTest/cpcapi20suite.cpp -E libtool: link: g++ -Wall -Wno-deprecated-declarations -Wno-multistatement-macros -Wno-error=stringop-overflow -Wno-error=stringop-truncation -Wno-error=cast-function-type -Wrestrict -Wno-comment -Wno-unknown-pragmas -Wredundant-decls -Wpointer-arith -Wmissing-declarations -Wmissing-include-dirs -Wlogical-op -Wreturn-local-addr -Wunused-const-variable=1 -Wextra -Wno-missing-braces -Wno-missing-field-initializers -Werror -fchecking -std=c++98 -Wno-c++1z-compat -g -DNO_ASN1_RT_REDUNDANT -D_COMPACT -fvar-tracking -fvar-tracking-assignments -fno-common -O0 --coverage -fprofile-abs-path -pipe -DARITHM64 -m64 -fchecking -std=c++98 -Wno-c++1z-compat -Woverloaded-virtual -Wabi -Wl,-z -Wl,noexecstack -Wl,--dynamic-linker=/lib64/ld-lsb-x86-64.so.3 --coverage -Wl,--dynamic-list-data -o .libs/CpCapi20UnitTest unittestmain.o CCmsTest.o CFindOIDInfoTest.o CReProvCrlInfoTest.o CCmsKeyIdTest.o cpcapi20suite.o CryptDefaultProviderTest.o -L/usr/local/cppunit-1.13.2/8/debug/lib/ /usr/local/cppunit-1.13.2/8/debug/lib/libcppunit.so ../../../CSP/capilite/.libs/libcapi20.so /home/dimhen/build/8/ccov/CSP/capilite/.libs/libcapi10.so /home/dimhen/build/8/ccov/CSP/capilite/.libs/liburlretrieve.so /home/dimhen/build/8/ccov/asn1/cpasn1/.libs/libcpasn1.so /home/dimhen/build/8/ccov/shared/cplib/.libs/libcplib.so ../../../CSP/capilite/.libs/libcapi10.so /home/dimhen/build/8/ccov/reader/source/support/.libs/librdrsup.so ../../../reader/source/support/.libs/librdrsup.so -ldl /usr/local/gcc_current/lib/../lib64/libstdc++.so -lm -lpthread -Wl,-rpath -Wl,/usr/local/cppunit-1.13.2/8/debug/lib -Wl,-rpath -Wl,/usr/local/gcc_current/lib/../lib64
[Bug gcov-profile/84548] [8 regression] gcov ICE in process_file, at gcov.c:1154
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84548 --- Comment #8 from Martin Liška --- Thanks and can you please attach also: /home/dimhen/src/CSPbuild/CSP/unittest/CpCapi20UnitTest/CryptDefaultProviderTest.h
[Bug gcov-profile/84548] [8 regression] gcov ICE in process_file, at gcov.c:1154
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84548 --- Comment #9 from Dmitry G. Dyachenko --- Created attachment 43505 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43505&action=edit header
[Bug c++/84569] [6 Regression] g++ -g -O3 consumes all memory
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84569 Martin Liška changed: What|Removed |Added Keywords||compile-time-hog Status|UNCONFIRMED |NEW Last reconfirmed||2018-02-26 CC||jakub at gcc dot gnu.org, ||marxin at gcc dot gnu.org Target Milestone|--- |6.6 Summary|g++ -g -O3 consumes all |[6 Regression] g++ -g -O3 |memory |consumes all memory Ever confirmed|0 |1 --- Comment #1 from Martin Liška --- Confirmed, fixed on trunk in r243662 (fix for PR77844). It's mentioned in the PR that gcc-6 branch is not affected. Looks it is. Jakub can you please take a look?
[Bug c++/84569] [6 Regression] g++ -g -O3 consumes all memory
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84569 --- Comment #2 from Jakub Jelinek --- Feel free to backport it if it is backportable.
[Bug c++/84569] [6 Regression] g++ -g -O3 consumes all memory
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84569 Martin Liška changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |marxin at gcc dot gnu.org --- Comment #3 from Martin Liška --- Ok, then I assign the PR.
[Bug fortran/84381] replace non-std 'call abort' by 'stop 1' in gfortran testsuite
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84381
Thomas Schwinge changed:
What|Removed |Added
Status|RESOLVED|REOPENED
CC||tschwinge at gcc dot gnu.org
Resolution|FIXED |---
--- Comment #9 from Thomas Schwinge ---
I suppose the same changes ("abort" -> "stop") should also be applied to the
libgomp Fortran test cases?
$ git grep -i abort upstream/trunk --
libgomp/testsuite/libgomp.{,oacc-}fortran/ | wc -l
2016
$ git grep -i fall-intrinsics upstream/trunk --
libgomp/testsuite/libgomp.{,oacc-}fortran/ | wc -l
2
Thus re-opened.
[Bug fortran/84094] several correctness issues in gfortran.dg
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84094 Bug 84094 depends on bug 84381, which changed state. Bug 84381 Summary: replace non-std 'call abort' by 'stop 1' in gfortran testsuite https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84381 What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED |---
[Bug target/84570] New: [og7, openacc, nvptx] Unused offloaded function parameters
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84570
Bug ID: 84570
Summary: [og7, openacc, nvptx] Unused offloaded function
parameters
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: vries at gcc dot gnu.org
Target Milestone: ---
Consider the following openacc program:
...
static
void foo(int n, int p[N][N])
{
int i, j, k;
#pragma acc parallel copy(p[0:N][0:N])
for (k = 0; k < n; k++)
{
#pragma acc loop gang
for (i = 0; i < n; i++)
for (j = 0; j < n; j++)
p[i][j] = ...;
}
}
...
The variables that are copied from host to accelerator are: n, i, j, k and *p.
The variables i, j and k are not initialized before the parallel region, nor is
the uninitialized value read in the parallel region, so the copy of these
variables is superfluous.
With the old approach where offloading functions where called with a single
pointer-to-struct argument, we wasted some global memory with this.
With the new "Use functional parameters for data mappings in OpenACC child
functions" approach in the og7 branch, we waste .param space with this.
Depending on the implementation, this may be global memory, but also something
else, which may make the wasting more costly.
Either way, the fact that all the arguments are now individually listed in the
function prototype makes it much easier to spot unused parameters.
[Bug c++/84557] ICE with invalid firstprivate variable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84557 Jakub Jelinek changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2018-02-26 Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Jakub Jelinek --- Created attachment 43506 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43506&action=edit gcc8-pr84557.patch Untested fix.
[Bug target/84571] New: [og7, openacc, nvptx] 32-bit value passed in 64 bits to offloading function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84571
Bug ID: 84571
Summary: [og7, openacc, nvptx] 32-bit value passed in 64 bits
to offloading function
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: vries at gcc dot gnu.org
Target Milestone: ---
Consider the following openacc program:
...
static
void foo(int n, int p[N][N])
{
#pragma acc parallel copy(p[0:N][0:N])
for (int k = 0; k < n; k++)
{
#pragma acc loop gang
for (int i = 0; i < n; i++)
for (int j = 0; j < n; j++)
p[i][j] = ...;
}
}
...
The offloaded function parameters are pointer p, and int n. For some reason, n
is passed as a 64-bit value:
...
.entry foo$_omp_fn$0 (.param .u64 %in_ar0, .param .u64 %in_ar1)
...
[Bug gcov-profile/84548] [8 regression] gcov ICE in process_file, at gcov.c:1154
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84548 Martin Liška changed: What|Removed |Added Status|WAITING |NEW --- Comment #10 from Martin Liška --- Thank you very much for help. So I see 2 problems: a) gcov.c wrong assumes that two functions starting at a same line must end on the same line -> it's wrong b) there's broken location map, because for your x.gcno file I see 2 functions starting as same line & column: CryptDefaultProviderTest.h:18:5:20 (addTestsToSuite) and CryptDefaultProviderTest.h:18:5:18 (getTestNamer__) and each ending at different line. That should not be possible. Is the project you are building public so I can build it locally and debug case b) ?
[Bug gcov-profile/84548] [8 regression] gcov ICE in process_file, at gcov.c:1154
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84548 --- Comment #11 from Dmitry G. Dyachenko --- (In reply to Martin Liška from comment #10) > Thank you very much for help. So I see 2 problems: ... > Is the project you are building public so I can build it locally and debug > case b) ? Alas, its proprietary project :( Maybe I may try to creduce it? And, alas, I will need some guidance -- I never creduce --coverage issues, only ICEs
[Bug gcov-profile/84548] [8 regression] gcov ICE in process_file, at gcov.c:1154
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84548 Martin Liška changed: What|Removed |Added Status|NEW |ASSIGNED --- Comment #12 from Martin Liška --- (In reply to Dmitry G. Dyachenko from comment #11) > (In reply to Martin Liška from comment #10) > > Thank you very much for help. So I see 2 problems: > ... > > Is the project you are building public so I can build it locally and debug > > case b) ? > > Alas, its proprietary project :( > > Maybe I may try to creduce it? > And, alas, I will need some guidance -- I never creduce --coverage issues, > only ICEs Ok, give me some time to cook a patch. I would be interested in how the patched GCC will then handle your project.
[Bug gcov-profile/84548] [8 regression] gcov ICE in process_file, at gcov.c:1154
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84548 --- Comment #13 from Dmitry G. Dyachenko --- Created attachment 43507 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43507&action=edit gcno+gcda: rebuild 2 functions at 18:5:18 and 4 at 20:5:20 Its issue b) -- I am understand correctly? cpcapi20suite.gcno: 0100: 40:FUNCTION ident=442525720, lineno_checksum=0xf28b54f7, cfg_checksum=0x879a122a, `CryptDefaultProviderTest::suite()' /home/dimhen/src/CSPbuild/CSP/unittest/CpCapi20UnitTest/CryptDefaultProviderTest.h:20:5:20 cpcapi20suite.gcno: 0100: 45:FUNCTION ident=1167046625, lineno_checksum=0x7b393d99, cfg_checksum=0xdb5de9e8, `CryptDefaultProviderTest::CppUnitExDeleter::release()' /home/dimhen/src/CSPbuild/CSP/unittest/CpCapi20UnitTest/CryptDefaultProviderTest.h:20:5:20 cpcapi20suite.gcno: 0100: 43:FUNCTION ident=750634865, lineno_checksum=0x336c2b17, cfg_checksum=0x819159b4, `CryptDefaultProviderTest::CppUnitExDeleter::~CppUnitExDeleter()' /home/dimhen/src/CSPbuild/CSP/unittest/CpCapi20UnitTest/CryptDefaultProviderTest.h:20:5:20 cpcapi20suite.gcno: 0100: 43:FUNCTION ident=1465838693, lineno_checksum=0xc88f0003, cfg_checksum=0xa43083b8, `CryptDefaultProviderTest::CppUnitExDeleter::CppUnitExDeleter()' /home/dimhen/src/CSPbuild/CSP/unittest/CpCapi20UnitTest/CryptDefaultProviderTest.h:20:5:20 cpcapi20suite.gcno: 0100: 52:FUNCTION ident=851573668, lineno_checksum=0x94de0233, cfg_checksum=0xb3ccce62, `CryptDefaultProviderTest::addTestsToSuite(CppUnit::TestSuiteBuilderContextBase&)' /home/dimhen/src/CSPbuild/CSP/unittest/CpCapi20UnitTest/CryptDefaultProviderTest.h:18:5:20 cpcapi20suite.gcno: 0100: 42:FUNCTION ident=106335, lineno_checksum=0x6adcbc1d, cfg_checksum=0x44818b72, `CryptDefaultProviderTest::getTestNamer__()' /home/dimhen/src/CSPbuild/CSP/unittest/CpCapi20UnitTest/CryptDefaultProviderTest.h:18:5:18
[Bug gcov-profile/84548] [8 regression] gcov ICE in process_file, at gcov.c:1154
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84548
--- Comment #14 from Martin Liška ---
Created attachment 43508
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43508&action=edit
Patch candidate
For reduced test-case:
$ cat test.cc
struct A { static int foo () { return 1; }; static int bar () {
int x;
return 2; } };
int main()
{
return A::foo () + A::bar ();
}
I now have:
$ cat test.cc.gcov
-:0:Source:test.cc
-:0:Graph:test.gcno
-:0:Data:test.gcda
-:0:Runs:1
-:0:Programs:1
2:1:struct A { static int foo () { return 1; }; static int bar () {
-:2: int x;
1:3: return 2; } };
--
_ZN1A3fooEv:
1:1:struct A { static int foo () { return 1; }; static int bar () {
--
_ZN1A3barEv:
1:1:struct A { static int foo () { return 1; }; static int bar () {
-:2: int x;
1:3: return 2; } };
--
-:4:
1:5:int main()
-:6:{
1:7: return A::foo () + A::bar ();
-:8:}
Which is correct in my opinion. Can you please Dmitry test the patch?
[Bug gcov-profile/84548] [8 regression] gcov ICE in process_file, at gcov.c:1154
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84548 --- Comment #15 from Martin Liška --- (In reply to Dmitry G. Dyachenko from comment #13) > Created attachment 43507 [details] > gcno+gcda: rebuild > > 2 functions at 18:5:18 > and 4 at 20:5:20 > > Its issue b) -- I am understand correctly? > > cpcapi20suite.gcno: 0100: 40:FUNCTION ident=442525720, > lineno_checksum=0xf28b54f7, cfg_checksum=0x879a122a, > `CryptDefaultProviderTest::suite()' > /home/dimhen/src/CSPbuild/CSP/unittest/CpCapi20UnitTest/ > CryptDefaultProviderTest.h:20:5:20 > cpcapi20suite.gcno: 0100: 45:FUNCTION ident=1167046625, > lineno_checksum=0x7b393d99, cfg_checksum=0xdb5de9e8, > `CryptDefaultProviderTest::CppUnitExDeleter::release()' > /home/dimhen/src/CSPbuild/CSP/unittest/CpCapi20UnitTest/ > CryptDefaultProviderTest.h:20:5:20 > cpcapi20suite.gcno: 0100: 43:FUNCTION ident=750634865, > lineno_checksum=0x336c2b17, cfg_checksum=0x819159b4, > `CryptDefaultProviderTest::CppUnitExDeleter::~CppUnitExDeleter()' > /home/dimhen/src/CSPbuild/CSP/unittest/CpCapi20UnitTest/ > CryptDefaultProviderTest.h:20:5:20 > cpcapi20suite.gcno: 0100: 43:FUNCTION ident=1465838693, > lineno_checksum=0xc88f0003, cfg_checksum=0xa43083b8, > `CryptDefaultProviderTest::CppUnitExDeleter::CppUnitExDeleter()' > /home/dimhen/src/CSPbuild/CSP/unittest/CpCapi20UnitTest/ > CryptDefaultProviderTest.h:20:5:20 ^--- these 4 are ok as they end on the same line > cpcapi20suite.gcno: 0100: 52:FUNCTION ident=851573668, > lineno_checksum=0x94de0233, cfg_checksum=0xb3ccce62, > `CryptDefaultProviderTest::addTestsToSuite(CppUnit:: > TestSuiteBuilderContextBase&)' > /home/dimhen/src/CSPbuild/CSP/unittest/CpCapi20UnitTest/ > CryptDefaultProviderTest.h:18:5:20 > cpcapi20suite.gcno: 0100: 42:FUNCTION ident=106335, > lineno_checksum=0x6adcbc1d, cfg_checksum=0x44818b72, > `CryptDefaultProviderTest::getTestNamer__()' > /home/dimhen/src/CSPbuild/CSP/unittest/CpCapi20UnitTest/ > CryptDefaultProviderTest.h:18:5:18 ^--- this is the problem, having same start line & column and one ending on a different line (18 vs. 20).
[Bug debug/84545] [8 regression] FAIL: g++.dg/debug/pr44182.C -gdwarf-2 -O2 (test for excess errors)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84545 Eric Botcazou changed: What|Removed |Added Target|hppa-unknown-linux-gnu |hppa-linux-gnu, ||sparc-linux-gnu Status|UNCONFIRMED |NEW Last reconfirmed||2018-02-26 CC||ebotcazou at gcc dot gnu.org Host|hppa-unknown-linux-gnu |hppa-linux-gnu, ||sparc-linux-gnu Target Milestone|--- |8.0 Summary|FAIL: |[8 regression] FAIL: |g++.dg/debug/pr44182.C |g++.dg/debug/pr44182.C |-gdwarf-2 -O2 (test for |-gdwarf-2 -O2 (test for |excess errors) |excess errors) Ever confirmed|0 |1 Build|hppa-unknown-linux-gnu |hppa-linux-gnu, ||sparc-linux-gnu --- Comment #1 from Eric Botcazou --- Visible on SPARC64/Linux too. Probably: 2018-02-19 Jakub Jelinek PR target/84146 * reg-notes.def (REG_CALL_ARG_LOCATION): New reg note. * insn-notes.def (NOTE_INSN_CALL_ARG_LOCATION): Remove. [...]
[Bug gcov-profile/84548] [8 regression] gcov ICE in process_file, at gcov.c:1154
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84548 --- Comment #16 from Dmitry G. Dyachenko --- (In reply to Martin Liška from comment #14) > Created attachment 43508 [details] > Patch candidate ... > Which is correct in my opinion. Can you please Dmitry test the patch? Thank you Martin! I'll try and report
[Bug c++/84325] [8 Regression] internal compiler error, in cxx_eval_constant_expression gcc/cp/constexpr.c:4740
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84325
--- Comment #5 from Marek Polacek ---
Unfortunately the patch for 83692 didn't fix it; the ICE now looks like:
$ ./cc1plus -quiet 84325.C
84325.C:10:45: internal compiler error: tree check: did not expect class
‘type’, have ‘type’ (record_type) in replace_placeholders_r, at cp/tree.c:3094
constexpr static seconds time_to_wait{10_s};
^
0x15d4e70 tree_not_class_check_failed(tree_node const*, tree_code_class, char
const*, int, char const*)
/home/marek/src/gcc/gcc/tree.c:9434
0x825fcb non_type_check(tree_node*, char const*, int, char const*)
/home/marek/src/gcc/gcc/tree.h:3311
0xac9308 replace_placeholders_r
/home/marek/src/gcc/gcc/cp/tree.c:3094
0x15dea23 walk_tree_1(tree_node**, tree_node* (*)(tree_node**, int*, void*),
void*, hash_set >*, tree_node*
(*)(tree_node**, int*, tree_node* (*)(tree_node**, int*, void*), void*,
hash_set >*))
/home/marek/src/gcc/gcc/tree.c:11400
0xad0d3c cp_walk_subtrees(tree_node**, int*, tree_node* (*)(tree_node**, int*,
void*), void*, hash_set >*)
/home/marek/src/gcc/gcc/cp/tree.c:4779
0x15deb2f walk_tree_1(tree_node**, tree_node* (*)(tree_node**, int*, void*),
void*, hash_set >*, tree_node*
(*)(tree_node**, int*, tree_node* (*)(tree_node**, int*, void*), void*,
hash_set >*))
/home/marek/src/gcc/gcc/tree.c:11423
0xac9848 replace_placeholders(tree_node*, tree_node*, bool*)
/home/marek/src/gcc/gcc/cp/tree.c:3181
0xb0bf05 store_init_value(tree_node*, tree_node*, vec**, int)
/home/marek/src/gcc/gcc/cp/typeck2.c:851
0x8c9484 check_initializer
/home/marek/src/gcc/gcc/cp/decl.c:6384
0x8cbe24 cp_finish_decl(tree_node*, tree_node*, bool, tree_node*, int)
/home/marek/src/gcc/gcc/cp/decl.c:6937
0x8fad83 finish_static_data_member_decl(tree_node*, tree_node*, bool,
tree_node*, int)
/home/marek/src/gcc/gcc/cp/decl2.c:804
0x8fbccc grokfield(cp_declarator const*, cp_decl_specifier_seq*, tree_node*,
bool, tree_node*, tree_node*)
/home/marek/src/gcc/gcc/cp/decl2.c:993
0x9c8a03 cp_parser_member_declaration
/home/marek/src/gcc/gcc/cp/parser.c:23880
0x9c7a67 cp_parser_member_specification_opt
/home/marek/src/gcc/gcc/cp/parser.c:23354
0x9c5754 cp_parser_class_specifier_1
/home/marek/src/gcc/gcc/cp/parser.c:22496
0x9c64df cp_parser_class_specifier
/home/marek/src/gcc/gcc/cp/parser.c:22748
0x9b9d29 cp_parser_type_specifier
/home/marek/src/gcc/gcc/cp/parser.c:16754
0x9b46b1 cp_parser_decl_specifier_seq
/home/marek/src/gcc/gcc/cp/parser.c:13612
0x9ce64d cp_parser_single_declaration
/home/marek/src/gcc/gcc/cp/parser.c:27060
0x9cd8fb cp_parser_template_declaration_after_parameters
/home/marek/src/gcc/gcc/cp/parser.c:26752
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See
[Bug debug/84545] [8 regression] FAIL: g++.dg/debug/pr44182.C -gdwarf-2 -O2 (test for excess errors)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84545 --- Comment #2 from Eric Botcazou --- -fno-delayed-branch seems to be the workaround.
[Bug target/83496] [7/8 regression] wrong code generated with -Os -mbranch-cost=1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83496 --- Comment #31 from Eric Botcazou --- > Just a note. I'm tracking a separate problem with delay slot filling that > looks like it's related to handling of debug insns. I doubt it's the same > problem, but if you stumble over it, be aware I'm testing a fix. Is that PR debug/84545 or something related?
[Bug c++/84297] ICE (mmap: Invalid argument) in std::is_trivially_constructible
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84297 Marek Polacek changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2018-02-26 CC||mpolacek at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Marek Polacek --- Confirmed.
[Bug rtl-optimization/84566] error: qsort comparator not anti-commutative: -1, -1 on aarch64 in sched1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84566
Alexander Monakov changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed||2018-02-26
CC||abel at gcc dot gnu.org
Ever confirmed|0 |1
--- Comment #3 from Alexander Monakov ---
Confirmed. Our comparator breaks here:
/* Prefer SCHED_GROUP_P insns to any others. */
if (SCHED_GROUP_P (tmp_insn) != SCHED_GROUP_P (tmp2_insn))
{
if (VINSN_UNIQUE_P (tmp_vinsn) && VINSN_UNIQUE_P (tmp2_vinsn))
return SCHED_GROUP_P (tmp2_insn) ? 1 : -1;
/* Now uniqueness means SCHED_GROUP_P is set, because schedule groups
cannot be cloned. */
if (VINSN_UNIQUE_P (tmp2_vinsn))
return 1;
return -1;
}
when we have two non-unique insns such that one is in a sched group. That is
not supposed to happen actually, since SCHED_GROUP_P should imply
VINSN_UNIQUE_P. This invariant is broken when sched_macro_fuse_insns sets
SCHED_GROUP_P without looking at deps->readonly.
So while we could get rid of the issue by rewriting the problematic sel-sched
code in terms of SCHED_GROUP_P only, lack of deps->readonly check for
macro-fusion seems like a bigger issue and should be fixed too.
[Bug gcov-profile/84548] [8 regression] gcov ICE in process_file, at gcov.c:1154
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84548 --- Comment #17 from Dmitry G. Dyachenko --- No ICE! Thank Martin! And once more strangeness I have (at least) 2 messages 'YYY.gcda:stamp mismatch with notes file' from 3K gcno-files in full project. $ ~/build/gcc_current/prev-gcc/gcov cpcapi20suite.gcno cpcapi20suite.gcda:stamp mismatch with notes file File '/home/dimhen/src/CSPbuild/CSP/unittest/CpCapi20UnitTest/cpcapi20suite.cpp' No executable lines Removing 'cpcapi20suite.cpp.gcov' File '/usr/local/cppunit-1.13.2/8/debug/include/cppunit/extensions/AutoRegisterSuite.h' Lines executed:0.00% of 14 Creating 'AutoRegisterSuite.h.gcov' [...] File '/usr/local/gcc_current/include/c++/8.0.1/new' Lines executed:0.00% of 3 Creating 'new.gcov' File '/home/dimhen/src/CSPbuild/CSP/unittest/CpCapi20UnitTest/cpcapi20suite.h' Lines executed:0.00% of 2 Creating 'cpcapi20suite.h.gcov'
[Bug gcov-profile/84548] [8 regression] gcov ICE in process_file, at gcov.c:1154
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84548 --- Comment #18 from Martin Liška --- (In reply to Dmitry G. Dyachenko from comment #17) > No ICE! > Thank Martin! Good. Can you please attach gcov file for the problematic invocation of gcov tool? > > And once more strangeness > > I have (at least) 2 messages 'YYY.gcda:stamp mismatch with notes file' > from 3K gcno-files in full project. > > $ ~/build/gcc_current/prev-gcc/gcov cpcapi20suite.gcno > cpcapi20suite.gcda:stamp mismatch with notes file > File > '/home/dimhen/src/CSPbuild/CSP/unittest/CpCapi20UnitTest/cpcapi20suite.cpp' > No executable lines > Removing 'cpcapi20suite.cpp.gcov' > > File > '/usr/local/cppunit-1.13.2/8/debug/include/cppunit/extensions/ > AutoRegisterSuite.h' > Lines executed:0.00% of 14 > Creating 'AutoRegisterSuite.h.gcov' > > [...] > > File '/usr/local/gcc_current/include/c++/8.0.1/new' > Lines executed:0.00% of 3 > Creating 'new.gcov' > > File > '/home/dimhen/src/CSPbuild/CSP/unittest/CpCapi20UnitTest/cpcapi20suite.h' > Lines executed:0.00% of 2 > Creating 'cpcapi20suite.h.gcov' It can be caused by 2 files 'cpcapi20suite.cpp' in the project. Is it possible that you have multiple files in a different folders?
[Bug c++/84297] ICE (mmap: Invalid argument) in std::is_trivially_constructible
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84297
--- Comment #2 from Marek Polacek ---
Reduced, hopefully still valid. But clang++ accepts it.
struct integral_constant {};
template using __bool_constant = integral_constant;
template
struct A : __bool_constant < __is_trivially_constructible(_Tp, _Args...)>
{};
A a;
Started with r226381.
[Bug c++/84558] [6/7/8 Regression] ICE with invalid constexpr constructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84558 Jakub Jelinek changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org --- Comment #2 from Jakub Jelinek --- Created attachment 43509 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43509&action=edit gcc8-pr84558.patch Untested fix.
[Bug c++/84558] [6/7/8 Regression] ICE with invalid constexpr constructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84558 Jakub Jelinek changed: What|Removed |Added Target Milestone|--- |6.5
[Bug c++/84559] [7/8 Regression] ICE with constexpr and variable-sized array
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84559 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org Version|unknown |7.0.1 Target Milestone|--- |7.4 Summary|[6/7/8 Regression] ICE with |[7/8 Regression] ICE with |constexpr and |constexpr and |variable-sized array|variable-sized array --- Comment #2 from Jakub Jelinek --- I don't see how something that doesn't even have known size at compile time could be a valid constant expression.
[Bug target/83496] [7/8 regression] wrong code generated with -Os -mbranch-cost=1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83496 Eric Botcazou changed: What|Removed |Added Attachment #43499|0 |1 is obsolete|| --- Comment #32 from Eric Botcazou --- Created attachment 43510 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43510&action=edit Final tentative fix I'm testing it on SPARC.
[Bug c++/84559] [7/8 Regression] ICE with constexpr and variable-sized array
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84559
--- Comment #3 from Jakub Jelinek ---
That said, we accept:
void foo(int i)
{
constexpr char x[i] = {1, 2, 3};
}
clang++ rejects both: error: constexpr variable cannot have non-literal type
'char const[i]'
[Bug gcov-profile/84572] New: Wrong number of execution of a line
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84572
Bug ID: 84572
Summary: Wrong number of execution of a line
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: gcov-profile
Assignee: unassigned at gcc dot gnu.org
Reporter: marxin at gcc dot gnu.org
CC: marxin at gcc dot gnu.org
Target Milestone: ---
Following test-case:
$ cat gcovbug.c
#include
#include
#define LCCG_StructAttrib RT_CC_STRUCT_ATTRIB
#define RT_CC_STRUCT_ATTRIB
typedef uint8_t RT_TD_IEC_BOOL;
typedef int8_t RT_TD_IEC_SINT;
typedef int16_t RT_TD_IEC_INT;
typedef int32_t RT_TD_IEC_DINT;
typedef int64_t RT_TD_IEC_LINT;
typedef RT_TD_IEC_BOOL LC_TD_BOOL;
typedef RT_TD_IEC_SINT LC_TD_SINT;
typedef RT_TD_IEC_INT LC_TD_INT;
typedef RT_TD_IEC_DINT LC_TD_DINT;
typedef RT_TD_IEC_LINT LC_TD_LINT;
/*Typedefs */
typedef struct _LC_TD_FunctionBlock_COVERAGE
{
LC_TD_INT LC_VD_INPUT_VAR;
LC_TD_BOOL LC_VD_ENO;
LC_TD_INT LC_VD_X;
LC_TD_INT LC_VD_Y;
} LCCG_StructAttrib LC_TD_FunctionBlock_COVERAGE;
void lcfu___COVERAGE(LC_TD_FunctionBlock_COVERAGE* LC_this);
int main(void)
{
LC_TD_FunctionBlock_COVERAGE test;
test.LC_VD_INPUT_VAR = 2;
test.LC_VD_ENO = 0;
test.LC_VD_X = 0;
test.LC_VD_Y = 0;
lcfu___COVERAGE(&test);
return 0;
}
void lcfu___COVERAGE(LC_TD_FunctionBlock_COVERAGE* LC_this)
{
{
LC_TD_DINT caseSelector;
caseSelector = LC_this->LC_VD_INPUT_VAR;
if
((caseSelector==(LC_TD_DINT)1L)||(caseSelector==(LC_TD_DINT)2L)||((caseSelector>=(LC_TD_DINT)33L)
&& (caseSelector<=(LC_TD_DINT)44L)))
{
LC_this->LC_VD_X = (LC_TD_INT)3;
if ((LC_TD_BOOL)(LC_this->LC_VD_INPUT_VAR == (LC_TD_INT)2))
{
LC_this->LC_VD_Y = (LC_TD_INT)666;
}
}
else
{
LC_this->LC_VD_X = (LC_TD_INT)4;
}
}
}
has following coverage:
1: 44:void lcfu___COVERAGE(LC_TD_FunctionBlock_COVERAGE* LC_this)
-: 45:{
-: 46: {
-: 47:LC_TD_DINT caseSelector;
1: 48:caseSelector = LC_this->LC_VD_INPUT_VAR;
-: 49:
1*: 50:if
((caseSelector==(LC_TD_DINT)1L)||(caseSelector==(LC_TD_DINT)2L)||((caseSelector>=(LC_TD_DINT)33L)
&& (caseSelector<=(LC_TD_DINT)44L)))
-: 51:{
1: 52: LC_this->LC_VD_X = (LC_TD_INT)3;
2: 53: if ((LC_TD_BOOL)(LC_this->LC_VD_INPUT_VAR ==
(LC_TD_INT)2))
-: 54: {
1: 55:LC_this->LC_VD_Y = (LC_TD_INT)666;
-: 56: }
-: 57:}
-: 58:else
-: 59:{
#: 60: LC_this->LC_VD_X = (LC_TD_INT)4;
-: 61:}
-: 62: }
[Bug gcov-profile/84572] Wrong number of execution of a line
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84572 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2018-02-26 Assignee|unassigned at gcc dot gnu.org |marxin at gcc dot gnu.org Target Milestone|--- |8.0 Ever confirmed|0 |1
[Bug gcov-profile/84548] [8 regression] gcov ICE in process_file, at gcov.c:1154
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84548
--- Comment #19 from Dmitry G. Dyachenko ---
(In reply to Martin Liška from comment #18)
> (In reply to Dmitry G. Dyachenko from comment #17)
> > No ICE!
> > Thank Martin!
>
> Good. Can you please attach gcov file for the problematic invocation of gcov
> tool?
...
> It can be caused by 2 files 'cpcapi20suite.cpp' in the project. Is it
> possible that you have multiple files in a different folders?
Fortunately, problem file(s) already attached: pre-proccessed cpcapi20suite.cpp
and x.{gcno,gcda}
There are only one cpcapi20suite.cpp
$ find /home/dimhen/src/CSPbuild/ -name cpcapi20suite\*
/home/dimhen/src/CSPbuild/CSP/unittest/CpCapi20UnitTest/cpcapi20suite.cpp
/home/dimhen/src/CSPbuild/CSP/unittest/CpCapi20UnitTest/cpcapi20suite.h
$ find . -name \*cpcapi20suite\*
./CSP/unittest/CpCapi20UnitTest/.deps/cpcapi20suite.Po
./CSP/unittest/CpCapi20UnitTest/cpcapi20suite.gcno
./CSP/unittest/CpCapi20UnitTest/cpcapi20suite.gcda
./CSP/unittest/CpCapi20UnitTest/cpcapi20suite.o
./CSP/unittest/CpCapi20UnitTest/cpcapi20suite.h.gcov
[Bug target/83496] [7/8 regression] wrong code generated with -Os -mbranch-cost=1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83496 --- Comment #33 from Jeffrey A. Law --- No. THe one I'm currently chasing is not 84545. I'm chasing a ton of ICEs due to debug insns appearing in places we didn't expect.
[Bug target/84564] error: unable to find a register to spill with -mforce-indirect-call
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84564
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #1 from Jakub Jelinek ---
/* PR target/84564 */
/* { dg-do compile } */
/* { dg-options "-O2 -mforce-indirect-call" } */
int a, b, c, d;
int foo (void);
static int
bar (int x, int y, int z)
{
while (a)
if (foo ())
bar (x, y, z);
return 0;
}
int
baz (void)
{
return bar (b, c, d);
}
[Bug c++/84537] [8 Regression] ICE in get_string, at spellcheck-tree.h
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84537 Marek Polacek changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |mpolacek at gcc dot gnu.org
[Bug c++/84537] [8 Regression] ICE in get_string, at spellcheck-tree.h
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84537 --- Comment #4 from Marek Polacek --- Author: mpolacek Date: Mon Feb 26 14:12:25 2018 New Revision: 257988 URL: https://gcc.gnu.org/viewcvs?rev=257988&root=gcc&view=rev Log: PR c++/84537 * name-lookup.c (suggest_alternative_in_explicit_scope): Return false if name is error node. * g++.dg/parse/error60.C: New test. Added: trunk/gcc/testsuite/g++.dg/parse/error60.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/name-lookup.c trunk/gcc/testsuite/ChangeLog
[Bug c++/84537] [8 Regression] ICE in get_string, at spellcheck-tree.h
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84537 Marek Polacek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #5 from Marek Polacek --- Fixed.
[Bug target/84564] error: unable to find a register to spill with -mforce-indirect-call
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84564 Jakub Jelinek changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #2 from Jakub Jelinek --- Created attachment 43511 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43511&action=edit gcc8-pr84564.patch Untested fix.
[Bug gcov-profile/84572] Wrong number of execution of a line
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84572
Martin Liška changed:
What|Removed |Added
Priority|P3 |P5
Status|ASSIGNED|NEW
Assignee|marxin at gcc dot gnu.org |unassigned at gcc dot
gnu.org
--- Comment #1 from Martin Liška ---
Reduced test-case:
$ cat gcov.c
int a, b;
void foo (int value)
{
if (value == 1 || value == 2 || (value >= 33 && value <= 44))
{
a = 1;
if (value == 2)
b = 2;
}
else
a = 4;
}
int main(int argc, char **argv)
{
foo (argc);
}
$ cat gcov.c.gcov
-:0:Source:gcov.c
-:0:Graph:gcov.gcno
-:0:Data:gcov.gcda
-:0:Runs:1
-:0:Programs:1
-:1:int a, b;
-:2:
1:3:void foo (int value)
-:4:{
1*:5: if (value == 1 || value == 2 || (value >= 33 && value <= 44))
-:6: {
1:7:a = 1;
2:8:if (value == 2)
1:9: b = 2;
-: 10: }
-: 11: else
#: 12:a = 4;
1: 13:}
-: 14:
-: 15:
1: 16:int main(int argc, char **argv)
-: 17:{
1: 18: foo (argc);
-: 19:}
As you can see, there's a duplicate expression (value == 2) on lines 5 and 8.
Even with -O0 we do some optimizations and the expression is executed just
once. That's why we report line 8 twice.
Note that we have couple of similar issue caused by similar optimization.
[Bug gcov-profile/84548] [8 regression] gcov ICE in process_file, at gcov.c:1154
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84548
--- Comment #20 from Martin Liška ---
(In reply to Dmitry G. Dyachenko from comment #19)
> (In reply to Martin Liška from comment #18)
> > (In reply to Dmitry G. Dyachenko from comment #17)
> > > No ICE!
> > > Thank Martin!
> >
> > Good. Can you please attach gcov file for the problematic invocation of gcov
> > tool?
> ...
> > It can be caused by 2 files 'cpcapi20suite.cpp' in the project. Is it
> > possible that you have multiple files in a different folders?
>
> Fortunately, problem file(s) already attached: pre-proccessed
> cpcapi20suite.cpp and x.{gcno,gcda}
>
>
> There are only one cpcapi20suite.cpp
>
> $ find /home/dimhen/src/CSPbuild/ -name cpcapi20suite\*
> /home/dimhen/src/CSPbuild/CSP/unittest/CpCapi20UnitTest/cpcapi20suite.cpp
> /home/dimhen/src/CSPbuild/CSP/unittest/CpCapi20UnitTest/cpcapi20suite.h
>
> $ find . -name \*cpcapi20suite\*
> ./CSP/unittest/CpCapi20UnitTest/.deps/cpcapi20suite.Po
> ./CSP/unittest/CpCapi20UnitTest/cpcapi20suite.gcno
> ./CSP/unittest/CpCapi20UnitTest/cpcapi20suite.gcda
> ./CSP/unittest/CpCapi20UnitTest/cpcapi20suite.o
> ./CSP/unittest/CpCapi20UnitTest/cpcapi20suite.h.gcov
It can explain why we see the strange locations. Note that when you invoke
gcc w/ --coverage, then it creates immediately *.gcno file (notes file) which
contains a timestamp. Then when you run an executable *.gcda file (data file)
is
created. Also included with a timestamp. And the note you see means basically
that
a data file was created before a notes file. Which should not be possible.
Isn't that
an old data file you forgot to remove?
[Bug gcov-profile/84548] [8 regression] gcov ICE in process_file, at gcov.c:1154
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84548
--- Comment #21 from Martin Liška ---
(In reply to Dmitry G. Dyachenko from comment #19)
> (In reply to Martin Liška from comment #18)
> > (In reply to Dmitry G. Dyachenko from comment #17)
> > > No ICE!
> > > Thank Martin!
> >
> > Good. Can you please attach gcov file for the problematic invocation of gcov
> > tool?
> ...
> > It can be caused by 2 files 'cpcapi20suite.cpp' in the project. Is it
> > possible that you have multiple files in a different folders?
>
> Fortunately, problem file(s) already attached: pre-proccessed
> cpcapi20suite.cpp and x.{gcno,gcda}
>
Yes, but it's *.ii file and the x.{gcno,gcda} are related to *.cpp file. Please
attach the resulting gcov file.
[Bug debug/84545] [8 regression] FAIL: g++.dg/debug/pr44182.C -gdwarf-2 -O2 (test for excess errors)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84545 Eric Botcazou changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |ebotcazou at gcc dot gnu.org --- Comment #3 from Eric Botcazou --- This looks trivial to fix.
[Bug gcov-profile/84572] Wrong number of execution of a line
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84572 Martin Liška changed: What|Removed |Added Target Milestone|8.0 |---
[Bug bootstrap/84405] [8 Regression] Fails to bootstrap with GCC 4.1.2, GCC 4.2.4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84405 --- Comment #9 from Jakub Jelinek --- Author: jakub Date: Mon Feb 26 14:37:45 2018 New Revision: 257989 URL: https://gcc.gnu.org/viewcvs?rev=257989&root=gcc&view=rev Log: PR bootstrap/84405 * vec.h (vec_default_construct): For BROKEN_VALUE_INITIALIZATION use memset and value initialization afterwards. Modified: trunk/gcc/ChangeLog trunk/gcc/vec.h
[Bug gcov-profile/84548] [8 regression] gcov ICE in process_file, at gcov.c:1154
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84548 --- Comment #22 from Dmitry G. Dyachenko --- (In reply to Martin Liška from comment #20) ... > Isn't that > an old data file you forgot to remove? I'll rebuild all and 'll report
[Bug debug/84545] [8 regression] FAIL: g++.dg/debug/pr44182.C -gdwarf-2 -O2 (test for excess errors)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84545
--- Comment #4 from Jakub Jelinek ---
Do the:
if (CALL_P (insn))
{
rtx note = find_reg_note (insn, REG_CALL_ARG_LOCATION, NULL_RTX);
if (note)
remove_note (insn, note);
}
also for insns inside a SEQUENCE?
[Bug c++/84461] [8 regression] openjdk-10 fails to build
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84461
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #4 from Jakub Jelinek ---
What g++ options? I can't reproduce either with -O0 -std={c++11,c++14} or
-std=c++14 -O2 -g.
[Bug target/84565] [8 Regression] ICE in extract_insn, at recog.c:2304 on aarch64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84565 Jakub Jelinek changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2018-02-26 CC||jakub at gcc dot gnu.org, ||rsandifo at gcc dot gnu.org Version|unknown |8.0 Summary|ICE in extract_insn, at |[8 Regression] ICE in |recog.c:2304 on aarch64 |extract_insn, at ||recog.c:2304 on aarch64 Ever confirmed|0 |1 --- Comment #1 from Jakub Jelinek --- Started with r256612.
[Bug c++/84533] [7/8 Regression] ICE with duplicate enum value
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84533 --- Comment #2 from paolo at gcc dot gnu.org --- Author: paolo Date: Mon Feb 26 15:00:44 2018 New Revision: 257991 URL: https://gcc.gnu.org/viewcvs?rev=257991&root=gcc&view=rev Log: /cp 2018-02-26 Paolo Carlini PR c++/84533 * decl.c (redeclaration_error_message): Don't try to use DECL_DECLARED_CONSTEXPR_P on CONST_DECLs. /testsuite 2018-02-26 Paolo Carlini PR c++/84533 * g++.dg/cpp1z/pr84533.C: New. Added: trunk/gcc/testsuite/g++.dg/cpp1z/pr84533.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/decl.c trunk/gcc/testsuite/ChangeLog
[Bug c++/84533] [7 Regression] ICE with duplicate enum value
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84533 Paolo Carlini changed: What|Removed |Added Summary|[7/8 Regression] ICE with |[7 Regression] ICE with |duplicate enum value|duplicate enum value --- Comment #3 from Paolo Carlini --- Fixed in trunk.
[Bug c++/84541] ICE with auto in function parameter
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84541 Paolo Carlini changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2018-02-26 Blocks|67491 | Summary|[8 Regression] ICE with |ICE with auto in function |auto in function parameter |parameter Ever confirmed|0 |1 --- Comment #1 from Paolo Carlini --- I don't think -fconcepts has anything to do with this and it doesn't look like an [8 regression], in fact I can reproduce it with -std=c++14 even in gcc-5-branch. Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67491 [Bug 67491] [meta-bug] concepts issues
[Bug c/84563] GCC interpretation of C11 atomics (DR 459)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84563 --- Comment #1 from Ruslan Nikolaev --- See also discussion in the gcc mailing list
[Bug debug/84545] [8 regression] FAIL: g++.dg/debug/pr44182.C -gdwarf-2 -O2 (test for excess errors)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84545
--- Comment #5 from Eric Botcazou ---
> Do the:
> if (CALL_P (insn))
> {
> rtx note = find_reg_note (insn, REG_CALL_ARG_LOCATION, NULL_RTX);
> if (note)
> remove_note (insn, note);
> }
> also for insns inside a SEQUENCE?
Yes, although doing it only for the first insn therein is sufficient.
[Bug target/84530] -mfunction-return=thunk does not work for simple_return_pop_internal insn
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84530 --- Comment #3 from hjl at gcc dot gnu.org --- Author: hjl Date: Mon Feb 26 15:29:30 2018 New Revision: 257992 URL: https://gcc.gnu.org/viewcvs?rev=257992&root=gcc&view=rev Log: i386: Update -mfunction-return= for return with pop When -mfunction-return= is used, simple_return_pop_internal should pop return address into ECX register, adjust stack by bytes to pop from stack and jump to the return thunk via ECX register. Tested on i686 and x86-64. PR target/84530 * config/i386/i386-protos.h (ix86_output_indirect_jmp): Remove the bool argument. (ix86_output_indirect_function_return): New prototype. (ix86_split_simple_return_pop_internal): Likewise. * config/i386/i386.c (indirect_return_via_cx): New. (indirect_return_via_cx_bnd): Likewise. (indirect_thunk_name): Handle return va CX_REG. (output_indirect_thunk_function): Create alias for __x86_return_thunk_[re]cx and __x86_return_thunk_[re]cx_bnd. (ix86_output_indirect_jmp): Remove the bool argument. (ix86_output_indirect_function_return): New function. (ix86_split_simple_return_pop_internal): Likewise. * config/i386/i386.md (*indirect_jump): Don't pass false to ix86_output_indirect_jmp. (*tablejump_1): Likewise. (simple_return_pop_internal): Change it to define_insn_and_split. Call ix86_split_simple_return_pop_internal to split it for -mfunction-return=. (simple_return_indirect_internal): Call ix86_output_indirect_function_return instead of ix86_output_indirect_jmp. gcc/testsuite/ PR target/84530 * gcc.target/i386/ret-thunk-22.c: New test. * gcc.target/i386/ret-thunk-23.c: Likewise. * gcc.target/i386/ret-thunk-24.c: Likewise. * gcc.target/i386/ret-thunk-25.c: Likewise. * gcc.target/i386/ret-thunk-26.c: Likewise. Added: trunk/gcc/testsuite/gcc.target/i386/ret-thunk-22.c trunk/gcc/testsuite/gcc.target/i386/ret-thunk-23.c trunk/gcc/testsuite/gcc.target/i386/ret-thunk-24.c trunk/gcc/testsuite/gcc.target/i386/ret-thunk-25.c trunk/gcc/testsuite/gcc.target/i386/ret-thunk-26.c Modified: trunk/gcc/ChangeLog trunk/gcc/config/i386/i386-protos.h trunk/gcc/config/i386/i386.c trunk/gcc/config/i386/i386.md trunk/gcc/testsuite/ChangeLog
[Bug c++/84461] [8 regression] openjdk-10 fails to build
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84461 Andreas Schwab changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #5 from Andreas Schwab --- Fixed between r257516 and now.
[Bug debug/84545] [8 regression] FAIL: g++.dg/debug/pr44182.C -gdwarf-2 -O2 (test for excess errors)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84545 --- Comment #6 from Jakub Jelinek --- Is it guaranteed that no target puts calls into delay slots?
[Bug target/84565] [8 Regression] ICE in extract_insn, at recog.c:2304 on aarch64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84565 --- Comment #2 from Jakub Jelinek --- The aarch64_cmpeqdf instruction no longer matches, because the CONST0_RTX (DFmode) operand doesn't match the aarch64_simd_reg_or_zero predicate. Either aarch64_simd_reg_or_zero predicate should use aarch64_simd_or_scalar_imm_zero rather than aarch64_simd_imm_zero, or the aarch64_cmp pattern with VHSDF_HSDF needs to use some other predicate at least for the scalar modes.
[Bug target/84565] [8 Regression] ICE in extract_insn, at recog.c:2304 on aarch64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84565 --- Comment #3 from Jakub Jelinek --- Created attachment 43512 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43512&action=edit gcc8-pr84565.patch This works for me.
[Bug debug/84545] [8 regression] FAIL: g++.dg/debug/pr44182.C -gdwarf-2 -O2 (test for excess errors)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84545 --- Comment #7 from Eric Botcazou --- Author: ebotcazou Date: Mon Feb 26 15:40:18 2018 New Revision: 257993 URL: https://gcc.gnu.org/viewcvs?rev=257993&root=gcc&view=rev Log: PR debug/84545 * final.c (rest_of_clean_state): Also look for calls inside sequences. Modified: trunk/gcc/ChangeLog trunk/gcc/final.c
[Bug debug/84545] [8 regression] FAIL: g++.dg/debug/pr44182.C -gdwarf-2 -O2 (test for excess errors)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84545 Eric Botcazou changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #8 from Eric Botcazou --- > Is it guaranteed that no target puts calls into delay slots? I think that reorg doesn't put instructions with delay slots into delay slots.
[Bug c++/84540] [6/7/8 Regression] ICE with alignas in variadic template
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84540 Paolo Carlini changed: What|Removed |Added Keywords|ice-on-invalid-code |ice-on-valid-code Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |paolo.carlini at oracle dot com --- Comment #2 from Paolo Carlini --- This is valid, and doesn't seem hard to fix.
