[Bug c/30769] compile error / segmentation fault / 64bit compiler
--- Comment #3 from armin at xos dot net 2007-02-12 08:06 --- Subject: Re: compile error / segmentation fault / 64bit compiler sorry it's early in the morning ... sun studio 11: cc: sun C 5.8 2005/10/13 do you need further information? i compiled mysql/apache/perl/... so far everything works. (with the resulting gcc) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30769
[Bug c/30769] compile error / segmentation fault / 64bit compiler
--- Comment #4 from ebotcazou at gcc dot gnu dot org 2007-02-12 08:21 --- do you need further information? Yes, see http://gcc.gnu.org/bugs.html for instructions. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30769
[Bug c++/30771] New: ice for legal code with -O2 -ftree-vectorize
I just tried to compile Suse Linux package ladspa-1.12.code10-56 with the GNU C++ compiler version 4.3 snapshot 20070209. The compiler said Descriptor.h: In static member function 'static void* DescriptorT::_instantiate(const _LADSPA_Descriptor*, ulong) [with T = CabinetII]': Descriptor.h:117: internal compiler error: in vectorizable_type_promotion, at tree-vect-transform.c:2601 Please submit a full bug report, with preprocessed source if appropriate. See URL:http://gcc.gnu.org/bugs.html for instructions. Preprocessed source code attached. Flags -ftree-vectorize -O2 required. -- Summary: ice for legal code with -O2 -ftree-vectorize Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: dcb314 at hotmail dot com GCC host triplet: x86_64-suse-linux http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30771
[Bug c++/30771] ice for legal code with -O2 -ftree-vectorize
--- Comment #1 from dcb314 at hotmail dot com 2007-02-12 08:53 --- Created an attachment (id=13038) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13038action=view) C++ source code -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30771
[Bug c/30772] New: ice for legal code with -fno-unit-at-a-time -O2
I just tried to compile Suse Linux package lsvpd-0.16.0-36 with the GNU C++ compiler version 4.3 snapshot 20070209. The compiler said In file included from node.c:31: /usr/include/stdlib.h: In function 'atof': /usr/include/stdlib.h:400: internal compiler error: in optimize_inline_calls, at tree-inline.c:2808 Please submit a full bug report, with preprocessed source if appropriate. See URL:http://gcc.gnu.org/bugs.html for instructions. Preprocessed source code attached. Flags -fno-unit-at-a-time -O2 required. -- Summary: ice for legal code with -fno-unit-at-a-time -O2 Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: dcb314 at hotmail dot com GCC host triplet: x86_64-suse-linux http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30772
[Bug c/30772] ice for legal code with -fno-unit-at-a-time -O2
--- Comment #1 from dcb314 at hotmail dot com 2007-02-12 08:55 --- Created an attachment (id=13039) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13039action=view) C source code -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30772
[Bug middle-end/7651] Define -Wextra strictly in terms of other warning flags
--- Comment #23 from manu at gcc dot gnu dot org 2007-02-12 09:32 --- Subject: Bug 7651 Author: manu Date: Mon Feb 12 09:32:08 2007 New Revision: 121843 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=121843 Log: 2007-02-12 Manuel Lopez-Ibanez [EMAIL PROTECTED] PR middle-end/7651 * doc/invoke.texi (Wunused-value): Update description. (Wextra): Delete item. * opts.c (set_Wextra): Don't use the value of Wextra to set the value of Wunused-value. * c-typeck.c (c_process_expr_stmt): Don't check extra_warnings. (c_finish_stmt_expr): Don't check extra_warnings. (emit_side_effect_warnings): The caller is responsible to check warn_unused_value. cp/ * cp-gimplify.c (gimplify_expr_stmt): Don't check extra_warnings. Check warn_unused_value just once. Modified: trunk/gcc/ChangeLog trunk/gcc/c-typeck.c trunk/gcc/cp/ChangeLog trunk/gcc/cp/cp-gimplify.c trunk/gcc/doc/invoke.texi trunk/gcc/opts.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=7651
[Bug c/30772] ice for legal code with -fno-unit-at-a-time -O2
--- Comment #2 from rguenth at gcc dot gnu dot org 2007-02-12 09:48 --- I'd say Doctor, it hurts when I do this -fno-unit-at-a-time RIP. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC||hubicka at gcc dot gnu dot ||org Summary|ice for legal code with - |ice for legal code with - |fno-unit-at-a-time -O2 |fno-unit-at-a-time -O2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30772
[Bug c++/30771] ice for legal code with -O2 -ftree-vectorize
--- Comment #2 from rguenth at gcc dot gnu dot org 2007-02-12 09:58 --- Confirmed. We hit #1 0x00ecf362 in vectorizable_type_promotion (stmt=0x2afac97cd000, bsi=0x0, vec_stmt=0x0) at /space/rguenther/src/svn/trunk/gcc/tree-vect-transform.c:2752 2752 gcc_assert (ncopies = 1); because nunits_in is 4 but LOOP_VINFO_VECT_FACTOR (loop_vinfo) is 2. As this is actually a widening (i_45 is int): D.6364_12 = (long unsigned int) i_45 This is the loop: # SMT.373_48 = PHI SMT.373_35(5), SMT.373_33(3) # SMT.372_46 = PHI SMT.372_34(5), SMT.372_32(3) # i_45 = PHI i_17(5), 0(3) L0:; d.29_10 = pretmp.393_8; D.6363_11 = pretmp.394_7; D.6364_12 = (long unsigned int) i_45; D.6365_13 = D.6364_12 * 12; D.6366_14 = (struct LADSPA_PortRangeHint *) D.6365_13; D.6367_15 = pretmp.394_7 + D.6366_14; D.6368_16 = D.6367_15-LowerBound; # SMT.372_34 = VDEF SMT.372_46 # SMT.373_35 = VDEF SMT.373_48 plugin_3-ports[i_45] = D.6368_16; i_17 = i_45 + 1; if (i_17 D.6359_44) goto L9; else goto L2; so we are actually trying to vectorize a widening of the induction variable. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC||dorit at il dot ibm dot com, ||rguenth at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30771
[Bug libfortran/15516] assembly snippets for nano second resolution wall clock time
--- Comment #3 from Helge dot Avlesen at bccs dot uib dot no 2007-02-12 10:03 --- Subject: Re: assembly snippets for nano second resolution wall clock time jv244 at cam dot ac dot uk [EMAIL PROTECTED] writes: is this comment about get_clockfreq.o actually correct ? I find it returns different values depending on the load of the machine (I guess this is frequency rescaling at work, i.e.): yup, it is rescaling. should be turned off if you want reliable high res measurements. Helge -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15516
[Bug c++/30771] ice for legal code with -O2 -ftree-vectorize
--- Comment #3 from dorit at il dot ibm dot com 2007-02-12 10:11 --- I'll look into it. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30771
[Bug tree-optimization/30563] [4.3 Regression] ice for legal code with flags -O2 -fno-unit-at-a-time
--- Comment #5 from pinskia at gcc dot gnu dot org 2007-02-12 10:41 --- *** Bug 30772 has been marked as a duplicate of this bug. *** -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30563
[Bug c/30772] ice for legal code with -fno-unit-at-a-time -O2
--- Comment #3 from pinskia at gcc dot gnu dot org 2007-02-12 10:41 --- *** This bug has been marked as a duplicate of 30563 *** -- 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=30772
[Bug libstdc++/18889] Unable to build libstdc++-v3
--- Comment #11 from mike at tedder dot com 2007-02-12 10:45 --- Whatever this bug was in 3.4.3, does not occur or has been fixed in gcc-3.4.6 or gcc-4.1.1. Both of these compile bootstrap without any problems. For the record (and just to make sure it wasn't anything specific with my setup), after successfully building with 3.4.6, trying to make bootstrap on 3.4.3 again results in the above compilation error when trying to build libstdc++-v3. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18889
[Bug c++/30583] [ODR] Non-static inline functions cause bugs when defined more than once in different files
--- Comment #4 from pinskia at gcc dot gnu dot org 2007-02-12 10:49 --- To dect an ODR violation in this case, means a couple of things. First you cannot compare byte for byte the function as one might be compiled with optimizations and the other was compiled without. And then if you just compare the size you run into the same problem because the funcitons might be optimized differently. Binutils at one tried adding that and guess what, it was warning all the time on libstdc++ because optimization differences. It was only doing guesses based on the size and not even based on byte for byte comparision. This is a hard problem to solve really which is why the standard mentions that this invalid does not have to be errored about. Also it is really hard to do in the compiler when we don't do any link time optimization at this point anyways. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||WONTFIX http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30583
[Bug pending/30773] New: Spec cpu2k6/h264ref and sphinx3 miscompare regression
Benchmarks spec cpu2006/464.h264ref and cpu2006/482.sphinx3 miscompare its output with 'test' dataset when compiled with trunk GCC revision 121821 at -O2 optimization level. Binary regression search showed that regression is caused by More REG_EQ* notes cleanups patch http://gcc.gnu.org/ml/gcc-patches/2007-02/msg00963.html I'm working on a minimal reproducer. -- Summary: Spec cpu2k6/h264ref and sphinx3 miscompare regression Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: pending AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: grigory_zagorodnev at linux dot intel dot com GCC build triplet: i386-redhat-linux http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30773
[Bug tree-optimization/29145] unsafe use of restrict qualifier
--- Comment #12 from dorit at gcc dot gnu dot org 2007-02-12 13:15 --- Subject: Bug 29145 Author: dorit Date: Mon Feb 12 13:14:52 2007 New Revision: 121844 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=121844 Log: PR tree-optimization/29145 * tree-data-ref.c (base_addr_differ_p): Make us more conservative in our handling of restrict qualified pointers. Added: trunk/gcc/testsuite/gcc.dg/vect/pr29145.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.dg/vect/vect-74.c trunk/gcc/testsuite/gcc.dg/vect/vect-80.c trunk/gcc/tree-data-ref.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29145
[Bug pending/30773] Spec cpu2k6/h264ref and sphinx3 miscompare regression
-- steven at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |steven at gcc dot gnu dot |dot org |org Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-02-12 14:15:44 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30773
[Bug tree-optimization/30771] ice for legal code with -O2 -ftree-vectorize
--- Comment #4 from dorit at il dot ibm dot com 2007-02-12 14:23 ---
I'm testing the patch below. (wasn;t able to reproduce the problem in the
attched testcase, but here's a reduced testcase for the problem that Richi
described - thanks!:
int a[128];
int
main()
{
short i;
for (i=0; i64; i++){
a[i] = (int)i;
}
return 0;
}
)
Index: tree-vect-analyze.c
===
--- tree-vect-analyze.c (revision 121843)
+++ tree-vect-analyze.c (working copy)
@@ -97,8 +97,12 @@
int nbbs = loop-num_nodes;
block_stmt_iterator si;
unsigned int vectorization_factor = 0;
+ tree scalar_type;
+ tree phi;
+ tree vectype;
+ unsigned int nunits;
+ stmt_vec_info stmt_info;
int i;
- tree scalar_type;
if (vect_print_dump_info (REPORT_DETAILS))
fprintf (vect_dump, === vect_determine_vectorization_factor ===);
@@ -107,12 +111,67 @@
{
basic_block bb = bbs[i];
+ for (phi = phi_nodes (bb); phi; phi = PHI_CHAIN (phi))
+ {
+ stmt_info = vinfo_for_stmt (phi);
+ if (vect_print_dump_info (REPORT_DETAILS))
+ {
+ fprintf (vect_dump, == examining phi: );
+ print_generic_expr (vect_dump, phi, TDF_SLIM);
+ }
+
+ gcc_assert (stmt_info);
+
+ /* Two cases of relevant phis: those that define an
+induction that is used in the loop, and those that
+define a reduction. */
+ if ((STMT_VINFO_RELEVANT (stmt_info) == vect_used_in_loop
+ STMT_VINFO_DEF_TYPE (stmt_info) == vect_induction_def)
+ || (STMT_VINFO_RELEVANT (stmt_info) == vect_used_by_reduction
+ STMT_VINFO_DEF_TYPE (stmt_info) == vect_reduction_def))
+{
+ gcc_assert (!STMT_VINFO_VECTYPE (stmt_info));
+ scalar_type = TREE_TYPE (PHI_RESULT (phi));
+
+ if (vect_print_dump_info (REPORT_DETAILS))
+ {
+ fprintf (vect_dump, get vectype for scalar type: );
+ print_generic_expr (vect_dump, scalar_type, TDF_SLIM);
+ }
+
+ vectype = get_vectype_for_scalar_type (scalar_type);
+ if (!vectype)
+ {
+ if (vect_print_dump_info (REPORT_UNVECTORIZED_LOOPS))
+ {
+ fprintf (vect_dump,
+ not vectorized: unsupported data-type );
+ print_generic_expr (vect_dump, scalar_type, TDF_SLIM);
+ }
+ return false;
+ }
+ STMT_VINFO_VECTYPE (stmt_info) = vectype;
+
+ if (vect_print_dump_info (REPORT_DETAILS))
+ {
+ fprintf (vect_dump, vectype: );
+ print_generic_expr (vect_dump, vectype, TDF_SLIM);
+ }
+
+ nunits = TYPE_VECTOR_SUBPARTS (vectype);
+ if (vect_print_dump_info (REPORT_DETAILS))
+ fprintf (vect_dump, nunits = %d, nunits);
+
+ if (!vectorization_factor
+ || (nunits vectorization_factor))
+ vectorization_factor = nunits;
+ }
+ }
+
for (si = bsi_start (bb); !bsi_end_p (si); bsi_next (si))
{
tree stmt = bsi_stmt (si);
- unsigned int nunits;
- stmt_vec_info stmt_info = vinfo_for_stmt (stmt);
- tree vectype;
+ stmt_info = vinfo_for_stmt (stmt);
if (vect_print_dump_info (REPORT_DETAILS))
{
@@ -269,10 +328,11 @@
return false;
}
- if (STMT_VINFO_RELEVANT_P (stmt_info))
+ if (STMT_VINFO_RELEVANT (stmt_info) == vect_used_in_loop
+ STMT_VINFO_DEF_TYPE (stmt_info) != vect_induction_def)
{
/* Most likely a reduction-like computation that is used
-in the loop. */
+in the loop. */
if (vect_print_dump_info (REPORT_UNVECTORIZED_LOOPS))
fprintf (vect_dump, not vectorized: unsupported pattern.);
return false;
@@ -2235,17 +2295,7 @@
(case 2)
If STMT has been identified as defining a reduction variable, then
- we have two cases:
- (case 2.1)
-The last use of STMT is the reduction-variable, which is defined
-by a loop-header-phi. We don't want to mark the phi as live or
-relevant (because it does not need to be vectorized, it is handled
- as part of the vectorization of the reduction), so in this case
we
-skip the call to vect_mark_relevant.
- (case 2.2)
-The rest of the uses of STMT are defined in the loop body. For
- the def_stmt of these uses we want to set liveness/relevance
- as follows:
+ we want to set liveness/relevance as follows:
STMT_VINFO_LIVE_P (DEF_STMT_info) -- false
[Bug middle-end/30774] New: [4.1 regression] ld: fatal: too many symbols require `small' PIC references
Several testsuite failures have arisen on solaris2.10 when using -fpic (not -fPIC). The problem has gotten worse over time and I don't believe the testcases are changing, so GCC has gotten worse for some reason. The logfiles look like this: ld: fatal: too many symbols require `small' PIC references: have 2144, maximum 2048 -- recompile some modules -K PIC. collect2: ld returned 1 exit status compiler exited with status 1 There are several failures on 4.1 and all later branches of this form. Here are the 4.1 failures on sparc32 that receive this message: FAIL: tmpdir-gcc.dg-struct-layout-1/t002 c_compat_x_tst.o-c_compat_y_tst.o link FAIL: tmpdir-g++.dg-struct-layout-1/t002 cp_compat_x_tst.o-cp_compat_y_tst.o link FAIL: gfortran.dg/cray_pointers_2.f90 -O0 (test for excess errors) on sparc64, in addition to the above errors I also get these: FAIL: tmpdir-gcc.dg-struct-layout-1/t001 c_compat_x_tst.o-c_compat_y_tst.o link FAIL: tmpdir-gcc.dg-struct-layout-1/t003 c_compat_x_tst.o-c_compat_y_tst.o link FAIL: tmpdir-gcc.dg-struct-layout-1/t024 c_compat_x_tst.o-c_compat_y_tst.o link FAIL: tmpdir-gcc.dg-struct-layout-1/t025 c_compat_x_tst.o-c_compat_y_tst.o link FAIL: tmpdir-gcc.dg-struct-layout-1/t026 c_compat_x_tst.o-c_compat_y_tst.o link FAIL: tmpdir-gcc.dg-struct-layout-1/t027 c_compat_x_tst.o-c_compat_y_tst.o link FAIL: tmpdir-gcc.dg-struct-layout-1/t028 c_compat_x_tst.o-c_compat_y_tst.o link FAIL: tmpdir-g++.dg-struct-layout-1/t001 cp_compat_x_tst.o-cp_compat_y_tst.o link FAIL: tmpdir-g++.dg-struct-layout-1/t003 cp_compat_x_tst.o-cp_compat_y_tst.o link FAIL: tmpdir-g++.dg-struct-layout-1/t024 cp_compat_x_tst.o-cp_compat_y_tst.o link FAIL: tmpdir-g++.dg-struct-layout-1/t025 cp_compat_x_tst.o-cp_compat_y_tst.o link FAIL: tmpdir-g++.dg-struct-layout-1/t026 cp_compat_x_tst.o-cp_compat_y_tst.o link FAIL: tmpdir-g++.dg-struct-layout-1/t027 cp_compat_x_tst.o-cp_compat_y_tst.o link FAIL: gfortran.dg/cray_pointers_2.f90 -O1 (test for excess errors) FAIL: gfortran.dg/cray_pointers_2.f90 -Os (test for excess errors) Since it happens across multiple languages, I'm guessing it's something in the middle or backend. -- Summary: [4.1 regression] ld: fatal: too many symbols require `small' PIC references Product: gcc Version: 4.1.2 Status: UNCONFIRMED Keywords: link-failure Severity: normal Priority: P3 Component: middle-end AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: ghazi at gcc dot gnu dot org GCC target triplet: sparc-sun-solaris2.10 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30774
[Bug middle-end/30774] [4.1 regression] ld: fatal: too many symbols require `small' PIC references
--- Comment #1 from ghazi at gcc dot gnu dot org 2007-02-12 14:39 --- This didn't seem to arise in 4.0.x, but all later branches have the problem. -- ghazi at gcc dot gnu dot org changed: What|Removed |Added Known to fail||4.1.2 4.2.0 4.3.0 Known to work||4.0.4 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30774
[Bug c/30769] compile error / segmentation fault / 64bit compiler
--- Comment #5 from armin at xos dot net 2007-02-12 14:40 --- Subject: Re: compile error / segmentation fault / 64bit compiler Stash.i is attached i compiled gcc with the above compiler. normal 64bit bootstrapping. cc - gcc 32 (can create 64bit with -m64) - gcc 32/64 (generates 64bit) - gcc 64 (full 64bit) i used the full 64bit version to compile perl and i tried to compile the above module. which failed. --- Comment #6 from armin at xos dot net 2007-02-12 14:40 --- Created an attachment (id=13040) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13040action=view) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30769
[Bug c/30769] compile error / segmentation fault / 64bit compiler
--- Comment #7 from ebotcazou at gcc dot gnu dot org 2007-02-12 14:54 --- i compiled gcc with the above compiler. normal 64bit bootstrapping. cc - gcc 32 (can create 64bit with -m64) - gcc 32/64 (generates 64bit) - gcc 64 (full 64bit) That's probably a duplicate of PR other/23541 then, it will be fixed in 4.1.2. You don't need to jump through all these hoops to build the 64-bit compiler, a single step is sufficient since the Sun compiler can generate 64-bit code, see http://gcc.gnu.org/install/specific.html#sparc64-x-solaris2 -- ebotcazou at gcc dot gnu dot org changed: What|Removed |Added Status|WAITING |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-02-12 14:54:32 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30769
[Bug middle-end/30774] [4.1 regression] ld: fatal: too many symbols require `small' PIC references
--- Comment #2 from ghazi at gcc dot gnu dot org 2007-02-12 14:56 --- Correction, on 4.0.3 4.0.4, I get one error: FAIL: tmpdir-gcc.dg-struct-layout-1/t002 c_compat_x_tst.o-c_compat_y_tst.o link http://gcc.gnu.org/ml/gcc-testresults/2006-03/msg00732.html http://gcc.gnu.org/ml/gcc-testresults/2007-02/msg00185.html As I noted here: http://gcc.gnu.org/ml/gcc/2007-02/msg00211.html exactly one of the three sparc32 errors arose between June 18 and June 22, 2006 on the 4.1 branch. Here are the testsuite posts: http://gcc.gnu.org/ml/gcc-testresults/2006-06/msg01003.html http://gcc.gnu.org/ml/gcc-testresults/2006-06/msg01167.html So far only the fortran one regressed between those dates, the C and C++ sparc32 errors were already there on the 18th. It doesn't seem to be any one particular patch that causes the overall problem since they didn't all happen at the same time. But I'd like to understand why these are getting worse. -- ghazi at gcc dot gnu dot org changed: What|Removed |Added Known to work|4.0.4 | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30774
[Bug bootstrap/30775] New: Bootstrap segmentation faults checking for sqrtl declaration...
AIX:doug:0 make bootstrap make[1]: Entering directory `/voltds/doug/tmp/gcc-3.4.6/libiberty' make[2]: Entering directory `/voltds/doug/tmp/gcc-3.4.6/libiberty/testsuite' make[2]: Nothing to be done for `all'. make[2]: Leaving directory `/voltds/doug/tmp/gcc-3.4.6/libiberty/testsuite' make[1]: Leaving directory `/voltds/doug/tmp/gcc-3.4.6/libiberty' make[1]: Entering directory `/voltds/doug/tmp/gcc-3.4.6/intl' make[1]: Nothing to be done for `all'. make[1]: Leaving directory `/voltds/doug/tmp/gcc-3.4.6/intl' make[1]: Entering directory `/voltds/doug/tmp/gcc-3.4.6/zlib' : make ; exec true AR_FLAGS=rc CC_FOR_BUILD=gcc CFLAGS=-g -O2 CXXFLAGS=-g -O2 CFLAGS_FOR_BUILD= CFLAGS_FOR_TARGET=-O2 -g -O2 INSTALL=/voltds/doug/tmp/gcc-3.4.6/install-sh -c INSTALL_DATA=/voltds/doug/tmp/gcc-3.4.6/install-sh -c -m 644 INSTALL_PROGRAM=/voltds/doug/tmp/gcc-3.4.6/install-sh -c INSTALL_SCRIPT=/voltds/doug/tmp/gcc-3.4.6/install-sh -c LDFLAGS= LIBCFLAGS=-g -O2 LIBCFLAGS_FOR_TARGET=-O2 -g -O2 MAKE=make MAKEINFO=/voltds/doug/tmp/gcc-3.4.6/missing makeinfo --split-size=500 PICFLAG= PICFLAG_FOR_TARGET= SHELL=/bin/sh EXPECT=expect RUNTEST=runtest RUNTESTFLAGS= exec_prefix=/voltds/doug/tmp/gcc-3.4.6.inst/usr/local infodir=/voltds/doug/tmp/gcc-3.4.6.inst/usr/local/info libdir=/voltds/doug/tmp/gcc-3.4.6.inst/usr/local/lib prefix=/voltds/doug/tmp/gcc-3.4.6.inst/usr/local tooldir=/voltds/doug/tmp/gcc-3.4.6.inst/usr/local/powerpc-ibm-aix5.2.0.0 AR=ar AS=as CC=gcc CXX=c++ LD=ld LIBCFLAGS=-g -O2 NM=nm PICFLAG= RANLIB=ranlib DESTDIR= DO=all multi-do make[1]: Leaving directory `/voltds/doug/tmp/gcc-3.4.6/zlib' Bootstrapping the compiler make[1]: Entering directory `/voltds/doug/tmp/gcc-3.4.6/gcc' Bootstrap complete - make quickstrap to redo last build, restage1 through restage3 to rebuild specific stages, restrap to redo the bootstrap from stage1, or cleanstrap to redo the bootstrap from scratch. make[1]: Leaving directory `/voltds/doug/tmp/gcc-3.4.6/gcc' Comparing stage2 and stage3 of the compiler make[1]: Entering directory `/voltds/doug/tmp/gcc-3.4.6/gcc' rm -f .bad_compare case slowcompare in *compare | *compare-lean ) stage=2 ;; * ) stage=`echo slowcompare | sed -e 's,^[a-z]*compare\([0-9][0-9]*\).*,\1,'` ;; esac; \ for dir in . cp java; do \ if [ `echo $dir/*.o` != $dir/*.o ] ; then \ for file in $dir/*.o; do \ case slowcompare in \ slowcompare* ) \ tail +16c ./$file tmp-foo1; \ tail +16c stage$stage/$file tmp-foo2 \ (cmp tmp-foo1 tmp-foo2 /dev/null 21 || echo $file differs .bad_compare) || true; \ ;; \ fastcompare* ) \ cmp $file stage$stage/$file 16 16 /dev/null 21; \ test $? -eq 1 echo $file differs .bad_compare || true; \ ;; \ gnucompare* ) \ cmp --ignore-initial=16 $file stage$stage/$file /dev/null 21; \ test $? -eq 1 echo $file differs .bad_compare || true; \ ;; \ esac ; \ done; \ else true; fi; \ done rm -f tmp-foo* case slowcompare in *compare | *compare-lean ) stage=2 ;; * ) stage=`echo slowcompare | sed -e 's,^[a-z]*compare\([0-9][0-9]*\).*,\1,'` ;; esac; \ if [ -f .bad_compare ]; then \ echo Bootstrap comparison failure!; \ cat .bad_compare; \ exit 1; \ else \ case slowcompare in \ *-lean ) rm -rf stage$stage ;; \ *) ;; \ esac; true; \ fi make[1]: Leaving directory `/voltds/doug/tmp/gcc-3.4.6/gcc' Building runtime libraries make[1]: Entering directory `/voltds/doug/tmp/gcc-3.4.6' make[2]: Entering directory `/voltds/doug/tmp/gcc-3.4.6/libiberty' make[3]: Entering directory `/voltds/doug/tmp/gcc-3.4.6/libiberty/testsuite' make[3]: Nothing to be done for `all'. make[3]: Leaving directory `/voltds/doug/tmp/gcc-3.4.6/libiberty/testsuite' make[2]: Leaving directory `/voltds/doug/tmp/gcc-3.4.6/libiberty' make[2]: Entering directory `/voltds/doug/tmp/gcc-3.4.6/intl' make[2]: Nothing to be done for `all'. make[2]: Leaving directory `/voltds/doug/tmp/gcc-3.4.6/intl' make[2]: Entering directory `/voltds/doug/tmp/gcc-3.4.6/zlib' : make ; exec true AR_FLAGS=rc CC_FOR_BUILD=gcc CFLAGS=-g -O2 CXXFLAGS=-g -O2 CFLAGS_FOR_BUILD= CFLAGS_FOR_TARGET=-O2 -g -O2 INSTALL=/voltds/doug/tmp/gcc-3.4.6/install-sh -c INSTALL_DATA=/voltds/doug/tmp/gcc-3.4.6/install-sh -c -m 644 INSTALL_PROGRAM=/voltds/doug/tmp/gcc-3.4.6/install-sh -c INSTALL_SCRIPT=/voltds/doug/tmp/gcc-3.4.6/install-sh -c LDFLAGS= LIBCFLAGS=-g -O2 LIBCFLAGS_FOR_TARGET=-O2 -g -O2 MAKE=make MAKEINFO=/voltds/doug/tmp/gcc-3.4.6/missing makeinfo --split-size=500 --split-size=500 PICFLAG= PICFLAG_FOR_TARGET= SHELL=/bin/sh EXPECT=expect RUNTEST=runtest RUNTESTFLAGS= exec_prefix=/voltds/doug/tmp/gcc-3.4.6.inst/usr/local infodir=/voltds/doug/tmp/gcc-3.4.6.inst/usr/local/info libdir=/voltds/doug/tmp/gcc-3.4.6.inst/usr/local/lib prefix=/voltds/doug/tmp/gcc-3.4.6.inst/usr/local tooldir=/voltds/doug/tmp/gcc-3.4.6.inst/usr/local/powerpc-ibm-aix5.2.0.0 AR=ar AS=as CC=gcc CXX=c++ LD=ld LIBCFLAGS=-g -O2 NM=nm PICFLAG=
[Bug bootstrap/30775] Bootstrap segmentation faults checking for sqrtl declaration...
--- Comment #1 from nospampeeps at yahoo dot com 2007-02-12 15:18 --- Created an attachment (id=13041) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13041action=view) Core dump. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30775
[Bug middle-end/30774] [4.1 regression] ld: fatal: too many symbols require `small' PIC references
--- Comment #3 from ghazi at gcc dot gnu dot org 2007-02-12 15:22 --- Hmm on June *15th*, the -fbounds-check flag was added to the fortran testcase gfortran.dg/cray_pointers_2.f90, and taking that flag out of today's sources allows the testcase to pass with -fpic. However clearly my checkout on the *18th* (which had -fbounds-check on it) the testcase somehow passed as well. So I don't think adding that flag was the actual cause of this failure. But it certainly affects the number of symbols drastically. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30774
[Bug c++/30567] -fPIC -O3 optimizer bug (32-bit target only)
--- Comment #9 from rwgk at yahoo dot com 2007-02-12 15:47 --- My binary search (using the gcc-4_2-branch) stopped here: 119790 OK 119791 fails The corresponding commit was: % svn log -r 119791 r119791 | dberlin | 2006-12-12 07:31:26 -0800 (Tue, 12 Dec 2006) | 6 lines 2006-12-12 Daniel Berlin [EMAIL PROTECTED] * tree-ssa-structalias.c (handle_ptr_arith): Return false when we can't handle the pointer arithmetic. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30567
[Bug fortran/29975] [meta-bugs] ICEs with CP2K
--- Comment #48 from jv244 at cam dot ac dot uk 2007-02-12 15:56 --- Currently, there is a new ICE on CP2K (see initial comment) that happens at any optimisation level: gfortran -c all_cp2k_gfortran.f90 all_cp2k_gfortran.f90:118549: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See URL:http://gcc.gnu.org/bugs.html for instructions. this is a new regression. I really think CP2K should be added to some nightly tester somewhere by gfortran developers... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29975
[Bug c/30776] New: Replacing both stdin and stdout on forked child does not work.
I am building on a SunFire T2000, Solaris 10 os. The test programs replaces the
stdin and stdout fds of the child with pipes from the parent. I keep thinking
there has to be a stupid mistake here somewhere but I can't find it and
everyone I show it to thinks it should work too.
I ran test using 2, 3, 8 and 12 with success, the parent could either write to
child or read from child.
Tests using 10, 11, 14, 15 all failed, whenever the parent tried either writing
then reading or writing then waiting neither the child or parent completed and
I had to CTRC to end it.
Compile options:
gcc -c -O -DSYSV -DSVR4 -Wa,-cg92 -I.. -D SUN -DUSEPROTO -Wall -ffloat-store
-DSOLARIS main.c
gcc -o runtest -O -DSYS -DSVR4 -Wa,-cg92 main.o -lm -lposix4 -lgen -lsocket
-lnsl -Wl,-R,/usr/lib
gcc -c -O -DSYSV -DSVR4 -Wa,-cg92 -I.. -D SUN -DUSEPROTO -Wall -ffloat-store
-DSOLARIS child.c
gcc -o childtest -O -DSYS -DSVR4 -Wa,-cg92 child.o -lm -lposix4 -lgen -lsocket
-lnsl -Wl,-R,/usr/lib
main.c
#include ctype.h
#include unistd.h
#include sys/types
#include sys/stat.h
#include sys/socket.h
#include fcntl.h
#include errno.h
#include string.h
#include signal.h
#include stdlib.h
#include stdio.h
#define PIPE_READ 0
#define PIPE_WRITE 1
int main (int argc, char *argv[])
{
int infds[2], outfds[2], pid, tempfd, testpath;
FILE *childIn, *childOut;
char childData[80];
char *parentData;
parentData = This is the parent data.\n;
if (0 pipe(infds)) {
exit(1);
}
fprintf(stderr, infds = [%d, %d]\n, infds[PIPE_READ], infds[PIPE_WRITE]);
if (0 pipe(outfds)) {
exit(1);
}
fprintf(stderr, outfds = [%d, %d]\n, outfds[PIPE_READ],
outfds[PIPE_WRITE]);
pid = fork();
fprintf(stderr, pid = %d\n, pid);
fflush(stderr);
switch (pid) {
case -1:
perror(Fork failed);
exit(1);
case 0: /* child */
close(0); /* setup standard in */
tempfd = dup(infds[PIPE_READ]);
if (tempfd 0) {
perror(Setup stdin dup failed);
exit(1);
}
fprintf(stderr, Child new stdin fd = %d\n, tempfd);
while ((0 != close(infds[PIPE_READ])) (EINTR == errno));
while ((0 != close(infds[PIPE_WRITE])) (EINTR == errno));
close(1); /* setup standard out */
tempfd = dup(outfds[PIPE_WRITE]);
if (tempfd 0) {
perror(Setup stdout dup failed);
exit(1);
}
fprintf(stderr, Child new stdout fd = %d\n, tempfd);
while ((0 != close(outfds[PIPE_READ])) (EINTR == errno));
while ((0 != close(outfds[PIPE_WRITE])) (EINTR == errno));
if (1 argc) {
execl(./childtest, ./childtest, argv[argc - 1], (char *)0);
} else {
execl(./childtest, ./childtest, (char *)0);
}
perror(Exec child failed);
exit(1);
default:
break;
}
while ((0 != close(infds[PIPE_READ]) (EINTR == errno));
childIn = fopen(infds[PIPE_WRITE], w);
if (NULL == childIn) {
perror(Parent creating child's stdin FILE);
}
while ((0 != close(outfds[PIPE_WRITE]) (EINTR == errno));
childOut = fopen(outfds[PIPE_READ], r);
if (NULL == childOut) {
perror(Parent creating child's stdout FILE);
}
if (1 argc) {
testpath = atoi(argv[argc - 1]);
} else {
testpath = 15;
}
if (testpath 1) { sleep(1); }
if (testpath 2) {
fprintf(stderr, Parent sends: %s, parentData);
fflush(stderr);
fputs(parentData, childIn);
}
if (testpath 4) {
int status;
fputs(Parent waiting\n, stderr);
while (wait(status) != pid) {
fputs(Parent woke but not child\n, stderr);
}
fprintf(stderr, Parent woke, child status: %d\n, status);
}
if (testpath 8) {
fputs(Parent reading child's stdout\n, stderr);
fflush(stderr);
if (NULL == fgets(childData, 80, childOut)) {
fprintf(stderr, Parent receive: NOTHING\n);
} else {
fprintf(stderr, Parent receive: %s\n, childData);
}
fflush(stderr);
}
fclose(childIn);
fclose(childOut);
fputs(Parent completed\n, stderr);
fflush(stderr);
exit(0);
}
child.c
#include ctype.h
#include unistd.h
#include sys/types.h
#include sys/stat.h
#include fcntl.h
#include errno.h
#include string.h
#include signal.h
#include stdlib.h
#include stdio.h
int main (int argc, char *argv[])
{
int testpath;
char recvData[180];
char *sendData;
sendData = This is the child data.\n;
fputs(Starting child\n, stderr);
fflush(stderr);
if (argc 1) {
testpath = atoi(argv[argc - 1]);
} else {
testpath = 15;
}
if (testpath 2) {
fputs(Child reading\n, stderr);
fflush(stderr);
if (NULL == fgets(recvData, 160, stdin)) {
fputs(child receive NULL\n, stderr);
fflush(stderr);
exit(1);
}
fprintf(stderr, child
[Bug c++/30567] -fPIC -O3 optimizer bug (32-bit target only)
--- Comment #10 from bangerth at dealii dot org 2007-02-12 16:03 --- Daniel, any idea? -- bangerth at dealii dot org changed: What|Removed |Added CC||dberlin at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30567
[Bug fortran/29975] [meta-bugs] ICEs with CP2K
--- Comment #49 from fxcoudert at gcc dot gnu dot org 2007-02-12 16:16 --- (In reply to comment #48) Currently, there is a new ICE on CP2K (see initial comment) that happens at any optimisation level: gfortran -c all_cp2k_gfortran.f90 all_cp2k_gfortran.f90:118549: internal compiler error: Segmentation fault It compiled fine two days ago (with the patch for PR30391), I tested it myself! I'm pretty sure it's the same problem that was already reported here: http://gcc.gnu.org/ml/fortran/2007-02/msg00250.html Of course, a confirmation wouldn't hurt, but I don't have time right now. If you manage to confirm this, it'd be nice to send a mail to the list. I really think CP2K should be added to some nightly tester somewhere by gfortran developers... Well, I second that, but we first need to get it working (like, the middle-end people have to move on PR30391). -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added CC||paulthomas2 at wanadoo dot ||fr Last reconfirmed|2007-01-21 16:34:55 |2007-02-12 16:16:29 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29975
[Bug c++/30567] -fPIC -O3 optimizer bug (32-bit target only)
--- Comment #11 from dberlin at gcc dot gnu dot org 2007-02-12 16:37 --- (In reply to comment #10) Daniel, any idea? None. This change actually made us more conservative with points-to, it certainly won't cause *more* things to be optimized away. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30567
[Bug fortran/29975] [meta-bugs] ICEs with CP2K
--- Comment #50 from jv244 at cam dot ac dot uk 2007-02-12 17:09 --- I really think CP2K should be added to some nightly tester somewhere by gfortran developers... Well, I second that, but we first need to get it working (like, the middle-end people have to move on PR30391). I agree that are two separate issues. One is to get it to work (and keep it that way), and the other would be to monitor runtime performance. For the latter issue I can prepare reasonable benchmark inputs, while for the former I think it is good enough to just compile the tarbal from the initial comment. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29975
[Bug target/30757] [4.3 Regression] ICE with -march=athlon-xp -mfpmath=sse
--- Comment #2 from stuart at apple dot com 2007-02-12 17:11 --- Almost certainly my fault; I'll look into this. Suggested workaround: choose a different target cpu; 'pentium4' works. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30757
[Bug fortran/29975] [meta-bugs] ICEs with CP2K
--- Comment #51 from jv244 at cam dot ac dot uk 2007-02-12 17:12 --- I'm pretty sure it's the same problem that was already reported here: http://gcc.gnu.org/ml/fortran/2007-02/msg00250.html Of course, a confirmation wouldn't hurt, but I don't have time right now. If you manage to confirm this, it'd be nice to send a mail to the list. The line corresponding to the error messageis: IF (failure) NULLIFY(sll) I don't know if this triggers something, looks like a simple statement. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29975
[Bug bootstrap/30775] Bootstrap segmentation faults checking for sqrtl declaration...
--- Comment #2 from pinskia at gcc dot gnu dot org 2007-02-12 17:14 --- This target is known to bootstrap with 3.4.6. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30775
[Bug fortran/29975] [meta-bugs] ICEs with CP2K
--- Comment #52 from pinskia at gcc dot gnu dot org 2007-02-12 17:20 --- I don't know if this triggers something, looks like a simple statement. Yes that triggers my memory of PR 30391. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29975
[Bug middle-end/28690] [4.2/4.3 Regression] Performace problem with indexed load/stores on powerpc
--- Comment #35 from bergner at gcc dot gnu dot org 2007-02-12 17:29
---
Created an attachment (id=13042)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13042action=view)
Alternate patch to commutative_operand_precedence to increase the precedence of
REG_POINTER and MEM_POINTER objects.
Ok, now that the libjava multilib problems have been fixed, I've been
able to attempt to bootstrap the patch in Comment #34 with java enabled.
In doing so, I'm now hitting an ICE while building the 64-bit libgcj.
The ICE is occurring in the same location and for the same reason as
the ICE (optabs.c:emit_cmp_and_jump_insns()) I hit when I attempted
to change swap_commutative_operands_p() (as in this alternate
patch) so that it sorted REG's by register numbers similar to how
simplify_plus_minus_op_data_cmp() sorts them.
With this attached alternate patch, we have a simple testcase that
exposes the problem:
void
gomp_sem_wait_slow (int *sem, int a, int b)
{
__sync_bool_compare_and_swap (sem, a, b);
}
For this testcase, the swap_commutative_operands_p (x, y) call that guards
the gcc_assert (label) we're failing in, x and y are simple REGs that
are swapped due to REGNO(y) is smaller then RGENO(x). I don't understand
why the gcc_assert(label) is needed, but I'll try and track that down.
--
bergner at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |bergner at gcc dot gnu dot
|dot org |org
Status|NEW |ASSIGNED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28690
[Bug middle-end/23237] [4.1 Regression] -O1 rejects valid code (xxx causes a section type conflict).
--- Comment #14 from fang at csl dot cornell dot edu 2007-02-12 17:31 --- I'm seeing some failures with 4.1.2-RC2 on test case pr23237.c on powerpc7400-apple-darwin8, posted: http://gcc.gnu.org/ml/gcc-testresults/2007-02/msg00475.html Are these known/expected/new? -- fang at csl dot cornell dot edu changed: What|Removed |Added CC||fang at csl dot cornell dot ||edu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23237
[Bug fortran/29975] [meta-bugs] ICEs with CP2K
--- Comment #53 from jv244 at cam dot ac dot uk 2007-02-12 17:52 --- (In reply to comment #52) I don't know if this triggers something, looks like a simple statement. Yes that triggers my memory of PR 30391. No, that one only happens at -O1 and above, the current ICE is at -O0 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29975
[Bug fortran/29975] [meta-bugs] ICEs with CP2K
--- Comment #54 from pault at gcc dot gnu dot org 2007-02-12 18:02 --- (In reply to comment #53) (In reply to comment #52) I don't know if this triggers something, looks like a simple statement. Yes that triggers my memory of PR 30391. No, that one only happens at -O1 and above, the current ICE is at -O0 Nonetheless, I do not see it being associated with my doo-doo in module.c, do you? Paul -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29975
[Bug testsuite/30777] New: testsuite/gcc.target/i386/abi-1.c failure on openSolaris
FAIL: gcc.target/i386/abi-1.c scan-assembler xmm0 Not certain if this is a code generation problem or a test suite problem. The generated code does not use mmx/sse registers. verbose output: /opt/gnu.org/gcc-4.1/bin/gcc abi-1.c -v -O1 -msse -mno-sse2 -S -o abi-1.s Using built-in specs. Target: i686-pc-solaris2.11 Configured with: ../../gcc/configure --prefix=/opt/gnu.org/gcc-4.1 --with-gnu-as --with-as=/opt/gnu.org/gcc-4.1/bin/as --without-gnu-ld --with-ld=/usr/ccs/bin/ld --enable-shared --disable-multilib --enable-languages=c --with-mpfr=/opt/gnu.org/gcc-4.1 --with-gmp=/opt/gnu.org/gcc-4.1 i686-pc-solaris2.11 Thread model: posix gcc version 4.1.2 20070211 (prerelease) built on openSolaris (Build 54) binutils version 2.17 gmp version 4.5.1 mpfr version 2.2.1 generated code: .file abi-1.c .text .globl foo .type foo, @function foo: movl4(%esp), %eax movl$0, (%eax) movl$1072693248, 4(%eax) movl$0, 8(%eax) movl$1073741824, 12(%eax) ret $4 .size foo, .-foo .ident GCC: (GNU) 4.1.2 20070211 (prerelease) -- Summary: testsuite/gcc.target/i386/abi-1.c failure on openSolaris Product: gcc Version: 4.1.2 Status: UNCONFIRMED Severity: minor Priority: P3 Component: testsuite AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: jb at druiddesigns dot com GCC build triplet: i686-pc-solaris2.11 GCC host triplet: i686-pc-solaris2.11 GCC target triplet: i686-pc-solaris2.11 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30777
[Bug target/30052] memory hog on x86-64
--- Comment #6 from pluto at agmk dot net 2007-02-12 18:25 --- Created an attachment (id=13043) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13043action=view) testcase -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30052
[Bug fortran/29975] [meta-bugs] ICEs with CP2K
--- Comment #55 from jv244 at cam dot ac dot uk 2007-02-12 18:26 --- Nonetheless, I do not see it being associated with my doo-doo in module.c, do you? I'm not an expert, but this is a traceback, leading to module.c: Program received signal SIGSEGV, Segmentation fault. gfc_insert_bbt (root=0x0, new=0x7a23c80, compare=0x459ed0 compare_symtree) at /scratch/vondele/gcc_trunk/gcc/gcc/fortran/bbt.c:137 137 *r = insert (n, *r, compare); (gdb) bt #0 gfc_insert_bbt (root=0x0, new=0x7a23c80, compare=0x459ed0 compare_symtree) at /scratch/vondele/gcc_trunk/gcc/gcc/fortran/bbt.c:137 #1 0x00459d34 in gfc_new_symtree (root=0x0, name=0x7fbfffe980 @20233) at /scratch/vondele/gcc_trunk/gcc/gcc/fortran/symbol.c:1909 #2 0x0043a44a in get_unique_symtree (ns=0x0) at /scratch/vondele/gcc_trunk/gcc/gcc/fortran/module.c:1775 #3 0x0043ca1a in read_cleanup (p=0x7c7f9f0) at /scratch/vondele/gcc_trunk/gcc/gcc/fortran/module.c:3290 #4 0x0043c9db in read_cleanup (p=0x7922d50) at /scratch/vondele/gcc_trunk/gcc/gcc/fortran/module.c:3284 #5 0x0043c9db in read_cleanup (p=0x7a26300) at /scratch/vondele/gcc_trunk/gcc/gcc/fortran/module.c:3284 #6 0x0043c9db in read_cleanup (p=0x7c77ec0) at /scratch/vondele/gcc_trunk/gcc/gcc/fortran/module.c:3284 #7 0x0043c9db in read_cleanup (p=0x79dfbf0) at /scratch/vondele/gcc_trunk/gcc/gcc/fortran/module.c:3284 #8 0x0043c9db in read_cleanup (p=0x7af9f20) at /scratch/vondele/gcc_trunk/gcc/gcc/fortran/module.c:3284 #9 0x0043c9db in read_cleanup (p=0x7af2390) at /scratch/vondele/gcc_trunk/gcc/gcc/fortran/module.c:3284 #10 0x0043d10d in read_module () at /scratch/vondele/gcc_trunk/gcc/gcc/fortran/module.c:3563 #11 0x0043d555 in gfc_use_module () at /scratch/vondele/gcc_trunk/gcc/gcc/fortran/module.c:4164 #12 0x00442b98 in accept_statement (st=Variable st is not available. ) at /scratch/vondele/gcc_trunk/gcc/gcc/fortran/parse.c:1255 #13 0x00443625 in parse_spec (st=ST_USE) at /scratch/vondele/gcc_trunk/gcc/gcc/fortran/parse.c:1887 #14 0x00444e9a in gfc_parse_file () at /scratch/vondele/gcc_trunk/gcc/gcc/fortran/parse.c:3063 #15 0x004631ae in gfc_be_parse_file (set_yydebug=Variable set_yydebug is not available. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29975
[Bug target/30052] memory hog on x86-64
--- Comment #7 from pluto at agmk dot net 2007-02-12 18:27 --- x86_64-pld-linux-g++ -c -fPIC -O2 -fno-strict-aliasing -fwrapv -march=x86-64 -fno-strict-aliasing -gdwarf-2 -g2 -Wall -W -D_REENTRANT --save-temps -ftime-report -fmem-report -DQT_NO_DEBUG -DQT_CORE_LIB -I. -I/usr/include/python2.5 -I/usr/lib64/qt4/mkspecs/default -I/usr/include/qt4/QtCore -I/usr/include/qt4 -I/usr/ginclude -o sipQtCorepart0.o sipQtCorepart0.cpp Memory still allocated at the end of the compilation process Size AllocatedUsedOverhead 8 81926920 240 1612k 8288 264 64 112k111k 1792 256 20k 18k280 512 16k 14k224 1024 64k 61k896 2048 56k 54k784 4096 92k 92k 1288 8192 64k 64k448 16384 64k 64k224 112 4096 896 56 208 16k 13k224 192 16k 12k224 160 48k 46k672 176 144k138k 2016 96 2008k 1975k 27k 416 48k 43k672 128 81926912 112 48 252k248k 4032 224 404k396k 5656 32 192k188k 3456 8028k 27k392 Total 3676k 3594k 50k String pool entries 21015 identifiers 21015 (100.00%) slots 32768 bytes 308k (24k overhead) table size 256k coll/search 0.5458 ins/search 0.0692 avg. entry 15.05 bytes (+/- 7.88) longest entry 57 ??? tree nodes created (No per-node statistics) Type hash: size 1021, 382 elements, 0.255906 collisions DECL_DEBUG_EXPR hash: size 1021, 0 elements, 0.00 collisions DECL_VALUE_EXPR hash: size 1021, 0 elements, 0.00 collisions no search statistics Execution times (seconds) name lookup : 0.00 ( 0%) usr 0.00 ( 0%) sys 0.01 ( 4%) wall 89 kB ( 3%) ggc TOTAL : 0.16 0.03 0.23 3530 kB Memory still allocated at the end of the compilation process Size AllocatedUsedOverhead 8 40962408 120 16 4424k 3253k 95k 6413M 9377k213k 256 648k647k 9072 512 368k262k 5152 10241876k 1876k 25k 2048 952k840k 13k 4096 940k936k 12k 81927480k 7472k 51k 16384 2160k 2144k 7560 32768224k192k392 65536960k960k840 131072384k256k168 262144768k768k168 112 3944k 3624k 53k 208 2704k 2267k 36k 192 2904k 1973k 39k 160 9732k 7882k133k 176 16M 9357k234k 9616M 16M237k 416 10M 10111k151k 128 2576k 2020k 35k 4818M 9012k291k 224 3824k 3723k 52k 3237M 37M674k 8011M 11M166k Total171M143M 2540k String pool entries 91552 identifiers 91552 (100.00%) slots 131072 bytes 1432k (103k overhead) table size 1024k coll/search 1.3361 ins/search 0.1857 avg. entry 16.02 bytes (+/- 10.91) longest entry 430 ??? tree nodes created (No per-node statistics) Type hash: size 16381, 8503 elements, 1.014345 collisions DECL_DEBUG_EXPR hash: size 1021, 47 elements, 0.107877 collisions DECL_VALUE_EXPR hash: size 1021, 0 elements, 0.00 collisions RESTRICT_BASEhash: size 509, 12 elements, 0.020408 collisions no search statistics Execution times (seconds) garbage collection: 0.29 ( 0%) usr 0.00 ( 0%) sys 0.30 ( 0%) wall 0 kB ( 0%) ggc callgraph construction: 0.12 ( 0%) usr 0.01 ( 1%) sys 0.15 ( 0%) wall 4866 kB ( 1%) ggc callgraph optimization: 0.01 ( 0%) usr 0.00 ( 0%) sys 0.02 ( 0%) wall 388 kB ( 0%) ggc ipa reference : 0.05 ( 0%) usr 0.01 ( 1%) sys 0.06 ( 0%) wall 100 kB ( 0%) ggc ipa pure const: 0.01 ( 0%) usr 0.00 ( 0%) sys 0.01 ( 0%) wall 0 kB ( 0%) ggc ipa type escape : 0.06 ( 0%) usr 0.01 ( 1%) sys 0.07 ( 0%) wall 0 kB ( 0%) ggc cfg cleanup : 0.07 ( 0%) usr 0.00 ( 0%) sys 0.09 ( 0%) wall 372 kB ( 0%) ggc trivially dead code : 0.11 ( 0%) usr 0.00 ( 0%) sys 0.10 ( 0%) wall 0 kB ( 0%) ggc life analysis : 0.40 ( 0%) usr 0.00 ( 0%) sys 0.52 ( 0%) wall 3401 kB ( 0%) ggc life info update : 0.07 ( 0%) usr 0.00 ( 0%) sys 0.10 (
[Bug fortran/29975] [meta-bugs] ICEs with CP2K
--- Comment #56 from fxcoudert at gcc dot gnu dot org 2007-02-12 18:30 --- (In reply to comment #55) Program received signal SIGSEGV, Segmentation fault. gfc_insert_bbt (root=0x0, new=0x7a23c80, compare=0x459ed0 compare_symtree) at /scratch/vondele/gcc_trunk/gcc/gcc/fortran/bbt.c:137 137 *r = insert (n, *r, compare); (gdb) bt #0 gfc_insert_bbt (root=0x0, new=0x7a23c80, compare=0x459ed0 compare_symtree) at /scratch/vondele/gcc_trunk/gcc/gcc/fortran/bbt.c:137 #1 0x00459d34 in gfc_new_symtree (root=0x0, name=0x7fbfffe980 @20233) at /scratch/vondele/gcc_trunk/gcc/gcc/fortran/symbol.c:1909 #2 0x0043a44a in get_unique_symtree (ns=0x0) at /scratch/vondele/gcc_trunk/gcc/gcc/fortran/module.c:1775 Yes, that's the one: http://gcc.gnu.org/ml/fortran/2007-02/msg00250.html -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added Last reconfirmed|2007-02-12 16:16:29 |2007-02-12 18:30:31 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29975
[Bug target/30757] [4.3 Regression] ICE with -march=athlon-xp -mfpmath=sse
--- Comment #3 from stuart at apple dot com 2007-02-12 18:32 --- O.K., the breakage here is that athlon-xp is an SSE1 machine, and most of the conversions in the patch require SSE2. It looks like SSE1 will support a few of the new conversions (e.g. unsigned int32 = float); I'll see about enabling these for SSE1 targets, and arranging for the SSE2-only conversions to fall back to the x87. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30757
[Bug middle-end/30751] [4.3 Regression] internal compiler error: in extract_insn, at recog.c:2108
--- Comment #4 from ian at airs dot com 2007-02-12 18:45 ---
Tom Tromey helped me recreate this with a cross-compiler.
I'm currently testing this patch:
Index: lower-subreg.c
===
--- lower-subreg.c (revision 121769)
+++ lower-subreg.c (working copy)
@@ -711,6 +711,23 @@ resolve_simple_move (rtx set, rtx insn)
return insn;
}
+ /* It's possible for the code to use a subreg of a decomposed
+ register while forming an address. We need to handle that before
+ passing the address to emit_move_insn. We pass NULL_RTX as the
+ insn parameter to resolve_subreg_use because we can not validate
+ the insn yet. */
+ if (MEM_P (src) || MEM_P (dest))
+{
+ int acg;
+
+ if (MEM_P (src))
+ for_each_rtx (XEXP (src, 0), resolve_subreg_use, NULL_RTX);
+ if (MEM_P (dest))
+ for_each_rtx (XEXP (dest, 0), resolve_subreg_use, NULL_RTX);
+ acg = apply_change_group ();
+ gcc_assert (acg);
+}
+
/* If SRC is a register which we can't decompose, or has side
effects, we need to move via a temporary register. */
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30751
[Bug middle-end/30751] [4.3 Regression] internal compiler error: in extract_insn, at recog.c:2108
-- ian at airs dot com changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |ian at airs dot com |dot org | Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-02-12 18:46:21 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30751
[Bug middle-end/30778] New: [4.3 Regression] invalid code generation for memset() with -mtune=k8
Reduced from combine.c, fails if compiled with -O1 -mtune=k8, doesn't fail
with -O1 -mtune=generic.
possibly introduced between r119211 and r119769 (not sure about this).
// ---8---
extern void *memset (void *, int, unsigned long);
extern void abort (void);
struct reg_stat {
void *last_death;
void *last_set;
void *last_set_value;
int last_set_label;
char last_set_sign_bit_copies;
int last_set_mode : 8;
char last_set_invalid;
char sign_bit_copies;
long nonzero_bits;
};
static struct reg_stat *reg_stat;
void __attribute__((noinline))
init_reg_last (void)
{
memset (reg_stat, 0, __builtin_offsetof (struct reg_stat, sign_bit_copies));
}
int main (void)
{
struct reg_stat r;
reg_stat = r;
r.nonzero_bits = -1;
init_reg_last ();
if (r.nonzero_bits != -1)
abort ();
return 0;
}
// ---8---
--
Summary: [4.3 Regression] invalid code generation for memset()
with -mtune=k8
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Keywords: wrong-code
Severity: normal
Priority: P3
Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: belyshev at depni dot sinp dot msu dot ru
GCC target triplet: x86_64-unknown-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30778
[Bug fortran/30779] New: incomplete file triggers ICE
trying to find a testcase for what is currently an issue in PR29975 I ran into this: [EMAIL PROTECTED]:/scratch/vondele/clean/cp2k/obj/Linux-x86-64-gfortran/sdbg gfortran t.f90 t.f90:0: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See URL:http://gcc.gnu.org/bugs.html for instructions. [EMAIL PROTECTED]:/scratch/vondele/clean/cp2k/obj/Linux-x86-64-gfortran/sdbg cat t.f90 MODULE M1 INTEGER :: I END MODULE M1 USE M1,ONLY: I, -- Summary: incomplete file triggers ICE Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: jv244 at cam dot ac dot uk http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30779
[Bug fortran/29975] [meta-bugs] ICEs with CP2K
--- Comment #57 from jv244 at cam dot ac dot uk 2007-02-12 19:18 --- Yes, that's the one: http://gcc.gnu.org/ml/fortran/2007-02/msg00250.html for people reducing the bug, I found that it is in the module cp_fm_pool_types. This indicates the the line number indicated in the segfault would be wrong. Trying to reduce the testcase further, my automatic script got stuck on what is now PR 30779 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29975
[Bug target/30778] [4.3 Regression] invalid code generation for memset() with -mtune=k8
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||hubicka at gcc dot gnu dot ||org Component|middle-end |target Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30778
[Bug testsuite/30649] [4.1.x] possible bogus checkin of g++.dg/debug/debug9.C
--- Comment #3 from aoliva at gcc dot gnu dot org 2007-02-12 19:26 --- Sorry, for some reason I had missed the e-mail with the question about this. Yes, the check in was bogus. I still don't understand how it happened. Sorry about that. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30649
[Bug fortran/30779] incomplete file triggers ICE
--- Comment #1 from tkoenig at gcc dot gnu dot org 2007-02-12 19:29 --- Confirmed. Backtrace: (gdb) r t.f90 Starting program: /home/ig25/libexec/gcc/i686-pc-linux-gnu/4.3.0/f951 t.f90 Failed to read a valid object file image from memory. t.f90:1: cat t.f90 1 Error: Unclassifiable statement at (1) Program received signal SIGSEGV, Segmentation fault. 0x0809a6d7 in gfc_next_char_literal (in_string=0) at /home/ig25/gcc/trunk/gcc/fortran/scanner.c:711 711 if (gfc_current_locus.lb-linenum == continue_line + 1) -- tkoenig at gcc dot gnu dot org changed: What|Removed |Added CC||tkoenig at gcc dot gnu dot ||org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Keywords||error-recovery, ice-on- ||invalid-code Last reconfirmed|-00-00 00:00:00 |2007-02-12 19:29:56 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30779
[Bug testsuite/30777] testsuite/gcc.target/i386/abi-1.c failure on openSolaris
--- Comment #1 from jb at druiddesigns dot com 2007-02-12 20:08 --- Correction gmp version is gmp-4.2.1 not gmp-4.5.1. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30777
[Bug fortran/30779] incomplete file triggers ICE
--- Comment #2 from jv244 at cam dot ac dot uk 2007-02-12 20:12 --- (In reply to comment #1) Confirmed. Backtrace: (gdb) r t.f90 Starting program: /home/ig25/libexec/gcc/i686-pc-linux-gnu/4.3.0/f951 t.f90 Failed to read a valid object file image from memory. t.f90:1: cat t.f90 1 Error: Unclassifiable statement at (1) Program received signal SIGSEGV, Segmentation fault. 0x0809a6d7 in gfc_next_char_literal (in_string=0) at /home/ig25/gcc/trunk/gcc/fortran/scanner.c:711 711 if (gfc_current_locus.lb-linenum == continue_line + 1) looks like you discovered an independent bug, in my case the 'cat t.f90' wasn't part of the program (but it is the command line that wraps) and in my case there is no error message. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30779
[Bug libfortran/30533] minval, maxval missing for kind=1 and kind=2
--- Comment #8 from tkoenig at gcc dot gnu dot org 2007-02-12 20:21 --- Created an attachment (id=13044) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13044action=view) combined patch for this and PR 30765 Regression-test is OK, file generation is OK. -- tkoenig at gcc dot gnu dot org changed: What|Removed |Added Attachment #13036|0 |1 is obsolete|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30533
[Bug libfortran/30533] minval, maxval missing for kind=1 and kind=2
--- Comment #9 from tkoenig at gcc dot gnu dot org 2007-02-12 20:23 --- Created an attachment (id=13045) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13045action=view) Test case Test case. I'll be away for a few days, I'll submit it as a proper patch then. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30533
[Bug libfortran/30533] minval, maxval missing for kind=1 and kind=2
--- Comment #10 from tkoenig at gcc dot gnu dot org 2007-02-12 20:25 --- (In reply to comment #8) Created an attachment (id=13044) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13044action=view) [edit] combined patch for this and PR 30765 Regression-test is OK, file generation is OK. I found and fixed the typo for i_any_c, it's a wonder this didn't break anything. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30533
[Bug target/30052] possible quadratic behaviour.
--- Comment #8 from dberlin at gcc dot gnu dot org 2007-02-12 20:47 --- Does this work on mainline with no real issue? If so, i'll try to backport the solver changes. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30052
[Bug fortran/30780] New: cpu_time produces a floating point exception when used with -O0
Test2.f95 has this code: program test2 real :: start, finish, dog call cpu_time(start) dog = 1.0 dog = dog*dog call cpu_time(finish) print '(Time = , f6.3, seconds. )', finish - start end program test2 I compiled it with: gfortran -O0 -ffpe-trap='precision' test2.f95 and on running got this error: Floating point exception -- Summary: cpu_time produces a floating point exception when used with -O0 Product: gcc Version: 4.1.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: glv at maths dot otago dot ac dot nz GCC target triplet: x86_64-redhat-linux http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30780
[Bug target/30770] BOOT_CFLAGS=-O2 -g -mtune=nocona miscompiled thes stage 3 compiler
--- Comment #2 from hjl at lucon dot org 2007-02-12 21:09 --- I have verified that revision 119252: http://gcc.gnu.org/ml/gcc-cvs/2006-11/msg00907.html breaks -mtune=nocona. Jan, can you take a look? Thanks. -- hjl at lucon dot org changed: What|Removed |Added CC||hubicka at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30770
[Bug fortran/30781] New: cpu_time produces a floating point exception when used with -O0
Test2.f95 has this code: program test2 real :: start, finish, dog call cpu_time(start) dog = 1.0 dog = dog*dog call cpu_time(finish) print '(Time = , f6.3, seconds. )', finish - start end program test2 I compiled it with: gfortran -O0 -ffpe-trap='precision' test2.f95 and on running got this error: Floating point exception -- Summary: cpu_time produces a floating point exception when used with -O0 Product: gcc Version: 4.1.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: glv at maths dot otago dot ac dot nz GCC build triplet: x86_64-redhat-linux GCC host triplet: x86_64-redhat-linux GCC target triplet: x86_64-redhat-linux http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30781
[Bug target/30770] [4.3 regression]: BOOT_CFLAGS=-O2 -g -mtune=nocona miscompiled thes stage 3 compiler
--- Comment #3 from belyshev at depni dot sinp dot msu dot ru 2007-02-12 21:19 --- I believe this is the same bug as pr 30778. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30770
[Bug middle-end/30667] [4.3 Regression] ICE in immed_double_const, at emit-rtl.c:468
--- Comment #3 from harsha dot jagasia at amd dot com 2007-02-12 21:25 --- Does the patch from Uros fix this bug or is it still unresolved? -- harsha dot jagasia at amd dot com changed: What|Removed |Added CC||harsha dot jagasia at amd ||dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30667
[Bug fortran/30781] cpu_time produces a floating point exception when used with -O0
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-02-12 21:25 --- *** This bug has been marked as a duplicate of 30780 *** -- 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=30781
[Bug fortran/30780] cpu_time produces a floating point exception when used with -O0
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-02-12 21:25 --- *** Bug 30781 has been marked as a duplicate of this bug. *** -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30780
[Bug c++/29054] [4.0 Regression] ICE on friend template specialization
--- Comment #10 from reichelt at gcc dot gnu dot org 2007-02-12 21:27 --- Was not fixed on the 4.0 branch. -- reichelt at gcc dot gnu dot org changed: What|Removed |Added CC||reichelt at gcc dot gnu dot ||org Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29054
[Bug fortran/30780] cpu_time produces a floating point exception when used with -O0
--- Comment #2 from pinskia at gcc dot gnu dot org 2007-02-12 21:28 --- This works for me on x86 linux-gnu. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30780
[Bug c/30776] Replacing both stdin and stdout on forked child does not work.
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-02-12 21:28 --- I really doubt this is a GCC bug. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30776
[Bug c/30776] Replacing both stdin and stdout on forked child does not work.
--- Comment #2 from schwab at suse dot de 2007-02-12 21:48 --- You never send EOF. -- schwab at suse dot de changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30776
[Bug middle-end/7651] Define -Wextra strictly in terms of other warning flags
--- Comment #24 from patchapp at dberlin dot org 2007-02-12 22:10 --- Subject: Bug number PR7651 A patch for this bug has been added to the patch tracker. The mailing list url for the patch is http://gcc.gnu.org/ml/gcc-patches/2007-02/msg01102.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=7651
[Bug c++/14622] type mismatch in explicit template instantiation not detected
--- Comment #3 from simartin at gcc dot gnu dot org 2007-02-12 22:17 --- Subject: Bug 14622 Author: simartin Date: Mon Feb 12 22:17:06 2007 New Revision: 121864 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=121864 Log: PR c++/14622 * pt.c (do_decl_instantiation): Detect type mismatches in explicit instantiations for variables. Added: trunk/gcc/testsuite/g++.dg/template/instantiate9.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/pt.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/g++.old-deja/g++.pt/instantiate12.C -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14622
[Bug c++/14622] type mismatch in explicit template instantiation not detected
--- Comment #4 from simartin at gcc dot gnu dot org 2007-02-12 22:25 --- Fixed on the mainline. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14622
[Bug c/30769] compile error / segmentation fault / 64bit compiler
--- Comment #8 from armin at xos dot net 2007-02-12 22:44 --- Subject: Re: compile error / segmentation fault / 64bit compiler i used that information you linked to, but i only got 64bit code with -m64 i needed it by default. i surely could have skipped the last step, but i wanted my local tree to just contain 64bit stuff. will the patch contained in the PR fix my problem. or is it just related somehow? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30769
[Bug fortran/29975] [meta-bugs] ICEs with CP2K
--- Comment #58 from paulthomas2 at wanadoo dot fr 2007-02-12 22:55 --- Subject: Re: [meta-bugs] ICEs with CP2K jv244 at cam dot ac dot uk wrote: --- Comment #57 from jv244 at cam dot ac dot uk 2007-02-12 19:18 --- Yes, that's the one: http://gcc.gnu.org/ml/fortran/2007-02/msg00250.html for people reducing the bug, I found that it is in the module cp_fm_pool_types. This indicates the the line number indicated in the segfault would be wrong. Trying to reduce the testcase further, my automatic script got stuck on what is now PR 30779 OK Yours is one and the same as Daniel's. The backtrace makes that completely clear. The fix was posted to the list earlier on today. It is just now regtesting - I will commit it before I go to bed tonight. Thanks for bearing with us. Paul -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29975
[Bug fortran/30319] [4.2 and 4.1 only] internal error in gfc_resolve_expr() for character parameter
--- Comment #6 from pault at gcc dot gnu dot org 2007-02-12 22:58 --- Under the circumstances, I had better accept it... Paul -- pault at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |pault at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED Last reconfirmed|2007-01-22 23:54:20 |2007-02-12 22:58:16 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30319
[Bug c/30769] compile error / segmentation fault / 64bit compiler
--- Comment #9 from ebotcazou at gcc dot gnu dot org 2007-02-12 23:02 --- i used that information you linked to, but i only got 64bit code with -m64 i needed it by default. i surely could have skipped the last step, but i wanted my local tree to just contain 64bit stuff. You probably missed something, it's the canonical way to build the 64-bit compiler. Did you forget to specify the native target? Just do CC=cc -xarch=v9 srcdir/configure sparc64-sun-solaris2.9 --prefix=xxx -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30769
[Bug c/29521] Confusing warning for return with expression in function returning void
--- Comment #3 from patchapp at dberlin dot org 2007-02-12 23:15 --- Subject: Bug number PR 29521 A patch for this bug has been added to the patch tracker. The mailing list url for the patch is http://gcc.gnu.org/ml/gcc-patches/2007-02/msg01110.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29521
[Bug fastjar/21822] fastjar/jartool.c's usage of MAXPATHLEN
--- Comment #6 from robilad at kaffe dot org 2007-02-12 23:38 --- thanks for the patch, I've checked it in at fastjar project on savannah. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21822
[Bug fortran/30554] [4.2 and 4.1 only] ICE in mio_pointer_ref at module.c:1945
--- Comment #14 from pault at gcc dot gnu dot org 2007-02-12 23:40 --- Subject: Bug 30554 Author: pault Date: Mon Feb 12 23:39:51 2007 New Revision: 121865 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=121865 Log: 2007-02-13 Paul Thomas [EMAIL PROTECTED] PR fortran/30554 * module.c (read_module): Set pointer_info to referenced if the symbol has no namespace. 2007-02-12 Paul Thomas [EMAIL PROTECTED] PR fortran/30554 * gfortran.dg/used_dummy_types_7.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/used_dummy_types_7.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/module.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30554
[Bug fastjar/13020] zip-style comments
--- Comment #6 from robilad at kaffe dot org 2007-02-12 23:47 --- I've checked in Wil's patch to the fastjar project's CVS on savannah. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13020
[Bug middle-end/29584] [4.0 Regression] internal compiler error on optimization
--- Comment #11 from reichelt at gcc dot gnu dot org 2007-02-13 00:02 --- Not fixed on the 4.0 branch, but fixed in GCC 4.1.2 and later. -- reichelt at gcc dot gnu dot org changed: What|Removed |Added CC||reichelt at gcc dot gnu dot ||org Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29584
[Bug libstdc++/21172] potential integer overflow error in STL heap functions
--- Comment #7 from paolo at gcc dot gnu dot org 2007-02-13 00:25 --- Subject: Bug 21172 Author: paolo Date: Tue Feb 13 00:25:30 2007 New Revision: 121875 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=121875 Log: 2007-02-12 Paolo Carlini [EMAIL PROTECTED] PR libstdc++/21172 * include/bits/stl_heap.h (__adjust_heap(_RandomAccessIterator, _Distance, _Distance, _Tp), __adjust_heap(_RandomAccessIterator, _Distance, _Distance, _Tp, _Compare)): Avoid potential integer overflow. * include/bits/stl_heap.h (__is_heap(_RandomAccessIterator, _RandomAccessIterator), __is_heap(_RandomAccessIterator, _RandomAccessIterator, _StrictWeakOrdering): Mark inline. (make_heap(_RandomAccessIterator, _RandomAccessIterator, _Compare)): Do not mark inline. * include/bits/stl_heap.h (push_heap(_RandomAccessIterator, _RandomAccessIterator), sort_heap(_RandomAccessIterator, _RandomAccessIterator)): Uncomment __glibcxx_requires_heap. Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/include/bits/stl_heap.h -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21172
[Bug libstdc++/21172] potential integer overflow error in STL heap functions
--- Comment #8 from pcarlini at suse dot de 2007-02-13 00:26 --- Fixed. -- pcarlini at suse dot de changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21172
[Bug c/29521] Confusing warning for return with expression in function returning void
--- Comment #4 from manu at gcc dot gnu dot org 2007-02-13 00:29 --- Subject: Bug 29521 Author: manu Date: Tue Feb 13 00:29:17 2007 New Revision: 121876 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=121876 Log: 2007-02-13 Manuel Lopez-Ibanez [EMAIL PROTECTED] PR c/29521 * c-typeck.c (c_finish_return): Improve warning message. testsuite/ * gcc.dg/c90-return-1.c: Update output. * gcc.dg/c99-return-1.c: Likewise. Added: trunk/gcc/testsuite/gcc.dg/pr29521-2.c trunk/gcc/testsuite/gcc.dg/pr29521.c Modified: trunk/gcc/ChangeLog trunk/gcc/c-typeck.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29521
[Bug c/30782] New: Error compiling SpiderMonkey.
1) Download GPAC extra_libs package from: gpac.sourceforge.net
2) Unpackage it and try to compile the SpiderMonkey library included in
extra_lib/js folder. Just go to that folder and execute make -f
Makefile.ref (as specified in extra_lib/ReadMe.
3) The result is:
gcc -o Linux_All_DBG.OBJ/jscpucfg.o -c -Wall -Wno-format -DGCC_OPT_BUG -g
-DXP_UNIX -DSVR4 -DSYSV -D_BSD_SOURCE -DPOSIX_SOURCE -DHAVE_LOCALTIME_R
-DX86_LINUX -DDEBUG -DDEBUG_rtubio -DEDITLINE -ILinux_All_DBG.OBJ jscpucfg.c
jscpucfg.c:360: internal compiler error: in dwarf2out_finish, at
dwarf2out.c:14129
Please submit a full bug report... etc
4) PREPROCESSED SOURCE:
I saved the file with the preprocessed source, but in this web interface of
bugzilla I do not know how to attach the file so, I just write it down here:
// /usr/lib/gcc/i486-linux-gnu/4.1.2/cc1 -quiet -ILinux_All_DBG.OBJ
-DGCC_OPT_BUG -DXP_UNIX -DSVR4 -DSYSV -D_BSD_SOURCE -DPOSIX_SOURCE
-DHAVE_LOCALTIME_R -DX86_LINUX -DDEBUG -DDEBUG_rtubio -DEDITLINE jscpucfg.c
-quiet -dumpbase jscpucfg.c -mtune=generic -auxbase-strip
Linux_All_DBG.OBJ/jscpucfg.o -g -Wall -Wno-format -fstack-protector
-fstack-protector -o - -frandom-seed=0
# 1 jscpucfg.c
# 1 /home/rtubio/Desktop/X3D/gpac/gpac/extra_lib/js//
# 1 built-in
# 1 command line
# 1 jscpucfg.c
# 39 jscpucfg.c
# 1 /usr/include/stdio.h 1 3 4
# 28 /usr/include/stdio.h 3 4
# 1 /usr/include/features.h 1 3 4
# 323 /usr/include/features.h 3 4
# 1 /usr/include/sys/cdefs.h 1 3 4
# 313 /usr/include/sys/cdefs.h 3 4
# 1 /usr/include/bits/wordsize.h 1 3 4
# 314 /usr/include/sys/cdefs.h 2 3 4
# 324 /usr/include/features.h 2 3 4
# 346 /usr/include/features.h 3 4
# 1 /usr/include/gnu/stubs.h 1 3 4
# 1 /usr/include/bits/wordsize.h 1 3 4
# 5 /usr/include/gnu/stubs.h 2 3 4
# 1 /usr/include/gnu/stubs-32.h 1 3 4
# 8 /usr/include/gnu/stubs.h 2 3 4
# 347 /usr/include/features.h 2 3 4
# 29 /usr/include/stdio.h 2 3 4
# 1 /usr/lib/gcc/i486-linux-gnu/4.1.2/include/stddef.h 1 3 4
# 214 /usr/lib/gcc/i486-linux-gnu/4.1.2/include/stddef.h 3 4
typedef unsigned int size_t;
# 35 /usr/include/stdio.h 2 3 4
# 1 /usr/include/bits/types.h 1 3 4
# 28 /usr/include/bits/types.h 3 4
# 1 /usr/include/bits/wordsize.h 1 3 4
# 29 /usr/include/bits/types.h 2 3 4
# 1 /usr/lib/gcc/i486-linux-gnu/4.1.2/include/stddef.h 1 3 4
# 32 /usr/include/bits/types.h 2 3 4
typedef unsigned char __u_char;
typedef unsigned short int __u_short;
typedef unsigned int __u_int;
typedef unsigned long int __u_long;
typedef signed char __int8_t;
typedef unsigned char __uint8_t;
typedef signed short int __int16_t;
typedef unsigned short int __uint16_t;
typedef signed int __int32_t;
typedef unsigned int __uint32_t;
__extension__ typedef signed long long int __int64_t;
__extension__ typedef unsigned long long int __uint64_t;
__extension__ typedef long long int __quad_t;
__extension__ typedef unsigned long long int __u_quad_t;
# 134 /usr/include/bits/types.h 3 4
# 1 /usr/include/bits/typesizes.h 1 3 4
# 135 /usr/include/bits/types.h 2 3 4
__extension__ typedef __u_quad_t __dev_t;
__extension__ typedef unsigned int __uid_t;
__extension__ typedef unsigned int __gid_t;
__extension__ typedef unsigned long int __ino_t;
__extension__ typedef __u_quad_t __ino64_t;
__extension__ typedef unsigned int __mode_t;
__extension__ typedef unsigned int __nlink_t;
__extension__ typedef long int __off_t;
__extension__ typedef __quad_t __off64_t;
__extension__ typedef int __pid_t;
__extension__ typedef struct { int __val[2]; } __fsid_t;
__extension__ typedef long int __clock_t;
__extension__ typedef unsigned long int __rlim_t;
__extension__ typedef __u_quad_t __rlim64_t;
__extension__ typedef unsigned int __id_t;
__extension__ typedef long int __time_t;
__extension__ typedef unsigned int __useconds_t;
__extension__ typedef long int __suseconds_t;
__extension__ typedef int __daddr_t;
__extension__ typedef long int __swblk_t;
__extension__ typedef int __key_t;
__extension__ typedef int __clockid_t;
__extension__ typedef void * __timer_t;
__extension__ typedef long int __blksize_t;
__extension__ typedef long int __blkcnt_t;
__extension__ typedef __quad_t __blkcnt64_t;
__extension__ typedef unsigned long int __fsblkcnt_t;
__extension__ typedef __u_quad_t __fsblkcnt64_t;
__extension__ typedef unsigned long int __fsfilcnt_t;
__extension__ typedef __u_quad_t __fsfilcnt64_t;
__extension__ typedef int __ssize_t;
typedef __off64_t __loff_t;
typedef __quad_t *__qaddr_t;
typedef char *__caddr_t;
__extension__ typedef int __intptr_t;
__extension__ typedef unsigned int __socklen_t;
# 37 /usr/include/stdio.h 2 3 4
typedef struct _IO_FILE FILE;
# 62 /usr/include/stdio.h 3 4
typedef struct _IO_FILE __FILE;
# 72 /usr/include/stdio.h 3 4
# 1 /usr/include/libio.h 1 3 4
# 32 /usr/include/libio.h 3 4
# 1 /usr/include/_G_config.h 1 3 4
# 14 /usr/include/_G_config.h 3 4
# 1 /usr/lib/gcc/i486-linux-gnu/4.1.2/include/stddef.h 1 3 4
# 326 /usr/lib/gcc/i486-linux-gnu/4.1.2/include/stddef.h
[Bug c/30782] Error compiling SpiderMonkey.
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-02-13 00:37 --- *** This bug has been marked as a duplicate of 26881 *** -- 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=30782
[Bug debug/26881] [4.1 Regression] internal compiler error in dwarf2out_finish
--- Comment #28 from pinskia at gcc dot gnu dot org 2007-02-13 00:37 --- *** Bug 30782 has been marked as a duplicate of this bug. *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||rtpardavila at gmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26881
[Bug tree-optimization/30735] 50% slow down due to mem-ssa merge
--- Comment #4 from dnovillo at gcc dot gnu dot org 2007-02-13 00:59 --- I have now reproduced this locally and I'm working on a fix. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30735
[Bug c/29521] Confusing warning for return with expression in function returning void
--- Comment #5 from manu at gcc dot gnu dot org 2007-02-13 01:52 --- Fixed in GCC 4.3 -- manu at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29521
[Bug c++/25868] [4.0 Regression] Multiple templates and typedefs cause function prototype not to match
--- Comment #11 from pinskia at gcc dot gnu dot org 2007-02-13 02:58 --- Fixed. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25868
[Bug target/27827] [4.0 Regression] gcc 4 produces worse x87 code on all platforms than gcc 3
--- Comment #70 from pinskia at gcc dot gnu dot org 2007-02-13 02:59 --- Fixed, 4.0 branch is now been closed. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27827
[Bug fortran/30780] cpu_time produces a floating point exception when used with -O0
--- Comment #3 from kargl at gcc dot gnu dot org 2007-02-13 04:26 --- troutmask:sgk[223] gfc4x -o z -g -ffpe-trap='precision' g.f90 troutmask:sgk[224] gdb ./z (gdb) run Starting program: /usr/home/sgk/tmp/z Program received signal SIGFPE, Arithmetic exception. 0x0040a3b2 in *_gfortrani_cpu_time_4 (time=0x7fffe988) at ../../../gcc4x/libgfortran/intrinsics/cpu_time.c:160 160 *time = sec + usec * (GFC_REAL_4)1.e-6; I have no idea how to fix this problem at the moment. This is on amd64-*-freebsd. -- kargl at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-02-13 04:26:26 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30780
[Bug libfortran/30780] cpu_time produces a floating point exception when used with -O0
--- Comment #4 from pinskia at gcc dot gnu dot org 2007-02-13 04:32 --- I have no idea how to fix this problem at the moment. It is hard as there are no functions which convert from a floating point to an integer that might not raise a signal. This is why setting trapping on precision is almost something you never want to do. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Component|fortran |libfortran http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30780
[Bug libfortran/30780] cpu_time produces a floating point exception when used with -O0
--- Comment #5 from jvdelisle at gcc dot gnu dot org 2007-02-13 05:41 --- I modified cpu_time_4 to just return some dummy values, and experimented a bit with the test case. When I commented out the print statement, the exception went away. Here is a reduced test case. program test2 real :: dog dog = 1.0 print *, dog end program test2 The exception is occurring in the print statement. Nothing to do with time. (gdb) r Starting program: /home/jerry/prs/pr30780/a.out Program received signal SIGFPE, Arithmetic exception. 0x2ab2c3d9 in write_float (dtp=0x7fff52698b00, f=0x7fff52698a50, source=value optimized out, len=value optimized out) at ../../../gcc43/libgfortran/io/write.c:366 366 if ((m 0.0 m 0.1 - 0.05 / exp_d) || (m = exp_d - 0.5 ) || -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30780
[Bug libfortran/30780] cpu_time produces a floating point exception when used with -O0
--- Comment #6 from kargl at gcc dot gnu dot org 2007-02-13 06:41 --- (In reply to comment #5) The exception is occurring in the print statement. Nothing to do with time. No, there is a problem in cpu_time. -ffpe-trap='precision' is trapping on lost precision. On x86_64, long is 64-bit and GFC_REAL_4 is 32-bit with only 24-bits of precision. You can't convert long to GFC_REAL_4 without loss of precision. In short, using this option is probably not a good idea if you have mixed mode math. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30780
[Bug fortran/29975] [meta-bugs] ICEs with CP2K
--- Comment #59 from pault at gcc dot gnu dot org 2007-02-13 06:56 --- (In reply to comment #58) Subject: Re: [meta-bugs] ICEs with CP2K jv244 at cam dot ac dot uk wrote: --- Comment #57 from jv244 at cam dot ac dot uk 2007-02-12 19:18 --- Yes, that's the one: http://gcc.gnu.org/ml/fortran/2007-02/msg00250.html for people reducing the bug, I found that it is in the module cp_fm_pool_types. This indicates the the line number indicated in the segfault would be wrong. Trying to reduce the testcase further, my automatic script got stuck on what is now PR 30779 OK Yours is one and the same as Daniel's. The backtrace makes that completely clear. The fix was posted to the list earlier on today. It is just now regtesting - I will commit it before I go to bed tonight. Thanks for bearing with us. Paul When you have a moment, could you confirm that all is now well with trunk, please? Once again, I am sorry about the breakage. Now I see Daniel's testcase, I realise that I could easily have devised a test... with 20:20 hindsight:) Paul -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29975
