[Bug ipa/65432] New: [5 Regression] Invalid read of size 1: ipa_icf::sem_item_optimizer::merge_classes(unsigned int) (ipa-icf.c:2958)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65432 Bug ID: 65432 Summary: [5 Regression] Invalid read of size 1: ipa_icf::sem_item_optimizer::merge_classes(unsigned int) (ipa-icf.c:2958) Product: gcc Version: 5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: ipa Assignee: unassigned at gcc dot gnu.org Reporter: trippels at gcc dot gnu.org Running the testsuite on ppc64le with an --enable-checking=valgrind compiler shows many instances of: ==94166== Invalid read of size 1 ==94166==at 0x40980F8: strlen (in /usr/lib64/valgrind/vgpreload_memcheck-ppc64le-linux.so) ==94166==by 0x4626503: vfprintf@@GLIBC_2.17 (in /usr/lib64/libc-2.20.so) ==94166==by 0x4631003: fprintf@@GLIBC_2.17 (in /usr/lib64/libc-2.20.so) ==94166==by 0x10CF34B3: ipa_icf::sem_item_optimizer::merge_classes(unsigned int) (ipa-icf.c:2958) ==94166==by 0x10CF962B: ipa_icf::sem_item_optimizer::execute() (ipa-icf.c:2236) ==94166==by 0x10CFC8DF: ipa_icf_driver (ipa-icf.c:3060) ==94166==by 0x10CFC8DF: ipa_icf::pass_ipa_icf::execute(function*) (ipa-icf.c:3107) ==94166==by 0x1068FBC7: execute_one_pass(opt_pass*) (passes.c:2328) ==94166==by 0x10690B53: execute_ipa_pass_list(opt_pass*) (passes.c:2727) ==94166==by 0x1038D2DF: ipa_passes (cgraphunit.c:2207) ==94166==by 0x1038D2DF: symbol_table::compile() (cgraphunit.c:2295) ==94166==by 0x1038ED47: symbol_table::finalize_compilation_unit() (cgraphunit.c:2444) ==94166==by 0x101A31CB: cp_write_global_declarations() (decl2.c:4754) ==94166==by 0x1076894F: compile_file() (toplev.c:608) ==94166== Address 0x701ee20 is 0 bytes inside a block of size 38 free'd ==94166==at 0x4095394: free (in /usr/lib64/valgrind/vgpreload_memcheck-ppc64le-linux.so) ==94166==by 0x10243CAF: cxx_printable_name_internal(tree_node*, int, bool) (tree.c:2026) ==94166==by 0x10374D23: symtab_node::name() const (symtab.c:479) ==94166==by 0x10CF3497: name (ipa-icf.h:177) ==94166==by 0x10CF3497: ipa_icf::sem_item_optimizer::merge_classes(unsigned int) (ipa-icf.c:2958) ==94166==by 0x10CF962B: ipa_icf::sem_item_optimizer::execute() (ipa-icf.c:2236) ==94166==by 0x10CFC8DF: ipa_icf_driver (ipa-icf.c:3060) ==94166==by 0x10CFC8DF: ipa_icf::pass_ipa_icf::execute(function*) (ipa-icf.c:3107) ==94166==by 0x1068FBC7: execute_one_pass(opt_pass*) (passes.c:2328) ==94166==by 0x10690B53: execute_ipa_pass_list(opt_pass*) (passes.c:2727) ==94166==by 0x1038D2DF: ipa_passes (cgraphunit.c:2207) ==94166==by 0x1038D2DF: symbol_table::compile() (cgraphunit.c:2295) ==94166==by 0x1038ED47: symbol_table::finalize_compilation_unit() (cgraphunit.c:2444) ==94166==by 0x101A31CB: cp_write_global_declarations() (decl2.c:4754) ==94166==by 0x1076894F: compile_file() (toplev.c:608)
[Bug middle-end/65431] [5 Regression] Invalid read of size 8 at 0x105DBBF8: delete_omp_context(unsigned long) (omp-low.c:1586)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65431 --- Comment #1 from Markus Trippelsdorf trippels at gcc dot gnu.org --- To reproduce: trippels@gcc2-power8 testsuite % ~/gcc_valgrind/usr/local/bin/g++ -c -std=c++11 -fopenacc c-c++-common/goacc/nesting-1.c
[Bug fortran/65024] [OOP] unlimited polymorphic pointer structure not built when it should be
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65024 Paul Thomas pault at gcc dot gnu.org changed: What|Removed |Added Keywords|ice-on-valid-code |FIXME Version|4.9.2 |5.0 Target Milestone|4.9.3 |6.0 Summary|[4.9/5 Regression] [OOP]|[OOP] unlimited polymorphic |ICE concerning unlimited|pointer structure not built |polymorphic pointer |when it should be --- Comment #14 from Paul Thomas pault at gcc dot gnu.org --- Although the regression is fixed, it is desirable to find out why the unlimited polymorphic type is not being built at source. This foxed me completely; albeit with a limited amount of time spent on it. The patch has the virtue that it is failsafe but I will leave the PR open. Thanks for the report Paul
[Bug target/65414] [5 Regression] ICE while building libgcc after stage 2, bootstrap failure on aarch64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65414 --- Comment #8 from Andrew Pinski pinskia at gcc dot gnu.org --- It is working with 2ed7acc3505bbfed6a80787cf2537e212ff2bbe2 (revision 221332).
[Bug go/65272] switch on type of interface failing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65272 --- Comment #3 from James Michael DuPont JamesMikeDuPont at googlemail dot com --- (In reply to James Michael DuPont from comment #2) also on github https://github.com/golang/go/issues/10047 this was closed on github because it is valid go.
[Bug c++/65159] Linker forgets definition of type_info::__is_pointer_p
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65159 --- Comment #8 from David Krauss potswa at mac dot com --- It was an updated tree. I'm not sure what revision it was updated from, but it was probably late January. Sorry for the delay, my machine got completely hosed by a bad RAM chip. Took the filesystem with it. So, bit rot and disk corruption can't be ruled out either. Jonathan, what does the confirmed mean, were you able to reproduce it at all?
[Bug c++/65159] Linker forgets definition of type_info::__is_pointer_p
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65159 --- Comment #9 from Jonathan Wakely redi at gcc dot gnu.org --- (In reply to David Krauss from comment #8) Jonathan, what does the confirmed mean, were you able to reproduce it at all? Yes, but not after starting a fresh build in am empty directory, so it seems to be due to building in a dirty tree. Please try again with a clean build.
[Bug preprocessor/60875] `_Pragma(message \foo\)` doesn't work in expression contexts.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60875 Ryan Lortie desrt at desrt dot ca changed: What|Removed |Added CC||desrt at desrt dot ca --- Comment #3 from Ryan Lortie desrt at desrt dot ca --- We want to do similar things in GLib in order to warn in the middle of arbitrary expressions or statements expanded from macros (essentially: support for deprecated macros).
[Bug go/65272] switch on type of interface failing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65272 Ian Lance Taylor ian at airs dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #4 from Ian Lance Taylor ian at airs dot com --- I was also closed on github because the bug was fixed in gccgo.
[Bug ipa/65432] [5 Regression] Invalid read of size 1: ipa_icf::sem_item_optimizer::merge_classes(unsigned int) (ipa-icf.c:2958)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65432 --- Comment #1 from Markus Trippelsdorf trippels at gcc dot gnu.org --- To reproduce: trippels@gcc2-power8 testsuite % ~/gcc_valgrind/usr/local/bin/g++ -c -O2 -fdump-ipa-icf -fno-inline g++.dg/ipa/ipa-icf-4.C
[Bug target/65414] [5 Regression] ICE while building libgcc after stage 2, bootstrap failure on aarch64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65414 --- Comment #9 from Andrew Pinski pinskia at gcc dot gnu.org --- (In reply to Andrew Pinski from comment #8) It is working with 2ed7acc3505bbfed6a80787cf2537e212ff2bbe2 (revision 221332). Fails with f4aade0acf5728ebadda80b38944f427a000e255 (revision 221402)
[Bug target/64833] [SH]: Error: pcrel too far when compiling imagemagick and graphicsmagick on Debian sh4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64833 --- Comment #6 from John Paul Adrian Glaubitz glaubitz at physik dot fu-berlin.de --- Here's a tarball with the failed build: http://userpage.physik.fu-berlin.de/~glaubitz/graphicsmagick-failed-build.tar.gz You can reproduce the problem with: $ cd graphicsmagick-1.3.20/ $ cd PerlMagick/ $ make Magick.o You probably need a working Perl installation to be able to build. Adrian
[Bug c/65430] New: false negative of -Wsequence-point
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65430
Bug ID: 65430
Summary: false negative of -Wsequence-point
Product: gcc
Version: 5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: chengniansun at gmail dot com
There is no warning on the expression on line 3, which has a sequence-point
issue. Either a=3 or a=0 could be executed first.
Moreover, it is odd that gcc does not warn that the value of the expression is
not used.
$: cat s.c
int a;
int fn1() {
(a = 3, 8) * (a = 0);
return a;
}
$: gcc-trunk -c -Wsequence-point s.c
$: clang-trunk -c -Wsequence-point -Wno-unused-value s.c
s.c:3:6: warning: multiple unsequenced modifications to 'a' [-Wunsequenced]
(a = 3, 8) * (a = 0);
^~
1 warning generated.
$:
$:
[Bug c/65423] No warning on always-true/false predicates containing bitwise operations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65423 Mikhail Maltsev maltsevm at gmail dot com changed: What|Removed |Added CC||maltsevm at gmail dot com --- Comment #2 from Mikhail Maltsev maltsevm at gmail dot com --- Probably this one: PR17534
[Bug fortran/65024] [4.9/5 Regression] [OOP] ICE concerning unlimited polymorphic pointer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65024 --- Comment #13 from Paul Thomas pault at gcc dot gnu.org --- Author: pault Date: Sun Mar 15 09:13:03 2015 New Revision: 221440 URL: https://gcc.gnu.org/viewcvs?rev=221440root=gccview=rev Log: 2015-03-15 Paul Thomas pa...@gcc.gnu.org PR fortran/65024 * trans-expr.c (gfc_conv_component_ref): If the component backend declaration is missing and the derived type symbol is available in the reference, call gfc_build_derived_type. 2015-03-15 Paul Thomas pa...@gcc.gnu.org PR fortran/65024 * gfortran.dg/unlimited_polymorphic_23.f90: New test Added: branches/gcc-4_8-branch/gcc/testsuite/gfortran.dg/unlimited_polymorphic_23.f90 Modified: branches/gcc-4_8-branch/gcc/fortran/ChangeLog branches/gcc-4_8-branch/gcc/fortran/trans-expr.c branches/gcc-4_8-branch/gcc/testsuite/ChangeLog
[Bug c++/65143] [C++11] missing devirtualization for virtual base in final classes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65143
Mikhail Maltsev maltsevm at gmail dot com changed:
What|Removed |Added
CC||maltsevm at gmail dot com
--- Comment #3 from Mikhail Maltsev maltsevm at gmail dot com ---
This optimization is still missing in current trunk:
$ cat ./test.cc
struct A
{
int j;
};
struct B : public virtual A
{
};
struct C final : public B
{
int get();
};
int C::get()
{
return A::j;
}
$ /opt/gcc-5.0.0/bin/g++ -O -std=c++11 -c -S ./test.cc -o test_gcc.s cat
./test_gcc.s
.file test.cc
.text
.align 2
.globl _ZN1C3getEv
.type _ZN1C3getEv, @function
_ZN1C3getEv:
.LFB0:
.cfi_startproc
movq(%rdi), %rax
movq-24(%rax), %rax
movl(%rdi,%rax), %eax
ret
.cfi_endproc
.LFE0:
.size _ZN1C3getEv, .-_ZN1C3getEv
.ident GCC: (GNU) 5.0.0 20150315 (experimental)
.section.note.GNU-stack,,@progbits
(Note: optimization flags like -O3 and -fdevirtualize-speculatively don't
affect this behavior; neither method calls nor data member accesses get
devirtualized)
$ clang++ -O -std=c++11 -c -S ./test.cc -o test_clang.s cat ./test_clang.s
.text
.file ./test.cc
.globl _ZN1C3getEv
.align 16, 0x90
.type _ZN1C3getEv,@function
_ZN1C3getEv:# @_ZN1C3getEv
.cfi_startproc
# BB#0: # %entry
movl8(%rdi), %eax
retq
.Ltmp0:
.size _ZN1C3getEv, .Ltmp0-_ZN1C3getEv
.cfi_endproc
.ident clang version 3.7.0 (trunk 228487)
.section.note.GNU-stack,,@progbits
So, I can confirm it in sense reproduce (I don't have a right to change the
status of PR)
[Bug middle-end/65431] New: [5 Regression] Invalid read of size 8 at 0x105DBBF8: delete_omp_context(unsigned long) (omp-low.c:1586)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65431 Bug ID: 65431 Summary: [5 Regression] Invalid read of size 8 at 0x105DBBF8: delete_omp_context(unsigned long) (omp-low.c:1586) Product: gcc Version: 5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end Assignee: unassigned at gcc dot gnu.org Reporter: trippels at gcc dot gnu.org Running the testsuite on ppc64le with an --enable-checking=valgrind compiler shows many instances of: ==32629== Invalid read of size 8 ==32629==at 0x105DBBF8: delete_omp_context(unsigned long) (omp-low.c:1586) ==32629==by 0x10D6D50F: splay_tree_delete_helper (splay-tree.c:96) ==32629==by 0x10D6D50F: splay_tree_delete (splay-tree.c:353) ==32629==by 0x105E265B: execute_lower_omp (omp-low.c:11906) ==32629==by 0x105E265B: (anonymous namespace)::pass_lower_omp::execute(function*) (omp-low.c:11936) ==32629==by 0x10619A07: execute_one_pass(opt_pass*) (passes.c:2328) ==32629==by 0x10619F03: execute_pass_list_1(opt_pass*) (passes.c:2380) ==32629==by 0x10619FA3: execute_pass_list(function*, opt_pass*) (passes.c:2391) ==32629==by 0x10317FFB: cgraph_node::analyze() (cgraphunit.c:645) ==32629==by 0x1031B207: analyze_functions() (cgraphunit.c:1023) ==32629==by 0x1031B6B7: symbol_table::finalize_compilation_unit() (cgraphunit.c:2435) ==32629==by 0x105657C7: write_global_declarations() (langhooks.c:344) ==32629==by 0x10206083: gfc_write_global_declarations() (f95-lang.c:309) ==32629==by 0x106F278F: compile_file() (toplev.c:608) ==32629== Address 0x4951198 is 264 bytes inside a block of size 304 free'd ==32629==at 0x4095394: free (in /usr/lib64/valgrind/vgpreload_memcheck-ppc64le-linux.so) ==32629==by 0x105DBC87: delete_omp_context(unsigned long) (omp-low.c:1607) ==32629==by 0x10D6D4AB: splay_tree_delete_helper (splay-tree.c:89) ==32629==by 0x10D6D4AB: splay_tree_delete (splay-tree.c:353) ==32629==by 0x105E265B: execute_lower_omp (omp-low.c:11906) ==32629==by 0x105E265B: (anonymous namespace)::pass_lower_omp::execute(function*) (omp-low.c:11936) ==32629==by 0x10619A07: execute_one_pass(opt_pass*) (passes.c:2328) ==32629==by 0x10619F03: execute_pass_list_1(opt_pass*) (passes.c:2380) ==32629==by 0x10619FA3: execute_pass_list(function*, opt_pass*) (passes.c:2391) ==32629==by 0x10317FFB: cgraph_node::analyze() (cgraphunit.c:645) ==32629==by 0x1031B207: analyze_functions() (cgraphunit.c:1023) ==32629==by 0x1031B6B7: symbol_table::finalize_compilation_unit() (cgraphunit.c:2435) ==32629==by 0x105657C7: write_global_declarations() (langhooks.c:344) ==32629==by 0x10206083: gfc_write_global_declarations() (f95-lang.c:309) or: ==66627== Invalid read of size 8 ==66627==at 0x10650F58: delete_omp_context(unsigned long) (omp-low.c:1586) ==66627==by 0x10DD258B: splay_tree_delete_helper (splay-tree.c:89) ==66627==by 0x10DD258B: splay_tree_delete (splay-tree.c:353) ==66627==by 0x106579BB: execute_lower_omp (omp-low.c:11906) ==66627==by 0x106579BB: (anonymous namespace)::pass_lower_omp::execute(function*) (omp-low.c:11936) ==66627==by 0x1068FBC7: execute_one_pass(opt_pass*) (passes.c:2328) ==66627==by 0x106900C3: execute_pass_list_1(opt_pass*) (passes.c:2380) ==66627==by 0x10690163: execute_pass_list(function*, opt_pass*) (passes.c:2391) ==66627==by 0x1038B67B: cgraph_node::analyze() (cgraphunit.c:645) ==66627==by 0x1038E887: analyze_functions() (cgraphunit.c:1023) ==66627==by 0x1038ED37: symbol_table::finalize_compilation_unit() (cgraphunit.c:2435) ==66627==by 0x101A31CB: cp_write_global_declarations() (decl2.c:4754) ==66627==by 0x1076894F: compile_file() (toplev.c:608) ==66627==by 0x10111D33: do_compile (toplev.c:2076) ==66627==by 0x10111D33: toplev::main(int, char**) (toplev.c:2174) ==66627== Address 0x4a0b928 is 264 bytes inside a block of size 304 free'd ==66627==at 0x4095394: free (in /usr/lib64/valgrind/vgpreload_memcheck-ppc64le-linux.so) ==66627==by 0x10650FE7: delete_omp_context(unsigned long) (omp-low.c:1607) ==66627==by 0x10DD25EF: splay_tree_delete_helper (splay-tree.c:96) ==66627==by 0x10DD25EF: splay_tree_delete (splay-tree.c:353) ==66627==by 0x106579BB: execute_lower_omp (omp-low.c:11906) ==66627==by 0x106579BB: (anonymous namespace)::pass_lower_omp::execute(function*) (omp-low.c:11936) ==66627==by 0x1068FBC7: execute_one_pass(opt_pass*) (passes.c:2328) ==66627==by 0x106900C3: execute_pass_list_1(opt_pass*) (passes.c:2380) ==66627==by 0x10690163: execute_pass_list(function*, opt_pass*) (passes.c:2391) ==66627==by 0x1038B67B: cgraph_node::analyze() (cgraphunit.c:645) ==66627==by 0x1038E887: analyze_functions() (cgraphunit.c:1023) ==66627==by 0x1038ED37: symbol_table::finalize_compilation_unit() (cgraphunit.c:2435) ==66627==by
[Bug target/65414] [5 Regression] ICE while building libgcc after stage 2, bootstrap failure on aarch64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65414 --- Comment #10 from Andrew Pinski pinskia at gcc dot gnu.org --- 132858c819691c84077f130a5e7021961c0fb3ef (revision 221370) works.
[Bug c++/65433] ICE processing lambdas
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65433 Mikhail Maltsev maltsevm at gmail dot com changed: What|Removed |Added CC||maltsevm at gmail dot com --- Comment #2 from Mikhail Maltsev maltsevm at gmail dot com --- Does not reproduce on trunk $ /opt/gcc-5.0.0/bin/g++ -v Using built-in specs. COLLECT_GCC=/opt/gcc-5.0.0/bin/g++ COLLECT_LTO_WRAPPER=/opt/gcc-5.0.0/libexec/gcc/x86_64-unknown-linux-gnu/5.0.0/lto-wrapper Target: x86_64-unknown-linux-gnu Configured with: /home/miyuki/gcc/src/configure --prefix=/opt/gcc-5.0.0 --enable-clocale=gnu --disable-nls --with-system-zlib --with-demangler-in-ld --enable-plugins --enable-shared --enable-bootstrap --with-fpmath=sse --enable-languages=c,c++,lto Thread model: posix gcc version 5.0.0 20150315 (experimental) (GCC) $ /opt/gcc-5.0.0/bin/g++ -std=gnu++1y -g -Wall -Werror -fvisibility=hidden -pthread -O2 -c fail.i
[Bug c++/65433] ICE processing lambdas
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65433 Markus Trippelsdorf trippels at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||trippels at gcc dot gnu.org Resolution|--- |FIXED --- Comment #5 from Markus Trippelsdorf trippels at gcc dot gnu.org --- 5.0.0 20150129 is too old. Please use latest trunk when reporting bugs against 5.0.
[Bug c++/65433] New: ICE processing lambdas
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65433
Bug ID: 65433
Summary: ICE processing lambdas
Product: gcc
Version: 5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: a...@cloudius-systems.com
Processing some complex code involving lambdas in gnu++1y mode, the compiler
segfaults:
$ g++ -std=gnu++1y -g -Wall -Werror -fvisibility=hidden -pthread -O2 fail.i
In file included from ./core/seastar.hh:26:0,
from ./core/reactor.hh:25,
from ./net/net.hh:25,
from net/native-stack.hh:25,
from net/native-stack.cc:22:
./core/future.hh: In instantiation of 'struct futureT::then_wrapped(Func)
[with Func = smp_message_queue::async_work_itemFunc::process() [with Func =
net::arp_learn(net::ethernet_address,
net::ipv4_address)::lambda()]::lambda(auto:8); T = {};
futurize_tstd::result_of_tFunc(futureT) = future]::lambda(struct
future_state)':
./core/future.hh:510:58: required from
'futurize_tstd::result_of_tFunc(futureT) futureT::then_wrapped(Func)
[with Func = smp_message_queue::async_work_itemFunc::process() [with Func =
net::arp_learn(net::ethernet_address,
net::ipv4_address)::lambda()]::lambda(auto:8); T = {};
futurize_tstd::result_of_tFunc(futureT) = future]'
./core/reactor.hh:454:18: required from 'future
smp_message_queue::async_work_itemFunc::process() [with Func =
net::arp_learn(net::ethernet_address, net::ipv4_address)::lambda()]'
net/native-stack.cc:338:1: required from here
./core/future.hh:510:86: internal compiler error: Segmentation fault
return
thenstd::result_of_tFunc(futureT...)(std::forwardFunc(func), []
(future_stateT... state) { return future(std::move(state)); });
^
This is using gcc 5.0.0 from Fedora 22 (5.0.0-0.17).
Full source available from https://github.com/cloudius-systems/seastar.
Preprocessed source attached.
[Bug c++/65433] ICE processing lambdas
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65433 --- Comment #1 from Avi Kivity a...@cloudius-systems.com --- Created attachment 35038 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=35038action=edit Preprocessed source triggering ICE (bzip2'ed)
[Bug go/65272] switch on type of interface failing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65272 --- Comment #5 from James Michael DuPont JamesMikeDuPont at googlemail dot com --- @iant thanks for the update. my bad, I got confused. here is the commit. https://github.com/gcc-mirror/gcc/commit/cc0446bae7c8c0ccead885787ad3fc4db0c127e0
[Bug target/63234] arm used label is removed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63234 --- Comment #7 from Mikael Pettersson mikpelinux at gmail dot com --- The wrong-code started in the 4.7 dev cycle with r183328, a fix for a similar bug (PR50313) in 4.6. That fix was backported to 4.6 but doesn't trigger this PR there (I just re-checked with 4.6.4). The bug is masked on trunk by r211885, a generic missed-optimization tweak, and even earlier for Cortex-A9 by a costing tweak in r203828, but I doubt either of those actually fixes the underlying problem.
[Bug tree-optimization/65337] [5 Regression] bootstrap-lto gnat1 linktime ICE: gcc/ada/exp_aggr.adb:6570:0: internal compiler error: in forward_edge_to_pdom, at tree-ssa-dce.c:1086
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65337 --- Comment #3 from Jan Hubicka hubicka at gcc dot gnu.org --- Indeed, the cd-dce is one the worst documented of the tradition SSA optimizations. I commented on this to Jakum on IRC. The mechanizm that should prevent conditional from being removed is the control dependency. For every PHI argument, the control dependent conditional is marked live. So it is a question why the control dependent conditional is not live here - one of problems I remember was that control dependency is defined for basic blocks, while PHI handling needs it for edges. This mostly does not matter because critical edges are split, but with abnormal edges perhaps we manage to get things wrong. I am finishing paper today and fly to Vancouver at Tuesday, but will try to look into this as time allows.
[Bug c++/65433] ICE processing lambdas
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65433 --- Comment #3 from Avi Kivity a...@cloudius-systems.com --- Ok, will check with trunk. On Sun, Mar 15, 2015 at 9:48 PM, maltsevm at gmail dot com gcc-bugzi...@gcc.gnu.org wrote: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65433 Mikhail Maltsev maltsevm at gmail dot com changed: What|Removed |Added CC||maltsevm at gmail dot com --- Comment #2 from Mikhail Maltsev maltsevm at gmail dot com --- Does not reproduce on trunk $ /opt/gcc-5.0.0/bin/g++ -v Using built-in specs. COLLECT_GCC=/opt/gcc-5.0.0/bin/g++ COLLECT_LTO_WRAPPER=/opt/gcc-5.0.0/libexec/gcc/x86_64-unknown-linux-gnu/5.0.0/lto-wrapper Target: x86_64-unknown-linux-gnu Configured with: /home/miyuki/gcc/src/configure --prefix=/opt/gcc-5.0.0 --enable-clocale=gnu --disable-nls --with-system-zlib --with-demangler-in-ld --enable-plugins --enable-shared --enable-bootstrap --with-fpmath=sse --enable-languages=c,c++,lto Thread model: posix gcc version 5.0.0 20150315 (experimental) (GCC) $ /opt/gcc-5.0.0/bin/g++ -std=gnu++1y -g -Wall -Werror -fvisibility=hidden -pthread -O2 -c fail.i -- You are receiving this mail because: You reported the bug.
[Bug c++/65433] ICE processing lambdas
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65433 --- Comment #4 from Avi Kivity a...@cloudius-systems.com --- I see the same crash on trunk, only now I get a stack trace: 0xca999f crash_signal ../../gcc/toplev.c:383 0x7f0b74 contains_struct_check ../../gcc/tree.h:2959 0x7f0b74 lambda_expr_this_capture(tree_node*, bool) ../../gcc/cp/lambda.c:752 0x7f12c7 maybe_resolve_dummy(tree_node*, bool) ../../gcc/cp/lambda.c:789 0x5f3cde build_new_method_call_1 ../../gcc/cp/call.c:8010 0x5f3cde build_new_method_call(tree_node*, tree_node*, vectree_node*, va_gc, vl_embed**, tree_node*, int, tree_node**, int) ../../gcc/cp/call.c:8258 0x5f5379 build_special_member_call(tree_node*, tree_node*, vectree_node*, va_gc, vl_embed**, tree_node*, int, int) ../../gcc/cp/call.c:7802 0x5ebac9 build_temp ../../gcc/cp/call.c:6039 0x5ebac9 convert_like_real ../../gcc/cp/call.c:6428 0x5ecbf1 perform_implicit_conversion_flags(tree_node*, tree_node*, int, int) ../../gcc/cp/call.c:9405 0x73b4d6 check_return_expr(tree_node*, bool*) ../../gcc/cp/typeck.c:8708 0x77a0ae finish_return_stmt(tree_node*) ../../gcc/cp/semantics.c:887 0x7f2879 maybe_add_lambda_conv_op(tree_node*) ../../gcc/cp/lambda.c:1085 0x68e6cf instantiate_class_template_1 ../../gcc/cp/pt.c:9619 0x68e6cf instantiate_class_template(tree_node*) ../../gcc/cp/pt.c:9672 0x72bf73 complete_type(tree_node*) ../../gcc/cp/typeck.c:146 0x65f3b3 tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool, bool) ../../gcc/cp/pt.c:15673 0x660d6b tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool, bool) ../../gcc/cp/pt.c:15050 0x64db96 tsubst_expr ../../gcc/cp/pt.c:14382 0x64f3dc tsubst_expr ../../gcc/cp/pt.c:13789 g++5 (GCC) 5.0.0 20150129 (experimental) Not bootstraped (built by gcc 4.9.2)
[Bug target/63234] arm used label is removed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63234 --- Comment #8 from Mikael Pettersson mikpelinux at gmail dot com --- The failures on 4.7+ seem to be triggered by r177855, yet another ARM costing tweak. I'm not going to investigate this any further.
[Bug libstdc++/58625] std::signbit always converts to double
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58625
Tijl Coosemans tijl at coosemans dot org changed:
What|Removed |Added
CC||tijl at coosemans dot org
--- Comment #15 from Tijl Coosemans tijl at coosemans dot org ---
(In reply to Jakub Jelinek from comment #8)
That said, I'd say that every conversion to double that would change the
sign looks wrong to me, no matter of what the rounding mode is, except
perhaps for NaN canonicalization and that sNaN could be signalled. So IMHO
this is mostly an optimization thing, not correctness.
I do think this is a correctness problem for long double. Consider the
following C code:
int test( long double x ) {
return( __builtin_signbit( x ));
}
With gcc49 -O2 -S test.c on x86_64 this compiles to:
fldt 8(%rsp)
fstpl -16(%rsp)
movsd -16(%rsp), %xmm0
movmskpd %xmm0, %eax
andl $1, %eax
ret
The fstpl instruction converts long double to double and may generate all kinds
of floating point exceptions if the value can't be converted exactly and I
don't think signbit(x) is allowed to generate FP exceptions. So it would be
best to fix the c_std version too.
[Bug c/46115] Feature request: anonymous functions (complementing anon aggregates)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=46115 --- Comment #5 from Shawn Landden shawn at churchofgit dot com --- http://mackyle.github.io/blocksruntime/#download
[Bug c/46115] Feature request: anonymous functions (complementing anon aggregates)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=46115 Shawn Landden shawn at churchofgit dot com changed: What|Removed |Added CC||shawn at churchofgit dot com --- Comment #4 from Shawn Landden shawn at churchofgit dot com --- There is also the Apple blocks extension to C. http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1370.pdf http://clang.llvm.org/docs/Block-ABI-Apple.html#history
[Bug c/46115] Feature request: anonymous functions (complementing anon aggregates)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=46115 --- Comment #6 from Andrew Pinski pinskia at gcc dot gnu.org --- (In reply to Rob Staudinger from comment #3) For the record, this is already possible using bracketed expressions, but the syntactical sugar of not having to pick a function name would be great. Actually that is not valid as func is local to that scope and now it escapes.
[Bug middle-end/65414] [5 Regression] ICE while building libgcc after stage 2, bootstrap failure on aarch64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65414 Andrew Pinski pinskia at gcc dot gnu.org changed: What|Removed |Added Keywords||build, wrong-code CC||vries at gcc dot gnu.org Component|target |middle-end Severity|normal |blocker --- Comment #11 from Andrew Pinski pinskia at gcc dot gnu.org --- I am almost 100% sure it was caused by e2a16b9122d238b8877640b5f6ef1599e195fae0 (revision 221372). I am checking if reverting this patch from the current upstream will not crash.
[Bug fortran/64432] [5 Regression] SYSTEM_CLOCK(COUNT_RATE=rate) wrong result for integer(4)::rate
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64432 --- Comment #32 from Harald Anlauf anlauf at gmx dot de --- Jerry, to give you some positive feedback: I'm now using your latest patch in https://gcc.gnu.org/ml/fortran/2015-03/msg00067.html It works for me. Thanks, Harald
[Bug ipa/44563] GCC uses a lot of RAM when compiling a large numbers of functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=44563 --- Comment #34 from Jan Hubicka hubicka at ucw dot cz --- The problem is (as described earlier) the fact htat we sum size of all call statmts in function after every inline decision. Most of time is spent in calling estimate_edge_size_and_time: 79.95% cc1 cc1[.] _ZL28estimate_calls_size_and_timeP11cgraph_nodePiS1_S1_S1_j3vecIP9tree_node7va_heap6vl_ptrES2_I28ipa_polymorphic_call_contextS5_S6_ES2_IP21ipa_agg 2.21% cc1 libc-2.13.so [.] _int_malloc 0.59% cc1 libc-2.13.so [.] _int_free Updating summaries incrementally will solve it but at the moment do not see any really simple change for GCC-5 (i looked at this code couple times already because of this PR) Honza
[Bug libgcj/52579] [4.8/4.9/5 regression] i386_w32_fallback_frame_state should care ffi raw-closure stub function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52579 gee jojelino at gmail dot com changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |FIXED --- Comment #8 from gee jojelino at gmail dot com --- (In reply to Kai Tietz from comment #7) This issue seems to be fixed in 5.0 by Richard's work on libffi. Could you please check, if issue is fixed for you? libffi is now have frame information for raw-stub closure of stdcall calling convention.
[Bug middle-end/65414] [5 Regression] ICE while building libgcc after stage 2, bootstrap failure on aarch64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65414 --- Comment #12 from Andrew Pinski pinskia at gcc dot gnu.org --- (In reply to Andrew Pinski from comment #11) I am almost 100% sure it was caused by e2a16b9122d238b8877640b5f6ef1599e195fae0 (revision 221372). I am checking if reverting this patch from the current upstream will not crash. yes reverting that patch fixes the bootstrap for me.
[Bug lto/65380] [5 Regression] LTO: ICE in add_symbol_to_partition_1, at lto/lto-partition.c:158
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65380 --- Comment #4 from Jan Hubicka hubicka at gcc dot gnu.org --- Hmm, this one compiles just fine for me with today mainline. Does the problem still reproduce for you? Can you possibly dump out node-debug() and c?
[Bug regression/63150] [4.9/5 regression] FAIL: gcc.target/powerpc/pr53199.c scan-assembler-times *
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63150 Alan Modra amodra at gmail dot com changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |amodra at gmail dot com
[Bug target/62109] __gthr_i486_lock_cmp_xchg missing clobber
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62109 --- Comment #4 from David gccbugzilla at limegreensocks dot com --- (In reply to Mikael Pettersson from comment #3) Do you have a test case which fails without your patch? I do not. But this is a by definition thing. This instruction is intended to emulate the Windows InterlockedCompareExchange instruction (see the comments above the code). And all Windows Interlocked* instructions perform an implicit compiler barrier. After all, it does no good for the 'lock' prefix to prevent the processor from re-ordering instructions if the compiler does it while building the code. Moving loads or stores past this statement makes a mess of thread synchronization. That said, this instruction was only intended to be used on Win95 (neither NT nor Win98 need it). Not exactly a common platform these days. But it's possible someone is still using this, or will copy this asm block for their own use, so it should still be correct.
[Bug regression/63150] [4.9/5 regression] FAIL: gcc.target/powerpc/pr53199.c scan-assembler-times *
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63150 --- Comment #5 from Alan Modra amodra at gcc dot gnu.org --- Author: amodra Date: Mon Mar 16 03:29:36 2015 New Revision: 221445 URL: https://gcc.gnu.org/viewcvs?rev=221445root=gccview=rev Log: PR target/63150 gcc/ * config/rs6000/rs6000.md (bswapdi2): Remove one scratch reg. Modify Z-r bswapdi splitter to use dest in place of scratch. In r-Z and Z-r bswapdi splitter rename word_high, word_low to word1, word2 and rearrange logic to suit. (bswapdi2_64bit): Remove early clobber on Z-r alternative. (bswapdi2_ldbrx): Likewise. Remove '??' on r-r. (bswapdi2_32bit): Remove early clobber on Z-r alternative. Add one '?' on r-r. Modify Z-r splitter to avoid need for early clobber. gcc/testsuite/ * gcc.target/powerpc/pr53199.c: Add extra functions. Revert 2014-12-05 change. Modified: trunk/gcc/ChangeLog trunk/gcc/config/rs6000/rs6000.md trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.target/powerpc/pr53199.c
[Bug c/53119] -Wmissing-braces wrongly warns about universal zero initializer {0}
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53119 --- Comment #24 from nightstrike nightstrike at gmail dot com --- (In reply to Marek Polacek from comment #20) Sorry, the patch hasn't been applied to 4.9 nor 4.8 branch yet, and I don't think it should be backported as-is, because just today I found out that the patch contains a bug; see https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64709 Now that PR64709 is fixed, could you please backport both to 4.9 (and possibly 4.8)?
