[Bug ada/58239] New: [4.9 regression] pretty-print.c:789: undefined reference to `operator delete(void*)'

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58239 Bug ID: 58239 Summary: [4.9 regression] pretty-print.c:789: undefined reference to `operator delete(void*)' Product: gcc Version: 4.9.0 Status: UNCONFIRMED Keywo

[Bug c++/53025] [C++11] noexcept operator depends on copy-elision

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53025 --- Comment #3 from Daniel Krügler --- This is just a polite reminder for some response. I'm especially interested to hear whether there exist any reasonable doubts on the validity of the arguments brought forward. IMO it is important to fix at, b

[Bug target/57982] GetModuleHandle in __register_frame_info causes abort on unload

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57982 Andrew Pinski changed: What|Removed |Added Target||i686-*-mingw32 |

[Bug libstdc++/58153] unordered_multimap::erase(iterator) is not constant-time when many entries have the same key

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58153 --- Comment #4 from Kenton Varda --- > This report entry made me wonder why iterators could not just be > pointing to the node just before the one containing the pointed to value. That's a neat idea. I think there is an obscure issue, though. I

[Bug target/58208] deque 32-bit "-O3" bug

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58208 --- Comment #4 from Tammy Hsu --- Sorry, I forgot to mention that I need to set LD_LIBRARY_PATH to "." to run import. I build the gcc473 and gcc481 by using the same configuration and on the same RHEL 5.5 system, however the gcc473 version works a

[Bug libstdc++/58153] unordered_multimap::erase(iterator) is not constant-time when many entries have the same key

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58153 --- Comment #3 from François Dumont --- This report entry made me wonder why iterators could not just be pointing to the node just before the one containing the pointed to value. For instance begin() iterator would contained the before_begin one.

[Bug target/58158] [4.8/4.9 Regression] ICE with conditional moves on GPRs with a floating point conditional on mipsel with loongson2f

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58158 --- Comment #7 from Aaro Koskinen --- Loongson 2F is MIPS III + movz/movn only. I am currently running my compiler with the below workaround, and it seems to help: --- gcc-4.8.1.orig/gcc/config/mips/mips.md 2013-02-25 15:53:16.0 +020

[Bug other/58238] New: cc1 crashes when built for ms-dos cross-compiling

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58238 Bug ID: 58238 Summary: cc1 crashes when built for ms-dos cross-compiling Product: gcc Version: 4.7.3 Status: UNCONFIRMED Severity: normal Priority: P3 Component:

[Bug c/58237] New: gcc fails to detect obvious resource leaks

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58237 Bug ID: 58237 Summary: gcc fails to detect obvious resource leaks Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c

[Bug fortran/57798] [4.8/4.9 regression] Incorrect handling of sum over first dimension of a product of automatic arrays

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57798 Mikael Morin changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|---

[Bug fortran/57798] Incorrect handling of sum over first dimension of a product of automatic arrays

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57798 Mikael Morin changed: What|Removed |Added Summary|[4.8 Regression] Incorrect |Incorrect handling of sum

[Bug target/58208] deque 32-bit "-O3" bug

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58208 --- Comment #3 from Mikael Pettersson --- I can't reproduce the SEGV on Fedora 17 with gcc-4.8.1 -m32 or gcc-4.9 -m32. However, I think the build recipe is flawed. If I follow it to the letter (with -Wl,-rpath pointing to where I installed gcc-4

[Bug fortran/58229] [F03] Memory leak with allocatable scalar function result

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58229 janus at gcc dot gnu.org changed: What|Removed |Added Summary|[F03] Memory leak with |[F03] Memory leak with

[Bug fortran/58229] [F03] Memory leak with allocatable function result

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58229 --- Comment #2 from janus at gcc dot gnu.org --- (In reply to janus from comment #1) > The second one is the allocate-on-assignment inside the function, which > nevers gets freed. This *is* a bug. What should be done is: Create a > temporary for th

[Bug fortran/58185] [4.8/4.9 Regression] [OOP] ICE when selector in SELECT TYPE is non-polymorphic

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58185 janus at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|---

[Bug c/58236] -Wuninitialized doesn't report uninitialised variable as expected

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58236 --- Comment #2 from Noufal Ibrahim --- That solves the issue although I find the relationship between the optimisations and the warnings somewhat tenuous atleast from a user perspective. Would it not be a good idea to have this warning even by def

[Bug rtl-optimization/58220] [4.9 Regression] Many new failures for SH after rev. 201833

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58220 Kazumoto Kojima changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|---

[Bug fortran/50392] SIGSEGV in gfc_trans_label_assign

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50392 --- Comment #7 from Vittorio Zecca --- Still in gfortran 4.8.1. In trans-stmt.c:105 " len = GFC_DECL_STRING_LEN (se.expr);" the pointer se.expr->decl_common.lang_specific is NULL. Thus causing the segmentation fault.

[Bug fortran/57843] [OOP] Type-bound assignment is resolved to non-polymorphic procedure call

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57843 janus at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|---

[Bug c/58236] -Wuninitialized doesn't report uninitialised variable as expected

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58236 --- Comment #1 from Marc Glisse --- Note, from the documentation of -Wuninitialized: "Because these warnings depend on optimization, the exact variables or elements for which there are warnings depends on the precise optimization options and vers