[Bug c++/43915] Compiler flags error: error: invalid initialization of reference of type 'boost::thread' from expression of type 'boost::thread'
--- Comment #3 from mlrus at mac dot com 2010-04-28 06:23 --- Subject: Re: Compiler flags error: error: invalid initialization of reference of type 'boost::thread' from expression of type 'boost::thread' Its attached. /Michah --- Comment #2 from pinskia at gcc dot gnu dot org 2010-04-28 02:00 --- Can you attach the preprocessed source? This might be an issue with boost. There was a change with respect to rvalue references; lvalues cannot bind to rvalue references. The C++0x standard is changing still so this was a change with the standard between the releases of 4.4 and 4.5. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43915 --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. You reported the bug, or are watching the reporter. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43915
[Bug c++/43915] Compiler flags error: error: invalid initialization of reference of type 'boost::thread' from expression of type 'boost::thread'
--- Comment #4 from mlrus at mac dot com 2010-04-28 06:24 --- Created an attachment (id=20502) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20502action=view) Bzip'ed preprocessor output for libs/thread/src/pthread/thread.cpp with g++ -c -save-temps -std=c++0x ... Bzip'ed thread.ii. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43915
[Bug libstdc++/43918] New: gcc 4.5.0 is failing for i586-pc-msdosdjgpp
Hi, I am building gcc 4.5.0 for i586-pc-msdosdjgpp target. I am getting the following erorors. In file included from /tools/tmp.14/obj/djgpp/cross/gcc-4.5.0/i586-pc-msdosdjgpp/libstdc++-v3/include/system_error:39:0, from /tools/tmp.14/obj/djgpp/cross/gcc-4.5.0/i586-pc-msdosdjgpp/libstdc++-v3/include/mutex:45, from /tools/tmp.14/src/djgpp/cross/gcc-4.5.0/libstdc++-v3/src/atomic.cc:28: /tools/tmp.14/obj/djgpp/cross/gcc-4.5.0/i586-pc-msdosdjgpp/libstdc++-v3/include/i586-pc-msdosdjgpp/bits/error_constants.h:40:40: error: 'EAFNOSUPPORT' was not declared in this scope /tools/tmp.14/obj/djgpp/cross/gcc-4.5.0/i586-pc-msdosdjgpp/libstdc++-v3/include/i586-pc-msdosdjgpp/bits/error_constants.h:41:28: error: 'EADDRINUSE' was not declared in this scope /tools/tmp.14/obj/djgpp/cross/gcc-4.5.0/i586-pc-msdosdjgpp/libstdc++-v3/include/i586-pc-msdosdjgpp/bits/error_constants.h:42:34: error: 'EADDRNOTAVAIL' was not declared in this scope /tools/tmp.14/obj/djgpp/cross/gcc-4.5.0/i586-pc-msdosdjgpp/libstdc++-v3/include/i586-pc-msdosdjgpp/bits/error_constants.h:43:30: error: 'EISCONN' was not declared in this scope /tools/tmp.14/obj/djgpp/cross/gcc-4.5.0/i586-pc-msdosdjgpp/libstdc++-v3/include/i586-pc-msdosdjgpp/bits/error_constants.h:54:31: error: 'ECONNABORTED' was not declared in this scope /tools/tmp.14/obj/djgpp/cross/gcc-4.5.0/i586-pc-msdosdjgpp/libstdc++-v3/include/i586-pc-msdosdjgpp/bits/error_constants.h:55:42: error: 'EALREADY' was not declared in this scope /tools/tmp.14/obj/djgpp/cross/gcc-4.5.0/i586-pc-msdosdjgpp/libstdc++-v3/include/i586-pc-msdosdjgpp/bits/error_constants.h:56:31: error: 'ECONNREFUSED' was not declared in this scope /tools/tmp.14/obj/djgpp/cross/gcc-4.5.0/i586-pc-msdosdjgpp/libstdc++-v3/include/i586-pc-msdosdjgpp/bits/error_constants.h:57:29: error: 'ECONNRESET' was not declared in this scope /tools/tmp.14/obj/djgpp/cross/gcc-4.5.0/i586-pc-msdosdjgpp/libstdc++-v3/include/i586-pc-msdosdjgpp/bits/error_constants.h:59:40: error: 'EDESTADDRREQ' was not declared in this scope /tools/tmp.14/obj/djgpp/cross/gcc-4.5.0/i586-pc-msdosdjgpp/libstdc++-v3/include/i586-pc-msdosdjgpp/bits/error_constants.h:67:29: error: 'EHOSTUNREACH' was not declared in this scope /tools/tmp.14/obj/djgpp/cross/gcc-4.5.0/i586-pc-msdosdjgpp/libstdc++-v3/include/i586-pc-msdosdjgpp/bits/error_constants.h:80:26: error: 'EMSGSIZE' was not declared in this scope /tools/tmp.14/obj/djgpp/cross/gcc-4.5.0/i586-pc-msdosdjgpp/libstdc++-v3/include/i586-pc-msdosdjgpp/bits/error_constants.h:81:26: error: 'ENETDOWN' was not declared in this scope /tools/tmp.14/obj/djgpp/cross/gcc-4.5.0/i586-pc-msdosdjgpp/libstdc++-v3/include/i586-pc-msdosdjgpp/bits/error_constants.h:82:27: error: 'ENETRESET' was not declared in this scope /tools/tmp.14/obj/djgpp/cross/gcc-4.5.0/i586-pc-msdosdjgpp/libstdc++-v3/include/i586-pc-msdosdjgpp/bits/error_constants.h:83:32: error: 'ENETUNREACH' was not declared in this scope /tools/tmp.14/obj/djgpp/cross/gcc-4.5.0/i586-pc-msdosdjgpp/libstdc++-v3/include/i586-pc-msdosdjgpp/bits/error_constants.h:84:28: error: 'ENOBUFS' was not declared in this scope /tools/tmp.14/obj/djgpp/cross/gcc-4.5.0/i586-pc-msdosdjgpp/libstdc++-v3/include/i586-pc-msdosdjgpp/bits/error_constants.h:97:24: error: 'ENOMSG' was not declared in this scope /tools/tmp.14/obj/djgpp/cross/gcc-4.5.0/i586-pc-msdosdjgpp/libstdc++-v3/include/i586-pc-msdosdjgpp/bits/error_constants.h:98:31: error: 'ENOPROTOOPT' was not declared in this scope /tools/tmp.14/obj/djgpp/cross/gcc-4.5.0/i586-pc-msdosdjgpp/libstdc++-v3/include/i586-pc-msdosdjgpp/bits/error_constants.h:110:26: error: 'ENOTSOCK' was not declared in this scope /tools/tmp.14/obj/djgpp/cross/gcc-4.5.0/i586-pc-msdosdjgpp/libstdc++-v3/include/i586-pc-msdosdjgpp/bits/error_constants.h:116:27: error: 'ENOTCONN' was not declared in this scope /tools/tmp.14/obj/djgpp/cross/gcc-4.5.0/i586-pc-msdosdjgpp/libstdc++-v3/include/i586-pc-msdosdjgpp/bits/error_constants.h:127:34: error: 'EINPROGRESS' was not declared in this scope Can you please provide us the patch ? -- Summary: gcc 4.5.0 is failing for i586-pc-msdosdjgpp Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: blocker Priority: P3 Component: libstdc++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: suresh dot gumpula at amd dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43918
[Bug fortran/43919] New: Coarrays: ICE in simplify_cobound
The following program gives an ICE:
f951: internal compiler error: in simplify_cobound, at fortran/simplify.c:2969
integer :: a[*]
print *,a
print *,lcobound(a), ucobound(a)
end
Patch (untested):
Index: gcc/fortran/simplify.c
===
--- gcc/fortran/simplify.c (revision 158822)
+++ gcc/fortran/simplify.c (working copy)
@@ -2936,6 +2936,13 @@ simplify_cobound (gfc_expr *array, gfc_e
switch (ref-u.ar.type)
{
case AR_ELEMENT:
+ if (ref-next == NULL)
+ {
+ gcc_assert (ref-u.ar.as-corank 0
+ ref-u.ar.as-rank == 0);
+ as = ref-u.ar.as;
+ goto done;
+ }
as = NULL;
continue;
--
Summary: Coarrays: ICE in simplify_cobound
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code
Severity: normal
Priority: P3
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: burnus at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43919
[Bug libstdc++/43918] gcc 4.5.0 is failing for i586-pc-msdosdjgpp
--- Comment #1 from suresh dot gumpula at amd dot com 2010-04-28 07:56 --- Created an attachment (id=20503) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20503action=view) patch for target i586-pc-msdosdjgpp for undefined error constants -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43918
[Bug libstdc++/43918] gcc 4.5.0 is failing for i586-pc-msdosdjgpp
--- Comment #2 from suresh dot gumpula at amd dot com 2010-04-28 08:00 --- (In reply to comment #1) Created an attachment (id=20503) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20503action=view) [edit] patch for target i586-pc-msdosdjgpp for undefined error constants I created a patch for target i586-pc-msdosdjgpp and the problem got solved, but now i am getting diffrent error gcc-4.5.0/libstdc++-v3/src/strstream.cc:414:1: internal compiler error: Segmentation fault -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43918
[Bug libstdc++/43918] gcc 4.5.0 is failing for i586-pc-msdosdjgpp
--- Comment #3 from suresh dot gumpula at amd dot com 2010-04-28 08:02 --- (In reply to comment #2) (In reply to comment #1) Created an attachment (id=20503) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20503action=view) [edit] patch for target i586-pc-msdosdjgpp for undefined error constants I created a patch for target i586-pc-msdosdjgpp and the problem got solved, but now i am getting diffrent error gcc-4.5.0/libstdc++-v3/src/strstream.cc:414:1: internal compiler error: Segmentation fault [sure...@ssdbang1 git]$ /tools/tmp.14/obj/djgpp/cross/gcc-4.5.0/./gcc/xgcc -shared-libgcc -B/tools/tmp.14/obj/djgpp/cross/gcc-4.5.0/./gcc -nostdinc++ -L/tools/tmp.14/obj/djgpp/cross/gcc-4.5.0/i586-pc-msdosdjgpp/libstdc++-v3/src -L/tools/tmp.14/obj/djgpp/cross/gcc-4.5.0/i586-pc-msdosdjgpp/libstdc++-v3/src/.libs -B/tools/toolchain.14/opt/djgpp/i586-pc-msdosdjgpp/bin/ -B/tools/toolchain.14/opt/djgpp/i586-pc-msdosdjgpp/lib/ -isystem /tools/toolchain.14/opt/djgpp/i586-pc-msdosdjgpp/include -isystem /tools/toolchain.14/opt/djgpp/i586-pc-msdosdjgpp/sys-include -I/tools/tmp.14/obj/djgpp/cross/gcc-4.5.0/i586-pc-msdosdjgpp/libstdc++-v3/include/i586-pc-msdosdjgpp -I/tools/tmp.14/obj/djgpp/cross/gcc-4.5.0/i586-pc-msdosdjgpp/libstdc++-v3/include -I/tools/tmp.14/src/djgpp/cross/gcc-4.5.0/libstdc++-v3/libsupc++ -fno-implicit-templates -Wall -Wextra -Wwrite-strings -Wcast-qual -fdiagnostics-show-location=once -ffunction-sections -fdata-sections -g -O2 -I/tools/tmp.14/obj/djgpp/cross/gcc-4.5.0/i586-pc-msdosdjgpp/libstdc++-v3/include/backward -Wno-deprecated -c /tools/tmp.14/src/djgpp/cross/gcc-4.5.0/libstdc++-v3/src/strstream.cc -o strstream.o /tools/tmp.14/src/djgpp/cross/gcc-4.5.0/libstdc++-v3/src/strstream.cc: In member function 'void std::strstream::_ZTv0_n12_NSt9strstreamD1Ev()': /tools/tmp.14/src/djgpp/cross/gcc-4.5.0/libstdc++-v3/src/strstream.cc:414:1: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43918
[Bug target/43920] New: A lot of instructions for condition (start == -1 || end == -1)
Compile the attached source code with options -march=armv7-a -mthumb -Os, gcc generates following instructions for if (start == -1 || end == -1): ... cmp r4, #-1 ite ne movne r3, #0 moveq r3, #1 cmp r0, #-1 it eq orreq r3, r3, #1 cbnzr3, .L4 ... A simplified code sequence is: ... cmp r4, #-1 bne .L4 cmp r0, #-1 bne .L4 ... The if statement is trivially translated into the following gimple statements: D.2530 = start == -1; D.2531 = end == -1; D.2532 = D.2530 || D.2531; if (D.2532 != 0) goto D.2533; else goto D.2534; And then expanded into rtl insns without further optimizations. -- Summary: A lot of instructions for condition (start == -1 || end == -1) Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: target AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: carrot at google dot com GCC build triplet: i686-linux GCC host triplet: i686-linux GCC target triplet: arm-eabi http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43920
[Bug target/43920] A lot of instructions for condition (start == -1 || end == -1)
--- Comment #1 from carrot at google dot com 2010-04-28 08:18 --- Created an attachment (id=20504) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20504action=view) test case -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43920
[Bug fortran/43919] Coarrays: ICE in simplify_cobound
--- Comment #1 from burnus at gcc dot gnu dot org 2010-04-28 08:30 --- Mine. Patch works. -- burnus at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |burnus at gcc dot gnu dot |dot org |org Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2010-04-28 08:30:20 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43919
[Bug c++/9335] [4.3/4.4/4.5/4.6 regression] repeated diagnostic when maximum template depth is exceeded
--- Comment #26 from manu at gcc dot gnu dot org 2010-04-28 08:34 --- Subject: Bug 9335 Author: manu Date: Wed Apr 28 08:34:01 2010 New Revision: 158823 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=158823 Log: 2010-04-28 Manuel López-Ibáñez m...@gcc.gnu.org PR c++/9335 cp/ * error.c (print_instantiation_partial_context_line): Handle recursive instantiation. (print_instantiation_partial_context): Likewise. testsuite/ * g++.dg/template/recurse2.C: Update * g++.dg/template/recurse.C: Update. * g++.dg/template/pr23510.C: Update. * lib/prune.exp: Filter out 'recursively instantiated'. Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/error.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/g++.dg/template/pr23510.C trunk/gcc/testsuite/g++.dg/template/recurse.C trunk/gcc/testsuite/g++.dg/template/recurse2.C trunk/gcc/testsuite/lib/prune.exp -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=9335
[Bug c++/9335] [4.3/4.4/4.5/4.6 regression] repeated diagnostic when maximum template depth is exceeded
--- Comment #27 from manu at gcc dot gnu dot org 2010-04-28 08:38 --- The current output is: recurse2.C:5:38: error: template instantiation depth exceeds maximum of 1024 (use -ftemplate-depth= to increase the maximum) instantiating struct X-0x00018 recurse2.C:5:38: recursively instantiated from const int X999::value recurse2.C:5:38: instantiated from const int X1000::value recurse2.C:8:17: instantiated from here recurse2.C:5:38: error: incomplete type X-0x00018 used in nested name specifier From my point of view this is FIXED. I am not going to backport any patches. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=9335
[Bug fortran/40117] [OOP][F2008] Type-bound procedure: allow list after PROCEDURE
--- Comment #1 from burnus at gcc dot gnu dot org 2010-04-28 08:42 --- Fortran 2008 FDIS (ftp://ftp.nag.co.uk/sc22wg5/N1801-N1850/N1826.pdf) has: R448 type-bound-procedure-stmt is PROCEDURE [ [ , binding-attr -list ] :: ] type-bound-proc-decl -list or PROCEDURE (interface-name), binding-attr -list :: binding-name-list -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40117
[Bug c++/43113] too long diagnostics in some cases of recursive template instantiation
--- Comment #4 from manu at gcc dot gnu dot org 2010-04-28 08:46 --- The output is now: $ cc1plus pr43113.C -ftemplate-depth=10 pr43113.C:7:11: error: template instantiation depth exceeds maximum of 10 (use -ftemplate-depth= to increase the maximum) instantiating struct AAAB::S::S::S::S::S::S::S::S::S::S pr43113.C:7:11: recursively instantiated from AAB::S pr43113.C:7:11: instantiated from AB pr43113.C:10:20: instantiated from here pr43113.C:7:11: error: A template-parameter-1-1 ::ht has incomplete type pr43113.C:5:8: error: declaration of struct AAAB::S::S::S::S::S::S::S::S::S::S The template-parameter-1-1 is wrong, not sure what is going on there. We could avoid the two long lines by not printing the full instantiation, only the first recursion, that is, just 'struct AAB::S' -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43113
[Bug bootstrap/43858] [4.6 Regression] Bootstrap failure for powerpc-apple-darwin9: cannot compute suffix of object files
--- Comment #19 from dominiq at lps dot ens dot fr 2010-04-28 08:50 --- Two questions - are you sure you didn't reverse the _w and _f files (i.e. maybe _f is the working version and _w the failing one)? I have looked at how I have generated the archive and I don't think so. I'll double-check later today. Are you sure this isn't a problem with your 4.0.1 bootstrap compiler? How can anyone be sure!-(however this does not seem consistent with the fact that the all the object files, but ifcvt.o, have the same size (is there a way to make a deeper comparison?) and also the regress bot is still failing to bootstrap (see pointer in comment #0) while using a different config (but probably the same gcc). Can you try building a different working gcc (e.g. from the 4.5 branch), and bootstrapping with that? I'll try to have a look later today. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43858
[Bug bootstrap/43858] [4.6 Regression] Bootstrap failure for powerpc-apple-darwin9: cannot compute suffix of object files
--- Comment #20 from dominiq at lps dot ens dot fr 2010-04-28 08:54 --- I have forgotten to ask my question! Could it be a similar issue to that you fixed for pr42220? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43858
[Bug fortran/43412] [OOP] BT_CLASS does not does not set array spec
--- Comment #1 from burnus at gcc dot gnu dot org 2010-04-28 08:57 --- Created an attachment (id=20505) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20505action=view) coarray_13.f90 test case Depending on this fix are constraint checking for coarrays, cf. attached test case. * * * Current result: allocate(t :: z[*]) 1 Error: Unexpected coarray designator at (1) Reason: gfc_match_array_ref's corank argument is 0. And the argument is sym-as or component-as (cf. primary). * * * class(t), allocatable :: z[:] ! Fails due to sym-attr.allocatable 1 Error: Variable 'z' at (1) is a coarray or has a coarray component and is not ALLOCATABLE, SAVE nor a dummy argument See check in resolve.c's resolve_symbol. And I do not really want to add tons of special cases for BT_CLASS; the check is already quite long: /* F2008, C526. The function-result case was handled above. */ if (((sym-ts.type == BT_DERIVED sym-ts.u.derived-attr.coarray_comp) || sym-attr.codimension) !(sym-attr.allocatable || sym-attr.dummy || sym-attr.save || sym-ns-proc_name-attr.flavor == FL_MODULE || sym-ns-proc_name-attr.is_main_program || sym-attr.function || sym-attr.result || sym-attr.use_assoc)) * * * Possibly related: PR 41539 (also as = NULL). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43412
[Bug target/43920] A lot of instructions for condition (start == -1 || end == -1)
--- Comment #2 from carrot at google dot com 2010-04-28 09:01 --- The expected sequence should be: ... cmp r4, #-1 beq .L4 cmp r0, #-1 beq .L4 ... When changes the options to -march=armv5te -mthumb -Os, gcc can generate the expected codes. This time gcc still generate the same gimple code, but expand to different rtl insns. So we should use the same expand logic as thumb1 in this case. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43920
[Bug libstdc++/43917] [C++0x] std::swap not working
--- Comment #1 from rguenth at gcc dot gnu dot org 2010-04-28 09:07 --- *** Bug 43916 has been marked as a duplicate of this bug. *** -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43917
[Bug libstdc++/43916] std::swap not working with -std=c++0x
--- Comment #1 from rguenth at gcc dot gnu dot org 2010-04-28 09:07 --- *** This bug has been marked as a duplicate of 43917 *** -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43916
[Bug c++/43915] Compiler flags error: error: invalid initialization of reference of type 'boost::thread' from expression of type 'boost::thread'
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|WAITING |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2010-04-28 09:07:45 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43915
[Bug libstdc++/43917] [C++0x] std::swap not working
--- Comment #2 from paolo dot carlini at oracle dot com 2010-04-28 09:09 --- Likely, something is broken in your installation, this problem cannot be reproduced in a sane installation of 4.5.0 or mainline. Note that the std::swap overload for std::pair takes *lvalue* references. -- paolo dot carlini at oracle dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||WORKSFORME http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43917
[Bug libstdc++/43918] gcc 4.5.0 is failing for i586-pc-msdosdjgpp
--- Comment #4 from paolo dot carlini at oracle dot com 2010-04-28 09:12 --- Dave, do you know this target? Is it a supported one? Thanks... -- paolo dot carlini at oracle dot com changed: What|Removed |Added CC||dave dot korn dot cygwin at ||gmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43918
[Bug libstdc++/43785] [C++0x] std::make_pair vs explicit template arguments
--- Comment #19 from paolo dot carlini at oracle dot com 2010-04-28 09:14 --- Closing as invalid, then. -- paolo dot carlini at oracle dot com changed: What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43785
[Bug c++/43911] [4.4/4.5 Regression] g++ can't compile any even trivial c++ source: undefined reference to `_Unwind_GetIPInfo'
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added Known to fail||4.4.3 4.5.0 Summary|[4.4.3/4.5.0 regression] g++|[4.4/4.5 Regression] g++ |can't compile any even |can't compile any even |trivial c++ source: |trivial c++ source: |undefined reference to |undefined reference to |`_Unwind_GetIPInfo' |`_Unwind_GetIPInfo' Target Milestone|--- |4.4.4 Version|unknown |4.4.3 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43911
[Bug bootstrap/42347] [4.5/4.6 Regression] sched-deps.c:3840:1: internal compiler error: in fixup_reorder_chain, at cfglayout.c:796
--- Comment #13 from rguenth at gcc dot gnu dot org 2010-04-28 09:16 --- May be related to PR43740 which also sees cc1 miscompilation but even with release checking. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42347
[Bug c++/43779] Parts of message not available for translation
-- pzhao at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |pzhao at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED Last reconfirmed|2010-04-18 18:24:42 |2010-04-28 09:23:04 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43779
[Bug c++/43911] [4.4/4.5 Regression] g++ can't compile any even trivial c++ source: undefined reference to `_Unwind_GetIPInfo'
--- Comment #11 from rguenth at gcc dot gnu dot org 2010-04-28 09:23 --- _Unwind_GetIPInfo is exported since 4.2.0, the symbol should be objdump -T /lib/libgcc_s.so.1 | grep GetIPI 00013f30 gDF .text 0016 GCC_4.2.0 _Unwind_GetIPInfo what binutils version are you using (why does your libgcc not have symbol versions?) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43911
[Bug bootstrap/43921] New: Bootstrap comparison fails when using -march=atom
When I try to build gcc-4.5 with gcc-4.5 using -march=atom it fails when comparing stage2 and 3: Comparing stages 2 and 3 warning: gcc/cc1plus-checksum.o differs warning: gcc/cc1-checksum.o differs Bootstrap comparison failure! gcc/graphite-interchange.o differs gcc/dwarf2out.o differs gcc/tree-cfg.o differs gcc/gcc.o differs gcc/ipa-struct-reorg.o differs gcc/tree-outof-ssa.o differs gcc/reg-stack.o differs gcc/cgraphbuild.o differs gcc/profile.o differs gcc/sched-rgn.o differs gcc/cfgexpand.o differs gcc/collect2.o differs gcc/sched-ebb.o differs gcc/tree-ssa-ccp.o differs gcc/omega.o differs gcc/tree-if-conv.o differs gcc/tree-vect-slp.o differs gcc/tree-ssa-reassoc.o differs gcc/tree-ssa-structalias.o differs gcc/fortran/trans-io.o differs gcc/fortran/trans.o differs gcc/fortran/arith.o differs gcc/fortran/decl.o differs gcc/tree-ssa-loop-ivopts.o differs gcc/gimple-pretty-print.o differs gcc/tree-switch-conversion.o differs gcc/graph.o differs gcc/cp/call.o differs gcc/c-lex.o differs gcc/opts.o differs gcc/varasm.o differs gcc/tree-vect-loop-manip.o differs gcc/bt-load.o differs gcc/diagnostic.o differs gcc/tree-ssa-live.o differs gcc/tree-ssa-dom.o differs gcc/reload.o differs gcc/tree-parloops.o differs gcc/tree-pretty-print.o differs gcc/params.o differs gcc/builtins.o differs gcc/lto-streamer-in.o differs gcc/sched-deps.o differs gcc/haifa-sched.o differs gcc/cse.o differs gcc/ipa-prop.o differs gcc/c-pragma.o differs gcc/tree-vrp.o differs gcc/c-common.o differs gcc/print-tree.o differs gcc/tree-affine.o differs gcc/graphite-clast-to-gimple.o differs gcc/tree-eh.o differs gcc/c-parser.o differs gcc/tree-phinodes.o differs gcc/tree-data-ref.o differs gcc/lambda-code.o differs gcc/build/gengtype-parse.o differs gcc/ipa-type-escape.o differs gcc/ipa-cp.o differs gcc/tree-inline.o differs libcpp/files.o differs libcpp/traditional.o differs libcpp/lex.o differs libcpp/charset.o differs libiberty/regex.o differs libiberty/pic/regex.o differs make[2]: *** [compare] Fel 1 make[2]: Leaving directory `/tmp/portage/sys-devel/gcc-4.5.0/work/build' make[1]: *** [stage3-bubble] Fel 2 make[1]: Leaving directory `/tmp/portage/sys-devel/gcc-4.5.0/work/build' make: *** [bootstrap-lean] Fel 2 Initially gcc-4.5 was built with gcc-4.4.3 using -march=core2 -mtune=generic. This is my first GCC bug report so I'm not sure what else I need to provide. -- Summary: Bootstrap comparison fails when using -march=atom Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: nisselarsson at home dot se http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43921
[Bug libstdc++/43918] gcc 4.5.0 is failing for i586-pc-msdosdjgpp
-- paolo dot carlini at oracle dot com changed: What|Removed |Added Severity|blocker |normal http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43918
[Bug target/43920] Choosing conditional execution over conditional branches for code size in some cases.
--- Comment #3 from ramana at gcc dot gnu dot org 2010-04-28 09:55 --- Confirmed though it isn't as simple as an expand time problem alone. -- ramana at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Keywords||missed-optimization Known to fail||4.5.0 Last reconfirmed|-00-00 00:00:00 |2010-04-28 09:55:09 date|| Summary|A lot of instructions for |Choosing conditional |condition (start == -1 || |execution over conditional |end == -1) |branches for code size in ||some cases. http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43920
[Bug target/43862] GCC doesn't use 16-bit armv5te multiplies when possible
--- Comment #2 from ramana at gcc dot gnu dot org 2010-04-28 10:06 --- * I don't see why smulbb, smultb, smulbt, smultt shouldn't be generated for their respective cases. So, yes that's correct. * smulwy is not supported in the backend, so that's a feature enhancement * smlawy is again not supported in the backend and anyone implementing this should note that overflow in the accumulate step is a part of the saturated Q bit. Also it isn't correct to be generating smlawy in the cases mentioned there. * smlaxy is something that could be generated in a few of the occasions but the PCS defeats us in these circumstances because we assume that the values passed in are appropriately zero /sign extended. -- ramana at gcc dot gnu dot org changed: What|Removed |Added Severity|normal |enhancement Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Keywords||missed-optimization Known to fail||4.5.0 Last reconfirmed|-00-00 00:00:00 |2010-04-28 10:06:44 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43862
[Bug rtl-optimization/43908] [4.5 only] Unnecessary conditionals
--- Comment #1 from ramana at gcc dot gnu dot org 2010-04-28 10:10 --- On trunk I don't see the movne / moveq problem but the extra mov r3, #1 could be removed. (I think one of Bernd's recent fixes to ifcvt.c fixed these issues). tst r1, #1 mov r3, #1 streq r3, [r0, #4] strne r3, [r0, #0] tst r1, #2 mov r3, #1 streq r3, [r0, #4] strne r3, [r0, #0] tst r1, #4 mov r3, #1 streq r3, [r0, #4] strne r3, [r0, #0] tst r1, #8 mov r3, #1 streq r3, [r0, #4] strne r3, [r0, #0] tst r1, #16 mov r3, #1 streq r3, [r0, #4] strne r3, [r0, #0] tst r1, #32 mov r3, #1 streq r3, [r0, #4] strne r3, [r0, #0] tst r1, #64 mov r3, #1 streq r3, [r0, #4] strne r3, [r0, #0] tst r1, #128 mov r3, #1 strne r3, [r0, #0] streq r3, [r0, #4] bx lr -- ramana at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Keywords||missed-optimization Known to fail||4.5.0 Last reconfirmed|-00-00 00:00:00 |2010-04-28 10:10:19 date|| Summary|Very poor code generation |[4.5 only] Unnecessary |(unnecessary conditionals |conditionals |and reloads) for ARM| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43908
[Bug middle-end/43880] [4.5/4.6 Regression] internal compiler error: in make_decl_rtl
--- Comment #6 from rguenth at gcc dot gnu dot org 2010-04-28 10:28 --- Subject: Bug 43880 Author: rguenth Date: Wed Apr 28 10:28:24 2010 New Revision: 158824 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=158824 Log: 2010-04-28 Richard Guenther rguent...@suse.de PR c++/43880 * tree-inline.c (copy_bind_expr): Also copy bind expr vars value-exprs. * g++.dg/torture/pr43880.C: New testcase. Added: trunk/gcc/testsuite/g++.dg/torture/pr43880.C Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-inline.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43880
[Bug middle-end/43880] [4.5 Regression] internal compiler error: in make_decl_rtl
--- Comment #7 from rguenth at gcc dot gnu dot org 2010-04-28 10:28 --- Fixed for 4.6 sofar. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Known to work|4.4.3 |4.4.3 4.6.0 Summary|[4.5/4.6 Regression]|[4.5 Regression] internal |internal compiler error: in |compiler error: in |make_decl_rtl |make_decl_rtl http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43880
[Bug libgomp/39098] FAIL: libgomp.fortran/reduction3.f90
--- Comment #4 from ramana at gcc dot gnu dot org 2010-04-28 10:38 --- (In reply to comment #3) Subject: Re: FAIL: libgomp.fortran/reduction3.f90 Does it work without -fopenmp? Yes. Dave Does this still fail ? Recent testresults don't show this failure in libgomp. Ramana -- ramana at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39098
[Bug c++/43915] Compiler flags error: error: invalid initialization of reference of type 'boost::thread' from expression of type 'boost::thread'
--- Comment #5 from redi at gcc dot gnu dot org 2010-04-28 11:15 ---
I think this error is correct:
./boost/thread/pthread/thread_heap_alloc.hpp: In function 'T*
boost::detail::heap_new(A1) [with T = boost::detail::thread_datavoid (*)(),
A1 = void (*)()]':
./boost/thread/detail/thread.hpp:130:95: instantiated from here
./boost/thread/pthread/thread_heap_alloc.hpp:24:47: error: cannot bind 'void
(*)()' lvalue to 'void (*)()'
./boost/thread/detail/thread.hpp:43:13: error: initializing argument 1 of
'boost::detail::thread_dataF::thread_data(F) [with F = void (*)()]'
A1 is deduced as an lvalue-reference, so reference-collapsing means that
static_castA1 is a cast to an lvalue-reference, which won't bind to the
rvalue-reference parameter.
And I also think this error is correct:
./boost/thread/detail/thread.hpp: In function 'boost::thread
boost::move(boost::thread)':
./boost/thread/detail/thread.hpp:349:16: error: invalid initialization of
reference of type 'boost::thread' from expression of type 'boost::thread'
Although the diagnostic is misleading. The code is:
inline thread move(thread t)
{
return t;
}
At the point of return 't' is an lvalue so to return it as an rvalue it needs
to be static_castthread(t)
I think this is INVALID
--
redi at gcc dot gnu dot org changed:
What|Removed |Added
CC||redi at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43915
[Bug lto/40702] lto-elf.c fails to compile on Solaris
--- Comment #7 from ro at CeBiTec dot Uni-Bielefeld dot DE 2010-04-28 11:16 --- Subject: Re: lto-elf.c fails to compile on Solaris --- Comment #5 from rguenth at gcc dot gnu dot org 2010-04-23 14:34 --- What's the status of this bug? I haven't checked anything before Solaris 10 yet (still have to set up my test sustems), but mainline is fine since the native libelf can be used. I haven't pushed the libelf 0.8.12 patch upstream yet, but there isn't much use if the native library can be used. The 4.5 branch is still affected until the elf_getshdrstrndx has been backported. Btw., what's the status with Honza's problem with that? I haven't heard anything yet, but would like to have this sorted out before backporting. Rainer -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40702
[Bug c++/43915] Compiler flags error: error: invalid initialization of reference of type 'boost::thread' from expression of type 'boost::thread'
--- Comment #6 from redi at gcc dot gnu dot org 2010-04-28 11:17 --- In this diagnostic: invalid initialization of reference of type 'boost::thread' from expression of type 'boost::thread' it might be clearer if the latter type was given as 'boost::thread' so that it's clear it is an lvalue, otherwise it looks like it is failing to bind an rvalue-reference to a temporary, which should work. In fact it's try to bind the reference to an lvalue, which is invalid -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43915
[Bug c++/43922] New: internal compiler error: in copy_body_r, at tree-inline.c:748 when compiling with -fopenmp
After some recent changes to our code we observed that g++ fails with ICE when compiled with -fopenmp. The error occurs only with the 4.3.4 compiler, 4.4.1 works. g++-4.3 -v Using built-in specs. Target: x86_64-linux-gnu Configured with: ../src/configure -v --with-pkgversion='Ubuntu 4.3.4-5ubuntu1' --with-bugurl=file:///usr/share/doc/gcc-4.3/README.Bugs --enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr --enable-shared --enable-multiarch --enable-linker-build-id --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --enable-nls --with-gxx-include-dir=/usr/include/c++/4.3 --program-suffix=-4.3 --enable-clocale=gnu --enable-libstdcxx-debug --enable-objc-gc --enable-mpfr --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.3.4 (Ubuntu 4.3.4-5ubuntu1) Command Line /usr/bin/g++-4.3 -DOpenMS_EXPORTS -DQT_DLL -DQT_OPENGL_LIB -DQT_GUI_LIB -DQT_TEST_LIB -DQT_XML_LIB -DQT_SQL_LIB -DQT_NETWORK_LIB -DQT_CORE_LIB -DQT_DLL -DQT_OPENGL_LIB -DQT_GUI_LIB -DQT_TEST_LIB -DQT_XML_LIB -DQT_SQL_LIB -DQT_NETWORK_LIB -DQT_CORE_LIB -DQT_NO_DEBUG -DQT_NO_DEBUG -fopenmp -O3 -DNDEBUG -fPIC -I/home/aiche/dev/openms-src/include -I/home/aiche/dev/openms-bin-4.3/include -I/home/aiche/dev/contrib-bin-4.3/include -I/usr/include/qt4 -I/usr/include/qt4/QtOpenGL -I/usr/include/qt4/QtGui -I/usr/include/qt4/QtTest -I/usr/include/qt4/QtXml -I/usr/include/qt4/QtSql -I/usr/include/qt4/QtNetwork -I/usr/include/qt4/QtCore -Wall -Wextra -Wno-non-virtual-dtor -Wno-long-long --pedantic -fPIC -o CMakeFiles/OpenMS.dir/source/TRANSFORMATIONS/FEATUREFINDER/FeatureFinder.C.o -c /home/aiche/dev/openms-src/source/TRANSFORMATIONS/FEATUREFINDER/FeatureFinder.C Error Message /home/aiche/dev/openms-src/include/OpenMS/TRANSFORMATIONS/FEATUREFINDER/BaseModel.h: In member function void OpenMS::BaseModelD::setCutOff(OpenMS::DoubleReal) [with unsigned int D = 2u]: /home/aiche/dev/openms-src/include/OpenMS/TRANSFORMATIONS/FEATUREFINDER/BaseModel.h:128: internal compiler error: in copy_body_r, at tree-inline.c:748 I attach the preprocessed files. -- Summary: internal compiler error: in copy_body_r, at tree- inline.c:748 when compiling with -fopenmp Product: gcc Version: 4.3.4 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: stephan dot aiche at fu-berlin dot de GCC target triplet: x86_64-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43922
[Bug c++/43922] internal compiler error: in copy_body_r, at tree-inline.c:748 when compiling with -fopenmp
--- Comment #1 from stephan dot aiche at fu-berlin dot de 2010-04-28 11:23 --- The preprocessed file is to big for bugzille but it can be downloaded here http://page.mi.fu-berlin.de/aiche/FeatureFinder.ii -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43922
[Bug libstdc++/43918] gcc 4.5.0 is failing for i586-pc-msdosdjgpp
--- Comment #5 from redi at gcc dot gnu dot org 2010-04-28 11:28 --- DJ Delorie is the port maintainer. The patch needs (at least) the right copyright dates -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43918
[Bug libstdc++/43918] gcc 4.5.0 is failing for i586-pc-msdosdjgpp
--- Comment #6 from paolo dot carlini at oracle dot com 2010-04-28 11:35 --- Ah, thanks. Let's add DJ in CC, otherwise, as far as I'm concerned, the patch could go also in 4_5-branch (dates fixed of course). -- paolo dot carlini at oracle dot com changed: What|Removed |Added CC|suresh dot gumpula at amd |dj at redhat dot com |dot com | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43918
[Bug c++/43915] Compiler flags error: error: invalid initialization of reference of type 'boost::thread' from expression of type 'boost::thread'
--- Comment #7 from redi at gcc dot gnu dot org 2010-04-28 11:40 --- N.B. I stopped testing boost trunk against gcc trunk ages ago and I don't think anyone does it these days, which means that boost releases often don't work with GCC versions that come out after the release, especially if they are using the experimental C++0x support. According to http://www.boost.org/users/news/version_1_42_0 Boost 1.42 was not tested with anything newer than 4.4.3 so it's unsurprising it doesn't use the new rvalue-reference rules that 4.5.0 implements This should be reported as a bug against Boost -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43915
[Bug c++/43915] Compiler flags error: error: invalid initialization of reference of type 'boost::thread' from expression of type 'boost::thread'
--- Comment #8 from redi at gcc dot gnu dot org 2010-04-28 11:46 --- (In reply to comment #6) In this diagnostic: invalid initialization of reference of type 'boost::thread' from expression of type 'boost::thread' it might be clearer if the latter type was given as 'boost::thread' so that it's clear it is an lvalue, otherwise it looks like it is failing to bind an rvalue-reference to a temporary, which should work. Even better, the diagnostic could say ... from lvalue expression of type ... Any change should probably wait until the dust settles on the lvalue/xvalue/prvalue taxonomy -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43915
[Bug tree-optimization/43879] -fipa-pta causes various miscompilations
--- Comment #5 from rguenth at gcc dot gnu dot org 2010-04-28 11:51 --- Subject: Bug 43879 Author: rguenth Date: Wed Apr 28 11:51:31 2010 New Revision: 158825 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=158825 Log: 2010-04-28 Richard Guenther rguent...@suse.de PR tree-optimization/43879 PR tree-optimization/43909 * tree-ssa-structalias.c (struct variable_info): Add only_restrict_pointers flag. (new_var_info): Initialize it. Increment stats.total_vars here. (create_function_info_for): Do not increment stats.total_vars here. (get_function_part_constraint): Fix build with C++. (insert_into_field_list): Remove. (push_fields_onto_fieldstack): Properly merge fields. (create_variable_info_for): Split and simplify. (create_variable_info_for_1): New piece. (intra_create_variable_infos): Properly make restrict constraints from parameters. * gcc.dg/ipa/ipa-pta-14.c: Adjust. Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.dg/ipa/ipa-pta-14.c trunk/gcc/tree-ssa-structalias.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43879
[Bug c++/43909] trunk rev158780. compile with --enable-build-with-cxx fails in get_function_part_constraint
--- Comment #2 from rguenth at gcc dot gnu dot org 2010-04-28 11:51 --- Subject: Bug 43909 Author: rguenth Date: Wed Apr 28 11:51:31 2010 New Revision: 158825 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=158825 Log: 2010-04-28 Richard Guenther rguent...@suse.de PR tree-optimization/43879 PR tree-optimization/43909 * tree-ssa-structalias.c (struct variable_info): Add only_restrict_pointers flag. (new_var_info): Initialize it. Increment stats.total_vars here. (create_function_info_for): Do not increment stats.total_vars here. (get_function_part_constraint): Fix build with C++. (insert_into_field_list): Remove. (push_fields_onto_fieldstack): Properly merge fields. (create_variable_info_for): Split and simplify. (create_variable_info_for_1): New piece. (intra_create_variable_infos): Properly make restrict constraints from parameters. * gcc.dg/ipa/ipa-pta-14.c: Adjust. Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.dg/ipa/ipa-pta-14.c trunk/gcc/tree-ssa-structalias.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43909
[Bug c++/43909] trunk rev158780. compile with --enable-build-with-cxx fails in get_function_part_constraint
--- Comment #3 from rguenth at gcc dot gnu dot org 2010-04-28 11:52 --- Fixed. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43909
[Bug lto/40702] lto-elf.c fails to compile on Solaris
--- Comment #8 from rguenth at gcc dot gnu dot org 2010-04-28 11:55 --- I'm not sure, let's as honza. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC||hubicka at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40702
[Bug target/43729] Mach-O LTO support needed for darwin
--- Comment #13 from dominiq at lps dot ens dot fr 2010-04-28 12:20 --- proof-of-concept patch Great!-) Thanks a lot. Besides the 17 C failures, for all languages but ADA, I also see FAIL: g++.dg/lto/20100302 cp_lto_20100302_0.o-cp_lto_20100302_1.o link and FAIL: gcc.c-torture/execute/cmpdi-1.c compilation, -O3 -g FAIL: gfortran.dg/array_constructor_11.f90 -O3 -g (internal compiler error) but they are probably unrelated. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43729
[Bug tree-optimization/43879] -fipa-pta causes various miscompilations
--- Comment #6 from rguenth at gcc dot gnu dot org 2010-04-28 12:53 --- Real miscompiles prevailing: === libstdc++ tests === Running target unix/-fipa-pta/ FAIL: 20_util/shared_ptr/thread/default_weaktoshared.cc execution test FAIL: 23_containers/bitset/cons/1.cc execution test FAIL: 23_containers/bitset/operations/1.cc execution test FAIL: 23_containers/bitset/to_ullong/1.cc execution test WARNING: program timed out. WARNING: program timed out. FAIL: tr1/2_general_utilities/shared_ptr/thread/default_weaktoshared.cc executio n test -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43879
[Bug lto/40702] lto-elf.c fails to compile on Solaris
--- Comment #9 from hubicka at gcc dot gnu dot org 2010-04-28 13:01 --- Hmm, I am not at all sure what problem I should have with this? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40702
[Bug target/43729] Mach-O LTO support needed for darwin
--- Comment #14 from dominiq at lps dot ens dot fr 2010-04-28 13:04 --- Note also that the polyhedron test aermod.f90 fails with -flto or -whopr at any level of optimization with: ld: in /var/tmp//ccDGk6QZ.o, in section __TEXT,__text reloc 17: local relocation for address 0x000E58F4 in section __text does not target section __0B61 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43729
[Bug tree-optimization/43846] [4.5 Regression] array vs members, total scalarization issues
--- Comment #6 from jamborm at gcc dot gnu dot org 2010-04-28 13:10 --- Subject: Bug 43846 Author: jamborm Date: Wed Apr 28 13:09:56 2010 New Revision: 158826 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=158826 Log: 2010-04-28 Martin Jambor mjam...@suse.cz PR tree-optimization/43846 * tree-sra.c (struct access): New flag grp_assignment_read. (build_accesses_from_assign): Set grp_assignment_read. (sort_and_splice_var_accesses): Propagate grp_assignment_read. (enum mark_read_status): New type. (analyze_access_subtree): Propagate grp_assignment_read, create accesses also if both direct_read and root-grp_assignment_read. * testsuite/gcc.dg/tree-ssa/sra-10.c: New test. Added: branches/gcc-4_5-branch/gcc/testsuite/gcc.dg/tree-ssa/sra-10.c Modified: branches/gcc-4_5-branch/gcc/ChangeLog branches/gcc-4_5-branch/gcc/testsuite/ChangeLog branches/gcc-4_5-branch/gcc/tree-sra.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43846
[Bug tree-optimization/43846] [4.5 Regression] array vs members, total scalarization issues
--- Comment #7 from jamborm at gcc dot gnu dot org 2010-04-28 13:15 --- This is now fixed on both the trunk and the 4.5 branch. -- jamborm at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43846
[Bug bootstrap/43858] [4.6 Regression] Bootstrap failure for powerpc-apple-darwin9: cannot compute suffix of object files
--- Comment #21 from dominiq at lps dot ens dot fr 2010-04-28 13:19 --- Two questions - are you sure you didn't reverse the _w and _f files (i.e. maybe _f is the working version and _w the failing one)? I have double checked and I confirm that the *_f.* files are coming from the failing bootstrap. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43858
[Bug lto/41376] collect2 does not handle static libraries
--- Comment #2 from davek at gcc dot gnu dot org 2010-04-28 13:38 --- Quoting RG from the gcc list: [ ... ] Or you fix collect2 to do processing of archives and hand lto1 the required information (it expects archive components with LTO bytecode like archiv...@offset with offset being the offset of the .o file with LTO bytecode inside the archive). See lto/lto-elf.c:lto_obj_file_open for details. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41376
[Bug tree-optimization/43846] [4.5 Regression] array vs members, total scalarization issues
--- Comment #8 from tbptbp at gmail dot com 2010-04-28 13:43 --- Allow me to extend to you my most profuse praises and blessing; may all the woman in your vicinity fall pregnant and your male progeny be granted abounding chest hair. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43846
[Bug target/43921] Bootstrap comparison fails when using -march=atom
-- hjl dot tools at gmail dot com changed: What|Removed |Added CC|hjl at gcc dot gnu dot org |hjl dot tools at gmail dot ||com Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2010-04-28 13:52:07 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43921
[Bug bootstrap/43858] [4.6 Regression] Bootstrap failure for powerpc-apple-darwin9: cannot compute suffix of object files
--- Comment #22 from bernds at codesourcery dot com 2010-04-28 13:59 --- (In reply to comment #20) I have forgotten to ask my question! Could it be a similar issue to that you fixed for pr42220? No, that looks completely unrelated at first glance. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43858
[Bug tree-optimization/43924] New: [4.6 Regression] FAIL: gfortran.dg/array_constructor_11.f90 -O3 -g (internal compiler error)
Since revision 158788 (see http://gcc.gnu.org/ml/gcc-regression/2010-04/msg00294.html) gfortran.dg/array_constructor_11.f90 fails with '-O3 -g' with: /opt/gcc/_clean/gcc/testsuite/gfortran.dg/array_constructor_11.f90:6:0: internal compiler error: in output_die, at dwarf2out.c:10649 -- Summary: [4.6 Regression] FAIL: gfortran.dg/array_constructor_11.f90 -O3 -g (internal compiler error) Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: dominiq at lps dot ens dot fr http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43924
[Bug lto/40702] lto-elf.c fails to compile on Solaris
--- Comment #10 from ro at CeBiTec dot Uni-Bielefeld dot DE 2010-04-28 14:40 --- Subject: Re: lto-elf.c fails to compile on Solaris --- Comment #9 from hubicka at gcc dot gnu dot org 2010-04-28 13:01 --- Hmm, I am not at all sure what problem I should have with this? In http://gcc.gnu.org/ml/gcc-patches/2010-04/msg01179.html Richard reported that you had a problem with the patch that introduced an elf_getshdrstrndx replacement for the benefit of older Solaris releases, but I wonder how the error reported can happen. Thanks. Rainer -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40702
[Bug fortran/42958] Weird temporary array allocation
--- Comment #18 from rguenth at gcc dot gnu dot org 2010-04-28 14:52
---
Updating the status on this bugreport. I am working on middle-end support
for hoisting/sinking malloc/free pairs out of loops (in case the size is
loop invariant). The Fortran FE makes this somewhat difficult.
For
subroutine test0(esss,Ix)
integer(kind=kind(1)), dimension(:), pointer :: esss
integer(kind=kind(1)), dimension(:), pointer :: Ix
esss = Ix + Ix
end subroutine
It creates
D.1552 = ix-dim[0].lbound;
D.1553 = ix-dim[0].ubound;
...
D.1562 = D.1553 - D.1552;
...
D.1571 = D.1562 0;
D.1572 = D.1562 + 1;
D.1573 = D.1571 ? 0 : D.1572 * 4;
D.1574 = (void * restrict) __builtin_malloc (MAX_EXPR D.1573, 1);
D.1575 = D.1574;
atmp.0.data = D.1575;
...
{
...
S.1 = 0;
while (1)
{
if (S.1 D.1562) goto L.1;
...
}
L.1:;
S.1 = 0;
while (1)
{
if (S.1 D.1562) goto L.2;
...
}
L.2:;
}
{
void * D.1576;
D.1576 = (void *) atmp.0.data;
if (D.1576 != 0B)
{
__builtin_free (D.1576);
}
}
two unfortunate facts remain.
1) __builtin_free is executed conditionally even though free(0) is
well-defined
2) __builtin_malloc (MAX_EXPR D.1571 ? 0 : D.1572 * 4, 1) later causes DOM
to jump-thread this into two malloc calls, one malloc(1) and one malloc(D.1573)
especially the latter is very hard to get rid of at the tree level later
(the conditional free can possibly be made unconditional by optimizers).
Thus I would request that for the purpose of allocating array temporaries
from the scalarizer you
1) unconditionally free the memory
2) drop the MAX_EXPR, malloc (0) is well-defined and we can just fold that to
NULL if DOM still thinks to jump-thread that
3) for the same reason you can also drop the + 1 in computing the allocation
size which is currently (ubound - lbound + 1) * 4
even better would be to guard the allocation by the loop entry check
(thus ubound - lbound = 0)
If that's all acceptable I will work on this soon.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |rguenth at gcc dot gnu dot
|dot org |org
Status|NEW |ASSIGNED
Last reconfirmed|2010-03-27 18:55:47 |2010-04-28 14:52:15
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42958
[Bug tree-optimization/43879] -fipa-pta causes various miscompilations
--- Comment #7 from zsojka at seznam dot cz 2010-04-28 15:09 --- Created an attachment (id=20507) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20507action=view) first part of reduced testcase second part to follow -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43879
[Bug tree-optimization/43879] -fipa-pta causes various miscompilations
--- Comment #8 from zsojka at seznam dot cz 2010-04-28 15:12 --- Created an attachment (id=20508) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20508action=view) second part of reduced testcase These testcases demonstrate what happens in cfgrtl.c, why is cfg_layout_merge_blocks miscompiled: ((a)-il.rtl-end_)-code is expected not to change during call to try_redirect_by_replacing_jump() Command line to demonstrate: $ gcc -O[123s] -fipa-pta pr43879.c pr43879-2.c ./a.out Aborted -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43879
[Bug fortran/42958] Weird temporary array allocation
--- Comment #19 from amonakov at gcc dot gnu dot org 2010-04-28 15:15 --- (In reply to comment #18) 3) for the same reason you can also drop the + 1 in computing the allocation size which is currently (ubound - lbound + 1) * 4 Sorry, but isn't +1 needed because bounds are inclusive? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42958
[Bug fortran/42958] Weird temporary array allocation
--- Comment #20 from jv244 at cam dot ac dot uk 2010-04-28 15:20 --- (In reply to comment #18) If that's all acceptable I will work on this soon. FYI, this would fix PR38318 and PR21046 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42958
[Bug fortran/42958] Weird temporary array allocation
--- Comment #21 from jb at gcc dot gnu dot org 2010-04-28 15:43 --- (In reply to comment #19) (In reply to comment #18) 3) for the same reason you can also drop the + 1 in computing the allocation size which is currently (ubound - lbound + 1) * 4 Sorry, but isn't +1 needed because bounds are inclusive? Yes. As an aside, for the 4.6 array descriptor update, there has been some discussion to move from the current (lbound, ubound, stride) triplet for every dimension to (lbound, stride, extent). Which would change these kinds of expressions. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42958
[Bug middle-end/14192] Restrict pointers don't help
--- Comment #13 from alexey dot salmin at gmail dot com 2010-04-28 15:53
---
Sorry, but I still don't get it :( Why exactly we can't remove the second load
of *b?
void f(int *a, const int *restrict b) {
*a++ = *b + 1;
*a++ = *b + 1;
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14192
[Bug target/22224] Several Tru64 UNIX testsuite failures: Length of .lcomm was less than 1
--- Comment #3 from ro at gcc dot gnu dot org 2010-04-28 16:24 --- Subject: Bug 4 Author: ro Date: Wed Apr 28 16:24:28 2010 New Revision: 158831 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=158831 Log: PR target/4 * config/alpha/osf5.h (ASM_OUTPUT_LOCAL): Redefine. Modified: trunk/gcc/ChangeLog trunk/gcc/config/alpha/osf5.h -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=4
[Bug target/22224] Several Tru64 UNIX testsuite failures: Length of .lcomm was less than 1
--- Comment #4 from ro at gcc dot gnu dot org 2010-04-28 16:26 --- Subject: Bug 4 Author: ro Date: Wed Apr 28 16:26:24 2010 New Revision: 158832 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=158832 Log: PR target/4 * config/alpha/osf.h (ASM_OUTPUT_LOCAL): Redefine. Modified: branches/gcc-4_5-branch/gcc/ChangeLog branches/gcc-4_5-branch/gcc/config/alpha/osf.h -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=4
[Bug target/22224] Several Tru64 UNIX testsuite failures: Length of .lcomm was less than 1
--- Comment #5 from ro at gcc dot gnu dot org 2010-04-28 16:28 --- Fixed for 4.5.1, 4.6.0. -- ro at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Known to fail|4.5.0 4.6.0 | Known to work||4.5.1 4.6.0 Resolution||FIXED Target Milestone|--- |4.5.1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=4
[Bug bootstrap/43858] [4.6 Regression] Bootstrap failure for powerpc-apple-darwin9: cannot compute suffix of object files
--- Comment #23 from howarth at nitro dot med dot uc dot edu 2010-04-28 16:50 --- Dominique, Are you saying you regression hunted and this was triggered by... Author: bernds Date: Thu Apr 22 11:47:52 2010 New Revision: 158643 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=158643 Log: * optabs.h (expand_widening_mult): Declare. Modified: trunk/gcc/ChangeLog trunk/gcc/optabs.h -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43858
[Bug bootstrap/43858] [4.6 Regression] Bootstrap failure for powerpc-apple-darwin9: cannot compute suffix of object files
--- Comment #24 from dominiq at lps dot ens dot fr 2010-04-28 17:07 --- Are you saying you regression hunted and this was triggered by... Author: bernds Date: Thu Apr 22 11:47:52 2010 New Revision: 158643 No. If you read the thread, it was due to revision 158639 (see comment #6). However in order to reach this conclusion, you need to apply revision 158643 in order to fix a previous bootstrap failure. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43858
[Bug testsuite/43925] New: Plugin tests unresolved on IRIX 6.5: libintl.h: No such file or directory
I've just noticed that all plugin tests are UNRESOLVED on IRIX 6.5, with the following error: UNRESOLVED: attribute_plugin.c compilation, -I. -I/vol/gcc/src/hg/trunk/local/g cc/testsuite -I/vol/gcc/src/hg/trunk/local/gcc/testsuite/../../gcc -I/vol/gcc/ob j/regression/trunk/6.5-gcc/build/gcc/testsuite/g++/../../../gcc -I/vol/gcc/src/ hg/trunk/local/gcc/testsuite/../../include -I/vol/gcc/src/hg/trunk/local/gcc/tes tsuite/../../libcpp/include -I/vol/gcc/include -I/vol/gcc/include -I/vol/gcc/in clude -DIN_GCC -fPIC -shared In file included from /vol/gcc/src/hg/trunk/local/gcc/testsuite/g++.dg/plugin/attribute_plugin.c:10:0: /vol/gcc/src/hg/trunk/local/gcc/testsuite/../../gcc/intl.h:31:21: fatal error: libintl.h: No such file or directory compilation terminated. Obviously, the -I$top_builddir/intl is missing to find libintl.h, unlike e.g. the gcc Makefile. -- Summary: Plugin tests unresolved on IRIX 6.5: libintl.h: No such file or directory Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: testsuite AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: ro at gcc dot gnu dot org GCC build triplet: mips-sgi-irix6.5 GCC host triplet: mips-sgi-irix6.5 GCC target triplet: mips-sgi-irix6.5 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43925
[Bug libstdc++/43917] [C++0x] std::swap not working
--- Comment #3 from navin dot kumar at gmail dot com 2010-04-28 17:43
---
Are you compiling with -std=c++0x or without? It compiles fine without the
-std=c++0x flag. The issue is when it is supplied.
Look at line 134 of include/c++/4.5.0/bits/stl_pair.h; inside a #ifdef
__GXX_EXPERIMENTAL_CXX0X__ tag there is the following function:
void
swap(pair __p)
{
using std::swap;
swap(first, __p.first);
swap(second, __p.second);
}
The compiler error stems from trying to pass a pair l-value reference to
pair.
Here's the compiler error with line numbers:
include/c++/4.5.0/bits/stl_pair.h: In function void std::swap(std::pair_T1,
_T2, std::pair_T1, _T2) [with _T1 = std::basic_stringchar, _T2 =
std::basic_stringchar]:
test.cpp:8:19: instantiated from here
include/c++/4.5.0/bits/stl_pair.h:187:7: error: cannot bind
std::pairstd::basic_stringchar, std::basic_stringchar lvalue to
std::pairstd::basic_stringchar, std::basic_stringchar
include/c++/4.5.0/bits/stl_pair.h:134:7: error: initializing argument 1 of
void std::pair_T1, _T2::swap(std::pair_T1, _T2) [with _T1 =
std::basic_stringchar, _T2 = std::basic_stringchar, std::pair_T1, _T2 =
std::pairstd::basic_stringchar, std::basic_stringchar ]
--
navin dot kumar at gmail dot com changed:
What|Removed |Added
Status|RESOLVED|UNCONFIRMED
Resolution|WORKSFORME |
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43917
[Bug bootstrap/43870] ICE in gcc/config/soft-fp/divtf3.c
--- Comment #4 from ro at CeBiTec dot Uni-Bielefeld dot DE 2010-04-28 17:51 --- Subject: Re: ICE in gcc/config/soft-fp/divtf3.c gcc-tgc at jupiterrise dot com gcc-bugzi...@gcc.gnu.org writes: Program received signal SIGSEGV, Segmentation fault. 0x084bd3c5 in df_ref_compare (r1=0xa3278a4, r2=0xa3278ac) at /export/home/tgc/source/gcc-4.5.0/gcc/df-scan.c:2357 2357 if (DF_REF_CLASS (ref1) != DF_REF_CLASS (ref2)) (gdb) bt #0 0x084bd3c5 in df_ref_compare (r1=0xa3278a4, r2=0xa3278ac) at /export/home/tgc/source/gcc-4.5.0/gcc/df-scan.c:2357 #1 0xdf89b889 in qsort () from /usr/lib/libc.so.1 This is most likely another instance of the qsort problem that has already bitten us in PR tree-optimization/42157. Rainer -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43870
[Bug middle-end/39883] preprocessor fails with myassertion
--- Comment #3 from ro at CeBiTec dot Uni-Bielefeld dot DE 2010-04-28 18:00 --- Subject: Re: preprocessor fails with myassertion --- Comment #1 from steven at gcc dot gnu dot org 2010-04-23 22:43 --- This one appears to have fallen through the cracks. Reported exactly one year ago, and now accidentally shows up in my search because my brain believed we still live in 2009... Oh well. I'll try to go through the Solaris bugs in the near future, but have concentrated on getting the 4.5 release in shape until now. Rainer, could you see if you can confirm this one (with 4.4/4.5/trunk)? I don't have a 4.4 tree around at the moment, but the testcase works fine on both 4.5 and mainline *with a sparc-sun-solaris2.10* compiler. The problem might be related to the sparc64-sun-solaris2.8 configuration, but I refuse to test that because I simply don't have the manpower to double testing effort when a 32-bit default bi-arch compiler handles this just fine. I'd rather remove the sparcv9-sun-solaris2.* configuration than deal with this. Could the warning: GMP header version 4.3 differs from library version 4.3.0. have something to do with the segfault? I doubt that, actually, though I haven't checked GMP versioning in detail. Maybe Eric has a sparcv9 compiler around and can easily check this? Rainer -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39883
[Bug bootstrap/43733] bootstrap fails on Solaris 10 x86 with GNU as 2.15 and --with-arch=core2
--- Comment #22 from ro at gcc dot gnu dot org 2010-04-28 18:13 --- (In reply to comment #20) I don't think it should be closed: the installation docs for Solaris x86 recommend to use the default binutils 2.15 and say it works fine, but that's not the case if you use --with-arch=core2, that should be documented (or even better, fixed) I think there are different issues here: gas 2.15 works fine *in a default configuration*. Once you start messing around with --with-arch, you can probably easily fine an arch value that this ancient gas (8 years by now) doesn't support. I don't think it's useful to document every possible variation here, especially since install.texi clearly states that current gas 2.20.1 works, too. The other (and primary) issue probably is that --with-arch=core2 might simply be wrong for a bi-arch compiler (as is --with-arch=pentium4). Could you try this with --with-arch-32=core2 instead? -- ro at gcc dot gnu dot org changed: What|Removed |Added CC||ro at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43733
[Bug target/43426] dlsym: invalid version 5 (max 0)
--- Comment #2 from ro at gcc dot gnu dot org 2010-04-28 18:19 --- (In reply to comment #0) gcc -DSQLITE_THREADSAFE=0 -DSQLITE_ENABLE_FTS3 -DSQLITE_ENABLE_RTREE -mtune=niagara -mcpu=niagara -m64 -m64 -m64 -m64 -o .libs/sqlite3 shell.o -L/usr/lib/sparcv9 ./.libs/libsqlite3.so -lreadline -lcurses -Wl,--rpath -Wl,/usr/local/lib /usr/shared-apps/lib/gcc/sparc-sun-solaris2.10/4.4.3/../../../../sparc-sun-solaris2.10/bin/ld: ./.libs/libsqlite3.so: dlsym: invalid version 5 (max 0) This is a GNU ld error message. You might want to report this to the binutils maintainers. Gcc options are: tchaikovski:[~/rpl/build/tools/sqlite-3.6.22] gcc -v Using built-in specs. Target: sparc-sun-solaris2.10 Configured with: ../gcc-4.4.3/configure --prefix=/usr/shared-apps --enable-languages=c,c++,fortran --enable-shared --enable-threads=posix --enable-nls --enable-checking=release --with-mpfr=/usr/shared-apps/ --with-gnu-ld --enable-bootstrap Thread model: posix gcc version 4.4.3 (GCC) I have checked mpfr and gmp and I use binutils 2.20.1. Please try this without --with-gnu-ld (and GNU ld as ld in PATH), as recommended in the installation instructions. On another sparc server (sun4u, dual UltraSPARC-III) running debian/squeeze with gcc-4.4 (gcc version 4.4.3 20100108), I cannot reproduce this bug. Irrelevant since this is a completely different OS. -- ro at gcc dot gnu dot org changed: What|Removed |Added CC||ro at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43426
[Bug c++/43915] Compiler flags error: error: invalid initialization of reference of type 'boost::thread' from expression of type 'boost::thread'
--- Comment #9 from mlrus at mac dot com 2010-04-28 18:20 --- Appended status to booost bug 3944 http://svn.boost.org/trac/boost/ticket/3844 -- mlrus at mac dot com changed: What|Removed |Added Status|NEW |SUSPENDED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43915
[Bug c++/31512] function template with member reference compile failure
--- Comment #2 from redi at gcc dot gnu dot org 2010-04-28 18:23 --- all three forms compile ok with 4.4.3 or 4.6.0 -- redi at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31512
[Bug target/43921] Bootstrap comparison fails when using -march=atom
--- Comment #1 from hjl dot tools at gmail dot com 2010-04-28 18:24 --- A patch is posed at http://gcc.gnu.org/ml/gcc-patches/2010-04/msg01755.html -- hjl dot tools at gmail dot com changed: What|Removed |Added URL||http://gcc.gnu.org/ml/gcc- ||patches/2010- ||04/msg01755.html http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43921
[Bug target/43324] core dump on throw
--- Comment #3 from ro at gcc dot gnu dot org 2010-04-28 18:35 --- I couldn't reproduce this so far, neither on the 4.4 branch nor on mainline. OTOH, I don't have snv_111b available here, but know that there are EH issues on Solaris 11/x86. I've posted a patch which works for snv_130/134, but didn't on snv_127 and breaks Solaris 10, so I've got more investigation to do: PATCH: Fix Solaris 11/x86 MD_FALLBACK_FRAME_STATE_FOR http://gcc.gnu.org/ml/gcc-patches/2010-02/msg00994.html -- ro at gcc dot gnu dot org changed: What|Removed |Added CC||ro at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43324
[Bug libstdc++/43259] ext/profile/all.cc fails on Solaris
--- Comment #12 from ro at gcc dot gnu dot org 2010-04-28 18:36 --- Any progress on this? The bug is open for almost 2 months now. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43259
[Bug bootstrap/43733] bootstrap fails on Solaris 10 x86 with GNU as 2.15 and --with-arch=core2
--- Comment #23 from redi at gcc dot gnu dot org 2010-04-28 18:38 --- core2 works fine for bi-arch linux builds, but I'll try your suggestion on Solaris asap I assume it will work, but 64bit code will not use the core2 instructions, which might be suboptimal (I want to use the cpu to the full potential!) I imagine it's also possible for the same problem to occur using -march=native, if the processor flags indicate core2 instructions will work. That said, 2.15 is an ancient gas (even though it's very common on Solaris 10) so I'm not too worried about this bug being fixed and I agree it's not worth changing the config docs. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43733
[Bug libstdc++/43917] [C++0x] std::swap not working
--- Comment #4 from redi at gcc dot gnu dot org 2010-04-28 18:40 ---
No, that's not what pair::swap looks like in 4.5.0, your installation is
broken. This is what I have in 4.5.0
void
swap(pair __p)
{
using std::swap;
swap(first, __p.first);
swap(second, __p.second);
}
Somehow you have a header from 4.4 in your 4.5 tree, or you have been manually
messing with headers
--
redi at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution||WORKSFORME
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43917
[Bug target/42753] _Complex_I is reported as undeclared. Code builds with Sun compiler.
--- Comment #14 from ro at gcc dot gnu dot org 2010-04-28 18:45 --- The bug was fixed for 4.5 by this patch: PATCH: Fix IRIX 6.5/Solaris 2 complex.h for GCC (PR libfortran/41169) http://gcc.gnu.org/ml/gcc-patches/2009-09/msg00114.html with a subsequent fix by Ralf Wildenhues. The 4.4 branch is currently frozen for the 4.4.4 release, and I have no idea if there are any releases planned after that. Given that 4.5.0 is already out, I'd like you to try this one before investing any effort into a backport. Parallel to this, we should try to get this Solaris CR fixed: 6549313 /usr/sfw/bin/gcc needs a patched complex.h http://bugs.opensolaris.org/bugdatabase/view_bug.do?bug_id=6549313 I'd like to get changes made by fixincludes backported to Solaris proper, but there are only so many hours in a day. -- ro at gcc dot gnu dot org changed: What|Removed |Added CC||ro at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42753
[Bug middle-end/39883] preprocessor fails with myassertion
--- Comment #4 from ebotcazou at gcc dot gnu dot org 2010-04-28 18:46 --- I'll try to go through the Solaris bugs in the near future, but have concentrated on getting the 4.5 release in shape until now. I totally missed it as well... Maybe Eric has a sparcv9 compiler around and can easily check this? I only have 4.3.5, 4.5.1 and 4.6.0 compilers for sparc64-sun-solaris2.x at the moment, I'll test if someone can attach the preprocessed source. The submitter said that the problem has disappeared so the PR can be closed though. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39883
[Bug c++/31584] ICE on probably invalid code
--- Comment #5 from redi at gcc dot gnu dot org 2010-04-28 18:47 --- compiles without error using 4.4.3 or 4.6.0 -- redi at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31584
[Bug c++/9335] [4.3/4.4/4.5/4.6 regression] repeated diagnostic when maximum template depth is exceeded
--- Comment #28 from jason at gcc dot gnu dot org 2010-04-28 18:49 --- Agreed. -- jason at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Known to work|2.95.4 |2.95.4 4.6.0 Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=9335
[Bug bootstrap/43926] New: missing crti.o file during build
I am trying to install gcc version 4.5.0. I have untarred and placed the latest versions of gmp (5.0.1). mpc (0.8.1) and mpfr (2.4.2) into my source directory, and I am building in a separate directory. My system is SuSE Linux version 2.6.5-7.244-smp and I currently have gcc v3.3.3 installed currently. I ran the configuration file with no options or target. Then I went to make it, and I received the following error: /usr/lib64/gcc-lib/x86_64-suse-linux/3.3.3/../../../../x86_64-suse-linux/bin/ld: crti.o: No such file: No such file or directory Collect2: ld returned 1 exit status make[5]: *** [libgcc_s.so] Error 1 make[5]: Leaving directory /home2/jlucido/gcc/x86_64-unknown-linux-gnu/32/libgcc followed by several other leaving directory lines. As per the faq section, I cleaned the distribution and configured with --prefix=usr/local/gcc2. Same error All files mentioned above had been downloaded from their sources today. -- Summary: missing crti.o file during build Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: blocker Priority: P3 Component: bootstrap AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: jjlucido at gmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43926
[Bug bootstrap/43926] missing crti.o file during build
--- Comment #1 from pinskia at gcc dot gnu dot org 2010-04-28 18:55 --- 32 I think you don't have the 32bit userland fully installed. Either use --disable-multilib or install the 32bit userland. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Severity|blocker |normal Status|UNCONFIRMED |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43926
[Bug libstdc++/43259] ext/profile/all.cc fails on Solaris
--- Comment #13 from rus at google dot com 2010-04-28 19:06 --- Subject: Re: ext/profile/all.cc fails on Solaris On Wed, Apr 28, 2010 at 11:36 AM, ro at gcc dot gnu dot org gcc-bugzi...@gcc.gnu.org wrote: --- Comment #12 from ro at gcc dot gnu dot org 2010-04-28 18:36 --- Any progress on this? The bug is open for almost 2 months now. I looked at it already, but it wasn't the quick fix I expected. I did not anticipate having to support systems without static mutex initialization. Will fix it one way or another soon. Silvius -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43259
[Bug tree-optimization/43924] [4.6 Regression] FAIL: gfortran.dg/array_constructor_11.f90 -O3 -g (internal compiler error)
--- Comment #1 from kargl at gcc dot gnu dot org 2010-04-28 19:08 --- The regression is also seen on i686-*-freebsd. The regression dissappears if r158788 is reverted. -- kargl at gcc dot gnu dot org changed: What|Removed |Added CC||jh at suse dot cz Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2010-04-28 19:08:00 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43924
[Bug debug/42278] [4.4, 4.5, 4.6 regression] incorrect dwarf data gcc-4.4.2
--- Comment #1 from ro at gcc dot gnu dot org 2010-04-28 19:08 --- Right: this is both a regression from 3.4 and in violation of the DWARF-3 spec, p. 63, 5.1, where DW_AT_name is a required field for DW_TAG_base_type. -- ro at gcc dot gnu dot org changed: What|Removed |Added CC||ro at gcc dot gnu dot org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Known to fail||4.4.3 4.6.0 Last reconfirmed|-00-00 00:00:00 |2010-04-28 19:08:22 date|| Summary|incorrect dwarf data gcc- |[4.4, 4.5, 4.6 regression] |4.4.2 |incorrect dwarf data gcc- ||4.4.2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42278
[Bug c++/43890] [4.6 Regression] invalid uninitialized reference in class
--- Comment #3 from fabien dot chene at gmail dot com 2010-04-28 19:14 --- patch here: http://gcc.gnu.org/ml/gcc-patches/2010-04/msg01759.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43890
[Bug target/40483] gcc 4.x needs to utilize better COMDAT mechanism under Solaris
--- Comment #1 from ro at gcc dot gnu dot org 2010-04-28 19:15 --- One part of this PR (supporting COMDAT group on Solaris 2 with GNU as) is implemented by this patch: [build, doc] Support COMDAT group with recent Sun ld http://gcc.gnu.org/ml/gcc-patches/2010-03/msg01482.html which went into 4.5.0. It requires snv_130, though, a recent OpenSolaris build. Unless paying customers require a backport from Oracle, this won't get into earlier releases,though. On the other hand, supporting COMDAT group with Sun as is still in the works. I've made some progress with help from the Sun assembler and linker maintainers,, but still hit some issues in both as and ld. I expect to have this ready for 4.6.0, but am undecided about a backport to the 4.5 branch yet. -- ro at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |ro at gcc dot gnu dot org |dot org | Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 GCC target triplet|i386-solaris|*-*-solaris2* Last reconfirmed|-00-00 00:00:00 |2010-04-28 19:15:45 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40483
[Bug c++/31902] Internal compiler error while tryint to compile cinelerra/mjpegtools-1.6.3-rc1/y4mdenoise/MotionSearcher.hh:2444 can i do something simple to fix that ?
--- Comment #4 from redi at gcc dot gnu dot org 2010-04-28 19:20 --- *** This bug has been marked as a duplicate of 30797 *** -- redi at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31902
[Bug c++/30797] Failure to build Cinelerra 2.1
--- Comment #4 from redi at gcc dot gnu dot org 2010-04-28 19:20 --- *** Bug 31902 has been marked as a duplicate of this bug. *** -- redi at gcc dot gnu dot org changed: What|Removed |Added CC||kriptomik at gmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30797
