[Bug lto/64374] New: [5.0 regression] LTO ICE in extract_insn, at recog.c:2327
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64374
Bug ID: 64374
Summary: [5.0 regression] LTO ICE in extract_insn, at
recog.c:2327
Product: gcc
Version: 5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: lto
Assignee: unassigned at gcc dot gnu.org
Reporter: dimhen at gmail dot com
r218764 PASS
r218817 FAIL, r218991 FAIL
Fedora 21 / x86_64
gcc -fpreprocessed -O3 -flto -c a.i -fPIC -DPIC -o a.o
g++ -fpreprocessed -O3 -flto -c b.ii -fPIC -DPIC -o b.o
g++ -fpreprocessed -O3 -flto -c e.ii -o e.o
g++ -flto -o x a.o b.o e.o
e.ii: In function ‘main’:
e.ii:10:1: error: unrecognizable insn:
}
^
(insn 52 13 16 3 (set (reg/f:DI 5 di [orig:98 D.3984 ] [98])
(plus:DI (reg:DI 0 ax [97])
(symbol_ref:DI (mOID_Params) [flags 0x2] var_decl 0x7fe0f905f900
mOID_Params))) a.i:13 -1
(nil))
e.ii:10:1: internal compiler error: in extract_insn, at recog.c:2327
0xb230b8 _fatal_insn(char const*, rtx_def const*, char const*, int, char
const*)
/home/dimhen/src/gcc_current/gcc/rtl-error.c:110
0xb23148 _fatal_insn_not_found(rtx_def const*, char const*, int, char const*)
/home/dimhen/src/gcc_current/gcc/rtl-error.c:118
0xad96f8 extract_insn(rtx_insn*)
/home/dimhen/src/gcc_current/gcc/recog.c:2327
0xad97a7 extract_insn_cached(rtx_insn*)
/home/dimhen/src/gcc_current/gcc/recog.c:2218
0x86f8c9 cleanup_subreg_operands(rtx_insn*)
/home/dimhen/src/gcc_current/gcc/final.c:3124
0xad51b9 split_insn
/home/dimhen/src/gcc_current/gcc/recog.c:2937
0xadd3ad split_all_insns()
/home/dimhen/src/gcc_current/gcc/recog.c:2991
0xadd4c8 rest_of_handle_split_after_reload
/home/dimhen/src/gcc_current/gcc/recog.c:3938
0xadd4c8 execute
/home/dimhen/src/gcc_current/gcc/recog.c:3967
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See http://gcc.gnu.org/bugs.html for instructions.
lto-wrapper: fatal error: /usr/local/gcc_current/bin/g++ returned 1 exit status
compilation terminated.
/usr/bin/ld: fatal error: lto-wrapper failed
collect2: error: ld returned 1 exit status
$ /usr/local/gcc_current/bin/gcc -v
Using built-in specs.
COLLECT_GCC=/usr/local/gcc_current/bin/gcc
COLLECT_LTO_WRAPPER=/usr/local/gcc_current/libexec/gcc/x86_64-unknown-linux-gnu/5.0.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: /home/dimhen/src/gcc_current/configure
--prefix=/usr/local/gcc_current/ --enable-checking=yes,df,rtl
--enable-languages=c,c++,lto --enable-plugin=yes --enable-static
Thread model: posix
gcc version 5.0.0 20141220 (experimental) [trunk revision 218991] (GCC)
$ cat a.i
typedef struct {const int m} s;
s ms[];
int i;
int *Create ( )
{
for ( ; ms[i].m; i++ )
f1 ( ms[i] );
}
$ cat b.ii
extern C {
typedef unsigned CPCCreate_t(int *, int);
CPCCreate_t CPCCreate;
int *Create();
}
unsigned CPCCreate(int *, int)
{
Create();
}
$ cat e.ii
extern C {
typedef unsigned CPCCreate_t(int, int);
CPCCreate_t CPCCreate;
}
main() {
CPCCreate(0, 0);
for (;;)
;
}
[Bug target/63805] ICE: in extract_insn, at recog.c:2327 with -mcpu=power8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63805 --- Comment #3 from Dmitry G. Dyachenko dimhen at gmail dot com --- (In reply to Dmitry G. Dyachenko from comment #2) I have similar error in LTO/x86_64, but stack is slightly different. Its different issue (now PR64374) Sorry for noise.
[Bug target/62231] [4.8/4.9 regression] Exception handling broken on powerpc-e500v2-linux-gnuspe
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62231 --- Comment #8 from manfred.rudigier at omicron dot at --- (In reply to Jakub Jelinek from comment #7) GCC 4.8.4 has been released. I have tried out GCC 4.8.4 today, but it still has this issue.
[Bug lto/64374] [5.0 regression] LTO ICE in extract_insn, at recog.c:2327
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64374 --- Comment #1 from Andrew Pinski pinskia at gcc dot gnu.org --- Looks like mixing of pic and non pic is causing the issue.
[Bug rtl-optimization/63259] Detecting byteswap sequence
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63259 --- Comment #19 from thopre01 at gcc dot gnu.org --- Yeah, when doing something like (x[0] 8) | x[1]) 8) | x[2]) 8) | x[3] there is already a depth proportional to the size of the value being byte swapped with a coefficient due to casting. But I need to evaluate the impact of increasing the limit in terms of compilation time. If the impact is noticeable, it might be necessary to do the refactoring suggested by Richard Biener in [1] first. [1] https://gcc.gnu.org/ml/gcc-patches/2014-10/msg00616.html From the performance side the pass could be re-structured to populate a lattice, thus work from def to use instead of the other way around. Which means we visit each stmt exactly once, compute its value symbolically and check it against a rotate.
[Bug target/63651] Lot of failures in obj(c|-c++) with yosemite
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63651 --- Comment #14 from Iain Sandoe iains at gcc dot gnu.org --- Created attachment 34310 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=34310action=edit Arrange for the instancetype type to be recognised This makes instancetype a synonym for id. So, in round terms it should work as expected - however: (a) there's nothing to prevent the User from using it in the Wrong Place (i.e. somewhere other than a return type). (b) there's none of the additional analysis that instancetype allows to provide greater type security. So it's part #1 of N that will be needed to implement this part of the modernisation. NOTE that on my tests we still fail to parse the system headers owing to the use of blocks (but that's a different, and bigger, problem).
[Bug rtl-optimization/62151] [5 Regression] wrong code at -O2 and -O3 on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62151 --- Comment #17 from amker at gcc dot gnu.org --- Author: amker Date: Mon Dec 22 10:25:10 2014 New Revision: 219008 URL: https://gcc.gnu.org/viewcvs?rev=219008root=gccview=rev Log: PR rtl-optimization/62151 * combine.c (try_combine): New local variables local_elim_i1 and local_elim_i0. Set elim_i1 and elim_i0 using the local version variables. Distribute notes from i0notes or i1notes using the local variables. gcc/testsuite/ChangeLog PR rtl-optimization/62151 * gcc.c-torture/execute/pr62151.c: New test. Added: trunk/gcc/testsuite/gcc.c-torture/execute/pr62151.c Modified: trunk/gcc/ChangeLog trunk/gcc/combine.c trunk/gcc/testsuite/ChangeLog
[Bug rtl-optimization/62151] [5 Regression] wrong code at -O2 and -O3 on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62151 amker at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #18 from amker at gcc dot gnu.org --- Should be fixed now.
[Bug middle-end/62178] [5.0 regression] [AArch64] Performance regression on matrix matrix multiply due to r211211
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62178 amker at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #8 from amker at gcc dot gnu.org --- Close.
[Bug lto/64374] [5.0 regression] LTO ICE in extract_insn, at recog.c:2327
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64374 --- Comment #2 from Dmitry G. Dyachenko dimhen at gmail dot com --- (In reply to Andrew Pinski from comment #1) Looks like mixing of pic and non pic is causing the issue. May be one more issue : -- without '-O3' during compilation there are no error
[Bug lto/64374] [5.0 regression] LTO ICE in extract_insn, at recog.c:2327
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64374 --- Comment #3 from Dmitry G. Dyachenko dimhen at gmail dot com --- (In reply to Dmitry G. Dyachenko from comment #0) Oh, I edit files after copy/paste error message. The correct one is the following: e.ii: In function ‘main’: e.ii:9:1: error: unrecognizable insn: } ^ (insn 52 13 16 3 (set (reg/f:DI 5 di [orig:98 D.3982 ] [98]) (plus:DI (reg:DI 0 ax [97]) (symbol_ref:DI (ms) [flags 0x2] var_decl 0x7f9b26cb4900 ms))) a.i:8 -1 (nil)) e.ii:9:1: internal compiler error: in extract_insn, at recog.c:2327 0xb230b8 _fatal_insn(char const*, rtx_def const*, char const*, int, char const*) /home/dimhen/src/gcc_current/gcc/rtl-error.c:110 0xb23148 _fatal_insn_not_found(rtx_def const*, char const*, int, char const*) /home/dimhen/src/gcc_current/gcc/rtl-error.c:118 0xad96f8 extract_insn(rtx_insn*) /home/dimhen/src/gcc_current/gcc/recog.c:2327 0xad97a7 extract_insn_cached(rtx_insn*) /home/dimhen/src/gcc_current/gcc/recog.c:2218 0x86f8c9 cleanup_subreg_operands(rtx_insn*) /home/dimhen/src/gcc_current/gcc/final.c:3124 0xad51b9 split_insn /home/dimhen/src/gcc_current/gcc/recog.c:2937 0xadd3ad split_all_insns() /home/dimhen/src/gcc_current/gcc/recog.c:2991 0xadd4c8 rest_of_handle_split_after_reload /home/dimhen/src/gcc_current/gcc/recog.c:3938 0xadd4c8 execute /home/dimhen/src/gcc_current/gcc/recog.c:3967 Please submit a full bug report, with preprocessed source if appropriate. Please include the complete backtrace with any bug report. See http://gcc.gnu.org/bugs.html for instructions. lto-wrapper: fatal error: /usr/local/gcc_current/bin/g++ returned 1 exit status compilation terminated. /usr/bin/ld: fatal error: lto-wrapper failed collect2: error: ld returned 1 exit status
[Bug target/62231] [4.8/4.9 regression] Exception handling broken on powerpc-e500v2-linux-gnuspe
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62231 --- Comment #9 from Arseny Solokha asolokha at gmx dot com --- Sure it has. The fix wasn't committed to the tree, otherwise it would be reported here.
[Bug other/63758] liblto_plugin.so has undefined reference to _environ on OSX
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63758 Iain Sandoe iains at gcc dot gnu.org changed: What|Removed |Added Attachment #33903|0 |1 is obsolete|| Assignee|unassigned at gcc dot gnu.org |iains at gcc dot gnu.org --- Comment #4 from Iain Sandoe iains at gcc dot gnu.org --- Created attachment 34311 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=34311action=edit Updated patch to catch another use. I'm taking this bug, if that's OK I'd like to post the revised patch to @patches ... but Roland can you confirm that's OK with you?
[Bug bootstrap/54696] Makefile doesn't propagate CPPFLAGS to host libraries
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54696 Eric Gallager egall at gwmail dot gwu.edu changed: What|Removed |Added CC||egall at gwmail dot gwu.edu --- Comment #2 from Eric Gallager egall at gwmail dot gwu.edu --- Ran into something similar in a combined tree with gdb, so once this is fixed for gcc, remember to have the gdb folks merge it as well...
[Bug libstdc++/60396] Missing time_get::get() functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60396 --- Comment #2 from Jonathan Wakely redi at gcc dot gnu.org --- Author: redi Date: Mon Dec 22 13:45:44 2014 New Revision: 219012 URL: https://gcc.gnu.org/viewcvs?rev=219012root=gccview=rev Log: 2014-12-22 Rüdiger Sonderfeld ruedi...@c-plusplus.de Jonathan Wakely jwak...@redhat.com PR libstdc++/60396 * config/abi/pre/gnu.ver: Add new exports. * include/bits/locale_facets_nonio.h (time_get::get): New overloads. (time_get::do_get): New virtual function. * include/bits/locale_facets_nonio.tcc (time_get::get): Define. (time_get::do_get): Define. * src/c++11/string-inst.cc (time_get::get, time_get::do_get): Add C++11-only instantiations. * testsuite/22_locale/time_get/get/char/1.cc: New. * testsuite/22_locale/time_get/get/char/2.cc: New. * testsuite/22_locale/time_get/get/wchar_t/1.cc: New. * testsuite/22_locale/time_get/get/wchar_t/2.cc: New. Added: trunk/libstdc++-v3/testsuite/22_locale/time_get/get/ trunk/libstdc++-v3/testsuite/22_locale/time_get/get/char/ trunk/libstdc++-v3/testsuite/22_locale/time_get/get/char/1.cc trunk/libstdc++-v3/testsuite/22_locale/time_get/get/char/2.cc trunk/libstdc++-v3/testsuite/22_locale/time_get/get/wchar_t/ trunk/libstdc++-v3/testsuite/22_locale/time_get/get/wchar_t/1.cc trunk/libstdc++-v3/testsuite/22_locale/time_get/get/wchar_t/2.cc Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/config/abi/pre/gnu.ver trunk/libstdc++-v3/include/bits/locale_facets_nonio.h trunk/libstdc++-v3/include/bits/locale_facets_nonio.tcc trunk/libstdc++-v3/src/c++11/string-inst.cc
[Bug libstdc++/54354] TODO extended iomanip manipulators std::get_time and std::put_time (C++11, section 27.7.5)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54354 --- Comment #8 from Jonathan Wakely redi at gcc dot gnu.org --- Author: redi Date: Mon Dec 22 13:45:52 2014 New Revision: 219013 URL: https://gcc.gnu.org/viewcvs?rev=219013root=gccview=rev Log: 2014-12-22 Rüdiger Sonderfeld ruedi...@c-plusplus.de PR libstdc++/54354 * include/std/iomanip (_Get_time): New struct. (get_time): New manipulator. (operator): New overloaded function. * testsuite/27_io/manipulators/extended/get_time/char/1.cc: New. * testsuite/27_io/manipulators/extended/get_time/char/2.cc: New. * testsuite/27_io/manipulators/extended/get_time/wchar_t/1.cc: New. * testsuite/27_io/manipulators/extended/get_time/wchar_t/2.cc: New. Added: trunk/libstdc++-v3/testsuite/27_io/manipulators/extended/get_time/ trunk/libstdc++-v3/testsuite/27_io/manipulators/extended/get_time/char/ trunk/libstdc++-v3/testsuite/27_io/manipulators/extended/get_time/char/1.cc trunk/libstdc++-v3/testsuite/27_io/manipulators/extended/get_time/char/2.cc trunk/libstdc++-v3/testsuite/27_io/manipulators/extended/get_time/wchar_t/ trunk/libstdc++-v3/testsuite/27_io/manipulators/extended/get_time/wchar_t/1.cc trunk/libstdc++-v3/testsuite/27_io/manipulators/extended/get_time/wchar_t/2.cc Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/include/std/iomanip
[Bug libstdc++/60396] Missing time_get::get() functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60396 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #3 from Jonathan Wakely redi at gcc dot gnu.org --- Fixed for GCC 5
[Bug libstdc++/54354] TODO extended iomanip manipulators std::get_time and std::put_time (C++11, section 27.7.5)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54354 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #9 from Jonathan Wakely redi at gcc dot gnu.org --- Fixed for GCC 5
[Bug libstdc++/24882] [meta-bug] Non-refcounted, moveable basic_string
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=24882 Bug 24882 depends on bug 60278, which changed state. Bug 60278 Summary: string::erase() (and other containers) does not take const_iterators https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60278 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED
[Bug libstdc++/60278] string::erase() (and other containers) does not take const_iterators
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60278 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #2 from Jonathan Wakely redi at gcc dot gnu.org --- Fixed for GCC 5 (when using the new string ABI)
[Bug libstdc++/54392] [4.8/4.9/5 Regression] std::string::assign() fails to update length
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54392 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #25 from Jonathan Wakely redi at gcc dot gnu.org --- Fixed for GCC 5 (when using the new string ABI)
[Bug libstdc++/56437] basic_string assumes that allocators are default-constructible
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56437 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #5 from Jonathan Wakely redi at gcc dot gnu.org --- Fixed for GCC 5 (when using the new string ABI)
[Bug libstdc++/24882] [meta-bug] Non-refcounted, moveable basic_string
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=24882 Bug 24882 depends on bug 56437, which changed state. Bug 56437 Summary: basic_string assumes that allocators are default-constructible https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56437 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED
[Bug libstdc++/24882] [meta-bug] Non-refcounted, moveable basic_string
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=24882 Bug 24882 depends on bug 54392, which changed state. Bug 54392 Summary: [4.8/4.9/5 Regression] std::string::assign() fails to update length https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54392 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED
[Bug libstdc++/53221] [C++11] basic_string lacks copy/move constructors with allocator
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53221 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #5 from Jonathan Wakely redi at gcc dot gnu.org --- Fixed for GCC 5 (when using the new string ABI)
[Bug libstdc++/24882] [meta-bug] Non-refcounted, moveable basic_string
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=24882 Bug 24882 depends on bug 53221, which changed state. Bug 53221 Summary: [C++11] basic_string lacks copy/move constructors with allocator https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53221 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED
[Bug target/63651] Lot of failures in obj(c|-c++) with yosemite
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63651 --- Comment #15 from Dominique d'Humieres dominiq at lps dot ens.fr --- With the patch in comment 14, I get === obj-c++ Summary for unix/-m64 === # of expected passes3073 # of unexpected failures13 # of expected failures19 # of unresolved testcases8 # of unsupported tests74 === obj-c++ Summary === # of expected passes6207 # of unexpected failures24 # of expected failures21 # of unresolved testcases16 # of unsupported tests142 and === objc Summary for unix/-m64 === # of expected passes5939 # of unexpected failures27 # of expected failures6 # of unresolved testcases10 # of unsupported tests91 === objc Summary === # of expected passes12045 # of unexpected failures43 # of expected failures12 # of unresolved testcases20 # of unsupported tests176 The additional failures compared to the use of the 10.9 SDK are FAIL: obj-c++.dg/torture/strings/const-cfstring-1.mm -O* -fnext-runtime (test for excess errors) FAIL: objc.dg/torture/strings/const-cfstring-1.m -O* -fnext-runtime (test for excess errors) FAIL: objc.dg/objc-foreach-4.m -fnext-runtime (test for excess errors) FAIL: objc.dg/objc-foreach-5.m -fnext-runtime (test for excess errors) Apparently they are related to the fact that NS_BLOCKS_AVAILABLE is no longer checked.
[Bug bootstrap/11799] The toplevel should handle multi-libs.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=11799 Eric Gallager egall at gwmail dot gwu.edu changed: What|Removed |Added CC||egall at gwmail dot gwu.edu --- Comment #4 from Eric Gallager egall at gwmail dot gwu.edu --- Yeah, multilibs are a real pain... I tried adding a --disable-multilib flag to the top-level configure script in my combined tree, but I can't seem to get the top-level Makefile to respect it, as it tries building multilibs anyways, and furthermore, it fails to pass the flag to any of the subdirs...
[Bug libstdc++/60271] [C++1y] std::max(initializer_listT) cannot use std::max_element
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60271 --- Comment #6 from Jonathan Wakely redi at gcc dot gnu.org --- http://cplusplus.github.io/LWG/lwg-active.html#2369
[Bug lto/64043] [5 Regression] ICE (segfault) with LTO: in tree_check/tree.h:2758 get_binfo_at_offset/tree.c:11914
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64043 Igor Zamyatin izamyatin at gmail dot com changed: What|Removed |Added CC||izamyatin at gmail dot com --- Comment #13 from Igor Zamyatin izamyatin at gmail dot com --- I also see performance degradation for several spec2006 tests after this commit (mostly on FP tests). Eg. on Haswell 433.milc shows ~-7-8% if compiled with -O3 -flto -funroll-loops -march=core-avx2 Not investigated this so far though
[Bug target/64375] New: m32c ICE building newlib in calls.cL3638
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64375 Bug ID: 64375 Summary: m32c ICE building newlib in calls.cL3638 Product: gcc Version: 5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: joel at gcc dot gnu.org Created attachment 34312 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=34312action=edit Preprocessed fopencookie.c from newlib xgcc (GCC) 5.0.0 20141221 (experimental) This appears to be completely independent of optimization. It fails at O[012s] if -mcpum32cm is included. /users/joel/test-gcc/b-m32c-rtems4.11-gcc/./gcc/xgcc -B/users/joel/test-gcc/b-m32c-rtems4.11-gcc/./gcc/ -c -Os -mcpu=m32cm f.c /users/joel/test-gcc/b-m32c-rtems4.11-gcc/./gcc/xgcc -B/users/joel/test-gcc/b-m32c-rtems4.11-gcc/./gcc/ -nostdinc -B/users/joel/test-gcc/b-m32c-rtems4.11-gcc/m32c-rtems4.11/m32cm/newlib/ -isystem /users/joel/test-gcc/b-m32c-rtems4.11-gcc/m32c-rtems4.11/m32cm/newlib/targ-include -isystem /users/joel/test-gcc/gcc/newlib/libc/include -B/users/joel/test-gcc/install-head/m32c-rtems4.11/bin/ -B/users/joel/test-gcc/install-head/m32c-rtems4.11/lib/ -isystem /users/joel/test-gcc/install-head/m32c-rtems4.11/include -isystem /users/joel/test-gcc/install-head/m32c-rtems4.11/sys-include -mcpu=m32cm -DPACKAGE_NAME=\newlib\ -DPACKAGE_TARNAME=\newlib\ -DPACKAGE_VERSION=\2.2.0\ -DPACKAGE_STRING=\newlib\ 2.2.0\ -DPACKAGE_BUGREPORT=\\ -DPACKAGE_URL=\\ -I. -I../../../../../../gcc/newlib/libc/stdio -Os -DPREFER_SIZE_OVER_SPEED -DSMALL_MEMORY -D_COMPILING_NEWLIB -DMALLOC_PROVIDED -DEXIT_PROVIDED -DSIGNAL_PROVIDED -DREENTRANT_SYSCALLS_PROVIDED -DHAVE_NANOSLEEP -DHAVE_BLKSIZE -DHAVE_FCNTL -DHAVE_ASSERT_FUNC -D_NO_GETLOGIN -D_NO_GETPWENT -D_NO_GETUT -D_NO_GETPASS -D_NO_SIGSET -D_NO_WORDEXP -D_NO_POPEN -D_NO_POSIX_SPAWN -fno-builtin -g -O2 -c -o lib_a-fopencookie.o `test -f 'fopencookie.c' || echo '../../../../../../gcc/newlib/libc/stdio/'`fopencookie.c ../../../../../../gcc/newlib/libc/stdio/fopencookie.c: In function 'fopencookie': ../../../../../../gcc/newlib/libc/stdio/fopencookie.c:260:10: internal compiler error: in expand_call, at calls.c:3638 return _fopencookie_r (_REENT, cookie, mode, functions); ^ 0x558859 expand_call(tree_node*, rtx_def*, int) ../../gcc/gcc/calls.c:3638 0x64ac10 expand_expr_real_1(tree_node*, rtx_def*, machine_mode, expand_modifier, rtx_def**, bool) ../../gcc/gcc/expr.c:10474 0x656c2c store_expr_with_bounds(tree_node*, rtx_def*, int, bool, tree_node*) ../../gcc/gcc/expr.c:5368 0x65e23e expand_assignment(tree_node*, tree_node*, bool) ../../gcc/gcc/expr.c:5137 0x5655a6 expand_call_stmt ../../gcc/gcc/cfgexpand.c:2345 0x5655a6 expand_gimple_stmt_1 ../../gcc/gcc/cfgexpand.c:3293 0x5655a6 expand_gimple_stmt ../../gcc/gcc/cfgexpand.c:3447 0x56b651 expand_gimple_tailcall ../../gcc/gcc/cfgexpand.c:3494 0x56b651 expand_gimple_basic_block ../../gcc/gcc/cfgexpand.c:5257 0x56cdce execute ../../gcc/gcc/cfgexpand.c:5889 Please submit a full bug report, with preprocessed source if appropriate. Please include the complete backtrace with any bug report. See http://gcc.gnu.org/bugs.html for instructions. make: *** [lib_a-fopencookie.o] Error 1
[Bug lto/64043] [5 Regression] ICE (segfault) with LTO: in tree_check/tree.h:2758 get_binfo_at_offset/tree.c:11914
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64043 --- Comment #14 from Jan Hubicka hubicka at ucw dot cz --- Hi, do you use same flags at compile time and link time? I did not see anything unusual at our testers, but perhaps some of the optimization flags are streamed wrong? Honza
[Bug target/64376] New: [SH] Improve bswap support
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64376 Bug ID: 64376 Summary: [SH] Improve bswap support Product: gcc Version: 5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: olegendo at gcc dot gnu.org Target: sh*-*-* There have been some improvements made w.r.t. bswap pattern detection at the tree level. Some of them expect a bswaphi2 expander, which is absent on SH (see PR 63259). It seems that adding the bswaphi2 pattern is not enough and we still need support from combine to get better pattern matching.
[Bug rtl-optimization/63259] Detecting byteswap sequence
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63259 --- Comment #20 from Oleg Endo olegendo at gcc dot gnu.org --- BTW, PR 42587 contains a few other cases. I've created PR 64376 for the SH specific parts.
[Bug target/64377] nios2 compile error in options-save.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64377
--- Comment #1 from Joel Sherrill joel at gcc dot gnu.org ---
Looking at the generated options-save.c, the first line of this method is
clearly incorrect in the cast on the RHS. It looks like a full declaration and
not a type. If anyone familiar with the magic in these files looked at it, I am
sure it is easy to fix.
/* Stream in target options */
void
cl_target_option_stream_in (struct data_in *data_in ATTRIBUTE_UNUSED,
struct bitpack_d *bp ATTRIBUTE_UNUSED,
struct cl_target_option *ptr ATTRIBUTE_UNUSED)
{
ptr-saved_custom_code_status[256] = (enum nios2_ccs_code
saved_custom_code_status[256]) bp_unpack_value (bp, 64);
ptr-saved_custom_code_index[256] = (int saved_custom_code_index[256])
bp_unpack_value (bp, 64);
ptr-saved_fpu_custom_code[n2fpu_code_num] = (int
saved_fpu_custom_code[n2fpu_code_num]) bp_unpack_value (bp, 64);
ptr-x_target_flags = (int) bp_unpack_value (bp, 64);
}
[Bug target/64377] New: nios2 compile error in options-save.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64377 Bug ID: 64377 Summary: nios2 compile error in options-save.c Product: gcc Version: 5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: joel at gcc dot gnu.org g++ -c -g -DIN_GCC -DCROSS_DIRECTORY_STRUCTURE -fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wmissing-format-attribute -Woverloaded-virtual -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -fno-common -DHAVE_CONFIG_H -I. -I. -I../../gcc/gcc -I../../gcc/gcc/. -I../../gcc/gcc/../include -I../../gcc/gcc/../libcpp/include -I../../gcc/gcc/../libdecnumber -I../../gcc/gcc/../libdecnumber/dpd -I../libdecnumber -I../../gcc/gcc/../libbacktrace -o options-save.o -MT options-save.o -MMD -MP -MF ./.deps/options-save.TPo options-save.c options-save.c: In function ‘void cl_target_option_stream_in(data_in*, bitpack_d*, cl_target_option*)’: options-save.c:1910:41: error: expected primary-expression before ‘enum’ ptr-saved_custom_code_status[256] = (enum nios2_ccs_code saved_custom_code_status[256]) bp_unpack_value (bp, 64); ^ options-save.c:1910:41: error: expected ‘)’ before ‘enum’ options-save.c:1911:40: error: expected primary-expression before ‘int’ ptr-saved_custom_code_index[256] = (int saved_custom_code_index[256]) bp_unpack_value (bp, 64); ^ options-save.c:1911:40: error: expected ‘)’ before ‘int’ options-save.c:1912:49: error: expected primary-expression before ‘int’ ptr-saved_fpu_custom_code[n2fpu_code_num] = (int saved_fpu_custom_code[n2fpu_code_num]) bp_unpack_value (bp, 64); ^ options-save.c:1912:49: error: expected ‘)’ before ‘int’ make: *** [options-save.o] Error 1
[Bug lto/64043] [5 Regression] ICE (segfault) with LTO: in tree_check/tree.h:2758 get_binfo_at_offset/tree.c:11914
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64043 --- Comment #15 from Igor Zamyatin izamyatin at gmail dot com --- Just checked: everywhere -Ofast -flto -funroll-loops -static -m64 -march=core-avx2 used (not -O3 as I mentioned before)
[Bug fortran/54756] [OOP] [F08] Should reject CLASS, intent(out) in PURE procedures
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54756 janus at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |janus at gcc dot gnu.org
[Bug fortran/54756] [OOP] [F08] Should reject CLASS, intent(out) in PURE procedures
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54756 --- Comment #7 from janus at gcc dot gnu.org --- Closely related: PR 59103.
[Bug libstdc++/60271] [C++1y] std::max(initializer_listT) cannot use std::max_element
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60271 --- Comment #7 from Jonathan Wakely redi at gcc dot gnu.org --- Author: redi Date: Mon Dec 22 16:00:16 2014 New Revision: 219015 URL: https://gcc.gnu.org/viewcvs?rev=219015root=gccview=rev Log: 2014-12-22 Ville Voutilainen ville.voutilai...@gmail.com PR libstdc++/60271 C++14 constexpr min, max, minmax, min_element, max_element and minmax_element. Also constexpr for 20.9.5-20.9.9, aka various library functors. * include/bits/c++config: Add _GLIBCXX14_CONSTEXPR. * include/bits/algorithmfwd.h (min, max, minmax, min_element, max_element): Use it. * include/bits/predefined_ops.h (_Iter_less_iter, __iter_less_iter, _Iter_comp_iter, __iter_comp_iter): Likewise. * include/bits/stl_algo.h (minmax, __minmax_element, minmax_element, min, max, __min_element, min_element, __max_element, max_element) Likewise. * include/bits/stl_algobase.h (min, max): Likewise. * include/bits/stl_function.h (plus, minus, multiplies, divides, modulus, negate, equal_to, not_equal_to, greater, less, greater_equal, less_equal, logical_and, logical_or, logical_not, bit_and, bit_or, bit_xor, bit_not, unary_negate, not1, binary_negate, not2): Likewise. * testsuite/20_util/function_objects/constexpr.cc: New. * testsuite/25_algorithms/max/constexpr.cc: Likewise. * testsuite/25_algorithms/max_element/constexpr.cc: Likewise. * testsuite/25_algorithms/min/constexpr.cc: Likewise. * testsuite/25_algorithms/min_element/constexpr.cc: Likewise. * testsuite/25_algorithms/minmax/constexpr.cc: Likewise. * testsuite/25_algorithms/minmax_element/constexpr.cc: Likewise. * testsuite/ext/profile/mutex_extensions_neg.cc: Adjust dg-error. Added: trunk/libstdc++-v3/testsuite/20_util/function_objects/constexpr.cc trunk/libstdc++-v3/testsuite/25_algorithms/max/constexpr.cc - copied, changed from r219014, trunk/libstdc++-v3/testsuite/ext/profile/mutex_extensions_neg.cc trunk/libstdc++-v3/testsuite/25_algorithms/max_element/constexpr.cc - copied, changed from r219014, trunk/libstdc++-v3/testsuite/ext/profile/mutex_extensions_neg.cc trunk/libstdc++-v3/testsuite/25_algorithms/min/constexpr.cc - copied, changed from r219014, trunk/libstdc++-v3/testsuite/ext/profile/mutex_extensions_neg.cc trunk/libstdc++-v3/testsuite/25_algorithms/min_element/constexpr.cc - copied, changed from r219014, trunk/libstdc++-v3/testsuite/ext/profile/mutex_extensions_neg.cc trunk/libstdc++-v3/testsuite/25_algorithms/minmax/constexpr.cc - copied, changed from r219014, trunk/libstdc++-v3/testsuite/ext/profile/mutex_extensions_neg.cc trunk/libstdc++-v3/testsuite/25_algorithms/minmax_element/constexpr.cc - copied, changed from r219014, trunk/libstdc++-v3/testsuite/ext/profile/mutex_extensions_neg.cc Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/include/bits/algorithmfwd.h trunk/libstdc++-v3/include/bits/c++config trunk/libstdc++-v3/include/bits/predefined_ops.h trunk/libstdc++-v3/include/bits/stl_algo.h trunk/libstdc++-v3/include/bits/stl_algobase.h trunk/libstdc++-v3/include/bits/stl_function.h trunk/libstdc++-v3/testsuite/ext/profile/mutex_extensions_neg.cc
[Bug other/36994] gcc/makefile contains one very long line (over 2k)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=36994 Eric Gallager egall at gwmail dot gwu.edu changed: What|Removed |Added CC||egall at gwmail dot gwu.edu --- Comment #1 from Eric Gallager egall at gwmail dot gwu.edu --- (In reply to Jay from comment #0) Waiting for Autoconf =2.60 (currently using 2.59) will make this easier, so maybe just wait. gcc currently requires Autoconf 2.64; does this still happen when using that version?
[Bug libstdc++/61580] stoi function unknown on W7/Cygwin/x86_64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61580 --- Comment #1 from Jonathan Wakely redi at gcc dot gnu.org --- This is similar to PR 58393, it's due to using a single _GLIBCXX_USE_C99 macro instead of more fine-grained tests for specific features.
[Bug target/52933] SH Target: Use div0s for integer sign comparisons
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52933 --- Comment #6 from Oleg Endo olegendo at gcc dot gnu.org --- Author: olegendo Date: Mon Dec 22 16:19:11 2014 New Revision: 219017 URL: https://gcc.gnu.org/viewcvs?rev=219017root=gccview=rev Log: gcc/testsuite/ PR target/52933 * gcc.target/sh/sh/pr52933-3.c: New. Added: trunk/gcc/testsuite/gcc.target/sh/pr52933-3.c Modified: trunk/gcc/testsuite/ChangeLog
[Bug preprocessor/48839] #error should terminate compilation - similar to missing #include
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=48839 Eric Gallager egall at gwmail dot gwu.edu changed: What|Removed |Added CC||egall at gwmail dot gwu.edu --- Comment #2 from Eric Gallager egall at gwmail dot gwu.edu --- I have been working around this by using the -Wfatal-errors flag when relevant, but I agree that an actual fix would be better than the workaround...
[Bug libstdc++/37522] [4.4 regression] Incorrect vswprintf prototype breaks __to_xstring
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=37522 --- Comment #18 from Jonathan Wakely redi at gcc dot gnu.org --- Author: redi Date: Mon Dec 22 16:41:39 2014 New Revision: 219019 URL: https://gcc.gnu.org/viewcvs?rev=219019root=gccview=rev Log: PR libstdc++/37522 * include/bits/basic_string.h (stod, stof, stoi, stol, stold, stoll, stoul, stoull, to_string): Only use _GLIBCXX_HAVE_BROKEN_VSWPRINTF to guard definition of to_wstring. * testsuite/21_strings/basic_string/numeric_conversions/char/dr1261.cc: Do not use dg-require-string-conversions. * testsuite/21_strings/basic_string/numeric_conversions/char/stod.cc: Likewise. * testsuite/21_strings/basic_string/numeric_conversions/char/stof.cc: Likewise. * testsuite/21_strings/basic_string/numeric_conversions/char/stoi.cc: Likewise. * testsuite/21_strings/basic_string/numeric_conversions/char/stol.cc: Likewise. * testsuite/21_strings/basic_string/numeric_conversions/char/stold.cc: Likewise. * testsuite/21_strings/basic_string/numeric_conversions/char/stoll.cc: Likewise. * testsuite/21_strings/basic_string/numeric_conversions/char/stoul.cc: Likewise. * testsuite/21_strings/basic_string/numeric_conversions/char/ stoull.cc: Likewise. * testsuite/21_strings/basic_string/numeric_conversions/char/ to_string.cc: Likewise. Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/include/bits/basic_string.h trunk/libstdc++-v3/testsuite/21_strings/basic_string/numeric_conversions/char/dr1261.cc trunk/libstdc++-v3/testsuite/21_strings/basic_string/numeric_conversions/char/stod.cc trunk/libstdc++-v3/testsuite/21_strings/basic_string/numeric_conversions/char/stof.cc trunk/libstdc++-v3/testsuite/21_strings/basic_string/numeric_conversions/char/stoi.cc trunk/libstdc++-v3/testsuite/21_strings/basic_string/numeric_conversions/char/stol.cc trunk/libstdc++-v3/testsuite/21_strings/basic_string/numeric_conversions/char/stold.cc trunk/libstdc++-v3/testsuite/21_strings/basic_string/numeric_conversions/char/stoll.cc trunk/libstdc++-v3/testsuite/21_strings/basic_string/numeric_conversions/char/stoul.cc trunk/libstdc++-v3/testsuite/21_strings/basic_string/numeric_conversions/char/stoull.cc trunk/libstdc++-v3/testsuite/21_strings/basic_string/numeric_conversions/char/to_string.cc
[Bug libstdc++/60271] [DR2369] [C++1y] std::max(initializer_listT) cannot use std::max_element
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60271 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|SUSPENDED Summary|[C++1y] |[DR2369] [C++1y] |std::max(initializer_listT |std::max(initializer_listT |) cannot use |) cannot use |std::max_element|std::max_element --- Comment #8 from Jonathan Wakely redi at gcc dot gnu.org --- Suspending until the DR is resolved.
[Bug preprocessor/48839] #error should terminate compilation - similar to missing #include
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=48839 --- Comment #3 from Jason Merrill jason at gcc dot gnu.org --- Makes sense to me.
[Bug fortran/63363] No diagnostic for passing function as actual argument to KIND
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63363 --- Comment #5 from janus at gcc dot gnu.org --- Author: janus Date: Mon Dec 22 18:15:08 2014 New Revision: 219027 URL: https://gcc.gnu.org/viewcvs?rev=219027root=gccview=rev Log: 2014-12-22 Janus Weil ja...@gcc.gnu.org PR fortran/63363 * check.c (gfc_check_kind): Reject polymorphic and non-data arguments. 2014-12-22 Janus Weil ja...@gcc.gnu.org PR fortran/63363 * gfortran.dg/kind_1.f90: New. Added: trunk/gcc/testsuite/gfortran.dg/kind_1.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/check.c trunk/gcc/testsuite/ChangeLog
[Bug fortran/63363] No diagnostic for passing function as actual argument to KIND
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63363 janus at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #6 from janus at gcc dot gnu.org --- Fixed with r219027. Closing. Thanks for the report!
[Bug fortran/60550] [OOP] ICE on factory design pattern
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60550 janus at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #5 from janus at gcc dot gnu.org --- (In reply to Dominique d'Humieres from comment #3) This PR could have been fixed by r208879 (first patch for pr58880). Yes, most probably. Resolve as FIXED and put the test case into the testsuite? I don't think we need additional test case. The one committed for PR 58880 should be enough. Closing.
[Bug preprocessor/48839] #error should terminate compilation - similar to missing #include
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=48839
Paolo Carlini paolo.carlini at oracle dot com changed:
What|Removed |Added
CC||joseph at codesourcery dot com
--- Comment #4 from Paolo Carlini paolo.carlini at oracle dot com ---
Thanks. I think the patch proper could be something as simple as the below, but
quite a few C testcases would require updating. I'd like to hear Joseph too
before the next steps.
Index: directives.c
===
--- directives.c(revision 219024)
+++ directives.c(working copy)
@@ -1103,7 +1103,7 @@ do_diagnostic (cpp_reader *pfile, int code, int re
static void
do_error (cpp_reader *pfile)
{
- do_diagnostic (pfile, CPP_DL_ERROR, 0, 1);
+ do_diagnostic (pfile, CPP_DL_FATAL, 0, 1);
}
static void
[Bug target/58314] SH4 error: 'asm' operand requires impossible reload
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58314 --- Comment #21 from Oleg Endo olegendo at gcc dot gnu.org --- Author: olegendo Date: Mon Dec 22 18:53:44 2014 New Revision: 219030 URL: https://gcc.gnu.org/viewcvs?rev=219030root=gccview=rev Log: gcc/testsuite/ PR target/58314 * gcc.target/sh/torture/pr58314-2.c: New. * gcc.target/sh/torture/pr58314.c: Don't set -Os option. Added: trunk/gcc/testsuite/gcc.target/sh/torture/pr58314-2.c Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.target/sh/torture/pr58314.c
[Bug fortran/63205] [OOP] Wrongly rejects type = class (for identical declared type)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63205 --- Comment #8 from Dominique d'Humieres dominiq at lps dot ens.fr --- For the record, I have a patch in my working tree such that gfortran.dg/widechar_intrinsics_10.f90 is miscomputed with -m32 (I did not yet investigate the problem: too many patches in my working tree). These failures have now disappeared.
[Bug c/37041] -Wc++-compat refinements
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=37041
--- Comment #6 from Manuel López-Ibáñez manu at gcc dot gnu.org ---
(In reply to Eric Gallager from comment #5)
#ifdef __cplusplus
extern C {
#endif
/* code that is C-only */
This is not what extern C means. The code still needs to be valid C++ and
this is why -Wc++-compat would be useful here. For example, this is not valid
C++ despite being valid C, and -Wc++-compat rightly warns you about it:
#ifdef __cplusplus
extern C {
#endif
/* code that is C-only */
int and(void);
#ifdef __cplusplus
}
#endif /* __cplusplus */
2. Make -Wc++-compat an umbrella warning flag like -Wall or -Wextra.
My guess is that if/when existing GCC developers have time to work on
-Wc++-compat, they will likely focus on fixing the missing warnings and
particularly invalid warnings, rather than figuring out how to refine
-Wc++-compat. But we always welcome new developers
(https://gcc.gnu.org/wiki/GettingStarted#Basics:_Contributing_to_GCC_in_10_easy_steps).
[Bug c++/64372] [DR1560] Gratuitous lvalue-to-rvalue conversion in conditional-expression with throw-expression operand
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64372 Manuel López-Ibáñez manu at gcc dot gnu.org changed: What|Removed |Added Keywords||diagnostic, wrong-code Status|UNCONFIRMED |NEW URL||http://www.open-std.org/jtc ||1/sc22/wg21/docs/cwg_defect ||s.html#1560 Last reconfirmed||2014-12-22 Summary|Spurious warning with throw |[DR1560] Gratuitous |in ternary operator |lvalue-to-rvalue conversion |returning const reference |in conditional-expression ||with throw-expression ||operand Ever confirmed|0 |1 --- Comment #5 from Manuel López-Ibáñez manu at gcc dot gnu.org --- Thanks Harald! I updated the PR accordingly.
[Bug c++/64372] [DR1560] Gratuitous lvalue-to-rvalue conversion in conditional-expression with throw-expression operand
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64372 --- Comment #6 from Manuel López-Ibáñez manu at gcc dot gnu.org --- BTW Harald, GCC needs more C++ FE developers, have you considered joining the project? Even if you don't end up contributing much code, you can get a gcc.gnu.org account for Bugzilla with the possibility of updating/confirming/rejecting bug reports.
[Bug target/64377] nios2 compile error in options-save.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64377
Manuel López-Ibáñez manu at gcc dot gnu.org changed:
What|Removed |Added
Keywords||build
Target||nios2
Status|UNCONFIRMED |NEW
Last reconfirmed||2014-12-22
Ever confirmed|0 |1
--- Comment #2 from Manuel López-Ibáñez manu at gcc dot gnu.org ---
(In reply to Joel Sherrill from comment #1)
Looking at the generated options-save.c, the first line of this method is
clearly incorrect in the cast on the RHS. It looks like a full declaration
and not a type. If anyone familiar with the magic in these files looked at
it, I am sure it is easy to fix.
Those types come from processing TargetSave in .opt files, which are
transformed into variable names and types in optc-save-gen.awk:
for (i = 0; i n_target_save; i++) {
var = target_save_decl[i];
sub ( *=.*, , var);
name = var;
type = var;
sub(^.*[ *], , name)
sub( * name $, , type)
if (target_save_decl[i] ~ ^const char \\*+[_ alnum ]+$)
var_target_str[n_target_str++] = name;
else {
var_target_val_type[n_target_val] = type;
var_target_val[n_target_val++] = name;
}
}
However, the above code does not seem to support array
declarations. Not only the resulting cast does not make any
sense, but something like ptr-saved_custom_code_status[256] does
not seem correct either.
My guess is that the TargetSave declarations in nios2.opt are not
valid (it is the only file that uses arrays for TargetSave), but I'm not sure
what is the correct way to do what those declarations are trying to do. A patch
to optc-save-gen.awk to give a sensible error would also be welcome.
[Bug sanitizer/59410] tsan tests fail with address randomization disabled
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59410 Phil Miller unmobile at gmail dot com changed: What|Removed |Added CC||unmobile at gmail dot com --- Comment #38 from Phil Miller unmobile at gmail dot com --- (In reply to Dmitry Vyukov from comment #34) I propose to close this as obsolete. Or does somebody see any actionable items here? Non-pie binaries are supported by tsan now. Non-aslr (0x5) are not. I have a definite real-world use case for ThreadSanitizer with ASLR disabled, which I would really like to see supported. I'm happy to help in testing or hacking, with pointers in the right direction. Potentially horrifying details: I work on a system for distributed-memory parallel programming called Charm++. One of the features of our system is an ability to migrate user-level threads across processes and hardware nodes. This lets us provide functionality like load balancing, communication optimization, and fault tolerance with low overhead and fine granularity. To do this 'nicely', without our users having to write huge amounts of very finicky serialization code, we implement a technique called 'isomalloc'. In isomalloc, each thread is allocated in a chunk of virtual address space that is unique across the entire distributed set of processes. Any memory allocations by that thread are served from this chunk. When we want to migrate a thread, we can just copy the allocated bits of that chunk, including its stack, from one process to another, and all the pointers within will remain valid. Isomalloc works best when we can assure it as large a range of common, unoccupied virtual address space as possible. Thus, it's much happier when ASLR is disabled. Our runtime system supports a shared-memory multi-threading mode that allows message passing by pointer within each process. Several libraries on top of the RTS also exploit shared memory to reduce memory footprint and/or improve performance. So, we and our users really benefit from being able to use ThreadSanitizer to help debug our code. For instance, you can see our tracking bug for issues in our code code that have been detected using tsan so far: https://charm.cs.illinois.edu/redmine/issues/535 Tie that all together, and we really want to see tsan working with non-ASLR. I've just tested the patch in https://bugzilla.kernel.org/show_bug.cgi?id=66721 against Linux 3.19-rc1, and found that it doesn't (no longer?) solve this issue. I tried compiling my code as non-PIE to hack around this issue. GCC will accept -fsanitize=thread -fPIC -shared instead of -fsanitize=thread -fPIE -pie to compile and link successfully. However, any attempts to run the resulting binary result in a segfault. Per earlier requests, here's /proc/.../maps for that process: 4000-5000 r-xp 08:07 2072846 /home/phil/pie 55754000-55755000 rw-p 08:07 2072846 /home/phil/pie 77ffb000-77ffd000 r-xp 00:00 0 [vdso] 77ffd000-77fff000 r--p 00:00 0 [vvar] 7ffde000-7000 rw-p 00:00 0 [stack] ff60-ff601000 r-xp 00:00 0 [vsyscall] If there's some other way to build as non-PIE that will let tsan work with ASLR disabled, I'm happy to get a workaround, as long as it's something I can document for our users.
[Bug c++/59759] internal compiler error: in unify, using std::enable_if on classes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59759 Kai Tietz ktietz at gcc dot gnu.org changed: What|Removed |Added CC||ktietz at gcc dot gnu.org --- Comment #11 from Kai Tietz ktietz at gcc dot gnu.org --- Hmm, I think this might be not the thing wanted here. But infact having a VAR_DECL can be caused by prior errors introducing them. So we might simple want to treat VAR_DECL in unify via unify_template_argument_mismatch. ChangeLog 2014-12-22 Kai Tietz kti...@redhat.com PR c++/59759 * pt.c (unify): Don't ICE on VAR_DECL. Regression tested on x86_64-w64-mingw32. Ok for apply? Regards, Kai Index: pt.c === --- pt.c(Revision 219014) +++ pt.c(Arbeitskopie) @@ -18490,11 +18490,12 @@ unify (tree tparms, tree targs, tree parm, tree ar case VAR_DECL: /* A non-type template parameter that is a variable should be a -an integral constant, in which case, it whould have been +an integral constant, in which case, it should have been folded into its (constant) value. So we should not be getting -a variable here. */ - gcc_unreachable (); +a variable here out-side of an error-case. */ + return unify_template_argument_mismatch (explain_p, parm, arg); + case TYPE_ARGUMENT_PACK: case NONTYPE_ARGUMENT_PACK: return unify (tparms, targs, ARGUMENT_PACK_ARGS (parm),
[Bug c++/64105] [4.9/5 Regression] ICE: in strip_typedefs, at cp/tree.c:1326
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64105 Jason Merrill jason at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED CC||jason at gcc dot gnu.org Resolution|--- |FIXED Assignee|unassigned at gcc dot gnu.org |jason at gcc dot gnu.org Target Milestone|4.9.3 |5.0 --- Comment #4 from Jason Merrill jason at gcc dot gnu.org --- (In reply to Richard Biener from comment #2) 4.8 rejected this testcase, possibly because a feature is not implemented. So not sure how this can count as a regression (regressions are things that have a known-to-work version) ICE where we previously gave an error has been considered a regression (usually P4) for a while. Fixed.
[Bug bootstrap/37704] RFE: Need specific version of --disable-multilib
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=37704 Eric Gallager egall at gwmail dot gwu.edu changed: What|Removed |Added CC||egall at gwmail dot gwu.edu --- Comment #1 from Eric Gallager egall at gwmail dot gwu.edu --- (In reply to Rainer Orth from comment #0) As seen in PR ada/37681, lack of multilib support in a specific target library can break bootstrap. To avoid this without having to disable multilib support completely, it would be useful to have either a --disable-libada-multilib or (better yet) a generic --disable-multilib[=liba,libb]. Agreed that the latter option would be better, because even directories that do have multilib support can sometimes have it break on them. Treating libada specially in this regard seems to me like it would just be a half-measure.
[Bug other/43171] build: target modules Makefiles have broken rebuild rules (multilib issue)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=43171 Eric Gallager egall at gwmail dot gwu.edu changed: What|Removed |Added CC||egall at gwmail dot gwu.edu --- Comment #1 from Eric Gallager egall at gwmail dot gwu.edu --- (In reply to Ralf Wildenhues from comment #0) Inside the build tree, for each $module and $MULTIDIR, the files $target/$module/Makefile and probably also $target/$MULTIDIR/$module/Makefile have broken rules for the 'Makefile' target: when run, these rules just run './config.status Makefile', whereas the right thing to do would be to also run the './config.status default-1' config commands. For modules that use automake, the rules that automake generates for the 'Makefile' target look like this: .PRECIOUS: Makefile Makefile: $(srcdir)/Makefile.in $(top_builddir)/config.status @case '$?' in \ *config.status*) \ echo ' $(SHELL) ./config.status'; \ $(SHELL) ./config.status;; \ *) \ echo ' cd $(top_builddir) $(SHELL) ./config.status $@ $(am__depfiles_maybe)'; \ cd $(top_builddir) $(SHELL) ./config.status $@ $(am__depfiles_maybe);; \ esac; Checking 'am__depfiles_maybe', it seems that automake sets it empty by default, so maybe 'default-1' needs to be added to 'am__depfiles_maybe' in the Makefile.am of any module that uses automake? (or whatever 'default-1' is called, that is; in my tree, I renamed the corresponding AC_CONFIG_COMMANDS argument in config/multi.m4 to say 'multilib-default-1' instead, as I find that more descriptive, but that would be a separate topic...)
[Bug target/63651] Lot of failures in obj(c|-c++) with yosemite
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63651 --- Comment #16 from mrs at gcc dot gnu.org mrs at gcc dot gnu.org --- We can fixincludes NS_BLOCKS_AVAILABLE support back in, this would disappear interfaces that cannot be supported. In the past, this was a safe thing to do, and might well be still safe wrt the runtime. Deeper language issues would likely need someone to do real work. No really nice fix for that other than someone who wanted to do the work stepping forward. Until then, SDK support for older OSes might be the old way to get code compiled on newer systems. We should be able to steal code from MIT style runtimes to put into newer systems, if we can get FSF approval for incorporating code they don't own. This should be easy enough, we don't vend sell or ship a competing abi compatible runtime, so, bundling one I think should be trivial, if we want to.
[Bug ipa/64378] New: [5 Regression] ICE: in inline_call, at ipa-inline-transform.c:347 with -O3 -fno-ipa-cp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64378 Bug ID: 64378 Summary: [5 Regression] ICE: in inline_call, at ipa-inline-transform.c:347 with -O3 -fno-ipa-cp Product: gcc Version: 5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: ipa Assignee: unassigned at gcc dot gnu.org Reporter: zsojka at seznam dot cz Created attachment 34313 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=34313action=edit reduced testcase (from g++.dg/ipa/pr61540.C) Compiler output: $ gcc -O3 -fno-ipa-cp testcase.C testcase.C:22:1: internal compiler error: in inline_call, at ipa-inline-transform.c:347 } ^ 0x1879ad0 inline_call(cgraph_edge*, bool, veccgraph_edge*, va_heap, vl_ptr*, int*, bool, bool*) /mnt/svn/gcc-trunk/gcc/ipa-inline-transform.c:347 0x1874bde recursive_inlining /mnt/svn/gcc-trunk/gcc/ipa-inline.c:1404 0x1874bde inline_small_functions /mnt/svn/gcc-trunk/gcc/ipa-inline.c:1771 0x1874bde ipa_inline /mnt/svn/gcc-trunk/gcc/ipa-inline.c:2189 0x1874bde execute /mnt/svn/gcc-trunk/gcc/ipa-inline.c:2562 Please submit a full bug report, with preprocessed source if appropriate. Please include the complete backtrace with any bug report. See http://gcc.gnu.org/bugs.html for instructions. Tested revisions: r219003 - ICE 4_9 r218177 - OK
[Bug target/63651] Lot of failures in obj(c|-c++) with yosemite
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63651 --- Comment #17 from Iain Sandoe iains at gcc dot gnu.org --- (In reply to m...@gcc.gnu.org from comment #16) We can fixincludes NS_BLOCKS_AVAILABLE support back in, this would disappear interfaces that cannot be supported. In the past, this was a safe thing to do, and might well be still safe wrt the runtime. Deeper language issues would likely need someone to do real work. No really nice fix for that other than someone who wanted to do the work stepping forward. Until then, SDK support for older OSes might be the old way to get code compiled on newer systems. We should be able to steal code from MIT style runtimes to put into newer systems, if we can get FSF approval for incorporating code they don't own. This should be easy enough, we don't vend sell or ship a competing abi compatible runtime, so, bundling one I think should be trivial, if we want to. two things here: (1) making FSF ObjC useful again on Darwin - the only solution there realistically is to implement blocks [TBH, this applies outside of ObjC too]. Likely there are two candidates for that job - mrs and ids .. ;) .. if there were some way to split the task up.. I believe this is rapidly becoming a show-stopper for FSF GCC on darwin. :( (2) Having a non-fragile ObjC library on Linux (and/or other interested *nix hosts). My understanding is that David Chisnall's libobjc2 might fit the bill for this (BSD license) ..
[Bug ipa/64378] [5 Regression] ICE: in inline_call, at ipa-inline-transform.c:347 with -O3 -fno-ipa-cp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64378 Dominique d'Humieres dominiq at lps dot ens.fr changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2014-12-22 Ever confirmed|0 |1 --- Comment #1 from Dominique d'Humieres dominiq at lps dot ens.fr --- r218722 - ICE Note the ICE disappears if gcc is configure with --enable-checking=release.
[Bug bootstrap/25508] MULTILIB_OSDIRNAMES undocumented
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=25508 Eric Gallager egall at gwmail dot gwu.edu changed: What|Removed |Added CC||egall at gwmail dot gwu.edu --- Comment #2 from Eric Gallager egall at gwmail dot gwu.edu --- In some of the t-linux64 Makefile fragments in config/gcc/, I found the following comment that seems to describe what the value of MULTILIB_OSDIRNAMES represents: # On Debian, Ubuntu and other derivative distributions, the 32bit libraries # are found in /lib32 and /usr/lib32, /lib64 and /usr/lib64 are symlinks to # /lib and /usr/lib, while other distributions install libraries into /lib64 # and /usr/lib64. The LSB does not enforce the use of /lib64 and /usr/lib64, # it doesn't tell anything about the 32bit libraries on those systems. Set # MULTILIB_OSDIRNAMES according to what is found on the target. Is there a more central location to which this comment should be moved? Or should it just be copied-and-pasted to the rest of the 64bit-Linux-specific Makefile fragments as well?
[Bug bootstrap/25537] EXTRA_MULTILIB_PARTS undocumented
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=25537 Eric Gallager egall at gwmail dot gwu.edu changed: What|Removed |Added CC||egall at gwmail dot gwu.edu --- Comment #2 from Eric Gallager egall at gwmail dot gwu.edu --- Looks like EXTRA_MULTILIB_PARTS is no longer used... (gcc/ChangeLog-2011 mentions its removal)
[Bug c/64379] New: VFP register restore in ARM epilogue can break indirect tailcalls
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64379
Bug ID: 64379
Summary: VFP register restore in ARM epilogue can break
indirect tailcalls
Product: gcc
Version: 4.9.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: donn.seeley at windriver dot com
Created attachment 34314
-- https://gcc.gnu.org/bugzilla/attachment.cgi?id=34314action=edit
reduced from content.c in xfsdump
In the example, the compiler uses a VFP/NEON register to hold a 64-bit scalar.
Restoring the saved VFP/NEON register from the stack stomps on IP. But the
indirect tailcall uses all 4 argument registers, so the function pointer is in
IP, which got trashed:
sub ip, fp, #44
fldmfdd ip!, {d8}
sub sp, fp, #36
ldmfd sp, {r4, r5, r6, r7, r8, r9, fp, sp, lr}
bx ip @ indirect register sibling call
The code branches to a stack location and the program segfaults.
[Bug c/64379] VFP register restore in ARM epilogue can break indirect tailcalls
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64379 --- Comment #1 from Donn Seeley donn.seeley at windriver dot com --- Created attachment 34315 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=34315action=edit generated assembly code for content.i
[Bug target/64379] VFP register restore in ARM epilogue can break indirect tailcalls
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64379 --- Comment #2 from Donn Seeley donn.seeley at windriver dot com --- Created attachment 34316 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=34316action=edit compiler parameters for the build
[Bug target/53987] [SH] Unnecessary zero-extensions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53987
--- Comment #6 from Oleg Endo olegendo at gcc dot gnu.org ---
In the following example function
bool stack_is_background_free( unsigned short* _data, const size_t _size){
size_t num_pixels_above_128 = 0;
for(size_t index = 0;index _size;++index){
if(_data[index] 128)
num_pixels_above_128++;
}
return num_pixels_above_128 == _size;
}
unsigned 16 bit values are compared against an 8 bit constant, which results in
the following code:
mov.w @r4+,r1
extu.w r1,r1
cmp/hi r7,r1
mov #0,r1
addcr1,r3
dt r2
bf .L4
In this case, the zero extension can be omitted, since the comparison result
will always be 'true' if any bits = 8 in the 16 bit value are set:
0x8000 (sign extend) - 0x8000 (unsigned) 0x80 = 1
0x8000 (zero extend) - 0x8000 (unsigned) 0x80 = 1
The same would also apply for 8 bit values:
int test (unsigned char* x)
{
return x[0] = 127;
}
compiles to:
mov.b @r4,r1
mov #126,r2
extu.b r1,r1
cmp/hi r2,r1
rts
movtr0
0x80 (sign extend) - 0xFF80 (unsigned) 0x7E = 1
0x80 (zero extend) - 0x0080 (unsigned) 0x7E = 1
[Bug target/63810] gcc sets incorrect macro for OS X deployment targets
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63810 Eric Gallager egall at gwmail dot gwu.edu changed: What|Removed |Added CC||egall at gwmail dot gwu.edu --- Comment #19 from Eric Gallager egall at gwmail dot gwu.edu --- (In reply to Francois-Xavier Coudert from comment #18) (In reply to Lawrence Velázquez from comment #17) Hey Lawrence, do you have a copyright assignment in place with the FSF? If so, please submit your trunk patch to gcc-patc...@gcc.gnu.org for review. If not, ask on the g...@gcc.gnu.org list for the paperwork to be sent to you. He appears to still be waiting on a response to a ping as of http://gcc.gnu.org/ml/gcc/2014-12/msg00047.html
[Bug target/64379] VFP register restore in ARM epilogue can break indirect tailcalls
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64379 --- Comment #3 from Mikael Pettersson mikpelinux at gmail dot com --- Can you add a main() with the necessary parameter setup and call to mark_set() to make the testcase self-contained and executable? You can annotate mark_set() with attribute((noinline,noclone)) to prevent it from being inlined into main() or specialized wrt to the specific parameters there.
[Bug target/55023] hppa: wrong code generated with tail call optimisation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55023 --- Comment #14 from John David Anglin danglin at gcc dot gnu.org --- Author: danglin Date: Mon Dec 22 23:10:18 2014 New Revision: 219037 URL: https://gcc.gnu.org/viewcvs?rev=219037root=gccview=rev Log: PR target/55023 * dse.c (scan_insn): Treat sibling call as though it does a wild read. * testsuite/gcc.dg/pr55023.c: New file. Added: trunk/gcc/testsuite/gcc.dg/pr55023.c Modified: trunk/gcc/ChangeLog trunk/gcc/dse.c trunk/gcc/testsuite/ChangeLog
[Bug c++/64380] New: Missed optimization: smarter dead store elimination in dtors
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64380 Bug ID: 64380 Summary: Missed optimization: smarter dead store elimination in dtors Product: gcc Version: 5.0 Status: UNCONFIRMED Severity: minor Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: petschy at gmail dot com Some of the stores are eliminated in dtors already, if the values are not used later. But if there are function calls after the stores, then they are not eliminated. I see the reason for this, but some functions are special, eg free(), operator delete and others with the same semantics: they won't crawl back and access these variables, so if the vars are not used locally, and no other functions are called, the stores could be eliminated. This would be useful eg for classes where there is a user callable function that releases some/all resources, while keeping the instance alive, and the dtor calls the same function to release all resources. In this latter case, stores that are otherwise needed to have a proper state can be omitted since the instance is being destroyed, anyway. This is a minor issue probably, since the program shouldn't spend most of its time running dtors. However, some function attribute symmetric in spirit to 'malloc' would be nice: eg 'free': this would mean that if called, it won't reach back to the variables of the calling scope, either through its arguments or through global variables, so those stores could be safely eliminated that are otherwise dead. g++-5.0.0 -v Using built-in specs. COLLECT_GCC=g++-5.0.0 COLLECT_LTO_WRAPPER=/usr/local/libexec/gcc/x86_64-unknown-linux-gnu/5.0.0/lto-wrapper Target: x86_64-unknown-linux-gnu Configured with: ../configure --enable-languages=c,c++ --disable-multilib --program-suffix=-5.0.0 Thread model: posix gcc version 5.0.0 20141222 (experimental) (GCC) Compliled with g++-5.0.0 -g -O3 -Wall 20141222-dtor-deadstore.cpp Dump of assembler code for function test_ra(Foo*): 0x004005f0 +0: push %rbp 0x004005f1 +1: push %rbx 0x004005f2 +2: mov%rdi,%rbp 0x004005f5 +5: sub$0x8,%rsp # two stores before the loop 0x004005f9 +9: movl $0x1,0x10(%rdi) 0x00400600 +16:movl $0x2,0x14(%rdi) 0x00400607 +23:mov0x8(%rdi),%rdi 0x0040060b +27:test %rdi,%rdi 0x0040060e +30:je 0x400620 test_ra(Foo*)+48 0x00400610 +32:mov(%rdi),%rbx 0x00400613 +35:callq 0x4004d0 _ZdlPv@plt 0x00400618 +40:test %rbx,%rbx 0x0040061b +43:mov%rbx,%rdi 0x0040061e +46:jne0x400610 test_ra(Foo*)+32 # two stores after the loop, so far so good 0x00400620 +48:movq $0x0,0x8(%rbp) 0x00400628 +56:movl $0x3,0x18(%rbp) 0x0040062f +63:add$0x8,%rsp 0x00400633 +67:pop%rbx 0x00400634 +68:pop%rbp 0x00400635 +69:retq Dump of assembler code for function test_dtor(Foo*): # two stores before the lop in the dtor. these won't ever be read again # could be eliminated 0x00400640 +0: movl $0x1,0x10(%rdi) 0x00400647 +7: movl $0x2,0x14(%rdi) 0x0040064e +14:mov0x8(%rdi),%rdi 0x00400652 +18:test %rdi,%rdi 0x00400655 +21:je 0x400671 test_dtor(Foo*)+49 0x00400657 +23:push %rbx 0x00400658 +24:nopl 0x0(%rax,%rax,1) 0x00400660 +32:mov(%rdi),%rbx 0x00400663 +35:callq 0x4004d0 _ZdlPv@plt 0x00400668 +40:test %rbx,%rbx 0x0040066b +43:mov%rbx,%rdi 0x0040066e +46:jne0x400660 test_dtor(Foo*)+32 # no stores here, the ones after 'delete' were eliminated successfully 0x00400670 +48:pop%rbx 0x00400671 +49:repz retq Dump of assembler code for function test_dtor2(Foo*): 0x00400680 +0: push %rbp 0x00400681 +1: push %rbx 0x00400682 +2: mov%rdi,%rbp 0x00400685 +5: sub$0x8,%rsp # 4 dead stores in the src, the one to the same addr is eliminated 0x00400689 +9: movl $0xc0,(%rdi) 0x0040068f +15:movl $0x1,0x10(%rdi) 0x00400696 +22:movl $0x2,0x14(%rdi) 0x0040069d +29:mov0x8(%rdi),%rdi 0x004006a1 +33:test %rdi,%rdi 0x004006a4 +36:je 0x4006c0 test_dtor2(Foo*)+64 0x004006a6 +38:nopw %cs:0x0(%rax,%rax,1) 0x004006b0 +48:mov(%rdi),%rbx 0x004006b3 +51:callq 0x4004d0 _ZdlPv@plt 0x004006b8 +56:test %rbx,%rbx 0x004006bb +59:mov%rbx,%rdi 0x004006be +62:jne
[Bug target/62231] [4.8/4.9 regression] Exception handling broken on powerpc-e500v2-linux-gnuspe
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62231 --- Comment #11 from Dan Wilder dan.wilder at watchguard dot com --- Created attachment 34318 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=34318action=edit Backport msg02605 patch to gcc-4.8.3 Apply after other attachment
[Bug target/62231] [4.8/4.9 regression] Exception handling broken on powerpc-e500v2-linux-gnuspe
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62231 --- Comment #12 from Dan Wilder dan.wilder at watchguard dot com --- I have a backport of the patches referenced in comment 4, which I applied to the gcc-4.8.3 we are using for e500v2. If anybody would care to look at it, comment whether it has any merit at all, try it etc, I'd be honored.
[Bug target/62231] [4.8/4.9 regression] Exception handling broken on powerpc-e500v2-linux-gnuspe
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62231 --- Comment #10 from Dan Wilder dan.wilder at watchguard dot com --- Created attachment 34317 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=34317action=edit Backport cfispan.diff to gcc-4.8.3 Attempt to backport cfispan.diff from https://gcc.gnu.org/ml/gcc-patches/2014-09/msg02625/cfispan.diff referenced from comment #4 here, to gcc-4.8.3 which we are using for ppc e500v2 So far as I've been able to determine so far, it works for us, passing the repro mentioned elsewhere in this bug and also the similar repro I had developed, and not introducing other unexpected changes. In combination with the msg2504.html backport also attached. gcc-4.8.4 code in the vicinity of this patch is nearly identical with 4.8.3.
[Bug target/64379] VFP register restore in ARM epilogue can break indirect tailcalls
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64379 --- Comment #4 from Donn Seeley donn.seeley at windriver dot com --- Created attachment 34319 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=34319action=edit main.i to go with content.i I copied content.i to main.i and added just enough material to get it to compile and (hopefully) run. I then built two versions of the example: arm-wrs-linux-gnueabi-gcc -march=armv7-a -mfloat-abi=softfp -mfpu=neon -marm -mthumb-interwork -O1 -pipe -mapcs-frame -c content.i arm-wrs-linux-gnueabi-gcc -march=armv7-a -mfloat-abi=softfp -mfpu=neon -marm -mthumb-interwork -O1 -pipe -mapcs-frame -c main.i arm-wrs-linux-gnueabi-gcc -march=armv7-a -mfloat-abi=softfp -mfpu=neon -marm -mthumb-interwork -O1 -pipe -mapcs-frame --sysroot=/home/donn/c/7.x/wrl-projects/qemuarma9-neon-standard-glibc_std/bitbake_build/tmp/sysroots/qemuarma9 content.o main.o -o without-sibcalls arm-wrs-linux-gnueabi-gcc -march=armv7-a -mfloat-abi=softfp -mfpu=neon -marm -mthumb-interwork -O1 -foptimize-sibling-calls -pipe -mapcs-frame -c content.i arm-wrs-linux-gnueabi-gcc -march=armv7-a -mfloat-abi=softfp -mfpu=neon -marm -mthumb-interwork -O1 -foptimize-sibling-calls -pipe -mapcs-frame -c main.i arm-wrs-linux-gnueabi-gcc -march=armv7-a -mfloat-abi=softfp -mfpu=neon -marm -mthumb-interwork -O1 -foptimize-sibling-calls -pipe -mapcs-frame --sysroot=/home/donn/c/7.x/wrl-projects/qemuarma9-neon-standard-glibc_std/bitbake_build/tmp/sysroots/qemuarma9 content.o main.o -o with-sibcalls I booted up QEMU and ran the programs: root@qemu0:~# ./without-sibcalls root@qemu0:~# ./with-sibcalls Segmentation fault root@qemu0:~#
[Bug c++/63522] [4.8/4.9/5 Regression] ICE: unexpected expression 'ElementIndices' of kind template_parm_index
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63522 Jason Merrill jason at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED CC||jason at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |jason at gcc dot gnu.org
[Bug sanitizer/59410] tsan tests fail with address randomization disabled
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59410 --- Comment #39 from Dmitry Vyukov dvyukov at google dot com --- Isomalloc works best when we can assure it as large a range of common, unoccupied virtual address space as possible. Thus, it's much happier when ASLR is disabled. I do not follow you here. How does ASLR give you larger continuous region? ASLR maps libraries in the middle of virtual address space (0x), so if anything it gives smaller continuous region. On top of that tsan itself uses lots of memory and restricts user mappings to 0x7e00-0x7 range. I would like to understand problem better before we do anything.
[Bug sanitizer/59410] tsan tests fail with address randomization disabled
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59410 --- Comment #40 from Dmitry Vyukov dvyukov at google dot com --- Phil, please move the discussion to: https://groups.google.com/forum/#!forum/thread-sanitizer This is not gcc specific, and more people will be able to see it in the tsan group.
