[Bug bootstrap/44107] New: libstdc++ (dylib) is built with an erroneous dependency towards /usr/lib
The symptoms are that for some inputs, my C++ program gets stuck after a `throw' and before the corresponding `catch', with CPU running. With an appropriate DYLD_LIBRARY_PATH, the problem disappears. The problem comes IMHO from libgcc/config/t-slibgcc-darwin (lines 29-35) where libgcc_s.10.5.dylib is _not_ built. Therefore it remains absent from $(objdir)/gcc. However, in the `specs' located in this directory, it is referenced from within the `*libgcc:' target (see also lines 400 and 405 of gcc/config/darwin.h). Consequently, libstdc++.6.dylib contains a dependency towards /usr/lib/libgcc_s.10.5.dylib (see line 577 of libstdc++-v3/src/Makefile.in, /usr/lib is a default directory), and this dependency remains in my C++ executable (dynamically linked). The symptoms follow (see explanations under the description of the option `-shared-libgcc' of GCC). I modified libgcc/config/t-slibgcc-darwin in order to build libgcc_s.10.5.dylib in all cases and everything is now perfect. Perhaps a better solution would be to remove the -lgcc_s.10.5 from the build of libstdc++.6.dylib. Hope this helps. I grabbed the 4.5-20100506 snapshot and found no change in this area. All the above lines and files are from the 4.5.0 distribution. -- Summary: libstdc++ (dylib) is built with an erroneous dependency towards /usr/lib Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: Denis dot Excoffier at airbus dot com GCC build triplet: powerpc-apple-darwin9.8.0 GCC host triplet: powerpc-apple-darwin9.8.0 GCC target triplet: powerpc-apple-darwin9.8.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44107
[Bug target/44074] Solaris 2.9 x86 Sun assembler doesn't like rep/lock prefixes on same line
--- Comment #6 from jay dot krell at cornell dot edu 2010-05-13 07:56 --- Another I didn't understand from the other mail thread: why not always output ;? In particular, the warning that would be disabled -- that is for hand written assembly only, right? Is it disable for the entire file? So it would affect hand written intermixed with compiler generated? Or only those particular lines? If it just the lines, then there's nothing wrong there -- gcc outputs them correctly, doesn't need gas checking it. If it disables it for the entire file, that I understand. For now I just changed mine to always output ;, for all platforms, if syntax==att. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44074
[Bug bootstrap/44107] libstdc++ (dylib) is built with an erroneous dependency towards /usr/lib
--- Comment #1 from paolo dot carlini at oracle dot com 2010-05-13 08:41 --- Mike, can you have a look? -- paolo dot carlini at oracle dot com changed: What|Removed |Added CC||mikestump at comcast dot net http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44107
[Bug other/39979] [4.4/4.5/4.6 Regression] libsupc++(eh_globals.cc)/stlport TLS incompatibility.
--- Comment #18 from pluto at agmk dot net 2010-05-13 09:13 --- (In reply to comment #17) Not a bug, you need to configure libstdc++ and stlport the same if you want them to work together. __thread/pthread in eh_globals.cc is an implemetation detail. how this could conflicts with pthread-based stlport? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39979
[Bug c/44091] [ARM/Thumb] Invalid stack frame usage at -Os
--- Comment #10 from sebastian dot huber at embedded-brains dot de 2010-05-13 09:42 --- Binary search through trunk revisions yield: r159321 BROKEN r15 BROKEN r14 BROKEN r135000 BROKEN r132500 BROKEN r131024 BROKEN r130512 BROKEN r130256 BROKEN r130128 BROKEN r130064 BROKEN r130056 BROKEN r130052 BROKEN r130051 OK r130050 OK r130048 OK r130032 OK r13 OK -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44091
[Bug c/44091] [ARM/Thumb] Invalid stack frame usage at -Os
--- Comment #11 from sebastian dot huber at embedded-brains dot de 2010-05-13 09:50 --- Created an attachment (id=20654) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20654action=view) Difference between bdbuf.s in revsions 130051 and 130052 This clearly shows how the frame usage sequence changed. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44091
[Bug ada/43885] [4.6 Regression] build failure using self
--- Comment #4 from tkoenig at gcc dot gnu dot org 2010-05-13 09:58 --- This works now. Closing. -- tkoenig at gcc dot gnu dot org changed: What|Removed |Added Status|WAITING |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43885
[Bug target/43988] unnecessary memory store
--- Comment #1 from ramana at gcc dot gnu dot org 2010-05-13 10:08 --- Confirmed . I think this is a result of DSE not being able to remove this because the prologue rtx pattern doesn't show the writes of the actual registers. Ramana -- ramana at gcc dot gnu dot org changed: What|Removed |Added Severity|normal |enhancement Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2010-05-13 10:08:00 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43988
[Bug other/39979] [4.4/4.5/4.6 Regression] libsupc++(eh_globals.cc)/stlport TLS incompatibility.
--- Comment #19 from redi at gcc dot gnu dot org 2010-05-13 10:24 --- (In reply to comment #15) the problematic is eh_globals.o which was merged into libstlport.a. If stlport imports files which are implementation details, then it depends on those implementation details. isn't that obvious? If that's by design, then as Andrew said you need to reconfigure stlport. If it's not by design, it's an stlport bug. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39979
[Bug c/44091] [ARM/Thumb] Invalid stack frame usage at -Os
--- Comment #12 from mikpe at it dot uu dot se 2010-05-13 10:28 --- r130052 is a generic scheduling tweak originally described here: http://gcc.gnu.org/ml/gcc-patches/2007-10/msg01814.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44091
[Bug fortran/43665] Optimization of libgfortran calls: function annotations for noclobber/noescape arguments
--- Comment #3 from dfranke at gcc dot gnu dot org 2010-05-13 10:31 --- Initial patch (trans-decl.c, trans.io.c) here: http://gcc.gnu.org/ml/fortran/2010-05/msg00124.html Mapping formal arguments to fnspec should be doable, but I'm experienced enough in tree-things to continue. -- dfranke at gcc dot gnu dot org changed: What|Removed |Added CC||dfranke at gcc dot gnu dot ||org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2010-05-13 10:31:22 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43665
[Bug debug/43983] var-tracking needlessly throws away location info for SRAed vars
--- Comment #6 from jakub at gcc dot gnu dot org 2010-05-13 10:41 --- Subject: Bug 43983 Author: jakub Date: Thu May 13 10:40:51 2010 New Revision: 159357 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=159357 Log: PR debug/43983 * var-tracking.c (track_expr_p): Allow tracking of variables optimized by SRA. * Makefile.in (dwarf2out.o): Depend on $(TREE_FLOW_H). * tree-sra.c (create_access_replacement): Call unshare_expr before passing expr to SET_DECL_DEBUG_EXPR, and remove any SSA_NAMEs from it. * dwarf2out.c: Include tree-flow.h. (struct var_loc_node): Rename var_loc_note field to loc, add comment. (size_of_loc_descr, output_loc_operands, output_loc_operands_raw): Handle DW_OP_bit_piece. (decl_piece_bitsize, decl_piece_varloc_ptr, decl_piece_node, construct_piece_list, adjust_piece_list): New functions. (add_var_loc_to_decl): Handle SRA optimized variables. Adjust for var_loc_note to loc field renaming. (dw_loc_list_1): For WANT_ADDRESS == 2 prefer DECL_MODE of decl in VAR_LOCATION note. (new_loc_descr_op_bit_piece): New function. (dw_sra_loc_expr): New function. (dw_loc_list): Use it. Don't handle the last range after the loop, handle it inside of the loop. Adjust for var_loc_note to loc field renaming. (add_location_or_const_value_attribute): Only special case single entry loc lists if loc is NOTE_P. Adjust for var_loc_note to loc field renaming. (dwarf2out_var_location): Don't set newloc-var_loc_note and newloc-next here. * gcc.dg/guality/sra-1.c: New test. Added: trunk/gcc/testsuite/gcc.dg/guality/sra-1.c Modified: trunk/gcc/ChangeLog trunk/gcc/Makefile.in trunk/gcc/dwarf2out.c trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-sra.c trunk/gcc/var-tracking.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43983
[Bug other/39979] [4.4/4.5/4.6 Regression] libsupc++(eh_globals.cc)/stlport TLS incompatibility.
--- Comment #20 from pluto at agmk dot net 2010-05-13 10:46 --- (In reply to comment #19) (In reply to comment #15) the problematic is eh_globals.o which was merged into libstlport.a. If stlport imports files which are implementation details, then it depends on those implementation details. isn't that obvious? If that's by design, then as Andrew said you need to reconfigure stlport. If it's not by design, it's an stlport bug. stlport includes some gcc archives in libstlport.a for simplier linking of stlport-based applications. users just type '-lstlport' and all is linked :) i see only references to __cxa_finalize in stlport code but this doesn't touch eh_globals.cc. i'll check this deeply... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39979
[Bug debug/43983] var-tracking needlessly throws away location info for SRAed vars
--- Comment #7 from jakub at gcc dot gnu dot org 2010-05-13 10:53 --- Fixed. -- jakub at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.6.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43983
[Bug middle-end/44104] [4.6 Regression] New test failures
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.6.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44104
[Bug c++/44108] New: [4.6 Regression] -Wunused-but-set-variable does not consider array sizing use of a const variable
Like PR c/43981, but still happening with 4.6.0 20100513 (Last Changed Rev: 159356 ), which is why I copied and editted the title. In case a const variable is used for array sizing it is not considered to be read whereas a non-const variable would be considered to be read. It does NOT happen when using gcc on a .c file, but it happens when using g++ on a .cpp file, as such component c++. See the attached test case which shows that only the const variables are affected by this. -- Summary: [4.6 Regression] -Wunused-but-set-variable does not consider array sizing use of a const variable Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: rubidium at openttd dot org GCC build triplet: x86_64-unknown-linux-gnu GCC host triplet: x86_64-unknown-linux-gnu GCC target triplet: x86_64-unknown-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44108
[Bug c++/44108] [4.6 Regression] -Wunused-but-set-variable does not consider array sizing use of a const variable
--- Comment #1 from rubidium at openttd dot org 2010-05-13 11:04 --- Created an attachment (id=20655) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20655action=view) Simple testcase Compile with g++ -Wunused-but-set-variable testcase.cpp -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44108
[Bug java/44109] New: gcj handling of assertions is in conflict with documentation
Built/installed gcc under openSUSE 11.1 with:
../configure --prefix=$pre --enable-languages=c,java
Test program AssertionTest.java:
class AssertionTest {
static public void main( String args[] ) {
assert false: test assertion;
System.out.println(Hello World!);
}
}
Compile/link as follows:
$pre/bin/gcj -v -save-temps --disable-assertions -Wl,-rpath,$pre/lib64
--main=AssertionTest AssertionTest.java
Output in AssertionTest.out. Note in particular the line:
cc1: warning: command line option -fdisable-assertions is valid for Java but
not for C
which is also output when not using the -v option.
According to the documentation from 'man -M $pre/share/man gcj', the
--disable-assertions option should exclude assertion checks from the
compiled code, but this does not appear to happen. Running the binary
as:
./a.out; echo $?
gives:
Exception in thread main java.lang.AssertionError: test assertion
at AssertionTest.main(a.out)
1
Expected:
Hello World!
0
Also, from man -M $pre/share/man gcj
By default, assertions are enabled when generating class files or when not
optimizing, and disabled when generating optimized binaries.
However, generating an optimized binary as follows:
$pre/bin/gcj -O -Wl,-rpath,$pre/lib64 --main=AssertionTest AssertionTest.java
succeeds without errors or warnings, but assertions are not
disabled. ./a.out; echo $? gives the same result as above.
From a cursory look at some older versions of gcc, it appears that
this is long-standing behaviour. If it is intentional, maybe this is
merely a documentation bug?
--
Summary: gcj handling of assertions is in conflict with
documentation
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: java
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: pkeller at globalphasing dot com
GCC build triplet: x86_64-unknown-linux-gnu
GCC host triplet: x86_64-unknown-linux-gnu
GCC target triplet: x86_64-unknown-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44109
[Bug fortran/44110] New: [4.6 Regression] FAIL: gfortran.dg/proc_ptr_23.f90 -O3 -g (test for excess errors) etc
At r159354 I see the following new failures in the testsuite: FAIL: gfortran.dg/proc_ptr_23.f90 -O3 -g (test for excess errors) FAIL: gfortran.dg/proc_ptr_25.f90 -O3 -g (test for excess errors) FAIL: gfortran.dg/proc_ptr_comp_9.f90 -O3 -g (test for excess errors) They give errors like /tmp/ccJ47x9g.o:(.debug_info+0x81): undefined reference to `abc.1535' /tmp/ccW6t4P4.o:(.debug_loc+0x12f): undefined reference to `add.1539' /tmp/cckErzEU.o:(.debug_info+0x21e): undefined reference to `triple.1552' (only with -O3 -g). I think these failures have not been there at r159303. -- Summary: [4.6 Regression] FAIL: gfortran.dg/proc_ptr_23.f90 -O3 -g (test for excess errors) etc Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: janus at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44110
[Bug java/44109] gcj handling of assertions is in conflict with documentation
--- Comment #1 from pkeller at globalphasing dot com 2010-05-13 11:14 --- Created an attachment (id=20656) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20656action=view) Output from compile/link step of test program -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44109
[Bug java/44109] gcj handling of assertions is in conflict with documentation
--- Comment #2 from pkeller at globalphasing dot com 2010-05-13 11:15 --- Created an attachment (id=20657) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20657action=view) Preprocessor output from compiling test program -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44109
[Bug other/39979] [4.4/4.5/4.6 Regression] libsupc++(eh_globals.cc)/stlport TLS incompatibility.
--- Comment #21 from redi at gcc dot gnu dot org 2010-05-13 11:29 --- (In reply to comment #20) stlport includes some gcc archives in libstlport.a for simplier linking for some definition of simpler :) Either don't use static linking or rebuild libstlport.a with the gcc version you plan to use. This isn't a gcc bug though. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39979
[Bug bootstrap/44111] New: [4.6 Regression] Bootstrap failure for powerpc-apple-darwin9 from revision 159339
Bootstrap failure for powerpc-apple-darwin9 from revision 159339: ... /opt/gcc/darwin_buildw/./prev-gcc/xgcc -B/opt/gcc/darwin_buildw/./prev-gcc/ -B/opt/gcc/gcc4.6w/powerpc-apple-darwin9/bin/ -B/opt/gcc/gcc4.6w/powerpc-apple-darwin9/bin/ -B/opt/gcc/gcc4.6w/powerpc-apple-darwin9/lib/ -isystem /opt/gcc/gcc4.6w/powerpc-apple-darwin9/include -isystem /opt/gcc/gcc4.6w/powerpc-apple-darwin9/sys-include-c -g -O2 -mdynamic-no-pic -gtoggle -DIN_GCC -W -Wall -Wwrite-strings -Wcast-qual -Wstrict-prototypes -Wmissing-prototypes -Wmissing-format-attribute -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -Werror -Wold-style-definition -Wc++-compat -fno-common -DHAVE_CONFIG_H -I. -I. -I../../gcc-4.6-work/gcc -I../../gcc-4.6-work/gcc/. -I../../gcc-4.6-work/gcc/../include -I../../gcc-4.6-work/gcc/../libcpp/include -I/sw/include -I/sw/include -I../../gcc-4.6-work/gcc/../libdecnumber -I../../gcc-4.6-work/gcc/../libdecnumber/dpd -I../libdecnumber -I/sw/include -I/sw/include -DCLOOG_PPL_BACKEND../../gcc-4.6-work/gcc/targhooks.c -o targhooks.o ../../gcc-4.6-work/gcc/targhooks.c: In function 'default_mode_dependent_address_p': ../../gcc-4.6-work/gcc/targhooks.c:968:3: error: passing argument 1 of 'rs6000_mode_dependent_address_ptr' discards qualifiers from pointer target type [-Werror] ../../gcc-4.6-work/gcc/targhooks.c:968:3: note: expected 'rtx' but argument is of type 'const_rtx' cc1: all warnings being treated as errors make[3]: *** [targhooks.o] Error 1 make[2]: *** [all-stage2-gcc] Error 2 make[1]: *** [stage2-bubble] Error 2 make: *** [all] Error 2 See also http://gcc.gnu.org/ml/gcc-patches/2010-05/msg00915.html . Replacing const_rtx with rtx in gcc/targhooks.* allows bootstrap to proceed. -- Summary: [4.6 Regression] Bootstrap failure for powerpc-apple- darwin9 from revision 159339 Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: dominiq at lps dot ens dot fr GCC build triplet: powerpc-apple-darwin9 GCC host triplet: powerpc-apple-darwin9 GCC target triplet: powerpc-apple-darwin9 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44111
[Bug bootstrap/44111] [4.6 Regression] Bootstrap failure for powerpc-apple-darwin9 from revision 159339
--- Comment #1 from dominiq at lps dot ens dot fr 2010-05-13 11:54 --- Fixed by revision 159359, see http://gcc.gnu.org/ml/gcc-patches/2010-05/msg00932.html . -- dominiq at lps dot ens dot fr changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44111
[Bug fortran/44036] I can't declare an external function in an OMP shared statement.
--- Comment #11 from jakub at gcc dot gnu dot org 2010-05-13 12:03 --- Subject: Bug 44036 Author: jakub Date: Thu May 13 12:02:50 2010 New Revision: 159361 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=159361 Log: PR fortran/44036 * openmp.c (resolve_omp_clauses): Allow procedure pointers in clause variable lists. * trans-openmp.c (gfc_omp_privatize_by_reference): Don't privatize by reference dummy procedures or non-dummy procedure pointers. (gfc_omp_predetermined_sharing): Return OMP_CLAUSE_DEFAULT_FIRSTPRIVATE for dummy procedures. * gfortran.dg/gomp/pr44036-1.f90: New test. * gfortran.dg/gomp/pr44036-2.f90: New test. * gfortran.dg/gomp/pr44036-3.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/gomp/pr44036-1.f90 trunk/gcc/testsuite/gfortran.dg/gomp/pr44036-2.f90 trunk/gcc/testsuite/gfortran.dg/gomp/pr44036-3.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/openmp.c trunk/gcc/fortran/trans-openmp.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44036
[Bug c++/44108] [4.6 Regression] -Wunused-but-set-variable does not consider array sizing use of a const variable
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.6.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44108
[Bug middle-end/44103] [4.6 Regression] New Java test failures
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.6.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44103
[Bug fortran/35779] error pointer wrong in PARAMETER
--- Comment #6 from dfranke at gcc dot gnu dot org 2010-05-13 12:30 --- Patch: http://gcc.gnu.org/ml/fortran/2010-05/msg00130.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35779
[Bug fortran/38404] Warning message identifies incorrect line
--- Comment #1 from dfranke at gcc dot gnu dot org 2010-05-13 12:30 --- Suggested patch: http://gcc.gnu.org/ml/fortran/2010-05/msg00116.html -- dfranke at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |dfranke at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2009-03-28 12:20:08 |2010-05-13 12:30:31 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38404
[Bug fortran/44055] Warn (-Wconversion*) when converting single to double precision
--- Comment #3 from dfranke at gcc dot gnu dot org 2010-05-13 12:31 --- Suggested patch: http://gcc.gnu.org/ml/fortran/2010-05/msg00109.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44055
[Bug fortran/44036] I can't declare an external function in an OMP shared statement.
--- Comment #12 from jakub at gcc dot gnu dot org 2010-05-13 12:36 --- Subject: Bug 44036 Author: jakub Date: Thu May 13 12:35:52 2010 New Revision: 159363 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=159363 Log: PR fortran/44036 * openmp.c (resolve_omp_clauses): Allow procedure pointers in clause variable lists. * trans-openmp.c (gfc_omp_privatize_by_reference): Don't privatize by reference dummy procedures or non-dummy procedure pointers. (gfc_omp_predetermined_sharing): Return OMP_CLAUSE_DEFAULT_FIRSTPRIVATE for dummy procedures. * gfortran.dg/gomp/pr44036-1.f90: New test. * gfortran.dg/gomp/pr44036-2.f90: New test. * gfortran.dg/gomp/pr44036-3.f90: New test. Added: branches/gcc-4_5-branch/gcc/testsuite/gfortran.dg/gomp/pr44036-1.f90 branches/gcc-4_5-branch/gcc/testsuite/gfortran.dg/gomp/pr44036-2.f90 branches/gcc-4_5-branch/gcc/testsuite/gfortran.dg/gomp/pr44036-3.f90 Modified: branches/gcc-4_5-branch/gcc/fortran/ChangeLog branches/gcc-4_5-branch/gcc/fortran/openmp.c branches/gcc-4_5-branch/gcc/fortran/trans-openmp.c branches/gcc-4_5-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44036
[Bug fortran/44036] I can't declare an external function in an OMP shared statement.
--- Comment #13 from jakub at gcc dot gnu dot org 2010-05-13 12:39 --- Subject: Bug 44036 Author: jakub Date: Thu May 13 12:39:17 2010 New Revision: 159365 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=159365 Log: PR fortran/44036 * openmp.c (resolve_omp_clauses): Allow procedure pointers in clause variable lists. * trans-openmp.c (gfc_omp_privatize_by_reference): Don't privatize by reference dummy procedures or non-dummy procedure pointers. (gfc_omp_predetermined_sharing): Return OMP_CLAUSE_DEFAULT_FIRSTPRIVATE for dummy procedures. * gfortran.dg/gomp/pr44036-1.f90: New test. * gfortran.dg/gomp/pr44036-2.f90: New test. * gfortran.dg/gomp/pr44036-3.f90: New test. Added: branches/gcc-4_4-branch/gcc/testsuite/gfortran.dg/gomp/pr44036-1.f90 branches/gcc-4_4-branch/gcc/testsuite/gfortran.dg/gomp/pr44036-2.f90 branches/gcc-4_4-branch/gcc/testsuite/gfortran.dg/gomp/pr44036-3.f90 Modified: branches/gcc-4_4-branch/gcc/fortran/ChangeLog branches/gcc-4_4-branch/gcc/fortran/openmp.c branches/gcc-4_4-branch/gcc/fortran/trans-openmp.c branches/gcc-4_4-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44036
[Bug middle-end/44103] [4.6 Regression] New Java test failures
--- Comment #1 from howarth at nitro dot med dot uc dot edu 2010-05-13 13:02 --- Also seen on powerpc-apple-darwin9. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44103
[Bug middle-end/44112] New: [4.6 regression] Revision 159354 causes Fortran test failures
Revision 159354: http://gcc.gnu.org/ml/gcc-cvs/2010-05/msg00406.html caused: FAIL: gfortran.dg/proc_ptr_23.f90 -O3 -g (test for excess errors) FAIL: gfortran.dg/proc_ptr_25.f90 -O3 -g (test for excess errors) FAIL: gfortran.dg/proc_ptr_comp_9.f90 -O3 -g (test for excess errors) -- Summary: [4.6 regression] Revision 159354 causes Fortran test failures Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: hjl dot tools at gmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44112
[Bug fortran/38404] Warning message identifies incorrect line
--- Comment #2 from steve dot chapel at a2pg dot com 2010-05-13 13:15 --- Excellent! The new warning is far more understandable than the old. X'R IN CALL RANDOM MAY NOT BE USED OUTSIDE THE BLOCK CONTAINING T 1 Warning: Initialization string starting at (1) was truncated after 72 characters to match the variable If it's difficult to place the error marker at the location the string was truncated, would it be easy to list the number of characters in the initialization string, so that one would not have to count characters to determine how many characters need to be removed, or how much larger to make the variable? Example: X'R IN CALL RANDOM MAY NOT BE USED OUTSIDE THE BLOCK CONTAINING T 1 Warning: Initialization string of 73 characters starting at (1) was truncated after 72 characters to match the variable -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38404
[Bug fortran/44036] I can't declare an external function in an OMP shared statement.
--- Comment #14 from jakub at gcc dot gnu dot org 2010-05-13 13:22 --- Fixed. -- jakub at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44036
[Bug fortran/38404] Warning message identifies incorrect line
--- Comment #3 from dfranke at gcc dot gnu dot org 2010-05-13 13:26 ---
That's easily doable. Alternative patch for data.c below gives:
$ gfortran-svn pr38404.f
pr38404.f:5.7:
X'R IN CALL RANDOM MAY NOT BE USED OUTSIDE THE BLOCK CONTAINING T
1
Warning: Initialization string starting at (1) was truncated to fit the
variable (73/72)
(Modified the message to be similar to many other actual-size/expected-size
outputs)
Index: data.c
===
--- data.c (revision 159348)
+++ data.c (working copy)
@@ -154,9 +154,10 @@ create_character_intializer (gfc_expr *i
if (len end - start)
{
+ gfc_warning_now (Initialization string starting at %L was
+ truncated to fit the variable (%d/%d),
+ rvalue-where, len, end - start);
len = end - start;
- gfc_warning_now (initialization string truncated to match variable
- at %L, rvalue-where);
}
if (rvalue-ts.type == BT_HOLLERITH)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38404
[Bug fortran/44110] [4.6 Regression] FAIL: gfortran.dg/proc_ptr_23.f90 -O3 -g (test for excess errors) etc
--- Comment #1 from hjl dot tools at gmail dot com 2010-05-13 13:39 --- *** This bug has been marked as a duplicate of 44112 *** -- hjl dot tools at gmail dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44110
[Bug middle-end/44112] [4.6 regression] Revision 159354 causes Fortran test failures
--- Comment #1 from hjl dot tools at gmail dot com 2010-05-13 13:39 --- *** Bug 44110 has been marked as a duplicate of this bug. *** -- hjl dot tools at gmail dot com changed: What|Removed |Added CC||janus at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44112
[Bug debug/44113] New: bad
With gdb 7.1 / gcc 4.5.0 I noticed that unrolled loops have very poor
debugging information. The body cannot be single stepped, but a next
in gdb jumps over the whole iteration space.
For example:
main()
{
int i;
for (i = 0; i 10; i++)
printf(%d\n,i );
}
compiled with -O3 -g (which results in auto unrolling) gives:
(gdb) b main
Breakpoint 1 at 0x400520: file tloop2.c, line 2.
(gdb) r
Starting program: /home2/andi/tsrc/tloop2
Breakpoint 1, main () at tloop2.c:2
2 {
(gdb) n
5 printf(%d\n,i );
(gdb) n
0
1
2
3
4
5
6
7
8
6 }
(gdb)
Note the single next stepped over the complete loop execution.
I would have expected next to only execute one iteration.
Is this a problem of the loop unroller not describing the unrolled
loop to the debugger?
--
Summary: bad
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: debug
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: andi-gcc at firstfloor dot org
GCC host triplet: x86_64-linux
GCC target triplet: x86_64-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44113
[Bug debug/44113] bad
--- Comment #1 from andi-gcc at firstfloor dot org 2010-05-13 13:44 --- Hmm sorry actually it stepped over everything except the last iteration. Still unexpected -- andi-gcc at firstfloor dot org changed: What|Removed |Added Summary|bad |bad http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44113
[Bug fortran/30941] intrinsic: FLUSH
--- Comment #4 from dfranke at gcc dot gnu dot org 2010-05-13 13:50 --- This (a) didn't turn out as much of an issue and (b) the general problem is known. Closing this specific incarnation as WONTFIX. -- dfranke at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||WONTFIX http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30941
[Bug fortran/30955] intrinsic: FGET
--- Comment #3 from dfranke at gcc dot gnu dot org 2010-05-13 13:50 --- This (a) didn't turn out as much of an issue and (b) the general problem is known. Closing this specific incarnation as WONTFIX. -- dfranke at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||WONTFIX http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30955
[Bug middle-end/44104] [4.6 Regression] New test failures
--- Comment #2 from hjl dot tools at gmail dot com 2010-05-13 13:51 --- It is caused by revision 159315: http://gcc.gnu.org/ml/gcc-cvs/2010-05/msg00367.html -- hjl dot tools at gmail dot com changed: What|Removed |Added CC|hubicka at gcc dot gnu dot |jakub at redhat dot com |org | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44104
[Bug fortran/35779] error pointer wrong in PARAMETER
--- Comment #7 from dfranke at gcc dot gnu dot org 2010-05-13 14:08 --- Subject: Bug 35779 Author: dfranke Date: Thu May 13 14:08:05 2010 New Revision: 159366 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=159366 Log: gcc/fortran/: 2010-05-13 Daniel Franke franke.dan...@gmail.com PR fortran/35779 * intrinsic.c (gfc_init_expr): Renamed to gfc_init_expr_flag. Updated all usages. * expr.c (init_flag): Removed; use gfc_init_expr_flag everywhere. * array.c (match_array_list): Pass on gfc_init_expr_flag when matching iterators. gcc/testsuite/: 2010-05-13 Daniel Franke franke.dan...@gmail.com PR fortran/35779 * gfortran.dg/initialization_25.f90: New. Added: trunk/gcc/testsuite/gfortran.dg/initialization_25.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/arith.c trunk/gcc/fortran/array.c trunk/gcc/fortran/expr.c trunk/gcc/fortran/gfortran.h trunk/gcc/fortran/intrinsic.c trunk/gcc/fortran/simplify.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35779
[Bug fortran/35779] error pointer wrong in PARAMETER
--- Comment #8 from dfranke at gcc dot gnu dot org 2010-05-13 14:09 --- Fixed in trunk. Closing. -- dfranke at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.6.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35779
[Bug debug/44114] New: [4.6 Regression] ICE in output_die with array_constructor_11.f90
This is with rev. 159354 and showed up as a testsuite
failure.
i...@linux-fd1f:/tmp gfortran -O3 -g array_constructor_11.f90
array_constructor_11.f90:13.41:
call test (4, 0, 11, (/ (i, i = 4, 0, 11) /)) ! { dg-warning will be execu
1
Warning: DO loop at (1) will be executed zero times
array_constructor_11.f90:17.47:
call test (29, 30, -6, (/ (i, i = 29, 30, -6) /)) ! { dg-warning will be
1
Warning: DO loop at (1) will be executed zero times
array_constructor_11.f90:24.45:
call test (1, 0, 3, (/ (i, i = 1, 0, 3), (i, i = order, 0, 1) /))
1
Warning: DO loop at (1) will be executed zero times
array_constructor_11.f90:25.48:
call test (1, 2000, -5, (/ (i, i = 1, 2000, -5), (i, i = order, 0, 1) /))
1
Warning: DO loop at (1) will be executed zero times
array_constructor_11.f90:26.49:
call test (3000, 99, 4, (/ (i, i = 3000, 99, 4), (i, i = order, 0, 1) /))
1
Warning: DO loop at (1) will be executed zero times
array_constructor_11.f90:6:0: internal compiler error: in output_die, at
dwarf2out.c:10649
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html for instructions.
g...@linux-fd1f:/tmp gfortran -v
Using built-in specs.
COLLECT_GCC=gfortran
COLLECT_LTO_WRAPPER=/home/ig25/libexec/gcc/x86_64-unknown-linux-gnu/4.6.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: ../trunk/configure --prefix=/home/ig25
--enable-languages=all,ada --with-mpc=/usr/local/
Thread model: posix
gcc version 4.6.0 20100513 (experimental) (GCC)
--
Summary: [4.6 Regression] ICE in output_die with
array_constructor_11.f90
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code
Severity: normal
Priority: P3
Component: debug
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: tkoenig at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44114
[Bug debug/44114] [4.6 Regression] ICE in output_die with array_constructor_11.f90
-- tkoenig at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.6.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44114
[Bug debug/44104] [4.6 Regression] New test failures
--- Comment #3 from jakub at gcc dot gnu dot org 2010-05-13 14:18 --- I'm fairly sure I have regtested the patch with lto and these failures didn't appear, so I guess only some concurrent lto/cgraph changes yesterday made this trigger. The fix is to add mod_type_die check, will commit momentarily. -- jakub at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |jakub at gcc dot gnu dot org |dot org | Status|UNCONFIRMED |ASSIGNED Component|middle-end |debug Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2010-05-13 14:18:02 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44104
[Bug debug/44115] New: gcc.dg/guality/sra-1.c failure
On Linux/x86-64, revision 159357 gave FAIL: gcc.dg/guality/sra-1.c -O1 line 20 a.j == 14 FAIL: gcc.dg/guality/sra-1.c -O1 line 20 a.j == 14 FAIL: gcc.dg/guality/sra-1.c -O2 line 20 a.j == 14 FAIL: gcc.dg/guality/sra-1.c -O2 line 20 a.j == 14 FAIL: gcc.dg/guality/sra-1.c -O2 -flto line 20 a.i == 4 FAIL: gcc.dg/guality/sra-1.c -O2 -flto line 20 a.i == 4 FAIL: gcc.dg/guality/sra-1.c -O2 -flto line 20 a.j == 14 FAIL: gcc.dg/guality/sra-1.c -O2 -flto line 20 a.j == 14 FAIL: gcc.dg/guality/sra-1.c -O2 -flto line 42 a.i == 4 FAIL: gcc.dg/guality/sra-1.c -O2 -flto line 42 a.i == 4 FAIL: gcc.dg/guality/sra-1.c -O2 -flto line 42 a.j == 14 FAIL: gcc.dg/guality/sra-1.c -O2 -flto line 42 a.j == 14 FAIL: gcc.dg/guality/sra-1.c -O2 -fwhopr line 20 a.i == 4 FAIL: gcc.dg/guality/sra-1.c -O2 -fwhopr line 20 a.i == 4 FAIL: gcc.dg/guality/sra-1.c -O2 -fwhopr line 20 a.j == 14 FAIL: gcc.dg/guality/sra-1.c -O2 -fwhopr line 20 a.j == 14 FAIL: gcc.dg/guality/sra-1.c -O2 -fwhopr line 42 a.i == 4 FAIL: gcc.dg/guality/sra-1.c -O2 -fwhopr line 42 a.i == 4 FAIL: gcc.dg/guality/sra-1.c -O2 -fwhopr line 42 a.j == 14 FAIL: gcc.dg/guality/sra-1.c -O2 -fwhopr line 42 a.j == 14 FAIL: gcc.dg/guality/sra-1.c -O3 -fomit-frame-pointer line 20 a.j == 14 FAIL: gcc.dg/guality/sra-1.c -O3 -fomit-frame-pointer line 20 a.j == 14 FAIL: gcc.dg/guality/sra-1.c -O3 -g line 20 a.j == 14 FAIL: gcc.dg/guality/sra-1.c -O3 -g line 20 a.j == 14 FAIL: gcc.dg/guality/sra-1.c -Os line 20 a.j == 14 FAIL: gcc.dg/guality/sra-1.c -Os line 20 a.j == 14 -- Summary: gcc.dg/guality/sra-1.c failure Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: debug AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: hjl dot tools at gmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44115
[Bug c/44091] [ARM/Thumb] Invalid stack frame usage at -Os
--- Comment #13 from pinskia at gcc dot gnu dot org 2010-05-13 14:22 --- *** This bug has been marked as a duplicate of 38644 *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44091
[Bug rtl-optimization/38644] Optimization flag -O1 -fschedule-insns2 causes wrong code
--- Comment #13 from pinskia at gcc dot gnu dot org 2010-05-13 14:22 --- *** Bug 44091 has been marked as a duplicate of this bug. *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||sebastian dot huber at ||embedded-brains dot de http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38644
[Bug debug/44104] [4.6 Regression] New test failures
--- Comment #4 from jakub at gcc dot gnu dot org 2010-05-13 14:24 --- Subject: Bug 44104 Author: jakub Date: Thu May 13 14:24:36 2010 New Revision: 159367 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=159367 Log: PR debug/44104 * dwarf2out.c (modified_type_die): Don't dereference mod_type_die if it is NULL. Modified: trunk/gcc/ChangeLog trunk/gcc/dwarf2out.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44104
[Bug tree-optimization/43924] [4.6 Regression] FAIL: gfortran.dg/array_constructor_11.f90 -O3 -g (internal compiler error)
--- Comment #8 from dominiq at lps dot ens dot fr 2010-05-13 14:25 --- *** This bug has been marked as a duplicate of 44114 *** -- dominiq at lps dot ens dot fr changed: What|Removed |Added Status|NEW |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43924
[Bug debug/44114] [4.6 Regression] ICE in output_die with array_constructor_11.f90
--- Comment #1 from dominiq at lps dot ens dot fr 2010-05-13 14:25 --- *** Bug 43924 has been marked as a duplicate of this bug. *** -- dominiq at lps dot ens dot fr changed: What|Removed |Added CC||dominiq at lps dot ens dot ||fr http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44114
[Bug c++/42325] ICE in instantiate_decl (with checking enabled)
--- Comment #4 from paolo dot carlini at oracle dot com 2010-05-13 14:28 --- Indeed, fixed for 4.6.0 by the patch which fixed PR34491. -- paolo dot carlini at oracle dot com changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED Target Milestone|--- |4.6.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42325
[Bug tree-optimization/43924] [4.6 Regression] FAIL: gfortran.dg/array_constructor_11.f90 -O3 -g (internal compiler error)
--- Comment #9 from hjl dot tools at gmail dot com 2010-05-13 14:31 --- Reopen. This bug report has more info than PR 44114. -- hjl dot tools at gmail dot com changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|DUPLICATE | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43924
[Bug debug/44114] [4.6 Regression] ICE in output_die with array_constructor_11.f90
--- Comment #2 from hjl dot tools at gmail dot com 2010-05-13 14:31 --- *** This bug has been marked as a duplicate of 43924 *** -- hjl dot tools at gmail dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44114
[Bug tree-optimization/43924] [4.6 Regression] FAIL: gfortran.dg/array_constructor_11.f90 -O3 -g (internal compiler error)
--- Comment #10 from hjl dot tools at gmail dot com 2010-05-13 14:31 --- *** Bug 44114 has been marked as a duplicate of this bug. *** -- hjl dot tools at gmail dot com changed: What|Removed |Added CC||tkoenig at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43924
[Bug debug/44115] gcc.dg/guality/sra-1.c failure
--- Comment #1 from jakub at gcc dot gnu dot org 2010-05-13 14:34 --- Buggy gdb, see http://bugzilla.redhat.com/589467 The lto/whopr issues are LTO bugs. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44115
[Bug fortran/44117] New: [4.6 Regression] testsuite failures with proc_ptr_23.f90 and proc_ptr_comp_9.f90
FAIL: gfortran.dg/proc_ptr_23.f90 -O3 -g (test for excess errors) WARNING: gfortran.dg/proc_ptr_23.f90 -O3 -g compilation failed to produce executable FAIL: gfortran.dg/proc_ptr_25.f90 -O3 -g (test for excess errors) WARNING: gfortran.dg/proc_ptr_25.f90 -O3 -g compilation failed to produce executable FAIL: gfortran.dg/proc_ptr_comp_9.f90 -O3 -g (test for excess errors) WARNING: gfortran.dg/proc_ptr_comp_9.f90 -O3 -g compilation failed to produce executable -- Summary: [4.6 Regression] testsuite failures with proc_ptr_23.f90 and proc_ptr_comp_9.f90 Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: tkoenig at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44117
[Bug c/44116] New: 64bit inodes for source code causes Value too large for defined data type (XFS,inode64)
On multi-TB storage array with XFS filesystem I have to enable 64bit inodes
recently (inode64 mount option). Having test.c with:
int main(void){
return 0;
}
compiles fine for one file, but if i copy it to another one (several times till
it got the right inode number) it produces:
r...@matylda1: /mnt/data/kasparek# LC_ALL=C gcc -o test.o test-10356.c
cc1: error: test-10356.c: Value too large for defined data type
The only difference I believe is inode number, definitely not the content of
the file:
r...@matylda1: /mnt/data/kasparek# stat test.c
File: `test.c'
Size: 30 Blocks: 8 IO Block: 4096 regular file
Device: 810h/2064d Inode: 10853690Links: 1
r...@matylda1: /mnt/data/kasparek# stat test-10356.c
File: `test-10356.c'
Size: 30 Blocks: 8 IO Block: 4096 regular file
Device: 810h/2064d Inode: 15447948189 Links: 1
from strace I found that cc1 is doing fstat64 call on the source code file and
then finishes with this message. The first this I need to help with is how to
check if the code that causes this (expect somewhere is used 32bit variable to
store the inode) is from gcc itself or it is some third-party library. I
checked latest version of 4.0, 4.1, 4.2, 4.3, 4.4, 4.5 branches and all behave
the same. The system is x86_64 2.6.32.12 kernel on CentOS 5.4. All GCCs are
32bit binaries (with cross compiler for x86_64, mips, arm and alpha having the
same behavior).
Thanks in advance.
--
Summary: 64bit inodes for source code causes Value too large for
defined data type (XFS,inode64)
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: major
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: kasparek at fit dot vutbr dot cz
GCC build triplet: x86_64-pc-linux-gnu
GCC host triplet: x86_64-pc-linux-gnu
GCC target triplet: i686-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44116
[Bug fortran/44117] [4.6 Regression] testsuite failures with proc_ptr_23.f90 and proc_ptr_comp_9.f90
--- Comment #1 from tkoenig at gcc dot gnu dot org 2010-05-13 14:37 --- Depends on both -O3 and -g: i...@linux-fd1f:/tmp gfortran proc_ptr_23.f90 i...@linux-fd1f:/tmp gfortran -O3 proc_ptr_23.f90 i...@linux-fd1f:/tmp gfortran -O3 -g proc_ptr_23.f90 /tmp/ccALU2k0.o:(.debug_info+0x81): undefined reference to `abc.1535' collect2: ld gab 1 als Ende-Status zurück i...@linux-fd1f:/tmp gfortran proc_ptr_comp_9.f90 i...@linux-fd1f:/tmp gfortran -O3 proc_ptr_comp_9.f90 i...@linux-fd1f:/tmp gfortran -O3 -g proc_ptr_comp_9.f90 /tmp/ccueBcKg.o:(.debug_info+0x21e): undefined reference to `triple.1552' collect2: ld gab 1 als Ende-Status zurück -- tkoenig at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.6.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44117
[Bug fortran/44117] [4.6 Regression] testsuite failures with proc_ptr_23.f90 and proc_ptr_comp_9.f90
--- Comment #2 from jakub at gcc dot gnu dot org 2010-05-13 14:44 --- *** This bug has been marked as a duplicate of 44110 *** -- jakub at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44117
[Bug fortran/44110] [4.6 Regression] FAIL: gfortran.dg/proc_ptr_23.f90 -O3 -g (test for excess errors) etc
--- Comment #2 from jakub at gcc dot gnu dot org 2010-05-13 14:44 --- *** Bug 44117 has been marked as a duplicate of this bug. *** -- jakub at gcc dot gnu dot org changed: What|Removed |Added CC||tkoenig at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44110
[Bug c/44116] 64bit inodes for source code causes Value too large for defined data type (XFS,inode64)
--- Comment #1 from amonakov at gcc dot gnu dot org 2010-05-13 14:46 --- r...@matylda1: /mnt/data/kasparek# LC_ALL=C gcc -o test.o test-10356.c cc1: error: test-10356.c: Value too large for defined data type The first this I need to help with is how to check if the code that causes this (expect somewhere is used 32bit variable to store the inode) is from gcc itself or it is some third-party library. I Execute gcc -o test.o test-10356.c -### 21 | grep cc1 to get the cc1 command line. Then use gdb --args cc1 cmdline to debug the compiler. Getting a backtrace before the abort would be nice. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44116
[Bug fortran/43207] [OOP] ICE for class pointer = null() initialization
--- Comment #3 from janus at gcc dot gnu dot org 2010-05-13 14:47 --- (In reply to comment #0) fff.f90:26:0: internal compiler error: in gfc_conv_structure, at fortran/trans-expr.c:4390 It turns out this ICE is actually due to the NULL() initialization of the class pointer and has nothing to do with the invalid pointer assignment. Here is a simpler test case: implicit none type :: parent end type class(parent) ,pointer :: this = null() call foo(this) contains subroutine foo(this) class(parent) :: this end subroutine end -- janus at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Keywords|ice-on-invalid-code |ice-on-valid-code Last reconfirmed|-00-00 00:00:00 |2010-05-13 14:47:03 date|| Summary|[OOP] ICE for invalid |[OOP] ICE for class pointer |pointer assignment = |= null() initialization |type%parent | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43207
[Bug debug/44112] [4.6 regression] Revision 159354 causes Fortran test failures
--- Comment #2 from jakub at gcc dot gnu dot org 2010-05-13 14:49 --- Fix posted: http://gcc.gnu.org/ml/gcc-patches/2010-05/msg00960.html -- jakub at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |jakub at gcc dot gnu dot org |dot org | Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2010-05-13 14:49:26 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44112
[Bug fortran/43207] [OOP] ICE for class pointer = null() initialization
--- Comment #4 from janus at gcc dot gnu dot org 2010-05-13 14:55 ---
When removing the NULL initialization in comment #3, the dump shows:
static struct .class.parent.p this = {.$data=0B};
Zeroing the $data pointer is probably not needed without NULL initialization.
With NULL initialization, both the $data and the $vptr components should be
zeroed.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43207
[Bug c++/44118] New: ICE: in instantiate_decl, at cp/pt.c:16657
Tested revisions: r159305 - crash (after pr34491 fix) 4.5 r158978 - crash 4.4 r158133 - crash Compiler output: $ /mnt/svn/gcc-trunk/binary-159305-lto-fortran/bin/g++ testcase.C testcase.C:2:30: error: template parameters not used in partial specialization: testcase.C:2:30: error: 'template-parameter-1-1' testcase.C: In function 'void f()': testcase.C:11:16: recursively instantiated from 'void Sint::f()' testcase.C:11:16: instantiated from here testcase.C:11:16: internal compiler error: in instantiate_decl, at cp/pt.c:16657 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. -- Summary: ICE: in instantiate_decl, at cp/pt.c:16657 Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: minor Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: zsojka at seznam dot cz http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44118
[Bug c++/44118] ICE: in instantiate_decl, at cp/pt.c:16657
--- Comment #1 from zsojka at seznam dot cz 2010-05-13 15:11 --- Created an attachment (id=20658) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20658action=view) reduced testcase $ g++ pr44118.C -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44118
[Bug c/44119] New: error: SSA name in freelist but still referenced
[reg...@gamow tmp413]$ current-gcc -v
Using built-in specs.
COLLECT_GCC=current-gcc
COLLECT_LTO_WRAPPER=/uusoc/exports/scratch/regehr/z/compiler-install/gcc-r159348-install/bin/../libexec/gcc/x86_64-unknown-linux-gnu/4.6.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: ../configure --with-libelf=/usr/local --enable-lto
--prefix=/home/regehr/z/compiler-install/gcc-r159348-install
--program-prefix=r159348- --enable-languages=c,c++
Thread model: posix
gcc version 4.6.0 20100513 (experimental) (GCC)
[reg...@gamow tmp413]$ current-gcc -O2 -c small.c
small.c: In function 'func_96':
small.c:32:7: warning: overflow in implicit constant conversion [-Woverflow]
small.c:22:1: error: SSA name in freelist but still referenced
pretmp.15_47
small.c:38:13: note: in statement
# .MEM_24 = VDEF .MEM_21(D)
*pretmp.8_41 = pretmp.15_47;
small.c:22:1: internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html for instructions.
[reg...@gamow tmp413]$ cat small.c
typedef signed char int8_t;
typedef short int int16_t;
typedef int int32_t;
typedef unsigned int uint32_t;
static int8_t
safe_mul_func_int16_t_s_s (int16_t si1, int8_t si2)
{
return si1 si2 si1 +si2 || si1 si2 si2 +si1 || si1 si2
si1 +si2 || si1 si2 si1 si2 +si1 ? : si1 * si2;
}
struct S0
{
};
int32_t g_72[7][4][1];
int32_t *g_184 = g_72[1][2][0];
int32_t **g_224 = g_184;
struct S0 g_244 = {
};
int8_t *
func_96 (int8_t p_97, uint32_t p_98, uint32_t p_99)
{
struct S0 *l_243 = g_244;
int i;
for (i = 0; i 1; p_98 = 1)
{
int32_t *l_202[3];
int i;
for (i = 0; i 1; i++)
l_202[i] = g_72[2][2][0];
if (safe_mul_func_int16_t_s_s (0xC4CAF0, **g_224))
{
if (p_98 l_243)
{
}
else
*g_224 = l_202[0];
for (0;; 1)
{
}
}
}
return 0;
}
--
Summary: error: SSA name in freelist but still referenced
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: regehr at cs dot utah dot edu
GCC build triplet: x86_64-unknown-linux-gnu
GCC host triplet: x86_64-unknown-linux-gnu
GCC target triplet: x86_64-unknown-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44119
[Bug c/44119] [4.6 Regressionerror: SSA name in freelist but still referenced
--- Comment #1 from rguenth at gcc dot gnu dot org 2010-05-13 15:27 --- Confirmed. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2010-05-13 15:27:39 date|| Summary|error: SSA name in freelist |[4.6 Regressionerror: SSA |but still referenced|name in freelist but still ||referenced http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44119
[Bug tree-optimization/44119] [4.6 Regression] error: SSA name in freelist but still referenced
--- Comment #2 from rguenth at gcc dot gnu dot org 2010-05-13 15:27 --- The PRE change again. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |rguenth at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Component|c |tree-optimization Last reconfirmed|2010-05-13 15:27:39 |2010-05-13 15:27:59 date|| Summary|[4.6 Regressionerror: SSA |[4.6 Regression] error: SSA |name in freelist but still |name in freelist but still |referenced |referenced Target Milestone|--- |4.6.0 Version|unknown |4.6.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44119
[Bug debug/44112] [4.6 regression] Revision 159354 causes Fortran test failures
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.6.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44112
[Bug c/44116] 64bit inodes for source code causes Value too large for defined data type (XFS,inode64)
--- Comment #2 from rguenth at gcc dot gnu dot org 2010-05-13 15:31 --- This is know. GCC does not use LFS and thus fails. A patch to fix that was once applied but broke AIX and thus was reverted. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC||rguenth at gcc dot gnu dot ||org URL||http://gcc.gnu.org/ml/gcc- ||patches/2009- ||02/msg00592.html http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44116
[Bug debug/44115] gcc.dg/guality/sra-1.c failure
--- Comment #2 from rguenth at gcc dot gnu dot org 2010-05-13 15:33 --- We throw away DECL_DEBUG_EXPR in free-lang-data (and do not try to stream it). -- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC||rguenth at gcc dot gnu dot ||org Keywords||lto http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44115
[Bug debug/44113] bad debugging information for unrolled loops
--- Comment #2 from rguenth at gcc dot gnu dot org 2010-05-13 15:36 --- Well, you step to the next line-number and only lines #5 are remaining, so I think you just get what you asked for. I don't know if we could (or should) signal to gdb that there are multiple lines #5 now. Jakub? -- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC||jakub at gcc dot gnu dot ||org, rguenth at gcc dot gnu ||dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44113
[Bug bootstrap/44120] New: ObjC++ build fails after change to build_array_ref (prob r159351)
I imagine this will affect all targets. dpd -I../libdecnumber/GCC/gcc-live-trunk/gcc/objc/objc-act.c \ -o objcp/objcp-act.o /GCC/gcc-live-trunk/gcc/objc/objc-act.c: In function build_typed_selector_reference: /GCC/gcc-live-trunk/gcc/objc/objc-act.c:2709:8: error: too few arguments to function build_array_ref /GCC/gcc-live-trunk/gcc/cp/cp-tree.h:5368:13: note: declared here /GCC/gcc-live-trunk/gcc/objc/objc-act.c: In function build_selector_reference: /GCC/gcc-live-trunk/gcc/objc/objc-act.c:2727:8: error: too few arguments to function build_array_ref /GCC/gcc-live-trunk/gcc/cp/cp-tree.h:5368:13: note: declared here /GCC/gcc-live-trunk/gcc/objc/objc-act.c:2740:9: error: too few arguments to function build_array_ref /GCC/gcc-live-trunk/gcc/cp/cp-tree.h:5368:13: note: declared here /GCC/gcc-live-trunk/gcc/objc/objc-act.c: In function objc_substitute_decl: /GCC/gcc-live-trunk/gcc/objc/objc-act.c:3130:10: error: too few arguments to function build_array_ref /GCC/gcc-live-trunk/gcc/cp/cp-tree.h:5368:13: note: declared here /GCC/gcc-live-trunk/gcc/objc/objc-act.c: In function build_selector_reference: /GCC/gcc-live-trunk/gcc/objc/objc-act.c:2741:1: error: control reaches end of non-void function [-Werror=return-type] cc1: all warnings being treated as errors make[3]: *** [objcp/objcp-act.o] Error 1 make[2]: *** [all-stage2-gcc] Error 2 make[1]: *** [stage2-bubble] Error 2 make: *** [bootstrap] Error 2 -- Summary: ObjC++ build fails after change to build_array_ref (prob r159351) Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: blocker Priority: P3 Component: bootstrap AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: iains at gcc dot gnu dot org GCC target triplet: i686-apple-darwin http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44120
[Bug debug/44113] bad debugging information for unrolled loops
--- Comment #3 from andi-gcc at firstfloor dot org 2010-05-13 16:16 --- I think it should describe multiple lines. next is expected to iterate through loops, not skip them. If I wanted to skip I would use until -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44113
[Bug c++/30298] [4.3/4.4/4.5/4.6 regression] ICE with duplicate broken inheritance
--- Comment #8 from paolo dot carlini at oracle dot com 2010-05-13 16:21 --- On it. -- paolo dot carlini at oracle dot com changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |paolo dot carlini at oracle |dot org |dot com Status|NEW |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30298
[Bug fortran/38404] Warning message identifies incorrect line
--- Comment #4 from steve dot chapel at a2pg dot com 2010-05-13 16:28 --- :) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38404
[Bug fortran/34505] FLOAT/SNGL: Not accepted as actual argument; diagnostics problems
--- Comment #2 from dfranke at gcc dot gnu dot org 2010-05-13 16:45 --- Patch: http://gcc.gnu.org/ml/fortran/2010-05/msg00135.html -- dfranke at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |dfranke at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2009-03-29 08:18:53 |2010-05-13 16:45:46 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34505
[Bug bootstrap/44120] ObjC++ build fails after change to build_array_ref (prob r159351)
--- Comment #1 from iains at gcc dot gnu dot org 2010-05-13 16:48 --- Created an attachment (id=20659) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20659action=view) fix PR44120 this is a quick-fix, FWIW we seem to be getting an ever-increasing number of #ifdef OBJCPLUS - I wonder if there's some partitioning that would help maintainability. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44120
[Bug fortran/43851] Add _gfortran_error_stop_numeric
--- Comment #3 from jvdelisle at gcc dot gnu dot org 2010-05-13 16:58 --- I have a revised patch that handles default integer and negative error codes. It is testing and I will submit when I get an opportunity. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43851
[Bug c++/44118] ICE: in instantiate_decl, at cp/pt.c:16657
--- Comment #2 from pinskia at gcc dot gnu dot org 2010-05-13 17:02 --- Related to PR 43630. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Known to fail|4.4.5 4.5.1 4.6.0 |4.4.5 4.5.1 4.6.0 4.1.3 ||4.2.4 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44118
[Bug c++/44106] False warning: 'control reaches end of non-void function' when comparing to undefined var
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Severity|normal |minor Keywords||diagnostic http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44106
[Bug fortran/44105] gfortran fails to work during build
--- Comment #2 from johnkhord at gmail dot com 2010-05-13 17:12 --- I re-compiled both GMP and MPFR (using the --with-gmp directive) and am now getting a new nastygram when make-ing gcc : Assembler messages: :5148: Error: symbol `fstatat64' is already defined :5185: Error: symbol `fstat64' is already defined :5218: Error: symbol `lstat64' is already defined :5251: Error: symbol `stat64' is already defined make[3]: *** [unix.lo] Error 1 make[3]: Leaving directory `/root/gcc-4.4.4/i686-pc-linux-gnu/libgfortran' make[2]: *** [all] Error 2 make[2]: Leaving directory `/root/gcc-4.4.4/i686-pc-linux-gnu/libgfortran' make[1]: *** [all-target-libgfortran] Error 2 make[1]: Leaving directory `/root/gcc-4.4.4' make: *** [all] Error 2 do I need to go and manually delete the OS-installed gmp/mpfr stuff under /usr/lib and /usr/include? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44105
[Bug debug/44113] bad debugging information for unrolled loops
--- Comment #4 from pinskia at gcc dot gnu dot org 2010-05-13 17:13 --- Confirmed. Though with the 4.5.0 and above we do have a debug_stmt with the correct line info at the tree level ... -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Keywords||wrong-debug Known to fail||4.1.3 4.2.4 4.6.0 4.3.2 Last reconfirmed|-00-00 00:00:00 |2010-05-13 17:13:45 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44113
[Bug fortran/44105] gfortran fails to work during build
--- Comment #3 from pinskia at gcc dot gnu dot org 2010-05-13 17:14 --- (In reply to comment #2) I re-compiled both GMP and MPFR (using the --with-gmp directive) and am now getting a new nastygram when make-ing gcc No but building in the source directory is not recommended. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44105
[Bug fortran/44105] gfortran fails to work during build
--- Comment #4 from johnkhord at gmail dot com 2010-05-13 17:15 --- Never mind -- according to other bug entries, apparently gcc-4.4.3 (and presumeably 4.4.4) requires glibc 2.6 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44105
[Bug fortran/44105] gfortran fails to work during build
--- Comment #5 from johnkhord at gmail dot com 2010-05-13 17:17 --- (In reply to comment #3) (In reply to comment #2) I re-compiled both GMP and MPFR (using the --with-gmp directive) and am now getting a new nastygram when make-ing gcc No but building in the source directory is not recommended. interesting -- why would that be? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44105
[Bug c++/44092] Undefined Symbol: std::basic_string
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Severity|blocker |normal http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44092
[Bug c++/30298] [4.3/4.4/4.5/4.6 regression] ICE with duplicate broken inheritance
--- Comment #9 from paolo dot carlini at oracle dot com 2010-05-13 17:28 --- Nope. -- paolo dot carlini at oracle dot com changed: What|Removed |Added AssignedTo|paolo dot carlini at oracle |unassigned at gcc dot gnu |dot com |dot org Status|ASSIGNED|NEW http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30298
[Bug fortran/44105] gfortran fails to work during build
--- Comment #6 from kargl at gcc dot gnu dot org 2010-05-13 17:49 --- (In reply to comment #4) Never mind -- according to other bug entries, apparently gcc-4.4.3 (and presumeably 4.4.4) requires glibc 2.6 glibc 2.6 is not required for gcc-4.4.3 or gcc-4.4.4. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44105
[Bug c++/34756] [4.3/4.4/4.5 regression] ICE with broken specialization of variadic template
--- Comment #7 from paolo dot carlini at oracle dot com 2010-05-13 17:54 --- Fixed for 4.6.0 by the patch which fixed PR34491. -- paolo dot carlini at oracle dot com changed: What|Removed |Added Summary|[4.3/4.4/4.5/4.6 regression]|[4.3/4.4/4.5 regression] ICE |ICE with broken |with broken specialization |specialization of variadic |of variadic template |template| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34756
[Bug middle-end/41082] [4.5/4.6 Regression] FAIL: gfortran.fortran-torture/execute/where_2.f90 execution, -O3 -g with -m64
--- Comment #48 from tkoenig at gcc dot gnu dot org 2010-05-13 18:04 --- Any news on this? -- tkoenig at gcc dot gnu dot org changed: What|Removed |Added CC||tkoenig at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41082
[Bug tree-optimization/42720] Problematic condition simplification logic at unswitch-loops pass
--- Comment #15 from jingyu at google dot com 2010-05-13 18:09 --- Patch was committed to trunk (4.6) r158138. Resolved. -- jingyu at google dot com changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42720
[Bug libstdc++/44121] New: [4.6 Regression] multiple char-related fails.
m32 and m64: FAIL: 27_io/basic_stringbuf/in_avail/char/1.cc (test for excess errors) WARNING: 27_io/basic_stringbuf/in_avail/char/1.cc compilation failed to produce executable FAIL: 27_io/basic_stringbuf/in_avail/wchar_t/1.cc (test for excess errors) WARNING: 27_io/basic_stringbuf/in_avail/wchar_t/1.cc compilation failed to produce executable FAIL: 27_io/basic_stringbuf/sbumpc/char/1.cc (test for excess errors) WARNING: 27_io/basic_stringbuf/sbumpc/char/1.cc compilation failed to produce executable FAIL: 27_io/basic_stringbuf/sbumpc/wchar_t/1.cc (test for excess errors) WARNING: 27_io/basic_stringbuf/sbumpc/wchar_t/1.cc compilation failed to produce executable FAIL: 27_io/basic_stringbuf/sgetc/char/1.cc (test for excess errors) WARNING: 27_io/basic_stringbuf/sgetc/char/1.cc compilation failed to produce executable FAIL: 27_io/basic_stringbuf/sgetc/wchar_t/1.cc (test for excess errors) WARNING: 27_io/basic_stringbuf/sgetc/wchar_t/1.cc compilation failed to produce executable FAIL: 27_io/basic_stringbuf/sgetn/char/1.cc (test for excess errors) WARNING: 27_io/basic_stringbuf/sgetn/char/1.cc compilation failed to produce executable FAIL: 27_io/basic_stringbuf/sgetn/wchar_t/1.cc (test for excess errors) WARNING: 27_io/basic_stringbuf/sgetn/wchar_t/1.cc compilation failed to produce executable FAIL: 27_io/basic_stringbuf/snextc/char/1.cc (test for excess errors) WARNING: 27_io/basic_stringbuf/snextc/char/1.cc compilation failed to produce executable FAIL: 27_io/basic_stringbuf/snextc/wchar_t/1.cc (test for excess errors) WARNING: 27_io/basic_stringbuf/snextc/wchar_t/1.cc compilation failed to produce executable FAIL: ext/mt_allocator/deallocate_global_thread-1.cc execution test FAIL: ext/mt_allocator/deallocate_global_thread-3.cc execution test FAIL: ext/stdio_sync_filebuf/char/1.cc (test for excess errors) WARNING: ext/stdio_sync_filebuf/char/1.cc compilation failed to produce executable FAIL: ext/stdio_sync_filebuf/char/12048-3.cc (test for excess errors) WARNING: ext/stdio_sync_filebuf/char/12048-3.cc compilation failed to produce executable FAIL: ext/stdio_sync_filebuf/char/12048-4.cc (test for excess errors) WARNING: ext/stdio_sync_filebuf/char/12048-4.cc compilation failed to produce executable FAIL: ext/stdio_sync_filebuf/wchar_t/1.cc (test for excess errors) WARNING: ext/stdio_sync_filebuf/wchar_t/1.cc compilation failed to produce executable FAIL: ext/stdio_sync_filebuf/wchar_t/12948-3.cc (test for excess errors) WARNING: ext/stdio_sync_filebuf/wchar_t/12948-3.cc compilation failed to produce executable FAIL: ext/stdio_sync_filebuf/wchar_t/12948-4.cc (test for excess errors) WARNING: ext/stdio_sync_filebuf/wchar_t/12948-4.cc compilation failed to produce executable collect2: ld returned 1 exit status compiler exited with status 1 output is: Undefined symbols: __gnu_cxx::stdio_sync_filebufchar, std::char_traitschar ::xsgetn(char*, int), referenced from: test05()in ccRAtAkX.o ld: symbol(s) not found collect2: ld returned 1 exit status FAIL: ext/stdio_sync_filebuf/char/12048-4.cc (test for excess errors) -- Summary: [4.6 Regression] multiple char-related fails. Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: iains at gcc dot gnu dot org GCC target triplet: i686-apple-darwin9 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44121
[Bug libstdc++/44121] [4.6 Regression] multiple char-related fails.
--- Comment #1 from iains at gcc dot gnu dot org 2010-05-13 18:47 --- also: FAIL: 27_io/basic_stringbuf/in_avail/wchar_t/1.cc (test for excess errors) Excess errors: /GCC/gcc-live-trunk/libstdc++-v3/testsuite/27_io/basic_stringbuf/in_avail/wchar_t/1.cc:53:1: error: Inline clone with address taken std::basic_string_CharT, _Traits, _Alloc::~basic_string() [with _CharT = wchar_t, _Traits = std::char_traitswchar_t, _Alloc = std::allocator wchar_t]/817(-1) @0x416fd774 (asm: _ZNSbIwSt11char_traitsIwESaIwEED1Ev) (inline copy in virtual std::basic_stringbufwchar_t::~basic_stringbu f()/842) availability:local analyzed 14 time, 12 benefit (6 after inlining) 5 size, 3 benefit (14 after inlining) 1 bytes stack usage address_ta ken body local finalized inlinable called by: virtual std::basic_stringbufwchar_t::~basic_stringbuf()/842 (1.00 per call) (inlined) calls: void std::basic_string_CharT, _Traits, _Alloc::_Rep::_M_dispose(const _Alloc) [with _CharT = wchar_t, _Traits = std::char_traitswch ar_t, _Alloc = std::allocatorwchar_t]/786 (inlined) (1.00 per call) References: Refering this function: fn:void _Z41__static_initialization_and_destruction_0ii.clone.0()/854 (addr) fn:void _Z41__static_initialization_and_ destruction_0ii.clone.0()/854 (addr) fn:void _Z41__static_initialization_and_destruction_0ii.clone.0()/854 (addr) /GCC/gcc-live-trunk/libstdc++-v3/testsuite/27_io/basic_stringbuf/in_avail/wchar_t/1.cc:53:1: internal compiler error: verify_cgraph_node failed Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. WARNING: 27_io/basic_stringbuf/in_avail/wchar_t/1.cc compilation failed to produce executable -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44121
