[Bug c++/88413] g++ mangles names involving unresolved names in function argument template parameters differently from the ABI standard.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88413 --- Comment #5 from Andrew Pinski --- GCC has the following in it: ::= sr# dependent name ::= sr*/ Hmm, maybe the ABI changed and GCC did not change with it ...
[Bug tree-optimization/58318] very slow compilation on x86_64-linux with -O3 and -g and checking enabled
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58318 Arseny Solokha changed: What|Removed |Added CC||asolokha at gmx dot com --- Comment #4 from Arseny Solokha --- I cannot reproduce it on all active branches. It looks like 4.8 was the last branch w/ this issue.
[Bug rtl-optimization/88416] New: [8/9 Regression] ICE in in df_uses_record, at df-scan.c:3013
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88416 Bug ID: 88416 Summary: [8/9 Regression] ICE in in df_uses_record, at df-scan.c:3013 Product: gcc Version: 8.0 Status: UNCONFIRMED Keywords: ice-on-valid-code Severity: normal Priority: P3 Component: rtl-optimization Assignee: unassigned at gcc dot gnu.org Reporter: asolokha at gmx dot com Target Milestone: --- Target: x86_64-unknown-linux-gnu gcc-9.0.0-alpha20181202 snapshot (r266729) and gcc 8.2 ICE when compiling gcc/testsuite/gcc.target/i386/writeeflags-1.c w/ -O1 (-Og) -fvar-tracking-assignments -fno-forward-propagate --param max-cse-insns=1: % x86_64-unknown-linux-gnu-gcc-9.0.0-alpha20181202 -O1 -fvar-tracking-assignments -fno-forward-propagate --param max-cse-insns=1 -c gcc/testsuite/gcc.target/i386/writeeflags-1.c during RTL pass: combine gcc/testsuite/gcc.target/i386/writeeflags-1.c: In function 'main': gcc/testsuite/gcc.target/i386/writeeflags-1.c:31:1: internal compiler error: in df_uses_record, at df-scan.c:3013 31 | } | ^ 0x5f20d6 df_uses_record /var/tmp/portage/sys-devel/gcc-9.0.0_alpha20181202/work/gcc-9-20181202/gcc/df-scan.c:3013 0x93ed66 df_insn_refs_collect /var/tmp/portage/sys-devel/gcc-9.0.0_alpha20181202/work/gcc-9-20181202/gcc/df-scan.c:3222 0x93f127 df_insn_refs_verify /var/tmp/portage/sys-devel/gcc-9.0.0_alpha20181202/work/gcc-9-20181202/gcc/df-scan.c:4088 0x940af3 df_insn_rescan(rtx_insn*) /var/tmp/portage/sys-devel/gcc-9.0.0_alpha20181202/work/gcc-9-20181202/gcc/df-scan.c:1065 0x9424d6 df_process_deferred_rescans() /var/tmp/portage/sys-devel/gcc-9.0.0_alpha20181202/work/gcc-9-20181202/gcc/df-scan.c:1246 0x92d57a df_finish_pass(bool) /var/tmp/portage/sys-devel/gcc-9.0.0_alpha20181202/work/gcc-9-20181202/gcc/df-core.c:651
[Bug target/88414] New: [9 Regression] ICE in lra_assign, at lra-assigns.c:1624
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88414
Bug ID: 88414
Summary: [9 Regression] ICE in lra_assign, at
lra-assigns.c:1624
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Keywords: ice-on-invalid-code
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: asolokha at gmx dot com
Target Milestone: ---
Target: x86_64-unknown-linux-gnu
gcc-9.0.0-alpha20181202 snapshot (r266729) for x86_64 ICEs when compiling
gcc/testsuite/gcc.target/m68k/pr45015.c w/ -O1 (-Og) -ftrapv:
% x86_64-unknown-linux-gnu-gcc-9.0.0-alpha20181202 -O1 -ftrapv -c
gcc/testsuite/gcc.target/m68k/pr45015.c
gcc/testsuite/gcc.target/m68k/pr45015.c: In function 'foo':
gcc/testsuite/gcc.target/m68k/pr45015.c:16:7: error: 'asm' operand has
impossible constraints
16 | __asm__ ("move.l %2, %0; move.l %3, %1" : "=d" (b), "=d" (c) :
"g<>" (y[j]), "d" (w));
| ^~~
during RTL pass: reload
gcc/testsuite/gcc.target/m68k/pr45015.c:26:1: internal compiler error: in
lra_assign, at lra-assigns.c:1624
26 | }
| ^
0xb897d0 lra_assign(bool&)
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20181202/work/gcc-9-20181202/gcc/lra-assigns.c:1624
0xb8443d lra(_IO_FILE*)
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20181202/work/gcc-9-20181202/gcc/lra.c:2508
0xb3b929 do_reload
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20181202/work/gcc-9-20181202/gcc/ira.c:5469
0xb3b929 execute
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20181202/work/gcc-9-20181202/gcc/ira.c:5653
[Bug tree-optimization/88415] New: [7/8/9 Regression] ICE: verify_gimple failed (error: dead STMT in EH table)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88415
Bug ID: 88415
Summary: [7/8/9 Regression] ICE: verify_gimple failed (error:
dead STMT in EH table)
Product: gcc
Version: 7.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code, openmp
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: asolokha at gmx dot com
Target Milestone: ---
gcc-9.0.0-alpha20181202 snapshot (r266729), 8.2, 7.4 ICE when compiling the
following snippet w/ -fexceptions -fnon-call-exceptions -fopenmp
-fsignaling-nans -funsafe-math-optimizations:
void
lx (_Complex int *yn)
{
int mj;
#pragma omp for
for (mj = 0; mj < 1; ++mj)
yn[mj] += 1;
}
% gcc-9.0.0-alpha20181202 -fexceptions -fnon-call-exceptions -fopenmp
-fsignaling-nans -funsafe-math-optimizations -w -c zgxacany.c
zgxacany.c: In function 'lx':
zgxacany.c:2:1: error: dead STMT in EH table
2 | lx (_Complex int *yn)
| ^~
# VUSE <.MEM_12>
_26 = *_3;
during GIMPLE pass: cplxlower0
zgxacany.c:2:1: internal compiler error: verify_gimple failed
0xd5107d verify_gimple_in_cfg(function*, bool)
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20181202/work/gcc-9-20181202/gcc/tree-cfg.c:5422
0xc2523f execute_function_todo
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20181202/work/gcc-9-20181202/gcc/passes.c:1977
0xc2617e execute_todo
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20181202/work/gcc-9-20181202/gcc/passes.c:2031
[Bug target/79636] [7/8/9 Regression] ICE in assign_by_spills, at lra-assigns.c:1457
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79636 Arseny Solokha changed: What|Removed |Added CC||asolokha at gmx dot com --- Comment #5 from Arseny Solokha --- In my setup, a current trunk snapshot and gcc 8 don't ICE, and gcc 7 still does.
[Bug inline-asm/69899] gcc ICE on invalid code on x86_64-linux-gnu in "replace_reg"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69899 Arseny Solokha changed: What|Removed |Added CC||asolokha at gmx dot com --- Comment #3 from Arseny Solokha --- I cannot reproduce this ICE on all active branches.
[Bug target/80540] gcc ICE at -O2 and above on x86_64-linux-gnu in "assign_by_spills"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80540 Arseny Solokha changed: What|Removed |Added CC||asolokha at gmx dot com --- Comment #5 from Arseny Solokha --- In my setup, a current trunk snapshot and gcc 8 don't ICE. Curiously, gcc 4.9 doesn't ICE too. So it's either semi-latent and gets unfortunate exposure at times, or was fixed at some point.
[Bug c++/88413] g++ mangles names involving unresolved names in function argument template parameters differently from the ABI standard.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88413 --- Comment #4 from brennan at umanwizard dot com --- Investigating a bit more, it seems Apple patched their c++filt to just call into __cxa_demangle in their own libc++abi , so it makes sense that c++filt on macOS matches clang and on Linux matches g++. I tried an old version of (real GNU) c++filt from 2005 and they match the current behavior, so it doesn't seem to be a new thing.
[Bug c++/88413] g++ mangles names involving unresolved names in function argument template parameters differently from the ABI standard.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88413 --- Comment #3 from Andrew Pinski --- [apinski@linux gcc]$ c++filt _Z1gIiEvP2S1IXsr2S2IT_EE3valEE _Z1gIiEvP2S1IXsr2S2IT_EE3valEE [apinski@linux gcc]$ c++filt _Z1gIiEvP2S1IXsr2S2IT_E3valEE void g(S1::val>*) [apinski@linux gcc]$ c++filt --version GNU c++filt version 2.27-27.base.el7 Copyright (C) 2016 Free Software Foundation, Inc. This program is free software; you may redistribute it under the terms of the GNU General Public License version 3 or (at your option) any later version. This program has absolutely no warranty.
[Bug c++/88413] g++ mangles names involving unresolved names in function argument template parameters differently from the ABI standard.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88413 --- Comment #2 from brennan at umanwizard dot com --- I find the opposite, on whatever ancient version of c++filt ships with macOS: $ c++filt --version GNU c++filt 070207 20070207 Copyright 2005 Free Software Foundation, Inc. This program is free software; you may redistribute it under the terms of the GNU General Public License. This program has absolutely no warranty. $ c++filt -n _Z1gIiEvP2S1IXsr2S2IT_EE3valEE void g(S1::val>*) $ c++filt -n _Z1gIiEvP2S1IXsr2S2IT_E3valEE _Z1gIiEvP2S1IXsr2S2IT_E3valEE So either the change was introduced since that version of c++filt came out, *or* Apple modified it to match clang...
[Bug c++/88413] g++ mangles names involving unresolved names in function argument template parameters differently from the ABI standard.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88413 --- Comment #1 from Andrew Pinski --- Hmm, interesting because the C++ demanager that is part of GCC is able to demanage GCC's and not clang's.
[Bug c++/88413] New: g++ mangles names involving unresolved names in function argument template parameters differently from the ABI standard.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88413 Bug ID: 88413 Summary: g++ mangles names involving unresolved names in function argument template parameters differently from the ABI standard. Product: gcc Version: 8.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: brennan at umanwizard dot com Target Milestone: --- Created attachment 45189 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45189=edit test case Please see the attached test case. how different compilers mangle g: clang: _Z1gIiEvP2S1IXsr2S2IT_EE3valEE g++ : _Z1gIiEvP2S1IXsr2S2IT_E3valEE Notice one less "E" from g++. I believe g++ is wrong here, if I am interpreting https://itanium-cxx-abi.github.io/cxx-abi/abi.html#mangle.unresolved-name correctly. It seems g++ doesn't emit the "E" in ::= [gs] sr + E
[Bug libfortran/88411] [9 Regression] Random crashes for ASYNCHRONOUS writes (bad locking?)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88411 Jerry DeLisle changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2018-12-08 CC||jvdelisle at gcc dot gnu.org, ||koenigni at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #2 from Jerry DeLisle --- Loooking at close.c it looks like we exit st_close before we actually close the unit. So the unit locks will still be locked.
[Bug fortran/88412] Associate segmentation fault assigning to derived type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88412 Dominique d'Humieres changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2018-12-07 Ever confirmed|0 |1 --- Comment #1 from Dominique d'Humieres --- Duplicate of pr87937? I don't get the segfault with a recent trunk (9.0).
[Bug target/88331] ICE in rtl_verify_bb_layout, at cfgrtl.c:2987
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88331 --- Comment #5 from mateuszb at poczta dot onet.pl --- Bug started with r266345 Both files pixel.ii and slicetype.ii could be compile by gcc 9 r266344 and both files ICE gcc 9 r266345. I've attached xz archive with both *.ii files (maybe it helps).
[Bug lto/88396] -flto -Wl,--whole-archive causes "multiple definition" errors in elfutils (only for bfd, not gold)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88396 H.J. Lu changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED See Also||https://sourceware.org/bugz ||illa/show_bug.cgi?id=23958 Resolution|--- |MOVED --- Comment #6 from H.J. Lu --- Moved to https://sourceware.org/bugzilla/show_bug.cgi?id=23958 and fixed for binutils 2.32.
[Bug ipa/85103] [8/9 Regression] Performance regressions on SPEC with r257582
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85103 --- Comment #17 from Jan Hubicka --- I am re-doing benchmarks now to see where we are standing with gcc9. I have checked reducing max-inline-insns-single as Richard mentioned, reducing to 200 or 300 basically brings one regression and that is CactusADM, about 29%. I will experiment with the hints and see if I can tweak the metrics here.
[Bug middle-end/88401] -Wshift-overflow only works for const variables
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88401 --- Comment #5 from Ulya --- (In reply to Jakub Jelinek from comment #4) Right, I see. Bugzilla forced me to add the previous comment when I changed the status. ;)
[Bug ipa/85103] [8/9 Regression] Performance regressions on SPEC with r257582
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85103 --- Comment #16 from Pat Haugen --- > > Do you observe the same slowdown if you restore either of the params to > the value before the r257582 change? > --param max-inline-insns-auto=40 results in the same degradation. --param inline-min-speedup=8 results in even more degratation (an additional 12% over r257582).
[Bug target/79185] [7/8 Regression] register allocation in the addition of two 128/9 bit ints
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79185 Jeffrey A. Law changed: What|Removed |Added Summary|[7/8/9 Regression] register |[7/8 Regression] register |allocation in the addition |allocation in the addition |of two 128/9 bit ints |of two 128/9 bit ints --- Comment #13 from Jeffrey A. Law --- Fixed by this change from Vlad on the trunk: Author: vmakarov Date: Thu Dec 6 18:41:46 2018 + 2018-12-06 Vladimir Makarov PR target/88282 * ira.c (ira_init_register_move_cost): Use info from hard_regno_mode_ok instead of contains_reg_of_mode. * ira-costs.c (contains_reg_of_mode): Don't use cost from bigger hard register class for some fixed hard registers. I don't know if there are any plans to backport that change. So I've just removed the gcc-9 regression tag.
[Bug rtl-optimization/77499] [7/8/9 Regression] Regression after code-hoisting, due to combine pass failing to evaluate known value range
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77499 --- Comment #17 from Jeffrey A. Law --- So if one manually does the sinking I suggest in c#14, we get the key insns into their own block (it's not *that* convoluted). That's still not enough to address the regression in this BZ. We lose the undesired extension, but we end up with extra insns to implement the conditional move.
[Bug fortran/88412] New: Associate segmentation fault assigning to derived type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88412 Bug ID: 88412 Summary: Associate segmentation fault assigning to derived type Product: gcc Version: 8.2.1 Status: UNCONFIRMED Keywords: easyhack Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: m.diehl at mpie dot de Target Milestone: --- The following program fails with a segmentation fault with 8.2.1 20181127 but works with 8.2.1 20180831 program derivedType implicit none type struct integer, dimension(:), allocatable :: p end type type(struct), dimension(2) :: a, b a(1)%p = [1,2,3] a(2)%p = [2,3] associate(a1 => a(1)) print*, 'a1',a1%p end associate associate(a2 => a(2)) print*, 'a2',a2%p end associate associate(b1 => b(1)) b1%p = [5,2,3]! crashes here end associate associate(b2 => b(2)) b2%p = [5,3] end associate print*, 'b1',b(1)%p print*, 'b2',b(2)%p end program
[Bug fortran/87477] [meta-bug] [F03] issues concerning the ASSOCIATE statement
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87477 Bug 87477 depends on bug 87449, which changed state. Bug 87449 Summary: -Wunused-variable and associate https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87449 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |INVALID
[Bug fortran/87449] -Wunused-variable and associate
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87449 Martin Diehl changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |INVALID --- Comment #5 from Martin Diehl --- It appears that b does not need to be defined for associate, so program test implicit none real :: a = 5 associate(b => a) write(6,*) b end associate end program is a valid program where b is only defined within the associate construct and no warning appears
[Bug fortran/71860] [7/8/9 Regression] [OOP] ICE on pointing to null(mold), verify_gimple failed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71860 Harald Anlauf changed: What|Removed |Added CC||anlauf at gmx dot de --- Comment #5 from Harald Anlauf --- Cannot reproduce with 9-trunk rev. 266866, nor gfortran 8.2.1. Also works for me with: GNU Fortran (SUSE Linux) 7.3.1 20180323 [gcc-7-branch revision 258812] Fixed?
[Bug libfortran/88411] [9 Regression] Random crashes for ASYNCHRONOUS writes (bad locking?)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88411 --- Comment #1 from Harald Anlauf --- Further data points: - removing the asynchronous='yes' for the first OPEN has no effect, - removing the asynchronous='yes' for the second OPEN makes the problem disappear
[Bug target/88402] inefficient code generation for mask from CC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88402
--- Comment #3 from Alexander Monakov ---
However, this may be worthwhile when one of operands is an immediate, as in
that case there's no register pressure increase, and the xor just mutates the
immediate.
Essentially, we'd change e.g.
(signed)a < 0xabcd ? -1ul : 0
to
(a^0x8000) < 0x8000abcd ? -1ul : 0
and emit a xorl/cmpl/sbbq sequence, plus a mov if a remains live.
Not for 64-bit operands though, where the 64-bits immediates would be costly.
But unfortunately today we don't manage to use the cmp-sbb trick for unsigned
comparison against an immediate, i.e. for
unsigned long baz (unsigned int a)
{
return a < 123 ? -1ul : 0;
}
we emit
xorl%eax, %eax
cmpl$122, %edi
setbe %al
negq%rax
[Bug libfortran/88411] New: [9 Regression] Random crashes for ASYNCHRONOUS writes (bad locking?)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88411 Bug ID: 88411 Summary: [9 Regression] Random crashes for ASYNCHRONOUS writes (bad locking?) Product: gcc Version: 9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libfortran Assignee: unassigned at gcc dot gnu.org Reporter: anlauf at gmx dot de Target Milestone: --- Created attachment 45187 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45187=edit Compile with -fopenmp, run with OMP_NUM_THREAD=2 or higher. The attached code crashes randomly with 9.0 trunk gfortran when compiled with -fopenmp and running with 2 or more threads: At line 22 of file gfcbug153.f90 (unit = 10, file = 'file2.dat') Fortran runtime error: Write exceeds length of DIRECT access record Error termination. Backtrace: #0 0x7fc02792019d in write_buf at ../../../trunk/libgfortran/io/transfer.c:906 #1 0x7fc027920200 in unformatted_write at ../../../trunk/libgfortran/io/transfer.c:1198 #2 0x40117f in gfcbug153 at /work/dwd/git/dace_code/gfcbug153.f90:22 #3 0x401302 in main at /work/dwd/git/dace_code/gfcbug153.f90:25 Running the code under valgrind prints lots of ==30672== Thread #1: lock order "0x52BF360 before 0x647FBF0" violated ==30672== ==30672== Observed (incorrect) order is: acquisition of lock at 0x647FBF0 ==30672==at 0x4C3291C: ??? (in /usr/lib64/valgrind/vgpreload_helgrind-amd64-linux.so) ==30672==by 0x506F7D1: __gthread_mutex_trylock (gthr-default.h:757) ==30672==by 0x506F7D1: get_gfc_unit (unit.c:380) ==30672==by 0x505C462: _gfortran_st_close (close.c:64) ==30672==by 0x4012CB: MAIN__ (gfcbug153.f90:24) ==30672==by 0x401302: main (gfcbug153.f90:25) ==30672== ==30672== followed by a later acquisition of lock at 0x52BF360 ==30672==at 0x4C3273C: ??? (in /usr/lib64/valgrind/vgpreload_helgrind-amd64-linux.so) ==30672==by 0x507043B: __gthread_mutex_lock (gthr-default.h:748) ==30672==by 0x507043B: close_unit_1 (unit.c:735) ==30672==by 0x4012CB: MAIN__ (gfcbug153.f90:24) ==30672==by 0x401302: main (gfcbug153.f90:25) ==30672== ==30672== Required order was established by acquisition of lock at 0x52BF360 ==30672==at 0x4C3273C: ??? (in /usr/lib64/valgrind/vgpreload_helgrind-amd64-linux.so) ==30672==by 0x506F73C: __gthread_mutex_lock (gthr-default.h:748) ==30672==by 0x506F73C: get_gfc_unit (unit.c:332) ==30672==by 0x50678E8: _gfortran_st_open (open.c:880) ==30672==by 0x400F82: MAIN__ (gfcbug153.f90:20) ==30672==by 0x401302: main (gfcbug153.f90:25) ==30672== ==30672== followed by a later acquisition of lock at 0x647FBF0 ==30672==at 0x4C3273C: ??? (in /usr/lib64/valgrind/vgpreload_helgrind-amd64-linux.so) ==30672==by 0x506F6A9: __gthread_mutex_lock (gthr-default.h:748) ==30672==by 0x506F6A9: insert_unit (unit.c:244) ==30672==by 0x506F8C7: get_gfc_unit (unit.c:356) ==30672==by 0x50678E8: _gfortran_st_open (open.c:880) ==30672==by 0x400F82: MAIN__ (gfcbug153.f90:20) ==30672==by 0x401302: main (gfcbug153.f90:25) ==30672== ==30672== Lock at 0x52BF360 was first observed ==30672==at 0x4C3273C: ??? (in /usr/lib64/valgrind/vgpreload_helgrind-amd64-linux.so) ==30672==by 0x506F73C: __gthread_mutex_lock (gthr-default.h:748) ==30672==by 0x506F73C: get_gfc_unit (unit.c:332) ==30672==by 0x50678E8: _gfortran_st_open (open.c:880) ==30672==by 0x400A96: MAIN__ (gfcbug153.f90:11) ==30672==by 0x401302: main (gfcbug153.f90:25) ==30672== Address 0x52bf360 is 0 bytes inside data symbol "_gfortrani_unit_lock" ==30672== ==30672== Lock at 0x647FBF0 was first observed ==30672==at 0x4C3273C: ??? (in /usr/lib64/valgrind/vgpreload_helgrind-amd64-linux.so) ==30672==by 0x506F6A9: __gthread_mutex_lock (gthr-default.h:748) ==30672==by 0x506F6A9: insert_unit (unit.c:244) ==30672==by 0x506F8C7: get_gfc_unit (unit.c:356) ==30672==by 0x50678E8: _gfortran_st_open (open.c:880) ==30672==by 0x400F82: MAIN__ (gfcbug153.f90:20) ==30672==by 0x401302: main (gfcbug153.f90:25) ==30672== Address 0x647fbf0 is 224 bytes inside a block of size 752 alloc'd ==30672==at 0x4C31645: calloc (in /usr/lib64/valgrind/vgpreload_helgrind-amd64-linux.so) ==30672==by 0x4E61C42: _gfortrani_xcalloc (memory.c:83) ==30672==by 0x506F667: insert_unit (unit.c:233) ==30672==by 0x506F8C7: get_gfc_unit (unit.c:356) ==30672==by 0x50678E8: _gfortran_st_open (open.c:880) ==30672==by 0x400F82: MAIN__ (gfcbug153.f90:20) ==30672==by 0x401302: main (gfcbug153.f90:25) ==30672== Block was alloc'd by thread #1 etc.
[Bug target/67288] [7/8/9 regression] non optimal simple function (useless additional shift/remove/shift/add)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67288 --- Comment #16 from Segher Boessenkool --- Many things in combine assume that they can move an earlier insn to later, if none of the registers it uses is set in the intermediate insns (etc.) This isn't correct if you make combine work on EBBs. Keeping the reg_stat info based on dominance relations doesn't work the way things are set up now. I have long wished for a dataflow problem that would compute known 0/1/ext bits, or value ranges, etc. Ideally this can replace reg_stat completely. This would be both more powerful and simpler and much less problematic code :-)
[Bug c++/88410] New: internal compiler error: output_operand: invalid expression as operand
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88410 Bug ID: 88410 Summary: internal compiler error: output_operand: invalid expression as operand Product: gcc Version: 8.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: notorca at gmail dot com Target Milestone: --- Created attachment 45186 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45186=edit Preprocessed source to reproduce error I've got ../../runtime/vm/raw_object_fields.cc:218:1: internal compiler error: output_operand: invalid expression as operand when trying to build https://github.com/dart-lang/sdk Preprocessed source is attached. Build command is: g++ -MMD -MF x86/obj/runtime/vm/libdart_vm_nosnapshot_with_precompiler.raw_object_fields.o.d -D_FORTIFY_SOURCE=2 -DNDEBUG -DTARGET_ARCH_ARM -DTARGET_ARCH_ARM_6 -DNDEBUG -DDART_USE_TCMALLOC -DTARGET_OS_LINUX -DDART_NO_SNAPSHOT -DDART_PRECOMPILER -I../../runtime -I../.. -Ix86/gen -I../../runtime/include -I../../third_party/tcmalloc/gperftools/src -m32 -msse2 -mfpmath=sse -fno-exceptions -pthread -Wendif-labels -Wno-missing-field-initializers -Wno-unused-parameter -fdebug-prefix-map=/home/lorca/dart/sdk=../.. -no-canonical-prefixes -O3 -fno-ident -fdata-sections -ffunction-sections -g3 -ggdb3 -Wno-unused-parameter -Wnon-virtual-dtor -Wvla -Wno-conversion-null -Woverloaded-virtual -Wno-comments -g3 -ggdb3 -fno-rtti -fno-exceptions -O3 -fvisibility-inlines-hidden -fno-omit-frame-pointer -std=gnu++11 -fno-rtti -fno-exceptions -c preprocessed.cc Reproduces on gcc version 8.2.0 (Ubuntu 8.2.0-7ubuntu1) and gcc version 7.3.0 (Ubuntu 7.3.0-27ubuntu1~18.04)
[Bug target/67288] [7/8/9 regression] non optimal simple function (useless additional shift/remove/shift/add)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67288 Jeffrey A. Law changed: What|Removed |Added CC||law at redhat dot com --- Comment #15 from Jeffrey A. Law --- I agree that the data combine would need comes from a different block. But ISTM that there's a dominance relationship we could exploit here. Specifically blocks 2 & 3 are a class extended basic block. Information generated in bb2 (or on the edge bb2->bb3) may still be available in bb3. I don't think we're set up to exploit extended blocks in combine, but that may be something worth exploring.
[Bug rtl-optimization/69633] [7/8/9 Regression] Redundant move is generated after r228097
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69633 Jeffrey A. Law changed: What|Removed |Added CC||law at redhat dot com --- Comment #13 from Jeffrey A. Law --- >From my reading, it looks like we do worse now than in previous releases. Things look OK going into IRA. The IRA allocations are different, but I haven't analyzed in any detail why and if one is inherently better than the other. LRA inserts more reloads/copies on the trunk than we did way back in r228097.
[Bug target/54589] struct offset add should be folded into address calculation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54589 --- Comment #13 from Segher Boessenkool --- Yeah, that's not going to happen. Will it help to do some define_split or define_insn_and_split for this?
[Bug target/88316] numerous big-endian issues with compatibility implementations of vector intrinsics for powerpc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88316 --- Comment #4 from pc at gcc dot gnu.org --- SSSE3 is still broken. Working on it...
[Bug other/88409] [9 Regression] FAIL at line 4429, options --format=gnu-v3:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88409 Ian Lance Taylor changed: What|Removed |Added CC||ian at airs dot com --- Comment #7 from Ian Lance Taylor --- It looks like that was a real symbol from a real program. What happens if we double the recursion limit?
[Bug target/87496] ICE in aggregate_value_p at gcc/function.c:2046
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87496 --- Comment #10 from Peter Bergner --- Author: bergner Date: Fri Dec 7 17:33:55 2018 New Revision: 266899 URL: https://gcc.gnu.org/viewcvs?rev=266899=gcc=rev Log: gcc/ PR target/87496 * config/rs6000/rs6000.c (rs6000_option_override_internal): Disallow -mabi=ieeelongdouble and -mabi=ibmlongdouble without -mlong-double-128. Do not error for -mabi=ibmlongdouble and no ISA 2.06 support. * doc/invoke.texi: Document -mabi=ibmlongdouble and -mabi=ieeelongdouble require -mlong-double-128. gcc/testsuite/ PR target/87496 * gcc.target/powerpc/pr87496.c: Rename from this... * gcc.target/powerpc/pr87496-1.c: ...to this. Update comment. * gcc.target/powerpc/pr87496-2.c: New test. * gcc.target/powerpc/pr87496-3.c: New test. Added: trunk/gcc/testsuite/gcc.target/powerpc/pr87496-1.c - copied, changed from r266898, trunk/gcc/testsuite/gcc.target/powerpc/pr87496.c trunk/gcc/testsuite/gcc.target/powerpc/pr87496-2.c trunk/gcc/testsuite/gcc.target/powerpc/pr87496-3.c Removed: trunk/gcc/testsuite/gcc.target/powerpc/pr87496.c Modified: trunk/gcc/ChangeLog trunk/gcc/config/rs6000/rs6000.c trunk/gcc/doc/invoke.texi trunk/gcc/testsuite/ChangeLog
[Bug other/88409] [9 Regression] FAIL at line 4429, options --format=gnu-v3:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88409 --- Comment #6 from H.J. Lu --- (In reply to Nick Clifton from comment #5) > (In reply to H.J. Lu from comment #4) > > > I am expecting that > > > > [hjl@gnu-cfl-1 libiberty]$ c++filt > > _ZN4modc6parser8sequenceINS_9astParser13LocatedParserINS0_9ParserRefINS2_UlRN > > S2_16TokenParserInputEE_EINS0_14OptionalParserINS2_18ListParserTemplateIL > > NS_6tokens5Token4TypeE4EXadL_ZNSD_Ut_13parenthesized6ParserINS4_INS0_6Par > > serIS5_NS_3ast10ExpressionENSA_INS4_INS2_22OneOfKeywordsToTParserINSJ > > _5StyleEEENS0_14SequenceParserIS5_INS0_18ExactElementParserIS5_EENSA_ISM_ > > ENS0_14RepeatedParserINS4_INS0_15TransformParserINSU_IS5_INS4_INSP_INSJ_1 > > 0Annotation12RelationshipESX_EEENS2_UlNS2_3LocES12_ONS_5MaybeISK_EEE19_EE > > EEELb0EENSU_INS0_17ExtractParserTypeIT_E9InputTypeEINS0_8MaybeRefIS1F_E4T > > ypeEDpNS1I_IT0_E4TypeOS1F_DpOS1L_ > > > > continues to work. Does it work with your patch? > > No. > > But "c++filt -r " will work. > > Is that string an example of a real world mangled symbol name, or was it just > invented to test the demangler ? It came from the fix for https://sourceware.org/bugzilla/show_bug.cgi?id=14065
[Bug c++/87861] [9 regression] ICE in output_constructor_regular_field, at varasm.c:5165
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87861 --- Comment #9 from Jeffrey A. Law --- Jakub -- with your patch and qsort checking hacked off I got a successful ia64 bootstrap.
[Bug libgomp/87995] [9 regression] libgomp.c/../libgomp.c-c++-common/cancel-taskgroup-3.c fails consistently after r265930
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87995 Jakub Jelinek changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2018-12-07 Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #2 from Jakub Jelinek --- Created attachment 45185 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45185=edit gcc9-pr87995.patch Ah, testsuite issue and one needs more than 64 threads for that.
[Bug target/88408] [9 regression] r266868 breaks gcc.target/powerpc/undef-bool-2.c on powerpc64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88408 pc at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #3 from pc at gcc dot gnu.org --- Fix checked in, per comment #2
[Bug middle-end/87813] sprintf pass calling evrp at -O0 and setting global ranges which affect strnlen expansion
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87813 Jeffrey A. Law changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #11 from Jeffrey A. Law --- Fixed on the trunk.
[Bug target/88408] [9 regression] r266868 breaks gcc.target/powerpc/undef-bool-2.c on powerpc64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88408 pc at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2018-12-07 CC||pc at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |pc at gcc dot gnu.org Ever confirmed|0 |1
[Bug other/88409] [9 Regression] FAIL at line 4429, options --format=gnu-v3:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88409 --- Comment #5 from Nick Clifton --- (In reply to H.J. Lu from comment #4) > I am expecting that > > [hjl@gnu-cfl-1 libiberty]$ c++filt > _ZN4modc6parser8sequenceINS_9astParser13LocatedParserINS0_9ParserRefINS2_UlRN > S2_16TokenParserInputEE_EINS0_14OptionalParserINS2_18ListParserTemplateIL > NS_6tokens5Token4TypeE4EXadL_ZNSD_Ut_13parenthesized6ParserINS4_INS0_6Par > serIS5_NS_3ast10ExpressionENSA_INS4_INS2_22OneOfKeywordsToTParserINSJ > _5StyleEEENS0_14SequenceParserIS5_INS0_18ExactElementParserIS5_EENSA_ISM_ > ENS0_14RepeatedParserINS4_INS0_15TransformParserINSU_IS5_INS4_INSP_INSJ_1 > 0Annotation12RelationshipESX_EEENS2_UlNS2_3LocES12_ONS_5MaybeISK_EEE19_EE > EEELb0EENSU_INS0_17ExtractParserTypeIT_E9InputTypeEINS0_8MaybeRefIS1F_E4T > ypeEDpNS1I_IT0_E4TypeOS1F_DpOS1L_ > > continues to work. Does it work with your patch? No. But "c++filt -r " will work. Is that string an example of a real world mangled symbol name, or was it just invented to test the demangler ?
[Bug other/88409] [9 Regression] FAIL at line 4429, options --format=gnu-v3:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88409 --- Comment #4 from H.J. Lu --- (In reply to Nick Clifton from comment #3) > (In reply to H.J. Lu from comment #2) > > Hi H.J. > > > > The attached patch resolves the problem by adding a --no-recurse-limit > > > option to the demangler testser and then using it for the problematic > > > test case. I felt that this was a better solution than raising the > > > recursion limit, as it means that the limit detecting code will actually > > > be exercised by the testsuite. > > > This will cause a regression since this input will fail now. > > Umm, sorry ? The change means that the old behaviour of the demangler > is restored. Ie the recursion limit is not enforced, and thus the test > will behave exactly as it used to do. > > Unless you mean that there would be a problem if the test input (or > something similar) is ever generated by the compilation of a real-world > program. In which case I agree, there would be a problem. But are you > ever going to get a real-world mangled version of: > > I am expecting that [hjl@gnu-cfl-1 libiberty]$ c++filt _ZN4modc6parser8sequenceINS_9astParser13LocatedParserINS0_9ParserRefINS2_UlRNS2_16TokenParserInputEE_EINS0_14OptionalParserINS2_18ListParserTemplateILNS_6tokens5Token4TypeE4EXadL_ZNSD_Ut_13parenthesized6ParserINS4_INS0_6ParserIS5_NS_3ast10ExpressionENSA_INS4_INS2_22OneOfKeywordsToTParserINSJ_5StyleEEENS0_14SequenceParserIS5_INS0_18ExactElementParserIS5_EENSA_ISM_ENS0_14RepeatedParserINS4_INS0_15TransformParserINSU_IS5_INS4_INSP_INSJ_10Annotation12RelationshipESX_EEENS2_UlNS2_3LocES12_ONS_5MaybeISK_EEE19_ELb0EENSU_INS0_17ExtractParserTypeIT_E9InputTypeEINS0_8MaybeRefIS1F_E4TypeEDpNS1I_IT0_E4TypeOS1F_DpOS1L_ continues to work. Does it work with your patch?
[Bug rtl-optimization/88349] [9 regression][MIPS] Redundant store instructions generated start with r266385
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88349 Jeffrey A. Law changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||law at redhat dot com Resolution|--- |FIXED --- Comment #3 from Jeffrey A. Law --- Fixed by Vlad's commit on the trunk
[Bug other/88409] [9 Regression] FAIL at line 4429, options --format=gnu-v3:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88409
Nick Clifton changed:
What|Removed |Added
Status|NEW |ASSIGNED
--- Comment #3 from Nick Clifton ---
(In reply to H.J. Lu from comment #2)
Hi H.J.
> > The attached patch resolves the problem by adding a --no-recurse-limit
> > option to the demangler testser and then using it for the problematic
> > test case. I felt that this was a better solution than raising the
> > recursion limit, as it means that the limit detecting code will actually
> > be exercised by the testsuite.
> This will cause a regression since this input will fail now.
Umm, sorry ? The change means that the old behaviour of the demangler
is restored. Ie the recursion limit is not enforced, and thus the test
will behave exactly as it used to do.
Unless you mean that there would be a problem if the test input (or
something similar) is ever generated by the compilation of a real-world
program. In which case I agree, there would be a problem. But are you
ever going to get a real-world mangled version of:
modc::parser::ParserRef::Parser::Style>
>
> >::InputType,
modc::parser::MaybeRef&&)#21}>::Type,
modc::parser::RepeatedParser::Parser::Style>
>::Parser >
>::Parser::Annotation::Relationship> >,
modc::parser::ExactElementParser> >,
modc::astParser::{lambda(modc::astParser::Loc, modc::parser::RepeatedParser,
modc::Maybe&&)#21}> >,
false>::Parser > > > >::Type,
modc::parser::RepeatedParser::Parser::Style>
>::Parser >
>::Parser::Annotation::Relationship> >,
modc::parser::ExactElementParser> >,
modc::astParser::{lambda(modc::astParser::Loc, modc::parser::RepeatedParser,
modc::Maybe&&)#21}> >,
false>
>::Parser::Style> > > >::Type,
modc::parser::RepeatedParser::Parser::Style>
>::Parser >
>::Parser::Annotation::Relationship> >,
modc::parser::ExactElementParser> >,
modc::astParser::{lambda(modc::astParser::Loc, modc::parser::RepeatedParser,
modc::Maybe&&)#21}> >,
false>,
modc::astParser::LocatedParser
> > > >::Type,
modc::parser::RepeatedParser::Parser::Style>
>::Parser >
>::Parser::Annotation::Relationship> >,
modc::parser::ExactElementParser> >,
modc::astParser::{lambda(modc::astParser::Loc, modc::parser::RepeatedParser,
modc::Maybe&&)#21}> >,
false>::Parser::Style>
>::Parser >
>::Parser::Annotation::Relationship> >,
modc::parser::ExactElementParser> >,
modc::astParser::{lambda(modc::astParser::Loc, modc::parser::RepeatedParser,
modc::Maybe&&)#21}> >, false> >::Type>
modc::parser::sequence
>,
modc::parser::OptionalParser::Parser > > >,
modc::astParser::LocatedParser
>::Parser::Style> > >,
modc::parser::SequenceParser,
modc::astParser::LocatedParser
> > >,
modc::parser::RepeatedParser::Parser::Style>
>::Parser >
>::Parser::Annotation::Relationship> >,
modc::parser::ExactElementParser> >,
modc::astParser::{lambda(modc::astParser::Loc, modc::parser::RepeatedParser,
modc::Maybe&&)#21}> >, false>
>(modc::astParser::{lambda(modc::astParser::Loc, modc::parser::RepeatedParser,
modc::Maybe&&)#21}&&,
(modc::parser::ExtractParserType
> >&&)...)
I would have thought that that would be extremely unlikely. Am I wrong ?
[Bug other/88409] [9 Regression] FAIL at line 4429, options --format=gnu-v3:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88409 H.J. Lu changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2018-12-07 Ever confirmed|0 |1 --- Comment #2 from H.J. Lu --- (In reply to Nick Clifton from comment #1) > Created attachment 45184 [details] > Proposed patch > > *sigh* Yes, I forgot to run the libiberty testsuite, and of course > there is one test that actually breaches the demangling limit. > > The attached patch resolves the problem by adding a --no-recurse-limit > option to the demangler testser and then using it for the problematic > test case. I felt that this was a better solution than raising the > recursion limit, as it means that the limit detecting code will actually > be exercised by the testsuite. > > Currently waiting for review of the patch... This will cause a regression since this input will fail now.
[Bug target/88408] [9 regression] r266868 breaks gcc.target/powerpc/undef-bool-2.c on powerpc64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88408 --- Comment #2 from pc at gcc dot gnu.org --- Author: pc Date: Fri Dec 7 16:32:34 2018 New Revision: 266895 URL: https://gcc.gnu.org/viewcvs?rev=266895=gcc=rev Log: [rs6000] mmintrin.h: fix use of "vector" A recent patch inadvertently added the use of "vector" to mmintrin.h when all such uses should be "__vector". [gcc] 2018-12-07 Paul A. Clarke PR target/88408 * config/rs6000/mmintrin.h (_mm_packs_pu16): Correctly use "__vector". Modified: trunk/gcc/ChangeLog trunk/gcc/config/rs6000/mmintrin.h
[Bug other/88409] [9 Regression] FAIL at line 4429, options --format=gnu-v3:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88409 Nick Clifton changed: What|Removed |Added CC||nickc at gcc dot gnu.org --- Comment #1 from Nick Clifton --- Created attachment 45184 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45184=edit Proposed patch *sigh* Yes, I forgot to run the libiberty testsuite, and of course there is one test that actually breaches the demangling limit. The attached patch resolves the problem by adding a --no-recurse-limit option to the demangler testser and then using it for the problematic test case. I felt that this was a better solution than raising the recursion limit, as it means that the limit detecting code will actually be exercised by the testsuite. Currently waiting for review of the patch...
[Bug target/88408] [9 regression] r266868 breaks gcc.target/powerpc/undef-bool-2.c on powerpc64 LE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88408 seurer at gcc dot gnu.org changed: What|Removed |Added Target|powerpc64-unknown-linux-gnu |powerpc64*-unknown-linux-gn ||u Build|powerpc64le-unknown-linux-g |powerpc64*-unknown-linux-gn |nu |u --- Comment #1 from seurer at gcc dot gnu.org --- Also fails on BE after further testing.
[Bug other/88409] New: [9 Regression] FAIL at line 4429, options --format=gnu-v3:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88409 Bug ID: 88409 Summary: [9 Regression] FAIL at line 4429, options --format=gnu-v3: Product: gcc Version: 9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: other Assignee: unassigned at gcc dot gnu.org Reporter: hjl.tools at gmail dot com CC: nickc at redhat dot com Target Milestone: --- r266886 caused: ./test-demangle < /export/gnu/import/git/sources/gcc/libiberty/testsuite/demangle-expected FAIL at line 4429, options --format=gnu-v3: in: _ZN4modc6parser8sequenceINS_9astParser13LocatedParserINS0_9ParserRefINS2_UlRNS2_16TokenParserInputEE_EINS0_14OptionalParserINS2_18ListParserTemplateILNS_6tokens5Token4TypeE4EXadL_ZNSD_Ut_13parenthesized6ParserINS4_INS0_6ParserIS5_NS_3ast10ExpressionENSA_INS4_INS2_22OneOfKeywordsToTParserINSJ_5StyleEEENS0_14SequenceParserIS5_INS0_18ExactElementParserIS5_EENSA_ISM_ENS0_14RepeatedParserINS4_INS0_15TransformParserINSU_IS5_INS4_INSP_INSJ_10Annotation12RelationshipESX_EEENS2_UlNS2_3LocES12_ONS_5MaybeISK_EEE19_ELb0EENSU_INS0_17ExtractParserTypeIT_E9InputTypeEINS0_8MaybeRefIS1F_E4TypeEDpNS1I_IT0_E4TypeOS1F_DpOS1L_ out: (null)
[Bug target/88271] Omit test instruction after add
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88271 --- Comment #9 from Daniel Fruzynski --- I have idea about alternate approach to this. gcc could try to look for relations between loop control statement, and other statements which modify variables used in that control statement. With such knowledge it could try to reorganize code to better optimize it. This approach would eliminate randomness here.
[Bug rtl-optimization/88349] [9 regression][MIPS] Redundant store instructions generated start with r266385
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88349 --- Comment #2 from Vladimir Makarov --- Author: vmakarov Date: Fri Dec 7 16:08:17 2018 New Revision: 266894 URL: https://gcc.gnu.org/viewcvs?rev=266894=gcc=rev Log: 2018-12-07 Vladimir Makarov PR rtl-optimization/88349 * ira-costs.c (record_operand_costs): Check bigger reg class on NO_REGS. 2018-12-07 Vladimir Makarov PR rtl-optimization/88349 * gcc.target/mips/pr88349.c: New. Added: trunk/gcc/testsuite/gcc.target/mips/pr88349.c Modified: trunk/gcc/ChangeLog trunk/gcc/ira-costs.c trunk/gcc/testsuite/ChangeLog
[Bug c++/87861] [9 regression] ICE in output_constructor_regular_field, at varasm.c:5165
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87861 --- Comment #8 from Jeffrey A. Law --- We certainly get further with your patch -- we fail qsort checking during the stage2 build, but that's nothing new. ia64 has run afoul of the qsort checking since the day qsort checking was introduced. I'll hack around it and let the bootstrap continue.
[Bug tree-optimization/88259] vectorization failure for a typical loop for getting max value and index
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88259 --- Comment #4 from rsandifo at gcc dot gnu.org --- (In reply to Richard Biener from comment #3) > The vectorizer does not like > >[local count: 955630224]: > # best_i_25 = PHI > # best_26 = PHI > # i_27 = PHI > _1 = (long unsigned int) i_27; > _2 = _1 * 4; > _3 = data_18(D) + _2; > _4 = *_3; > best_i_11 = _4 <= best_26 ? best_i_25 : i_27; > best_13 = MAX_EXPR <_4, best_26>; > i_20 = i_27 + 1; > if (n_17(D) > i_20) > > because for the best MAX reduction we have an additional use of the > reduction value in the index reduction. This combination isn't > magically supported even though in isolation both cases are. > > t.c:4:5: note: Analyze phi: best_26 = PHI > t.c:4:5: missed: reduction used in loop. > t.c:4:5: missed: Unknown def-use cycle pattern. > t.c:4:5: note: Analyze phi: best_i_25 = PHI best_i_16(D)(18)> > t.c:4:5: note: detected reduction: need to swap operands: best_i_11 = _4 > > best_26 ? i_27 : best_i_25; > t.c:4:5: note: Detected reduction. > > if we'd been lucky and had analyzed best_i_25 before best_26 then we could > probably special-case the case of "reduction used in loop" when that appears > in other reductions. In general that's of course still not valid I think. Yeah. Disabling the check for uses in the loop: /* If this isn't a nested cycle or if the nested cycle reduction value is used ouside of the inner loop we cannot handle uses of the reduction value. */ if ((!nested_in_vect_loop || inner_loop_of_double_reduc) && (nlatch_def_loop_uses > 1 || nphi_def_loop_uses > 1)) gives us something like the vector body we want, modulo some inefficiency: .L4: ldr q4, [x2], 16 mov v3.16b, v2.16b add v2.4s, v2.4s, v6.4s cmgev5.4s, v0.4s, v4.4s cmp x3, x2 smaxv0.4s, v0.4s, v4.4s bif v1.16b, v3.16b, v5.16b bne .L4 where v0.4s ends up containing the maximum for each individual lane and v1.s contains the best_i associated with each member of v0.4s. We "just" then need to make the epilogue do the right thing with this information. Hacking out the condition above (obviously an invalid thing to do) sets "best" to the maximum of v0.s (good) but also sets "best_i" to the maximum of v1.s (bad). We need to restrict the maximum of v1.s to lanes of v0.s that contain "best" (i.e. the reduction result of v0.s): dupv2.4s, best cmpeq v2.4s, v2.4s, v0.4s andv1.4s, v1.4s, v2.4s and only then take the maximum of v1.4s. This requires "best" to come from a reassociatve conditional reduction and would require the "best_i" reduction to be marked as dependent on the "best" reduction. Might end up being a bit messy, since we'd have to be careful to retain the uses check above for all other cases.
[Bug middle-end/64242] Longjmp expansion incorrect
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64242 --- Comment #21 from Wilco --- (In reply to Rainer Orth from comment #20) > The new testcase also FAILs on sparc-sun-solaris2.11 (both 32 and 64-bit): > > +FAIL: gcc.c-torture/execute/pr64242.c -O2 execution test > +FAIL: gcc.c-torture/execute/pr64242.c -O2 -flto execution test > +FAIL: gcc.c-torture/execute/pr64242.c -O2 -flto -flto-partition=none > execution test > +FAIL: gcc.c-torture/execute/pr64242.c -O3 -g execution test > +FAIL: gcc.c-torture/execute/pr64242.c -Os execution test > > Thread 2 received signal SIGSEGV, Segmentation fault. > [Switching to Thread 1 (LWP 1)] > 0x0008 in ?? () > (gdb) where > #0 0x0008 in ?? () > Backtrace stopped: previous frame identical to this frame (corrupt stack?) > > Single-stepping, I find that this happens at the very end of main: > > 1: x/i $pc > => 0x10de4 : return %i7 + 8 > (gdb) > 0x00010de8 in main () > at > /vol/gcc/src/hg/trunk/local/gcc/testsuite/gcc.c-torture/execute/pr64242.c:50 > 50return 0; > 1: x/i $pc > => 0x10de8 : nop > (gdb) > 0x0008 in ?? () > 1: x/i $pc > => 0x8: > > Obviously the stack is corrupted beyond repair. I tried to avoid this by > replacing the return 0 with exit (0) to no avail. My latest patch detects this stack corruption with 100% certainty again, see https://gcc.gnu.org/ml/gcc-patches/2018-12/msg00459.html. However sparc has a custom nonlocal_goto MD pattern which would need fixing too.
[Bug target/88408] New: [9 regression] r266868 breaks gcc.target/powerpc/undef-bool-2.c on powerpc64 LE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88408
Bug ID: 88408
Summary: [9 regression] r266868 breaks
gcc.target/powerpc/undef-bool-2.c on powerpc64 LE
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: seurer at gcc dot gnu.org
Target Milestone: ---
spawn -ignore SIGHUP /home/seurer/gcc/build/gcc-test2/gcc/xgcc
-B/home/seurer/gcc/build/gcc-test2/gcc/
/home/seurer/gcc/gcc-test2/gcc/testsuite/gcc.target/powerpc/undef-bool-2.c
-fno-diagnostics-show-caret -fno-diagnostics-show-line-numbers
-fdiagnostics-color=never -O2 -std=c11 -DNO_WARN_X86_INTRINSICS -mvsx -S -o
undef-bool-2.s
In file included from
/home/seurer/gcc/build/gcc-test2/gcc/include/xmmintrin.h:79,
from
/home/seurer/gcc/gcc-test2/gcc/testsuite/gcc.target/powerpc/undef-bool-2.c:10:
/home/seurer/gcc/build/gcc-test2/gcc/include/mmintrin.h: In function
'_mm_packs_pu16':
/home/seurer/gcc/build/gcc-test2/gcc/include/mmintrin.h:231:19: error: 'vector'
undeclared (first use in this function); did you mean 'vec_or'?
/home/seurer/gcc/build/gcc-test2/gcc/include/mmintrin.h:231:19: note: each
undeclared identifier is reported only once for each function it appears in
/home/seurer/gcc/build/gcc-test2/gcc/include/mmintrin.h:231:25: error: expected
')' before 'unsigned'
/home/seurer/gcc/build/gcc-test2/gcc/include/mmintrin.h:231:41: error: expected
')' before 'vm1'
/home/seurer/gcc/build/gcc-test2/gcc/include/mmintrin.h:233:25: error: expected
')' before 'vector'
/home/seurer/gcc/build/gcc-test2/gcc/include/mmintrin.h:233:3: error: can't
convert a vector of type '__vector signed short' {aka 'const __vector(8) short
int'} to type 'int' which has different size
/home/seurer/gcc/gcc-test2/gcc/testsuite/gcc.target/powerpc/undef-bool-2.c: At
top level:
/home/seurer/gcc/gcc-test2/gcc/testsuite/gcc.target/powerpc/undef-bool-2.c:12:1:
error: unknown type name 'bool'
compiler exited with status 1
PASS: gcc.target/powerpc/undef-bool-2.c (test for errors, line 12)
FAIL: gcc.target/powerpc/undef-bool-2.c (test for excess errors)
Excess errors:
/home/seurer/gcc/build/gcc-test2/gcc/include/mmintrin.h:231:19: error: 'vector'
undeclared (first use in this function); did you mean 'vec_or'?
/home/seurer/gcc/build/gcc-test2/gcc/include/mmintrin.h:231:25: error: expected
')' before 'unsigned'
/home/seurer/gcc/build/gcc-test2/gcc/include/mmintrin.h:231:41: error: expected
')' before 'vm1'
/home/seurer/gcc/build/gcc-test2/gcc/include/mmintrin.h:233:25: error: expected
')' before 'vector'
/home/seurer/gcc/build/gcc-test2/gcc/include/mmintrin.h:233:3: error: can't
convert a vector of type '__vector signed short' {aka 'const __vector(8) short
int'} to type 'int' which has different size
[Bug driver/35532] Native GCC no longer searches $prefix/lib for startfiles when run from $objdir
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=35532 Eric Gallager changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |INVALID --- Comment #19 from Eric Gallager --- (In reply to Andrew Pinski from comment #18) > > 1. build and install Glibc --prefix=/tmp/foo > > Since glibc is not able to build this way any more, I doubt this can be > supported. OK, I guess I will actually close it then after all.
[Bug target/88402] inefficient code generation for mask from CC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88402 Alexander Monakov changed: What|Removed |Added CC||amonakov at gcc dot gnu.org --- Comment #2 from Alexander Monakov --- It's possible to change signed comparison to unsigned by rotating integer domain by half, i.e. foo(a, b) == bar(a^0x8000, b^0x8000) but this increases register pressure if a and b are not dead after the comparison.
[Bug target/37637] Build fails with reserved constraints
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=37637 Eric Gallager changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |WORKSFORME --- Comment #3 from Eric Gallager --- (In reply to Matthias Klose from comment #2) > Debian doesn't have any s390 hardware anymore. multilib builds on > s390x-linux-gnu work, so maybe just close this issue. OK.
[Bug c++/86669] [7/8 regression] Complete object constructor clone omits length for a c++11 braced initialiser
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86669 Jakub Jelinek changed: What|Removed |Added Summary|[7/8/9 regression] Complete |[7/8 regression] Complete |object constructor clone|object constructor clone |omits length for a c++11|omits length for a c++11 |braced initialiser |braced initialiser --- Comment #8 from Jakub Jelinek --- Fixed for GCC9+ so far.
[Bug c++/87861] [9 regression] ICE in output_constructor_regular_field, at varasm.c:5165
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87861 --- Comment #7 from Jeffrey A. Law --- I've still got my ia64 beaker box from yesterday provisioned. I'll spin your patch.
[Bug c++/87506] [7/8 Regression] ICE with inherited constexpr constructor with const argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87506 Jakub Jelinek changed: What|Removed |Added Summary|[7/8/9 Regression] ICE with |[7/8 Regression] ICE with |inherited constexpr |inherited constexpr |constructor with const |constructor with const |argument|argument --- Comment #4 from Jakub Jelinek --- Fixed for GCC9+ so far.
[Bug tree-optimization/88367] [9 Regression] -fno-delete-null-pointer-checks doesn't work properly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88367 Jakub Jelinek changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #11 from Jakub Jelinek --- Hopefully fixed now.
[Bug fortran/88377] ICE in gfc_omp_clause_copy_ctor, at fortran/trans-openmp.c:614
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88377 --- Comment #3 from Jakub Jelinek --- Fixed on GCC trunk so far.
[Bug target/85593] [7/8 Regression] GCC on ARM allocates R3 for local variable when calling naked function with O2 optimizations enabled
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85593 --- Comment #15 from Jakub Jelinek --- ARM maintainers - feel free to add some ARM test for naked vs. IPA-RA too.
[Bug target/86753] [9 Regression] gcc.target/aarch64/sve/vcond_[45].c fail after recent combine patch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86753 --- Comment #6 from Jeffrey A. Law --- Sorry, my misunderstanding. I thought you had indicated the resulting code was better.
[Bug c++/86669] [7/8/9 regression] Complete object constructor clone omits length for a c++11 braced initialiser
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86669 --- Comment #7 from Jakub Jelinek --- Author: jakub Date: Fri Dec 7 15:20:04 2018 New Revision: 266893 URL: https://gcc.gnu.org/viewcvs?rev=266893=gcc=rev Log: PR c++/86669 * call.c (make_temporary_var_for_ref_to_temp): Call pushdecl even for automatic vars. * g++.dg/cpp0x/initlist105.C: New test. * g++.dg/cpp0x/initlist106.C: New test. * g++.dg/other/pr86669.C: New test. Added: trunk/gcc/testsuite/g++.dg/cpp0x/initlist105.C trunk/gcc/testsuite/g++.dg/cpp0x/initlist106.C trunk/gcc/testsuite/g++.dg/other/pr86669.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/call.c trunk/gcc/testsuite/ChangeLog
[Bug libgomp/88407] [OpenACC] Correctly handle unseen async-arguments
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88407 Thomas Schwinge changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2018-12-07 Assignee|unassigned at gcc dot gnu.org |tschwinge at gcc dot gnu.org Ever confirmed|0 |1
[Bug libgomp/88407] New: [OpenACC] Correctly handle unseen async-arguments
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88407 Bug ID: 88407 Summary: [OpenACC] Correctly handle unseen async-arguments Product: gcc Version: 9.0 Status: UNCONFIRMED Keywords: openacc, patch Severity: normal Priority: P3 Component: libgomp Assignee: unassigned at gcc dot gnu.org Reporter: tschwinge at gcc dot gnu.org CC: cltang at gcc dot gnu.org, jakub at gcc dot gnu.org Target Milestone: --- The current implementation of "acc_async_test" does not conform to the specification, and I've now generally asked the OpenACC technical committee about the intended behavior of 'OpenACC "wait" directive/clause/runtime API call with async-argument not used before'. This will need to be fixed on all release branches.
[Bug ipa/88214] ICE in bitmap_intersect_p() on 32-bit BE platforms
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88214 --- Comment #7 from Martin Jambor --- I have posted the patch to the mailing list for review: https://gcc.gnu.org/ml/gcc-patches/2018-12/msg00460.html
[Bug go/88406] [9 regression] Many 64-bit Solaris 10/SPARC execution tests FAIL
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88406 Rainer Orth changed: What|Removed |Added Target Milestone|--- |9.0
[Bug go/88406] New: [9 regression] Many 64-bit Solaris 10/SPARC execution tests FAIL
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88406 Bug ID: 88406 Summary: [9 regression] Many 64-bit Solaris 10/SPARC execution tests FAIL Product: gcc Version: 9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: go Assignee: ian at airs dot com Reporter: ro at gcc dot gnu.org CC: cmang at google dot com Target Milestone: --- Target: sparc*-sun-solaris2.10 Since the Go 1.11 merge, many (all?) 64-bit Solaris 10/SPARC execution tests FAIL with FAIL: cmd/go/internal/cache runtime: memory allocated by OS [18446744071360741376, 18446744071427850240) not in usable address space: base outside usable address space fatal error: memory reservation exceeds address space limit runtime stack: :0 :0 :0 :0 :0 :0 :0 :0 [...] :0 main /vol/gcc/src/hg/trunk/local/libgo/runtime/go-main.c:57 _start :0 Solaris 11/SPARC and Solaris/x86 are fine, though.
[Bug tree-optimization/88405] New: Missed DSE opportunity
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88405
Bug ID: 88405
Summary: Missed DSE opportunity
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: ktkachov at gcc dot gnu.org
Target Milestone: ---
For the following code:
#define MATRIX_SIZE 512
static double a[MATRIX_SIZE][MATRIX_SIZE];
static double b[MATRIX_SIZE][MATRIX_SIZE];
static double c[MATRIX_SIZE][MATRIX_SIZE];
double
foo (void) {
double s;
int i, j, k;
/* Section A */
for (i = 0; i < MATRIX_SIZE; i++) {
for (j = 0; j < MATRIX_SIZE; j++) {
a[i][j] = (double)i * (double)j;
b[i][j] = (double)i / (double)(j+5);
}
}
/* Section B */
for (j = 0; j < MATRIX_SIZE; j++) {
for (i = 0; i < MATRIX_SIZE; i++) {
s = 0;
for (k = 0; k < MATRIX_SIZE; k++) {
s += a[i][k] * b[k][j];
}
c[i][j] = s;
}
}
s = 0.0; // (1)
#if 0
/* Section C */
for (i = 0; i < MATRIX_SIZE; i++) {
for (j = 0; j < MATRIX_SIZE; j++) {
s += c[i][j];
}
}
#endif
return s;
}
GCC does not manage to eliminate the code up to (1) and retains the expensive
Section A.
Clang manages to eliminate much more and produces:
foo:// @foo
// %bb.0: // %entry
orr w8, wzr, #0x200
.LBB0_1:// %vector.ph
// =>This Inner Loop Header: Depth=1
subsx8, x8, #1 // =1
b.ne.LBB0_1
// %bb.2: // %for.cond20.preheader.preheader
fmovd0, xzr
ret
on aarch64. This happens at -O3 as well as -O2 as well as other targets (occurs
also on x86)
[Bug sanitizer/88404] New: [9 Regression] ICE (tree check) with -fsanitize=thread on Fortran2003 code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88404 Bug ID: 88404 Summary: [9 Regression] ICE (tree check) with -fsanitize=thread on Fortran2003 code Product: gcc Version: 9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: sanitizer Assignee: unassigned at gcc dot gnu.org Reporter: janus at gcc dot gnu.org CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org, jakub at gcc dot gnu.org, kcc at gcc dot gnu.org, marxin at gcc dot gnu.org Target Milestone: --- Simple test case (valid Fortran2003 code with unlimited polymorphism): program t type :: tString character(len=:), allocatable :: cs end type call test(getstr()) contains subroutine test(val) class(*), intent(in) :: val end subroutine function getstr() result(str) type(tString) :: str end function end gfortran versions 5 to 8 handle this well with -fsanitize=thread, but recent 9-trunk ICEs: during GIMPLE pass: tsan0 tsan_ice.f90:1:0: 1 | program t | internal compiler error: tree check: expected record_type or union_type or qual_union_type or array_type, have void_type in may_be_nonaddressable_p, at tree-ssa-loop-ivopts.c:2265 0x5c17c3 tree_check_failed(tree_node const*, char const*, int, char const*, ...) /home/janus/github/gcc/trunk/gcc/tree.c:9757 0xdfc6d6 tree_check4(tree_node*, char const*, int, char const*, tree_code, tree_code, tree_code, tree_code) /home/janus/github/gcc/trunk/gcc/tree.h:3218 0xdfc6d6 may_be_nonaddressable_p(tree_node*) /home/janus/github/gcc/trunk/gcc/tree-ssa-loop-ivopts.c:2265 0xcb14ea instrument_expr /home/janus/github/gcc/trunk/gcc/tsan.c:190 0xcb23dd instrument_gimple /home/janus/github/gcc/trunk/gcc/tsan.c:729 0xcb23dd instrument_memory_accesses /home/janus/github/gcc/trunk/gcc/tsan.c:802 0xcb23dd tsan_pass /home/janus/github/gcc/trunk/gcc/tsan.c:854 0xcb23dd execute /home/janus/github/gcc/trunk/gcc/tsan.c:905
[Bug ipa/87615] Possible excessive compile time with -O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87615 --- Comment #12 from Martin Jambor --- I have just posted the patch for review in: https://gcc.gnu.org/ml/gcc-patches/2018-12/msg00456.html With it the compile time of the testcase goes down from approximately 340 seconds to about 160 seconds (With -fno-ipa-cp -fno-inline the compile time is only 30 seconds, however) the relevant bits of-ftime-report -ftime-report-details are below: Time variable usr sys wall GGC phase setup: 0.00 ( 0%) 0.00 ( 0%) 0.01 ( 0%) 1215 kB ( 0%) phase parsing : 1.07 ( 1%) 1.12 ( 38%) 2.20 ( 1%) 37151 kB ( 7%) phase opt and generate : 161.38 ( 99%) 1.85 ( 62%) 163.28 ( 99%) 469241 kB ( 92%) ... ipa function summary : 0.11 ( 0%) 0.00 ( 0%) 0.10 ( 0%) 554 kB ( 0%) `- tree STMT verifier : 0.04 ( 0%) 0.00 ( 0%) 0.04 ( 0%) 0 kB ( 0%) `- loop init : 0.04 ( 0%) 0.00 ( 0%) 0.04 ( 0%) 11 kB ( 0%) `- tree SSA verifier : 0.02 ( 0%) 0.00 ( 0%) 0.02 ( 0%) 0 kB ( 0%) `- dominance computation : 0.02 ( 0%) 0.00 ( 0%) 0.03 ( 0%) 0 kB ( 0%) ... ipa cp : 0.12 ( 0%) 0.02 ( 1%) 0.10 ( 0%) 9656 kB ( 2%) `- tree STMT verifier : 0.05 ( 0%) 0.00 ( 0%) 0.05 ( 0%) 0 kB ( 0%) `- alias stmt walking : 0.00 ( 0%) 0.00 ( 0%) 0.02 ( 0%) 0 kB ( 0%) `- tree SSA verifier : 0.02 ( 0%) 0.00 ( 0%) 0.02 ( 0%) 0 kB ( 0%) `- dominance computation : 0.02 ( 0%) 0.00 ( 0%) 0.03 ( 0%) 0 kB ( 0%) ... ipa icf: 2.98 ( 2%) 0.00 ( 0%) 2.99 ( 2%) 0 kB ( 0%) `- tree STMT verifier : 0.04 ( 0%) 0.00 ( 0%) 0.04 ( 0%) 0 kB ( 0%) `- tree SSA verifier : 0.02 ( 0%) 0.00 ( 0%) 0.02 ( 0%) 0 kB ( 0%) `- dominance computation : 0.01 ( 0%) 0.00 ( 0%) 0.01 ( 0%) 0 kB ( 0%) ... CFG verifier : 2.27 ( 1%) 0.00 ( 0%) 2.37 ( 1%) 0 kB ( 0%) ... df reaching defs : 1.59 ( 1%) 0.01 ( 0%) 1.59 ( 1%) 0 kB ( 0%) df live regs : 1.74 ( 1%) 0.00 ( 0%) 1.73 ( 1%) 0 kB ( 0%) df live regs : 5.32 ( 3%) 0.00 ( 0%) 5.37 ( 3%) 0 kB ( 0%) ... alias stmt walking : 3.19 ( 2%) 0.30 ( 10%) 3.35 ( 2%) 5 kB ( 0%) ... tree VRP : 36.88 ( 23%) 0.15 ( 5%) 37.00 ( 22%) 58212 kB ( 11%) `- tree SSA incremental: 0.10 ( 0%) 0.07 ( 2%) 0.19 ( 0%) 16219 kB ( 3%) `- CFG verifier: 0.02 ( 0%) 0.00 ( 0%) 0.02 ( 0%) 0 kB ( 0%) `- repair loop structures : 0.01 ( 0%) 0.00 ( 0%) 0.02 ( 0%) 0 kB ( 0%) `- dominance computation : 0.02 ( 0%) 0.00 ( 0%) 0.02 ( 0%) 0 kB ( 0%) `- tree operand scan : 0.09 ( 0%) 0.04 ( 1%) 0.14 ( 0%) 9616 kB ( 2%) `- tree SSA verifier : 0.10 ( 0%) 0.00 ( 0%) 0.10 ( 0%) 0 kB ( 0%) `- loop init : 0.03 ( 0%) 0.00 ( 0%) 0.03 ( 0%) 23 kB ( 0%) `- tree STMT verifier : 0.13 ( 0%) 0.00 ( 0%) 0.15 ( 0%) 0 kB ( 0%) tree Early VRP : 6.53 ( 4%) 0.00 ( 0%) 6.52 ( 4%) 1621 kB ( 0%) `- CFG verifier: 0.01 ( 0%) 0.00 ( 0%) 0.01 ( 0%) 0 kB ( 0%) `- repair loop structures : 0.01 ( 0%) 0.00 ( 0%) 0.01 ( 0%) 0 kB ( 0%) `- dominance computation : 0.01 ( 0%) 0.00 ( 0%) 0.01 ( 0%) 0 kB ( 0%) `- tree operand scan : 0.00 ( 0%) 0.00 ( 0%) 0.01 ( 0%) 0 kB ( 0%) `- tree SSA verifier : 0.04 ( 0%) 0.00 ( 0%) 0.04 ( 0%) 0 kB ( 0%) `- loop init : 0.05 ( 0%) 0.00 ( 0%) 0.05 ( 0%) 39 kB ( 0%) `- tree STMT verifier : 0.05 ( 0%) 0.00 ( 0%) 0.05 ( 0%) 0 kB ( 0%) tree FRE : 59.08 ( 36%) 0.69 ( 23%) 59.93 ( 36%) 1822 kB ( 0%) `- CFG verifier: 0.02 ( 0%) 0.00 ( 0%) 0.03 ( 0%) 0 kB ( 0%) `- repair loop structures : 0.01 ( 0%) 0.00 ( 0%) 0.01 ( 0%) 0 kB ( 0%) `- dominance computation : 0.01 ( 0%) 0.00 ( 0%) 0.01 ( 0%) 0 kB ( 0%) `- tree SSA verifier : 0.08 ( 0%) 0.00 ( 0%) 0.08 ( 0%) 0 kB ( 0%) `- loop init : 0.06 ( 0%) 0.00 ( 0%) 0.05 ( 0%) 0 kB ( 0%) `- alias stmt walking
[Bug target/88402] inefficient code generation for mask from CC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88402
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #1 from Jakub Jelinek ---
I don't think you can use it in that case, you get it with:
unsigned long bar (unsigned int a, unsigned int b)
{
return a < b ? -1ul : 0;
}
which does something different:
cmpl%esi, %edi
sbbq%rax, %rax
ret
at -O2 as well as -O.
[Bug bootstrap/87551] [9 regression] libgnat-9.so fails to link on Solaris
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87551 --- Comment #5 from ro at CeBiTec dot Uni-Bielefeld.DE --- > --- Comment #4 from Jakub Jelinek --- > So fixed with r265025 ? That commit should have referenced this PR... Yes to both. I've now added the forgotten PR marker.
[Bug middle-end/88401] -Wshift-overflow only works for const variables
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88401 --- Comment #4 from Jakub Jelinek --- That is not that easy, because what is considered invalid heavily depends on the FE (and standard version), e.g. the above is completely valid in C++20. Furthermore, warning too late in the middle-end could very well mean warning about stuff that is propagated into statements after jump threading etc. and that are dead and not something user actually wrote. As I said, if you want accurate diagnostics, use the runtime one.
[Bug ipa/61159] __builtin_constant_p gives incorrect results with aliases
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61159 --- Comment #7 from ro at CeBiTec dot Uni-Bielefeld.DE --- > --- Comment #6 from Martin Liška --- > Can the bug be marked as resolved? No, the Solaris/x86 problem persists.
[Bug middle-end/88401] -Wshift-overflow only works for const variables
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88401 Ulya changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #3 from Ulya --- The warning needs to be re-implemented in middle-end to be able to use constant propagation.
[Bug middle-end/88401] -Wshift-overflow only works for const variables
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88401 --- Comment #2 from Ulya --- (In reply to Jakub Jelinek from comment #1) > It is a front-end warning, so there is no constant propagation possible. > You can use -fsanitize=shift to detect this stuff at runtime. Ok, understood. Maybe someday it can be moved to middle-end.
[Bug demangler/82890] Demangler segfaults
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82890 Nick Clifton changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||nickc at gcc dot gnu.org Resolution|--- |FIXED --- Comment #1 from Nick Clifton --- Fixed by commit 266886.
[Bug demangler/85122] Stack Overflow(Stack Exhaustion) in demangle related functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85122 Nick Clifton changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||nickc at gcc dot gnu.org Resolution|--- |FIXED --- Comment #4 from Nick Clifton --- Fixed by commit 266886.
[Bug rtl-optimization/88403] New: [Mips,AArch64] The gcse prevents if-conversion
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88403 Bug ID: 88403 Summary: [Mips,AArch64] The gcse prevents if-conversion Product: gcc Version: 7.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: rtl-optimization Assignee: unassigned at gcc dot gnu.org Reporter: dragan.mladjeno...@rt-rk.com Target Milestone: --- Created attachment 45183 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45183=edit mark.c If I compile the marck.c with aarch64-linux-gnu-gcc -O3 or mipsel-linux-gnu-gcc -mips32r6 -mbranch-cost=5 the inner if does not get transformed to use conditional moves. mips32r6 example: li $13,5000# 0x1388 $L4: ... subu$3,$2,$3 bgec$13,$3,$L3 addiu $2,$2,5000 sra $4,$2,31 <-- inserted by gcse $L3: muh $2,$2,$9 sra $2,$2,12 subu$2,$4,$2 ... The if-conversion fails because it refuses to speculate both instructions whose set regs are alive. If I use -fno-gcse or -ftree-loop-if-convert the problem disappears. Is there something that can be done here w/o resolving to ftree-loop-if-convert ? Tried: mipsel-linux-gnu-gcc --version mipsel-linux-gnu-gcc-7 (Debian 7.3.0-28) 7.3.0 xgcc --version xgcc (GCC) 9.0.0 20181203 (experimental)
[Bug other/86656] Issues found with -fsanitize=address
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86656 Bug 86656 depends on bug 85122, which changed state. Bug 85122 Summary: Stack Overflow(Stack Exhaustion) in demangle related functions https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85122 What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED
[Bug target/37637] Build fails with reserved constraints
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=37637 Matthias Klose changed: What|Removed |Added CC||doko at debian dot org --- Comment #2 from Matthias Klose --- Debian doesn't have any s390 hardware anymore. multilib builds on s390x-linux-gnu work, so maybe just close this issue.
[Bug c++/87335] The stack overflow in function cplus_demangle_type in cp-demangle.c:2565 (c++filt -t)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87335 Nick Clifton changed: What|Removed |Added Status|WAITING |RESOLVED CC||nickc at gcc dot gnu.org Resolution|--- |FIXED --- Comment #13 from Nick Clifton --- Fixed by commit 266886.
[Bug c++/87350] NULL-Pointer problem in cplus-dem.c when executing program c++filt
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87350 Nick Clifton changed: What|Removed |Added Status|NEW |RESOLVED CC||nickc at gcc dot gnu.org Resolution|--- |FIXED --- Comment #8 from Nick Clifton --- Fixed by commit 266886
[Bug target/88402] New: inefficient code generation for mask from CC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88402
Bug ID: 88402
Summary: inefficient code generation for mask from CC
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: rguenth at gcc dot gnu.org
Target Milestone: ---
For sth like
unsigned long foo (int a, int b)
{
return a < b ? -1ul : 0;
}
we produce at -O[23]
xorl%eax, %eax
cmpl%esi, %edi
setl%al
negq%rax
ret
(partial register stall?)
and at -O
cmpl%esi, %edi
setl%al
movzbl %al, %eax
negq%rax
while we could use sbbq %rax, %rax if the suggestion at
https://lwn.net/Articles/744257/ is correct.
[Bug demangler/87681] Recursive Stack Overflow within function d_name, d_encoding, and d_local_name in cp-demangle.c, as demonstrated by "nm -C"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87681 Nick Clifton changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||nickc at gcc dot gnu.org Resolution|--- |FIXED --- Comment #2 from Nick Clifton --- Fixed by commit 266886.
[Bug demangler/87675] Stack Overflow in function next_is_type_qual() in cp-demangle.c, as demonstrated by "nm -C"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87675 Nick Clifton changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||nickc at gcc dot gnu.org Resolution|--- |FIXED --- Comment #6 from Nick Clifton --- Fixed by commit 266886.
[Bug c++/87636] Infinite Recursive Stack Frames in cp-demangle.c in libiberty(function cplus_demangle_type, d_bare_function_type, d_function_type)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87636 Nick Clifton changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||nickc at gcc dot gnu.org Resolution|--- |FIXED --- Comment #4 from Nick Clifton --- Fixed by commit 266886.
[Bug demangler/87620] NULL deref in iterate_demangle_function (117536819)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87620 Nick Clifton changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||nickc at gcc dot gnu.org Resolution|--- |FIXED --- Comment #1 from Nick Clifton --- Fixed by commit 266886.
[Bug demangler/86664] Demangler segfaults
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86664 Nick Clifton changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||nickc at gcc dot gnu.org Resolution|--- |FIXED --- Comment #2 from Nick Clifton --- Fixed by commit 266886.
[Bug demangler/85454] Multiple memory corruptions in objdump / C++ name demangler (binuitils-2.30-15ubuntu1)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85454 Nick Clifton changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||nickc at gcc dot gnu.org Resolution|--- |FIXED --- Comment #1 from Nick Clifton --- Fixed with commit 266886.
[Bug other/86656] Issues found with -fsanitize=address
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86656 Bug 86656 depends on bug 85454, which changed state. Bug 85454 Summary: Multiple memory corruptions in objdump / C++ name demangler (binuitils-2.30-15ubuntu1) https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85454 What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED
[Bug middle-end/88401] -Wshift-overflow only works for const variables
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88401 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #1 from Jakub Jelinek --- It is a front-end warning, so there is no constant propagation possible. You can use -fsanitize=shift to detect this stuff at runtime.
[Bug target/54589] struct offset add should be folded into address calculation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54589 --- Comment #12 from Jakub Jelinek --- (In reply to Jakub Jelinek from comment #11) > Unless the combiner grows the possibility to split into 3 functions, I'm I mean 3 instructions when trying to combine 4. > afraid this would need to be solved in machine reorg or something similar.
