[Bug rtl-optimization/47763] Useless initialization of register
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47763 --- Comment #5 from Andrew Pinski 2011-02-16 08:08:33 UTC --- (In reply to comment #4) > Yeah, normally we don't care about such cases. But this one comes from > dhrystone. If it can be fixed cleanly, why not do it? Then the whole dhrystone benchmark is invalid and should not be trusted. I think people should report the bug to the benchmark maker and then declare all previous results of the benchmark as invalid. In fact any benchmark which depends on undefined code should not be trusted.
[Bug target/17994] avr-gcc does not output a dwarf2 .debug_frame section
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17994 --- Comment #8 from Anitha Boyapati 2011-02-16 08:20:03 UTC --- Created attachment 23360 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=23360 Initial fix that emits the output shown in comment 5 (In reply to comment #7) > (In reply to comment #6) > > The reason for ICE is that POST_DEC is not handled in > > dwarf2out_frame_debug_expr(). Fixing that issue will enable the compiler to > > generate the call-stack debug info. > This is handled by properly defining INCOMING_FRAME_SP_OFFSET. > You don't need a POST_DEC in the INCOMING_RETURN_ADDR_RTX definition. > C.f. the i386 versions of these, which set up the exact same sort of > on-stack return address. Going by the internals document, INCOMING_FRAME_SP_OFFSET is already defined but it is not used anywhere (in my patch). Looking at i386, I understand that the return address is stored on the stack much in the same way. However, what I dont understand is the requirement for cfa initialization in prologue expansion. This is something not handled in AVR. > You don't need a POST_DEC in the INCOMING_RETURN_ADDR_RTX definition. INCOMING_RETURN_ADDR_RTX per se is not using POST_DEC. But once they are defined to some values, during the libgcc build, an ICE is hit in dwarf2out_frame_debug_expr(). If POST_DEC mode is defined, ICE disappears. I am yet to understand the relation between the POST_DEC and ICE and why it appears when only CFI is being emitted. Attaching the patch.
[Bug target/43653] [4.3/4.4/4.5/4.6 Regression] ICE at reload1.c:1188 with -O1 -ftree-vectorize and empty struct
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43653 Uros Bizjak changed: What|Removed |Added Status|NEW |ASSIGNED Component|rtl-optimization|target AssignedTo|unassigned at gcc dot |ubizjak at gmail dot com |gnu.org | --- Comment #12 from Uros Bizjak 2011-02-16 08:27:50 UTC --- Target bug. I have a patch in testing.
[Bug rtl-optimization/47763] Useless initialization of register
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47763 --- Comment #6 from Jie Zhang 2011-02-16 08:32:14 UTC --- I think we all know that dhrystone is a bad benchmark. But some users don't. Which is more difficult: educating all users about that vs apply a simple patch in GCC to remove the useless initialization? 4.4 does has such initialization. But 4.5 has. Fixing this is an improvement and does not hurt. From another point, leaving it unfixed does not help GCC.
[Bug debug/44367] -O0 -g wrong DW_AT_location on c++ class retval
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44367 Juha Kallioinen changed: What|Removed |Added CC||juha.kallioinen at nokia ||dot com --- Comment #6 from Juha Kallioinen 2011-02-16 08:35:46 UTC --- The patch in comment 4 only seems to only be applicable/applyable to the gcc-4.6 branch. I tried applying the patch from comment 3 to gcc-4.4 and that seems to be enough to fix the issue demonstrated with the test program. What would I potentially miss/break if I just ignore the patch from comment 4 with gcc-4.4/4.5?
[Bug rtl-optimization/47763] Useless initialization of register
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47763 --- Comment #7 from Jie Zhang 2011-02-16 08:49:46 UTC --- Sorry, in my last comment, I meant to say "4.4 does NOT have such initialization".
[Bug debug/47283] [4.6 regression] ICE in refs_may_alias_p_1, at tree-ssa-alias.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47283 --- Comment #12 from Jakub Jelinek 2011-02-16 08:55:41 UTC --- Created attachment 23361 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=23361 gcc46-pr47283.patch Untested patch for this. Can anyone test this on ia64-hpux -milp32 and also on spu-elf (or m32c)? The latter two because of the address space fixes.
[Bug debug/47283] [4.6 regression] ICE in refs_may_alias_p_1, at tree-ssa-alias.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47283 Jakub Jelinek changed: What|Removed |Added Priority|P1 |P4 CC||sje at gcc dot gnu.org, ||uweigand at gcc dot gnu.org --- Comment #13 from Jakub Jelinek 2011-02-16 08:57:35 UTC --- That said, downgrading to P4 as none of the Pmode != ptr_mode or special address space targets are primary or secondary targets.
[Bug c++/47704] [4.6 regression] [C++0x] Java-related error message when trying to instantiate a strongly typed enum with new
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47704 --- Comment #5 from Jakub Jelinek 2011-02-16 09:08:51 UTC --- Author: jakub Date: Wed Feb 16 09:08:48 2011 New Revision: 170209 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=170209 Log: PR c++/47704 * cp-tree.h (ENUM_FIXED_UNDERLYING_TYPE_P): Use TYPE_LANG_FLAG_5 instead of TYPE_LANG_FLAG_3. * pt.c (lookup_template_class): Copy over ENUM_FIXED_UNDERLYING_TYPE_P. * g++.dg/cpp0x/enum8.C: New test. Added: trunk/gcc/testsuite/g++.dg/cpp0x/enum8.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/cp-tree.h trunk/gcc/cp/pt.c trunk/gcc/testsuite/ChangeLog
[Bug c++/47704] [4.6 regression] [C++0x] Java-related error message when trying to instantiate a strongly typed enum with new
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47704 Jakub Jelinek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #6 from Jakub Jelinek 2011-02-16 09:17:05 UTC --- Fixed.
[Bug libfortran/47757] Unintentionally? not exported _gfortran_* symbols in libgfortran.so.3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47757 Jakub Jelinek changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2011.02.16 10:05:41 AssignedTo|unassigned at gcc dot |jakub at gcc dot gnu.org |gnu.org | Ever Confirmed|0 |1 --- Comment #2 from Jakub Jelinek 2011-02-16 10:05:41 UTC --- Created attachment 23362 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=23362 gcc46-pr47757.patch Untested fix.
[Bug target/47754] [missed optimization] AVX allows unaligned memory operands but GCC uses unaligned load and register operand
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47754 Richard Guenther changed: What|Removed |Added CC||rth at gcc dot gnu.org --- Comment #4 from Richard Guenther 2011-02-16 10:49:30 UTC --- Note that GCC doesn't use unaligned memory operands because it doesn't have the knowledge implemented that this is ok for AVX, it simply treats the AVX case the same as the SSE case where the memory operands are required to be aligned. That said, unaligned SSE and AVX moves are implemented using UNSPECs, so they will be never combined with other instructions. I don't know if there is a way to still distinguish unaligned and aligned loads/stores and let them appear as regular RTL moves at the same time. Richard, is that even possible?
[Bug driver/47760] Getting internal compiler error: Segmentation fault
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47760 Richard Guenther changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||WONTFIX --- Comment #2 from Richard Guenther 2011-02-16 10:56:25 UTC --- GCC 4.2.0 is no longer maintained, please update to at least GCC 4.3.5, preferably to GCC 4.5.2. The issue is likely even fixed in 4.2.4.
[Bug rtl-optimization/47763] Useless initialization of register
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47763 Richard Guenther changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2011.02.16 11:04:15 Ever Confirmed|0 |1 --- Comment #8 from Richard Guenther 2011-02-16 11:04:15 UTC --- The difference is that with -funroll-loops the init_regs pass isn't presented with (insn 8 7 6 2 (clobber (reg:SI 59 [ ])) t.c:1 -1 (nil)) and thus inserts a zero-initialization instruction. I wonder whether it could instead insert a clobber.
[Bug target/43653] [4.3/4.4/4.5/4.6 Regression] ICE at reload1.c:1188 with -O1 -ftree-vectorize and empty struct
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43653 Uros Bizjak changed: What|Removed |Added URL||http://gcc.gnu.org/ml/gcc-p ||atches/2011-02/txt00085.txt --- Comment #13 from Uros Bizjak 2011-02-16 11:21:03 UTC --- Patch at [1]. [1] http://gcc.gnu.org/ml/gcc-patches/2011-02/txt00085.txt
[Bug rtl-optimization/47763] Useless initialization of register
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47763 --- Comment #9 from Jie Zhang 2011-02-16 11:29:50 UTC --- The clobber is optimized away in 172r.cprop3 because the register renaming in 171r.web breaks the def-use relationship between the clobber and the use in the following instruction when -funroll-loops is used. My patch prevents the renaming in such case.
[Bug c++/47765] New: Wrong template deduction
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47765
Summary: Wrong template deduction
Product: gcc
Version: 4.5.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: dk_m...@mail.ru
The following code fails to compile neither with g++ version 4.4.5
(Ubuntu/Linaro 4.4.4-14ubuntu5) nor with 4.5.1:
template
struct traits {
typedef typename ItT::value_type value_t;
};
template
struct A {
typedef typename traits::value_t value_t;
};
template
struct B {
typedef T type_t;
};
struct C {
template
void foo(const A& r) {}
template
void foo(const B& r) {}
};
void foo()
{
B b;
C c;
c.foo(b);
c.foo(b); // fails to compile
}
[Bug tree-optimization/47738] ICE: verify_ssa failed: no immediate_use list with -O3 -fno-tree-vectorize
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47738 Richard Guenther changed: What|Removed |Added CC||rakdver at gcc dot gnu.org --- Comment #3 from Richard Guenther 2011-02-16 12:32:43 UTC --- We are removing the definition of D.2738_12 in remove_stmt but the PHI use which was created by tree_transform_and_unroll_loop is not in the list of stmts to be removed. It is created by PHI copying of tree_transform_and_unroll_loop phi_rest = create_phi_node (new_init, rest); SSA_NAME_DEF_STMT (new_init) = phi_rest; add_phi_arg (phi_rest, init, precond_edge, UNKNOWN_LOCATION); add_phi_arg (phi_rest, next, new_exit, UNKNOWN_LOCATION); SET_USE (op, new_init); } remove_path (exit); >From tree_transform_and_unroll_loop we call execute_pred_commoning_cbck /* Transform the loop. */ if (transform) (*transform) (loop, data); which also does the stmt removal, then we verify SSA form in ok = gimple_duplicate_loop_to_header_edge (loop, loop_latch_edge (loop), factor - 1, wont_exit, new_exit, &to_remove, DLTHE_FLAG_UPDATE_FREQ); which fails. I wonder if the simplest fix is to kill that stmt removal code as it looks like unconditionally removing the loads isn't going to work for the peeled iterations. Zdenek?
[Bug libgomp/47758] 729 unexpected failures in the libgomp test suite on powerpc-apple-darwin8
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47758 --- Comment #3 from Dominique d'Humieres 2011-02-16 12:51:44 UTC --- > Do you know when it last worked? Well it was my first attempt to build 4.6 on my poor G4 (almost ten year old, so slow with a crowded disk that I don't even have 4.5 installed in it;-). This build was motivated by pr45381 and I stumbled on this PR only by chance. > My candidate would be the patch - assuming that it is not a new issue. The patch in comment #1 fixes the failures and has been tested also on powerpc-apple-darwin9 and x86_64-apple-darwin10 without problem. Thanks for the quick fix.
[Bug c++/47326] [4.4/4.5/4.6 Regression][C++0x] ICE in tsubst_copy (triggered by dependency of return type on parameter pack size)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47326 Dodji Seketeli changed: What|Removed |Added Status|NEW |ASSIGNED AssignedTo|unassigned at gcc dot |dodji at gcc dot gnu.org |gnu.org |
[Bug target/47766] New: [x32] -fstack-protector doesn't work
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47766
Summary: [x32] -fstack-protector doesn't work
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: hjl.to...@gmail.com
[hjl@gnu-6 ilp32-22]$ cat x.c
int
parse_opt (int key)
{
struct
{
int arg[key];
} reqdata;
return 0;
}
[hjl@gnu-6 ilp32-22]$ make x.s
/export/build/gnu/gcc-x32/build-x86_64-linux/gcc/xgcc
-B/export/build/gnu/gcc-x32/build-x86_64-linux/gcc/ -S -o x.s -mx32 -O2 -g
-fstack-protector x.c
x.c: In function \u2018parse_opt\u2019:
x.c:9:1: error: unrecognizable insn:
(insn 4 3 6 2 (parallel [
(set (mem/v/f/c/i:SI (plus:DI (reg/f:DI 54 virtual-stack-vars)
(const_int -4 [0xfffc])) [2 D.2703+0 S4
A32])
(unspec:DI [
(const_int 40 [0x28])
] UNSPEC_SP_TLS_SET))
(set (scratch:DI)
(const_int 0 [0]))
(clobber (reg:CC 17 flags))
]) x.c:3 -1
(nil))
x.c:9:1: internal compiler error: in extract_insn, at recog.c:2109
Please submit a full bug report,
with preprocessed source if appropriate.
See for instructions.
make: *** [x.s] Error 1
[hjl@gnu-6 ilp32-22]$
[Bug debug/47283] [4.6 regression] ICE in refs_may_alias_p_1, at tree-ssa-alias.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47283 --- Comment #14 from Jakub Jelinek 2011-02-16 13:50:05 UTC --- FYI I've bootstrapped/regtested #c12 patch on x86_64-linux and i686-linux (though, of course, it doesn't make much difference there, given that POINTERS_EXTEND_UNSIGNED is not defined there nor it has special address spaces).
[Bug tree-optimization/47738] ICE: verify_ssa failed: no immediate_use list with -O3 -fno-tree-vectorize
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47738 --- Comment #4 from Richard Guenther 2011-02-16 14:26:50 UTC --- Author: rguenth Date: Wed Feb 16 14:26:43 2011 New Revision: 170212 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=170212 Log: 2011-02-12 Richard Guenther PR tree-optimization/47738 * tree-ssa-loop.c (run_tree_predictive_commoning): Return the TODO from tree_predictive_commoning. Modified: trunk/gcc/ChangeLog trunk/gcc/tree-ssa-loop.c
[Bug tree-optimization/47738] ICE: verify_ssa failed: no immediate_use list with -O3 -fno-tree-vectorize
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47738 --- Comment #5 from Richard Guenther 2011-02-16 14:27:46 UTC --- With release checking now no bad IL prevails.
[Bug c/47689] [trans-mem] function is cloned even if not used in transaction
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47689 Aldy Hernandez changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE --- Comment #1 from Aldy Hernandez 2011-02-16 15:21:49 UTC --- Not exactly a duplicate, but related and fixed by the patch in the other PR. *** This bug has been marked as a duplicate of bug 47690 ***
[Bug c/47690] [trans-mem] ICE in verify_cgraph_node with O0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47690 --- Comment #2 from Aldy Hernandez 2011-02-16 15:21:49 UTC --- *** Bug 47689 has been marked as a duplicate of this bug. ***
[Bug c++/47747] [trans-mem] unsafe virtual function not properly displayed
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47747 Aldy Hernandez changed: What|Removed |Added Priority|P3 |P5
[Bug libgomp/47758] 729 unexpected failures in the libgomp test suite on powerpc-apple-darwin8
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47758
--- Comment #4 from Iain Sandoe 2011-02-16 16:14:02
UTC ---
thanks, IIRC, when the patch was originally applied it was not possible to test
on Darwin 8 (libquadmath was broken for other reasons).
---
This is not an objection to the proposed solution - but - for the record:
I remain concerned that the libgomp test-suite is driven by xgcc (which does
not apply the fortran spec) and, thus, is different from the notional idea of
equivalence with the installed gfortran.
[if the fortran spec is used, I think you will find that the fails are also
resolved]
e.g.
Index: libgomp/testsuite/libgomp.fortran/fortran.exp
===
--- libgomp/testsuite/libgomp.fortran/fortran.exp (revision 170210)
+++ libgomp/testsuite/libgomp.fortran/fortran.exp (working copy)
@@ -8,6 +8,7 @@ set lang_library_path "../libgfortran/.libs"
set lang_link_flags"-lgfortran"
set lang_test_file_found 0
set quadmath_library_path "../libquadmath/.libs"
+set lang_spec_path "../libgfortran"
# Initialize dg.
@@ -44,6 +45,8 @@ if { $lang_test_file_found } {
lappend ALWAYS_CFLAGS "ldflags=-L${blddir}/${quadmath_library_path}/"
# Allow for spec subsitution.
lappend ALWAYS_CFLAGS
"additional_flags=-B${blddir}/${quadmath_library_path}/"
+ # use the libgfortran spec.
+ lappend ALWAYS_CFLAGS
"additional_flags=-specs=${blddir}/${lang_spec_path}/libgfortran.spec"
set ld_library_path
"$always_ld_library_path:${blddir}/${lang_library_path}:${blddir}/${quadmath_library_path}"
} else {
set ld_library_path "$always_ld_library_path"
[Bug lto/47247] Linker plugin specification makes it difficult to handle COMDATs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47247 --- Comment #18 from Rafael Avila de Espindola 2011-02-16 16:14:52 UTC --- I have created a "small" test of the symbol table problem. It is in http://people.mozilla.com/~respindola/test.tar.xz The test is firefox's libxul with most files copied into one directory to make it easy to run. The test script runs the link twice. First with the IL files and then with combined .o file. The sizes are 39339456 libxul1.so 34436696 libxul2.so The output of "size" in both files is For a 5 MB reduction I might end up writing a wrapper that runs ld twice :-) 232180682380480 2896682588821618b05d8libxul1.so 231754182380480 2896682584556618a5f3elibxul2.so
[Bug c/47690] [trans-mem] ICE in verify_cgraph_node with O0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47690 --- Comment #3 from Aldy Hernandez 2011-02-16 16:23:33 UTC --- Author: aldyh Date: Wed Feb 16 16:23:28 2011 New Revision: 170213 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=170213 Log: PR 47690 * trans-mem.c (ipa_tm_execute): Do not scan past exit blocks when accumulating BB's. (is_tm_ending_fndecl): Remove static. * tree-cfg.c (is_ctrl_altering_stmt): Add TM ending statements. * tree.h (is_tm_ending_fndecl): New prototype. Added: branches/transactional-memory/gcc/testsuite/gcc.dg/tm/pr47690.c Modified: branches/transactional-memory/gcc/ChangeLog.tm branches/transactional-memory/gcc/trans-mem.c branches/transactional-memory/gcc/tree-cfg.c branches/transactional-memory/gcc/tree.h
[Bug c/47690] [trans-mem] ICE in verify_cgraph_node with O0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47690 Aldy Hernandez changed: What|Removed |Added Status|WAITING |RESOLVED Resolution||FIXED
[Bug c++/47326] [4.4/4.5/4.6 Regression][C++0x] ICE in tsubst_copy (triggered by dependency of return type on parameter pack size)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47326 --- Comment #10 from Dodji Seketeli 2011-02-16 16:30:22 UTC --- Candidate patch posted to http://gcc.gnu.org/ml/gcc-patches/2011-02/msg01050.html
[Bug lto/45375] [meta-bug] Issues with building Mozilla with LTO
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45375 --- Comment #47 from Martin Jambor 2011-02-16 16:30:31 UTC --- With the elfhack issues gone, the build now fails with: -- /home/mjambor/gcc/icln/inst/bin/g++ -o js -fno-rtti -fno-exceptions -Wall -Wpointer-arith -Woverloaded-virtual -Wsynth -Wno-ctor-dtor-privacy -Wno-non-virtual-dtor -Wcast-align -Wno-invalid-offsetof -Wno-variadic-macros -Werror=return-type -pedantic -Wno-long-long -O2 -flto=jobserver -fpermissive -fuse-linker-plugin -fno-strict-aliasing -pthread -pipe -DNDEBUG -DTRIMMED -Os -freorder-blocks -fomit-frame-pointer js.o jsworkers.o -lpthread -O2 -flto=jobserver -fuse-linker-plugin -Wl,-rpath-link,/bin -Wl,-rpath-link,/home/mjambor/mozilla/lto/objdir-ff-release/dist/lib -L../../../dist/bin -L../../../dist/lib -L/home/mjambor/mozilla/lto/objdir-ff-release/dist/lib -lplds4 -lplc4 -lnspr4 -lpthread -ldl ../editline/libeditline.a ../libjs_static.a -ldl make[6]: warning: jobserver unavailable: using -j1. Add `+' to parent make rule. /home/mjambor/binutils/obj/gold/ld-new: /tmp/ccmP9JrU.ltrans0.ltrans.o:(.text+0x33): error: undefined reference to 'SetVMFrameRegs' /home/mjambor/binutils/obj/gold/ld-new: /tmp/ccmP9JrU.ltrans0.ltrans.o:(.text+0x3b): error: undefined reference to 'PushActiveVMFrame' /home/mjambor/binutils/obj/gold/ld-new: /tmp/ccmP9JrU.ltrans0.ltrans.o:(.text+0x4d): error: undefined reference to 'PopActiveVMFrame' /home/mjambor/binutils/obj/gold/ld-new: /tmp/ccmP9JrU.ltrans0.ltrans.o:(.text+0x6b): error: undefined reference to 'js_InternalThrow' /home/mjambor/binutils/obj/gold/ld-new: /tmp/ccmP9JrU.ltrans0.ltrans.o:(.text+0x7a): error: undefined reference to 'PopActiveVMFrame' collect2: ld returned 1 exit status make[5]: *** [js] Error 1 make[5]: Leaving directory `/home/mjambor/mozilla/lto/objdir-ff-release/js/src/shell' -- I have not been able to have a closer look at the issue yet but hope to do so soon.
[Bug libfortran/47757] Unintentionally? not exported _gfortran_* symbols in libgfortran.so.3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47757
--- Comment #3 from Jakub Jelinek 2011-02-16
17:18:44 UTC ---
Author: jakub
Date: Wed Feb 16 17:18:41 2011
New Revision: 170215
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=170215
Log:
PR libfortran/47757
* gfortran.map (GFORTRAN_1.4): Export
_gfortran_{m,s}i{all,any,parity}_i{1,2,4,8,16} and
_gfortran_{cshift0,eoshift{0,2}}_16_char4.
* gfortran.dg/pr47757-1.f90: New test.
* gfortran.dg/pr47757-2.f90: New test.
* gfortran.dg/pr47757-3.f90: New test.
Added:
trunk/gcc/testsuite/gfortran.dg/pr47757-1.f90
trunk/gcc/testsuite/gfortran.dg/pr47757-2.f90
trunk/gcc/testsuite/gfortran.dg/pr47757-3.f90
Modified:
trunk/gcc/testsuite/ChangeLog
trunk/libgfortran/ChangeLog
trunk/libgfortran/gfortran.map
[Bug fortran/47767] New: SELECT TYPE fails to execute correct TYPE IS block
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47767 Summary: SELECT TYPE fails to execute correct TYPE IS block Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: aben...@caltech.edu Created attachment 23363 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=23363 Test case to reproduce the bug. The attached code should execute the contents of the TYPE IS block and print "correct", but fails to do so, falling through to the CLASS DEFAULT block and printing "incorrect". There are a number of ways to avoid the bug and get the output 'correct': * removing the 'private' statement * removing the 'public' statement * removing the 'baseNode' component * removing the unneeded module 'merger_tree_build' Compiled using r170207 of gfortran 4.6.0 $ gfortran selectTypeFail.F90 -o selectTypeFail.exe -g -fbacktrace -v Driving: gfortran selectTypeFail.F90 -o selectTypeFail.exe -g -fbacktrace -v -l gfortran -l m -shared-libgcc Using built-in specs. COLLECT_GCC=gfortran COLLECT_LTO_WRAPPER=/usr/local/gcc-trunk/libexec/gcc/i686-pc-linux-gnu/4.6.0/lto-wrapper Target: i686-pc-linux-gnu Configured with: ../gcc-4.6/configure --prefix=/usr/local/gcc-trunk --enable-languages=c,c++,fortran --disable-multilib --with-gmp=/usr/local --with-mpc=/usr/local --with-mpfr=/usr/local Thread model: posix gcc version 4.6.0 20110216 (experimental) (GCC) COLLECT_GCC_OPTIONS='-o' 'selectTypeFail.exe' '-g' '-fbacktrace' '-v' '-shared-libgcc' '-mtune=generic' '-march=pentiumpro' /usr/local/gcc-trunk/libexec/gcc/i686-pc-linux-gnu/4.6.0/f951 selectTypeFail.F90 -cpp=/tmp/ccro8Gvw.f90 -quiet -v selectTypeFail.F90 -quiet -dumpbase selectTypeFail.F90 -mtune=generic -march=pentiumpro -auxbase selectTypeFail -g -version -fbacktrace -fintrinsic-modules-path /usr/local/gcc-trunk/lib/gcc/i686-pc-linux-gnu/4.6.0/finclude -o /tmp/ccguPzRS.s GNU Fortran (GCC) version 4.6.0 20110216 (experimental) (i686-pc-linux-gnu) compiled by GNU C version 4.6.0 20110216 (experimental), GMP version 4.3.2, MPFR version 3.0.0, MPC version 0.8.2 GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096 ignoring nonexistent directory "/usr/local/gcc-trunk/lib/gcc/i686-pc-linux-gnu/4.6.0/../../../../i686-pc-linux-gnu/include" #include "..." search starts here: #include <...> search starts here: /usr/local/gcc-trunk/lib/gcc/i686-pc-linux-gnu/4.6.0/finclude /usr/local/gcc-trunk/lib/gcc/i686-pc-linux-gnu/4.6.0/include /usr/local/include /usr/local/gcc-trunk/include /usr/local/gcc-trunk/lib/gcc/i686-pc-linux-gnu/4.6.0/include-fixed /usr/include End of search list. GNU Fortran (GCC) version 4.6.0 20110216 (experimental) (i686-pc-linux-gnu) compiled by GNU C version 4.6.0 20110216 (experimental), GMP version 4.3.2, MPFR version 3.0.0, MPC version 0.8.2 GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096 COLLECT_GCC_OPTIONS='-o' 'selectTypeFail.exe' '-g' '-fbacktrace' '-v' '-shared-libgcc' '-mtune=generic' '-march=pentiumpro' as --32 -o /tmp/ccZqndJg.o /tmp/ccguPzRS.s Reading specs from /usr/local/gcc-trunk/lib/gcc/i686-pc-linux-gnu/4.6.0/../../../libgfortran.spec rename spec lib to liborig COLLECT_GCC_OPTIONS='-o' 'selectTypeFail.exe' '-g' '-fbacktrace' '-v' '-shared-libgcc' '-mtune=generic' '-march=pentiumpro' COMPILER_PATH=/usr/local/gcc-trunk/libexec/gcc/i686-pc-linux-gnu/4.6.0/:/usr/local/gcc-trunk/libexec/gcc/i686-pc-linux-gnu/4.6.0/:/usr/local/gcc-trunk/libexec/gcc/i686-pc-linux-gnu/:/usr/local/gcc-trunk/lib/gcc/i686-pc-linux-gnu/4.6.0/:/usr/local/gcc-trunk/lib/gcc/i686-pc-linux-gnu/ LIBRARY_PATH=/usr/local/gcc-trunk/lib/gcc/i686-pc-linux-gnu/4.6.0/:/usr/local/gcc-trunk/lib/gcc/i686-pc-linux-gnu/4.6.0/../../../:/lib/:/usr/lib/ COLLECT_GCC_OPTIONS='-o' 'selectTypeFail.exe' '-g' '-fbacktrace' '-v' '-shared-libgcc' '-mtune=generic' '-march=pentiumpro' /usr/local/gcc-trunk/libexec/gcc/i686-pc-linux-gnu/4.6.0/collect2 --eh-frame-hdr -m elf_i386 -dynamic-linker /lib/ld-linux.so.2 -o selectTypeFail.exe /usr/lib/crt1.o /usr/lib/crti.o /usr/local/gcc-trunk/lib/gcc/i686-pc-linux-gnu/4.6.0/crtbegin.o -L/usr/local/gcc-trunk/lib/gcc/i686-pc-linux-gnu/4.6.0 -L/usr/local/gcc-trunk/lib/gcc/i686-pc-linux-gnu/4.6.0/../../.. /tmp/ccZqndJg.o -lgfortran -lm -lgcc_s -lgcc -lquadmath -lm -lgcc_s -lgcc -lc -lgcc_s -lgcc /usr/local/gcc-trunk/lib/gcc/i686-pc-linux-gnu/4.6.0/crtend.o /usr/lib/crtn.o $ selectTypeFail.exe incorrect
[Bug lto/45375] [meta-bug] Issues with building Mozilla with LTO
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45375 Jan Hubicka changed: What|Removed |Added Attachment #21543|0 |1 is obsolete|| --- Comment #48 from Jan Hubicka 2011-02-16 17:19:47 UTC --- Created attachment 23364 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=23364 Mozilla updates needed Updated mozilla patch fixing the undefined symbols Martin reported. Sorry, had it in tree for a while, but didn't noticed PR is out of date.
[Bug lto/44334] rnflow.f90 ~27% slower with -fwhole-program -flto after revision 159852
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44334 Dominique d'Humieres changed: What|Removed |Added Status|WAITING |RESOLVED Resolution||FIXED --- Comment #49 from Dominique d'Humieres 2011-02-16 17:21:14 UTC --- Since it seems that revision 169136 is the "right fix", I am closing this PR as fixed. Any further discussion about the interaction between -fwhole-program and -flto for the polyhedron test fatigue.f90 should take place in pr45810.
[Bug libfortran/47757] Unintentionally? not exported _gfortran_* symbols in libgfortran.so.3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47757 Jakub Jelinek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #4 from Jakub Jelinek 2011-02-16 17:23:59 UTC --- Fixed.
[Bug fortran/47767] [OOP] SELECT TYPE fails to execute correct TYPE IS block
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47767 janus at gcc dot gnu.org changed: What|Removed |Added Keywords||wrong-code Status|UNCONFIRMED |NEW Last reconfirmed||2011.02.16 17:32:32 CC||janus at gcc dot gnu.org Summary|SELECT TYPE fails to|[OOP] SELECT TYPE fails to |execute correct TYPE IS |execute correct TYPE IS |block |block Ever Confirmed|0 |1
[Bug libgomp/47758] 729 unexpected failures in the libgomp test suite on powerpc-apple-darwin8
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47758 --- Comment #5 from Tobias Burnus 2011-02-16 17:44:48 UTC --- Author: burnus Date: Wed Feb 16 17:44:45 2011 New Revision: 170216 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=170216 Log: 2011-02-16 Tobias Burnus PR libgomp/47758 * testsuite/libgomp.fortran/fortran.exp: Check for the existence of libquadmath.a before adding its libpath to ldflags. Modified: trunk/libgomp/ChangeLog trunk/libgomp/testsuite/libgomp.fortran/fortran.exp
[Bug fortran/47768] New: ICE: printing a derived-type variable with proc-pointer components
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47768 Summary: ICE: printing a derived-type variable with proc-pointer components Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: ja...@gcc.gnu.org Test case: type :: t integer :: i = 3 !type(t), pointer :: p ! rejected with this line procedure(type(t)), pointer, nopass :: ppc end type type(t) :: x print *,x end This segfaults with 4.5 and 4.6. Adding a data pointer component leads to rejection: print *,x 1 Error: Data transfer element at (1) cannot have POINTER components So I'm guessing the version with proc-pointer is also illegal (haven't checked the standard). Changing the proc-pointer to procedure(integer), pointer, nopass :: ppc makes it compile and gives the output: 3 0
[Bug fortran/47692] Numeric inaccuracy reported in testing lapack-3.3.0 BLAS module
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47692 --- Comment #12 from Harald Anlauf 2011-02-16 18:01:16 UTC --- (In reply to comment #11) > (In reply to comment #8) > > On Fri, Feb 11, 2011 at 07:56:05PM +, jrt at worldlinc dot net wrote: > > > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47692 > > > > > > --- Comment #6 from John T 2011-02-11 19:56:02 > > > UTC --- > > > I built the reference BLAS included with Lapack from source. I just got > > > the > > > results from blas_testing using gcc-4.4.5 and results good again. I don't > > > know > > > where to find the raw results from lapack and blas testing. Should there > > > be an > > > ieee flag in compiler settings? Any flags on how to round? > > > > > > My flags were: > > > # > > > FORTRAN = gfortran -fimplicit-none -g > > > OPTS = -O3 > > > DRVOPTS = $(OPTS) > > > NOOPT= -g -O0 > > > LOADER = gfortran -g > > > LOADOPTS = > > > > > > > I just built the blas included with lapack-3.3.0 with > > -O3 of x86_64-*-freebsd with 4.5.3 and 4.6.0 (a fews > > old version). There were no errors. Can you rebuild > > with -O and see if you have problems? If you have > > problems with -O, can you then use -O0 -ffloat-store? > > I haven't been able to try these suggestions because I'm finding a different > problem, linking. The GCC programs didn't respond well to an attempt to > reconfigure the existing build so I rebuilt for /usr/local and used a colorgcc > trick to switch between 4.4.5 and the test version. But the build for > /usr/local tried to link with /usr/lib/libgfortran.so.3 and the first set of > test programs (in lapack-3.3.0/INSTALL) wouldn't run. I don't see anything in > the makefiles that would confuse a linker. Can you be a little bit more specific? What are the precise error messages? In case the gfortran you build for /usr/local is incompatible with the system version in /usr, you might try adding the following flags for linking: LOADOPTS = -static-libgfortran -static-libgcc or you need to set LD_LIBRARY_PATH appropriately.
[Bug target/17994] avr-gcc does not output a dwarf2 .debug_frame section
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17994 --- Comment #9 from Richard Henderson 2011-02-16 18:04:08 UTC --- > Going by the internals document, INCOMING_FRAME_SP_OFFSET is already defined > but it is not used anywhere (in my patch). Certainly it's going to be used by the generic code in dwarf2out_frame_init, and if that's wrong everything that follows will be off as well. > INCOMING_RETURN_ADDR_RTX per se is not using POST_DEC. But once they are > defined to some values, during the libgcc build, an ICE is hit in > dwarf2out_frame_debug_expr(). If POST_DEC mode is defined, ICE disappears. I > am > yet to understand the relation between the POST_DEC and ICE and why it appears > when only CFI is being emitted. Ah, I see. Nothing to do with the initial frame setup, but the rest of the unwind info, since AVR uses POST_DEC for pushes. See http://gcc.gnu.org/ml/gcc-patches/2011-02/msg01059.html for my proposed patch for this. Note that the message contains both gas and gcc patches.
[Bug fortran/47768] ICE: printing a derived-type variable with proc-pointer components
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47768 janus at gcc dot gnu.org changed: What|Removed |Added Keywords||ice-on-invalid-code --- Comment #1 from janus at gcc dot gnu.org 2011-02-16 18:16:13 UTC --- (In reply to comment #0) > Adding a data pointer component leads to rejection: > > print *,x > 1 > Error: Data transfer element at (1) cannot have POINTER components > > So I'm guessing the version with proc-pointer is also illegal (haven't checked > the standard). I have the feeling we reject too much here. F08 says in chapter 9.6.3: "If an output item is a pointer, it shall be associated with a target and data are transferred from the target to the file." I think this is the same in F03 and F95. So, it seems like pointers are ok (but should be associated), unless I'm missing something. Procedure pointers, however, are definitely illegal: C935 (R917) An expression that is an output-item shall not have a value that is a procedure pointer.
[Bug rtl-optimization/47763] Useless initialization of register
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47763 --- Comment #10 from Andreas Schwab 2011-02-16 18:26:31 UTC --- There is no undefined behaviour if all calls to foo ignore the returned value.
[Bug fortran/47767] [OOP] SELECT TYPE fails to execute correct TYPE IS block
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47767 --- Comment #1 from janus at gcc dot gnu.org 2011-02-16 18:31:06 UTC --- Here is a variant: Apart from SELECT TYPE, this bug can also be exposed via the SAME_TYPE_AS intrinsic. module Tree_Nodes type treeNode contains procedure :: walk end type contains subroutine walk (thisNode) class (treeNode) :: thisNode print *, SAME_TYPE_AS (thisNode, treeNode()) end subroutine end module module Merger_Trees use Tree_Nodes private public :: mergerTree type mergerTree type(treeNode), pointer :: baseNode end type end module module Merger_Tree_Build use Merger_Trees end module program test use Merger_Tree_Build use Tree_Nodes type(treeNode) :: node call walk (node) end program This prints "F", but should print "T". The underlying problem seems to be related to the vtable not being properly set up. The vtab symbol for the type 'treeNode' apparently is present, but it is not initialized properly: The '_hash' component is 0! Looking at the mod files, the symbol '__vtab_tree_nodes_Treenode' seems to be present in tree_nodes.mod and merger_tree_build.mod, but not in merger_trees.mod!
[Bug lto/45810] 40% slowdown when using LTO for a single-file program
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45810 --- Comment #25 from Dominique d'Humieres 2011-02-16 18:38:19 UTC --- AFAICT the patch in http://gcc.gnu.org/ml/gcc-patches/2011-02/msg00973.html seems to fix most of the fatigue.f90 problems: At revision 170178 without the patch, I get [macbook] lin/test% gfcp -Ofast fatigue.f90 [macbook] lin/test% time a.out > /dev/null 8.903u 0.005s 0:08.91 99.8%0+0k 0+2io 0pf+0w [macbook] lin/test% gfcp -Ofast -fwhole-program fatigue.f90 [macbook] lin/test% time a.out > /dev/null 6.392u 0.002s 0:06.39 100.0%0+0k 0+0io 0pf+0w [macbook] lin/test% gfcp -Ofast -finline-limit=322 -fwhole-program fatigue.f90 [macbook] lin/test% time a.out > /dev/null 4.653u 0.002s 0:04.65 100.0%0+0k 0+1io 0pf+0w [macbook] lin/test% gfcp -Ofast -finline-limit=322 -fwhole-program -flto fatigue.f90 [macbook] lin/test% time a.out > /dev/null 8.212u 0.004s 0:08.22 99.8%0+0k 0+2io 0pf+0w [macbook] lin/test% gfcp -Ofast -finline-limit=322 --param large-function-growth=132 -fwhole-program -flto fatigue.f90 [macbook] lin/test% time a.out > /dev/null 4.526u 0.004s 0:04.53 99.7%0+0k 0+1io 0pf+0w At revision 170212 with the patch, I get [macbook] lin/test% gfc -Ofast fatigue.f90 [macbook] lin/test% time a.out > /dev/null 4.628u 0.002s 0:04.63 99.7%0+0k 0+0io 0pf+0w [macbook] lin/test% gfc -Ofast -fwhole-program fatigue.f90 [macbook] lin/test% time a.out > /dev/null 4.654u 0.002s 0:04.65 100.0%0+0k 0+1io 0pf+0w [macbook] lin/test% gfc -Ofast -finline-limit=322 -fwhole-program fatigue.f90 [macbook] lin/test% time a.out > /dev/null 4.657u 0.002s 0:04.66 99.7%0+0k 0+1io 0pf+0w [macbook] lin/test% gfc -Ofast -finline-limit=322 -fwhole-program -flto fatigue.f90 [macbook] lin/test% time a.out > /dev/null 4.715u 0.003s 0:04.72 99.7%0+0k 0+1io 0pf+0w [macbook] lin/test% gfc -Ofast -finline-limit=322 --param large-function-growth=132 -fwhole-program -flto fatigue.f90 [macbook] lin/test% time a.out > /dev/null 4.713u 0.003s 0:04.71 100.0%0+0k 0+1io 0pf+0w [macbook] lin/test% gfc -Ofast -finline-limit=322 --param large-function-growth=137 -fwhole-program -flto fatigue.f90 [macbook] lin/test% time a.out > /dev/null 4.524u 0.003s 0:04.52 100.0%0+0k 0+1io 0pf+0w [macbook] lin/test% gfc -Ofast --param large-function-growth=137 -fwhole-program -flto fatigue.f90 [macbook] lin/test% time a.out > /dev/null 4.564u 0.003s 0:04.57 99.7%0+0k 0+1io 0pf+0w [macbook] lin/test% gfc -Ofast --param large-function-growth=137 -fwhole-program fatigue.f90 [macbook] lin/test% time a.out > /dev/null 4.479u 0.003s 0:04.48 99.7%0+0k 0+2io 0pf+0w A quick check of the other tests does not show any obvious slowdown with the patch.
[Bug target/47769] New: [missed optimization] use of btr (bit test and reset)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47769 Summary: [missed optimization] use of btr (bit test and reset) Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: minor Priority: P3 Component: target AssignedTo: unassig...@gcc.gnu.org ReportedBy: kr...@kde.org The code: tmp &= ~(1 << bit); gets translated to actual shift, not, and and instructions. Instead GCC could emit one btr instruction (which modifies the flags - unwanted but acceptable): btr %[bit], %[tmp] The btr instruction has a latency of 1 cycle and throughput of 0.5 cycles on all recent Intel CPUs and thus outperforms the shift + not + and combination. Rationale: I make use of this pattern for iteration over a bitmask. I use bsf (_bit_scan_forward(bitmask)) to find the lowest set bit. To find the next one I have to mask off the last found bit and currently have to use inline assembly to get a btr instruction there. Alternatively an intrinsic for btr and friends might make sense.
[Bug tree-optimization/47770] New: wrong code -O2 -ftree-loop-if-convert-stores -fno-tree-reassoc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47770 Summary: wrong code -O2 -ftree-loop-if-convert-stores -fno-tree-reassoc Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization AssignedTo: unassig...@gcc.gnu.org ReportedBy: zso...@seznam.cz CC: s...@gcc.gnu.org Host: x86_64-pc-linux-gnu Target: x86_64-pc-linux-gnu Created attachment 23365 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=23365 reduced testcase Output: $ gcc -O2 -ftree-loop-if-convert-stores -fno-tree-reassoc testcase.c $ ./a.out Aborted By looking that the dumps testcase.c.110t.ifcvt is "binary equal" to testcase.c.109t.ivcanon, but with -ftree-loop-if-convert-stores, testcase.c.126t.cddce2 removes most of code of foo(). Dumps with and without -ftree-loop-if-convert-stores are the same up to that point.
[Bug libgomp/47758] 729 unexpected failures in the libgomp test suite on powerpc-apple-darwin8
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47758 Jakub Jelinek changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED --- Comment #6 from Jakub Jelinek 2011-02-16 19:45:27 UTC --- Fixed.
[Bug target/47769] [missed optimization] use of btr (bit test and reset)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47769
Richard Guenther changed:
What|Removed |Added
Keywords||missed-optimization
Target||x86_64-*-*, i?86-*-*
Status|UNCONFIRMED |WAITING
Last reconfirmed||2011.02.16 19:46:40
Ever Confirmed|0 |1
--- Comment #1 from Richard Guenther 2011-02-16
19:46:40 UTC ---
Can you provide a testcase that can be compiled please?
Cut&pasting from i386.md:
;; %%% bts, btr, btc, bt.
;; In general these instructions are *slow* when applied to memory,
;; since they enforce atomic operation. When applied to registers,
;; it depends on the cpu implementation. They're never faster than
;; the corresponding and/ior/xor operations, so with 32-bit there's
;; no point. But in 64-bit, we can't hold the relevant immediates
;; within the instruction itself, so operating on bits in the high
;; 32-bits of a register becomes easier.
;;
;; These are slow on Nocona, but fast on Athlon64. We do require the use
;; of btrq and btcq for corner cases of post-reload expansion of absdf and
;; negdf respectively, so they can never be disabled entirely.
(define_insn "*btrq"
[(set (zero_extract:DI (match_operand:DI 0 "register_operand" "+r")
(const_int 1)
(match_operand:DI 1 "const_0_to_63_operand" ""))
(const_int 0))
(clobber (reg:CC FLAGS_REG))]
"TARGET_64BIT && (TARGET_USE_BT || reload_completed)"
"btr{q}\t{%1, %0|%0, %1}"
[(set_attr "type" "alu1")
(set_attr "prefix_0f" "1")
(set_attr "mode" "DI")])
and
/* X86_TUNE_USE_BT */
m_AMD_MULTIPLE | m_ATOM | m_CORE2I7 | m_GENERIC,
so it appears it should already be used by default.
[Bug c++/47771] New: gcc crashes on MinGW platform
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47771
Summary: gcc crashes on MinGW platform
Product: gcc
Version: 4.5.2
Status: UNCONFIRMED
Severity: major
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: parvez_ah...@yahoo.co.uk
Created attachment 23366
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=23366
Contains the cpp file which caused the crash
For the following program store in file crash.cpp:
#include
#include
int main(int argc, char **argv)
{
int longint = static_cast(pow(2, 32));
std::cout << longint;
}
when gcc run with the following option:
gcc crash.cpp -lstdc++ -lm
causes a crash.
The crash points to line no. 5
[Bug middle-end/47725] [x32] error: unable to find a register to spill in class DIREG
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47725 --- Comment #11 from hjl at gcc dot gnu.org 2011-02-16 20:15:12 UTC --- Author: hjl Date: Wed Feb 16 20:15:07 2011 New Revision: 170218 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=170218 Log: Check zero/sign extended hard registers in cant_combine_insn_p. 2011-02-15 H.J. Lu PR middle-end/47725 * combine.c (cant_combine_insn_p): Check zero/sign extended hard registers. Modified: branches/x32/gcc/ChangeLog.x32 branches/x32/gcc/combine.c
[Bug target/47766] [x32] -fstack-protector doesn't work
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47766 --- Comment #1 from hjl at gcc dot gnu.org 2011-02-16 20:22:06 UTC --- Author: hjl Date: Wed Feb 16 20:22:03 2011 New Revision: 170219 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=170219 Log: Add x32 support to stack protect and split. gcc/ 2011-02-16 H.J. Lu PR target/47766 * config/i386/i386.md (PTR): New. (stack_protect_set: Check TARGET_LP64 instead of TARGET_64BIT. (stack_protect_test): Likewise. (stack_protect_set_): Replace ":P" with ":PTR". (stack_tls_protect_set_): Likewise. (stack_tls_protect_test_): Likewise. * config/i386/linux64.h (TARGET_THREAD_SSP_OFFSET): Support TARGET_X32. (TARGET_THREAD_SPLIT_STACK_OFFSET): Likewise. gcc/testsuite/ 2011-02-16 H.J. Lu PR target/47766 * gcc.target/i386/pr47766.c: New. Added: branches/x32/gcc/testsuite/gcc.target/i386/pr47766.c Modified: branches/x32/gcc/ChangeLog.x32 branches/x32/gcc/config/i386/i386.md branches/x32/gcc/config/i386/linux64.h branches/x32/gcc/testsuite/ChangeLog.x32
[Bug c++/47326] [4.4/4.5/4.6 Regression][C++0x] ICE in tsubst_copy (triggered by dependency of return type on parameter pack size)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47326 --- Comment #11 from Dodji Seketeli 2011-02-16 20:45:18 UTC --- Author: dodji Date: Wed Feb 16 20:45:15 2011 New Revision: 170222 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=170222 Log: PR c++/47326 gcc/cp/ PR c++/47326 * pt.c (tsubst_copy): Ensure that even pack expansion arguments are not evaluated. gcc/testsuite/ PR c++/47326 * g++.dg/cpp0x/variadic106.C: New test. Added: trunk/gcc/testsuite/g++.dg/cpp0x/variadic106.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/pt.c trunk/gcc/testsuite/ChangeLog
[Bug c/47772] New: warnings from -Wmissing-field-initializers contradict documentation
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47772 Summary: warnings from -Wmissing-field-initializers contradict documentation Product: gcc Version: 4.5.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassig...@gcc.gnu.org ReportedBy: dar...@kulp.ch Created attachment 23367 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=23367 testcase re: -Wmissing-field-initializers and designated initializers According to gcc(1): -Wmissing-field-initializers Warn if a structure's initializer has some fields missing. ... This option does not warn about designated initializers This I find normally to be true. Attached is a test case that produces the following warning on GCC 4.2.1, 4.4.4., and 4.5.2: $ gcc -save-temps -Wmissing-field-initializers -c test3.c test3.c:14: warning: missing initializer test3.c:14: warning: (near initialization for ‘(anonymous)[0].b’) If the `b' field is initialized either before or after the `a' field, the warning disappears, but this should not be necessary, according to the documentation.
[Bug libstdc++/47773] New: Versatile string lacks a default hash function
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47773 Summary: Versatile string lacks a default hash function Product: gcc Version: 4.5.1 Status: UNCONFIRMED Severity: minor Priority: P3 Component: libstdc++ AssignedTo: unassig...@gcc.gnu.org ReportedBy: mlcre...@gmail.com Created attachment 23368 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=23368 Example code __gnu_cxx::__vstring is a nice API-compatible drop-in replacement for std::string. However, std::string defines hash functions, so that it can be used with unordered_xxx out of the box. Currently, the versatile string classes do not, so code which works with std::string fails with __gnu_cxx::__vstring, with an error like: ... undefined reference to `std::hash<__gnu_cxx::__versa_string, std::allocator, __gnu_cxx::__sso_string_base> >::operator()(__gnu_cxx::__versa_string, std::allocator, __gnu_cxx::__sso_string_base>) const' I just replicated what's already being done in in my code, so presumably the same could be done in .
[Bug fortran/47745] [OOP] Segfault with CLASS(*) and derived type dummy arguments
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47745 --- Comment #8 from janus at gcc dot gnu.org 2011-02-16 20:52:00 UTC --- Author: janus Date: Wed Feb 16 20:51:56 2011 New Revision: 170223 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=170223 Log: 2011-02-16 Janus Weil PR fortran/47745 * class.c (gfc_build_class_symbol): Set 'class_ok' attribute. * decl.c (build_sym,attr_decl1): Move setting of 'class_ok' into 'gfc_build_class_symbol'. (gfc_match_decl_type_spec): Reject unlimited polymorphism. * interface.c (matching_typebound_op): Check for 'class_ok' attribute. * match.c (select_type_set_tmp): Move setting of 'class_ok' into 'gfc_build_class_symbol'. * primary.c (gfc_variable_attr): Check for 'class_ok' attribute. 2011-02-16 Janus Weil PR fortran/47745 * gfortran.dg/class_39.f03: New. Added: trunk/gcc/testsuite/gfortran.dg/class_39.f03 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/class.c trunk/gcc/fortran/decl.c trunk/gcc/fortran/interface.c trunk/gcc/fortran/match.c trunk/gcc/fortran/primary.c trunk/gcc/testsuite/ChangeLog
[Bug fortran/47745] [OOP] Segfault with CLASS(*) and derived type dummy arguments
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47745 janus at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #9 from janus at gcc dot gnu.org 2011-02-16 20:53:58 UTC --- Fixed with r170223. Closing. Thanks for the report, Rodney!
[Bug c/47772] warnings from -Wmissing-field-initializers contradict documentation
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47772 --- Comment #1 from Darren Kulp 2011-02-16 20:58:17 UTC --- Here is the output of `gcc -v' on the one system to which I have direct access: Using built-in specs. Target: i686-apple-darwin10 Configured with: /var/tmp/gcc/gcc-5646~6/src/configure --disable-checking --enable-werror --prefix=/usr --mandir=/share/man --enable-languages=c,objc,c++,obj-c++ --program-transform-name=/^[cg][^.-]*$/s/$/-4.2/ --with-slibdir=/usr/lib --build=i686-apple-darwin10 --with-gxx-include-dir=/include/c++/4.2.1 --program-prefix=i686-apple-darwin10- --host=x86_64-apple-darwin10 --target=i686-apple-darwin10 Thread model: posix gcc version 4.2.1 (Apple Inc. build 5646)
[Bug c++/47326] [4.4/4.5/4.6 Regression][C++0x] ICE in tsubst_copy (triggered by dependency of return type on parameter pack size)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47326 Dodji Seketeli changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #12 from Dodji Seketeli 2011-02-16 21:08:43 UTC --- Fixed in trunk (4.6).
[Bug c++/47771] gcc crashes on MinGW platform
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47771 Kai Tietz changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||ktietz at gcc dot gnu.org Resolution||WORKSFORME --- Comment #1 from Kai Tietz 2011-02-16 21:09:07 UTC --- I tested it with a 4.5.2 32-bit/64-bit with mingw-w64 runtime, and with current 4.6 trunk version 32-bit/64-bit and I can reproduce this issue. It works nice and all versions are printing the same output: 2147483647 as to be expected. So please ask your the project providing this toolchain.
[Bug fortran/47767] [OOP] SELECT TYPE fails to execute correct TYPE IS block
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47767 janus at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED AssignedTo|unassigned at gcc dot |janus at gcc dot gnu.org |gnu.org | --- Comment #2 from janus at gcc dot gnu.org 2011-02-16 21:58:12 UTC --- Ok, I think what we need to do is basically to make sure that vtab/vtype symbols are always public and are not affected by PRIVATE statements. Here is a first patch: Index: gcc/fortran/module.c === --- gcc/fortran/module.c(revision 170222) +++ gcc/fortran/module.c(working copy) @@ -4874,7 +4874,8 @@ write_symbol0 (gfc_symtree *st) && !sym->attr.subroutine && !sym->attr.function) dont_write = true; - if (!gfc_check_access (sym->attr.access, sym->ns->default_access)) + if (!sym->attr.vtab && !sym->attr.vtype + && !gfc_check_access (sym->attr.access, sym->ns->default_access)) dont_write = true; if (!dont_write) @@ -4982,7 +4983,8 @@ write_symtree (gfc_symtree *st) && sym->ns->proc_name->attr.if_source == IFSRC_IFBODY) return; - if (!gfc_check_access (sym->attr.access, sym->ns->default_access) + if ((!sym->attr.vtab && !sym->attr.vtype + && !gfc_check_access (sym->attr.access, sym->ns->default_access)) || (sym->attr.flavor == FL_PROCEDURE && sym->attr.generic && !sym->attr.subroutine && !sym->attr.function)) return; This fixes the test case, but is not regtested yet.
[Bug fortran/47768] ICE: printing a derived-type variable with proc-pointer components
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47768 --- Comment #2 from janus at gcc dot gnu.org 2011-02-16 22:22:03 UTC --- (In reply to comment #1) > (In reply to comment #0) > > Adding a data pointer component leads to rejection: > > > > print *,x > > 1 > > Error: Data transfer element at (1) cannot have POINTER components > > > > So I'm guessing the version with proc-pointer is also illegal (haven't > > checked > > the standard). > > I have the feeling we reject too much here. F08 says in chapter 9.6.3: > > "If an output item is a pointer, it shall be associated with a target and data > are transferred from the target to the file." > > I think this is the same in F03 and F95. > So, it seems like pointers are ok (but should be associated), unless I'm > missing something. I indeed missed something. Further down in 9.6.3 one finds: "If a derived-type list item is not processed by a defined input/output procedure and is not treated as a list of its individual components, all the subcomponents of that list item shall be accessible in the scoping unit containing the input/output statement and shall not be pointers or allocatable." So, pointer components are indeed forbidden. All that's left to do here is to also reject procedure pointers and procedure pointer components.
[Bug tree-optimization/47770] wrong code -O2 -ftree-loop-if-convert-stores -fno-tree-reassoc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47770 --- Comment #1 from Zdenek Sojka 2011-02-16 22:36:17 UTC --- "-ftree-loop-if-convert -fno-tree-reassoc -fno-tree-vectorize" gives about 316 exec failures on current trunk. I should try the fix for PR46029 from http://gcc.gnu.org/ml/gcc-patches/2010-11/msg01613.html, but I am failing to apply it (I can't find the revision it applies to, and the mentioned 0001-Fix-PR46029-reimplement-if-convert-stores.patch in general).
[Bug fortran/47768] ICE: printing a derived-type variable with proc-pointer components
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47768
janus at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed||2011.02.16 22:37:22
AssignedTo|unassigned at gcc dot |janus at gcc dot gnu.org
|gnu.org |
Ever Confirmed|0 |1
--- Comment #3 from janus at gcc dot gnu.org 2011-02-16 22:37:22 UTC ---
(In reply to comment #2)
> So, pointer components are indeed forbidden. All that's left to do here is to
> also reject procedure pointers and procedure pointer components.
Here is a patch for rejecting PPCs:
Index: gcc/fortran/resolve.c
===
--- gcc/fortran/resolve.c (revision 170222)
+++ gcc/fortran/resolve.c (working copy)
@@ -8091,6 +8091,13 @@ resolve_transfer (gfc_code *code)
return;
}
+ if (ts->u.derived->attr.proc_pointer_comp)
+ {
+ gfc_error ("Data transfer element at %L cannot have "
+"procedure pointer components", &code->loc);
+ return;
+ }
+
if (ts->u.derived->attr.alloc_comp)
{
gfc_error ("Data transfer element at %L cannot have "
Procedure pointers are already rejected with:
print *,pp
1
Error: Function 'pp' requires an argument list at (1)
[Bug c++/47774] New: [C++0x] constexpr specifier on ctor not ignored when template instantiation causes ctor to not satify constexpr requirements
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47774
Summary: [C++0x] constexpr specifier on ctor not ignored when
template instantiation causes ctor to not satify
constexpr requirements
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: dev.li...@jessamine.co.uk
The definition of b in the program below fails to compile due to the default
constructor for its only member not being a valid constexpr. B itself does not
claim to be a literal type or that instances of it should be usable as
constants but g++ currently seems to enforce the constexpr nature of the ctor
of X even when T causes the definition to fail to meet the constexpr
constructor requirements.
7.1.5 para 4 states:
6 If the instantiated template specialization of a constexpr
function template or member function of a class template would
fail to satisfy the requirements for a constexpr function or
constexpr constructor, that specialization is not a constexpr
function or constexpr constructor. [Note: if the function is
a member function it will still be const as described below.
Implementations are encouraged to issue a warning if a
function is rendered not constexpr by a non-dependent
construct. --end note]
The program below demonstrates what I think to be non-compliance with this. It
is a reduced case (I originally came across this when attempting to instantiate
a std::array,N> where objects of either F or S were not usable
as constants; pair's default constructor is specified as constexpr yielding the
same problem).
template
struct X
{
constexpr X() : t() {}
T t;
};
struct CanBeCompileTimeConstant { constexpr CanBeCompileTimeConstant() {}
};
struct CannotBeCompileTimeConstant { CannotBeCompileTimeConstant() {} };
X nonconstexpr1;
X nonconstexpr2;
constexpr X constexpr1;
//constexpr X constexpr2; // fails as expected
struct A
{
X mem;
};
struct B
{
X mem;
};
A a;
B b; // fails unexpectedly: 'constexpr X::X() [with T =
CannotBeCompileTimeConstant]' is not 'constexpr'
[Bug libstdc++/47773] Versatile string lacks a default hash function
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47773 Paolo Carlini changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2011.02.16 22:44:18 AssignedTo|unassigned at gcc dot |paolo.carlini at oracle dot |gnu.org |com Target Milestone|--- |4.6.0 Ever Confirmed|0 |1 --- Comment #1 from Paolo Carlini 2011-02-16 22:44:18 UTC --- Sure. Seems safe enough for 4.6.0 too.
[Bug c++/47774] [C++0x] constexpr specifier on ctor not ignored when template instantiation causes ctor to not satify constexpr requirements
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47774 --- Comment #1 from Adam Butcher 2011-02-16 23:03:22 UTC --- Created attachment 23369 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=23369 Various declarations and constexpr specifications demonstrating problem -- runnable as sh script Added an additional test file, runnable as sh script, which tests various combinations of ctor specifications and member types. Compiling with gcc version 4.6.0 20110216 (experimental) (GCC) built tonight yields: $ sh constexpr-ctor-templ.cpp + g++ -c constexpr-ctor-templ.cpp -std=c++0x -DPLAIN_T -DUSE_SYNTHESIZED_X_CTOR + g++ -c constexpr-ctor-templ.cpp -std=c++0x -DPLAIN_T -DGIVE_X_EXPLICIT_CONSTEXPR_CTOR + g++ -c constexpr-ctor-templ.cpp -std=c++0x -DPLAIN_T -DGIVE_X_EXPLICIT_CONSTEXPR_CTOR + g++ -c constexpr-ctor-templ.cpp -std=c++0x -DPLAIN_T_ARRAY -DUSE_SYNTHESIZED_X_CTOR + g++ -c constexpr-ctor-templ.cpp -std=c++0x -DPLAIN_T_ARRAY -DGIVE_X_EXPLICIT_CONSTEXPR_CTOR constexpr-ctor-templ.cpp: In constructor ‘constexpr X::X() [with T = ncbool]’: constexpr-ctor-templ.cpp:148:14: instantiated from here constexpr-ctor-templ.cpp:103:24: error: ‘ncbool::ncbool(bool)’ is not ‘constexpr’ + g++ -c constexpr-ctor-templ.cpp -std=c++0x -DPLAIN_T_ARRAY -DGIVE_X_EXPLICIT_CONSTEXPR_CTOR constexpr-ctor-templ.cpp: In constructor ‘constexpr X::X() [with T = ncbool]’: constexpr-ctor-templ.cpp:148:14: instantiated from here constexpr-ctor-templ.cpp:103:24: error: ‘ncbool::ncbool(bool)’ is not ‘constexpr’ + g++ -c constexpr-ctor-templ.cpp -std=c++0x -DFLAG_T -DUSE_SYNTHESIZED_X_CTOR constexpr-ctor-templ.cpp: In constructor ‘X::X()’: constexpr-ctor-templ.cpp:100:8: error: ‘constexpr flag::flag(bool) [with BoolType = ncbool]’ is not ‘constexpr’ constexpr-ctor-templ.cpp: In function ‘int main(int, char**)’: constexpr-ctor-templ.cpp:148:14: note: synthesized method ‘X::X()’ first required here + g++ -c constexpr-ctor-templ.cpp -std=c++0x -DFLAG_T -DGIVE_X_EXPLICIT_CONSTEXPR_CTOR + g++ -c constexpr-ctor-templ.cpp -std=c++0x -DFLAG_T -DGIVE_X_EXPLICIT_CONSTEXPR_CTOR + g++ -c constexpr-ctor-templ.cpp -std=c++0x -DFLAG_T_ARRAY -DUSE_SYNTHESIZED_X_CTOR constexpr-ctor-templ.cpp: In constructor ‘constexpr X::X()’: constexpr-ctor-templ.cpp:100:8: error: ‘constexpr flag::flag(bool) [with BoolType = ncbool]’ is not ‘constexpr’ constexpr-ctor-templ.cpp:100:8: error: non-constant array initialization constexpr-ctor-templ.cpp: In function ‘int main(int, char**)’: constexpr-ctor-templ.cpp:148:14: note: synthesized method ‘X::X()’ first required here + g++ -c constexpr-ctor-templ.cpp -std=c++0x -DFLAG_T_ARRAY -DGIVE_X_EXPLICIT_CONSTEXPR_CTOR constexpr-ctor-templ.cpp: In constructor ‘constexpr X::X() [with T = ncbool]’: constexpr-ctor-templ.cpp:148:14: instantiated from here constexpr-ctor-templ.cpp:103:24: error: ‘constexpr flag::flag(bool) [with BoolType = ncbool]’ is not ‘constexpr’ + g++ -c constexpr-ctor-templ.cpp -std=c++0x -DFLAG_T_ARRAY -DGIVE_X_EXPLICIT_CONSTEXPR_CTOR constexpr-ctor-templ.cpp: In constructor ‘constexpr X::X() [with T = ncbool]’: constexpr-ctor-templ.cpp:148:14: instantiated from here constexpr-ctor-templ.cpp:103:24: error: ‘constexpr flag::flag(bool) [with BoolType = ncbool]’ is not ‘constexpr’ Failed 6
Re: [Bug lto/47247] Linker plugin specification makes it difficult to handle COMDATs
> 39339456 libxul1.so > 34436696 libxul2.so Yep, it seems similar to what I was getting. Quite important difference and all the stuff gets loaded into memory at startup by dynamic linker. > For a 5 MB reduction I might end up writing a wrapper that runs ld twice :-) You might try GNU-ld's plugin support (I am not sure if it has same problem, but I think it doesn't, definitly not with HJ's double linking branch). Honza
[Bug lto/47247] Linker plugin specification makes it difficult to handle COMDATs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47247 --- Comment #19 from Jan Hubicka 2011-02-16 23:12:32 UTC --- > 39339456 libxul1.so > 34436696 libxul2.so Yep, it seems similar to what I was getting. Quite important difference and all the stuff gets loaded into memory at startup by dynamic linker. > For a 5 MB reduction I might end up writing a wrapper that runs ld twice :-) You might try GNU-ld's plugin support (I am not sure if it has same problem, but I think it doesn't, definitly not with HJ's double linking branch). Honza
[Bug fortran/47767] [OOP] SELECT TYPE fails to execute correct TYPE IS block
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47767 --- Comment #3 from Andrew Benson 2011-02-16 23:17:49 UTC --- I can confirm that this patch resolves the problem in the application from which my original test case was derived.
[Bug lto/47247] Linker plugin specification makes it difficult to handle COMDATs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47247 --- Comment #20 from ccoutant at google dot com 2011-02-16 23:35:28 UTC --- > I have created a "small" test of the symbol table problem. It is in > > http://people.mozilla.com/~respindola/test.tar.xz > > The test is firefox's libxul with most files copied into one directory to make > it easy to run. The test script runs the link twice. First with the IL files > and then with combined .o file. > > The sizes are > > 39339456 libxul1.so > 34436696 libxul2.so > For a 5 MB reduction I might end up writing a wrapper that runs ld twice :-) That 5MB difference is all due to the dynamic symbol table? I think we can fix that in gold. : ) -cary
[Bug libfortran/47775] New: Error on allocatable array returned by function
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47775 Summary: Error on allocatable array returned by function Product: gcc Version: 4.5.3 Status: UNCONFIRMED Severity: major Priority: P3 Component: libfortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: fmarti...@gmv.com Created attachment 23370 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=23370 Modules, one program and a data file in XML A function returning an allocatable array seems to have the return array variable already allocated on entry to the function. The attempt to allocate it generates the error: Fortran runtime error: Attempting to allocate already allocated array 'res' In module t_dom_node_slist_ftl.f90 the commented lines 1358 to 1361 solve the problem but would expect that function return allocatable arrays are not allocated on entry (this is the observed behaviour in Intel and g95) The attached .tar.gz contains the collection of files that reproduce the problem (sorry, but I have not been able to isolate the problem in a smaller case). The compilation command line I have used is: > /opt/gfortran/bin/gfortran -g m_string.F90 m_messages.f90 m_util_convert.f90 > m_xml.f90 m_dom_element.f90 t_dom_element_pure_tree_ftl.f90 > t_string_slist_ftl.f90 m_dom_node.f90 t_dom_node_slist_ftl.f90 > m_dom_xpath.f90 m_dom.f90 m_unit_support.f90 unit_m_dom_xpath.f90 The resulting a.out has to be executed with the command line: > ./ a.out 1 this uses the file unit_m_dom.xml as input Cheers, Fran
[Bug fortran/47775] Error on allocatable array returned by function
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47775 kargl at gcc dot gnu.org changed: What|Removed |Added CC||kargl at gcc dot gnu.org Component|libfortran |fortran Severity|major |normal --- Comment #1 from kargl at gcc dot gnu.org 2011-02-16 23:48:21 UTC --- Reset component to fortran and importance to normal.
[Bug debug/47620] [4.6 Regression] Profiledbootstrap failure on powerpc-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47620 --- Comment #10 from Jakub Jelinek 2011-02-16 23:49:56 UTC --- Created attachment 23371 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=23371 ice.i.bz2 For the s390-linux ICE, which is still present on the current trunk: bunzip2 ice.i.bz2 ../configure --target s390-linux --enable-languages=c gcc/cc1 -O2 -g -m31 -fprofile-use -march=z9-109 -mtune=z10 ice.i
[Bug debug/47620] [4.6 Regression] Profiledbootstrap failure on powerpc-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47620 --- Comment #11 from Jakub Jelinek 2011-02-16 23:51:11 UTC --- Created attachment 23372 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=23372 ice.gcda Corresponding ice.gcda.
[Bug debug/47620] [4.6 Regression] Profiledbootstrap failure on powerpc-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47620 --- Comment #12 from Jakub Jelinek 2011-02-16 23:54:42 UTC --- The ICE happens even with the #c6 patch applied on top of today's trunk.
[Bug tree-optimization/47770] wrong code -O2 -ftree-loop-if-convert-stores -fno-tree-reassoc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47770 Sebastian Pop changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2011.02.17 00:36:38 AssignedTo|unassigned at gcc dot |spop at gcc dot gnu.org |gnu.org | Ever Confirmed|0 |1 --- Comment #2 from Sebastian Pop 2011-02-17 00:36:38 UTC --- I do not think that 0001-Fix-PR46029-reimplement-if-convert-stores.patch is the right way to fix this: I discussed with Ira Rosen about the vectorization of the code produced by this patch and we ended up realizing that the vectorizer would have to answer the same hard questions (memory accesses out of bounds and writes into read-only memory) that are now analyzed in -ftree-loop-if-convert-stores. I will look at how to fix these miscompiles.
[Bug fortran/47745] [OOP] Segfault with CLASS(*) and derived type dummy arguments
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47745 --- Comment #10 from rodneyp at physics dot uq.edu.au 2011-02-17 00:48:38 UTC --- > Thanks for the report, Rodney! Thanks for working so hard on the compiler. I'm learning Fortran 03 and 08 at the moment, so I'm likely to compile a lot of invalid code. Should I report a bug every time gfortran accepts code it should reject, or try to pick the serious ones?
[Bug fortran/47694] [4.3/4.4/4.5/4.6 Regression] Fortran read from named pipe fails to read all available data
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47694 --- Comment #12 from Jerry DeLisle 2011-02-17 01:07:20 UTC --- the "file" is not seekable so the position eturne by seek always returns zero. I plane to see if we can do something with the seek to get it to return a position within fbuf. If that does not seem reasonable, I will go with the fbuf_fgetc approach which should be fairly efficient.
[Bug fortran/47692] Numeric inaccuracy reported in testing lapack-3.3.0 BLAS module
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47692 --- Comment #13 from Jerry DeLisle 2011-02-17 01:12:44 UTC --- Always set LD_LIBRARY_PATH or another way is to compile with -static to make sure the correct runtime functions get invoked.
[Bug lto/47247] Linker plugin specification makes it difficult to handle COMDATs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47247 --- Comment #21 from Rafael Avila de Espindola 2011-02-17 01:13:35 UTC --- Most of it is in the string table. Ian gave me some pointers and I will try to fix it tomorrow :-)
[Bug libstdc++/47773] Versatile string lacks a default hash function
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47773 --- Comment #2 from paolo at gcc dot gnu.org 2011-02-17 01:24:42 UTC --- Author: paolo Date: Thu Feb 17 01:24:37 2011 New Revision: 170235 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=170235 Log: 2011-02-16 Paolo Carlini PR libstdc++/47773 * include/ext/vstring.h (hash<__gnu_cxx::__vstring>, hash<__gnu_cxx::__wvstring>, hash<__gnu_cxx::__u16vstring>, hash<__gnu_cxx::__u32vstring>): Add. * testsuite/ext/vstring/hash/char/1.cc: New. * testsuite/ext/vstring/hash/wchar_t/1.cc: Likewise. Added: trunk/libstdc++-v3/testsuite/ext/vstring/hash/ trunk/libstdc++-v3/testsuite/ext/vstring/hash/char/ trunk/libstdc++-v3/testsuite/ext/vstring/hash/char/1.cc trunk/libstdc++-v3/testsuite/ext/vstring/hash/wchar_t/ trunk/libstdc++-v3/testsuite/ext/vstring/hash/wchar_t/1.cc Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/include/ext/vstring.h
[Bug libstdc++/47773] Versatile string lacks a default hash function
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47773 Paolo Carlini changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #3 from Paolo Carlini 2011-02-17 01:26:59 UTC --- Done.
[Bug libstdc++/47724] [C++0x] Regex string anchors cause segfault
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47724 --- Comment #5 from Jonathan Wakely 2011-02-17 01:47:25 UTC --- Author: redi Date: Thu Feb 17 01:47:21 2011 New Revision: 170236 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=170236 Log: 2011-02-17 Jonathan Wakely PR libstdc++/47724 * include/bits/regex_compiler.h (_Scanner::_M_advance): Do not treat line anchors as metacharacters. * testsuite/28_regex/basic_regex/ctors/47724.cc: New. Added: trunk/libstdc++-v3/testsuite/28_regex/basic_regex/ctors/47724.cc Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/include/bits/regex_compiler.h
[Bug libstdc++/46207] std::atomic::store(...) fails to compile
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46207 Paolo Carlini changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED Target Milestone|--- |4.6.0 --- Comment #9 from Paolo Carlini 2011-02-17 01:49:59 UTC --- atomic_address is gone, this works fine now!
[Bug libstdc++/47724] [C++0x] Regex string anchors cause segfault
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47724 --- Comment #6 from Jonathan Wakely 2011-02-17 01:55:05 UTC --- I've checked in a change which prevents the crash, but only by treating line anchors as non-metacharacters. Unfortunately our regex implementation is incomplete, but this is better than crashing
[Bug libstdc++/47724] [C++0x] Regex string anchors cause segfault
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47724 Jonathan Wakely changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #7 from Jonathan Wakely 2011-02-17 01:56:07 UTC --- ... so fixed
[Bug fortran/47745] [OOP] Segfault with CLASS(*) and derived type dummy arguments
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47745 --- Comment #11 from kargl at gcc dot gnu.org 2011-02-17 02:57:08 UTC --- (In reply to comment #10) > > I'm learning Fortran 03 and 08 at the moment, so I'm likely to compile > a lot of invalid code. Should I report a bug every time gfortran > accepts code it should reject, or try to pick the serious ones? Yes, report bugs. This includes gfortran accepting invalid code, crashing on valid code, crashing on invalid code. Bugs, that go unreported, can't be fixed.
[Bug libstdc++/47776] New: [4.6 Regression] New libstc++ test failures
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47776 Summary: [4.6 Regression] New libstc++ test failures Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ AssignedTo: unassig...@gcc.gnu.org ReportedBy: hjl.to...@gmail.com CC: paolo.carl...@oracle.com On Linux/ia32, revision 170237 gave FAIL: ext/vstring/hash/char/1.cc execution test FAIL: ext/vstring/hash/wchar_t/1.cc execution test It is caused by revision 170235: http://gcc.gnu.org/ml/gcc-cvs/2011-02/msg00780.html
[Bug libfortran/47567] Wrong output for small absolute values with F editing
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47567 --- Comment #15 from Jerry DeLisle 2011-02-17 05:19:54 UTC --- Author: jvdelisle Date: Thu Feb 17 05:19:50 2011 New Revision: 170239 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=170239 Log: 2011-02-16 Jerry DeLisle PR libgfortran/47567 * io/list_read.c (read_logical): Check for end of line before calling eat_line. (read_integer): Likewise. (parse_real): Don't unget the separator. Check for end of line before callingeat_line. (read_complex): Allow line-end before and after parenthesis and comma. Check for end of line before calling eat_line. (read_real): Check for end of line before calling eat_line. Modified: trunk/libgfortran/ChangeLog trunk/libgfortran/io/list_read.c
[Bug c++/47172] [4.6 Regression] [C++0x] cannot call member function without object
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47172 --- Comment #9 from Dodji Seketeli 2011-02-17 06:50:40 UTC --- Author: dodji Date: Thu Feb 17 06:50:35 2011 New Revision: 170240 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=170240 Log: Fix PR c++/47172 gcc/cp/ PR c++/47172 * pt.c (finish_call_expr): Consider a call expression that has a dependent "this" pointer as being dependent. Add comments. (dependent_type_p, type_dependent_expression_p): Update comments. gcc/testsuite/ * g++.dg/template/inherit6.C: New test. Added: trunk/gcc/testsuite/g++.dg/template/inherit6.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/pt.c trunk/gcc/cp/semantics.c trunk/gcc/testsuite/ChangeLog
[Bug c++/47172] [4.6 Regression] [C++0x] cannot call member function without object
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47172 Dodji Seketeli changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #10 from Dodji Seketeli 2011-02-17 06:52:04 UTC --- Hopefully fixed in trunk (4.6) this time.
[Bug target/47777] New: use __aeabi_idivmod to compute quotient and remainder at the same time
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=4
Summary: use __aeabi_idivmod to compute quotient and remainder
at the same time
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: target
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: car...@google.com
Target: arm-eabi
Compile the following source code with options -march=armv7-a -O2
int t06(int x, int y)
{
int a = x / y;
int b = x % y;
return a+b;
}
GCC 4.6 generates:
t06:
@ args = 0, pretend = 0, frame = 0
@ frame_needed = 0, uses_anonymous_args = 0
stmfdsp!, {r4, r5, r6, lr}
movr6, r0
movr5, r1
bl__aeabi_idiv
movr1, r5
movr4, r0
movr0, r6
bl__aeabi_idivmod
addr0, r4, r1
ldmfdsp!, {r4, r5, r6, pc}
It calls function __aeabi_idiv to compute quotient and calls __aeabi_idivmod to
compute remainder. Actually __aeabi_idivmod can compute quotient and remainder
at the same time. By taking advantage of this we can simplify the code to
push{r4, lr}
bl__aeabi_idivmod
addr0, r0, r1
pop{r4, pc}
[Bug fortran/47775] Error on allocatable array returned by function
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47775 Tobias Burnus changed: What|Removed |Added CC||burnus at gcc dot gnu.org --- Comment #2 from Tobias Burnus 2011-02-17 07:33:55 UTC --- If I try the example, I get a segmentation fault in m_string.F90's string_to_char The code looks as follows: elemental function string_to_char( s ) result(res) [...] character(len=size(s%string)) :: res [...] if( allocated(s%string) ) then res = transfer( s%string, res ) else res = '' end if The crash happens in the "res =''" line and makes perfectly sense. If the variable "s%string" is not allocated, it is not surprising that there is a segfault: "13.7.156 SIZE (ARRAY [, DIM, KIND])" [...] "Arguments. 'ARRAY shall be an array of any type. It shall not be an unallocated allocatable variable or a pointer that is not associated."
[Bug libstdc++/47776] [4.6 Regression] New libstc++ test failures
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47776 Paolo Carlini changed: What|Removed |Added CC|paolo.carlini at oracle dot | |com | AssignedTo|unassigned at gcc dot |paolo.carlini at oracle dot |gnu.org |com Target Milestone|--- |4.6.0
