[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 redi at gcc dot gnu.org 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=gccview=revrev=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
[Bug c++/53574] ICE with -fstack-usage
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53574 Eric Botcazou ebotcazou at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2012-06-19 Ever Confirmed|0 |1 --- Comment #2 from Eric Botcazou ebotcazou at gcc dot gnu.org 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 ada/53686] gnatchop -r raises STORAGE_ERROR on all inputs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53686 Eric Botcazou ebotcazou at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||DUPLICATE --- Comment #2 from Eric Botcazou ebotcazou at gcc dot gnu.org 2012-06-19 08:44:30 UTC --- Presumably. *** This bug has been marked as a duplicate of bug 53688 ***
[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 ebotcazou at gcc dot gnu.org changed: What|Removed |Added CC||georggcc at googlemail dot ||com --- Comment #3 from Eric Botcazou ebotcazou at gcc dot gnu.org 2012-06-19 08:44:30 UTC --- *** Bug 53686 has been marked as a duplicate of this bug. ***
[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 dominiq at lps dot ens.fr 2012-06-19 08:46:49 UTC --- Works for me too on x86_64-apple-darwin10 and powerpc-apple-darwin9.
[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 rguenth at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |4.7.2
[Bug debug/53719] can't display x87 stack information
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53719 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID --- Comment #2 from Richard Guenther rguenth at gcc dot gnu.org 2012-06-19 09:17:50 UTC --- This is not a bug in GCC.
[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 rguenth at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||WONTFIX --- Comment #11 from Richard Guenther rguenth at gcc dot gnu.org 2012-06-19 09:18:12 UTC --- Indeed.
[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 rguenth at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #7 from Richard Guenther rguenth at gcc dot gnu.org 2012-06-19 09:18:29 UTC --- Thanks Vlad.
[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 rguenth at gcc dot gnu.org 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=gccview=revrev=188771 Log: 2012-06-19 Richard Guenther rguent...@suse.de 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 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 rguenth at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #8 from Richard Guenther rguenth at gcc dot gnu.org 2012-06-19 09:20:49 UTC --- Fixed.
[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 paolo.carlini at oracle dot com 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 paolo.carlini at oracle dot com 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 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 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 #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 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 redi at gcc dot gnu.org 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 redi at gcc dot gnu.org 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/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 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 rguenth at gcc dot gnu.org changed:
What|Removed |Added
CC||rguenth at gcc dot gnu.org
--- Comment #5 from Richard Guenther rguenth at gcc dot gnu.org 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
bb 14:
# result_81 = PHI result_44(13), 0(21)
# n_78 = PHI n_46(13), 0(21)
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 bb 13;
else
goto bb 15;
but with 4.7 we see
bb 16:
# result_76 = PHI result_50(15), 0(22)
# n_77 = PHI n_52(15), 0(22)
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 bb 15;
else
goto bb 17;
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 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 rguenth at gcc dot gnu.org 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 rguenth at gcc dot gnu.org 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 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 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 rainarchitect at gmail dot com 2012-06-19 14:29:08 UTC --- Work fine with real pointers and mutex locking in temp object Locker.
[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 redi at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID --- Comment #2 from Jonathan Wakely redi at gcc dot gnu.org 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 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 ebotcazou at gcc dot gnu.org 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 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 ebotcazou at gcc dot gnu.org 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 #4 from Eric Botcazou ebotcazou at gcc dot gnu.org 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 #5 from Eric Botcazou ebotcazou at gcc dot gnu.org 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 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 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 'fooint' 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 c++/53723] [C++11] Variadic template specialisation fails
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53723 --- Comment #1 from Seth Carnegie sethcarnegie at gmail dot com 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] [C++11] Variadic template specialisation fails
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53723 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2012-06-19 Ever Confirmed|0 |1 --- Comment #2 from Jonathan Wakely redi at gcc dot gnu.org 2012-06-19 17:32:01 UTC --- Confirmed, I think this should be accepted.
[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 dominiq at lps dot ens.fr 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 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 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 ppluzhnikov at google dot com 2012-06-19 21:56:31 UTC --- Google ref: b/6695435
[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 bootstrap/52887] Bootstrap on AIX failure: Undefined symbol: .std::functionvoid (std::__regex::_PatternCursor const, std::__regex::_Results)::function(std::functionvoid (std::__regex::_Patte
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52887 David Edelsohn dje at gcc dot gnu.org 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 dje at gcc dot gnu.org 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 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(rvmovable)’ 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(rvmovable) 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 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 jason at gcc dot gnu.org 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=gccview=revrev=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 bootstrap/52887] Bootstrap on AIX failure: Undefined symbol: .std::functionvoid (std::__regex::_PatternCursor const, std::__regex::_Results)::function(std::functionvoid (std::__regex::_Patte
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52887 --- Comment #14 from Jonathan Wakely redi at gcc dot gnu.org 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++/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 redi at gcc dot gnu.org changed: What|Removed |Added Keywords||rejects-valid Status|UNCONFIRMED |NEW Last reconfirmed||2012-06-20 Ever Confirmed|0 |1 --- Comment #1 from Jonathan Wakely redi at gcc dot gnu.org 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 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 ppluzhnikov at google dot com 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 stdio.h
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 bootstrap/52887] Bootstrap on AIX failure: Undefined symbol: .std::functionvoid (std::__regex::_PatternCursor const, std::__regex::_Results)::function(std::functionvoid (std::__regex::_Patte
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52887 --- Comment #15 from Daniel Richard G. skunk at iskunk dot org 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.
