[Bug c/53726] [4.8 Regression] aes test performance drop for eembc_2_0_peak_32
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53726 --- Comment #1 from Vladimir Yakovlev 2012-06-20 06:13:26 UTC --- Created attachment 27658 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27658 Test case and assemblers
[Bug c/53726] New: [4.8 Regression] aes test performance drop for eembc_2_0_peak_32
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53726 Bug #: 53726 Summary: [4.8 Regression] aes test performance drop for eembc_2_0_peak_32 Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassig...@gcc.gnu.org ReportedBy: vbyakov...@gmail.com After fix r188261 | rguenth | 2012-06-06 13:45:27 +0400 (Wed, 06 Jun 2012) | 23 lines 2012-06-06 Richard Guenther PR tree-optimization/53081 * tree-data-ref.h (adjacent_store_dr_p): Rename to ... (adjacent_dr_p): ... this and make it work for reads, too. * tree-loop-distribution.c (enum partition_kind): Add PKIND_MEMCPY. (struct partition_s): Change main_stmt to main_dr, add secondary_dr member. (build_size_arg_loc): Change to date data-reference and not gimplify here. (build_addr_arg_loc): New function split out from ... (generate_memset_builtin): ... here. Use it and simplify. (generate_memcpy_builtin): New function. (generate_code_for_partition): Adjust. (classify_partition): Streamline pattern detection. Detect memcpy. (ldist_gen): Adjust. (tree_loop_distribution): Adjust seed statements for memcpy recognition. * gcc.dg/tree-ssa/ldist-20.c: New testcase. * gcc.dg/tree-ssa/loop-19.c: Add -fno-tree-loop-distribute-patterns. regression on Atom 11%, on Sundy Bridge 30%. The fix lead to unrecognition of memcpy. Reduced test case and assemblers are attached. Command line to reproduce gcc -ansi -O3 -ffast-math -msse2 -mfpmath=sse -m32 -static -march=corei7 -mtune=corei7 test.c
[Bug bootstrap/52887] Bootstrap on AIX failure: Undefined symbol: .std::function::function(std::function
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52887 --- Comment #15 from Daniel Richard G. 2012-06-20 04:10:28 UTC --- David, thank you for commenting; I have a better appreciation now of how AIX is a different animal from most, and indeed may be doing things more correctly than other systems on this one point. I'd also like to bring attention to a seemingly similar issue I've encountered when bootstrapping on AIX 4.3: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53238#c11 That one is less straightforward, however, because (as reported a couple comments further down) it only occurs when bootstrapping. If I build GCC with a C-only GCC of the same version and --disable-bootstrap, there's no error.
[Bug c++/53220] [4.7/4.8 Regression] g++ mis-compiles compound literals
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53220 --- Comment #18 from Paul Pluzhnikov 2012-06-20 01:59:01 UTC --- FWIW, it appears that the new error is too strict. It rejects this source, which (AFAIU) is entirely kosher: #include void fn(int arr[]) { for (int j = 0; j < 5; ++j) printf("%d: %d\n", j, arr[j]); } int main() { fn((int[]) { 41, 42, 43, 44, 45 } ); return 0; } g++ -c t.cc t.cc: In function ‘int main()’: t.cc:11:37: error: taking address of temporary array fn((int[]) { 41, 42, 43, 44, 45 } ); ^ Still, I prefer to rewrite the case above, then to debug undiagnosed runtime problems from the original test case.
[Bug c++/53725] Prototype does not match error if the definition of the ctor is separated from its declaration and attributes
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53725 Jonathan Wakely changed: What|Removed |Added Keywords||rejects-valid Status|UNCONFIRMED |NEW Last reconfirmed||2012-06-20 Ever Confirmed|0 |1 --- Comment #1 from Jonathan Wakely 2012-06-20 01:43:15 UTC --- Confirmed. The candidate list also includes the implicitly-declared copy ctor (and in c++11 mode the move ctor) which is also wrong because no definition can be provided for an implicitly-declared special member function.
[Bug bootstrap/52887] Bootstrap on AIX failure: Undefined symbol: .std::function::function(std::function
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52887 --- Comment #14 from Jonathan Wakely 2012-06-20 01:35:58 UTC --- OK, I'll deal with it asap. I have quite a queue of patches to test and commit at present though.
[Bug c++/53651] [4.7/4.8 Regression] [C++11] seg fault when specifying using decltype(...)::method
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53651 --- Comment #3 from Jason Merrill 2012-06-20 01:18:03 UTC --- Author: jason Date: Wed Jun 20 01:17:59 2012 New Revision: 188807 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=188807 Log: PR c++/53651 * name-lookup.c (constructor_name_p): Don't try to look at the name of a DECLTYPE_TYPE. Added: trunk/gcc/testsuite/g++.dg/cpp0x/decltype37.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/name-lookup.c trunk/gcc/testsuite/ChangeLog
[Bug c++/53725] New: Prototype does not match error if the definition of the ctor is separated from its declaration.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53725 Bug #: 53725 Summary: Prototype does not match error if the definition of the ctor is separated from its declaration. Classification: Unclassified Product: gcc Version: 4.6.3 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassig...@gcc.gnu.org ReportedBy: t...@freemail.hu Created attachment 27657 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27657 Minimal example In certain conditions if the definition of the ctor separated from its declaration it generates an compiler error. I created a minimal example. The original code is from Boost.Move. Error: testfull.cpp:16:1: error: prototype for ‘movable::movable(rv&)’ does not match any in class ‘movable’ testfull.cpp:5:7: error: candidates are: movable::movable(const movable&) testfull.cpp:13:5: error: movable::movable(rv&) If the ctor definition is inside the class the code compiles. The same can happen with the assignment operator as visible here: http://lists.boost.org/Archives/boost/2011/07/184263.php
[Bug bootstrap/52887] Bootstrap on AIX failure: Undefined symbol: .std::function::function(std::function
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52887 David Edelsohn changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2012-06-19 CC||dje at gcc dot gnu.org Ever Confirmed|0 |1 --- Comment #13 from David Edelsohn 2012-06-19 23:21:27 UTC --- I successfully bootstrap on AIX 5.3 multiple times per week with the need of the additional instantiations. This may be due to different versions of the AIX assembler. The system I am using has bos.adt.base level 5.3.7.0 installed. I also do not use many of the additional configure options. --disable-shared probably is a bad choice. The file format used on AIX is XCOFF. The file format used on most other systems is ELF. ELF provides a richer set of features for symbols and sections that GCC implicitly assumes to support C++ features. Additionally, SVR4/ELF semantics allows linkers to play a little more "fast and loose". Basically, SVR4/ELF lazy binding allows libraries to omit symbol definitions if they never are used. I suspect that the instantiations that Jonathan is adding truly are needed and should be defined for all systems, but the other systems silently ignore the error. And this probably works on my builds of AIX because I build shared libraries with an option for SVR4-like semantics that allows link-time errors during shared library creation. So the real answer probably is that the instantiations are necessary and libstdc++ really has a latent bug that is not visible on other systems.
[Bug target/53724] New: ICE when using the 'd' asm operand modifier
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53724 Bug #: 53724 Summary: ICE when using the 'd' asm operand modifier Classification: Unclassified Product: gcc Version: 4.7.1 Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: target AssignedTo: unassig...@gcc.gnu.org ReportedBy: svfue...@gmail.com The following gives: internal compiler error: in print_reg, at config/i386/i386.c:13692 typedef double ymmd __attribute__ ((vector_size (32))); ymmd func(ymmd p1, ymmd p2) { asm ("vfmadd132pd %1, %d0" : "+x" (p1) : "x" (p2)); return p1; } when compiled with "gcc-4.7 -mavx -O2 gcc_asm.c -S -o gcc_asm.S" using gcc-4.7.real (Debian 4.7.1-1) 4.7.0 on x86_64
[Bug c++/53524] [4.7/4.8 Regression] Bogus and unsuppressible enum comparison warning
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53524 --- Comment #25 from Paul Pluzhnikov 2012-06-19 21:56:31 UTC --- Google ref: b/6695435
[Bug fortran/53694] [OOP] GENERIC type-bound procs should be available without part-ref syntax
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53694 --- Comment #7 from janus at gcc dot gnu.org 2012-06-19 21:56:09 UTC --- One problem with the patch in comment #6 is that it produces double error messages for type-bound generics, e.g. on typebound_generic_{1,10,11}.
[Bug fortran/53718] [4.7/4.8 regression] [OOP] gfortran generates asm label twice in the same output file
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53718 --- Comment #8 from Dominique d'Humieres 2012-06-19 17:36:26 UTC --- (In reply to comment #7) > Indeed the following patch, which is practically a revert of the trans-decl.c > part of the above commit, makes the errors go away: ... Confirmed for the tests in this PR (as well as the test in http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46313#c25 ) without regression. Note that without the patch the tests fail only with -O0, but not with the optimization I have tried (-O1 or -O3). It would be nice if someone could compile gfortran.dg/select_type_12.f03 (and the tests) through valgrind (I cannot do it under darwin).
[Bug c++/53723] [C++11] Variadic template specialisation fails
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53723 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2012-06-19 Ever Confirmed|0 |1 --- Comment #2 from Jonathan Wakely 2012-06-19 17:32:01 UTC --- Confirmed, I think this should be accepted.
[Bug c++/53723] [C++11] Variadic template specialisation fails
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53723 --- Comment #1 from Seth Carnegie 2012-06-19 17:16:03 UTC --- Also you might want to know that Clang 3.2 accepts the code. There was a StackOverflow question about it here: http://stackoverflow.com/a/11069116/726361
[Bug c++/53723] New: [C++11] Variadic template specialisation fails
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53723 Bug #: 53723 Summary: [C++11] Variadic template specialisation fails Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassig...@gcc.gnu.org ReportedBy: sethcarne...@gmail.com Created attachment 27656 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27656 Example code The code in the attached file, which should compile, does not. It fails with the error: test.cpp:6:5: error: template-id 'foo' for 'int foo()' does not match any template declaration I compiled with the following command line: g++ test.cpp -std=c++11 -Wall -Wextra -fno-strict-aliasing -fwrapv
[Bug fortran/41951] [OOP] Not diagnosing ambiguous operators (TB vs. INTERFACE)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41951 --- Comment #11 from janus at gcc dot gnu.org 2012-06-19 15:53:02 UTC --- Here is a reduced version of comment 2, which is invalid according to comment 10: module m_sort implicit none type, abstract :: sort_t contains generic :: assignment(=) => assign procedure(assign_it), deferred :: assign end type interface assignment(=) subroutine assign_it (lhs, rhs) import class(sort_t), intent(out) :: lhs class(sort_t), intent(in) :: rhs end subroutine end interface end module
[Bug debug/53704] [4.8 Regression] ICE: in based_loc_descr, at dwarf2out.c:10027 after revision 188621
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53704 --- Comment #5 from Eric Botcazou 2012-06-19 15:20:33 UTC --- Created attachment 27655 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27655 Tentative fix #2 Slight variation.
[Bug debug/53704] [4.8 Regression] ICE: in based_loc_descr, at dwarf2out.c:10027 after revision 188621
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53704 --- Comment #4 from Eric Botcazou 2012-06-19 15:13:55 UTC --- > I guess is_fortran never returns true on Darwin, which would mean that the > debug info for Fortran is already pretty broken... Likewise for Ada.
[Bug debug/53704] [4.8 Regression] ICE: in based_loc_descr, at dwarf2out.c:10027 after revision 188621
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53704 --- Comment #3 from Eric Botcazou 2012-06-19 15:06:39 UTC --- Created attachment 27654 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27654 Tentative fix
[Bug debug/53704] [4.8 Regression] ICE: in based_loc_descr, at dwarf2out.c:10027 after revision 188621
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53704 --- Comment #2 from Eric Botcazou 2012-06-19 15:04:09 UTC --- I guess is_fortran never returns true on Darwin, which would mean that the debug info for Fortran is already pretty broken...
[Bug c++/53722] [C++0x] Returning implicit conversion class with deleted copy constructor
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53722 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID --- Comment #2 from Jonathan Wakely 2012-06-19 14:51:10 UTC --- To return it by value Locker must have an accessible copy constructor or move constructor. The deleted copy constructor suppresses the implicit definition of a move constructor, so the class cannot be copied or moved. If you declare the copy constructor for Locker then the class has an accessible copy constructor, so it compiles. Copy elision means the copy constructor is not actually used, but if you compile with -fno-elide-constructors you will get a linker error because the copy ctor isn't defined.
[Bug c++/53722] [C++0x] Returning implicit conversion class with deleted copy constructor
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53722 --- Comment #1 from George Galeev 2012-06-19 14:29:08 UTC --- Work fine with real pointers and mutex locking in temp object Locker.
[Bug c++/53722] New: [C++0x] Returning implicit conversion class with deleted copy constructor
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53722 Bug #: 53722 Summary: [C++0x] Returning implicit conversion class with deleted copy constructor Classification: Unclassified Product: gcc Version: 4.6.3 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassig...@gcc.gnu.org ReportedBy: rainarchit...@gmail.com struct Uncopyable { public: Uncopyable() {} Uncopyable(const Uncopyable&) = delete; }; struct Locker: public Uncopyable { Locker(void*) {} // declaration without a definition //Locker(const Locker&); }; struct SmartPtr { // error: use of deleted function «Locker::Locker(const Locker&)» Locker lock() { return 0; } }; But if uncomment «Locker(const Locker&)» constructor declaration even without a definition, this code compile and work fine.
[Bug middle-end/53695] [4.8 Regression] ICE: in dfs_enumerate_from, at cfganal.c:1221 with -O2 -ftracer and labels/gotos
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53695 Richard Guenther changed: What|Removed |Added CC||rakdver at gcc dot gnu.org Known to work|4.7.2 |4.8.0 Known to fail|4.8.0 |4.7.2 --- Comment #3 from Richard Guenther 2012-06-19 14:12:46 UTC --- I think the bug is that we detect a loop just over abnormal goto edges (can be first seen in 031t.cddce1). Not sure if we do that on purpose ...
[Bug middle-end/53676] [4.7/4.8 regression] empty loop is not always removed now
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53676 Richard Guenther changed: What|Removed |Added CC||rguenth at gcc dot gnu.org --- Comment #5 from Richard Guenther 2012-06-19 13:18:19 UTC --- First of all confirmed. We rely on SCCP to compute the overall loop effect which does not happen anymore. The loops are different - 4.6 has : # result_81 = PHI # n_78 = PHI result.7_42 = (unsigned char) result_81; D.7248_43 = result.7_42 + 2; result_44 = (signed char) D.7248_43; n_46 = n_78 + 1; if (n_46 != 8000) goto ; else goto ; but with 4.7 we see : # result_76 = PHI # n_77 = PHI D.7583_48 = (int) result_76; D.7582_49 = D.7583_48 + 2; result_50 = (signed char) D.7582_49; n_52 = n_77 + 1; if (n_52 != 8000) goto ; else goto ; thus 4.6 performed the premature shortening optimization that 4.7 no longer performs. Testcase that nobody handles because it has the operation explicitely in int: int main() { int i; signed char result = 0; for (i = 0; i != 8000; ++i) { int tem = result; tem = tem + 2; result = tem; } if (__builtin_abs ((int)(signed char)((unsigned char ) result + 128)) != 0) __builtin_abort (); return 0; } Proper action could be to implement that shortening inside forwprop or to teach the trick to SCEV analysis.
[Bug fortran/53718] [4.7/4.8 regression] [OOP] gfortran generates asm label twice in the same output file
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53718 --- Comment #7 from janus at gcc dot gnu.org 2012-06-19 13:13:03 UTC --- (In reply to comment #6) > > Could it be revision 181505? > > Very likely. If it is, I'm betting on the PR50640 part of that commit. Indeed the following patch, which is practically a revert of the trans-decl.c part of the above commit, makes the errors go away: Index: gcc/fortran/trans-decl.c === --- gcc/fortran/trans-decl.c(revision 188334) +++ gcc/fortran/trans-decl.c(working copy) @@ -1483,7 +1483,6 @@ gfc_get_symbol_decl (gfc_symbol * sym) || (sym->name[0] == '_' && strncmp ("__def_init", sym->name, 10) == 0)) { TREE_READONLY (decl) = 1; - GFC_DECL_PUSH_TOPLEVEL (decl) = 1; } return decl; @@ -1913,8 +1912,7 @@ build_function_decl (gfc_symbol * sym, bool global /* Layout the function declaration and put it in the binding level of the current function. */ - if (global - || (sym->name[0] == '_' && strncmp ("__copy", sym->name, 6) == 0)) + if (global) pushdecl_top_level (fndecl); else pushdecl (fndecl);
[Bug libstdc++/53270] [4.6/4.7 Regression] Error when bootstrapping gcc on hppa2.0-unknown-linux-gcc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53270 Jonathan Wakely changed: What|Removed |Added Known to work|4.7.2 | Summary|[4.6 Regression] Error when |[4.6/4.7 Regression] Error |bootstrapping gcc on|when bootstrapping gcc on |hppa2.0-unknown-linux-gcc |hppa2.0-unknown-linux-gcc --- Comment #33 from Jonathan Wakely 2012-06-19 11:14:55 UTC --- Bah, the patch on the 4.7 branch isn't right as it also disables the macros when using NPTL, which isn't needed. As Dave suggested on comment 15 we'll need to check in acinclude.m4 whether the macros cause problems. Proper fix coming soon ...
[Bug fortran/53694] [OOP] GENERIC type-bound procs should be available without part-ref syntax
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53694 --- Comment #6 from janus at gcc dot gnu.org 2012-06-19 10:46:56 UTC --- (In reply to comment #5) > Btw, I'm not completely convinced yet that the code in comment #0 (and #4) is > really legal. In any case, here is a simple draft patch, which makes the code in comment 4 work (at least when the ONLY clause in the USE statement is removed): Index: gcc/fortran/decl.c === --- gcc/fortran/decl.c(revision 188334) +++ gcc/fortran/decl.c(working copy) @@ -8374,12 +8374,20 @@ gfc_match_generic (void) { const bool is_op = (op_type == INTERFACE_USER_OP); gfc_symtree* st; +gfc_symbol *gensym; st = gfc_new_symtree (is_op ? &ns->tb_uop_root : &ns->tb_sym_root, name); gcc_assert (st); st->n.tb = tb; +/* Create non-typebound generic symbol. */ +if (gfc_get_symbol (name, NULL, &gensym)) + return MATCH_ERROR; +if (!gensym->attr.generic +&& gfc_add_generic (&gensym->attr, gensym->name, NULL) == FAILURE) + return MATCH_ERROR; + break; } Index: gcc/fortran/resolve.c === --- gcc/fortran/resolve.c(revision 188335) +++ gcc/fortran/resolve.c(working copy) @@ -11125,6 +11125,26 @@ specific_found: return FAILURE; } +/* Add target to (non-typebound) generic symbol. */ +if (!p->u.generic->is_operator) + { +gfc_symbol *gensym; +if (gfc_get_symbol (name, NULL, &gensym)) + return FAILURE; +if (gensym) + { +gfc_interface *head, *intr; +head = gensym->generic; +intr = gfc_get_interface (); +intr->sym = target->specific->u.specific->n.sym; +intr->where = gfc_current_locus; +intr->sym->declared_at = gfc_current_locus; +intr->next = head; +gensym->generic = intr; +gfc_commit_symbol (gensym); + } + } + /* Check those already resolved on this type directly. */ for (g = p->u.generic; g; g = g->next) if (g != target && g->specific
[Bug fortran/53718] [4.7/4.8 regression] [OOP] gfortran generates asm label twice in the same output file
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53718 --- Comment #6 from janus at gcc dot gnu.org 2012-06-19 10:35:34 UTC --- (In reply to comment #5) > Could it be revision 181505? Very likely. If it is, I'm betting on the PR50640 part of that commit.
[Bug fortran/53694] [OOP] GENERIC type-bound procs should be available without part-ref syntax
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53694 --- Comment #5 from janus at gcc dot gnu.org 2012-06-19 09:52:42 UTC --- (In reply to comment #3) > > > See also: > > > https://groups.google.com/forum/#!msg/comp.lang.fortran/YDt3j0--1Do > > Note: That link does not seem to work. > > Try: > > http://www.rhinocerus.net/forum/lang-fortran/708232-there-way-do-following.html The correct google groups link would be: https://groups.google.com/forum/#!topic/comp.lang.fortran/YDt3j0--1Do Btw, I'm not completely convinced yet that the code in comment #0 (and #4) is really legal. No one in the c.l.f. thread has brought up a quote from the standard which clearly shows that referencing a type-bound generic is legal without part-ref syntax. For me, to most convincing reference up to now is this quote from F08:12.4.3.4.5 (though it still sounds a bit 'cloudy' to me): NOTE 12.10 In most scoping units, the possible sources of procedures with a particular generic identifier are the accessible interface blocks and the generic bindings other than names for the accessible objects in that scoping unit.
[Bug libstdc++/53657] [4.7/4.8 Regression] [C++11] pair(pair&&) move constructor is non-trivial
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53657 Paolo Carlini changed: What|Removed |Added Status|NEW |ASSIGNED CC|jason at gcc dot gnu.org, | |paolo.carlini at oracle dot | |com | AssignedTo|unassigned at gcc dot |paolo.carlini at oracle dot |gnu.org |com --- Comment #8 from Paolo Carlini 2012-06-19 09:30:00 UTC --- Ah, great, Daniel pointed out in private mail that the latest update of LWG 2005 indeed specifies is_constructible as I seemed to remember: http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#2005
[Bug middle-end/53708] [4.8 Regression] Many failures of the objc tests with -O3 -fnext-runtime and -m32
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53708 Richard Guenther changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #8 from Richard Guenther 2012-06-19 09:20:49 UTC --- Fixed.
[Bug middle-end/53708] [4.8 Regression] Many failures of the objc tests with -O3 -fnext-runtime and -m32
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53708 --- Comment #7 from Richard Guenther 2012-06-19 09:19:17 UTC --- Author: rguenth Date: Tue Jun 19 09:19:07 2012 New Revision: 188771 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=188771 Log: 2012-06-19 Richard Guenther PR tree-optimization/53708 * tree-vect-data-refs.c (vect_can_force_dr_alignment_p): Preserve user-supplied alignment and alignment of decls with the used attribute. Modified: trunk/gcc/ChangeLog trunk/gcc/tree-vect-data-refs.c
[Bug rtl-optimization/53700] [4.7 regression] ICE in reload_cse_simplify_operands, at postreload.c:403
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53700 Richard Guenther changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #7 from Richard Guenther 2012-06-19 09:18:29 UTC --- Thanks Vlad.
[Bug middle-end/8743] receiving result from __builtin_return_address() beyond stack top causes segfault
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=8743 Richard Guenther changed: What|Removed |Added Status|NEW |RESOLVED Resolution||WONTFIX --- Comment #11 from Richard Guenther 2012-06-19 09:18:12 UTC --- Indeed.
[Bug debug/53719] can't display x87 stack information
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53719 Richard Guenther changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID --- Comment #2 from Richard Guenther 2012-06-19 09:17:50 UTC --- This is not a bug in GCC.
[Bug fortran/53718] [4.7/4.8 regression] [OOP] gfortran generates asm label twice in the same output file
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53718 Richard Guenther changed: What|Removed |Added Target Milestone|--- |4.7.2
[Bug middle-end/53708] [4.8 Regression] Many failures of the objc tests with -O3 -fnext-runtime and -m32
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53708 --- Comment #6 from Dominique d'Humieres 2012-06-19 08:46:49 UTC --- Works for me too on x86_64-apple-darwin10 and powerpc-apple-darwin9.
[Bug middle-end/53688] [4.8 Regression] 191.fma3d in SPEC CPU 2000 miscompiled
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53688 Eric Botcazou changed: What|Removed |Added CC||georggcc at googlemail dot ||com --- Comment #3 from Eric Botcazou 2012-06-19 08:44:30 UTC --- *** Bug 53686 has been marked as a duplicate of this bug. ***
[Bug ada/53686] gnatchop -r raises STORAGE_ERROR on all inputs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53686 Eric Botcazou changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||DUPLICATE --- Comment #2 from Eric Botcazou 2012-06-19 08:44:30 UTC --- Presumably. *** This bug has been marked as a duplicate of bug 53688 ***
[Bug c++/53574] ICE with -fstack-usage
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53574 Eric Botcazou changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2012-06-19 Ever Confirmed|0 |1 --- Comment #2 from Eric Botcazou 2012-06-19 08:20:04 UTC --- This also crashes debug_tree on the decl from within the debugger. It seems that lang_decl_name can do a fair amount of processing if v >= 2. Additionally passing TFF_NO_FUNCTION_ARGUMENTS from there fixes the crash (and would be sufficient for -fstack-usage), but this breaks __PRETTY_FUNCTION__ for example. A possible solution would be to set TFF_NO_FUNCTION_ARGUMENTS if v == 2 and use level 3 internally (in error.c and in pt.c for __PRETTY_FUNCTION__). FWIW the Ada front-end doesn't print the arguments if v == 2.
[Bug libstdc++/53270] Error when bootstrapping gcc on hppa2.0-unknown-linux-gcc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53270 --- Comment #32 from Jonathan Wakely 2012-06-19 07:42:30 UTC --- Author: redi Date: Tue Jun 19 07:42:21 2012 New Revision: 188768 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=188768 Log: PR libstdc++/53270 * config/os/gnu-linux/os_defines.h: Disable static initializer macros for gthreads types in C++11 mode. Modified: branches/gcc-4_7-branch/libstdc++-v3/ChangeLog branches/gcc-4_7-branch/libstdc++-v3/config/os/gnu-linux/os_defines.h