[Bug fortran/46978] [4.6 Regression] TRANSPOSE with RESHAPE and ALLOCATE: Segfault
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46978 --- Comment #9 from Martien Hulsen m.a.hulsen at tue dot nl 2010-12-23 09:13:05 UTC --- (In reply to comment #7) This seems to fix it, though I find it somewhat suspicious. With this change all my test cases run fine again. Thanks.
[Bug regression/47037] 465.tonto Segmentation Fault in memset
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47037 Thomas Koenig tkoenig at gcc dot gnu.org changed: What|Removed |Added CC||tkoenig at gcc dot gnu.org --- Comment #2 from Thomas Koenig tkoenig at gcc dot gnu.org 2010-12-23 09:13:59 UTC --- Can you supply a simplified test case? This might be a gfortran bug, but it's hard to tell.
[Bug c++/47049] New: internal compiler error: in write_unnamed_type_name due to C++0x lamba use
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47049
Summary: internal compiler error: in write_unnamed_type_name
due to C++0x lamba use
Product: gcc
Version: 4.5.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: emn13+...@nerbonne.org
Created attachment 22842
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=22842
Preprocessed source
errtest.cpp: In lambda function:
errtest.cpp:16:78: internal compiler error: in write_unnamed_type_name, at
cp/mangle.c:1311
While using a mingw64 build I encountered the above ICE and reported it @
http://sourceforge.net/tracker/?func=detailatid=983354aid=3141173group_id=202880
It was suggested that this is a gcc bug (and it looks like it). I'm using a
lambda in a class template; as follows:
std::sort(v.begin(),v.end(), [eigenvaluesUnsorted](size_t a, size_t b) - bool
{ return eigenvaluesUnsorted(a) eigenvaluesUnsorted(b);});
Attached are the small unpreprocessed source, the huge preprocessed source, and
g++'s output. The command line was:
g++ -I%EIGEN3_DIR% --std=c++0x -march=core2 -v -save-temps errtest.cpp
2gcc-err.txt
[Bug c++/47049] internal compiler error: in write_unnamed_type_name due to C++0x lamba use
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47049 --- Comment #1 from Eamon Nerbonne emn13+gcc at nerbonne dot org 2010-12-23 09:30:20 UTC --- Created attachment 22843 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=22843 G++'s output
[Bug c++/47049] internal compiler error: in write_unnamed_type_name due to C++0x lamba use
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47049 --- Comment #2 from Eamon Nerbonne emn13+gcc at nerbonne dot org 2010-12-23 09:31:24 UTC --- Created attachment 22844 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=22844 Unpreprocessed source (depends on Eigen3)
[Bug c++/47049] internal compiler error: in write_unnamed_type_name due to C++0x lamba use
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47049 --- Comment #3 from Eamon Nerbonne emn13+gcc at nerbonne dot org 2010-12-23 09:33:11 UTC --- Oh, and finally: a comment on the mingw64 tracker is meaningless to me but perhaps useful to you: ktietz70 said: So, I investigate your issue a bit. First this is for sure a gcc bug, which calls here write_unnamed_type_name for an ENUMERAL_TYPE, which isn't unnamed. The issue is related to write_nested_name, which doesn't special case here named enumeral types.
[Bug libstdc++/47045] NetBSD: define changes in ctype.h
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47045 --- Comment #2 from Thomas Klausner tk at giga dot or.at 2010-12-23 09:35:32 UTC --- I can test on 5.99.40 and 5.99.41/amd64. Just send me short instructions how to test. Thanks!
[Bug libfortran/46720] [4.6 Regression] missing quadmath_weak.h with --enable-maintainer-mode
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46720 --- Comment #8 from Thomas Koenig tkoenig at gcc dot gnu.org 2010-12-23 09:41:08 UTC --- (In reply to comment #7) * PING * Can you still reproduce it -- with the correct version of automake installed? With the correct automake, there is no error. Close as INVALID?
[Bug libfortran/46720] [4.6 Regression] missing quadmath_weak.h with --enable-maintainer-mode
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46720 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|WAITING |RESOLVED Resolution||INVALID
[Bug libstdc++/47045] NetBSD: define changes in ctype.h
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47045 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added AssignedTo|unassigned at gcc dot |redi at gcc dot gnu.org |gnu.org | --- Comment #3 from Jonathan Wakely redi at gcc dot gnu.org 2010-12-23 10:01:13 UTC --- Created attachment 22845 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=22845 check version in config/os/bsd/netbsd/ctype_base.h Does sys/param.h get included via ctype.h or do I need to include it explicitly? This patch includes it explicitly. To test this you'll need to check out svn trunk (or download the gcc-core and gcc-g++ tarballs from a recent snapshot) and apply this patch in the libstdc++-v3 directory, then build the compiler. Let me know if you need details of how to build the compiler if you don't have the GMP, MPFR and MPC prerequisite libs installed
[Bug target/46934] gcc ICE: error: unrecognizable insn: in extract_insn, at recog.c:2109
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46934 Chung-Lin Tang cltang at gcc dot gnu.org changed: What|Removed |Added CC||cltang at gcc dot gnu.org --- Comment #2 from Chung-Lin Tang cltang at gcc dot gnu.org 2010-12-23 10:09:29 UTC --- I think this can be solved by changing the predicate of operand[2] in *thumb1_addsi3 to reg_or_int_operand. This allows later passes like reload to do its job. However, after the above change, I see another ICE during reload: h.c:16:1: error: unrecognizable insn: (insn 88 3 6 2 (set (reg:SI 3 r3) (const_int 2147483648 [0x8000])) h.c:5 -1 (nil)) h.c:16:1: internal compiler error: in extract_insn, at recog.c:2127 This turns out to be because, the generic 'general_operand' predicate used in thumb1_movsi_insn does a trunc_int_for_mode (INTVAL(op), mode) == INTVAL(op) test, and 0x8000 (2147483648) gets negated due to the sign-extension in trunc_int_for_mode(), failing the equality test: trunc_int_for_mode(2147483648, SImode) == -2147483648 (0x8000) We can probably fix this by using another ARM predicate in this case, though this boundary case of trunc_int_for_mode() is troubling, as the above truncate-and-test-for-equality idiom seems quite common in the compiler.
[Bug ada/47017] [4.6 Regression] gnatlib ICE on sparc64-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47017 --- Comment #1 from Laurent GUERBY laurent at guerby dot net 2010-12-23 10:27:54 UTC --- on sparc32-linux (--with-cpu=v8) bootstrap and gnatlib work fine: http://gcc.gnu.org/ml/gcc-testresults/2010-12/msg02070.html So this is a 64 bits issue.
[Bug preprocessor/47047] Support for path translation in __FILE__
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47047 --- Comment #1 from joseph at codesourcery dot com joseph at codesourcery dot com 2010-12-23 12:16:37 UTC --- On Thu, 23 Dec 2010, joerg at netbsd dot org wrote: The patch is the version included in NetBSD against the system gcc, it can be updated if necessary. Who are the authors of this patch? It's large enough that it can't be considered without a copyright assignment on file with the FSF (and given such an assignment a version against trunk would then need to be submitted).
[Bug testsuite/41146] FAIL: gcc.target/powerpc/asm-es-2.c scan-assembler *
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41146 --- Comment #3 from Dominique d'Humieres dominiq at lps dot ens.fr 2010-12-23 12:34:27 UTC --- An updated patch has been posted at http://gcc.gnu.org/ml/gcc-patches/2010-12/msg01765.html .
[Bug c++/46626] [4.6 Regression] simple use of virtual methods causes pure virtual method call in c++0x mode
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46626 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED AssignedTo|unassigned at gcc dot |jakub at gcc dot gnu.org |gnu.org | --- Comment #7 from Jakub Jelinek jakub at gcc dot gnu.org 2010-12-23 12:34:40 UTC --- Created attachment 22846 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=22846 gcc46-pr46626.patch Untested fix. The problem seems to be that the B::B() ctor body, which is constexpr (and g++ generated) has a CLEANUP_STMT in it, and build_data_member_initialization ignores CLEANUP_STMT, which means the setting of vtable pointer to _ZTV1B + 16 is ignored, thus it stays to be _ZTV1A + 16. The attached patch handles CLEANUP_BODY of CLEANUP_STMT by recursing into it.
[Bug preprocessor/47047] Support for path translation in __FILE__
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47047 --- Comment #2 from joerg at britannica dot bec.de 2010-12-23 12:51:33 UTC --- On Thu, Dec 23, 2010 at 12:16:40PM +, joseph at codesourcery dot com wrote: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47047 --- Comment #1 from joseph at codesourcery dot com joseph at codesourcery dot com 2010-12-23 12:16:37 UTC --- On Thu, 23 Dec 2010, joerg at netbsd dot org wrote: The patch is the version included in NetBSD against the system gcc, it can be updated if necessary. Who are the authors of this patch? It's large enough that it can't be considered without a copyright assignment on file with the FSF (and given such an assignment a version against trunk would then need to be submitted). I am the author of the text. Where can I find the papers for the FSF? Joerg
[Bug testsuite/47050] New: gcc.target/i386/aggregate-ret[12].c FAIL with -m64
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47050 Summary: gcc.target/i386/aggregate-ret[12].c FAIL with -m64 Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: testsuite AssignedTo: unassig...@gcc.gnu.org ReportedBy: r...@gcc.gnu.org CC: kai.ti...@onevision.de Host: i386-pc-solaris2.1[01] Target: i386-pc-solaris2.1[01] Build: i386-pc-solaris2.1[01] The two new testcases gcc.target/i386/aggregate-ret[12].c fail on Solaris 10/11 x86 with -m64: FAIL: gcc.target/i386/aggregate-ret1.c (test for excess errors) Excess errors: /vol/gcc/src/hg/trunk/solaris/gcc/testsuite/gcc.target/i386/aggregate-ret1.c:17:1: warning: 'callee_pop_aggregate_return' attribute only available for 32-bit [-Wattributes] FAIL: gcc.target/i386/aggregate-ret2.c (test for excess errors) Excess errors: /vol/gcc/src/hg/trunk/solaris/gcc/testsuite/gcc.target/i386/aggregate-ret2.c:17:1: warning: 'callee_pop_aggregate_return' attribute only available for 32-bit [-Wattributes] FAIL: gcc.target/i386/aggregate-ret2.c scan-assembler ret[ \t]\\$4 The tests obviously need an ilp32.
[Bug fortran/47051] New: [4.6 Regression] wrong reallocate
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47051 Summary: [4.6 Regression] wrong reallocate Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: joost.vandevond...@pci.uzh.ch In the following a reallocation seems to happen, changing the bounds of a. However the size of a and b are the same, so I would not expect this. INTEGER, DIMENSION(:), ALLOCATABLE :: a,b ALLOCATE(a(-1:1),b(1:3)) b=0 a=b write(6,*) LBOUND(a) IF(LBOUND(a,1).NE.-1) STOP BUG END
[Bug fortran/46978] [4.6 Regression] TRANSPOSE with RESHAPE and ALLOCATE: Segfault
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46978 --- Comment #10 from Mikael Morin mikael at gcc dot gnu.org 2010-12-23 13:35:57 UTC --- Author: mikael Date: Thu Dec 23 13:35:53 2010 New Revision: 168206 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=168206 Log: 2010-12-23 Mikael Morin mikael.mo...@gcc.gnu.org PR fortran/46978 Revert part of revision 164112 * trans-array.c (gfc_trans_create_temp_array): Set loop n'th upper bound from (possibly transposed) array's dim bounds. Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/trans-array.c
[Bug fortran/47051] [4.6 Regression] wrong reallocate
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47051 --- Comment #1 from Dominique d'Humieres dominiq at lps dot ens.fr 2010-12-23 13:36:40 UTC --- ... so I would not expect this. Why?
[Bug fortran/46978] [4.6 Regression] TRANSPOSE with RESHAPE and ALLOCATE: Segfault
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46978 --- Comment #11 from Mikael Morin mikael at gcc dot gnu.org 2010-12-23 13:39:10 UTC --- Author: mikael Date: Thu Dec 23 13:39:06 2010 New Revision: 168207 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=168207 Log: 2010-12-23 Mikael Morin mik...@gcc.gnu.org PR fortran/46978 * gfortran.dg/transpose_intrinsic_func_call_1.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/transpose_intrinsic_func_call_1.f90 Modified: trunk/gcc/testsuite/ChangeLog
[Bug fortran/46978] [4.6 Regression] TRANSPOSE with RESHAPE and ALLOCATE: Segfault
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46978 Mikael Morin mikael at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #12 from Mikael Morin mikael at gcc dot gnu.org 2010-12-23 13:43:08 UTC --- Fixed. Thanks for the bug report.
[Bug fortran/47051] [4.6 Regression] wrong reallocate
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47051 --- Comment #2 from Joost VandeVondele Joost.VandeVondele at pci dot uzh.ch 2010-12-23 13:46:50 UTC --- (In reply to comment #1) ... so I would not expect this. Why? that would imply that F95 code and F2003 code are not compatible ? Or was this not allowed in F95 (certainly that was in CP2K, and no compiler ever gave a bounds check error)
[Bug fortran/47051] [4.6 Regression] wrong reallocate
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47051 --- Comment #3 from Joost VandeVondele Joost.VandeVondele at pci dot uzh.ch 2010-12-23 13:56:29 UTC --- OK, more checking. F2003 specifies that the lhs should only be deallocated if it differs in shape. a and b have the same shape here.
[Bug libstdc++/47052] New: make: *** [configure-target-libstdc++-v3] Error 1 Cross compile GCC for Alpha Architecture
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47052 Summary: make: *** [configure-target-libstdc++-v3] Error 1 Cross compile GCC for Alpha Architecture Product: gcc Version: 4.0.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ AssignedTo: unassig...@gcc.gnu.org ReportedBy: wen.jian.o...@gmail.com Hi there ,, I'm Cross compiling a GNU GCC for Alpha Architecture on my i686-pc-linux-gnu machine. The crosstool that I used is gcc-4.0.2-glibc-2.3.6 and the output is shown below , checking if alpha-unknown-linux-gnu-gcc supports -fno-rtti -fno-exceptions ... no checking whether the linker (alpha-unknown-linux-gnu-ld) supports shared libraries... yes checking how to hardcode library paths into programs... immediate checking whether stripping libraries is possible... yes checking dynamic linker characteristics... GNU/Linux ld.so checking command to parse alpha-unknown-linux-gnu-nm output... ok checking if libtool supports shared libraries... yes checking whether to build shared libraries... yes checking whether to build static libraries... yes creating libtool updating cache ./config.cache configure: loading cache ./config.cache checking how to run the C++ preprocessor... /lib/cpp loading cache ./config.cache within ltconfig checking host system type... alpha-unknown-linux-gnu checking build system type... i686-pc-linux-gnu ltcf-cxx.sh: error: problem compiling test program checking for objdir... .libs checking for alpha-unknown-linux-gnu-c++ option to produce PIC... -DPIC checking if alpha-unknown-linux-gnu-c++ PIC flag -DPIC works... no checking if alpha-unknown-linux-gnu-c++ static flag works... no finding the maximum length of command line arguments... (cached) 49153 checking if alpha-unknown-linux-gnu-c++ supports -c -o file.o... (cached) yes checking whether the linker (alpha-unknown-linux-gnu-ld) supports shared libraries... checking how to hardcode library paths into programs... unsupported checking whether stripping libraries is possible... yes checking dynamic linker characteristics... GNU/Linux ld.so checking command to parse alpha-unknown-linux-gnu-nm output... failed checking if libtool supports shared libraries... no checking whether to build shared libraries... no checking whether to build static libraries... yes appending configuration tag CXX to libtool checking for exception model to use... configure: error: unable to detect exception model make: *** [configure-target-libstdc++-v3] Error 1
[Bug rtl-optimization/45051] [4.6 Regression]: gcc.c-torture/execute/builtins/abs-2.c and abs-3.c due to track subwords of DImode allocnos
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45051 --- Comment #9 from Hans-Peter Nilsson hp at gcc dot gnu.org 2010-12-23 14:29:13 UTC --- (In reply to comment #8) Nevertheless, I'm testing r162418 with your patch. FWIW, no regressions for cris-elf, with your patch (manually) applied on top of Bernds's patch applied to r162418.
[Bug fortran/47051] [4.6 Regression] wrong reallocate
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47051 --- Comment #4 from Dominique d'Humieres dominiq at lps dot ens.fr 2010-12-23 15:13:46 UTC --- I have raised a similar question in http://gcc.gnu.org/ml/fortran/2010-11/msg4.html answered in the following posts in this thread. The relevant part of the standard (from f2008 draft) is 7.2.1.3 Interpretation of intrinsic assignments ... 3 If the variable is an unallocated allocatable array, expr shall have the same rank. If the variable is an allocated allocatable variable, it is deallocated if expr is an array of diff erent shape, any of the corresponding length type parameter values of the variable and expr diff er, or the variable is polymorphic and the dynamic type of the variable and expr diff er. If the variable is or becomes an unallocated allocatable variable, it is then allocated with if the variable is polymorphic, the same dynamic type as expr, each deferred type parameter equal to the corresponding type parameter of expr, if the variable is an array and expr is scalar, the same bounds as before, and if expr is an array, the shape of expr with each lower bound equal to the corresponding element of LBOUND (expr). NOTE 7.36 For example, given the declaration CHARACTER(:),ALLOCATABLE :: NAME then after the assignment statement NAME = 'Dr. '//FIRST_NAME//' '//SURNAME NAME will have the length LEN(FIRST NAME)+LEN(SURNAME)+5, even if it had previously been unallocated, or allocated with a di erent length. However, for the assignment statement NAME(:) = 'Dr. '//FIRST_NAME//' '//SURNAME NAME must already be allocated at the time of the assignment; the assigned value is truncated or blank padded to the previously allocated length of NAME. For which a strict reading of If the variable is or becomes an unallocated allocatable variable, ... the shape of expr with each lower bound equal to the corresponding element of LBOUND (expr). support this PR since a is not deallocated. If this reading is right it will be a very strong restriction for reallocate on assignement: INTEGER, DIMENSION(:), ALLOCATABLE :: a,b,c,d ALLOCATE(a(-1:1),b(1:3),c(2:3),d(3:6)) b=0 c=0 d=0 a=b write(6,*) LBOUND(a), size(a) a=c write(6,*) LBOUND(a), size(a) a=d write(6,*) LBOUND(a), size(a) END will give -1 3 2 2 3 4 Note that there are two work-around: (1) compile with -fno-realloc-lhs, (2) use a(:).
[Bug fortran/47051] [4.6 Regression] wrong reallocate
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47051 --- Comment #5 from Joost VandeVondele Joost.VandeVondele at pci dot uzh.ch 2010-12-23 15:32:14 UTC --- (In reply to comment #4) Hi Dominique, I have read exactly this: 3 If the variable is an unallocated allocatable array, expr shall have the same rank. If the variable is an allocated allocatable variable, it is deallocated if expr is an array of diff erent shape, any of the corresponding length type parameter values of the variable and expr diff er, or the variable is polymorphic and the dynamic type of the variable and expr diff er. this section explicitly says it is deallocated only if the shape is different. In my example, the shape is the same (even if the bounds are different). There is thus no need to deallocate a, and reallocate afterwards with the bounds of b. Joost
[Bug c++/46941] [trans-mem] new/delete operator are unsafe
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46941 --- Comment #3 from Patrick Marlier patrick.marlier at gmail dot com 2010-12-23 15:45:15 UTC --- Actually, I was guessing that the patch was not intrusive. Wrong guess, play again... I should really spend more time on hacking gcc ;) Anyway, Thank you for your advices! (I will follow them next time!) About the bug itself, I will not have time to look at it these days.
[Bug tree-optimization/47053] New: [4.5/4.6 Regression] ICE: verify_flow_info failed: BB 2 can not throw but has an EH edge with -O -fnon-call-exceptions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47053 Summary: [4.5/4.6 Regression] ICE: verify_flow_info failed: BB 2 can not throw but has an EH edge with -O -fnon-call-exceptions Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization AssignedTo: unassig...@gcc.gnu.org ReportedBy: zso...@seznam.cz Host: x86_64-pc-linux-gnu Target: x86_64-pc-linux-gnu Created attachment 22847 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=22847 reduced testcase Compiler output: $ gcc -O -fnon-call-exceptions pr47053.C pr47053.C: In function 'void foo()': pr47053.C:17:6: error: BB 2 can not throw but has an EH edge pr47053.C:17:6: internal compiler error: verify_flow_info failed Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. (gdb) bt #0 error (gmsgid=0x12db400 BB %i can not throw but has an EH edge) at /mnt/svn/gcc-trunk/gcc/diagnostic.c:747 #1 0x00a5b65c in verify_eh_edges (stmt=0x75d71160) at /mnt/svn/gcc-trunk/gcc/tree-eh.c:3997 #2 0x00a2fcbb in gimple_verify_flow_info () at /mnt/svn/gcc-trunk/gcc/tree-cfg.c:4538 #3 0x00733384 in verify_flow_info () at /mnt/svn/gcc-trunk/gcc/cfghooks.c:257 #4 0x00b210f0 in fini_reassoc () at /mnt/svn/gcc-trunk/gcc/tree-ssa-reassoc.c:2247 #5 execute_reassoc () at /mnt/svn/gcc-trunk/gcc/tree-ssa-reassoc.c:2260 #6 0x0093a2e6 in execute_one_pass (pass=0x17baee0) at /mnt/svn/gcc-trunk/gcc/passes.c:1553 #7 0x0093a5d5 in execute_pass_list (pass=0x17baee0) at /mnt/svn/gcc-trunk/gcc/passes.c:1608 #8 0x0093a5e7 in execute_pass_list (pass=0x17b9d40) at /mnt/svn/gcc-trunk/gcc/passes.c:1609 #9 0x00a7a846 in tree_rest_of_compilation (fndecl=0x75d31b00) at /mnt/svn/gcc-trunk/gcc/tree-optimize.c:422 #10 0x00c3fd72 in cgraph_expand_function (node=0x75d3bc60) at /mnt/svn/gcc-trunk/gcc/cgraphunit.c:1508 #11 0x00c4244a in cgraph_expand_all_functions () at /mnt/svn/gcc-trunk/gcc/cgraphunit.c:1567 #12 cgraph_optimize () at /mnt/svn/gcc-trunk/gcc/cgraphunit.c:1827 #13 0x00c429ca in cgraph_finalize_compilation_unit () at /mnt/svn/gcc-trunk/gcc/cgraphunit.c:1031 #14 0x005b786d in cp_write_global_declarations () at /mnt/svn/gcc-trunk/gcc/cp/decl2.c:3974 #15 0x00a240b6 in compile_file (argc=15, argv=0x7fffdad8) at /mnt/svn/gcc-trunk/gcc/toplev.c:591 #16 do_compile (argc=15, argv=0x7fffdad8) at /mnt/svn/gcc-trunk/gcc/toplev.c:1874 #17 toplev_main (argc=15, argv=0x7fffdad8) at /mnt/svn/gcc-trunk/gcc/toplev.c:1937 #18 0x76586bbd in __libc_start_main () from /lib/libc.so.6 #19 0x004fe9ed in _start () Tetsted revisions: r168200 - crash 4.5 r168062 - crash 4.4 r168062 - OK
[Bug tree-optimization/47053] [4.5/4.6 Regression] ICE: verify_flow_info failed: BB 2 can not throw but has an EH edge with -O -fnon-call-exceptions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47053 Steven Bosscher steven at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2010.12.23 15:55:50 CC||steven at gcc dot gnu.org AssignedTo|unassigned at gcc dot |steven at gcc dot gnu.org |gnu.org | Ever Confirmed|0 |1 --- Comment #1 from Steven Bosscher steven at gcc dot gnu.org 2010-12-23 15:55:50 UTC --- Probably one of the remaining tree-ssa-phiopt.c issues mentioned by Richi.
[Bug preprocessor/47047] Support for path translation in __FILE__
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47047 --- Comment #3 from joseph at codesourcery dot com joseph at codesourcery dot com 2010-12-23 16:13:53 UTC --- On Thu, 23 Dec 2010, joerg at britannica dot bec.de wrote: On Thu, 23 Dec 2010, joerg at netbsd dot org wrote: The patch is the version included in NetBSD against the system gcc, it can be updated if necessary. Who are the authors of this patch? It's large enough that it can't be considered without a copyright assignment on file with the FSF (and given such an assignment a version against trunk would then need to be submitted). I am the author of the text. Where can I find the papers for the FSF? Please fill in the form at http://gcc.gnu.org/wiki/CopyrightAssignment and send it to fsf-reco...@gnu.org and they will then send you the appropriate assignment form.
[Bug c++/46941] [trans-mem] new/delete operator are unsafe
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46941 --- Comment #4 from Aldy Hernandez aldyh at gcc dot gnu.org 2010-12-23 16:19:12 UTC --- Patrick. You will find out that when hacking on GCC, everything is intrusive in non-obvious ways :). What I had in mind was something simple like this, since push_cp_library_fn() only gets called when creating delete/new operators. Index: cp/decl.c === --- cp/decl.c (revision 168123) +++ cp/decl.c (working copy) @@ -3775,6 +3775,8 @@ push_cp_library_fn (enum tree_code opera operator_code, type); pushdecl (fn); + if (flag_tm) +apply_tm_attr (fn, get_identifier (transaction_pure)); return fn; } However, this is exhibiting an unrelated bug with inlining that I am investigating. Thanks for all your bugreports! They've made my life easier.
[Bug tree-optimization/47002] [4.6 Regression] segmentation fault in find_uses_to_rename_use
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47002 --- Comment #5 from Sebastian Pop spop at gcc dot gnu.org 2010-12-23 16:25:59 UTC --- Author: spop Date: Thu Dec 23 16:25:52 2010 New Revision: 168210 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=168210 Log: Fix PR47002: memory leaks. 2010-12-23 Sebastian Pop sebastian@amd.com PR tree-optimization/47002 * tree-data-ref.c (compute_data_dependences_for_loop): Pass in a pointer to the loop_nest. (analyze_all_data_dependences): Initialize and free the loop_nest. (free_dependence_relations): Do not free loop_nest. (build_rdg): Pass in the loop_nest, datarefs, and dependence_relations. (free_rdg): Also free the data on edges. * tree-data-ref.h (build_rdg): Update declaration. (compute_data_dependences_for_loop): Same. * tree-if-conv.c (if_convertible_loop_p_1): Pass in the loop_nest. (if_convertible_loop_p): Allocate and free loop_nest. * tree-loop-distribution.c (rdg_flag_loop_exits): Free conds. (free_rdg_components): VEC_free components. (distribute_loop): Update call to build_rdg. Allocate and free loop_nest, datarefs, and dependence_relations. * tree-loop-linear.c (linear_transform_loops): Allocate and free loop_nest. * tree-parloops.c (loop_parallel_p): Same. * tree-predcom.c (tree_predictive_commoning_loop): Same. * tree-vect-data-refs.c (vect_analyze_data_refs): Pass to compute_data_dependences_for_loop a pointer to LOOP_VINFO_LOOP_NEST. * tree-vect-loop.c (new_loop_vec_info): Initialize LOOP_VINFO_LOOP_NEST. (destroy_loop_vec_info): Free LOOP_VINFO_MAY_ALIAS_DDRS and LOOP_VINFO_LOOP_NEST. * tree-vect-slp.c (destroy_bb_vec_info): Call free_data_refs and free_dependence_relations. * tree-vectorizer.h (struct _loop_vec_info): Add a field loop_nest. (LOOP_VINFO_LOOP_NEST): New. Modified: trunk/gcc/ChangeLog trunk/gcc/tree-data-ref.c trunk/gcc/tree-data-ref.h trunk/gcc/tree-if-conv.c trunk/gcc/tree-loop-distribution.c trunk/gcc/tree-loop-linear.c trunk/gcc/tree-parloops.c trunk/gcc/tree-predcom.c trunk/gcc/tree-vect-data-refs.c trunk/gcc/tree-vect-loop.c trunk/gcc/tree-vect-slp.c trunk/gcc/tree-vectorizer.h
[Bug middle-end/46758] [4.5/4.6 Regression] -fgraphite-identity produces wrong code when using 64bit constants
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46758 --- Comment #7 from Sebastian Pop spop at gcc dot gnu.org 2010-12-23 16:26:17 UTC --- Author: spop Date: Thu Dec 23 16:26:11 2010 New Revision: 168211 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=168211 Log: Fix PR46758: Do not use int_cst_value. 2010-12-23 Sebastian Pop sebastian@amd.com Richard Guenther rguent...@suse.de PR tree-optimization/46758 * graphite-sese-to-poly.c (scan_tree_for_params_right_scev): Use tree_int_to_gmp instead of int_cst_value. (scan_tree_for_params_int): Same. (scan_tree_for_params): Same. (pdr_add_data_dimensions): Use ppl_set_inhomogeneous_tree. * gcc.dg/graphite/run-id-pr46758.c: New. Added: trunk/gcc/testsuite/gcc.dg/graphite/run-id-pr46758.c Modified: trunk/gcc/ChangeLog trunk/gcc/graphite-sese-to-poly.c trunk/gcc/testsuite/ChangeLog
[Bug c++/46941] [trans-mem] new/delete operator are unsafe
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46941 --- Comment #5 from Patrick Marlier patrick.marlier at gmail dot com 2010-12-23 16:27:47 UTC --- Aldy. I think you should declare it 'transaction_safe' and not 'transaction_pure' since symbols in the libitm are binded to safe: _ZGTtnwm; _ZGTtnam; _ZGTtdlPv; _ZGTtdaPv; _ZGTtnwmRKSt9nothrow_t; _ZGTtnamRKSt9nothrow_t; _ZGTtdlPvRKSt9nothrow_t; _ZGTtdaPvRKSt9nothrow_t;
[Bug ada/47017] [4.6 Regression] gnatlib ICE on sparc64-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47017 Eric Botcazou ebotcazou at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2010.12.23 16:29:29 Ever Confirmed|0 |1 --- Comment #2 from Eric Botcazou ebotcazou at gcc dot gnu.org 2010-12-23 16:29:29 UTC --- I built a 32-bit multilib'ed compiler recently on the machine and this worked fine so this looks like a miscompilation of the compiler itself. :-(
[Bug tree-optimization/47001] segmentation fault in vect_mark_slp_stmts
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47001 Ira Rosen irar at il dot ibm.com changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #3 from Ira Rosen irar at il dot ibm.com 2010-12-23 16:31:43 UTC --- Fixed.
[Bug middle-end/46758] [4.5/4.6 Regression] -fgraphite-identity produces wrong code when using 64bit constants
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46758 Sebastian Pop spop at gcc dot gnu.org changed: What|Removed |Added Known to work||4.6.0 Version|4.6.0 |4.5.3 Known to fail|4.6.0 | --- Comment #8 from Sebastian Pop spop at gcc dot gnu.org 2010-12-23 16:35:00 UTC --- Fixed on 4.6, I am backporting this to 4.5.
[Bug tree-optimization/46029] -ftree-loop-if-convert-stores causes FAIL: libstdc++-v3/testsuite/ext/pb_ds/example/tree_intervals.cc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46029 Sebastian Pop spop at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2010.12.23 17:20:47 AssignedTo|unassigned at gcc dot |spop at gcc dot gnu.org |gnu.org | Ever Confirmed|0 |1 --- Comment #3 from Sebastian Pop spop at gcc dot gnu.org 2010-12-23 17:20:47 UTC --- This bug is fixed by the rewrite of the if-convert-stores patch: http://gcc.gnu.org/ml/gcc-patches/2010-11/msg00304.html
[Bug fortran/47051] [4.6 Regression] wrong reallocate
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47051 Paul Thomas pault at gcc dot gnu.org changed: What|Removed |Added CC||pault at gcc dot gnu.org --- Comment #6 from Paul Thomas pault at gcc dot gnu.org 2010-12-23 17:51:00 UTC --- (In reply to comment #4) INTEGER, DIMENSION(:), ALLOCATABLE :: a,b,c,d ALLOCATE(a(-1:1),b(1:3),c(2:3),d(3:6)) b=0 c=0 d=0 a=b write(6,*) LBOUND(a), size(a) a=c write(6,*) LBOUND(a), size(a) a=d write(6,*) LBOUND(a), size(a) END will give -1 3 2 2 3 4 Note that there are two work-around: (1) compile with -fno-realloc-lhs, (2) use a(:). extending this example slightly: INTEGER, DIMENSION(:), ALLOCATABLE :: a,b,c,d ALLOCATE(a(-1:1),b(1:3),c(2:3),d(3:6)) b=0 c=0 d=0 write(6,*) LBOUND(a), size(a), loc(a(lbound(a))) a=b write(6,*) LBOUND(a), size(a), loc(a(lbound(a))) a=c write(6,*) LBOUND(a), size(a), loc(a(lbound(a))) a=d write(6,*) LBOUND(a), size(a), loc(a(lbound(a))) END gives [...@localhost pr47051]# ifort --version ifort (IFORT) 11.1 20090630 Copyright (C) 1985-2009 Intel Corporation. All rights reserved. [...@localhost pr47051]# ifort -assume realloc-lhs pr47051a.f90 [...@localhost pr47051]# ./a.out -1 3 17346660 1 3 17346652 2 2 17346648 3 4 17346644 and for gfortran: -1 3 140736566840176 1 3 140736566840128 2 2 140736566840080 3 4 140736566840032 Thus the bounds are the same and it was this comparison that made me stop where I did. Worryingly, though, the array is being reallocated at each assignment. If you examine the code, the address should be the same for the first two lines, since the array sizes are the same. In summary, the reallocation should NOT occur and the setting of the bounds should be sorted out. Cheers Paul
[Bug fortran/47054] New: Compilation error when cray pointers are declared in both host and internal subroutines
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47054 Summary: Compilation error when cray pointers are declared in both host and internal subroutines Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: deji_ak...@yahoo.ca The following code produces compilation error when compiled with gfortran-4.5.1 (gcc version 4.5.1 20101130 (Red Hat 4.5.1-6) (GCC)). It compiles fine if I remove the 'contains' statement, and replace it with 'end subroutine host_sub'. subroutine host_sub(F_su,F_nk) implicit none integer :: F_nk real,dimension(F_nk) :: F_su integer G_ni, G_nj real*8 G_xg_8, G_yg_8 pointer (paxg_8, G_xg_8(G_ni)) pointer (payg_8, G_yg_8(G_nj)) common / G_p / paxg_8,payg_8 ! common / G / G_ni, G_nj call internal_sub(F_su,F_nk) return contains subroutine internal_sub(F_su,F_nk) implicit none ! integer G_ni, G_nj real*8 G_xg_8, G_yg_8 pointer (paxg_8, G_xg_8(G_ni)) pointer (payg_8, G_yg_8(G_nj)) common / G_p / paxg_8,payg_8 ! common / G / G_ni, G_nj integer :: F_nk real,dimension(F_nk) :: F_su integer k,k2 k2 = 0 do k = 1, F_nk, 2 k2 = k2+1 F_su(k) = F_su(k) + 1.0 enddo return end subroutine internal_sub end subroutine host_sub
[Bug regression/47037] 465.tonto Segmentation Fault in memset with -fcaller-saves (default at -O2 or higher)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47037 Changpeng Fang changpeng.fang at amd dot com changed: What|Removed |Added Summary|465.tonto Segmentation |465.tonto Segmentation |Fault in memset |Fault in memset with ||-fcaller-saves (default at ||-O2 or higher) --- Comment #3 from Changpeng Fang changpeng.fang at amd dot com 2010-12-23 18:05:02 UTC --- .LBB633: .loc 1 967 0 discriminator 2 movq%r13, %rdx movq%rbx, %rsi movq%rsp, %rdi callmemcpy movl$128, %edx leaq(%rsp,%r13), %rdi ## bad address movl$32, %esi subq%r13, %rdx movq%rsp, %r12 callmemset jmp .L707 .LVL646: .p2align 4,,10 .p2align 3 Actually, the segfault is in copying label to symbol at line 967: character(128) :: symbol symbol = label(1:lensym) The memset is to set the remainder of the 128 bytes to ZEROs. The local code seems good to me. It might be that the %rsp is not appropriately set. Anyway, it is not likely to be a fortran bug because it only occurs at -O2 or higher when -fcaller-saves is turned on,
[Bug regression/47037] 465.tonto Segmentation Fault in memset with -fcaller-saves (default at -O2 or higher)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47037 --- Comment #4 from Changpeng Fang changpeng.fang at amd dot com 2010-12-23 18:08:44 UTC --- (In reply to comment #2) Can you supply a simplified test case? The difficulty is that the bug only shows up on a new AMD system (bobcat). The compiled binary on bobcat can run correctly on other systems.
[Bug bootstrap/47055] New: make profiledbootstrap fails on MSYS/mingw-w64
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47055 Summary: make profiledbootstrap fails on MSYS/mingw-w64 Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap AssignedTo: unassig...@gcc.gnu.org ReportedBy: vanboxem.ru...@gmail.com When doing a make profiledbootstrap, there are two things that go wrong: 1. All mkdir commands contain /DriveLetter:\restofpath and fail. Example profiling:/M:\Development\msys\home\Ruben\mingw64\build64\gcc\libiberty/pex-common.gcda:Skip profiling:/M::Cannot create directory 2. Random errors (which are caused by #1?) make the stage profile fail. Doing a normal make (which does the stage 1, 2, and 3 + compare 2=?3) works as expected. MSYS can handle m:/path/to/file and /m/path/to/file and any mix of capitals and non-capitals. It can't however, handle /m:/path/to/file, which is a mix of the two.
[Bug tree-optimization/43023] missing SSA_NAME def for -ftree-loop-distribution in 459.GemsFDTD
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43023 --- Comment #6 from Sebastian Pop spop at gcc dot gnu.org 2010-12-23 18:51:55 UTC --- Author: spop Date: Thu Dec 23 18:51:51 2010 New Revision: 168212 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=168212 Log: Fix PR43023: fuse_partitions_with_similar_memory_accesses. 2010-12-23 Sebastian Pop sebastian@amd.com PR tree-optimization/43023 * tree-data-ref.c (mem_write_stride_of_same_size_as_unit_type_p): Removed. (stores_zero_from_loop): Call stmt_stores_zero. (stmt_with_adjacent_zero_store_dr_p): New. * tree-data-ref.h (stmt_with_adjacent_zero_store_dr_p): Declared. (stride_of_unit_type_p): New. * tree-loop-distribution.c (generate_memset_zero): Do not return a boolean. Call gcc_assert on stride_of_unit_type_p. (generate_builtin): Call stmt_stores_zero. (rdg_flag_all_uses): Removed. (rdg_flag_similar_memory_accesses): Removed. (build_rdg_partition_for_component): Removed parameter other_stores. Removed call to rdg_flag_similar_memory_accesses. (can_generate_builtin): New. (similar_memory_accesses): New. (fuse_partitions_with_similar_memory_accesses): New. (rdg_build_partitions): Call fuse_partitions_with_similar_memory_accesses. * gfortran.dg/ldist-1.f90: Adjust pattern. * gfortran.dg/ldist-pr43023.f90: New. Added: branches/gcc-4_5-branch/gcc/testsuite/gfortran.dg/ldist-pr43023.f90 Modified: branches/gcc-4_5-branch/gcc/ChangeLog branches/gcc-4_5-branch/gcc/testsuite/ChangeLog branches/gcc-4_5-branch/gcc/testsuite/gfortran.dg/ldist-1.f90 branches/gcc-4_5-branch/gcc/tree-data-ref.c branches/gcc-4_5-branch/gcc/tree-data-ref.h branches/gcc-4_5-branch/gcc/tree-loop-distribution.c
[Bug middle-end/46758] [4.5/4.6 Regression] -fgraphite-identity produces wrong code when using 64bit constants
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46758 --- Comment #9 from Sebastian Pop spop at gcc dot gnu.org 2010-12-23 18:52:15 UTC --- Author: spop Date: Thu Dec 23 18:52:12 2010 New Revision: 168214 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=168214 Log: Fix PR46758: Do not use int_cst_value. 2010-12-23 Sebastian Pop sebastian@amd.com Richard Guenther rguent...@suse.de PR tree-optimization/46758 * graphite-sese-to-poly.c (scan_tree_for_params_right_scev): Use tree_int_to_gmp instead of int_cst_value. (scan_tree_for_params_int): Same. (scan_tree_for_params): Same. (pdr_add_data_dimensions): Use ppl_set_inhomogeneous_tree. * gcc.dg/graphite/run-id-pr46758.c: New. Added: branches/gcc-4_5-branch/gcc/testsuite/gcc.dg/graphite/run-id-pr46758.c Modified: branches/gcc-4_5-branch/gcc/ChangeLog branches/gcc-4_5-branch/gcc/graphite-sese-to-poly.c branches/gcc-4_5-branch/gcc/testsuite/ChangeLog
[Bug tree-optimization/45552] [graphite] ICE in sese_loop_depth, at sese.h:172
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45552 --- Comment #6 from Sebastian Pop spop at gcc dot gnu.org 2010-12-23 18:52:08 UTC --- Author: spop Date: Thu Dec 23 18:52:04 2010 New Revision: 168213 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=168213 Log: Fix PR45552: backport fix for PR45758 to 4.5 branch. 2010-12-23 Sebastian Pop sebastian@amd.com Backport from mainline Fix PR45758: reset scevs before Graphite. 2010-09-24 Sebastian Pop sebastian@amd.com PR tree-optimization/45552 * graphite.c (graphite_initialize): Call scev_reset. * gcc.dg/graphite/pr45552.c Added: branches/gcc-4_5-branch/gcc/testsuite/gcc.dg/graphite/pr45552.c Modified: branches/gcc-4_5-branch/gcc/ChangeLog branches/gcc-4_5-branch/gcc/graphite.c branches/gcc-4_5-branch/gcc/testsuite/ChangeLog
[Bug tree-optimization/43023] missing SSA_NAME def for -ftree-loop-distribution in 459.GemsFDTD
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43023 Sebastian Pop spop at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #7 from Sebastian Pop spop at gcc dot gnu.org 2010-12-23 18:53:01 UTC --- Fixed.
[Bug middle-end/46758] [4.5/4.6 Regression] -fgraphite-identity produces wrong code when using 64bit constants
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46758 Sebastian Pop spop at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #10 from Sebastian Pop spop at gcc dot gnu.org 2010-12-23 18:53:48 UTC --- Fixed.
[Bug fortran/47054] Compilation error when cray pointers are declared in both host and internal subroutines
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47054 kargl at gcc dot gnu.org changed: What|Removed |Added CC||kargl at gcc dot gnu.org --- Comment #1 from kargl at gcc dot gnu.org 2010-12-23 19:23:14 UTC --- What compilation error?
[Bug fortran/47054] Compilation error when cray pointers are declared in both host and internal subroutines
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47054 --- Comment #2 from Dominique d'Humieres dominiq at lps dot ens.fr 2010-12-23 19:33:04 UTC --- What compilation error? For me it is [macbook] f90/bug% gfc -fcray-pointer pr47054.f90 pr47054.f90:23.29: pointer (paxg_8, G_xg_8(G_ni)) 1 Error: Symbol 'g_xg_8' at (1) has no IMPLICIT type pr47054.f90:24.29: pointer (payg_8, G_yg_8(G_nj)) 1 Error: Symbol 'g_yg_8' at (1) has no IMPLICIT type
[Bug ada/47056] New: [4.6 Regression] 10 Ada ACATS tests fail to link with undefined reference on ia64-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47056 Summary: [4.6 Regression] 10 Ada ACATS tests fail to link with undefined reference on ia64-linux Product: gcc Version: unknown Status: UNCONFIRMED Keywords: link-failure Severity: normal Priority: P3 Component: ada AssignedTo: unassig...@gcc.gnu.org ReportedBy: laur...@guerby.net Host: ia64-linux Target: ia64-linux Build: ia64-linux From: http://gcc.gnu.org/ml/gcc-testresults/2010-12/msg02106.html The following ACATS FAIL with the same kind of linker error: FAIL:c390002 FAIL:c392002 FAIL:c392003 FAIL:c392013 FAIL:c393008 FAIL:c393009 FAIL:c760013 FAIL:cd72a02 FAIL:cdd2a01 FAIL:cdd2a03 gnatlink c390002.ali -O2 --GCC=/home/guerby/build/gcc/xgcc -B/home/guerby/build/gcc/ ./c390002.o: In function `_ada_c390002': c390002.adb:(.text+0x1070): undefined reference to `c390002__vehicle___alignment.1865' c390002.adb:(.text+0x1071): undefined reference to `c390002__vehicle__objectDF.1869' c390002.adb:(.text+0x1072): undefined reference to `c390002__vehicle__create.1880' c390002.adb:(.text+0x1082): undefined reference to `c390002__vehicle__wheels.1883' c390002.adb:(.text+0x16d0): undefined reference to `c390002__motivators___alignment.2087' c390002.adb:(.text+0x1cc0): undefined reference to `c390002__motivators___alignment__2.2292' c390002.adb:(.text+0x22a0): undefined reference to `c390002__motivators___alignment__3.2497' collect2: ld returned 1 exit status gnatlink: error when calling /home/guerby/build/gcc/xgcc gnatlink: error when calling /home/guerby/build/gcc/xgcc gnatmake: *** link failed. ... gnatlink cdd2a03.ali -O2 --GCC=/home/guerby/build/gcc/xgcc -B/home/guerby/build/gcc/ ./cdd2a03.o: In function `_ada_cdd2a03': cdd2a03.adb:(.text+0x1520): undefined reference to `cdd2a03___alignment.2046' cdd2a03.adb:(.text+0x1600): undefined reference to `cdd2a03__parentDF.2073' cdd2a03.adb:(.text+0x1b92): undefined reference to `cdd2a03___alignment__2.2511' cdd2a03.adb:(.text+0x20b2): undefined reference to `cdd2a03___alignment__3.2709' collect2: ld returned 1 exit status gnatlink: error when calling /home/guerby/build/gcc/xgcc gnatmake: *** link failed. (The other two FAIL are unrelated)
[Bug rtl-optimization/45352] ICE: in reset_sched_cycles_in_current_ebb, at sel-sched.c:7058
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45352 --- Comment #24 from Zdenek Sojka zsojka at seznam dot cz 2010-12-23 20:56:46 UTC --- Created attachment 22848 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=22848 testcase failing in r168214 Thank you for fixing all the problem so far, but there seems to be further problem, this time with array of volatile floats and insane set of flags. I hope to find a more sane testcase... $ gcc -O -fprofile-generate -fgcse -fno-gcse-lm -fgcse-sm -fno-ivopts -fno-tree-loop-im -ftree-pre -funroll-loops -fno-web -fschedule-insns2 -fselective-scheduling2 -fsel-sched-pipelining pr45352_r168214.c pr45352_r168214.c: In function 'foo': pr45352_r168214.c:13:1: internal compiler error: in reset_sched_cycles_in_current_ebb, at sel-sched.c:7105 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions.
[Bug testsuite/47057] New: FAIL/XPASS gcc.dg/vect/costmodel/ppc/costmodel-vect-outer-fir.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47057
Summary: FAIL/XPASS
gcc.dg/vect/costmodel/ppc/costmodel-vect-outer-fir.c
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: testsuite
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: domi...@lps.ens.fr
Target: powerpc*-*-*
The test gcc.dg/vect/costmodel/ppc/costmodel-vect-outer-fir.c gives
XPASS: gcc.dg/vect/costmodel/ppc/costmodel-vect-outer-fir.c
scan-tree-dump-times vect OUTER LOOP VECTORIZED 2
FAIL: gcc.dg/vect/costmodel/ppc/costmodel-vect-outer-fir.c scan-tree-dump-times
vect OUTER LOOP VECTORIZED 1
Obviously if there are two outer loops vectorized, there cannot be only one
vectorized! The following patch fixes the test
---
../_gcc_clean/gcc/testsuite/gcc.dg/vect/costmodel/ppc/costmodel-vect-outer-fir.c
2007-11-21 20:18:34.0 +0100
+++
../gcc-4.6-work/gcc/testsuite/gcc.dg/vect/costmodel/ppc/costmodel-vect-outer-fir.c
2010-12-23 22:02:28.0 +0100
@@ -71,6 +71,6 @@ int main (void)
return 0;
}
-/* { dg-final { scan-tree-dump-times OUTER LOOP VECTORIZED 2 vect { xfail
*-*-* } } } */
-/* { dg-final { scan-tree-dump-times OUTER LOOP VECTORIZED 1 vect { xfail
vect_no_align } } } */
+/* { dg-final { scan-tree-dump-times OUTER LOOP VECTORIZED 2 vect { xfail
vect_no_align } } } */
+/* { dg-final { scan-tree-dump-times OUTER LOOP VECTORIZED 1 vect { xfail
{ ! vect_no_align } } } } */
/* { dg-final { cleanup-tree-dump vect } } */
[Bug bootstrap/47055] make profiledbootstrap fails on MSYS/mingw-w64
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47055 Kai Tietz ktietz at gcc dot gnu.org changed: What|Removed |Added CC||ktietz at gcc dot gnu.org --- Comment #1 from Kai Tietz ktietz at gcc dot gnu.org 2010-12-23 21:36:44 UTC --- Well, this bug seems to happen by the generation of the gcov_list, which seems to have the habit to always prefix full-pathnames by a slash ... Anayway, you can work-a-round this issue by setting environment variable GCOV_PREFIX_STRIP to 1 and setting GCOV_PREFIX to m:/.
[Bug libstdc++/47058] New: --enable-maintainer-mode --disable-werror wrongly upgrades warnings to errors in libstdc++
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47058 Summary: --enable-maintainer-mode --disable-werror wrongly upgrades warnings to errors in libstdc++ Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ AssignedTo: unassig...@gcc.gnu.org ReportedBy: john.tyt...@aaug.net Using gcc 4.6trunk r168215, target arm-unknown-eabi, newlib 1.19.0, binutils 2.21. Configured with: --target=arm-unknown-eabi --prefix=/home/joty/projects/gccsdk/riscos7/cross --with-gmp=/home/joty/projects/gccsdk/gccsdk_svn7/gcc4/builddir/installed-libs-for-cross-gcc --with-mpfr=/home/joty/projects/gccsdk/gccsdk_svn7/gcc4/builddir/installed-libs-for-cross-gcc --with-mpc=/home/joty/projects/gccsdk/gccsdk_svn7/gcc4/builddir/installed-libs-for-cross-gcc --with-ppl=/home/joty/projects/gccsdk/gccsdk_svn7/gcc4/builddir/installed-libs-for-cross-gcc --with-cloog=/home/joty/projects/gccsdk/gccsdk_svn7/gcc4/builddir/installed-libs-for-cross-gcc --disable-threads --disable-multilib --disable-shared --with-newlib --enable-maintainer-mode --disable-werror --enable-interwork --disable-nls --disable-libquadmath --enable-checking=release --enable-languages=c,c++ Mind --enable-maintainer-mode --disable-werror being used. And this still results in a -Werror during libstdc++ building, which results into: --8-- ln -s /home/joty/projects/gccsdk/gccsdk_svn7/gcc4/srcdir/gcc/libstdc++-v3/config/locale/generic/ctype_members.cc . || true /bin/bash ../libtool --tag CXX --mode=compile /home/joty/projects/gccsdk/gccsdk_svn7/gcc4/builddir/cross-gcc/./gcc/xgcc -shared-libgcc -B/home/joty/projects/gccsdk/gccsdk_svn7/gcc4/builddir/cross-gcc/./gcc -nostdinc++ -L/home/joty/projects/gccsdk/gccsdk_svn7/gcc4/builddir/cross-gcc/arm-unknown-eabi/libstdc++-v3/src -L/home/joty/projects/gccsdk/gccsdk_svn7/gcc4/builddir/cross-gcc/arm-unknown-eabi/libstdc++-v3/src/.libs -nostdinc -B/home/joty/projects/gccsdk/gccsdk_svn7/gcc4/builddir/cross-gcc/arm-unknown-eabi/newlib/ -isystem /home/joty/projects/gccsdk/gccsdk_svn7/gcc4/builddir/cross-gcc/arm-unknown-eabi/newlib/targ-include -isystem /home/joty/projects/gccsdk/gccsdk_svn7/gcc4/srcdir/gcc/newlib/libc/include -B/home/joty/projects/gccsdk/gccsdk_svn7/gcc4/builddir/cross-gcc/arm-unknown-eabi/libgloss/arm -L/home/joty/projects/gccsdk/gccsdk_svn7/gcc4/builddir/cross-gcc/arm-unknown-eabi/libgloss/libnosys -L/home/joty/projects/gccsdk/gccsdk_svn7/gcc4/srcdir/gcc/libgloss/arm -B/home/joty/projects/gccsdk/riscos7/cross/arm-unknown-eabi/bin/ -B/home/joty/projects/gccsdk/riscos7/cross/arm-unknown-eabi/lib/ -isystem /home/joty/projects/gccsdk/riscos7/cross/arm-unknown-eabi/include -isystem /home/joty/projects/gccsdk/riscos7/cross/arm-unknown-eabi/sys-include -I/home/joty/projects/gccsdk/gccsdk_svn7/gcc4/builddir/cross-gcc/arm-unknown-eabi/libstdc++-v3/include/arm-unknown-eabi -I/home/joty/projects/gccsdk/gccsdk_svn7/gcc4/builddir/cross-gcc/arm-unknown-eabi/libstdc++-v3/include -I/home/joty/projects/gccsdk/gccsdk_svn7/gcc4/srcdir/gcc/libstdc++-v3/libsupc++ -fno-implicit-templates -Wall -Wextra -Wwrite-strings -Wcast-qual -Werror -fdiagnostics-show-location=once -ffunction-sections -fdata-sections -g -O2 -c -o ctype_members.lo ctype_members.cc libtool: compile: /home/joty/projects/gccsdk/gccsdk_svn7/gcc4/builddir/cross-gcc/./gcc/xgcc -shared-libgcc -B/home/joty/projects/gccsdk/gccsdk_svn7/gcc4/builddir/cross-gcc/./gcc -nostdinc++ -L/home/joty/projects/gccsdk/gccsdk_svn7/gcc4/builddir/cross-gcc/arm-unknown-eabi/libstdc++-v3/src -L/home/joty/projects/gccsdk/gccsdk_svn7/gcc4/builddir/cross-gcc/arm-unknown-eabi/libstdc++-v3/src/.libs -nostdinc -B/home/joty/projects/gccsdk/gccsdk_svn7/gcc4/builddir/cross-gcc/arm-unknown-eabi/newlib/ -isystem /home/joty/projects/gccsdk/gccsdk_svn7/gcc4/builddir/cross-gcc/arm-unknown-eabi/newlib/targ-include -isystem /home/joty/projects/gccsdk/gccsdk_svn7/gcc4/srcdir/gcc/newlib/libc/include -B/home/joty/projects/gccsdk/gccsdk_svn7/gcc4/builddir/cross-gcc/arm-unknown-eabi/libgloss/arm -L/home/joty/projects/gccsdk/gccsdk_svn7/gcc4/builddir/cross-gcc/arm-unknown-eabi/libgloss/libnosys -L/home/joty/projects/gccsdk/gccsdk_svn7/gcc4/srcdir/gcc/libgloss/arm -B/home/joty/projects/gccsdk/riscos7/cross/arm-unknown-eabi/bin/ -B/home/joty/projects/gccsdk/riscos7/cross/arm-unknown-eabi/lib/ -isystem /home/joty/projects/gccsdk/riscos7/cross/arm-unknown-eabi/include -isystem /home/joty/projects/gccsdk/riscos7/cross/arm-unknown-eabi/sys-include -I/home/joty/projects/gccsdk/gccsdk_svn7/gcc4/builddir/cross-gcc/arm-unknown-eabi/libstdc++-v3/include/arm-unknown-eabi -I/home/joty/projects/gccsdk/gccsdk_svn7/gcc4/builddir/cross-gcc/arm-unknown-eabi/libstdc++-v3/include -I/home/joty/projects/gccsdk/gccsdk_svn7/gcc4/srcdir/gcc/libstdc++-v3/libsupc++ -fno-implicit-templates -Wall -Wextra -Wwrite-strings -Wcast-qual -Werror -fdiagnostics-show-location=once -ffunction-sections
[Bug libstdc++/47045] NetBSD: define changes in ctype.h
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47045 --- Comment #4 from Jonathan Wakely redi at gcc dot gnu.org 2010-12-24 01:32:19 UTC --- Building GCC snapshots made easy: http://advogato.org/person/redi/diary/229.html
