[Bug middle-end/66429] ICE in expand_GOMP_SIMD_LAST_LANE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66429 --- Comment #6 from Jakub Jelinek jakub at gcc dot gnu.org --- Author: jakub Date: Wed Jun 17 18:10:23 2015 New Revision: 224570 URL: https://gcc.gnu.org/viewcvs?rev=224570root=gccview=rev Log: 2015-06-17 Jakub Jelinek ja...@redhat.com PR middle-end/66429 * omp-low.c (expand_omp_taskreg, expand_omp_target): Use child_cfun instead of DECL_STRUCT_FUNCTION (child_fn). Or in has_simduid_loops and has_force_vectorize_loops flags from cfun into child_cfun. (expand_omp_simd): For broken loop, set cfun-has_simduid_loops if simduid is non-NULL. * tree-pass.h (make_pass_simduid_cleanup): New prototype. * passes.def (pass_simduid_cleanup): Add new pass after loop passes. * tree-vectorizer.c (adjust_simduid_builtins): Remove one unnecessary indirection from htab argument's type. (shrink_simd_arrays): New function. (vectorize_loops): Use it. Adjust adjust_simduid_builtins caller. Don't call adjust_simduid_builtins if there are no loops. (pass_data_simduid_cleanup, pass_simduid_cleanup): New variables. (pass_simduid_cleanup::execute): New method. (make_pass_simduid_cleanup): New function. Added: branches/gcc-5-branch/gcc/testsuite/c-c++-common/gomp/pr66429.c Modified: branches/gcc-5-branch/gcc/ChangeLog branches/gcc-5-branch/gcc/omp-low.c branches/gcc-5-branch/gcc/passes.def branches/gcc-5-branch/gcc/testsuite/ChangeLog branches/gcc-5-branch/gcc/tree-pass.h branches/gcc-5-branch/gcc/tree-vectorizer.c
[Bug fortran/66577] ICE in generate_finalization_wrapper, at fortran/class.c:1567
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66577 Dominique d'Humieres dominiq at lps dot ens.fr changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2015-06-17 Summary|ICE with gfortran-5.1.0 in |ICE in |generate_finalization_wrapp |generate_finalization_wrapp |er |er, at fortran/class.c:1567 Ever confirmed|0 |1 --- Comment #1 from Dominique d'Humieres dominiq at lps dot ens.fr --- Confirmed from 4.9.2 up to trunk (6.0).
[Bug c/66552] Missed optimization when shift amount is result of signed modulus
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66552 Martin Sebor msebor at gcc dot gnu.org changed: What|Removed |Added Keywords||missed-optimization Target|x86/generic |x86, powerpc64 --- Comment #1 from Martin Sebor msebor at gcc dot gnu.org --- On powerpc64, with -O2, GCC emits the following f: srawi 9,4,5 addze 9,9 slwi 9,9,5 subf 4,9,4 srw 3,3,4 rldicl 3,3,0,32 blr while Clang emits what looks like optimal code: f: rlwinm 4, 4, 0, 27, 31 srw 3, 3, 4 blr With the return expression rewritten as suggested (i.e., x (n 31)), GCC still emits an extra instruction compare to Clang. I believe this aspect is tracked in bug 66217. rldicl 4,4,0,59 srw 3,3,4 rldicl 3,3,0,32 blr
[Bug c++/66445] [5/6 Regression] ICE with lambda in stmt expression in a template
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66445 Jason Merrill jason at gcc dot gnu.org changed: What|Removed |Added CC||megahallon at gmail dot com --- Comment #3 from Jason Merrill jason at gcc dot gnu.org --- *** Bug 66517 has been marked as a duplicate of this bug. ***
[Bug c++/66517] [5 Regression] [C++11] sorry, unimplemented: unexpected AST of kind type_decl
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66517 Jason Merrill jason at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||jason at gcc dot gnu.org Resolution|--- |DUPLICATE --- Comment #3 from Jason Merrill jason at gcc dot gnu.org --- Yes, duplicate. *** This bug has been marked as a duplicate of bug 66445 ***
[Bug c++/66445] [5/6 Regression] ICE with lambda in stmt expression in a template
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66445 Jason Merrill jason at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED Assignee|unassigned at gcc dot gnu.org |jason at gcc dot gnu.org --- Comment #4 from Jason Merrill jason at gcc dot gnu.org --- Fixed.
[Bug go/66574] Time is provided in millisecond precision instead of nanoseconds as described in go documentation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66574 --- Comment #3 from Ian Lance Taylor ian at airs dot com --- I suppose it doesn't matter much to me one way or another. It's between you and your team leader.
[Bug middle-end/66429] ICE in expand_GOMP_SIMD_LAST_LANE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66429 --- Comment #5 from Jakub Jelinek jakub at gcc dot gnu.org --- Author: jakub Date: Wed Jun 17 17:59:25 2015 New Revision: 224568 URL: https://gcc.gnu.org/viewcvs?rev=224568root=gccview=rev Log: PR middle-end/66429 * omp-low.c (expand_omp_taskreg): Use child_cfun instead of DECL_STRUCT_FUNCTION (child_fn). Or in has_simduid_loops and has_force_vectorize_loops flags from cfun into child_cfun. (expand_omp_simd): For broken loop, set cfun-has_simduid_loops if simduid is non-NULL. * tree-pass.h (make_pass_simduid_cleanup): New prototype. * passes.def (pass_simduid_cleanup): Add new pass after loop passes. * tree-vectorizer.c (adjust_simduid_builtins): Remove one unnecessary indirection from htab argument's type. (shrink_simd_arrays): New function. (vectorize_loops): Use it. Adjust adjust_simduid_builtins caller. Don't call adjust_simduid_builtins if there are no loops. (pass_data_simduid_cleanup, pass_simduid_cleanup): New variables. (pass_simduid_cleanup::execute): New method. (make_pass_simduid_cleanup): New function. * c-c++-common/gomp/pr66429.c: New test. Added: trunk/gcc/testsuite/c-c++-common/gomp/pr66429.c Modified: trunk/gcc/ChangeLog trunk/gcc/omp-low.c trunk/gcc/passes.def trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-pass.h trunk/gcc/tree-vectorizer.c
[Bug fortran/66578] [F2008] Invalid free on allocate(...,source=a(:)) in block
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66578 Thomas Koenig tkoenig at gcc dot gnu.org changed: What|Removed |Added Keywords||wrong-code CC||vehre at gcc dot gnu.org --- Comment #1 from Thomas Koenig tkoenig at gcc dot gnu.org --- Well, here's one of the corner cases :-)
[Bug middle-end/66429] ICE in expand_GOMP_SIMD_LAST_LANE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66429 --- Comment #7 from Jakub Jelinek jakub at gcc dot gnu.org --- Author: jakub Date: Wed Jun 17 18:11:42 2015 New Revision: 224571 URL: https://gcc.gnu.org/viewcvs?rev=224571root=gccview=rev Log: PR middle-end/66429 * omp-low.c (expand_omp_taskreg, expand_omp_target): Use child_cfun instead of DECL_STRUCT_FUNCTION (child_fn). Or in has_simduid_loops and has_force_vectorize_loops flags from cfun into child_cfun. (expand_omp_simd): For broken loop, set cfun-has_simduid_loops if simduid is non-NULL. * tree-pass.h (make_pass_simduid_cleanup): New prototype. * passes.def (pass_simduid_cleanup): Add new pass after loop passes. * tree-vectorizer.c (adjust_simduid_builtins): Remove one unnecessary indirection from htab argument's type. (shrink_simd_arrays): New function. (vectorize_loops): Use it. Adjust adjust_simduid_builtins caller. Don't call adjust_simduid_builtins if there are no loops. (pass_data_simduid_cleanup, pass_simduid_cleanup): New variables. (pass_simduid_cleanup::execute): New method. (make_pass_simduid_cleanup): New function. Modified: trunk/gcc/ChangeLog trunk/gcc/omp-low.c
[Bug fortran/66578] New: [F2008] Invalid free on allocate(...,source=a(:)) in block
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66578 Bug ID: 66578 Summary: [F2008] Invalid free on allocate(...,source=a(:)) in block Product: gcc Version: 6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: tkoenig at gcc dot gnu.org Target Milestone: --- $ cat a4.f90 program main integer :: n n = 42 block real, dimension(0:n) :: a real, dimension(:), allocatable :: c call random_number(a) allocate(c,source=a(:)) end block end program main $ gfortran -g a4.f90 $ ./a.out *** Error in `./a.out': free(): invalid pointer: 0x020c2110 *** === Backtrace: = /lib64/libc.so.6(+0x7364f)[0x7fa5b086664f] /lib64/libc.so.6(+0x78eae)[0x7fa5b086beae] ./a.out[0x400b0d] ./a.out[0x400b6b] /lib64/libc.so.6(__libc_start_main+0xf5)[0x7fa5b0814be5] ./a.out[0x4007c9] === Memory map: 0040-00401000 r-xp 08:04 4731063 /home/ig25/Krempel/Andre/a.out 00601000-00602000 r--p 1000 08:04 4731063 /home/ig25/Krempel/Andre/a.out 00602000-00603000 rw-p 2000 08:04 4731063 /home/ig25/Krempel/Andre/a.out 020bf000-020e rw-p 00:00 0 [heap]
[Bug c++/66383] [5/6 Regression] ICE in gimplify_expr on this passed in inline initialization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66383 Jason Merrill jason at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #7 from Jason Merrill jason at gcc dot gnu.org --- Fixed.
[Bug c++/58616] [meta-bug] nsdmi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58616 Bug 58616 depends on bug 66383, which changed state. Bug 66383 Summary: [5/6 Regression] ICE in gimplify_expr on this passed in inline initialization https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66383 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED
[Bug c++/66571] Template substitution causes some OpenMP rejects-valid
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66571 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #6 from Jakub Jelinek jakub at gcc dot gnu.org --- Fixed for 5.2+.
[Bug middle-end/66429] ICE in expand_GOMP_SIMD_LAST_LANE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66429 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #8 from Jakub Jelinek jakub at gcc dot gnu.org --- Fixed.
[Bug libstdc++/55409] std::list not properly wrapping access to custom allocator through allocator_traits
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55409 --- Comment #15 from David Krauss potswa at mac dot com --- On 2015–06–18, at 5:58 AM, redi at gcc dot gnu.org gcc-bugzi...@gcc.gnu.org wrote: These changes shouldn't affect the ABI. Eh… the simplest case of a fancy pointer is a raw pointer to a class derived from value_type. The allocator can provide an extra overload of deallocate to help do the downcast. Such an allocator doesn’t even need to declare a fancy pointer type, but it can. I don’t know how far that works currently, or if you’re interested in supporting such hacks. In any case, great! Sorry about the false alarms, I was only looking at the online diff viewer :P .=
[Bug target/66579] New: frv target: -gsplit-dwarf confuses assembler
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66579 Bug ID: 66579 Summary: frv target: -gsplit-dwarf confuses assembler Product: gcc Version: 5.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: nicstange at gmail dot com Target Milestone: --- Created attachment 35797 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=35797action=edit Testcase Adding `-gsplit-dwarf' leads to doubly defined symbols even in trivial testcases (see attached). # gcc-5.1.0/frv-linux/bin/frv-linux-gcc -c -gsplit-dwarf -o test.o test.c /tmp/cc2kwvh4.s: Assembler messages: /tmp/cc2kwvh4.s:225: Error: symbol `.LSLT0' is already defined /tmp/cc2kwvh4.s:229: Error: symbol `.LASLTP0' is already defined /tmp/cc2kwvh4.s:254: Error: symbol `.LELTP0' is already defined /tmp/cc2kwvh4.s:255: Error: symbol `.LELT0' is already defined # gcc-5.1.0/frv-linux/bin/frv-linux-gcc -v Using built-in specs. COLLECT_GCC=./gcc-5.1.0/frv-linux/bin/frv-linux-gcc COLLECT_LTO_WRAPPER=/mnt/scratch/nic/cc/gcc-5.1.0/frv-linux/libexec/gcc/frv-linux/5.1.0/lto-wrapper Target: frv-linux Configured with: ../gcc-5.1.0/configure --prefix=/mnt/scratch/nic/cc/gcc-5.1.0/frv-linux --target=frv-linux --target=frv-linux --enable-targets=all --enable-languages=c --without-headers --enable-sjlj-exceptions --with-system-libunwind --disable-nls --disable-threads --disable-shared --disable-libmudflap --disable-libssp --disable-libgomp --disable-decimal-float --enable-checking=release --disable-bootstrap --disable-multilib --host=x86_64-linux-gnu --build=x86_64-linux-gnu --with-newlib : (reconfigured) ../gcc-5.1.0/configure --prefix=/mnt/scratch/nic/cc/gcc-5.1.0/frv-linux --target=frv-linux --target=frv-linux --enable-targets=all --enable-languages=c --without-headers --enable-sjlj-exceptions --with-system-libunwind --disable-nls --disable-threads --disable-shared --disable-libmudflap --disable-libssp --disable-libgomp --disable-decimal-float --enable-checking=release --disable-bootstrap --disable-multilib --host=x86_64-linux-gnu --build=x86_64-linux-gnu --with-newlib --disable-libquadmath : (reconfigured) ../gcc-5.1.0/configure --prefix=/mnt/scratch/nic/cc/gcc-5.1.0/frv-linux --target=frv-linux --target=frv-linux --enable-targets=all --enable-languages=c --without-headers --enable-sjlj-exceptions --with-system-libunwind --disable-nls --disable-threads --disable-shared --disable-libmudflap --disable-libssp --disable-libgomp --disable-decimal-float --enable-checking=release --disable-bootstrap --disable-multilib --host=x86_64-linux-gnu --build=x86_64-linux-gnu --with-newlib --disable-libquadmath --disable-libatomic Thread model: single gcc version 5.1.0 (GCC)
[Bug target/66579] frv target: -gsplit-dwarf confuses assembler
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66579 --- Comment #1 from Nicolai Stange nicstange at gmail dot com --- Created attachment 35798 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=35798action=edit Output of `gcc -S -gsplit-dwarf' on Testcase
[Bug libstdc++/57272] node-based containers don't use allocator's pointer type internally
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57272
Jonathan Wakely redi at gcc dot gnu.org changed:
What|Removed |Added
CC||potswa at mac dot com
--- Comment #4 from Jonathan Wakely redi at gcc dot gnu.org ---
In PR55409#c15 David Krauss pointed out that ...
the simplest case of a fancy pointer is a raw pointer to a class derived from
value_type
I hadn't considered that case, and should ensure it works.
Currently I am working on something like this, which should handle it
correctly:
templatetypename _Traits,
typename _Tp = typename _Traits::value_type,
typename _Ptr = typename _Traits::pointer
struct _List_node_traits;
// For C++03 allocators, and C++11 allocators without non-fancy pointers.
templatetypename _Traits, typename _Tp
struct _List_node_traits_Traits, _Tp, _Tp*
{
typedef _List_iterator_Tp iterator;
typedef _List_const_iterator_Tp const_iterator;
typedef _List_node_Tp _Node;
typedef __detail::_List_node_base _Node_base;
typedef _Node_base* _Node_base_ptr;
typedef const _Node_base* _Node_base_const_ptr;
typedef typename _Traits::template rebind_Node::other _Alloc_type;
typedef __gnu_cxx::__alloc_traits_Alloc_type _Alloc_traits;
...
};
#if __cplusplus = 201103L
// For C++11 allocators with fancy pointers.
templatetypename _Traits, typename _Tp, typename _Ptr
struct _List_node_traits
{
typedef typename _Traits::void_pointervoid_pointer;
typedef _List_ptr_iterator_Ptr iterator;
typedef _List_ptr_const_iterator_Ptrconst_iterator;
typedef _List_ptr_node_Ptr _Node;
typedef _List_ptr_node_basevoid_pointer _Node_base;
typedef typename _Node_base::_SelfPtr _Node_base_ptr;
typedef typename _Node_base::_ConstSelfPtr_Node_base_const_ptr;
typedef typename _Traits::template rebind_Node::other _Alloc_type;
typedef __gnu_cxx::__alloc_traits_Alloc_type _Alloc_traits;
...
};
#endif
[Bug libstdc++/57272] node-based containers don't use allocator's pointer type internally
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57272 --- Comment #3 from Jonathan Wakely redi at gcc dot gnu.org --- c.f. http://cplusplus.github.io/LWG/lwg-active.html#2261
[Bug c++/66572] [6 Regression] Bogus Wlogical-op warning for operands coming from template instantiations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66572 --- Comment #2 from Mikhail Maltsev miyuki at gcc dot gnu.org --- (In reply to Manuel López-Ibáñez from comment #1) Why is it a regression? Because GCC 5.1 and 4.9.2 do not issue such warning.
[Bug c++/66571] Template substitution causes some OpenMP rejects-valid
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66571 --- Comment #4 from Jakub Jelinek jakub at gcc dot gnu.org --- Author: jakub Date: Wed Jun 17 18:01:05 2015 New Revision: 224569 URL: https://gcc.gnu.org/viewcvs?rev=224569root=gccview=rev Log: PR c++/66571 * pt.c (tsubst_omp_clause_decl): New function. (tsubst_omp_clauses): Use it or tsubst_copy instead of tsubst_expr on OMP_CLAUSE_DECL. * g++.dg/gomp/pr66571-1.C: New test. Added: trunk/gcc/testsuite/g++.dg/gomp/pr66571-1.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/pt.c trunk/gcc/testsuite/ChangeLog
[Bug c++/66571] Template substitution causes some OpenMP rejects-valid
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66571 --- Comment #5 from Jakub Jelinek jakub at gcc dot gnu.org --- Author: jakub Date: Wed Jun 17 18:14:49 2015 New Revision: 224572 URL: https://gcc.gnu.org/viewcvs?rev=224572root=gccview=rev Log: PR c++/66571 * pt.c (tsubst_omp_clause_decl): New function. (tsubst_omp_clauses): Use it or tsubst_copy instead of tsubst_expr on OMP_CLAUSE_DECL. * g++.dg/gomp/pr66571-1.C: New test. Added: branches/gcc-5-branch/gcc/testsuite/g++.dg/gomp/pr66571-1.C Modified: branches/gcc-5-branch/gcc/cp/ChangeLog branches/gcc-5-branch/gcc/cp/pt.c branches/gcc-5-branch/gcc/testsuite/ChangeLog
[Bug fortran/66549] [5/6 Regression] ICE on valid in OMP parallel region
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66549
--- Comment #3 from Mikael Morin mikael at gcc dot gnu.org ---
(In reply to Jakub Jelinek from comment #2)
r221586 in particular.
There is no openmp change in that revision. :-/
--- comment_0.f90.003t.original.good2015-06-17 21:29:00.667012376 +0200
+++ comment_0.f90.003t.original.bad 2015-06-17 21:31:28.013012840 +0200
@@ -6,7 +6,7 @@
clwf ()
{
- #pragma omp parallel
+ #pragma omp parallel private(i)
{
{
struct __class_smfa_Sgc_t sg_.0;
@@ -20,7 +20,6 @@
cvn (struct __class_smfa_Sgc_t restrict sg_, struct array1_real(kind=8)
restrict vn)
{
- integer(kind=4) i;
integer(kind=8) ubound.1;
integer(kind=8) stride.2;
integer(kind=8) offset.3;
[Bug c++/66289] [5/6 Regression] error: ambiguous template instantiation with partial specialization defined in terms of alias template
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66289 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 --- Comment #4 from Jason Merrill jason at gcc dot gnu.org --- Fixed for 5.2.
[Bug libstdc++/55409] std::list not properly wrapping access to custom allocator through allocator_traits
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55409 --- Comment #12 from Jonathan Wakely redi at gcc dot gnu.org --- Author: redi Date: Wed Jun 17 20:36:42 2015 New Revision: 224580 URL: https://gcc.gnu.org/viewcvs?rev=224580root=gccview=rev Log: C++11 allocator support for std::list. PR libstdc++/55409 * include/bits/list.tcc (_List_base::_M_clear()): Use allocator traits. (list::list(const list)): Use allocator propagation trait. Use _M_assign_dispatch to copy elements. * include/bits/stl_list.h (_List_node): Use __aligned_membuf in C++11. (_List_node::_M_valptr()): Add accessor for stored value. (_List_iterator, _List_const_iterator, _List_base): Use _M_valptr(). (_List_base, list): Use allocator traits. (_List_base::_M_get_Tp_allocator, _List_base::get_allocator): Remove. (_List_base::_M_move_nodes): New function. (_List_base(_List_base)): Use _M_move_nodes. (_List_base(_List_base, _Node_alloc_type)): New constructor. (list::_M_create_node, list::_M_erase, list::max_size): Use allocator traits. (list(size_type)): Add allocator parameter. (list(const list)): Use allocator propagation trait. (list(const list, const allocator_type)): New constructor. (list(list, const allocator_type)): Likewise. (list::operator=(list), list::swap(list)): Use allocator propagation traits. (list::_M_move_assign): New functions. * include/debug/list: Add allocator-extended constructors. * include/profile/list: Likewise. * python/libstdcxx/v6/printers.py (get_value_from_list_node): New function to get value from _List_node. (StdListPrinter): Use get_value_from_list_node. * testsuite/23_containers/list/allocator/copy.cc: New. * testsuite/23_containers/list/allocator/copy_assign.cc: New. * testsuite/23_containers/list/allocator/minimal.cc: New. * testsuite/23_containers/list/allocator/move.cc: New. * testsuite/23_containers/list/allocator/move_assign.cc: New. * testsuite/23_containers/list/allocator/noexcept.cc: New. * testsuite/23_containers/list/allocator/swap.cc: New. * testsuite/23_containers/list/requirements/dr438/assign_neg.cc: Adjust dg-prune-output line number. * testsuite/23_containers/list/requirements/dr438/constructor_1_neg.cc: Likewise. * testsuite/23_containers/list/requirements/dr438/insert_neg.cc: Likewise. Added: trunk/libstdc++-v3/testsuite/23_containers/list/allocator/ trunk/libstdc++-v3/testsuite/23_containers/list/allocator/copy.cc trunk/libstdc++-v3/testsuite/23_containers/list/allocator/copy_assign.cc trunk/libstdc++-v3/testsuite/23_containers/list/allocator/minimal.cc trunk/libstdc++-v3/testsuite/23_containers/list/allocator/move.cc trunk/libstdc++-v3/testsuite/23_containers/list/allocator/move_assign.cc trunk/libstdc++-v3/testsuite/23_containers/list/allocator/noexcept.cc trunk/libstdc++-v3/testsuite/23_containers/list/allocator/swap.cc Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/include/bits/list.tcc trunk/libstdc++-v3/include/bits/stl_list.h trunk/libstdc++-v3/include/debug/list trunk/libstdc++-v3/include/profile/list trunk/libstdc++-v3/python/libstdcxx/v6/printers.py trunk/libstdc++-v3/testsuite/23_containers/list/requirements/dr438/assign_neg.cc trunk/libstdc++-v3/testsuite/23_containers/list/requirements/dr438/constructor_1_neg.cc trunk/libstdc++-v3/testsuite/23_containers/list/requirements/dr438/insert_neg.cc
[Bug c++/66515] [5/6 Regression] g++ segfaults when creating an std::initializer_list
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66515 --- Comment #4 from Jason Merrill jason at gcc dot gnu.org --- Author: jason Date: Wed Jun 17 20:45:32 2015 New Revision: 224581 URL: https://gcc.gnu.org/viewcvs?rev=224581root=gccview=rev Log: PR c++/66515 * call.c (implicit_conversion): Call reshape_init here, early. (build_aggr_conv): Not here. Added: trunk/gcc/testsuite/g++.dg/cpp0x/initlist96.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/call.c
[Bug libstdc++/55409] std::list not properly wrapping access to custom allocator through allocator_traits
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55409 --- Comment #13 from David Krauss potswa at mac dot com --- Nice! Just a few things: 1. Line 304: rebind isn’t an official member of allocator_traits. Prefer rebind_alloc. 2. _M_put_node is assuming no fancy pointers: its parameter is a _Node_alloc_traits::pointer but its argument is a _Node*. I think the intent with fancy pointers is that they get stored in nodes, but doing so would change the ABI for fancy pointers that implicitly convert to raw. Perhaps that’s acceptable, with these sweeping changes? 3. Line 554: should call _Node_alloc_traits::construct. (This breaks allocators which need a rebind to do construction, but so does the C++11 standard. To be both backward- and forward-compatible would require rebinding, converting, constructing via traits, converting back, and assigning. According to my reading, anyway.) For what it’s worth, the revision already uses _Node_alloc_traits::destroy, although that’s customized less in practice.
[Bug c++/66061] [5/6 Regression] Internal Compiler Error when specializing a variable template when the specialization is variadic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66061 Jason Merrill jason at gcc dot gnu.org changed: What|Removed |Added Status|NEW |WAITING CC||jason at gcc dot gnu.org --- Comment #2 from Jason Merrill jason at gcc dot gnu.org --- I can't reproduce this on the current trunk or 5 branch; it seems to have been fixed.
[Bug libstdc++/55409] std::list not properly wrapping access to custom allocator through allocator_traits
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55409 --- Comment #14 from Jonathan Wakely redi at gcc dot gnu.org --- (In reply to David Krauss from comment #13) 1. Line 304: rebind isn’t an official member of allocator_traits. Prefer rebind_alloc. That isn't allocator_traits, it's __gnu_cxx::__alloc_traits, which is a compatibility layer that works the same in C++03 and C++11. It has rebind, not rebind_alloc, see ext/alloc_traits.h 2. _M_put_node is assuming no fancy pointers: its parameter is a _Node_alloc_traits::pointer but its argument is a _Node*. I think the intent with fancy pointers is that they get stored in nodes, I agree it's desirable, but it's not really clear that it's required, see http://cplusplus.github.io/LWG/lwg-active.html#2261 but doing so would change the ABI for fancy pointers that implicitly convert to raw. Perhaps that’s acceptable, with these sweeping changes? These changes shouldn't affect the ABI. I have patches coming some time for fancy pointers in all containers, for PR57272, which also don't affect the ABI. My plan is to use the existing node types for allocators without fancy pointers, but use a new family of types (_List_ptr_node, _List_ptr_iterator etc.) that use fancy pointers. That will preserve ABI compatibility for non-fancy pointers, but also fully support fancy pointers. But it's a lot of work, due to the backward-compatibility requirements. 3. Line 554: should call _Node_alloc_traits::construct. (This breaks allocators which need a rebind to do construction, but so does the C++11 standard. To be both backward- and forward-compatible would require rebinding, converting, constructing via traits, converting back, and assigning. According to my reading, anyway.) For what it’s worth, the revision already uses _Node_alloc_traits::destroy, although that’s customized less in practice. Line 504 is only compiled in C++98 mode, where allocators are required to provide a construct member.
[Bug target/66358] [5/6 Regression] [SH] ICE: in extract_constrain_insn, at recog.c:2232
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66358 Oleg Endo olegendo at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2015-06-18 Ever confirmed|0 |1 --- Comment #13 from Oleg Endo olegendo at gcc dot gnu.org --- (In reply to Kazumoto Kojima from comment #5) Created attachment 35673 [details] original test case My sh-elf compiler COLLECT_GCC=../xsh-elf-combined/build/gcc/xgcc Target: sh-unknown-elf Configured with: /exp/ldroot/dodes/xsh-elf-combined/combined/configure --target=sh-unknown-elf --disable-libssp --disable-libgomp --disable-libstdcxx-pch --with-gnu-as --with-gnu-ld --enable-languages=c,c++ --disable-shared --with-newlib --disable-nls --prefix=/exp/ldroot/dodes/xsh-elf-combined/install --with-headers=yes --disable-gdbtk --with-mpfr=/opt2/i686-pc-linux-gnu --with-gmp=/opt2/i686-pc-linux-gnu --without-libgloss Thread model: single gcc version 6.0.0 20150531 (experimental) (GCC) can reproduce it with -O2 -fpic -m4 -ml, though the bug looks a bit fragile like as other RA related bugs. I've attached unreduced test case. sh-elf compiler ICEs for this test case even with -O2 only here. Confirmed with gcc version 6.0.0 20150617 (experimental) (GCC)
[Bug target/66358] [5/6 Regression] [SH] ICE: in extract_constrain_insn, at recog.c:2232
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66358
--- Comment #14 from Oleg Endo olegendo at gcc dot gnu.org ---
It seems the problem is adjacent insns that need R0:
(insn 10503 2627 2628 402 (set (reg:SI 2424)
(sign_extend:SI (mem:QI (plus:SI (reg/v/f:SI 243 [ p2 ])
(const_int 2 [0x2])) [0 MEM[(unsigned char *)p2_97 + 2B]+0
S1 A8]))) ../../ORIG/trunk/libiberty/regex.c:7109 232
{*extendqisi2_compact_mem_disp}
(nil))
(note 2628 10503 10505 402 NOTE_INSN_DELETED)
(insn 10505 2628 2629 402 (set (reg:SI 2425)
(sign_extend:SI (mem:QI (plus:SI (reg/f:SI 774 [ D.8751 ])
(const_int 5 [0x5])) [0 MEM[(unsigned char *)_1000 + 5B]+0
S1 A8]))) ../../ORIG/trunk/libiberty/regex.c:7109 232
{*extendqisi2_compact_mem_disp}
(nil))
(note 2629 10505 2631 402 NOTE_INSN_DELETED)
(note 2631 2629 10507 402 NOTE_INSN_DELETED)
(insn 10507 2631 2633 402 (set (reg:SI 147 t)
(eq:SI (and:SI (reg:SI 2424)
(reg:SI 2425))
(const_int 0 [0]))) ../../ORIG/trunk/libiberty/regex.c:7109 1
{tstsi_t}
(expr_list:REG_DEAD (reg:SI 2425)
(expr_list:REG_DEAD (reg:SI 2424)
(nil
In insn 10503 reg 2424 will be allocated to R0 and will remain live until insn
10507. Reload then fails to insert a move insn R0 - other reg after insn
10503 and R0 allocation for insn 10505 becomes impossible. I've observed this
issue already a while ago. I think this condition can be improved using some
sort of linear register allocator for R0-insns.
[Bug testsuite/65767] Test pr65276 failed on arm-none-eabi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65767 --- Comment #13 from amker at gcc dot gnu.org --- (In reply to Uroš Bizjak from comment #12) (In reply to Rainer Orth from comment #9) It's been more than a month without any activity to fix this. There's now also PR testsuite/65944 about the same issue. Let's track testsuite issue in PR 65944. The original case is fixed. Hi Uroš, Thanks very much for helping. And sorry for late response because of long vacation.
[Bug c++/66572] [6 Regression] Bogus Wlogical-op warning for operands coming from template instantiations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66572 --- Comment #3 from Mikhail Maltsev miyuki at gcc dot gnu.org --- Started with r222408. The commit message says: PR c/63357 * c-common.c (warn_logical_operator): Warn if the operands have the same expressions. * doc/invoke.texi: Update description of -Wlogical-op. Apperntly, the warning about same expressions in a logical expression was added to Wlogical-op after GCC 5.1 release (I didn't know that) and it had this problem from the very beginning. In warn_logical_operator we have a check: /* We do not warn for constants because they are typical of macro expansions that test for features. */ if (CONSTANT_CLASS_P (op_left) || CONSTANT_CLASS_P (op_right)) return; But in this case op_left and op_right are: var_decl 0x76118bd0 value type boolean_type 0x76263888 bool readonly public unsigned QI size integer_cst 0x7610bf48 constant 8 unit size integer_cst 0x7610bf60 constant 1 align 8 symtab 0 alias set -1 canonical type 0x76263888 precision 1 min integer_cst 0x7612e1b0 0 max integer_cst 0x7612e1e0 1 I think it's still possible to fix this check to handle C++ boolean constants properly (as if they were literal constants). But for general case we probably must somehow know (e.g. add a new flag to enum tsubst_flags and pass it to warn_logical_operator from build_new_op_1), that current expression depends on template parameter.
[Bug fortran/66577] New: ICE with gfortran-5.1.0 in generate_finalization_wrapper
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66577 Bug ID: 66577 Summary: ICE with gfortran-5.1.0 in generate_finalization_wrapper Product: gcc Version: 5.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: Daniel.Kokron at nasa dot gov Target Milestone: --- gfortran --version GNU Fortran (GCC) 5.1.0 Copyright (C) 2015 Free Software Foundation, Inc. gcc-5.1.0 was build using gmp-6.0.0, mpfr-3.1.2 and mpc-1.0.3 932 cat Minimal.f03 module SingleLinkedListClass implicit none private integer, parameter :: intG_IK = SELECTED_INT_KIND (8) type SingleLinkItem integer (kind=4), public:: intTag logical (kind=4), public:: blnIsPointer class (*), pointer :: udtData = NULL () type (SingleLinkItem), pointer :: udtNext = NULL() contains final :: Destroy end type SingleLinkItem type SingleLinkedList private type (SingleLinkItem), pointer :: udtFirstLink = NULL () integer (intG_IK), public :: intItemCount = 0 contains procedure, public, pass(this) :: GoToStart end type SingleLinkedList contains function GoToStart (this) result (intSuccess) implicit none class (SingleLinkedList), intent (inout) :: this integer (intG_IK) :: intSuccess = -1 end function GoToStart subroutine Destroy (this) implicit none type(SingleLinkItem), intent(inout) :: this integer(kind=4) :: intStat DEALLOCATE (this%udtData, STAT=intStat) this%intTag = 0 end subroutine Destroy end module SingleLinkedListClass 935 gfortran -fPIC -cpp -Wall -Wextra -ffree-form -O2 -m64 -I. -c Minimal.f03 f951: internal compiler error: in generate_finalization_wrapper, at fortran/class.c:1567 0x61ebab generate_finalization_wrapper ../.././gcc/fortran/class.c:1566 0x61ebab gfc_find_derived_vtab(gfc_symbol*) ../.././gcc/fortran/class.c:2401 0x69fcb5 resolve_fl_derived ../.././gcc/fortran/resolve.c:12950 0x69a747 resolve_symbol ../.././gcc/fortran/resolve.c:13230 0x6b2f5b do_traverse_symtree ../.././gcc/fortran/symbol.c:3641 0x69d882 resolve_types ../.././gcc/fortran/resolve.c:14977 0x6994b0 gfc_resolve(gfc_namespace*) ../.././gcc/fortran/resolve.c:15081 0x684df6 gfc_parse_file() ../.././gcc/fortran/parse.c:5477 0x6c43f5 gfc_be_parse_file ../.././gcc/fortran/f95-lang.c:228
[Bug fortran/66578] [F2008] Invalid free on allocate(...,source=a(:)) in block
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66578 Dominique d'Humieres dominiq at lps dot ens.fr changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2015-06-17 Ever confirmed|0 |1 --- Comment #2 from Dominique d'Humieres dominiq at lps dot ens.fr --- I don't see the invalid free on x86_64-apple-darwin14, but if I compile the code with -fsanitize=address, I get at run time ==49974==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x60f0effc at pc 0x00010b20fa1d bp 0x7fff549f11f0 sp 0x7fff549f11e8 READ of size 4 at 0x60f0effc thread T0 #0 0x10b20fa1c (/Users/dominiq/Documents/Fortran/g95bench/win/f90/bug/a.out+0x11a1c) #1 0x10b20fb67 (/Users/dominiq/Documents/Fortran/g95bench/win/f90/bug/a.out+0x11b67) #2 0x7fff8ecb55c8 (/usr/lib/system/libdyld.dylib+0x35c8) #3 0x0 (unknown module) 0x60f0effc is located 0 bytes to the right of 172-byte region [0x60f0ef50,0x60f0effc) allocated by thread T0 here: #0 0x10b24755a (/opt/gcc/gcc6w/lib/libasan.2.dylib+0x3255a) #1 0x10b20f761 (/Users/dominiq/Documents/Fortran/g95bench/win/f90/bug/a.out+0x11761) #2 0x10b20fb67 (/Users/dominiq/Documents/Fortran/g95bench/win/f90/bug/a.out+0x11b67) #3 0x7fff8ecb55c8 (/usr/lib/system/libdyld.dylib+0x35c8) #4 0x0 (unknown module) SUMMARY: AddressSanitizer: heap-buffer-overflow ??:0 ?? Shadow bytes around the buggy address: 0x1c1e1da0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x1c1e1db0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x1c1e1dc0: fa fa fa fa fa fa fa fa fa fa fa fa 00 00 00 00 0x1c1e1dd0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x1c1e1de0: 00 04 fa fa fa fa fa fa fa fa 00 00 00 00 00 00 =0x1c1e1df0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00[04] 0x1c1e1e00: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x1c1e1e10: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x1c1e1e20: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x1c1e1e30: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x1c1e1e40: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa Shadow byte legend (one shadow byte represents 8 application bytes): Addressable: 00 Partially addressable: 01 02 03 04 05 06 07 Heap left redzone: fa Heap right redzone: fb Freed heap region: fd Stack left redzone: f1 Stack mid redzone: f2 Stack right redzone: f3 Stack partial redzone: f4 Stack after return: f5 Stack use after scope: f8 Global redzone: f9 Global init order: f6 Poisoned by user:f7 Container overflow: fc Array cookie:ac Intra object redzone:bb ASan internal: fe ==49974==ABORTING
[Bug fortran/66549] [5/6 Regression] ICE on valid in OMP parallel region
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66549 --- Comment #4 from Mikael Morin mikael at gcc dot gnu.org --- Created attachment 35796 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=35796action=edit Draft patch
[Bug middle-end/66568] New: [CHKP] internal compiler error: in expand_expr_addr_expr_1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66568
Bug ID: 66568
Summary: [CHKP] internal compiler error: in
expand_expr_addr_expr_1
Product: gcc
Version: 6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: ienkovich at gcc dot gnu.org
Target Milestone: ---
cat test.i
int a, b, c;
void *set_test () {
if (b)
a ? exit (0) : exit (1);
b = c;
}
gcc -fcheck-pointer-bounds -mmpx -O2 test.i
test.i: In function 'set_test':
test.i:8:9: warning: implicit declaration of function 'exit'
[-Wimplicit-function-declaration]
a ? exit (0) : exit (1);
^
test.i:8:9: warning: incompatible implicit declaration of built-in function
'exit'
test.i:8:9: note: include 'stdlib.h' or provide a declaration of 'exit'
test.i: In function 'set_test.chkp':
test.i:6:7: internal compiler error: in expand_expr_addr_expr_1, at expr.c:7671
void *set_test () {
^
0x98c710 expand_expr_addr_expr_1
/gnumnt/msticlxl7_users/ienkovic/issues/mpx/gcc/gcc/expr.c:7671
0x98cdaa expand_expr_addr_expr
/gnumnt/msticlxl7_users/ienkovic/issues/mpx/gcc/gcc/expr.c:7760
0x9985f0 expand_expr_real_1(tree_node*, rtx_def*, machine_mode,
expand_modifier, rtx_def**, bool)
/gnumnt/msticlxl7_users/ienkovic/issues/mpx/gcc/gcc/expr.c:10638
0x98d1e1 expand_expr_real(tree_node*, rtx_def*, machine_mode, expand_modifier,
rtx_def**, bool)
/gnumnt/msticlxl7_users/ienkovic/issues/mpx/gcc/gcc/expr.c:7928
0x83c460 expand_normal
/gnumnt/msticlxl7_users/ienkovic/issues/mpx/gcc/gcc/expr.h:261
0x84853e expand_return
/gnumnt/msticlxl7_users/ienkovic/issues/mpx/gcc/gcc/cfgexpand.c:3148
0x848cd1 expand_gimple_stmt_1
/gnumnt/msticlxl7_users/ienkovic/issues/mpx/gcc/gcc/cfgexpand.c:3290
0x84922d expand_gimple_stmt
/gnumnt/msticlxl7_users/ienkovic/issues/mpx/gcc/gcc/cfgexpand.c:3414
0x8502ed expand_gimple_basic_block
/gnumnt/msticlxl7_users/ienkovic/issues/mpx/gcc/gcc/cfgexpand.c:5426
0x851f5f execute
/gnumnt/msticlxl7_users/ienkovic/issues/mpx/gcc/gcc/cfgexpand.c:6045
Fails on GCC 6 and GCC 5.1
[Bug ipa/66566] New: [CHKP] ICE in early_inliner: internal compiler error: in operator[], at vec.h:714
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66566
Bug ID: 66566
Summary: [CHKP] ICE in early_inliner: internal compiler error:
in operator[], at vec.h:714
Product: gcc
Version: 6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: ipa
Assignee: unassigned at gcc dot gnu.org
Reporter: ienkovich at gcc dot gnu.org
Target Milestone: ---
cat test.i
union jsval_layout
{
void *asPtr;
};
union jsval_layout a;
union jsval_layout b;
union jsval_layout __inline__ fn1() { return b; }
void fn2() { a = fn1(); }
gcc -fcheck-pointer-bounds -mmpx -O2 test.i
test.i: In function 'fn2.chkp':
test.i:9:1: internal compiler error: in operator[], at vec.h:714
void fn2() { a = fn1(); }
^
0xb74862 vecinline_edge_summary, va_heap, vl_embed::operator[](unsigned int)
/gnumnt/msticlxl7_users/ienkovic/issues/mpx/gcc/gcc/vec.h:714
0xb73074 vecinline_edge_summary, va_heap, vl_ptr::operator[](unsigned int)
/gnumnt/msticlxl7_users/ienkovic/issues/mpx/gcc/gcc/vec.h:1180
0xb65743 inline_edge_summary
/gnumnt/msticlxl7_users/ienkovic/issues/mpx/gcc/gcc/ipa-inline.h:281
0xb6ea9f estimate_calls_size_and_time
/gnumnt/msticlxl7_users/ienkovic/issues/mpx/gcc/gcc/ipa-inline-analysis.c:3125
0xb70594 inline_update_overall_summary(cgraph_node*)
/gnumnt/msticlxl7_users/ienkovic/issues/mpx/gcc/gcc/ipa-inline-analysis.c:3689
0x158ffc8 early_inliner(function*)
/gnumnt/msticlxl7_users/ienkovic/issues/mpx/gcc/gcc/ipa-inline.c:2713
0x15901ff execute
/gnumnt/msticlxl7_users/ienkovic/issues/mpx/gcc/gcc/ipa-inline.c:2801
Fails on GCC 6 and GCC 5.1
[Bug target/66569] New: [CHKP]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66569
Bug ID: 66569
Summary: [CHKP]
Product: gcc
Version: 6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: ienkovich at gcc dot gnu.org
Target Milestone: ---
cat test.i
struct s1 {
int *p;
int i;
};
struct s2 {
struct s1 s;
int i;
};
int test (struct s2 s, ...) { }
gcc -fcheck-pointer-bounds -mmpx test.i
test.i: In function 'test.chkp':
test.i:14:18: error: unable to find a register to spill
int test (struct s2 s, ...) { }
^
test.i:14:18: error: this is the insn:
(insn 20 19 42 4 (parallel [
(set (reg:BND64 92 [orig:88 __chkp_bounds_of_s ] [88])
(unspec:BND64 [
(mem:DI (unspec:DI [
(plus:DI (reg/f:DI 16 argp)
(const_int 16 [0x10]))
(reg:DI 89)
] UNSPEC_BNDLDX_ADDR) [0 S8 A8])
] UNSPEC_BNDLDX))
(use (mem:BLK (plus:DI (reg/f:DI 16 argp)
(const_int 16 [0x10])) [0 A8]))
]) test.i:14 1062 {*bnd64_ldx}
(expr_list:REG_DEAD (reg:DI 89)
(nil)))
test.i:14:18: internal compiler error: in assign_by_spills, at
lra-assigns.c:1418
0xd3badb _fatal_insn(char const*, rtx_def const*, char const*, int, char
const*)
/gnumnt/msticlxl7_users/ienkovic/issues/mpx/gcc/gcc/rtl-error.c:110
0xc0462b assign_by_spills
/gnumnt/msticlxl7_users/ienkovic/issues/mpx/gcc/gcc/lra-assigns.c:1418
0xc04f82 lra_assign()
/gnumnt/msticlxl7_users/ienkovic/issues/mpx/gcc/gcc/lra-assigns.c:1593
0xbfdf80 lra(_IO_FILE*)
/gnumnt/msticlxl7_users/ienkovic/issues/mpx/gcc/gcc/lra.c:2331
0xba9512 do_reload
/gnumnt/msticlxl7_users/ienkovic/issues/mpx/gcc/gcc/ira.c:5401
0xba98c0 execute
/gnumnt/msticlxl7_users/ienkovic/issues/mpx/gcc/gcc/ira.c:5572
Fails on GCC 6 and GCC 5.1
[Bug middle-end/66567] New: [CHKP] internal compiler error: in assign_parms
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66567
Bug ID: 66567
Summary: [CHKP] internal compiler error: in assign_parms
Product: gcc
Version: 6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: ienkovich at gcc dot gnu.org
Target Milestone: ---
cat test.i
void (*b) ();
void fn1 (const int *p1)
{
static void *a = conv_1234_123C;
conv_1234_123C:
;
}
void fn2 ()
{
b = fn1;
}
gcc -fcheck-pointer-bounds -mmpx test.i
test.i: In function 'fn1':
test.i:6:6: internal compiler error: in assign_parms, at function.c:3640
void fn1 (const int *p1)
^
0x9fbaf5 assign_parms
/gnumnt/msticlxl7_users/ienkovic/issues/mpx/gcc/gcc/function.c:3640
0xa00118 expand_function_start(tree_node*)
/gnumnt/msticlxl7_users/ienkovic/issues/mpx/gcc/gcc/function.c:5081
0x8517c0 execute
/gnumnt/msticlxl7_users/ienkovic/issues/mpx/gcc/gcc/cfgexpand.c:5939
Fails for GCC 6 and GCC 5.1
[Bug tree-optimization/61171] vectorization fails for a reduction in presence of subtraction
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61171
alalaw01 at gcc dot gnu.org changed:
What|Removed |Added
CC||alalaw01 at gcc dot gnu.org
--- Comment #2 from alalaw01 at gcc dot gnu.org ---
This vectorizes fine, if vv is made a local variable:
float isOk() {
float vv = 0;
for (int j=0U; jN; ++j) {
float ax = xx-px[j];
vv+=ax;
}
return vv;
}
[Bug target/66554] [4.9 Regression] ICE (in expand_fix, at optabs.c:5365) on aarch64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66554 --- Comment #4 from Maxim Kuvyrkov mkuvyrkov at gcc dot gnu.org --- Hi Kugan, Are you working on fixing this issue on 4.9? If so, would you please assign yourself to this bug. Thanks.
[Bug target/66554] [4.9 Regression] ICE (in expand_fix, at optabs.c:5365) on aarch64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66554 kugan at gcc dot gnu.org changed: What|Removed |Added CC||kugan at gcc dot gnu.org --- Comment #1 from kugan at gcc dot gnu.org --- Also happens for arm-none-linux-gnueabi-g++ with -mfpu=neon -O3
[Bug target/65527] ICE: in expand_builtin_with_bounds, at builtins.c:7120 with -fcheck-pointer-bounds -mmpx
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65527 --- Comment #3 from Ilya Enkovich ienkovich at gcc dot gnu.org --- Author: ienkovich Date: Wed Jun 17 07:42:39 2015 New Revision: 224547 URL: https://gcc.gnu.org/viewcvs?rev=224547root=gccview=rev Log: gcc/ Backport from mainline r223929. 2015-06-01 Ilya Enkovich ilya.enkov...@intel.com PR target/65527 * cgraph.c (cgraph_edge::redirect_call_stmt_to_callee): Add redirection for instrumented calls. * lto-wrapper.c (merge_and_complain): Merge -fcheck-pointer-bounds. (append_compiler_options): Append -fcheck-pointer-bounds. * tree-chkp.h (chkp_copy_call_skip_bounds): New. (chkp_redirect_edge): New. * tree-chkp.c (chkp_copy_call_skip_bounds): New. (chkp_redirect_edge): New. gcc/testsuite/ Backport from mainline r223929. 2015-06-01 Ilya Enkovich ilya.enkov...@intel.com PR target/65527 * gcc.target/i386/mpx/chkp-fix-calls-1.c: New. * gcc.target/i386/mpx/chkp-fix-calls-2.c: New. * gcc.target/i386/mpx/chkp-fix-calls-3.c: New. * gcc.target/i386/mpx/chkp-fix-calls-4.c: New. Added: branches/gcc-5-branch/gcc/testsuite/gcc.target/i386/mpx/chkp-fix-calls-1.c branches/gcc-5-branch/gcc/testsuite/gcc.target/i386/mpx/chkp-fix-calls-2.c branches/gcc-5-branch/gcc/testsuite/gcc.target/i386/mpx/chkp-fix-calls-3.c branches/gcc-5-branch/gcc/testsuite/gcc.target/i386/mpx/chkp-fix-calls-4.c Modified: branches/gcc-5-branch/gcc/ChangeLog branches/gcc-5-branch/gcc/cgraph.c branches/gcc-5-branch/gcc/lto-wrapper.c branches/gcc-5-branch/gcc/testsuite/ChangeLog branches/gcc-5-branch/gcc/tree-chkp.c branches/gcc-5-branch/gcc/tree-chkp.h
[Bug fortran/45440] [F03] ALLOCATE with SOURCE gives an ICE (segfault)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=45440 vehre at gcc dot gnu.org changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |FIXED --- Comment #13 from vehre at gcc dot gnu.org --- Fixed with r224477.
[Bug fortran/44672] [F08] ALLOCATE with SOURCE and no array-spec
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=44672 vehre at gcc dot gnu.org changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |FIXED --- Comment #10 from vehre at gcc dot gnu.org --- Fixed with r224477.
[Bug fortran/57307] ICE with sourced allocation with array constructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57307 vehre at gcc dot gnu.org changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |FIXED --- Comment #4 from vehre at gcc dot gnu.org --- Fixed with r224477.
[Bug target/66554] [4.9 Regression] ICE (in expand_fix, at optabs.c:5365) on aarch64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66554 --- Comment #2 from kugan at gcc dot gnu.org --- can_fix_p is returining CODE_FOR_nothing for converting from tomode=V4SImode to frommode=V4SFmode with branch 4.9. With trunk it is returning CODE_FOR_fix_truncv4sfv4si2.
[Bug target/66554] [4.9 Regression] ICE (in expand_fix, at optabs.c:5365) on aarch64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66554
--- Comment #3 from kugan at gcc dot gnu.org ---
correction:
with 4.9 when it ICE we have:
Breakpoint 1, expand_fix (to=to@entry=0x765b5480, from=0x765b2000,
unsignedp=unsignedp@entry=0) at
/home/kugan/work/sources/gcc-fsf/4.9/gcc/optabs.c:5206
5206{
(gdb) p debug_rtx (from)
(reg:V4SI 155 [ vect_vec_iv_.19 ])
$23 = void
(gdb) p debug_rtx (to)
(reg:V4SI 281)
$24 = void
with trunk when it is working:
Breakpoint 1, expand_fix (to=to@entry=0x764a7ac8, from=0x764a7a98,
unsignedp=unsignedp@entry=0) at
/home/kugan/work/sources/gcc-fsf/gcc/gcc/optabs.c:5196
5196{
(gdb) p debug_rtx (to)
(reg:V4SI 281)
$12 = void
(gdb) p debug_rtx (from)
(reg:V4SF 280 [ vect__11.23 ])
$13 = void
[Bug middle-end/66251] [6 Regression] ICE in vect_get_vec_def_for_operand, at tree-vect-stmts.c:1484
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66251 --- Comment #19 from Richard Biener rguenth at gcc dot gnu.org --- Author: rguenth Date: Wed Jun 17 07:37:40 2015 New Revision: 224545 URL: https://gcc.gnu.org/viewcvs?rev=224545root=gccview=rev Log: 2015-06-17 Richard Biener rguent...@suse.de PR tree-optimization/66251 * tree-vect-stmts.c (vectorizable_store): Fix gathering of vectorized stmts for SLP strided stores. * gfortran.fortran-torture/compile/pr66251-2.f90: New testcase. Revert 2015-05-22 Richard Biener rguent...@suse.de PR tree-optimization/66251 * tree-vect-stmts.c (vectorizable_conversion): Properly set STMT_VINFO_VEC_STMT even for the SLP case. 2015-05-26 Michael Matz m...@suse.de PR middle-end/66251 * tree-vect-stmts.c (vect_create_vectorized_demotion_stmts): Always set STMT_VINFO_VEC_STMT, also with SLP. Added: trunk/gcc/testsuite/gfortran.fortran-torture/compile/pr66251-2.f90 Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-vect-stmts.c
[Bug target/66554] [4.9 Regression] ICE (in expand_fix, at optabs.c:5365) on aarch64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66554 Ramana Radhakrishnan ramana at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2015-06-17 CC||ramana at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #5 from Ramana Radhakrishnan ramana at gcc dot gnu.org --- Confirmed.
[Bug c++/66564] New: ICE on explicit instantiation of nested template class
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66564
Bug ID: 66564
Summary: ICE on explicit instantiation of nested template class
Product: gcc
Version: 5.1.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: nurupo.ga.ga.ga at gmail dot com
Target Milestone: ---
The following code generates an ice:
//Begin Sample Code
templateclass T1, class T2
class Outer{
templateclass S1, class S2 class Inner;
};
template templateclass T1, class T2 class OuterT1, T2::InnerT1,T2{};
template class Outerint,int::Innerint,int;
//End Sample Code
error message:
test.cpp:6:62: internal compiler error: in retrieve_specialization, at
cp/pt.c:1059
template templateclass T1, class T2 class OuterT1, T2::InnerT1,T2{};
^
libbacktrace could not find executable to open
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html for instructions.
command line:
gcc -v -save-temps test.cpp
output:
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=d:/program\ files\
(x86)/dev-cpp/mingw64/bin/../libexec/gcc/x86_64-w64-mingw32/5.1.1/lto-wrapper.exe
Target: x86_64-w64-mingw32
Configured with: /home/cauchy/vcs/svn/gcc/branches/gcc-5-branch/configure
--prefix=/home/cauchy/native/gcc-5-win64
--with-sysroot=/home/cauchy/native/gcc-5-win64 --build=x86_64-unknown-linux-gnu
--host=x86_64-w64-mingw32 --target=x86_64-w64-mingw32 --disable-gcov-tool
--disable-multilib --disable-nls --disable-win32-registry
--enable-checking=release --enable-languages=c,c++,fortran
--enable-fully-dynamic-string --with-arch=core2 --with-tune=generic
Thread model: win32
gcc version 5.1.1 (GCC)
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-mtune=generic' '-march=core2'
d:/program files
(x86)/dev-cpp/mingw64/bin/../libexec/gcc/x86_64-w64-mingw32/5.1.1/cc1plus.exe
-E -quiet -v -iprefix d:\program files
(x86)\dev-cpp\mingw64\bin\../lib/gcc/x86_64-w64-mingw32/5.1.1/ -U_REENTRANT
test.cpp -mtune=generic -march=core2 -fpch-preprocess -o test.ii
ignoring duplicate directory d:/program files
(x86)/dev-cpp/mingw64/lib/gcc/../../lib/gcc/x86_64-w64-mingw32/5.1.1/../../../../include/c++/5.1.1
ignoring duplicate directory d:/program files
(x86)/dev-cpp/mingw64/lib/gcc/../../lib/gcc/x86_64-w64-mingw32/5.1.1/../../../../include/c++/5.1.1/x86_64-w64-mingw32
ignoring duplicate directory d:/program files
(x86)/dev-cpp/mingw64/lib/gcc/../../lib/gcc/x86_64-w64-mingw32/5.1.1/../../../../include/c++/5.1.1/backward
ignoring duplicate directory d:/program files
(x86)/dev-cpp/mingw64/lib/gcc/../../lib/gcc/x86_64-w64-mingw32/5.1.1/include
ignoring nonexistent directory
/home/cauchy/native/gcc-5-win64/home/cauchy/native/gcc-5-win64/lib/gcc/x86_64-w64-mingw32/5.1.1/../../../../include
ignoring duplicate directory d:/program files
(x86)/dev-cpp/mingw64/lib/gcc/../../lib/gcc/x86_64-w64-mingw32/5.1.1/include-fixed
ignoring duplicate directory d:/program files
(x86)/dev-cpp/mingw64/lib/gcc/../../lib/gcc/x86_64-w64-mingw32/5.1.1/../../../../x86_64-w64-mingw32/include
ignoring nonexistent directory /home/cauchy/native/gcc-5-win64/mingw/include
#include ... search starts here:
#include ... search starts here:
d:\program files
(x86)\dev-cpp\mingw64\bin\../lib/gcc/x86_64-w64-mingw32/5.1.1/../../../../include/c++/5.1.1
d:\program files
(x86)\dev-cpp\mingw64\bin\../lib/gcc/x86_64-w64-mingw32/5.1.1/../../../../include/c++/5.1.1/x86_64-w64-mingw32
d:\program files
(x86)\dev-cpp\mingw64\bin\../lib/gcc/x86_64-w64-mingw32/5.1.1/../../../../include/c++/5.1.1/backward
d:\program files
(x86)\dev-cpp\mingw64\bin\../lib/gcc/x86_64-w64-mingw32/5.1.1/include
d:\program files
(x86)\dev-cpp\mingw64\bin\../lib/gcc/x86_64-w64-mingw32/5.1.1/include-fixed
d:\program files
(x86)\dev-cpp\mingw64\bin\../lib/gcc/x86_64-w64-mingw32/5.1.1/../../../../x86_64-w64-mingw32/include
End of search list.
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-mtune=generic' '-march=core2'
d:/program files
(x86)/dev-cpp/mingw64/bin/../libexec/gcc/x86_64-w64-mingw32/5.1.1/cc1plus.exe
-fpreprocessed test.ii -quiet -dumpbase test.cpp -mtune=generic -march=core2
-auxbase test -version -o test.s
GNU C++ (GCC) version 5.1.1 (x86_64-w64-mingw32)
compiled by GNU C version 5.1.1, GMP version 5.1.3, MPFR version
3.1.2-p11, MPC version 1.0.3
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
GNU C++ (GCC) version 5.1.1 (x86_64-w64-mingw32)
compiled by GNU C version 5.1.1, GMP version 5.1.3, MPFR version
3.1.2-p11, MPC version 1.0.3
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: b5faee4d84f4cec59dcc3ea208cd79d6
test.cpp:6:62: internal compiler error: in retrieve_specialization, at
cp/pt.c:1059
template templateclass T1, class T2 class OuterT1, T2::InnerT1,T2{};
[Bug target/66563] New: [4.9 Regression] ICE (segmentation fault) on sh4-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66563 Bug ID: 66563 Summary: [4.9 Regression] ICE (segmentation fault) on sh4-linux-gnu Product: gcc Version: 4.9.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: doko at gcc dot gnu.org Target Milestone: --- Created attachment 35792 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=35792action=edit preprocessed source seen while building the GCC 5 branch using GCC 4.9 SVN 20150531 (r223898): sh4-linux-gnu-gcc -c -DHAVE_CONFIG_H -g -O1 -I. -I../../src/libiberty/../include -W -Wall -Wwrite-strings -Wc++-compat -Wstrict-prototypes -pedantic -fpic ../../src/libiberty/floatformat.c -o pic/floatformat.o ../../src/libiberty/floatformat.c: In function 'floatformat_to_double': ../../src/libiberty/floatformat.c:529:2: internal compiler error: Segmentation fault dto = ldexp (1.0, exponent); ^ Please submit a full bug report, with preprocessed source if appropriate. Not checked with GCC 5.
[Bug testsuite/65944] [5/6 Regression] FAIL: g++.dg/lto/pr65276: undefined reference to std2::exception::~exception()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65944 --- Comment #4 from uros at gcc dot gnu.org --- Author: uros Date: Wed Jun 17 10:12:17 2015 New Revision: 224551 URL: https://gcc.gnu.org/viewcvs?rev=224551root=gccview=rev Log: PR testsuite/65944 * g++.dg/lto/pr65276_0.C: Add std2::exception::~exception() function. Modified: branches/gcc-5-branch/gcc/testsuite/ChangeLog branches/gcc-5-branch/gcc/testsuite/g++.dg/lto/pr65276_0.C
[Bug libfortran/66557] gfortran gives segfault error when trying to replace file
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66557 Dominique d'Humieres dominiq at lps dot ens.fr changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2015-06-17 Ever confirmed|0 |1 --- Comment #2 from Dominique d'Humieres dominiq at lps dot ens.fr --- Looks like a MingW problem. Please, contact MingW. Works for me too on x86_64-apple-darwin14.
[Bug fortran/66549] [5/6 Regression] ICE on valid in OMP parallel region
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66549 Dominique d'Humieres dominiq at lps dot ens.fr changed: What|Removed |Added Summary|[Regression] ICE on valid |[5/6 Regression] ICE on |in OMP parallel region |valid in OMP parallel ||region --- Comment #1 from Dominique d'Humieres dominiq at lps dot ens.fr --- The regression appeared between revisions r221569 (2015-03-22, OK) and r221610 (2015-03-23, ICE). Note that the ICE on x86_64-apple-darwin14 is internal compiler error: in make_decl_rtl, at varasm.c:1313
[Bug middle-end/66565] New: Problems and limitation GCC cost metrics and ways to improve the situation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66565 Bug ID: 66565 Summary: Problems and limitation GCC cost metrics and ways to improve the situation Product: gcc Version: 6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end Assignee: unassigned at gcc dot gnu.org Reporter: ktkachov at gcc dot gnu.org CC: dje at gcc dot gnu.org Target Milestone: --- In preparation for the GNU Cauldron 2015 costs BoF here are some talking points gathered from various GCC developers. Feel free to your own gripes, proposals, concerns. * We have many different types of costs: rtx costs, branch costs, address costs, vector costs etc. that measure different things in different units. This causes a problem when they are compared against each other. Example: IVOPTs calculate complex profitability metrics and use both rtx and address costs, mixing and adding them together. Any changes in either can cause unexpected variations in the codegen. * Costs are frequently compared to magic constants that have been picked for a particular testcase on a particular target Example: loop-invariant.c: create_new_invariant compares an address cost to 3 because it helped bwaves on x86. * Implementing rtx costs in the backend usually involves writing a dumbed-down recog to pattern match on the rtxes. This is duplication of logic. * The midend frequently builds bogus rtxes that are never going to match anything and then ask the backend to assign a cost. This unnecessarily complicates backend rtx costs implementations and is hard to reason about when the midend just wants a measure of 'complexity'. * rtx costs need to be able express whether they are being used for calculating the result delay or for understanding how long it is before another (related – for some definition of related) instruction can be issued. Furthermore, result delay may depend on the context of how that result is used (eg due to pipeline forwarding). * I'm not sure whether it is necessary to distinguish between early availability of a result vs late use of a result. Branch costs really need to understand more about how predictable a branch is, not how strongly taken or not taken that branch is. With modern branch predictors a branch can be neither strongly taken nor strongly not taken yet be entirely predictable (eg if it alternates precisely between the two states). It's true that traditional static profiling tools do not do a good job of identifying the pattern of taken/not-taken that a single branch follows, let alone whether the branch is taken often enough with temporal locality to be likely predictable at all. * Cost is too vacuous a term with too overloaded a meaning and too low a resolution for the queries we actually want to make. The midend always wants a cost so that it can compare two strategies and pick the more optimal. The proliferation and misunderstanding of cost units is a side effect of this. So we really have to move to something like: target_should_inline_call (interesting call information from the pass) target_should_ifconvert (gimple sequences for before/after transformation) target_combine_is_profitable_p (before, after rtx) target_should_reconstruct_value_p (candidate RTX to either build and keep in registers or reconstruct in loop) target_choose_preferred_addressing_mode (list of candidate addressing modes for a MEM) Where we ask specific and meaningful questions of the target, rather than asking for a guess at costs and using that. The difficult argument to make will be that we have to be radical about this and prepared to regress many targets (in the short term) for the sake of ending up with a maintainable and understandable design for making these decisions. Otherwise we'll sink years of engineering time in to trying to figure out the meaning of the number 3, and we'll design something very poor which tries to emulate the old behaviour. * Can we use the (C++) type system to: (a) prevent costs from being compared to things that aren't costs, like magic numbers; (b) prevent comparisons between costs of different units; (c) enable multiple axes i.e. throughput, latency, codesize. * The documentation and guidance for what costs mean is poor. And it probably cannot be improved while costs have these ambiguous inconsistent uses.
[Bug fortran/63494] ICE with deferred-character-length component
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63494 Dominique d'Humieres dominiq at lps dot ens.fr changed: What|Removed |Added CC||Daniel.Kokron at nasa dot gov --- Comment #6 from Dominique d'Humieres dominiq at lps dot ens.fr --- *** Bug 66562 has been marked as a duplicate of this bug. ***
[Bug target/66563] [4.9 Regression] ICE (segmentation fault) on sh4-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66563 --- Comment #1 from John Paul Adrian Glaubitz glaubitz at physik dot fu-berlin.de --- Hi Matthias! Thanks for the bug report but I think this might actually a problem with the host compiler or its libraries. I have seen segfaults in multiple packages now [1-3] and so I am very sure this is not an issue with gcc but with the gcc-4.9_4.9.2-20+sh4 package that I built. The problem occurred after I built gcc-4.9_4.9.2-20+sh4 manually to re-add libstdc++6 back which was missing yet and I am suspecting that I messed something up while doing that. I have even seen segfaults during packages postinst scripts, for example, so I suspect an issue with the libstdc++6 library being broken. The buildd tirpitz is currently [4] building gcc-4.9_4.9.2-21 which will be your vanilla gcc-4.9 package and I hope that this will fix the issue. Cheers, Adrian [1] http://buildd.debian-ports.org/status/fetch.php?pkg=gnutls28arch=sh4ver=3.3.15-7stamp=1434506763 [2] http://buildd.debian-ports.org/status/fetch.php?pkg=wmfirearch=sh4ver=1.2.4-1stamp=1434405734 [3] http://buildd.debian-ports.org/status/fetch.php?pkg=cdebconfarch=sh4ver=0.194stamp=1434394400 [4] http://buildd.debian-ports.org/status/package.php?p=gcc-4.9suite=sid
[Bug target/66563] [4.9 Regression] ICE (segmentation fault) on sh4-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66563 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |4.9.3
[Bug testsuite/65944] [5/6 Regression] FAIL: g++.dg/lto/pr65276: undefined reference to std2::exception::~exception()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65944 --- Comment #3 from uros at gcc dot gnu.org --- Author: uros Date: Wed Jun 17 10:03:49 2015 New Revision: 224550 URL: https://gcc.gnu.org/viewcvs?rev=224550root=gccview=rev Log: PR testsuite/65944 * g++.dg/lto/pr65276_0.C: Add std2::exception::~exception() function. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/g++.dg/lto/pr65276_0.C
[Bug testsuite/65944] [5/6 Regression] FAIL: g++.dg/lto/pr65276: undefined reference to std2::exception::~exception()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65944 Uroš Bizjak ubizjak at gmail dot com changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #5 from Uroš Bizjak ubizjak at gmail dot com --- Fixed.
[Bug fortran/66562] ICE with gfortran-5.1.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66562 Dominique d'Humieres dominiq at lps dot ens.fr changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #2 from Dominique d'Humieres dominiq at lps dot ens.fr --- I think it is a duplicate of pr63494. *** This bug has been marked as a duplicate of bug 63494 ***
[Bug fortran/66549] [5/6 Regression] ICE on valid in OMP parallel region
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66549 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added CC||mikael at gcc dot gnu.org Component|libgomp |fortran Target Milestone|--- |5.2 --- Comment #2 from Jakub Jelinek jakub at gcc dot gnu.org --- r221586 in particular.
[Bug fortran/66544] ICE on function with pointer result in combination with implicit none
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66544 Dominique d'Humieres dominiq at lps dot ens.fr changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2015-06-17 Ever confirmed|0 |1 --- Comment #2 from Dominique d'Humieres dominiq at lps dot ens.fr --- Confirmed from 4.8 up to trunk (6.0).
[Bug target/66563] [4.9 Regression] ICE (segmentation fault) on sh4-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66563 --- Comment #2 from John Paul Adrian Glaubitz glaubitz at physik dot fu-berlin.de --- Just as a heads up: Once the buildd has finished building the latest gcc-4.9_4.9.2-21 package, I will update all buildds and reschedule all affected packages to see if that fixes the problem. If not, we might actually see really a regression here which could certainly be attributed to any of the recent changes listed here [1]. But I really hope it's just this single package built which is broken :). Adrian [1] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65979#c8
[Bug target/65952] [AArch64] Will not vectorize storing induction of pointer addresses for LP64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65952 --- Comment #7 from alalaw01 at gcc dot gnu.org --- (In reply to Richard Biener from comment #6) So aarch64 has no DImode vectors? Or just no DImode multiply (but it has a DImode vector shift?). Yes, the latter.
[Bug c++/66383] [5/6 Regression] ICE in gimplify_expr on this passed in inline initialization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66383 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #6 from Jakub Jelinek jakub at gcc dot gnu.org --- This regressed PR66536.
[Bug target/66483] [4.9 Regression] ICE (in add_stores, at var-tracking.c:6000) on arm-linux-gnueabihf
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66483 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Target Milestone|4.9.4 |4.9.3
[Bug target/65952] [AArch64] Will not vectorize storing induction of pointer addresses for LP64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65952 --- Comment #8 from alalaw01 at gcc dot gnu.org --- (In reply to alalaw01 from comment #7) (In reply to Richard Biener from comment #6) So aarch64 has no DImode vectors? Or just no DImode multiply (but it has a DImode vector shift?). Yes, the latter. Sorry, aarch64 has a DImode multiply, but no V2DImode multiply; and it has V2DImode shifts.
[Bug fortran/66562] ICE with gfortran-5.1.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66562 --- Comment #3 from Dan Kokron Daniel.Kokron at nasa dot gov --- @karlg The original code accessed the array with in a loop using i:, so the proposed workaround doesn't help my case. PS: Thanks for the advise. Newbie mistake.
[Bug target/65527] ICE: in expand_builtin_with_bounds, at builtins.c:7120 with -fcheck-pointer-bounds -mmpx
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65527 Ilya Enkovich ienkovich at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #4 from Ilya Enkovich ienkovich at gcc dot gnu.org --- Fixed
[Bug other/65530] [meta-bug] -mmpx -fcheck-pointer-bounds failures
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65530 Bug 65530 depends on bug 65527, which changed state. Bug 65527 Summary: ICE: in expand_builtin_with_bounds, at builtins.c:7120 with -fcheck-pointer-bounds -mmpx https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65527 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED
[Bug lto/66394] [4.9/5/6 Regression] ICE in -flto -fmerge-all-constants -fno-use-linker-plugin targetting i686-w64-mingw32
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66394 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |4.9.3
[Bug bootstrap/63740] [4.9 Regression] GCC 4.9.2 bootstrap fails on ARM, haifa-sched.c:6507:1: internal compiler error: in lra_create
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63740 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #12 from Jakub Jelinek jakub at gcc dot gnu.org --- Any progress on this?
[Bug c++/66536] [5/6 Regression] ICE in build_ctor_subob_ref, at cp/tree.c:2534
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66536 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Priority|P3 |P1 Status|UNCONFIRMED |NEW Last reconfirmed||2015-06-17 CC||jakub at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #2 from Jakub Jelinek jakub at gcc dot gnu.org --- Started with r224282, therefore very recent regression from 5.1. Thus a P1 blocker for 5.2.
[Bug target/65952] [AArch64] Will not vectorize storing induction of pointer addresses for LP64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65952 --- Comment #6 from Richard Biener rguenth at gcc dot gnu.org --- So aarch64 has no DImode vectors? Or just no DImode multiply (but it has a DImode vector shift?). If so this could be handled by a vectorizer pattern transforming the multiply to a shift.
[Bug ipa/64190] [4.9 Regression] FAIL: gcc.dg/ipa/pr63551.c (test for excess errors)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64190 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Target Milestone|3.4.4 |4.9.3
[Bug ipa/64190] [4.9 Regression] FAIL: gcc.dg/ipa/pr63551.c (test for excess errors)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64190 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Target Milestone|4.9.4 |3.4.4
[Bug ipa/65908] [5/6 Regression] ICE: in expand_thunk, at cgraphunit.c:1700
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65908 --- Comment #10 from Martin Liška marxin at gcc dot gnu.org --- There's pending patch in ML: https://gcc.gnu.org/ml/gcc-patches/2015-06/msg00746.html I'm going to ping Honza.
[Bug c++/66536] [5 Regression] ICE in build_ctor_subob_ref, at cp/tree.c:2534
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66536 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Known to work||5.1.0, 6.0 Summary|[5/6 Regression] ICE in |[5 Regression] ICE in |build_ctor_subob_ref, at|build_ctor_subob_ref, at |cp/tree.c:2534 |cp/tree.c:2534 --- Comment #3 from Richard Biener rguenth at gcc dot gnu.org --- Fixed on trunk sofar.
[Bug c/63307] [4.9 Regression] Cilk+ breaks -fcompare-debug bootstrap
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63307 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Priority|P1 |P2 Status|ASSIGNED|NEW Assignee|jakub at gcc dot gnu.org |unassigned at gcc dot gnu.org --- Comment #12 from Jakub Jelinek jakub at gcc dot gnu.org --- Not a P1 for the branch, furthermore not easily backportable.
[Bug bootstrap/63740] [4.9 Regression] GCC 4.9.2 bootstrap fails on ARM, haifa-sched.c:6507:1: internal compiler error: in lra_create
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63740 --- Comment #13 from Maxim Kuvyrkov mkuvyrkov at gcc dot gnu.org --- (In reply to Jakub Jelinek from comment #12) Any progress on this? This has slipped off my radar. Thanks for the ping, I'm working on this now.
[Bug target/65952] [AArch64] Will not vectorize storing induction of pointer addresses for LP64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65952
--- Comment #5 from alalaw01 at gcc dot gnu.org ---
So the above example tends to get fully unrolled, but even on an example with
32 ptrs rather than 4, yes the vectorizer fails because of the multiplication -
but the multiplication is gone by the final tree stage, as it's strength
reduced down to an add; I believe this -fdump-tree-optimized would be perfectly
vectorizable:
loop ()
{
unsigned long ivtmp.12;
unsigned long ivtmp.10;
void * _4;
struct my_struct * _7;
struct my_struct * pretmp_11;
unsigned long _20;
bb 2:
pretmp_11 = array;
ivtmp.10_16 = (unsigned long) pretmp_11;
ivtmp.12_2 = (unsigned long) ptrs;
_20 = (unsigned long) MEM[(void *)ptrs + 256B];
bb 3:
# ivtmp.10_10 = PHI ivtmp.10_1(3), ivtmp.10_16(2)
# ivtmp.12_15 = PHI ivtmp.12_14(3), ivtmp.12_2(2)
_7 = (struct my_struct *) ivtmp.10_10;
_4 = (void *) ivtmp.12_15;
MEM[base: _4, offset: 0B] = _7;
ivtmp.10_1 = ivtmp.10_10 + 16;
ivtmp.12_14 = ivtmp.12_15 + 8;
if (ivtmp.12_14 != _20)
goto bb 3;
else
goto bb 4;
bb 4:
return;
}
[Bug ipa/65908] [5/6 Regression] ICE: in expand_thunk, at cgraphunit.c:1700
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65908 --- Comment #9 from Jakub Jelinek jakub at gcc dot gnu.org --- Any progress on this? This is a P1 and we'd like to release GCC 5.2 soon.
[Bug c++/66450] [5 Regression][C++11][constexpr] Issues when delegating implicit copy constructor in constexpr function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66450 --- Comment #3 from Jason Merrill jason at gcc dot gnu.org --- Author: jason Date: Wed Jun 17 14:33:02 2015 New Revision: 224557 URL: https://gcc.gnu.org/viewcvs?rev=224557root=gccview=rev Log: PR c++/66450 * constexpr.c (cxx_eval_store_expression): Avoid messing up outer ctx-ctor. Added: branches/gcc-5-branch/gcc/testsuite/g++.dg/cpp0x/constexpr-fwctor1.C Modified: branches/gcc-5-branch/gcc/cp/ChangeLog branches/gcc-5-branch/gcc/cp/constexpr.c
[Bug c++/66387] [5/6 Regression] ICE in make_decl_rtl with lambda
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66387 --- Comment #6 from Jason Merrill jason at gcc dot gnu.org --- Author: jason Date: Wed Jun 17 14:33:08 2015 New Revision: 224558 URL: https://gcc.gnu.org/viewcvs?rev=224558root=gccview=rev Log: PR c++/66387 * pt.c (tsubst_copy) [VAR_DECL]: Use process_outer_var_ref. Added: branches/gcc-5-branch/gcc/testsuite/g++.dg/cpp1y/lambda-generic-ice2.C Modified: branches/gcc-5-branch/gcc/cp/ChangeLog branches/gcc-5-branch/gcc/cp/pt.c branches/gcc-5-branch/gcc/cp/semantics.c
[Bug c++/66289] [5/6 Regression] error: ambiguous template instantiation with partial specialization defined in terms of alias template
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66289 --- Comment #3 from Jason Merrill jason at gcc dot gnu.org --- Author: jason Date: Wed Jun 17 14:32:55 2015 New Revision: 224556 URL: https://gcc.gnu.org/viewcvs?rev=224556root=gccview=rev Log: PR c++/66289 * cp-tree.h (TEMPLATE_DECL_COMPLEX_ALIAS_P): New. * pt.c (push_template_decl_real): Set it. (dependent_alias_template_spec_p): Use it. (dependent_type_p_r): Use dependent_alias_template_spec_p. (uses_all_template_parms_data, uses_all_template_parms_r) (complex_alias_template_p): New. (get_template_parm_index): Handle BOUND_TEMPLATE_TEMPLATE_PARM. Added: branches/gcc-5-branch/gcc/testsuite/g++.dg/cpp0x/alias-decl-48.C Modified: branches/gcc-5-branch/gcc/cp/ChangeLog branches/gcc-5-branch/gcc/cp/cp-tree.h branches/gcc-5-branch/gcc/cp/pt.c
[Bug c++/66536] [5 Regression] ICE in build_ctor_subob_ref, at cp/tree.c:2534
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66536 --- Comment #4 from Jason Merrill jason at gcc dot gnu.org --- Author: jason Date: Wed Jun 17 14:33:23 2015 New Revision: 224560 URL: https://gcc.gnu.org/viewcvs?rev=224560root=gccview=rev Log: PR c++/66536 * tree.c (replace_placeholders_r) [CONSTRUCTOR]: Handle type mismatch. Added: branches/gcc-5-branch/gcc/testsuite/g++.dg/cpp1y/var-templ30.C Modified: branches/gcc-5-branch/gcc/cp/ChangeLog branches/gcc-5-branch/gcc/cp/tree.c
[Bug c++/58063] default arguments evaluated twice per call
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58063 --- Comment #14 from Jason Merrill jason at gcc dot gnu.org --- Author: jason Date: Wed Jun 17 14:33:17 2015 New Revision: 224559 URL: https://gcc.gnu.org/viewcvs?rev=224559root=gccview=rev Log: PR c++/58063 * tree.c (bot_manip): Remap SAVE_EXPR. Added: branches/gcc-5-branch/gcc/testsuite/g++.dg/overload/defarg10.C Modified: branches/gcc-5-branch/gcc/cp/ChangeLog branches/gcc-5-branch/gcc/cp/tree.c
[Bug c++/66571] New: Template substitution causes some OpenMP rejects-valid
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66571
Bug ID: 66571
Summary: Template substitution causes some OpenMP rejects-valid
Product: gcc
Version: 5.1.1
Status: UNCONFIRMED
Keywords: openmp
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: jakub at gcc dot gnu.org
CC: jason at gcc dot gnu.org
Target Milestone: ---
template typename T, typename U
extern void bar (T, T, U);
template typename T, typename U
void
foo (T a, T b, U c)
{
#pragma omp parallel for simd shared (a, c) reduction (+:b)
for (int i = 0; i 10; i++)
barT (a, b, c);
#pragma omp target map(tofrom:a, c[0:5])
;
#pragma omp task depend(inout:c[4:2])
;
T d = a;
T e = b;
U f = c;
#pragma omp parallel for simd shared (d, f) reduction (+:e)
for (int i = 0; i 10; i++)
barT (d, e, f);
#pragma omp target map(tofrom:d, f[0:5])
;
#pragma omp task depend(inout:f[4:2])
;
}
void
baz ()
{
int a = 0, b = 0, cb[10] = {}, *c = cb;
foo int, int * (a, b, c);
foo int , int * (a, b, c);
}
is rejected with -fopenmp right now, because during tsubst_omp_clauses if
changing a non-REFERENCE_TYPE decl into a REFERENCE_TYPE decl
convert_from_reference is called, while finish_omp_clauses (and later code)
checks if OMP_CLAUSE_DECL is a decl (and later code relies on it).
[Bug libgcc/66570] New: libbacktrace is not installed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66570 Bug ID: 66570 Summary: libbacktrace is not installed Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: libgcc Assignee: unassigned at gcc dot gnu.org Reporter: jj at stusta dot net Target Milestone: --- libbacktrace is really useful and can be used by user programs perfectly. Please install the library by default. Currently: libbacktrace/Makefile.am: noinst_LTLIBRARIES = libbacktrace.la Gentoo won't install it on its own: https://bugs.gentoo.org/show_bug.cgi?id=552098 Debian already includes the library in in libgcc-4.8-dev and later (https://packages.debian.org/sid/amd64/libgcc-4.9-dev/filelist). We'd like to use libbacktrace for http://openage.sft.mx/ but because of this issue many distributors don't provide the probably best backtrace library.
[Bug bootstrap/63740] [4.9 Regression] GCC 4.9.2 bootstrap fails on ARM, haifa-sched.c:6507:1: internal compiler error: in lra_create
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63740 Maxim Kuvyrkov mkuvyrkov at gcc dot gnu.org changed: What|Removed |Added Assignee|mkuvyrkov at gcc dot gnu.org |vmakarov at gcc dot gnu.org --- Comment #14 from Maxim Kuvyrkov mkuvyrkov at gcc dot gnu.org --- OK, I'm not sorry after all, this was not supposed to be on my radar :-). Re-assigning to the right person -- Vladimir.
[Bug c++/66572] New: [6 Regression] Bogus Wlogical-op warning for operands coming from template instantiations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66572
Bug ID: 66572
Summary: [6 Regression] Bogus Wlogical-op warning for operands
coming from template instantiations
Product: gcc
Version: 6.0
Status: UNCONFIRMED
Keywords: diagnostic
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: miyuki at gcc dot gnu.org
Target Milestone: ---
Consider this example:
$ cat ./test.cc
struct false_type
{
static constexpr bool value = false;
};
struct true_type
{
static constexpr bool value = true;
};
templatetypename T
struct is_unsigned : false_type {};
template
struct is_unsignedunsigned : true_type {};
templatetypename T1, typename T2
bool foo()
{
return is_unsignedT1::value is_unsignedT2::value;
}
int main()
{
foounsigned, unsigned();
}
$ g++ -Wlogical-op -std=c++11 ./test.cc
./test.cc: In instantiation of 'bool foo() [with T1 = unsigned int; T2 =
unsigned int]':
./test.cc:25:29: required from here
./test.cc:20:35: warning: logical 'and' of equal expressions [-Wlogical-op]
return is_unsignedT1::value is_unsignedT2::value;
IMHO GCC should not issue this warning: in this instantiation
(is_unsignedunsigned::value is_unsignedunsigned::value) operator is
indeed redundant, but that is not true for general case.
[Bug target/66483] [4.9 Regression] ICE (in add_stores, at var-tracking.c:6000) on arm-linux-gnueabihf
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66483 --- Comment #10 from Thomas Preud'homme thopre01 at gcc dot gnu.org --- There is something strange about this bug. I compiled an arm-linux-gnueabihf gcc only (using make all-gcc) twice, once with an arm-none-eabi cross binutils in the PATH and once without. The bug is reproduced with the former case but not the latter. I checked the objdump of object files in both case and most files have no difference, with a few showing at first glance only small offset difference. Could there be a dangling pointer issue at play? r212178 can be backported without issue but any full build of gcc for me falls in the latter case so I'm not confident with the testing.
[Bug c++/66387] [5/6 Regression] ICE in make_decl_rtl with lambda
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66387 Markus Trippelsdorf trippels at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #7 from Markus Trippelsdorf trippels at gcc dot gnu.org --- Fixed.
[Bug c++/66573] New: Unexpected change in static, branch-prediction cost from O1 to O2.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66573
Bug ID: 66573
Summary: Unexpected change in static, branch-prediction cost
from O1 to O2.
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: jmcguiness at liquidcapital dot com
Target Milestone: ---
For the following versions of gcc: 4.8.2, 4.9.0 and 5.10 with the following
code sequence:
extern void bar1();
extern void bar2();
void foo(bool i) {
if (i)
bar1();
else
bar2();
}
I have examined the assembler output for -O0, -O1, -O2 and -O3.
For all versions with -O0 -O1 I get this:
foo(bool):
subq$8, %rsp
testb %dil, %dil
je .L2
callbar1()
jmp .L1
.L2:
callbar2()
.L1:
addq$8, %rsp
ret
For all version with -O2 and -O3 I get this:
foo(bool):
testb %dil, %dil
jne .L4
jmp bar2()
.L4:
jmp bar1()
Note how the calls to bar1() and bar2() have been swapped. (I realise that the
condition has been swapped too, so that the generated code is correct.)
According to:
https://software.intel.com/en-us/articles/branch-and-loop-reorganization-to-prevent-mispredicts/
Forward jumps are not taken. So what has happened is that for -O0 and -O1 the
static branch-prediction has given no mis-prediction if bar1() is called, i.e.
the condition is usually true. But this flips for -O2 and -O3 so that now
bar2() suffers no mis-prediction if the condition is usually false.
The result is that if one codes so that one minimises the mis-predition cost
for -O0 and -O1 this becomes a pessimisation for -O2 and -O3. A rather
unexpected result.
Note that icc v13.0.1 generates the following assembly sequence:
foo(bool):
testb %dil, %dil#5.7
je..B1.3# Prob 50% #5.7
jmp bar1() #6.2
..B1.3: # Preds ..B1.1
jmp bar2() #8.5
Which is stable for all optimisation levels, and works as one might expect: the
if-branch is the predicted branch, the else not.
(Yes I am aware of __builtin_expected(), but that is beside the point. One
would expect that the cost should reduce with increasing levels of optimisation
not increase!)
[Bug go/66138] json decoder Decode function fails for some structure return values
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66138 --- Comment #1 from boger at us dot ibm.com --- I am not sure, but this appears to be similar to the golang issue I opened yesterday https://github.com/golang/go/issues/11236 which was closed as a duplicate of https://github.com/golang/go/issues/7247.
[Bug target/65914] [6 Regression] error: unrecognizable insn
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65914
Markus Trippelsdorf trippels at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed||2015-06-17
Ever confirmed|0 |1
--- Comment #3 from Markus Trippelsdorf trippels at gcc dot gnu.org ---
Another smaller testcase:
trippels@gcc2-power8 tools % cat sf_concept_check_elliptic.ii
enum expression_template_option { et_on };
template class, expression_template_option = et_on class A;
template class, class, class, class = void, class = void struct expression;
template class T struct B { typedef const T type; };
template class tag, class A1, class A2, class A3, class A4
struct Bexpressiontag, A1, A2, A3, A4 {
typedef expressiontag, A1, A2 type;
};
template class tag, class Arg1, class Arg2
struct expressiontag, Arg1, Arg2 {
expression(Arg1 p1, const Arg2 p2) : arg1(p1), arg2(p2) {}
typename BArg1::type arg1;
typename BArg2::type arg2;
};
template class Backend expressionint, int, ABackend sin(ABackend) {
return expressionint, int, ABackend(0, 0);
}
template class tag, class A1, class A2, class A3, class A4
expressionint, int, expressiontag, A1, A2
asin(expressiontag, A1, A2, A3, A4 p1) {
return expressionint, int, expressiontag, A1, A2(0, p1);
}
template class B, expression_template_option ET, class tag, class Arg1,
class Arg2, class Arg3, class Arg4
expressionint, AB, expressiontag, Arg1, Arg2
operator+(AB, ET, expressiontag, Arg1, Arg2, Arg3, Arg4 p2) {
return expressionint, AB, expressiontag, Arg1, Arg2(0, p2);
}
template class tag, class Arg1, class Arg2, class Arg3, class Arg4, class
tag2,
class Arg1b, class Arg2b, class Arg3b, class Arg4b
expressionint, expressiontag, Arg1, Arg2, expressiontag2, Arg1b, Arg2b
operator*(expressiontag, Arg1, Arg2, Arg3, Arg4 p1,
expressiontag2, Arg1b, Arg2b, Arg3b, Arg4b p2) {
return expressionint, expressiontag, Arg1, Arg2,
expressiontag2, Arg1b, Arg2b(p1, p2);
}
template class B expressionint, AB, AB operator/(AB, AB) {
return expressionint, AB, AB(0, 0);
}
template class tag, class Arg1, class Arg2, class Arg3, class Arg4, class V
void operator/(expressiontag, Arg1, Arg2, Arg3, Arg4, V);
template class, expression_template_option class A {
public:
A() {}
template class V A(V) {}
};
template class T, class Policy void jacobi_recurse(T, T, Policy) {
T a, b, c;
(a + asin(b / c) * sin(a)) / 0.1;
}
template class T, class Policy void jacobi_imp(T p1, Policy) {
T x;
jacobi_recurse(x, p1, 0);
}
template class T, class U, class V, class Policy
void jacobi_elliptic(T, U, V, Policy) {
jacobi_imp(static_castT(0), 0);
}
template class U, class T, class Policy void jacobi_sn(U, T, Policy) {
jacobi_elliptic(static_castT(0), 0, 0, 0);
}
template class U, class T void jacobi_sn(U, T p2) { jacobi_sn(0, p2, 0); }
template class T void test_extra(T) {
T d;
jacobi_sn(0, d);
}
void foo() { test_extra(Aint()); }
trippels@gcc2-power8 tools % g++ -O3 -c -std=c++14 sf_concept_check_elliptic.ii
sf_concept_check_elliptic.ii: In function ‘void foo()’:
sf_concept_check_elliptic.ii:67:36: error: unrecognizable insn:
void foo() { test_extra(Aint()); }
^
(insn 11 10 12 2 (set (reg:V2DI 168 [ vect_cst_.59 ])
(vec_concat:V2DI (reg:DI 169 [ D.3522 ])
(reg/f:DI 150 virtual-stack-vars [ D.3522 ]))) -1
(nil))
sf_concept_check_elliptic.ii:67:36: internal compiler error: in extract_insn,
at recog.c:2319
0x109fe913 _fatal_insn(char const*, rtx_def const*, char const*, int, char
const*)
../../gcc/gcc/rtl-error.c:110
0x109fe98f _fatal_insn_not_found(rtx_def const*, char const*, int, char const*)
../../gcc/gcc/rtl-error.c:118
0x109c32a7 extract_insn(rtx_insn*)
../../gcc/gcc/recog.c:2319
0x106f6d5b instantiate_virtual_regs_in_insn
../../gcc/gcc/function.c:1588
0x106f6d5b instantiate_virtual_regs
../../gcc/gcc/function.c:1956
0x106f6d5b execute
../../gcc/gcc/function.c:2005
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.
