[Bug fortran/61632] memory corruption in Fortran RTL when writing formatted data
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61632 --- Comment #5 from Dominique d'Humieres dominiq at lps dot ens.fr --- With the patch in comment 4, the caret is shifted one character to the left and there are some missing characters in the format string. This causes the failure of the tests gfortran.dg/fmt_error_4.f90 and gfortran.dg/fmt_error_5.f90 Fortran runtime error: Unexpected element 'Q' in format Q, A) - with patch ^ (A, Q, A) - unpatched ^ Fortran runtime error: Unexpected element 'Q' in format Q) - with patch ^ (Q) - unpatched ^
[Bug libstdc++/61791] New: [C++11] [constexpr] Additional overloads of std::real should be a constexpr function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61791
Bug ID: 61791
Summary: [C++11] [constexpr] Additional overloads of std::real
should be a constexpr function
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: kariya_mitsuru at hotmail dot com
I think that the sample code below should be compiled successfully.
===
#include complex
static constexpr double d = std::real(10);
int main() {}
===
Note that it is compiled successfully if the argument is
std::complexdouble(10) instead of 10.
According to C++11 standard 26.4.9[cmplx.over] paragraph 2, if either argument
has type complexdouble, double, or an integer type, then both arguments are
effectively cast to complexdouble.
Therefore, I think it should be compiled successfully too.
[Bug c++/51312] [C++0x] Wrong interpretation of converted constant expressions (for enumerator initializers)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51312 --- Comment #7 from Paolo Carlini paolo.carlini at oracle dot com --- Uhm, it occurs to me that we may also play with moving up the code we already have a few line below handling ENUM_UNDERLYING_TYPE (enumtype): if convert is called first on the X() in e = X() we get a CALL_EXPR from a TARGET_EXPR, which then cxx_constant_value is able to handle...
[Bug libstdc++/61791] [C++11] [constexpr] Additional overloads of std::real should be a constexpr function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61791 --- Comment #1 from Mitsuru Kariya kariya_mitsuru at hotmail dot com --- Sorry, the text which should be quoted was mistaken. According to C++11 standard 26.4.9[cmplx.over] paragraph 2, if either argument has type complexdouble, double, or an integer type, then both arguments are effectively cast to complexdouble. According to C++11 standard 26.4.9[cmplx.over] paragraph 2, if the argument has type double or an integer type, then it is effectively cast to complexdouble.
[Bug c++/51312] [C++0x] Wrong interpretation of converted constant expressions (for enumerator initializers)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51312 --- Comment #8 from Paolo Carlini paolo.carlini at oracle dot com --- ... but then value isn't yet an INTEGER_CST and we can't use int_fits_type_p... Still, something seems redundant between an early conversion and the final convert.
[Bug c++/60628] [4.7/4.8 Regression] [c++11] ICE initializing array of auto
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60628 --- Comment #5 from Paolo Carlini paolo.carlini at oracle dot com --- *** Bug 60629 has been marked as a duplicate of this bug. ***
[Bug c++/60629] [c++11] ICE initializing array of function pointers with auto
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60629 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE Known to fail|4.9.0 | --- Comment #2 from Paolo Carlini paolo.carlini at oracle dot com --- This is invalid, already fixed in the released 4.9.0. *** This bug has been marked as a duplicate of bug 60628 ***
[Bug bootstrap/60830] [4.9 Regression] ICE on bootstrapping on cygwin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60830 --- Comment #50 from Denis Excoffier g...@denis-excoffier.org --- gcc-4.9.1-RC-20140710 bootstraps perfectly. Thank you.
[Bug bootstrap/61792] New: [4.10 Regression] Bootstrap error with undeclared function isl_ast_expr_get_val
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61792 Bug ID: 61792 Summary: [4.10 Regression] Bootstrap error with undeclared function isl_ast_expr_get_val Product: gcc Version: 4.10.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap Assignee: unassigned at gcc dot gnu.org Reporter: tkoenig at gcc dot gnu.org Created attachment 33115 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=33115action=edit config.log In revision 212492, bootstrap aborts with ../../trunk/gcc/graphite-isl-ast-to-gimple.c: In Funktion »tree_node* gcc_expression_from_isl_expr_int(tree, isl_ast_expr*)«: ../../trunk/gcc/graphite-isl-ast-to-gimple.c:143:44: Fehler: »isl_ast_expr_get_val« wurde in diesem Gültigkeitsbereich nicht definiert isl_val *val = isl_ast_expr_get_val (expr); ^ ../../trunk/gcc/graphite-isl-ast-to-gimple.c: In Funktion »isl_ast_expr* get_upper_bound(isl_ast_node*)«: ../../trunk/gcc/graphite-isl-ast-to-gimple.c:465:63: Fehler: »isl_ast_expr_from_val« wurde in diesem Gültigkeitsbereich nicht definiert res = isl_ast_expr_sub (ub, isl_ast_expr_from_val (one)); ^ make[3]: *** [graphite-isl-ast-to-gimple.o] Fehler 1 make[3]: *** Warte auf noch nicht beendete Prozesse... rm gcov-tool.pod cpp.pod gfdl.pod gcc.pod gcov.pod fsf-funding.pod make[3]: Leaving directory `/home/ig25/Gcc/trunk-bin/gcc' make[2]: *** [all-stage1-gcc] Fehler 2 make[2]: Leaving directory `/home/ig25/Gcc/trunk-bin' make[1]: *** [stage1-bubble] Fehler 2 make[1]: Leaving directory `/home/ig25/Gcc/trunk-bin' make: *** [all] Fehler 2 Configuration was done with ../trunk/configure --with-isl=$HOME --prefix=$HOME --enable-languages=c,fortran,c++,lto make -j6 make install The version of ISL was the one that is advertised on the gcc web site, 0.12.2.
[Bug bootstrap/61792] [4.10 Regression] Bootstrap error with undeclared function isl_ast_expr_get_val
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61792 Thomas Koenig tkoenig at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |4.10.0
[Bug bootstrap/61792] [4.10 Regression] Bootstrap error with undeclared function isl_ast_expr_get_val
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61792 --- Comment #1 from Andreas Schwab sch...@linux-m68k.org --- Looks like it doesn't use/prefer the configured ISL headers. Unfortunately you left out the actual compiler command lines.
[Bug fortran/60898] model compile error with gfortran 4.7 and gcc 4.9 on Mac OS 10.9
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60898 --- Comment #7 from Dominique d'Humieres dominiq at lps dot ens.fr --- Created attachment 33116 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=33116action=edit Reduced test case This is the smallest test I can get to gives an ICE plib8b-1_red.f90: In function 'master.3.mulbb': plib8b-1_red.f90:96:0: internal compiler error: Segmentation fault: 11 END SUBROUTINE mulvb ^ plib8b-1_red.f90:96:0: internal compiler error: Abort trap: 6 gfc: internal compiler error: Abort trap: 6 (program f951) Abort
[Bug fortran/61780] [4.8/4.9/4.10 Regression] Wrong code when shifting elements of a multidimensional array
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61780 --- Comment #5 from Mikael Morin mikael at gcc dot gnu.org --- (In reply to paul.richard.tho...@gmail.com from comment #3) Dear Mikael, I didn't see your posting, which was about an hour before mine. At least we came to the same conclusion! Yes, that's good. :-) Thanks for the fix.
[Bug fortran/60898] model compile error with gfortran 4.7 and gcc 4.9 on Mac OS 10.9
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60898 --- Comment #8 from Dominique d'Humieres dominiq at lps dot ens.fr --- Backtrace for the reduced test case * thread #1: tid = 0x1357c7a, 0x0001000afb00 f951`count_st_nodes(st=unavailable) + 16 at symbol.c:3580, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=1, address=0x9) frame #0: 0x0001000afb00 f951`count_st_nodes(st=unavailable) + 16 at symbol.c:3580 3577 if (!st) 3578return 0; 3579 - 3580 nodes = count_st_nodes (st-left); 3581 nodes++; 3582 nodes += count_st_nodes (st-right); 3583 (lldb) bt * thread #1: tid = 0x1357c7a, 0x0001000afb00 f951`count_st_nodes(st=unavailable) + 16 at symbol.c:3580, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=1, address=0x9) * frame #0: 0x0001000afb00 f951`count_st_nodes(st=unavailable) + 16 at symbol.c:3580 frame #1: 0x0001000afb09 f951`count_st_nodes(st=unavailable) + 25 at symbol.c:3580 frame #2: 0x0001000afb09 f951`count_st_nodes(st=unavailable) + 25 at symbol.c:3580 frame #3: 0x0001000afb09 f951`count_st_nodes(st=unavailable) + 25 at symbol.c:3580 frame #4: 0x0001000afb09 f951`count_st_nodes(st=unavailable) + 25 at symbol.c:3580 frame #5: 0x0001000afb09 f951`count_st_nodes(st=unavailable) + 25 at symbol.c:3580 frame #6: 0x0001000afb09 f951`count_st_nodes(st=unavailable) + 25 at symbol.c:3580 frame #7: 0x0001000afb09 f951`count_st_nodes(st=unavailable) + 25 at symbol.c:3580 frame #8: 0x0001000b1a61 f951`do_traverse_symtree(st=unavailable, st_func=0x, sym_func=0x0001000f6040) + 49 at symbol.c:3617 frame #9: 0x0001000f7255 f951`gfc_generate_function_code(ns=0x000142052e00) + 373 at trans-decl.c:5126 frame #10: 0x0001000cb9b2 f951`gfc_generate_module_code(ns=unavailable) + 466 at trans.c:1998 frame #11: 0x0001000817c3 f951`gfc_parse_file() + 167 at parse.c:4934 frame #12: 0x00010008171c f951`gfc_parse_file() + 1116 frame #13: 0x0001000c4c56 f951`gfc_be_parse_file + 38 at f95-lang.c:212 frame #14: 0x0001008ba397 f951`compile_file + 39 at toplev.c:548 frame #15: 0x0001008bcbbf f951`toplev_main(argc=2, argv=0x7fff5fbff440) + 3327 at toplev.c:1946
[Bug libstdc++/61791] [C++11] [constexpr] Additional overloads of std::real should be a constexpr function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61791 Daniel Krügler daniel.kruegler at googlemail dot com changed: What|Removed |Added CC||daniel.kruegler@googlemail. ||com --- Comment #2 from Daniel Krügler daniel.kruegler at googlemail dot com --- The problem still exists in gcc trunk version 4.10.0 20140707 (experimental)
[Bug c++/60967] ICE with range for in template function with C++11 and cilkplus
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60967 --- Comment #2 from Paolo Carlini paolo.carlini at oracle dot com --- I'm adding the testcase and closing the bug.
[Bug c++/60967] ICE with range for in template function with C++11 and cilkplus
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60967 --- Comment #3 from paolo at gcc dot gnu.org paolo at gcc dot gnu.org --- Author: paolo Date: Sun Jul 13 13:24:18 2014 New Revision: 212493 URL: https://gcc.gnu.org/viewcvs?rev=212493root=gccview=rev Log: 2014-07-13 Paolo Carlini paolo.carl...@oracle.com PR c++/60967 * g++.dg/cilk-plus/pr60967.C: New. Added: trunk/gcc/testsuite/g++.dg/cilk-plus/pr60967.C Modified: trunk/gcc/testsuite/ChangeLog
[Bug c++/60967] ICE with range for in template function with C++11 and cilkplus
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60967 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC|florent.hivert at lri dot fr | Resolution|--- |FIXED Target Milestone|--- |4.9.0 --- Comment #4 from Paolo Carlini paolo.carlini at oracle dot com --- Done.
[Bug regression/61793] New: regression: bootstrapping fails on x86_64-linux-gnu after r212352
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61793 Bug ID: 61793 Summary: regression: bootstrapping fails on x86_64-linux-gnu after r212352 Product: gcc Version: 4.10.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: regression Assignee: unassigned at gcc dot gnu.org Reporter: kikairoya at gmail dot com bootstrapping SVN trunk r212352 fails on Linux x86_64 (using github's git mirror.) r212490 still fails. $ uname -a Linux vmarch-ubuntu 3.15.5-1-ARCH #1 SMP PREEMPT Thu Jul 10 07:08:50 CEST 2014 x86_64 x86_64 x86_64 GNU/Linux $ gcc -v Using built-in specs. COLLECT_GCC=gcc COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/4.6/lto-wrapper Target: x86_64-linux-gnu Configured with: ../src/configure -v --with-pkgversion='Ubuntu/Linaro 4.6.3-1ubuntu5' --with-bugurl=file:///usr/share/doc/gcc-4.6/README.Bugs --enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr --program-suffix=-4.6 --enable-shared --enable-linker-build-id --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --with-gxx-include-dir=/usr/include/c++/4.6 --libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --enable-gnu-unique-object --enable-plugin --enable-objc-gc --disable-werror --with-arch-32=i686 --with-tune=generic --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu Thread model: posix gcc version 4.6.3 (Ubuntu/Linaro 4.6.3-1ubuntu5) $ git log -1 commit 3beff0e12fe55eece14fed410c5e5b66bda90833 Author: rguenth rguenth@138bc75d-0d04-0410-961f-82ee72b054a4 Date: Tue Jul 8 09:22:54 2014 + 2014-07-08 Richard Biener rguent...@suse.de * tree-ssa-dom.h (loop_depth_of_name): Remove. * tree-ssa-dom.c (record_equivalences_from_phis): Remove restriction on loop depth difference. (record_equality): Likewise. (propagate_rhs_into_lhs): Likewise. Simplify condition. (loop_depth_of_name): Remove. * tree-ssa-copy.c (copy_prop_visit_phi_node): Remove restriction on loop depth difference. (init_copy_prop): Likewise. * gcc.dg/tree-ssa/ssa-pre-16.c: Adjust expected eliminations. git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@212352 138bc75d-0d04-0410-961f-82ee72b054a4 $ rm -rf ../build mkdir -p ../build cd ../build $ ../gcc/configure --enable-languages=c --disable-multilib --without-ppl --without-cloog-ppl --enable-checking=release --disable-nls ** snip ** $ make ** snip ** make[3]: Entering directory `/home/kikairoya/tmp/build/gcc' build/genmddeps ../../gcc/gcc/common.md ../../gcc/gcc/config/i386/i386.md tmp-mddeps /bin/bash ../../gcc/gcc/../move-if-change tmp-mddeps mddeps.mk echo timestamp s-mddeps build/genmodes -h tmp-modes.h build/genmodes: config/i386/i386-modes.def:25: (TF) field format must not be set build/genmodes: config/i386/i386-modes.def:24: (XF) field format must not be set build/genmodes: machmode.def:203: (DF) field format must not be set build/genmodes: machmode.def:202: (SF) field format must not be set build/genmodes: machmode.def:244: (TD) field format must not be set build/genmodes: machmode.def:243: (DD) field format must not be set build/genmodes: machmode.def:242: (SD) field format must not be set make[3]: *** [s-modes-h] Error 1 make[3]: Leaving directory `/home/kikairoya/tmp/build/gcc' make[2]: *** [all-stage3-gcc] Error 2 make[2]: Leaving directory `/home/kikairoya/tmp/build' make[1]: *** [stage3-bubble] Error 2 make[1]: Leaving directory `/home/kikairoya/tmp/build' make: *** [all] Error 2
[Bug c++/61623] [4.10 Regression] ICE: verify_symtab failed: Two symbols with same comdat_group are not linked by the same_comdat_group list.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61623 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2014-07-13 Ever confirmed|0 |1 --- Comment #1 from Paolo Carlini paolo.carlini at oracle dot com --- Confirmed.
[Bug bootstrap/61792] [4.10 Regression] Bootstrap error with undeclared function isl_ast_expr_get_val
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61792 --- Comment #2 from Thomas Koenig tkoenig at gcc dot gnu.org --- Here is the command line: make[3]: Entering directory `/home/ig25/Gcc/trunk-bin/gcc' g++ -c -g -DIN_GCC-fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wno-format -Wmissing-format-attribute -Woverloaded-virtual -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -fno-common -DHAVE_CONFIG_H -I. -I. -I../../trunk/gcc -I../../trunk/gcc/. -I../../trunk/gcc/../include -I../../trunk/gcc/../libcpp/include -I../../trunk/gcc/../libdecnumber -I../../trunk/gcc/../libdecnumber/bid -I../libdecnumber -I../../trunk/gcc/../libbacktrace -DCLOOG_INT_GMP -I/home/ig25/include -o graphite-isl-ast-to-gimple.o -MT graphite-isl-ast-to-gimple.o -MMD -MP -MF ./.deps/graphite-isl-ast-to-gimple.TPo ../../trunk/gcc/graphite-isl-ast-to-gimple.c ../../trunk/gcc/graphite-isl-ast-to-gimple.c: In function 'tree_node* gcc_expression_from_isl_expr_int(tree, isl_ast_expr*)': ../../trunk/gcc/graphite-isl-ast-to-gimple.c:143:44: error: 'isl_ast_expr_get_val' was not declared in this scope isl_val *val = isl_ast_expr_get_val (expr); ^ ../../trunk/gcc/graphite-isl-ast-to-gimple.c: In function 'isl_ast_expr* get_upper_bound(isl_ast_node*)': ../../trunk/gcc/graphite-isl-ast-to-gimple.c:465:63: error: 'isl_ast_expr_from_val' was not declared in this scope res = isl_ast_expr_sub (ub, isl_ast_expr_from_val (one));
[Bug c++/60209] Declaration of user-defined literal operator cause error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60209 --- Comment #5 from emsr at gcc dot gnu.org --- Author: emsr Date: Sun Jul 13 13:36:57 2014 New Revision: 212494 URL: https://gcc.gnu.org/viewcvs?rev=212494root=gccview=rev Log: cp/ 2014-07-13 Edward Smith-Rowland 3dw...@verizon.net PR C++/60209 - Declaration of user-defined literal operator cause error * cp/parser.c (cp_parser_operator()): Fold treatment of strings and user-defined string literals. Use the full string parser. (cp_parser_string_literal()): Add flag to not look for literal operator. testsuite/ 2014-07-13 Edward Smith-Rowland 3dw...@verizon.net PR C++/60209 - Declaration of user-defined literal operator cause error * g++.dg/cpp0x/pr60209-neg.C: New. * g++.dg/cpp0x/pr60209.C: New. * g++.dg/cpp1y/udlit-empty-string-neg.C: Adjust messages. Added: trunk/gcc/testsuite/g++.dg/cpp0x/pr60209-neg.C trunk/gcc/testsuite/g++.dg/cpp0x/pr60209.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/parser.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/g++.dg/cpp1y/udlit-empty-string-neg.C
[Bug regression/61793] regression: bootstrapping fails on x86_64-linux-gnu after r212352
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61793 Dominique d'Humieres dominiq at lps dot ens.fr changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #1 from Dominique d'Humieres dominiq at lps dot ens.fr --- Duplicate of pr61757. *** This bug has been marked as a duplicate of bug 61757 ***
[Bug tree-optimization/61757] [4.10 Regression] genmodes failure with enable-checking
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61757 Dominique d'Humieres dominiq at lps dot ens.fr changed: What|Removed |Added CC||kikairoya at gmail dot com --- Comment #20 from Dominique d'Humieres dominiq at lps dot ens.fr --- *** Bug 61793 has been marked as a duplicate of this bug. ***
[Bug c++/60209] Declaration of user-defined literal operator cause error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60209 emsr at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #6 from emsr at gcc dot gnu.org --- Fixed on trunk.
[Bug c++/61794] New: internal error: unrecognizable insn, from avx512 extract instruction
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61794 Bug ID: 61794 Summary: internal error: unrecognizable insn, from avx512 extract instruction Product: gcc Version: 4.10.0 Status: UNCONFIRMED Severity: major Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: agner at agner dot org Created attachment 33117 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=33117action=edit c++ file producing error The attached file bug1.cpp generates internal error when compiling: g++ -mavx512f bug1.cpp g++ version: 4.9 and 4.10.0 20140706 binutils version: 2.24 Ubuntu version: 12.04.2 LTS Error message: == a@a-desktop:~/avx512$ g++ -mavx512f bug1.cpp bug1.cpp: In member function ‘int32_t Vec16i::extract(uint32_t) const’: bug1.cpp:59:5: error: unrecognizable insn: } ^ (insn 29 28 30 8 (set (reg:V4SI 89 [ D.12727 ]) (vec_merge:V4SI (vec_select:V4SI (reg:V16SI 88 [ D.12726 ]) (parallel [ (const_int 0 [0]) (const_int 1 [0x1]) (const_int 2 [0x2]) (const_int 3 [0x3]) ])) (reg:V4SI 86 [ D.12724 ]) (reg:QI 113))) bug1.cpp:38 -1 (nil)) bug1.cpp:59:5: internal compiler error: in extract_insn, at recog.c:2204 0xb25c68 _fatal_insn(char const*, rtx_def const*, char const*, int, char const*) ../.././gcc/rtl-error.c:109 0xb25c99 _fatal_insn_not_found(rtx_def const*, char const*, int, char const*) ../.././gcc/rtl-error.c:117 0xaf609e extract_insn(rtx_def*) ../.././gcc/recog.c:2204 0x980803 instantiate_virtual_regs_in_insn ../.././gcc/function.c:1561 0x980803 instantiate_virtual_regs ../.././gcc/function.c:1932 0x980803 execute ../.././gcc/function.c:1983 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.
[Bug fortran/61615] Failure to resolve correct generic with TYPE(C_PTR) arguments
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61615 Harald Anlauf anlauf at gmx dot de changed: What|Removed |Added CC||anlauf at gmx dot de --- Comment #3 from Harald Anlauf anlauf at gmx dot de --- (In reply to Dominique d'Humieres from comment #2) I don't understand how the code in comment 0 can distinguish bar_s from bar_a1d based on the variable locations in memory, TKR, i.e. rank in the present case? nor why it chooses bar_a1d. Intel 14.2, NAG 5.3.2(951) and PGI 14.4-0 succeed with the original testcase.
[Bug fortran/61615] Failure to resolve correct generic with TYPE(C_PTR) arguments
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61615 --- Comment #4 from Dominique d'Humieres dominiq at lps dot ens.fr --- TKR, i.e. rank in the present case? Doesn't it assume that TKR is available trough C_LOC(i)?
[Bug fortran/61615] Failure to resolve correct generic with TYPE(C_PTR) arguments
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61615 --- Comment #5 from Harald Anlauf anlauf at gmx dot de --- (In reply to Dominique d'Humieres from comment #4) TKR, i.e. rank in the present case? Doesn't it assume that TKR is available trough C_LOC(i)? Well, my understanding is that TYPE(c_ptr) :: a, b are pointers (void*) and TYPE(c_ptr) :: a(:), b(:) are arrays of pointers (void**). But I am not the author of the original code. ;-)
[Bug c++/58636] [4.8/4.9/4.10 Regression] ICE with initializer_list and rvalue references
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58636 Jason Merrill jason at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2014-07-13 CC||jason at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |jason at gcc dot gnu.org Ever confirmed|0 |1
[Bug fortran/61615] Failure to resolve correct generic with TYPE(C_PTR) arguments
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61615
--- Comment #6 from Dominique d'Humieres dominiq at lps dot ens.fr ---
Well, my understanding is that
TYPE(c_ptr) :: a, b
are pointers (void*) and
TYPE(c_ptr) :: a(:), b(:)
are arrays of pointers (void**).
The result of -fdump-tree-original of
PROGRAM cptr_array_vs_scalar_arg
USE iso_c_binding
IMPLICIT NONE
INTEGER, TARGET :: i, j(5)
TYPE(c_ptr) :: a, b
a = C_LOC(i)
b = C_LOC(j)
END PROGRAM cptr_array_vs_scalar_arg
is
cptr_array_vs_scalar_arg ()
{
void * a;
void * b;
integer(kind=4) i;
integer(kind=4) j[5];
{
void * D.2336;
D.2336 = (void *) i;
a = D.2336;
}
{
void * D.2337;
D.2337 = (void *) j;
b = D.2337;
}
}
main (integer(kind=4) argc, character(kind=1) * * argv)
{
static integer(kind=4) options.0[9] = {68, 1023, 0, 0, 1, 1, 0, 0, 31};
_gfortran_set_args (argc, argv);
_gfortran_set_options (9, options.0[0]);
cptr_array_vs_scalar_arg ();
return 0;
}
[Bug c++/58612] [4.8/4.9/4.10 Regression] [c++11] ICE calling non-constexpr from constexpr in template class
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58612 Jason Merrill jason at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2014-07-13 CC||jason at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |jason at gcc dot gnu.org Ever confirmed|0 |1
[Bug fortran/61632] memory corruption in Fortran RTL when writing formatted data
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61632 --- Comment #6 from Jerry DeLisle jvdelisle at gcc dot gnu.org --- yes, I need to adjust the offset and width calculation. Updated patch is in the works.
[Bug tree-optimization/61757] [4.10 Regression] genmodes failure with enable-checking
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61757 Segher Boessenkool segher at gcc dot gnu.org changed: What|Removed |Added CC||segher at gcc dot gnu.org --- Comment #21 from Segher Boessenkool segher at gcc dot gnu.org --- (In reply to Pat Haugen from comment #19) So in the case where MIN_INT32 is passed (sign extended), the upper 32 bits are '1' so r212352 returns a value of 63 whereas prior revisions returned a value of 31. When called with r3=8000 the new code returns -1 as far as I can see? And it should be called with 8000 instead; does the caller not have a prototype in scope?
[Bug c++/58611] [4.8/4.9/4.10 Regression] [c++11] ICE with invalid constexpr constructor used in array initialization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58611 Jason Merrill jason at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED CC||jason at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |jason at gcc dot gnu.org
[Bug libstdc++/61795] New: [C++11] return type of std::pow(std::complexfloat, int) should be std::complexdouble
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61795
Bug ID: 61795
Summary: [C++11] return type of std::pow(std::complexfloat,
int) should be std::complexdouble
Product: gcc
Version: 4.10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: kariya_mitsuru at hotmail dot com
With libstdc++, the return type of std::pow(std::complexfloat, int) is
std::complexfloat.
However, In C++11 mode, the return type of std::pow(std::complexfloat, int)
should be std::complexdouble.
According to C++11 standard 26.4.9[cmplx.over] paragraph 3, if either argument
has type complexdouble, double, or an integer type, then both arguments are
effectively cast to complexdouble.
The return type of std::pow(std::complexdouble, std::complexdouble) is
std::complexdouble, So I think that std::pow(std::complexfloat, int) should
be std::complexdouble in C++11 mode.
The sample code below can show whether the return type is std::complexdouble.
#include iostream
#include typeinfo
#include complex
int main()
{
std::cout std::boolalpha
(typeid(std::pow(std::complexfloat(1), 1)) ==
typeid(std::complexdouble))
std::endl;
}
cf. http://melpon.org/wandbox/permlink/zW8TWZe9kKzKWqFq
While in C++03 mode, the return type of std::pow(std::complexfloat, int)
should be std::complexfloat, I think.
Note that this problem does not occur in std::complexdouble and
std::complexlong double because there is no difference between C++03 and
C++11.
See also: PR56106, PR57974
[Bug bootstrap/61792] [4.10 Regression] Bootstrap error with undeclared function isl_ast_expr_get_val
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61792 Thomas Koenig tkoenig at gcc dot gnu.org changed: What|Removed |Added CC||romangareev at gcc dot gnu.org --- Comment #3 from Thomas Koenig tkoenig at gcc dot gnu.org --- Could be due to https://gcc.gnu.org/viewcvs?rev=212455root=gccview=rev .
[Bug libstdc++/61795] [C++11] return type of std::pow(std::complexfloat, int) should be std::complexdouble
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61795 Daniel Krügler daniel.kruegler at googlemail dot com changed: What|Removed |Added CC||daniel.kruegler@googlemail. ||com --- Comment #1 from Daniel Krügler daniel.kruegler at googlemail dot com --- I agree with your analysis. I believe that the observed behaviour is due to a lack of applying yet the corresponding library defect http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#844 to libstdc++, because in an earlier working draft there was the required overload: templateclass T complexT pow(const complexT x, int y); which had lead to the observed result.
[Bug fortran/61615] Failure to resolve correct generic with TYPE(C_PTR) arguments
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61615 --- Comment #7 from Harald Anlauf anlauf at gmx dot de --- (In reply to Dominique d'Humieres from comment #6) Well, the problem is in the resolution of the generic, not in the invocation in the main. If you comment out ! MODULE PROCEDURE bar_a1d you get the result desired by the author: in bar_s Now if you comment out the module procedure bar_s, gfortran does *not* complain, but resolve to the *wrong* procedure. So for some strange reason, gfortran fails to recognise the proper rank. OTOH, NAG complains: Error: pr61615.f90, line 28: No specific match for reference to generic BAR I get corresponding errors from PGI or Intel. IMO a bug in gfortran.
[Bug c++/60608] Template argument problem
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60608
Paolo Carlini paolo.carlini at oracle dot com changed:
What|Removed |Added
CC|volumedriverteam@cloudfound |
|ers.com |
--- Comment #2 from Paolo Carlini paolo.carlini at oracle dot com ---
Thus boils down to:
templatetypename... Args
void
wrapper(void (*f)(Args...), Args...);
void myfun(int);
void
test()
{
const int b = 0;
wrapperconst int(myfun, b);
}
where a non-variadic version is fine. Figuring out where the cv-qualifier is
treated differently in the two cases should be relatively easy...
[Bug other/61796] New: gcc arm hardfloat
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61796
Bug ID: 61796
Summary: gcc arm hardfloat
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: other
Assignee: unassigned at gcc dot gnu.org
Reporter: luka.perkov at sartura dot hr
When building crosscompile toolchain for arm with hardware floating point
support toolchain is built with software floating point or at least that seems
to be the case. The flags passed include:
-pipe -march=armv7-a -mtune=cortex-a9 -mfpu=neon -mfloat-abi=hard
I've noticed this behaviour while building eglibc. The relevant code for this
seems to be located in the following files:
gcc/config/arm/arm.h
gcc/config/arm/arm-opts.h
gcc/gcc/config/arm/arm.opt
Regardles of the -mfloat-abi=hard flag being passed the gcc ends up setting
__SOFTFP__ which is only set if -mfloat-abi=soft is passed. Command below shows
how I tested this:
$ arm-openwrt-linux-gnueabi-gcc -x c - -E -dM /dev/null 2/dev/null | fgrep
SOFT
#define __SOFTFP__ 1
The following hack seems to fix the problem:
--- a/gcc/config/arm/arm.opt
+++ b/gcc/config/arm/arm.opt
@@ -106,7 +106,7 @@ Target RejectNegative Joined Enum(proces
Specify the name of the target CPU
mfloat-abi=
-Target RejectNegative Joined Enum(float_abi_type) Var(arm_float_abi)
Init(TARGET_DEFAULT_FLOAT_ABI)
+Target RejectNegative Joined Enum(float_abi_type) Var(arm_float_abi)
Init(ARM_FLOAT_ABI_HARD)
Specify if floating point hardware should be used
Enum
Because of the check in eglibc (paste below) compilation fails because
__ARM_PCS_VFP is not set. The __ARM_PCS_VFP is only set if the hardware float
is used - and that should be the case, here is the relevant chunk from
gcc/config/arm/arm.c:
else if (arm_float_abi == ARM_FLOAT_ABI_HARD
TARGET_HARD_FLOAT
TARGET_VFP)
arm_pcs_default = ARM_PCS_AAPCS_VFP;
And the eglibc code refered to in the last section (libc/scripts/config.guess):
if echo __ARM_PCS_VFP | $CC_FOR_BUILD -E - 2/dev/null \
| grep -q __ARM_PCS_VFP
then
echo ${UNAME_MACHINE}-unknown-linux-${LIBC}eabi
else
echo ${UNAME_MACHINE}-unknown-linux-${LIBC}eabihf
fi
Even though I've managed to compile eglibc successfully and entire system
without issue I didn't manage to boot it. That might be a different problem but
I'd like to hear your opinion about this bug first.
Luka
[Bug gcov-profile/61790] [4.10 Regression] gcov-tool.c uses atoll
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61790 --- Comment #1 from dave.anglin at bell dot net --- On 12-Jul-14, at 8:47 PM, danglin at gcc dot gnu.org wrote: ../../gcc/gcc/gcov-tool.c:313:42: error: 'atoll' was not declared in this scope sscanf will work. Dave -- John David Anglindave.ang...@bell.net
[Bug c++/60608] Template argument problem
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60608
--- Comment #3 from Paolo Carlini paolo.carlini at oracle dot com ---
Slightly shorter:
templatetypename... Args
void
wrapper(void (*f)(Args...));
void myfun(int);
void
test()
{
wrapperconst int(myfun);
}
[Bug fortran/61632] memory corruption in Fortran RTL when writing formatted data
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61632 Jerry DeLisle jvdelisle at gcc dot gnu.org changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |jvdelisle at gcc dot gnu.org --- Comment #7 from Jerry DeLisle jvdelisle at gcc dot gnu.org --- Patch awaiting approval
[Bug fortran/60898] model compile error with gfortran 4.7 and gcc 4.9 on Mac OS 10.9
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60898 Jerry DeLisle jvdelisle at gcc dot gnu.org changed: What|Removed |Added Status|WAITING |NEW --- Comment #9 from Jerry DeLisle jvdelisle at gcc dot gnu.org --- Confirmed.
[Bug fortran/61632] memory corruption in Fortran RTL when writing formatted data
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61632
--- Comment #8 from Dominique d'Humieres dominiq at lps dot ens.fr ---
Sorry! There is still a glitch: the following code
program p
call ss()
call ss()
end program p
subroutine ss
CHARACTER(3), save :: ZTYP(3)
DATA ZTYP /'XXX','YYY','ZZZ'/
write(*,600) 0.0,ZTYP
600 FORMAT(1PE13.5,A3)
end subroutine ss
used to give the runtime error
0.0E+00XXX
At line 8 of file pr61632_1.f90 (unit = 6, file = 'stdout')
Fortran runtime error: Expected REAL for item 3 in formatted transfer, got
CHARACTER
(1PE13.5,A3)
^
and I think the position of the caret is right. With the patch at
https://gcc.gnu.org/ml/fortran/2014-07/msg00107.html
it is
0.0E+00XXX
At line 8 of file pr61632_1.f90 (unit = 6, file = 'stdout')
Fortran runtime error: Expected REAL for item 3 in formatted transfer, got
CHARACTER
(1PE13.5,A3)
^
i.e., the caret position does not seem right. Your patch probably does not take
into account the fact that the third item of the output uses the first item of
the format (periodic extension).
Otherwise I have run
make -k check-gfortran RUNTESTFLAGS=dg.exp=fmt*
--target_board=unix'{-m32,-m64}'
without regression.
[Bug fortran/61632] memory corruption in Fortran RTL when writing formatted data
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61632 --- Comment #9 from Jerry DeLisle jvdelisle at gcc dot gnu.org --- Its not really a glitch. In this case reversion has occurred so i can only approximate where in the string the error occured. I can improve on it with: offset = fmt-reversion_ok ? fmt-format_string_len + 2: dtp-format_len - fmt-format_string_len; I don't think I can do better for now. Of course we want diagnostics to be helpful, but they can not be perfect. I would suggest we commit the patch for now.
[Bug tree-optimization/61757] [4.10 Regression] genmodes failure with enable-checking
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61757 John David Anglin danglin at gcc dot gnu.org changed: What|Removed |Added CC||danglin at gcc dot gnu.org --- Comment #22 from John David Anglin danglin at gcc dot gnu.org --- Bootstrap is still broken on hppa-unknown-linux-gnu as revision 212498: echo timestamp s-genrtl-h build/genmodes -m tmp-min-modes.c build/genhooks Target Hook \ tmp-target-hooks-def.h build/genmodes: config/pa/pa-modes.def:29: (TF) field format must not be set build/genmodes: machmode.def:203: (DF) field format must not be set build/genmodes: machmode.def:202: (SF) field format must not be set build/genmodes: machmode.def:244: (TD) field format must not be set build/genmodes: machmode.def:243: (DD) field format must not be set build/genmodes: machmode.def:242: (SD) field format must not be set Makefile:2175: recipe for target 's-modes-m' failed
[Bug lto/61786] wrong code by LTO on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61786 Hans-Peter Nilsson hp at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2014-07-14 CC||hp at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #2 from Hans-Peter Nilsson hp at gcc dot gnu.org --- Comfirmed at r212486 (-O2 and not -O2 -flto). Also seen for mmix-knuth-mmixware so apparently not target-specific. (Would be nice to have a test-case that aborts instead of loops infinitely; fits better within the test-harness.)
[Bug libstdc++/61795] [C++11] return type of std::pow(std::complexfloat, int) should be std::complexdouble
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61795
--- Comment #2 from Mitsuru Kariya kariya_mitsuru at hotmail dot com ---
I think that this behaviour is caused by r201253 (for PR57974, Comment 11).
DR844 was fixed by r136694 but reverted by r201253.
diff r135878 r136694
https://gcc.gnu.org/viewcvs/gcc/trunk/libstdc%2B%2B-v3/include/std/complex?r1=135878r2=136694
diff r199924 r201253
https://gcc.gnu.org/viewcvs/gcc/trunk/libstdc%2B%2B-v3/include/std/complex?r1=199924r2=201253
Moreover, I think that I mistook.
Note that this problem does not occur in std::complexdouble and
std::complexlong double because there is no difference between
C++03 and C++11.
This is not true.
In C++03, the 2nd argument of std::pow can cause implicit conversions.
(Because it is the trivial int type.)
However, I believe that it should cause no implicit conversion in C++11.
(I think so from C++11 standard text quoted above.)
Therefore, I think that the sample code below should be compiled successfully
in C++03 mode but should cause compilation error in C++11 mode.
===
#include complex
struct S {
operator int() { return 1; }
};
int main()
{
std::complexdouble d = std::pow(std::complexdouble(0), S());
}
===
[Bug c++/60628] [4.7/4.8 Regression] [c++11] ICE initializing array of auto
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60628 --- Comment #6 from Jason Merrill jason at gcc dot gnu.org --- Author: jason Date: Mon Jul 14 05:25:19 2014 New Revision: 212504 URL: https://gcc.gnu.org/viewcvs?rev=212504root=gccview=rev Log: PR c++/60628 * decl.c (create_array_type_for_decl): Only check for auto once. Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/decl.c
[Bug c++/58636] [4.8/4.9/4.10 Regression] ICE with initializer_list and rvalue references
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58636 --- Comment #2 from Jason Merrill jason at gcc dot gnu.org --- Author: jason Date: Mon Jul 14 05:25:13 2014 New Revision: 212503 URL: https://gcc.gnu.org/viewcvs?rev=212503root=gccview=rev Log: PR c++/58636 * call.c (build_list_conv): Don't try to build a list of references. Added: trunk/gcc/testsuite/g++.dg/cpp0x/initlist-array4.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/call.c
[Bug c++/58511] [4.8/4.9/4.10 Regression] [c++11] ICE using static const member variable in constexpr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58511 --- Comment #5 from Jason Merrill jason at gcc dot gnu.org --- Author: jason Date: Mon Jul 14 05:25:37 2014 New Revision: 212507 URL: https://gcc.gnu.org/viewcvs?rev=212507root=gccview=rev Log: PR c++/58511 * semantics.c (is_instantiation_of_constexpr): Return true for defaulted functions, too. (explain_invalid_constexpr_fn): Only use explain_implicit_non_constexpr if !DECL_DECLARED_CONSTEXPR_P. * method.c (explain_implicit_non_constexpr): Pass DECL_INHERITED_CTOR_BASE to explain_implicit_non_constexpr. Added: trunk/gcc/testsuite/g++.dg/cpp0x/constexpr-inhctor1.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/method.c trunk/gcc/cp/semantics.c trunk/gcc/testsuite/g++.dg/cpp0x/nsdmi3.C
[Bug c++/58612] [4.8/4.9/4.10 Regression] [c++11] ICE calling non-constexpr from constexpr in template class
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58612 --- Comment #3 from Jason Merrill jason at gcc dot gnu.org --- Author: jason Date: Mon Jul 14 05:25:25 2014 New Revision: 212505 URL: https://gcc.gnu.org/viewcvs?rev=212505root=gccview=rev Log: PR c++/58612 * tree.c (bot_replace): Only replace a dummy 'this' parm. Added: trunk/gcc/testsuite/g++.dg/cpp0x/constexpr-neg3.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/tree.c
[Bug c++/58611] [4.8/4.9/4.10 Regression] [c++11] ICE with invalid constexpr constructor used in array initialization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58611 --- Comment #2 from Jason Merrill jason at gcc dot gnu.org --- Author: jason Date: Mon Jul 14 05:25:31 2014 New Revision: 212506 URL: https://gcc.gnu.org/viewcvs?rev=212506root=gccview=rev Log: PR c++/58611 * decl.c (check_initializer): Don't finish_compound_literal on erroneous constexpr init. Added: trunk/gcc/testsuite/g++.dg/cpp0x/constexpr-array6.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/decl.c
[Bug c++/58511] [4.8/4.9/4.10 Regression] [c++11] ICE using static const member variable in constexpr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58511 Jason Merrill jason at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED CC||jason at gcc dot gnu.org Resolution|--- |FIXED Assignee|unassigned at gcc dot gnu.org |jason at gcc dot gnu.org Target Milestone|4.9.1 |4.10.0 --- Comment #6 from Jason Merrill jason at gcc dot gnu.org --- Fixed on trunk.
[Bug c++/55004] [meta-bug] constexpr issues
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55004 Bug 55004 depends on bug 58511, which changed state. Bug 58511 Summary: [4.8/4.9/4.10 Regression] [c++11] ICE using static const member variable in constexpr https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58511 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED
[Bug c++/55004] [meta-bug] constexpr issues
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55004 Bug 55004 depends on bug 58612, which changed state. Bug 58612 Summary: [4.8/4.9/4.10 Regression] [c++11] ICE calling non-constexpr from constexpr in template class https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58612 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED
[Bug c++/55004] [meta-bug] constexpr issues
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55004 Bug 55004 depends on bug 58611, which changed state. Bug 58611 Summary: [4.8/4.9/4.10 Regression] [c++11] ICE with invalid constexpr constructor used in array initialization https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58611 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED
[Bug c++/58612] [4.8/4.9/4.10 Regression] [c++11] ICE calling non-constexpr from constexpr in template class
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58612 Jason Merrill jason at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED Target Milestone|4.8.4 |4.10.0 --- Comment #4 from Jason Merrill jason at gcc dot gnu.org --- Fixed on trunk.
[Bug c++/58611] [4.8/4.9/4.10 Regression] [c++11] ICE with invalid constexpr constructor used in array initialization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58611 Jason Merrill jason at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED Target Milestone|4.8.4 |4.10.0 --- Comment #3 from Jason Merrill jason at gcc dot gnu.org --- Fixed on trunk.
[Bug c++/58636] [4.8/4.9/4.10 Regression] ICE with initializer_list and rvalue references
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58636 --- Comment #4 from Jason Merrill jason at gcc dot gnu.org --- Author: jason Date: Mon Jul 14 05:28:21 2014 New Revision: 212508 URL: https://gcc.gnu.org/viewcvs?rev=212508root=gccview=rev Log: PR c++/58636 * call.c (build_list_conv): Don't try to build a list of references. Added: branches/gcc-4_9-branch/gcc/testsuite/g++.dg/cpp0x/initlist-array4.C Modified: branches/gcc-4_9-branch/gcc/cp/ChangeLog branches/gcc-4_9-branch/gcc/cp/call.c
[Bug c++/58636] [4.8/4.9/4.10 Regression] ICE with initializer_list and rvalue references
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58636 Jason Merrill jason at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED Target Milestone|4.8.4 |4.9.1 --- Comment #3 from Jason Merrill jason at gcc dot gnu.org --- Fixed for 4.9.1.
[Bug c++/61445] [4.10 Regression][C++11] ice in instantiate_decl at cp/pt.c:19770
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61445 Jason Merrill jason at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |jason at gcc dot gnu.org
