[Bug target/57989] New: gcc for ARM defines __ARM_FEATURE_SIMD32, but does provide SIMD32 (ARMv6) intrinsics

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57989 Bug ID: 57989 Summary: gcc for ARM defines __ARM_FEATURE_SIMD32, but does provide SIMD32 (ARMv6) intrinsics Product: gcc Version: 4.8.0 Status: UNCONFIRMED Sever

[Bug c++/56014] [C++1y] ICE using return type deduction for member functions with -g enabled

Goller --- It also exists in a 4.9.0 snapshot from yesterday (20130725, built from the master branch).

[Bug target/57954] AVX missing vxorps (zeroing) before vcvtsi2s %edx, slow down AVX code

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57954 H.J. Lu changed: What|Removed |Added CC||dushistov at mail dot ru --- Comment #1 from H.

[Bug target/57988] missed optimization vxorpd before vcvtsi2sdq

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57988 H.J. Lu changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|---

[Bug target/57988] New: missed optimization vxorpd before vcvtsi2sdq

: target Assignee: unassigned at gcc dot gnu.org Reporter: dushistov at mail dot ru I tested such simple function on i7-3740QM CPU @ 2.70GHz, with gcc 4.8.1 and gcc 4.9.0 20130725: double pi(unsigned int count) { unsigned int i; double p = 0; double z = 1

[Bug fortran/57530] [OOP] Wrongly rejects type_pointer => class_target (which have identical declared type)

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57530 --- Comment #5 from Tobias Burnus --- Resolution patch (approved but not yet committed): http://gcc.gnu.org/ml/fortran/2013-06/msg00049.html trans*.c patch for TYPE => CLASS (submitted): http://gcc.gnu.org/ml/fortran/2013-07/msg00086.html

[Bug fortran/57966] [OOP] Using a TBP to specify the shape of a dummy argument

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

[Bug target/38836] Documentation for x86 builtins is outdated

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38836 Uroš Bizjak changed: What|Removed |Added Target||x86 Status|UNCONFIRMED

[Bug middle-end/57974] std::pow(std::complex(0),1) returns (-nan,-nan)

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57974 Paolo Carlini changed: What|Removed |Added CC|paolo.carlini at oracle dot com| --- Comment #13 from Paolo Carlin

[Bug c++/57880] cp/parser.c: 6 * missing break ?

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57880 --- Comment #13 from Paolo Carlini --- I added c++/57880 to the svn CL. Sorry, I'm not going to reference by hand each and every patch I commit (svn should do it automatically, send a message to Bugzilla, as it used to).

[Bug c++/57880] cp/parser.c: 6 * missing break ?

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57880 --- Comment #12 from David Binderman --- (In reply to Paolo Carlini from comment #11) > Fixed for 4.9.0. Good news. Worth referencing the patch that fixed it ?

[Bug middle-end/57974] std::pow(std::complex(0),1) returns (-nan,-nan)

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57974 --- Comment #12 from Paolo Carlini --- Agreed, let's do it.

[Bug middle-end/57974] std::pow(std::complex(0),1) returns (-nan,-nan)

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57974 --- Comment #11 from Gabriel Dos Reis --- (In reply to Paolo Carlini from comment #10) > Gaby, do you have an opinion on this? Irrespective of the long double issue, > do you want me to re-enable (contra LWG 844) the pow(const complex<>&, int) > o

[Bug middle-end/57974] std::pow(std::complex(0),1) returns (-nan,-nan)

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57974 Paolo Carlini changed: What|Removed |Added CC||gdr at gcc dot gnu.org --- Comment #10 fr

[Bug fortran/57987] New: Fortran finalizers considered extern-inline by middle-end

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57987 Bug ID: 57987 Summary: Fortran finalizers considered extern-inline by middle-end Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: normal Prior

[Bug middle-end/56382] FAIL: gcc.c-torture/compile/pr55921.c (internal compiler error)

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56382 John David Anglin changed: What|Removed |Added Attachment #29485|0 |1 is obsolete|

[Bug tree-optimization/55334] [4.8/4.9 Regression] mgrid regression (ipa-cp disables vectorization)

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55334 --- Comment #34 from Jan Hubicka --- > I can confirm that one call of resid now gets inlined on the branch > even on x86_64 (I'm confused why, the dump seems to suggest all call > sites would violate param max-inline-insns-auto limit but then one

[Bug middle-end/56382] FAIL: gcc.c-torture/compile/pr55921.c (internal compiler error)

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56382 --- Comment #2 from John David Anglin --- Executing on host: /mnt/gnu/gcc/objdir-test/gcc/xgcc -B/mnt/gnu/gcc/objdir-test/ gcc/ -fno-diagnostics-show-caret -O0 -w -c -o pr55921.o /mnt/gnu/gcc/gcc/gc c/testsuite/gcc.c-torture/compile/pr55921.c

[Bug middle-end/57974] std::pow(std::complex(0),1) returns (-nan,-nan)

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57974 --- Comment #9 from Paolo Carlini --- Or maybe should be made a little weaker / safer? Are you 100% sure we are beating performancewise clang and icc on this?

[Bug middle-end/57974] std::pow(std::complex(0),1) returns (-nan,-nan)

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57974 --- Comment #8 from Uroš Bizjak --- (In reply to Paolo Carlini from comment #7) > However it's still not clear to me why this inconsistency doesn't happen > with clang or icc, for example. I'm not convinced we are doing our job in > the best way a

[Bug c++/57986] call to local "bind" template function called std::bind without "using" any namespace.

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57986 --- Comment #9 from yangzhe1990 at gmail dot com --- > is probably including Yes, you are right. is not including . > Make the type non-copyable, and if you need to pass it around then use > shared_ptr Thanks. Anyway there seems no way to do

[Bug middle-end/57974] std::pow(std::complex(0),1) returns (-nan,-nan)

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57974 Paolo Carlini changed: What|Removed |Added CC||paolo.carlini at oracle dot com --- Comme

[Bug c++/57986] call to local "bind" template function called std::bind without "using" any namespace.

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57986 --- Comment #7 from yangzhe1990 at gmail dot com --- Thanks. Now only one question left. Why removing could disable the ADL? BTW, in c++03, to avoid the const_cast, is writing a shared_ptr the right choice?

[Bug c++/57986] call to local "bind" template function called std::bind without "using" any namespace.

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57986 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|---

[Bug middle-end/57974] std::pow(std::complex(0),1) returns (-nan,-nan)

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57974 --- Comment #6 from Uroš Bizjak --- (In reply to Paolo Carlini from comment #5) > But isn't this a bug? I mean, naively, what do we gain from the optimization > point of view from not evaluating as 0 in any case? And why it happens only > for long

[Bug middle-end/57974] std::pow(std::complex(0),1) returns (-nan,-nan)

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57974 --- Comment #5 from Paolo Carlini --- But isn't this a bug? I mean, naively, what do we gain from the optimization point of view from not evaluating as 0 in any case? And why it happens only for long double?

[Bug middle-end/57974] std::pow(std::complex(0),1) returns (-nan,-nan)

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57974 --- Comment #4 from Uroš Bizjak --- (In reply to Paolo Carlini from comment #3) > I suspect the back end could be also involved because it happens only for > long double and I didn't see anything special for long double in builtins.c -funsafe-ma

[Bug c/57983] cmakefiles/opencv_perf_gpu.dir

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57983 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed|

[Bug middle-end/57974] std::pow(std::complex(0),1) returns (-nan,-nan)

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57974 Paolo Carlini changed: What|Removed |Added CC||uros at gcc dot gnu.org --- Comment #3 fr

[Bug c++/57981] [4.8/4.9 Regression] ICE in this code

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57981 Paolo Carlini changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|---

[Bug c++/57986] call to local "bind" template function called std::bind without "using" any namespace.

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57986 --- Comment #5 from Jonathan Wakely --- thread(const thread &X) { swap(const_cast(X)); } This is insane, don't do that.

[Bug c++/57880] cp/parser.c: 6 * missing break ?

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57880 Paolo Carlini changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|---

[Bug c++/57986] call to local "bind" template function called std::bind without "using" any namespace.

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57986 --- Comment #6 from Jonathan Wakely --- class vector_iterator_asdf : public std::iterator { vector_iterator_asdf has a base class defined in namespace std, therefore that is an associated namespace and so an unqualified call to bind()

[Bug c++/57986] call to local "bind" template function called std::bind without "using" any namespace.

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57986 --- Comment #4 from Jonathan Wakely --- (In reply to yangzhe1990 from comment #0) > Then interesting thing > happens: If I omit a parameter to the bind function, the compiling error > message shows that std::bind was called instead of telling me i

[Bug c++/57986] call to local "bind" template function called std::bind without "using" any namespace.

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57986 --- Comment #3 from yangzhe1990 at gmail dot com --- Created attachment 30554 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30554&action=edit main program

[Bug c++/57986] call to local "bind" template function called std::bind without "using" any namespace.

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57986 --- Comment #2 from yangzhe1990 at gmail dot com --- Created attachment 30553 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30553&action=edit vector_iterator_asdf and computation functions

[Bug c++/57986] call to local "bind" template function called std::bind without "using" any namespace.

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57986 --- Comment #1 from yangzhe1990 at gmail dot com --- Created attachment 30552 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30552&action=edit thread

[Bug c++/57986] New: call to local "bind" template function called std::bind without "using" any namespace.

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57986 Bug ID: 57986 Summary: call to local "bind" template function called std::bind without "using" any namespace. Product: gcc Version: 4.8.1 Status: UNCONFIRMED Sev

[Bug c++/57977] zero-length const array in union prohibits default copy xtor

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57977 --- Comment #3 from Daniel Santos --- Hmm, I guess it's actually the copy assignment operator. Either way, it makes sense if the const union member was "real", in this case, the copy assignment for this member would be a no-op (were we to copy it

[Bug c/57821] 'array is too large' error is missing when sizetype overflows

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57821 --- Comment #9 from dave.anglin at bell dot net --- On 25-Jul-13, at 6:56 AM, amylaar at gcc dot gnu.org wrote: > hwint.h says that HOST_WIDE_INT should be 64 bit when targeting a > machine with > 64 bit size_t. You can insure that by setting n

[Bug c++/57977] zero-length const array in union prohibits default copy xtor

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57977 --- Comment #2 from Daniel Santos --- Don't you mean the part which prohibits its creation?

[Bug rtl-optimization/57967] [4.7 regresssion] Incorrect code generated on ARM with -fexpensive-optimizations

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57967 --- Comment #4 from Mikael Pettersson --- I can reproduce the wrong-code with gcc-4.7.3 on armv5tel-linux-gnueabi. The wrong-code disappeared on 4.7 branch with the recent PR57829 fix in r200773. On trunk the wrong-code disappeared with r186147,

[Bug fortran/57966] [OOP] Using a TBP to specify the shape of a dummy argument

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57966 --- Comment #8 from janus at gcc dot gnu.org --- (In reply to janus from comment #7) > Regtesting now ... Completed successfully!

[Bug c/57821] 'array is too large' error is missing when sizetype overflows

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57821 --- Comment #8 from dave.anglin at bell dot net --- On 25-Jul-13, at 12:51 AM, jasonwucj at gmail dot com wrote: > John, does your case happen on 32-bit only as well? Yes. -- John David Anglindave.ang...@bell.net

[Bug other/57985] New: ICE in cgraph_function_node with -fprofile-arcs -O2

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57985 Bug ID: 57985 Summary: ICE in cgraph_function_node with -fprofile-arcs -O2 Product: gcc Version: 4.8.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component

[Bug fortran/57966] [OOP] Using a TBP to specify the shape of a dummy argument

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57966 --- Comment #7 from janus at gcc dot gnu.org --- The following patch fixes both variants (comment 1 and comment 5): Index: gcc/fortran/resolve.c === --- gcc/fortran/resolve.c(rev

[Bug fortran/57978] f951: internal compiler error: Segmentation fault

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57978 --- Comment #10 from Karin Nyström --- Thanks for looking into this so quickly, will upgrading gcc and following that feature request.

[Bug fortran/44672] [F2008] ALLOCATE with SOURCE and no array-spec

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44672 --- Comment #4 from Tobias Burnus --- (In reply to Dominique d'Humieres from comment #1) > Duplicate of pr45440? It's related but not a duplicate. (Some items in the comments of the PR might be.) However, PR44529 and PR57978 are duplicates. (And

[Bug fortran/44529] [F03] array allocation with SOURCE

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44529 Tobias Burnus changed: What|Removed |Added Status|NEW |RESOLVED CC|

[Bug fortran/44672] [F2008] ALLOCATE with SOURCE and no array-spec

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44672 --- Comment #3 from Tobias Burnus --- *** Bug 44529 has been marked as a duplicate of this bug. ***

[Bug fortran/57978] f951: internal compiler error: Segmentation fault

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57978 Tobias Burnus changed: What|Removed |Added Status|NEW |RESOLVED Resolution|---

[Bug fortran/57978] f951: internal compiler error: Segmentation fault

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57978 --- Comment #8 from Karin Nyström --- NO_DAY is an array

[Bug fortran/57978] f951: internal compiler error: Segmentation fault

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57978 --- Comment #7 from Tobias Burnus --- (In reply to Joost VandeVondele from comment #6) > for 4.8 gives a segfault Which has seemingly be fixed in GCC 4.9. > for 4.9 reports: > allocate (diffdays, source=NO_DAY) > 1

[Bug fortran/57978] f951: internal compiler error: Segmentation fault

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57978 --- Comment #6 from Joost VandeVondele --- Reduced testcase: subroutine Change_calendar (ts_arr, target_calendar) integer, dimension(1) :: NO_DAY = (/ 0 /), ONE_DAY = (/ 180 /) integer, allocatable :: diffdays(:), diffdays_leap(:)

[Bug fortran/57978] f951: internal compiler error: Segmentation fault

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57978 --- Comment #5 from Karin Nyström --- Created attachment 30551 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30551&action=edit logini.inc logini.inc is normally created by the makefile which is why I forgot that one as well >.< Here it is.

[Bug fortran/57978] f951: internal compiler error: Segmentation fault

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57978 Joost VandeVondele changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed|

[Bug fortran/57978] f951: internal compiler error: Segmentation fault

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57978 Joost VandeVondele changed: What|Removed |Added CC||Joost.VandeVondele at mat dot ethz

[Bug c/57821] 'array is too large' error is missing when sizetype overflows

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57821 --- Comment #7 from Jorn Wolfgang Rennecke --- (In reply to Chung-Ju Wu from comment #6) > Check gcc test summary, it shows that the problem only appears on 32-bit > host. That's because of the different size of HOST_WIDE_INT. FWIW, you can als

[Bug libstdc++/57984] "terminate called after throwing an instance of 'std::regex_error' what(): regex_error" during regex object construction

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57984 Paolo Carlini changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC|

[Bug libstdc++/53631] [C++11] is unimplemented

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53631 Paolo Carlini changed: What|Removed |Added CC||snypxy at yandex dot com --- Comment #15

[Bug c++/57984] New: "terminate called after throwing an instance of 'std::regex_error' what(): regex_error" during regex object construction

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57984 Bug ID: 57984 Summary: "terminate called after throwing an instance of 'std::regex_error' what(): regex_error" during regex object construction Product: gcc Ver

[Bug c/57983] New: cmakefiles/opencv_perf_gpu.dir

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57983 Bug ID: 57983 Summary: cmakefiles/opencv_perf_gpu.dir Product: gcc Version: 4.6.3 Status: UNCONFIRMED Severity: blocker Priority: P3 Component: c Assign

[Bug fortran/57978] f951: internal compiler error: Segmentation fault

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57978 --- Comment #2 from Karin Nyström --- Created attachment 30550 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30550&action=edit Parameters.f90 (missing in archive) Sorry about that. All dependencies should be there now.

[Bug c++/57981] gcc 4.8 is the ICE in this code

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57981 Paolo Carlini changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed|

[Bug fortran/57966] [OOP] Using a TBP to specify the shape of a dummy argument

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57966 --- Comment #6 from Tobias Burnus --- (In reply to janus from comment #5) > However, it ICEs on the following variant (which involves a GENERIC TBP): That test case compile with NAG f95 v5.1 (of 2007!) and with a pretty new Cray ftn (version 8.1.

[Bug c++/57979] G++ accepts constant expression defined using floating point non-constexpr glvalue

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57979 --- Comment #2 from Johannes Goller --- Confirmed that the problem exists in the most recent version of GCC 4.9, i.e. a 20130725 snapshot from the master branch.

[Bug c++/57981] gcc 4.8 is the ICE in this code

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57981 --- Comment #2 from Yuhki Ogasawara --- I'm sorry. I mistook in previous comment. >compile: > >$ g++ -std=c++11 -Wall -Wextra -pedantic a.cpp compile (correct) and messages: $ g++ -std=c++11 -Wall -Wextra -pedantic a.cpp ' Internal compiler e

[Bug fortran/57966] [OOP] Using a TBP to specify the shape of a dummy argument

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57966 --- Comment #5 from janus at gcc dot gnu.org --- (In reply to janus from comment #3) > (In reply to janus from comment #2) > > Draft patch (not regtested yet): > > Seems to survive the regtest without any failures However, it ICEs on the followin

[Bug c/57980] gcc 4.8.1 -foptimize-sibling-calls -O1 ICE in build_int_cst_wide, at tree.c:1210

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57980 Marc Glisse changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed|

[Bug libgcc/57982] New: GetModuleHandle in __register_frame_info causes abort on unload

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57982 Bug ID: 57982 Summary: GetModuleHandle in __register_frame_info causes abort on unload Product: gcc Version: 4.7.3 Status: UNCONFIRMED Severity: major

[Bug c++/57981] gcc 4.8 is the ICE in this code

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57981 Yuhki Ogasawara changed: What|Removed |Added Summary|[ICE} |gcc 4.8 is the ICE in this

[Bug c++/57981] New: [ICE}

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57981 Bug ID: 57981 Summary: [ICE} Product: gcc Version: 4.8.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc do

[Bug fortran/57639] [OOP] ICE with polymorphism (and illegal code)

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

[Bug fortran/57978] f951: internal compiler error: Segmentation fault

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57978 Tobias Burnus changed: What|Removed |Added CC||burnus at gcc dot gnu.org --- Comment #1

[Bug libstdc++/51965] Redundant move constructions in heap algorithms

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51965 Jonathan Wakely changed: What|Removed |Added Target Milestone|--- |4.9.0

[Bug c++/56427] [C++11] template template parameter template parameter pack that depends on another parameter pack

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56427 Marek Polacek changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed|

[Bug c/57980] New: gcc 4.8.1 -foptimize-sibling-calls -O1 ICE in build_int_cst_wide, at tree.c:1210

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57980 Bug ID: 57980 Summary: gcc 4.8.1 -foptimize-sibling-calls -O1 ICE in build_int_cst_wide, at tree.c:1210 Product: gcc Version: 4.8.1 Status: UNCONFIRMED Severity:

[Bug c++/57979] G++ accepts constant expression defined using floating point non-constexpr glvalue

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57979 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed|

[Bug c++/57979] New: G++ accepts constant expression defined using floating point glvalue

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57979 Bug ID: 57979 Summary: G++ accepts constant expression defined using floating point glvalue Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: normal

[Bug fortran/57978] New: f951: internal compiler error: Segmentation fault

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57978 Bug ID: 57978 Summary: f951: internal compiler error: Segmentation fault Product: gcc Version: 4.8.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: