[Bug middle-end/31127] [4.3 regression] ICE in cse_find_path, at cse.c:5930
--- Comment #2 from steven at gcc dot gnu dot org 2007-03-11 10:14 --- *** Bug 31116 has been marked as a duplicate of this bug. *** -- steven at gcc dot gnu dot org changed: What|Removed |Added CC||hp at gcc dot gnu dot org Bug 31127 depends on bug 31116, which changed state. Bug 31116 Summary: [4.3 regression] libstdc++ ext/pb_ds/regression/priority_queue_rand.cc http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31116 What|Old Value |New Value Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31127
[Bug middle-end/31116] [4.3 regression] libstdc++ ext/pb_ds/regression/priority_queue_rand.cc
--- Comment #4 from steven at gcc dot gnu dot org 2007-03-11 10:14 --- Same problem as PR31127. *** This bug has been marked as a duplicate of 31127 *** -- steven at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31116
[Bug middle-end/31127] [4.3 regression] ICE in cse_find_path, at cse.c:5930
-- steven at gcc dot gnu dot org changed: What|Removed |Added BugsThisDependsOn|31116 | Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-03-11 10:15:23 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31127
[Bug tree-optimization/25371] -ftree-vectorize results in internal compiler error on AMD64
--- Comment #6 from irar at il dot ibm dot com 2007-03-11 10:33 --- Harsha, could you please attach vectorizer's dump file (produced with -fdump-tree-vect-details)? Thanks, Ira -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25371
[Bug middle-end/31127] [4.3 regression] ICE in cse_find_path, at cse.c:5930
--- Comment #3 from steven at gcc dot gnu dot org 2007-03-11 11:01 --- Created an attachment (id=13188) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13188action=view) suggestion for what a fix may look like -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31127
[Bug middle-end/31115] [4.3 regression] libstdc++ 22_locale/num_get/get/char/2.cc 27_io/basic_ostream/inserters_arithmetic/char/6.cc
--- Comment #12 from rguenth at gcc dot gnu dot org 2007-03-11 11:27 --- Fixed. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31115
[Bug tree-optimization/31130] New: [4.3 Regression] VRP no longer derives range for division after negation
extern void link_error ();
void foo (int a)
{
if (a 0)
{
int y;
a = -a;
y = a / 7;
if (y 1 30)
link_error ();
}
}
int main()
{
return 0;
}
Before the VRP overflow handling changes we have after the first VRP pass:
Value ranges after VRP:
a_1(D): VARYING
a_2: [1, +INF] EQUIVALENCES: { } (0 elements)
y_3: [0, 306783378] EQUIVALENCES: { } (0 elements)
a_4: [-INF, -1] EQUIVALENCES: { a_1(D) } (1 elements)
Substituing values and folding statements
Folding predicate y_3 1073741824 to 0
Folded statement: if (y_3 1073741824) goto L1; else goto L2;
into: if (0) goto L1; else goto L2;
void foo(int) (a)
{
int y;
bb 2:
if (a_1(D) 0) goto L0; else goto L2;
L0:;
a_2 = -a_1(D);
y_3 = a_2 / 7;
L2:;
return;
}
while now we get
Value ranges after VRP:
a_1(D): VARYING
a_2: [1, +INF(OVF)] EQUIVALENCES: { } (0 elements)
y_3: [0, +INF(OVF)] EQUIVALENCES: { } (0 elements)
a_4: [-INF, -1] EQUIVALENCES: { a_1(D) } (1 elements)
Substituing values and folding statements
foo (a)
{
int y;
bb 2:
if (a_1(D) 0) goto L0; else goto L2;
L0:;
a_2 = -a_1(D);
y_3 = a_2 / 7;
if (y_3 1073741824) goto L1; else goto L2;
L1:;
link_error ();
L2:;
return;
}
without -Wstrict-overflow=N warning about the issues with signed negation
and the [1, +INF(OVF)] derived range. Note that the testcase is simple
enough that expansion optimizes the comparison, so it will not fail to link.
--
Summary: [4.3 Regression] VRP no longer derives range for
division after negation
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: normal
Priority: P3
Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: rguenth at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31130
[Bug c++/31131] New: [4.2/4.3 regression] ICE on invalid constructor definition
The following invalid code snippet triggers an ICE on mainline and 4.2 branch:
=
templateint struct A
{
A(int);
};
templateint N AN::A() {}
struct B
{
A0 a;
};
B b;
=
bug.cc:6: error: prototype for 'AN::A()' does not match any in class 'AN'
bug.cc:3: error: candidate is: AN::A(int)
bug.cc:6: error: template definition of non-template 'AN::A()'
bug.cc:13: internal compiler error: in locate_ctor, at cp/method.c:899
Please submit a full bug report, [etc.]
If I replace A(int); by A(0); I get a slightly different crash:
bug.cc:3: error: expected unqualified-id before numeric constant
bug.cc:3: error: expected `)' before numeric constant
bug.cc:6: error: no 'AN::A()' member function declared in class 'AN'
bug.cc:6: error: template definition of non-template 'AN::A()'
bug.cc:13: internal compiler error: vector VEC(tree,base) index domain error,
in locate_ctor at cp/method.c:889
Please submit a full bug report, [etc.]
--
Summary: [4.2/4.3 regression] ICE on invalid constructor
definition
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Keywords: ice-on-invalid-code, error-recovery, monitored
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: reichelt at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31131
[Bug c++/31131] [4.2/4.3 regression] ICE on invalid constructor definition
-- reichelt at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.2.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31131
[Bug c++/31132] New: [4.1/4.2/4.3 regression] ICE on inconsistent friend declaration
The following invalid code snippet triggers an ICE since GCC 3.4.0:
=
templatetypename T class A
{
static int i;
friend int T::foo();
};
struct B
{
void foo() { AB::i; }
};
=
bug.cc: In instantiation of 'AB':
bug.cc:9: instantiated from here
bug.cc:4: error: prototype for 'int B::foo()' does not match any in class 'B'
bug.cc:9: error: candidate is: void B::foo()
bug.cc:4: error: 'int B::foo()' cannot be overloaded
bug.cc:9: error: with 'void B::foo()'
bug.cc: In member function 'void B::foo()':
bug.cc:9: internal compiler error: tree check: expected record_type or
union_type or qual_union_type, have template_type_parm in template_class_depth,
at cp/pt.c:295
Please submit a full bug report, [etc.]
--
Summary: [4.1/4.2/4.3 regression] ICE on inconsistent friend
declaration
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Keywords: ice-on-invalid-code, error-recovery, monitored
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: reichelt at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31132
[Bug c++/31132] [4.1/4.2/4.3 regression] ICE on inconsistent friend declaration
-- reichelt at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.1.3 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31132
[Bug fortran/30883] procedure with dummy procedure f1 rejected with implicit none
--- Comment #5 from patchapp at dberlin dot org 2007-03-11 12:01 --- Subject: Bug number PR30883 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-03/msg00651.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30883
[Bug libstdc++/28080] header dependencies
--- Comment #25 from paolo at gcc dot gnu dot org 2007-03-11 12:03 --- Subject: Bug 28080 Author: paolo Date: Sun Mar 11 12:03:34 2007 New Revision: 122818 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=122818 Log: 2007-03-11 Paolo Carlini [EMAIL PROTECTED] PR libstdc++/28080 (final) * include/std/iosfwd: Do not include bits/c++io.h. * config/io/basic_file_stdio.h: Do it here. * include/ext/stdio_sync_filebuf.h: Likewise. * include/ext/rope: Include bits/gthr.h unconditionally. * include/std/fstream: Do not include bits/gthr.h. * include/std/ios: Do not include cstdio. * include/bits/ios_base.h: Do it here. * testsuite/27_io/ios_base/cons/assign_neg.cc: Adjust dg-error line numbers. * testsuite/27_io/ios_base/cons/copy_neg.cc: Likewise. Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/config/io/basic_file_stdio.h trunk/libstdc++-v3/include/bits/ios_base.h trunk/libstdc++-v3/include/ext/rope trunk/libstdc++-v3/include/ext/stdio_sync_filebuf.h trunk/libstdc++-v3/include/std/fstream trunk/libstdc++-v3/include/std/ios trunk/libstdc++-v3/include/std/iosfwd trunk/libstdc++-v3/testsuite/27_io/ios_base/cons/assign_neg.cc trunk/libstdc++-v3/testsuite/27_io/ios_base/cons/copy_neg.cc -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28080
[Bug libstdc++/28080] header dependencies
--- Comment #26 from pcarlini at suse dot de 2007-03-11 12:07 --- Now, for example, the preprocessed memory is about 100 KB smaller and there are noticeable improvements eveywhere (containers, streams, etc.). Also, thanks to variadic templates the compile-time performance and preprocessed header size for tr1/tuple and tr1/functional are hugely better than in 4_2-branch. I think we can consider this issue solved and further improvements considered proper enhancements not bug fixes. -- 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=28080
[Bug target/30980] [4.3 Regression] Recent complex miscompilation
--- Comment #9 from dominiq at lps dot ens dot fr 2007-03-11 12:19 --- I confirm that the bug does not show with gcc. Is theis related to the following failures in the regtest? FAIL: gcc.dg/builtins-59.c scan-tree-dump __builtin_cexpi FAIL: gcc.dg/builtins-59.c scan-tree-dump-not sincos FAIL: gcc.dg/builtins-61.c scan-tree-dump cexpi FAIL: gcc.dg/builtins-61.c scan-tree-dump sin FAIL: gcc.dg/builtins-61.c scan-tree-dump cos FAIL: gcc.dg/builtins-61.c scan-tree-dump return 0.0 FAIL: gcc.dg/builtins-62.c scan-tree-dump-times cexpi 3 Also the following fortran code complex(8) :: cplx, t real(8):: tmp cplx = cmplx(-1.0,0.0,8) t = log(cplx) tmp = 0.5 * imag(t) print *, cos(tmp), sin(tmp) end reproduces the bug. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30980
[Bug libstdc++/30915] [4.3 regression] bootstrap fails while building libstdc++-v3 on x86_64-pc-linux-gnu
--- Comment #4 from martin dot jansa at mk dot cvut dot cz 2007-03-11 12:20 --- (In reply to comment #3) Well Ahmed, right now you can't possibly see the exact same error, because stl_algobase.h does *not* include iosfwd anymore... Please provide more info. Thanks. My error seems quite similar (with profiledbootstrap and bootstrap too). Older snapshots have the same issue. I'm using latest glibc-2.5.90.20070214. /tmp/tmpwork/portage/sys-devel/gcc-4.3.0_alpha20070309/work/build/./gcc/xgcc -shared-libgcc -B/tmp/tmpwork/portage/sys-devel/gcc-4.3.0_alpha20070309/work/build/./gcc -nostdinc++ -L/tmp/tmpwork/portage/sys-devel/gcc-4.3.0_alpha20070309/work/build/x86_64-pc-linux-gnu/libstdc++-v3/src -L/tmp/tmpwork/portage/sys-devel/gcc-4.3.0_alpha20070309/work/build/x86_64-pc-linux-gnu/libstdc++-v3/src/.libs -B/usr/x86_64-pc-linux-gnu/bin/ -B/usr/x86_64-pc-linux-gnu/lib/ -isystem /usr/x86_64-pc-linux-gnu/include -isystem /usr/x86_64-pc-linux-gnu/sys-include -I/tmp/tmpwork/portage/sys-devel/gcc-4.3.0_alpha20070309/work/build/x86_64-pc-linux-gnu/libstdc++-v3/include/x86_64-pc-linux-gnu -I/tmp/tmpwork/portage/sys-devel/gcc-4.3.0_alpha20070309/work/build/x86_64-pc-linux-gnu/libstdc++-v3/include -I/tmp/tmpwork/portage/sys-devel/gcc-4.3.0_alpha20070309/work/gcc-4.3-20070309/libstdc++-v3/libsupc++ -fno-implicit-templates -Wall -Wextra -Wwrite-strings -Wcast-qual -fdiagnostics-show-location=once -ffunction-sections -fdata-sections -O2 -march=k8 -D_GNU_SOURCE -c /tmp/tmpwork/portage/sys-devel/gcc-4.3.0_alpha20070309/work/gcc-4.3-20070309/libstdc++-v3/src/compatibility.cc -fPIC -DPIC -o .libs/compatibility.o In file included from /tmp/tmpwork/portage/sys-devel/gcc-4.3.0_alpha20070309/work/build/x86_64-pc-linux-gnu/libstdc++-v3/include/bits/char_traits.h:49, from /tmp/tmpwork/portage/sys-devel/gcc-4.3.0_alpha20070309/work/build/x86_64-pc-linux-gnu/libstdc++-v3/include/string:47, from /tmp/tmpwork/portage/sys-devel/gcc-4.3.0_alpha20070309/work/gcc-4.3-20070309/libstdc++-v3/src/compatibility.cc:49: /tmp/tmpwork/portage/sys-devel/gcc-4.3.0_alpha20070309/work/build/x86_64-pc-linux-gnu/libstdc++-v3/include/cstdio:100: error: '::fpos_t' has not been declared /tmp/tmpwork/portage/sys-devel/gcc-4.3.0_alpha20070309/work/build/x86_64-pc-linux-gnu/libstdc++-v3/include/cstdio:102: error: '::clearerr' has not been declared /tmp/tmpwork/portage/sys-devel/gcc-4.3.0_alpha20070309/work/build/x86_64-pc-linux-gnu/libstdc++-v3/include/cstdio:103: error: '::fclose' has not been declared /tmp/tmpwork/portage/sys-devel/gcc-4.3.0_alpha20070309/work/build/x86_64-pc-linux-gnu/libstdc++-v3/include/cstdio:104: error: '::feof' has not been declared /tmp/tmpwork/portage/sys-devel/gcc-4.3.0_alpha20070309/work/build/x86_64-pc-linux-gnu/libstdc++-v3/include/cstdio:105: error: '::ferror' has not been declared /tmp/tmpwork/portage/sys-devel/gcc-4.3.0_alpha20070309/work/build/x86_64-pc-linux-gnu/libstdc++-v3/include/cstdio:106: error: '::fflush' has not been declared /tmp/tmpwork/portage/sys-devel/gcc-4.3.0_alpha20070309/work/build/x86_64-pc-linux-gnu/libstdc++-v3/include/cstdio:107: error: '::fgetc' has not been declared /tmp/tmpwork/portage/sys-devel/gcc-4.3.0_alpha20070309/work/build/x86_64-pc-linux-gnu/libstdc++-v3/include/cstdio:108: error: '::fgetpos' has not been declared /tmp/tmpwork/portage/sys-devel/gcc-4.3.0_alpha20070309/work/build/x86_64-pc-linux-gnu/libstdc++-v3/include/cstdio:109: error: '::fgets' has not been declared /tmp/tmpwork/portage/sys-devel/gcc-4.3.0_alpha20070309/work/build/x86_64-pc-linux-gnu/libstdc++-v3/include/cstdio:110: error: '::fopen' has not been declared /tmp/tmpwork/portage/sys-devel/gcc-4.3.0_alpha20070309/work/build/x86_64-pc-linux-gnu/libstdc++-v3/include/cstdio:111: error: '::fprintf' has not been declared /tmp/tmpwork/portage/sys-devel/gcc-4.3.0_alpha20070309/work/build/x86_64-pc-linux-gnu/libstdc++-v3/include/cstdio:112: error: '::fputc' has not been declared /tmp/tmpwork/portage/sys-devel/gcc-4.3.0_alpha20070309/work/build/x86_64-pc-linux-gnu/libstdc++-v3/include/cstdio:113: error: '::fputs' has not been declared /tmp/tmpwork/portage/sys-devel/gcc-4.3.0_alpha20070309/work/build/x86_64-pc-linux-gnu/libstdc++-v3/include/cstdio:114: error: '::fread' has not been declared /tmp/tmpwork/portage/sys-devel/gcc-4.3.0_alpha20070309/work/build/x86_64-pc-linux-gnu/libstdc++-v3/include/cstdio:115: error: '::freopen' has not been declared /tmp/tmpwork/portage/sys-devel/gcc-4.3.0_alpha20070309/work/build/x86_64-pc-linux-gnu/libstdc++-v3/include/cstdio:116: error: '::fscanf' has not been declared /tmp/tmpwork/portage/sys-devel/gcc-4.3.0_alpha20070309/work/build/x86_64-pc-linux-gnu/libstdc++-v3/include/cstdio:117: error: '::fseek' has not been declared /tmp/tmpwork/portage/sys-devel/gcc-4.3.0_alpha20070309/work/build/x86_64-pc-linux-gnu/libstdc++-v3/include/cstdio:118: error: '::fsetpos' has not been declared
[Bug libstdc++/30915] [4.3 regression] bootstrap fails while building libstdc++-v3 on x86_64-pc-linux-gnu
--- Comment #5 from martin dot jansa at mk dot cvut dot cz 2007-03-11 12:29 --- (In reply to comment #4) And my toolchain: jama gcc # /lib/libc.so.6 GNU C Library 20070214 release version 2.5.90, by Roland McGrath et al. Copyright (C) 2007 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. Compiled by GNU CC version 4.2.0-alpha20070228 (prerelease) (Gentoo 4.2.0_alpha20070228). Compiled on a Linux 2.6.20-JaMa system on 2007-03-05. Available extensions: C stubs add-on version 2.1.2 crypt add-on version 2.1 by Michael Glad and others Gentoo patchset 1.4.1 GNU Libidn by Simon Josefsson Native POSIX Threads Library by Ulrich Drepper et al Support for some architectures added on, not maintained in glibc core. BIND-8.2.3-T5B For bug reporting instructions, please see: http://www.gnu.org/software/libc/bugs.html. jama gcc # gcc --version x86_64-pc-linux-gnu-gcc (GCC) 4.2.0-alpha20070307 (prerelease) (Gentoo 4.2.0_alpha20070307) Copyright (C) 2007 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. jama gcc # make --version GNU Make 3.81 Copyright (C) 2006 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. This program built for x86_64-pc-linux-gnu jama gcc # as --version GNU assembler 2.17.50.0.12 20070128 Copyright 2005 Free Software Foundation, Inc. This program is free software; you may redistribute it under the terms of the GNU General Public License. This program has absolutely no warranty. This assembler was configured for a target of `x86_64-pc-linux-gnu'. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30915
[Bug libstdc++/30915] [4.3 regression] bootstrap fails while building libstdc++-v3 on x86_64-pc-linux-gnu
--- Comment #6 from pcarlini at suse dot de 2007-03-11 12:32 --- My error seems quite similar (with profiledbootstrap and bootstrap too). Older snapshots have the same issue. Thanks, but *how much* older, exactly, we must pin-point the exact source of this problem. I'm using latest glibc-2.5.90.20070214. Can you try with an official release. Really we need to reduce the number of independent variables, because, as far as I can see, at this point it can be anything, maybe glibc too. In the reports, on the C++ library side things don't make sense to me, frankly: cstdio just includes stdio.h and then there are the using from the global namespace. And of course nobody among the develepors is seeing the issue... I'm trying to CC Jakub as a glibc man, just in case... -- pcarlini at suse dot de changed: What|Removed |Added CC||jakub at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30915
[Bug libstdc++/30915] [4.3 regression] bootstrap fails while building libstdc++-v3 on x86_64-pc-linux-gnu
--- Comment #7 from pcarlini at suse dot de 2007-03-11 12:53 ---
People encountering this kind of problem should check whether this trivial C++
snippet compiles:
/
#include stdio.h
#undef clearerr
namespace my
{
using ::clearerr;
}
/
because really, in that place the build isn't doing much else...
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30915
[Bug middle-end/31030] [4.3 Regression] Segmentation fault with -O2
--- Comment #3 from dominiq at lps dot ens dot fr 2007-03-11 12:58 --- The following reduced test case PROGRAM LINPK PARAMETER (N=2500,LDA=N+1) DOUBLE PRECISION a(LDA,N) , b(N) , x(N) a = 1.0 print *, 'before DSCAL' CALL DSCAL(N-1,1.0D0,A(2,1),1) print *, 'after DSCAL' END SUBROUTINE DSCAL(N,Da,Dx,Incx) DOUBLE PRECISION Da , Dx(*) INTEGER i , Incx , m , mp1 , N , nincx ! print *, N, Da, Dx(MOD(N,5)+1), Incx IF ( N.GT.0 ) THEN mp1 = MOD(N,5) + 1 DO i = mp1 , N , 5 Dx(i) = Da*Dx(i) ENDDO ENDIF END shows the bug: [karma] lin/source% gfc -O2 linpk_red.f90 [karma] lin/source% a.out before DSCAL Bus error Looking at linpk_red.f90.116t.optimized, the loop in DSCAL reads L2:; D.1053 = (unnamed type) ivtmp.54; MEM[index: D.1053] = pretmp.36 * MEM[index: D.1053]; ivtmp.45 = ivtmp.45 + 1; ivtmp.54 = ivtmp.54 + 40; if (ivtmp.45 == 2147483647) goto L.4; else goto L2; I don't know the origin of 2147483647, but it looks pretty bad!-(even for me) Note that DSCAL appears in linpk.f90, rnflow.f90, and test_fpu.f90. PS this is my second attempt to post this, I apologize if the first one shows up later. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31030
[Bug libstdc++/30915] [4.3 regression] bootstrap fails while building libstdc++-v3 on x86_64-pc-linux-gnu
--- Comment #8 from pcarlini at suse dot de 2007-03-11 13:03 --- Then this snippet could be also useful, just in case we are doing something wrong in the configury (I doubt it) // #include stdio.h #include bits/c++config.h #undef clearerr _GLIBCXX_BEGIN_NAMESPACE(std) using ::clearerr; _GLIBCXX_END_NAMESPACE // -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30915
[Bug libstdc++/30915] [4.3 regression] bootstrap fails while building libstdc++-v3 on x86_64-pc-linux-gnu
--- Comment #9 from pcarlini at suse dot de 2007-03-11 13:05 --- Oh well, if the build really failed bits/c++config.h has not been installed, then include it from the exact place where is available in the build dir. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30915
[Bug libstdc++/30915] [4.3 regression] bootstrap fails while building libstdc++-v3 on x86_64-pc-linux-gnu
--- Comment #10 from pcarlini at suse dot de 2007-03-11 13:14 --- In c++config we have the below lines, which I never noriced before, I wonder whether can cause problems given the our current framework (in the future is another matter...) Note hovewer, that currently __cplusplus in the official GNU tree at least is still *1*. Is it possible that only *Gentoo* GCC has an external patch defining __cplusplus as 199711L??? Paolo. // Macro used to indicate that the native C includes, when compiled // as C++, have declarations in namespace std and not the global // namespace. Note, this is unrelated to possible C compatibility // includes that inject C90/C99 names into the global namespace. // XXX May not be necessary #if __cplusplus == 199711L # define _GLIBCXX_NAMESPACE_C 1 #endif -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30915
[Bug middle-end/31030] [4.3 Regression] Segmentation fault with -O2
--- Comment #4 from dominiq at lps dot ens dot fr 2007-03-11 13:16 ---
Note that the bug affect lapack/blas/{s,d}scal.f. Note also that in the
*optimized* dumps of
lapack/blas/{c,z}scal.f there are several:
Invalid sum of incoming frequencies , should be
cscal.f:
...
Invalid sum of incoming frequencies 2224, should be 2116
L19:;
D.1073 = (unnamed type) ivtmp.47;
CR.63 = MEM[index: D.1073];
CI.64 = MEM[index: D.1073, offset: 4];
MEM[index: D.1073] = CR.61 * CR.63 - CI.62 * CI.64;
MEM[index: D.1073, offset: 4] = CR.61 * CI.64 + CI.62 * CR.63;
ivtmp.44 = ivtmp.44 + 1;
ivtmp.47 = ivtmp.47 + 8;
if ((int4) ivtmp.44 == D.968) goto L14; else goto L19;
Invalid sum of incoming frequencies 2322, should be 2430
L14:;
return;
and zscal.f:
...
Invalid sum of incoming frequencies 10511, should be 1
L24:;
D.1095 = (unnamed type) ivtmp.59;
CR.21 = MEM[index: D.1095];
CI.22 = MEM[index: D.1095, offset: 8];
MEM[index: D.1095] = CR.64 * CR.21 - CI.65 * CI.22;
MEM[index: D.1095, offset: 8] = CR.64 * CI.22 + CI.65 * CR.21;
ivtmp.53 = ivtmp.53 + 1;
ivtmp.59 = ivtmp.59 + ivtmp.62;
if ((int4) ivtmp.53 == D.967) goto L16; else goto L24;
L29:;
CR.19 = REALPART_EXPR *za;
CI.20 = IMAGPART_EXPR *za;
ivtmp.50 = (unnamed type) REALPART_EXPR (*zx)[0];
ivtmp.47 = 0;
Invalid sum of incoming frequencies 4723, should be 4493
L23:;
D.1079 = (unnamed type) ivtmp.50;
CR.25 = MEM[index: D.1079];
CI.26 = MEM[index: D.1079, offset: 8];
MEM[index: D.1079] = CR.19 * CR.25 - CI.20 * CI.26;
MEM[index: D.1079, offset: 8] = CR.19 * CI.26 + CI.20 * CR.25;
ivtmp.47 = ivtmp.47 + 1;
ivtmp.50 = ivtmp.50 + 16;
if ((int4) ivtmp.47 == D.967) goto L16; else goto L23;
Invalid sum of incoming frequencies 4420, should be 5160
L16:;
return;
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31030
[Bug fortran/30883] procedure with dummy procedure f1 rejected with implicit none
-- 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|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-03-11 13:20:58 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30883
[Bug c/31133] New: allow to set sysroot via environment variable
I use gcc to cross compile a system with --sysroot option. However replace every gcc command with 'gcc --sysroot=blah' is kind of redundant. It would be great if I can set environment variable SYSROOT=blah (or GNUSYSROOT=blah) and leave gcc commands intact, just like CFLAGS and friends. -- Summary: allow to set sysroot via environment variable Product: gcc Version: unknown Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: pclouds at gmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31133
[Bug libstdc++/30915] [4.3 regression] bootstrap fails while building libstdc++-v3 on x86_64-pc-linux-gnu
--- Comment #11 from pcarlini at suse dot de 2007-03-11 13:26 --- (In reply to comment #10) Note hovewer, that currently __cplusplus in the official GNU tree at least is still *1*. Is it possible that only *Gentoo* GCC has an external patch defining __cplusplus as 199711L??? But that doesn't matter, because the newly built FSF GCC still defines __cplusplus as 1 (in licpp/init.c, by the way). I'm lost... We badly need details about the behavior of the two snippets, a time-range for the appearance of the problem, anything to restrict the number of possibilities... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30915
[Bug libstdc++/30915] [4.3 regression] bootstrap fails while building libstdc++-v3 on x86_64-pc-linux-gnu
--- Comment #12 from martin dot jansa at mk dot cvut dot cz 2007-03-11 13:36 --- (In reply to comment #11) Those 2 snippets working fine here and printf(%d,__cplusplus); says still 1. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30915
[Bug libstdc++/30915] [4.3 regression] bootstrap fails while building libstdc++-v3 on x86_64-pc-linux-gnu
--- Comment #13 from pcarlini at suse dot de 2007-03-11 13:46 --- Ok, can we know when exactly this bootstrap problem appeared? Nobody among the developers is seeing it, I repeat, we can't reproduce it, and if the submitters are not going to help more, much more, the problem cannot be fixed, this must be clear. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30915
[Bug tree-optimization/29925] Wrong code with -ftree-vectorize
--- Comment #10 from irar at gcc dot gnu dot org 2007-03-11 13:47 --- Subject: Bug 29925 Author: irar Date: Sun Mar 11 13:47:40 2007 New Revision: 122819 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=122819 Log: PR tree-optimization/29925 * tree-data-ref.c (analyze_offset): Add a return value (bool) to indicate success/failure of the analysis. Add negation to subtrahend in case of subtraction. Fail if both operands contain constants. (create_data_ref): Fail if analyze_offset fails. Added: branches/gcc-4_2-branch/gcc/testsuite/gcc.dg/vect/fast-math-vect-pr29925.c Modified: branches/gcc-4_2-branch/gcc/ChangeLog branches/gcc-4_2-branch/gcc/testsuite/ChangeLog branches/gcc-4_2-branch/gcc/tree-data-ref.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29925
[Bug libstdc++/30915] [4.3 regression] bootstrap fails while building libstdc++-v3 on x86_64-pc-linux-gnu
--- Comment #14 from martin dot jansa at mk dot cvut dot cz 2007-03-11 13:54 --- (In reply to comment #13) Ok, can we know when exactly this bootstrap problem appeared? Nobody among the developers is seeing it, I repeat, we can't reproduce it, and if the submitters are not going to help more, much more, the problem cannot be fixed, this must be clear. I cannot say *how much* older, because snapshots older than about 3 weeks failed with internal error (with profiledbootstrap) and with this error http://gcc.gnu.org/ml/gcc-patches/2006-02/msg00449.html (with bootstrap). Only last 3 weekly snapshots didn't fail until libstdc++ building. Maybe other submitters have better image when it firstly appeared, but as I said only few last weekly snapshots was trying to build libstdc++. I'm using latest glibc-2.5.90.20070214. I'm downgrading glibc to latest official release. I'm trying to CC Jakub as a glibc man, just in case... Thanks anyway -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30915
[Bug target/29255] [4.2/4.3 regression] ICE on valid code on PPC SPE
--- Comment #5 from jsm28 at gcc dot gnu dot org 2007-03-11 13:59 --- I can't reproduce this bug with current 4.2 branch or trunk. My guess as to the most likely patch to have fixed this is: 2006-11-16 Joseph Myers [EMAIL PROTECTED] * config/rs6000/spe.md (frob_di_df_2): Handle non-offsettable memory operand. -- jsm28 at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29255
[Bug middle-end/31127] [4.3 regression] ICE in cse_find_path, at cse.c:5930
--- Comment #4 from rguenth at gcc dot gnu dot org 2007-03-11 14:06 --- It also breaks FreeFEM. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC||rguenth at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31127
[Bug middle-end/31030] [4.3 Regression] Segmentation fault with -O2
--- Comment #5 from burnus at gcc dot gnu dot org 2007-03-11 14:07 --- Ian, looking at the changelog, it seems as if your commit http://gcc.gnu.org/viewcvs?view=revrevision=122487 r122487 | ian | 2007-03-02 21:09:31 +0100 (Fri, 02 Mar 2007) | 35 lines Used signed infinities in VRP. could be the cause of this problem. -- burnus at gcc dot gnu dot org changed: What|Removed |Added CC||ian at gcc dot gnu dot org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-03-11 14:07:33 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31030
[Bug target/29498] FTZ/DAZ for SSE should be ported to mingw32
--- Comment #3 from zuxy dot meng at gmail dot com 2007-03-11 14:27 --- Created an attachment (id=13189) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13189action=view) Updated patch -- zuxy dot meng at gmail dot com changed: What|Removed |Added Attachment #13151|0 |1 is obsolete|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29498
[Bug objc++/31134] New: objc-act.c:570: error: comparison is always false
/home/dave/gnu/gcc-4.3/objdir/./prev-gcc/xgcc -B/home/dave/gnu/gcc-4.3/objdir/./ prev-gcc/ -B/home/dave/opt/gnu/gcc/gcc-4.3.0/hppa-linux/bin/ -c -g -O2 -DIN_GC C -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -Wold-style-definiti on -Wmissing-format-attribute -Werror -DOBJCPLUS -I../../gcc/gcc/objc -I../../gc c/gcc/cp -fno-common -DHAVE_CONFIG_H -I. -Iobjcp -I../../gcc/gcc -I../../gcc/g cc/objcp -I../../gcc/gcc/../include -I../../gcc/gcc/../libcpp/include -I../../g cc/gcc/../libdecnumber -I../libdecnumber-I. -Iobjcp -I../../gcc/gcc -I../../ gcc/gcc/objcp -I../../gcc/gcc/../include -I../../gcc/gcc/../libcpp/include -I.. /../gcc/gcc/../libdecnumber -I../libdecnumber ../../gcc/gcc/objc/objc-act.c -o o bjcp/objcp-act.o cc1: warnings being treated as errors ../../gcc/gcc/objc/objc-act.c: In function 'lookup_method_in_protocol_list': ../../gcc/gcc/objc/objc-act.c:570: error: comparison is always false due to limi ted range of data type ../../gcc/gcc/objc/objc-act.c: In function 'lookup_protocol_in_reflist': ../../gcc/gcc/objc/objc-act.c:598: error: comparison is always false due to limi ted range of data type ../../gcc/gcc/objc/objc-act.c:605: error: comparison is always false due to limi ted range of data type ../../gcc/gcc/objc/objc-act.c: In function 'generate_protocol_references': ../../gcc/gcc/objc/objc-act.c:4443: error: comparison is always false due to lim ited range of data type ../../gcc/gcc/objc/objc-act.c: In function 'generate_protocol_list': ../../gcc/gcc/objc/objc-act.c:5457: error: comparison is always false due to lim ited range of data type ../../gcc/gcc/objc/objc-act.c:5465: error: comparison is always false due to lim ited range of data type ../../gcc/gcc/objc/objc-act.c:5478: error: comparison is always false due to lim ited range of data type ../../gcc/gcc/objc/objc-act.c:5487: error: comparison is always false due to lim ited range of data type ../../gcc/gcc/objc/objc-act.c: In function 'synth_id_with_class_suffix': ../../gcc/gcc/objc/objc-act.c:5834: error: comparison is always false due to lim ited range of data type ../../gcc/gcc/objc/objc-act.c: In function 'build_keyword_selector': ../../gcc/gcc/objc/objc-act.c:5910: error: comparison is always false due to lim ited range of data type ../../gcc/gcc/objc/objc-act.c:5930: error: comparison is always false due to lim ited range of data type ../../gcc/gcc/objc/objc-act.c: In function 'build_method_decl': ../../gcc/gcc/objc/objc-act.c:5967: error: comparison is always false due to lim ited range of data type ../../gcc/gcc/objc/objc-act.c: In function 'get_arg_type_list': ../../gcc/gcc/objc/objc-act.c:6003: error: comparison is always false due to lim ited range of data type ../../gcc/gcc/objc/objc-act.c: In function 'check_duplicates': ../../gcc/gcc/objc/objc-act.c:6087: error: comparison is always false due to lim ited range of data type ../../gcc/gcc/objc/objc-act.c:6093: error: comparison is always false due to lim ited range of data type ../../gcc/gcc/objc/objc-act.c: In function 'receiver_is_class_object': ../../gcc/gcc/objc/objc-act.c:6115: error: comparison is always false due to lim ited range of data type ../../gcc/gcc/objc/objc-act.c: In function 'build_ivar_reference': ../../gcc/gcc/objc/objc-act.c:6714: error: comparison is always false due to lim ited range of data type ../../gcc/gcc/objc/objc-act.c: In function 'objc_add_method': ../../gcc/gcc/objc/objc-act.c:6979: error: comparison is always false due to lim ited range of data type ../../gcc/gcc/objc/objc-act.c: In function 'conforms_to_protocol': ../../gcc/gcc/objc/objc-act.c:7294: error: comparison is always false due to lim ited range of data type ../../gcc/gcc/objc/objc-act.c: In function 'check_protocol': ../../gcc/gcc/objc/objc-act.c:7384: error: comparison is always false due to lim ited range of data type ../../gcc/gcc/objc/objc-act.c: In function 'synth_self_and_ucmd_args': ../../gcc/gcc/objc/objc-act.c:8319: error: comparison is always false due to lim ited range of data type ../../gcc/gcc/objc/objc-act.c: In function 'really_start_method': ../../gcc/gcc/objc/objc-act.c:8602: error: comparison is always false due to lim ited range of data type ../../gcc/gcc/objc/objc-act.c:8637: error: comparison is always false due to lim ited range of data type ../../gcc/gcc/objc/objc-act.c:8644: error: comparison is always false due to lim ited range of data type ../../gcc/gcc/objc/objc-act.c:8667: error: comparison is always false due to lim ited range of data type ../../gcc/gcc/objc/objc-act.c: In function 'get_super_receiver': ../../gcc/gcc/objc/objc-act.c:8714: error: comparison is always false due to lim ited range of data type ../../gcc/gcc/objc/objc-act.c:8736: error: comparison is always false due to lim ited range of data type ../../gcc/gcc/objc/objc-act.c:8750: error: comparison is always false due to lim ited range of data type ../../gcc/gcc/objc/objc-act.c: In
[Bug objc++/31134] objc-act.c:570: error: comparison is always false
--- Comment #1 from danglin at gcc dot gnu dot org 2007-03-11 14:42 --- Occurs in stage2. [EMAIL PROTECTED]:~/gnu/gcc-4.3/objdir/prev-gcc$ ./xgcc -B./ -v Reading specs from ./specs Target: hppa-linux Configured with: ../gcc/configure --with-gnu-as --with-gnu-ld --enable-shared --prefix=/home/dave/opt/gnu/gcc/gcc-4.3.0 --with-local-prefix=/home/dave/opt/gnu --enable-threads=posix --enable-__cxa_atexit --build=hppa-linux --enable-clocale=gnu --enable-java-gc=boehm --enable-java-awt=xlib --enable-languages=c,c++,objc,fortran,java,obj-c++,ada Thread model: posix gcc version 4.3.0 20070310 (experimental) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31134
[Bug objc++/31134] objc-act.c:570: error: comparison is always false
--- Comment #2 from schwab at suse dot de 2007-03-11 15:02 --- The limit on the number of tree codes is reached (LAST_CPLUS_TREE_CODE = 251, LAST_OBJC_TREE_CODE = 262). -- schwab at suse dot de changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 GCC build triplet|hppa-unknown-linux-gnu | GCC host triplet|hppa-unknown-linux-gnu | GCC target triplet|hppa-unknown-linux-gnu | Keywords||build Last reconfirmed|-00-00 00:00:00 |2007-03-11 15:02:59 date|| Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31134
[Bug bootstrap/31118] Bootstrap failure: darwin.c:1188: error: too many arguments to function 'categorize_decl_for_section
--- Comment #2 from lucier at math dot purdue dot edu 2007-03-11 15:56 --- Fixed [descartes:~/programs/gcc/objdir-mainline] gcc-test% cat ../mainline/LAST_UPDATED Sat Mar 10 22:35:54 EST 2007 Sun Mar 11 03:35:54 UTC 2007 (revision 122814M) -- lucier at math dot purdue dot edu changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31118
[Bug middle-end/31115] [4.3 regression] libstdc++ 22_locale/num_get/get/char/2.cc 27_io/basic_ostream/inserters_arithmetic/char/6.cc
--- Comment #13 from rguenth at gcc dot gnu dot org 2007-03-11 16:08 --- Subject: Bug 31115 Author: rguenth Date: Sun Mar 11 16:08:35 2007 New Revision: 122821 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=122821 Log: 2007-03-11 Richard Guenther [EMAIL PROTECTED] PR tree-optimization/31115 * tree-vrp.c (extract_range_from_binary_expr): Make sure the shift count is positive and non-anti-range for RSHIFT_EXPR. A shift count of zero is not special as with *_DIV_EXPR. (vrp_int_const_binop): Handle RSHIFT_EXPR for determining overflow direction. * gcc.dg/torture/pr31115.c: New testcase. Added: trunk/gcc/testsuite/gcc.dg/torture/pr31115.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-vrp.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31115
[Bug fortran/30883] procedure with dummy procedure f1 rejected with implicit none
--- Comment #6 from pault at gcc dot gnu dot org 2007-03-11 16:17 --- Subject: Bug 30883 Author: pault Date: Sun Mar 11 16:17:32 2007 New Revision: 122822 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=122822 Log: 2007-03-11 Paul Thomas [EMAIL PROTECTED] PR fortran/30883 * parse.c (parse_interface): Use the default types from the formal namespace if a function or its result do not have a type after parsing the specification statements. 2007-03-11 Paul Thomas [EMAIL PROTECTED] PR fortran/30883 * gfortran.dg/interface_11.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/interface_11.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/parse.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30883
[Bug c/31135] New: ice for legal code with -O3
I just tried to compile Suse Linux package rasmol-2.7.3.1-44 with the GNU C++ compiler version 4.3 snapshot 20070309. The compiler said repres.c: In function 'InitialiseRepres': repres.c:1638: internal compiler error: in cse_find_path, at cse.c:5930 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. Flag -O3 required. -- Summary: ice for legal code with -O3 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=31135
[Bug c/31135] ice for legal code with -O3
--- Comment #1 from dcb314 at hotmail dot com 2007-03-11 16:19 --- Created an attachment (id=13190) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13190action=view) C source code -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31135
[Bug target/26090] IA-64 creates DT_TEXTREL binaries
--- Comment #5 from rth at gcc dot gnu dot org 2007-03-11 16:22 --- Fixed. -- rth at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26090
[Bug driver/31133] allow to set sysroot via environment variable
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-03-11 17:09 --- just like CFLAGS and friends Well CFLAGS is a make file and nothing to do with GCC really. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Component|c |driver http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31133
[Bug middle-end/31135] [4.3 Regression] ice for legal code with -O3
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Component|c |middle-end GCC host triplet|x86_64-suse-linux | GCC target triplet||x86_64-suse-linux-gnu Summary|ice for legal code with -O3 |[4.3 Regression] ice for ||legal code with -O3 Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31135
[Bug middle-end/31135] [4.3 Regression] ice for legal code with -O3
--- Comment #2 from pinskia at gcc dot gnu dot org 2007-03-11 17:15 --- *** This bug has been marked as a duplicate of 31127 *** -- 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=31135
[Bug middle-end/31127] [4.3 regression] ICE in cse_find_path, at cse.c:5930
--- Comment #5 from pinskia at gcc dot gnu dot org 2007-03-11 17:15 --- *** Bug 31135 has been marked as a duplicate of this bug. *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||dcb314 at hotmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31127
[Bug driver/31133] allow to set sysroot via environment variable
--- Comment #2 from pclouds at gmail dot com 2007-03-11 17:26 --- Ahh.. I made a mistake, sorry for the annoyance. -- pclouds at gmail dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31133
[Bug middle-end/30798] mode_dependent_address_p not checked when simplifying subreg
--- Comment #2 from TabonyEE at austin dot rr dot com 2007-03-11 18:28 --- Hhmm. I have made a few other changes and now when I don't define WORD_REGISTER_OPERATIONS, I get correct code. I get an HI load followed by a QI - SI zero extend, not the preferred POST_MODIFY. I looked at all the changes I made since my last comment and I don't see how any could affect this. I think this is a latent bug waiting to be exposed that for some reason is difficult to trigger. Now combine creates the subreg, but the subreg is spilled during the greg pass. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30798
[Bug tree-optimization/31136] New: FRE ignores bit-field truncation
With the tip of the 4.2 branch, the following program returns 1. Mainline
returns 0. Is this defined behavior? I could not find anything on the
subject.
struct S {
unsigned b4:4;
unsigned b6:6;
} s;
int main(void){
s.b6 = 31;
s.b4 = s.b6;
s.b6 = s.b4;
return s.b6 == 15 ? 0 : 1;
}
before FRE (-fdump-tree-ccp):
;; Function main (main)
main ()
{
short unsigned int D.1882;
short unsigned int D.1881;
int D.1880;
unnamed type D.1879;
unnamed type D.1878;
unnamed type D.1877;
unnamed type D.1876;
bb 2:
s.b6 = 31;
D.1876_3 = s.b6;
D.1877_4 = (unnamed type) D.1876_3;
s.b4 = D.1877_4;
D.1878_7 = s.b4;
D.1879_8 = (unnamed type) D.1878_7;
s.b6 = D.1879_8;
D.1881_10 = BIT_FIELD_REF s, 16, 0;
D.1882_11 = D.1881_10 1008;
D.1880_12 = D.1882_11 != 240;
return D.1880_12;
}
after FRE (-fdump-tree-fre):
;; Function main (main)
main ()
{
short unsigned int D.1882;
short unsigned int D.1881;
int D.1880;
unnamed type D.1879;
unnamed type D.1878;
unnamed type D.1877;
unnamed type D.1876;
bb 2:
s.b6 = 31;
D.1876_3 = 31;
D.1877_4 = (unnamed type) D.1876_3;
s.b4 = D.1877_4;
D.1878_7 = D.1877_4;
D.1879_8 = 31;
s.b6 = D.1879_8;
D.1881_10 = BIT_FIELD_REF s, 16, 0;
D.1882_11 = D.1881_10 1008;
D.1880_12 = D.1882_11 != 240;
return D.1880_12;
}
D.1879_8 was replaced by 31, ignoring the fact that the value should have been
truncated to 15 when assigned to s.b4.
--
Summary: FRE ignores bit-field truncation
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: TabonyEE at austin dot rr 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=31136
[Bug middle-end/30816] gfortran.dg/g77/intrinsic-unix-erf.f tests fail with optimization
--- Comment #18 from tobi at gcc dot gnu dot org 2007-03-11 18:53 --- The tests no longer fail, even with the system gmp/mpfr (which haven't been updated), so I'm closing this as WORKSFORME. -- tobi at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||WORKSFORME http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30816
[Bug fortran/29651] Subroutine: Kind convertion of intent(out) value: signal
--- Comment #3 from dfranke at gcc dot gnu dot org 2007-03-11 18:54 --- Taking care of this one as the solution is probably the same as with ALARM (PR30947). -- 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|2006-10-31 05:36:37 |2007-03-11 18:54:23 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29651
[Bug middle-end/30798] mode_dependent_address_p not checked when simplifying subreg
--- Comment #3 from TabonyEE at austin dot rr dot com 2007-03-11 18:57 --- By the way, I think emit-rtl.c: change_address_1 could at least use an assert that if the modes are different and the addresses are the same, then mode_dependent_address_p is not true. That is unless change_address_1 can be used to change the semantics of a mem. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30798
[Bug fortran/31067] MINLOC should sometimes be inlined (gas_dyn is sooooo sloooow)
--- Comment #9 from tkoenig at gcc dot gnu dot org 2007-03-11 19:43 ---
I have looked at this some more. Channging gfc_conv_intrinsic_function so that
we call gfc_conv_intrinsic_minmaxloc is easy enough:
@@ -3481,7 +3481,9 @@ gfc_conv_intrinsic_function (gfc_se * se
name = expr-value.function.name[2];
- if (expr-rank 0 !expr-inline_noncopying_intrinsic)
+ if (expr-rank 0 !expr-inline_noncopying_intrinsic
+ ! (expr-rank == 1 (isym-generic_id == GFC_ISYM_MINLOC
+ || isym-generic_id == GFC_ISYM_MAXLOC)))
{
lib = gfc_is_intrinsic_libcall (expr);
if (lib != 0)
If we do that, we hit the if (se-ss) contition on top of that function, and
we would have to handle scalarization of that one-trip loop. I have currently
no idea how to go about that. Simply removing the condition doesn't work :-)
As a workaround, one could always use minloc(...,dim=1), then
we get the inline version.
Unassigning myself.
--
tkoenig at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|tkoenig at gcc dot gnu dot |unassigned at gcc dot gnu
|org |dot org
Status|ASSIGNED|NEW
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31067
[Bug c++/31038] [4.1/4.2/4.3 regression] ICE with C99 style compound literal vs templates vs instiaiontion
-- mmitchel at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |mark at codesourcery dot com |dot org | Status|NEW |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31038
[Bug c++/31131] [4.2/4.3 regression] ICE on invalid constructor definition
-- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P4 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31131
[Bug c++/31132] [4.1/4.2/4.3 regression] ICE on inconsistent friend declaration
-- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P4 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31132
[Bug c++/30857] [4.1/4.2/4.3 regression] accepts both explicit instantiation and explicit specialization, duplicate explicit instantiations, etc.
-- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30857
[Bug libstdc++/30915] [4.3 regression] bootstrap fails while building libstdc++-v3 on x86_64-pc-linux-gnu
--- Comment #15 from martin dot jansa at mk dot cvut dot cz 2007-03-11 20:35 --- (In reply to comment #14) downgrading glibc didn't that trick but now() I have successfully builded latest snapshot with this patch: --- ./gcc-4.3-20070309/libstdc++-v3/include/c_global/cstdio.orig 2007-03-11 20:12:59.0 +0100 +++ ./gcc-4.3-20070309/libstdc++-v3/include/c_global/cstdio 2007-03-11 20:14:00.0 +0100 @@ -46,7 +46,7 @@ #include bits/c++config.h #include cstddef -#include_next stdio.h +#include /usr/include/gentoo-multilib/amd64/stdio.h #ifndef _GLIBCXX_CSTDIO #define _GLIBCXX_CSTDIO 1 There is list of \*stdio\* in build directory: ./build/gcc/include-fixed/stdio.h ./build/x86_64-pc-linux-gnu/libstdc++-v3/include/tr1/stdio.h ./build/x86_64-pc-linux-gnu/libstdc++-v3/include/tr1/cstdio ./build/x86_64-pc-linux-gnu/libstdc++-v3/include/ext/stdio_sync_filebuf.h ./build/x86_64-pc-linux-gnu/libstdc++-v3/include/ext/stdio_filebuf.h ./build/x86_64-pc-linux-gnu/libstdc++-v3/include/cstdio ./build/x86_64-pc-linux-gnu/libstdc++-v3/docs/doxygen/man/man3/__gnu_cxx::stdio_sync_filebuf.3 ./build/x86_64-pc-linux-gnu/libstdc++-v3/docs/doxygen/man/man3/__gnu_cxx::stdio_filebuf.3 ./build/x86_64-pc-linux-gnu/libstdc++-v3/docs/doxygen/xml/cstdio.xml ./build/x86_64-pc-linux-gnu/libstdc++-v3/docs/doxygen/xml/classgnu__cxx_1_1stdio__filebuf.xml ./build/x86_64-pc-linux-gnu/libstdc++-v3/docs/doxygen/xml/stdio__filebuf_8h.xml ./build/x86_64-pc-linux-gnu/libstdc++-v3/docs/doxygen/xml/stdio_8h.xml ./build/x86_64-pc-linux-gnu/libstdc++-v3/docs/doxygen/xml/classgnu__cxx_1_1stdio__sync__filebuf.xml ./build/x86_64-pc-linux-gnu/libstdc++-v3/docs/doxygen/xml/tr1_2cstdio.xml ./build/x86_64-pc-linux-gnu/libstdc++-v3/docs/doxygen/xml/stdio__sync__filebuf_8h.xml ./build/x86_64-pc-linux-gnu/32/libstdc++-v3/include/tr1/stdio.h ./build/x86_64-pc-linux-gnu/32/libstdc++-v3/include/tr1/cstdio ./build/x86_64-pc-linux-gnu/32/libstdc++-v3/include/ext/stdio_sync_filebuf.h ./build/x86_64-pc-linux-gnu/32/libstdc++-v3/include/ext/stdio_filebuf.h ./build/x86_64-pc-linux-gnu/32/libstdc++-v3/include/cstdio ./build/stage1-gcc/include-fixed/stdio.h ./build/prev-gcc/include-fixed/stdio.h ./gcc-4.3-20070309/gcc/testsuite/gcc.dg/cpp/usr/include/stdio.h ./gcc-4.3-20070309/libstdc++-v3/config/io/basic_file_stdio.cc ./gcc-4.3-20070309/libstdc++-v3/config/io/c_io_stdio.h ./gcc-4.3-20070309/libstdc++-v3/config/io/basic_file_stdio.h ./gcc-4.3-20070309/libstdc++-v3/testsuite/tr1/8_c_compatibility/cstdio ./gcc-4.3-20070309/libstdc++-v3/testsuite/27_io/ios_base/sync_with_stdio ./gcc-4.3-20070309/libstdc++-v3/testsuite/27_io/headers/cstdio ./gcc-4.3-20070309/libstdc++-v3/testsuite/ext/stdio_filebuf ./gcc-4.3-20070309/libstdc++-v3/testsuite/ext/stdio_sync_filebuf ./gcc-4.3-20070309/libstdc++-v3/include/c_std/cstdio ./gcc-4.3-20070309/libstdc++-v3/include/tr1/stdio.h ./gcc-4.3-20070309/libstdc++-v3/include/tr1/cstdio ./gcc-4.3-20070309/libstdc++-v3/include/c_global/cstdio ./gcc-4.3-20070309/libstdc++-v3/include/ext/stdio_sync_filebuf.h ./gcc-4.3-20070309/libstdc++-v3/include/ext/stdio_filebuf.h ./gcc-4.3-20070309/libstdc++-v3/include/c_compatibility/stdio.h ./gcc-4.3-20070309/libstdc++-v3/include/c/cstdio ./gcc-4.3-20070309/fixincludes/tests/base/stdio_tag.h ./gcc-4.3-20070309/fixincludes/tests/base/stdio.h ./gcc-4.3-20070309/libssp/ssp/stdio.h -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30915
[Bug middle-end/30433] [4.1/4.2 Regression] no longer folding __complex__(0.0, 1.0) == __complex__(1.0, 0.0)
--- Comment #5 from sayle at gcc dot gnu dot org 2007-03-11 20:37 --- Subject: Bug 30433 Author: sayle Date: Sun Mar 11 20:37:40 2007 New Revision: 122823 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=122823 Log: 2007-03-11 Roger Sayle [EMAIL PROTECTED] Andrew Pinski [EMAIL PROTECTED] PR middle-end/30433 * fold-const.c (fold_relational_const): Add back compile-time evaluation of complex constant equality/inequality comparisons. * gcc.c-torture/compile/pr30433.c: New testcase to check that complex constant comparisions are folded. Added: branches/gcc-4_2-branch/gcc/testsuite/gcc.c-torture/compile/pr30433.c Modified: branches/gcc-4_2-branch/gcc/ChangeLog branches/gcc-4_2-branch/gcc/fold-const.c branches/gcc-4_2-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30433
[Bug tree-optimization/31130] [4.3 Regression] VRP no longer derives range for division after negation
--- Comment #1 from ian at airs dot com 2007-03-11 20:39 ---
I am testing this patch.
Index: gcc/tree-vrp.c
===
--- gcc/tree-vrp.c (revision 122820)
+++ gcc/tree-vrp.c (working copy)
@@ -2142,13 +2142,11 @@ extract_range_from_unary_expr (value_ran
min = fold_unary_to_constant (code, TREE_TYPE (expr), vr0.max);
else if (needs_overflow_infinity (TREE_TYPE (expr)))
{
- if (supports_overflow_infinity (TREE_TYPE (expr)))
- min = positive_overflow_infinity (TREE_TYPE (expr));
- else
- {
- set_value_range_to_varying (vr);
- return;
- }
+ /* Negating TYPE_MIN_VALUE gives us a minimum value of
+positive overflow infinity, and there is nothing useful
+we can do with such a range. */
+ set_value_range_to_varying (vr);
+ return;
}
else
min = TYPE_MIN_VALUE (TREE_TYPE (expr));
@@ -2161,8 +2159,16 @@ extract_range_from_unary_expr (value_ran
max = fold_unary_to_constant (code, TREE_TYPE (expr), vr0.min);
else if (needs_overflow_infinity (TREE_TYPE (expr)))
{
- if (supports_overflow_infinity (TREE_TYPE (expr)))
- max = positive_overflow_infinity (TREE_TYPE (expr));
+ /* We have a non-overflowed TYPE_MIN as the minimum value.
+If TYPE_MIN is also the maximum value, then negating this
+gives us a positive overflow, and we just go straight to
+varying since we will get there anyhow at the bottom of
+this function. Otherwise TYPE_MIN is a half-range
+[TYPE_MIN, X] without overflow, so we flip it to a
+half-range [-X, TYPE_MAX] without overflow. */
+ if (vr0.max != TYPE_MIN_VALUE (TREE_TYPE (expr))
+ !is_negative_overflow_infinity (vr0.max))
+ max = TYPE_MAX_VALUE (TREE_TYPE (expr));
else
{
set_value_range_to_varying (vr);
--
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-03-11 20:39:57
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31130
[Bug middle-end/31030] [4.3 Regression] Segmentation fault with -O2
--- Comment #6 from ian at airs dot com 2007-03-11 20:46 --- Can you see if the patch I committed this morning fixes this problem? 2007-03-11 Ian Lance Taylor [EMAIL PROTECTED] * tree-vrp.c (vrp_int_const_binop): Handle PLUS_EXPR and the *_DIV_EXPR codes correctly with overflow infinities. Thanks. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31030
[Bug target/31137] New: missing break in switch for MULT in avr_rtx_costs
I have just started reading the gcc code a bit, and while looking at the avr
port I noticed that in the function avr_rtx_costs in avr.c there is some code
to calculate the cost of a multiplication:
case MULT:
switch (mode)
{
case QImode:
if (AVR_HAVE_MUL)
*total = COSTS_N_INSNS (optimize_size ? 3 : 4);
else if (optimize_size)
*total = COSTS_N_INSNS (AVR_MEGA ? 2 : 1);
else
return false;
case HImode:
if (AVR_HAVE_MUL)
*total = COSTS_N_INSNS (optimize_size ? 7 : 10);
else if (optimize_size)
*total = COSTS_N_INSNS (AVR_MEGA ? 2 : 1);
else
return false;
default:
return false;
}
*total += avr_operand_rtx_cost (XEXP (x, 0), mode, code);
*total += avr_operand_rtx_cost (XEXP (x, 1), mode, code);
return true;
if AVR_HAVE_MUL is true, the above code will be equal to the following:
case MULT:
switch (mode)
{
case QImode:
*total = COSTS_N_INSNS (optimize_size ? 3 : 4);
case HImode:
*total = COSTS_N_INSNS (optimize_size ? 7 : 10);
default:
return false;
}
*total += avr_operand_rtx_cost (XEXP (x, 0), mode, code);
*total += avr_operand_rtx_cost (XEXP (x, 1), mode, code);
return true;
which I belive is incorrect since it means that the assignments to *total in
the switch statement are useless. It probably doesn't break anything serious
but might give slightly worse optimizations.
--
Summary: missing break in switch for MULT in avr_rtx_costs
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: christer at weinigel dot se
GCC build triplet: i686-pc-linux-gnu
GCC host triplet: i686-pc-linux-gnu
GCC target triplet: avr-unknown-none
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31137
[Bug libstdc++/30915] [4.3 regression] bootstrap fails while building libstdc++-v3 on x86_64-pc-linux-gnu
--- Comment #16 from pcarlini at suse dot de 2007-03-11 21:20 --- I see, weird, I'm going to add Benjamin in CC, he added very recently the c_global files and I'm not familiar with #include_next... -- pcarlini at suse dot de changed: What|Removed |Added CC||bkoz at redhat dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30915
[Bug fortran/31051] gfortran bug with x and t format descriptors.
--- Comment #2 from jvdelisle at gcc dot gnu dot org 2007-03-11 21:28 --- A patch has been submiited for approval for this one. -- jvdelisle at gcc dot gnu dot org changed: What|Removed |Added GCC host triplet|wtf does 'host triplet' |i686-pc-linux-gnu |mean? | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31051
[Bug middle-end/31030] [4.3 Regression] Segmentation fault with -O2
--- Comment #7 from burnus at gcc dot gnu dot org 2007-03-11 21:42 --- Can you see if the patch I committed this morning fixes this problem? http://gcc.gnu.org/ml/gcc-patches/2007-03/msg00664.html Yes, the patch fixes this problem. Thanks! -- burnus at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31030
[Bug c++/31138] New: [4.3 regression] ICE with ellipsis
The following valid code snippet triggers an ICE on mainline: = void foo(long ...); = bug.cc:1: internal compiler error: Segmentation fault Please submit a full bug report, [etc.] The same thing happens for the following invalid variation: = void foo(const ...); = -- Summary: [4.3 regression] ICE with ellipsis Product: gcc Version: 4.3.0 Status: UNCONFIRMED Keywords: ice-on-valid-code, ice-on-invalid-code, monitored Severity: normal Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: reichelt at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31138
[Bug c++/31138] [4.3 regression] ICE with ellipsis
-- reichelt at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31138
[Bug ada/31108] [4.2 regression] ACATS C35507M fails
--- Comment #2 from rolf dot ebert dot gcc at gmx dot de 2007-03-11 22:17 --- I have to rerun the ACATS tests with more disk space available. After the C3 tests all other failures were due to disk full. Currently c35507m is the only failure in 4.2 on MinGW that I know of. But as I said, I did not yet run the complete test suite. Had the fix for PR 26797 been back-ported to the 4.2 branch? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31108
[Bug middle-end/30835] ICE with -O2 -ftree-loop-linear
-- rakdver at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |rakdver at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2007-02-17 20:24:42 |2007-03-11 22:31:17 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30835
[Bug fortran/31139] New: sum(w_re(1:nn,1)*fi(i(1:nn, ii))) up to 3.5x slower than C version
The problem came up with octopus, http://www.tddft.org/programs/octopus/ http://www.tddft.org/pipermail/octopus-devel/2007-March/003398.html (Somehow, all my messages are not archived?) The problem is that sum(w_re(1:nn,1)*fi(i(1:nn, ii))) can be much slower. For the original program, one finds the following timings: Core 2 Duo + gfortan + gcc (v. 4.1.x), total cpu time: SSE2 120 s PLAIN C 160 s FORTRAN 331 s (Fortran = assumed shape arrays) * * * I tried to reproduce this with a smaller test case (see attachment) - and with explicit shape arrays. Here, SSE and non-SSE version made little difference. Result for gcc/gfortran 4.3.0 20070311 on an Athlon 64 X2 4800+. -O3 -march=opteron -funroll-loops -msse3 -ftree-vectorize -m64: Fortran: 0.8240519, real0m7.661s, user0m7.232s Fortran: 0.8240528, real0m7.654s, user0m7.232s c_nosse: 0.2320137, real0m7.071s, user0m6.652s c_nosse: 0.2320151, real0m7.062s, user0m6.672s -O3 -march=opteron -msse3 -ftree-vectorize -m32: Fortran: 0.3840241, real0m7.714s, user0m7.280s Fortran: 0.3840246, real0m7.701s, user0m7.328s c_nosse: 0.3480220, real0m7.687s, user0m7.256s c_nosse: 0.3400207, real0m7.670s, user0m7.236s And with ifort/x86-64: gcc -std=c99 -O3 -funroll-loops -ftree-vectorize -march=opteron -msse3 -m64 ifort -xW -O3 Fortran: 0.3280210, real0m0.855s, user0m0.624s Fortran: 0.3280210, real0m0.856s, user0m0.624s c_nosse: 0.2320140, real0m0.753s, user0m0.492s c_nosse: 0.2280150, real0m0.756s, user0m0.464s and with ifort/ia32: Fortran: 0.3000200, real0m0.818s, user0m0.516s Fortran: 0.2960190, real0m0.826s, user0m0.528s c_nosse: 0.3760230, real0m0.904s, user0m0.652s c_nosse: 0.3800240, real0m0.902s, user0m0.624s I did no yet check which of the problems are Fortran, Backend and Target problems. Summary: - GCC -m32 is much slower than -m64 - gfortran is slower (-m32) / much slower (-m64) than the C version - ifort is faster than gfortran and similarly fast on both -m32 and -m64. -- Summary: sum(w_re(1:nn,1)*fi(i(1:nn, ii))) up to 3.5x slower than C version Product: gcc Version: 4.3.0 Status: UNCONFIRMED Keywords: missed-optimization Severity: enhancement Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: burnus at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31139
[Bug fortran/31139] sum(w_re(1:nn,1)*fi(i(1:nn, ii))) up to 3.5x slower than C version
--- Comment #1 from burnus at gcc dot gnu dot org 2007-03-11 22:45 --- Contains the test case. The hand-made SSE version (USE_VECTORS) crashes here for -m32, but as it is C vs. Fortran, one can completely ignore that test case (for -m64 USE_VECTORS is about as fast as the other C versions anyhow). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31139
[Bug fortran/31139] sum(w_re(1:nn,1)*fi(i(1:nn, ii))) up to 3.5x slower than C version
--- Comment #2 from burnus at gcc dot gnu dot org 2007-03-11 22:50 --- Created an attachment (id=13191) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13191action=view) test.tar.gz -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31139
[Bug objc++/31134] [4.3 Regression] Objective-C++ has ran into the tree number limit
--- Comment #3 from dave at hiauly1 dot hia dot nrc dot ca 2007-03-11 22:53 --- Subject: Re: [4.3 Regression] Objective-C++ has ran into the tree number limit Summary|objc-act.c:570: error: |[4.3 Regression] Objective- |comparison is always false |C++ has ran into the tree ||number limit Don't like to name people, but I suppose this patch should be reverted: 2007-03-09 Douglas Gregor [EMAIL PROTECTED] PR c++/20599 * typeck.c (check_return_expr): Check for bare parameter packs. (comptypes): Compare template parameter packs and type pack expansions. ... Dave -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31134
[Bug c++/31140] New: [4.3 regression] ICE with ellipsis in template parameter list
The following invalid code snippet triggers an ICE on mainline:
templatetypename T... void foo()
{
T t;
}
bug.cc:1: error: expected nested-name-specifier before 'T'
bug.cc:1: error: ISO C++ does not include variadic templates
bug.cc: In function 'void foo()':
bug.cc:3: error: expected `;' before 't'
bug.cc:3: error: parameter packs not expanded with `...':
bug.cc:3: internal compiler error: tree check: expected tree that contains
'decl minimal' structure, have 'template_parm_index' in
check_for_bare_parameter_packs, at cp/pt.c:2620
Please submit a full bug report, [etc.]
Looks like this was caused by your patch for variadic templates, Douglas:
2007-03-09 Douglas Gregor [EMAIL PROTECTED]
PR c++/20599
* typeck.c (check_return_expr): Check for bare parameter packs.
(comptypes): Compare template parameter packs and
type pack expansions.
...
--
Summary: [4.3 regression] ICE with ellipsis in template parameter
list
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Keywords: ice-on-invalid-code, error-recovery, monitored
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: reichelt at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31140
[Bug c++/31140] [4.3 regression] ICE with ellipsis in template parameter list
-- reichelt at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31140
[Bug c++/31141] New: [4.3 regression] ICE with ellipsis in template parameter list
The following invalid code snippet triggers an ICE on mainline:
templateint N... void foo(int x[1][N]);
void bar()
{
int x[1][1];
foo(x);
}
bug.cc:1: error: ISO C++ does not include variadic templates
bug.cc: In function 'void bar()':
bug.cc:1: internal compiler error: tree check: expected class 'expression',
have 'constant' (integer_cst) in tsubst_pack_expansion, at cp/pt.c:6829
Please submit a full bug report, [etc.]
Looks like this was caused by your patch for variadic templates, Douglas:
2007-03-09 Douglas Gregor [EMAIL PROTECTED]
PR c++/20599
* typeck.c (check_return_expr): Check for bare parameter packs.
(comptypes): Compare template parameter packs and
type pack expansions.
...
--
Summary: [4.3 regression] ICE with ellipsis in template parameter
list
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Keywords: ice-on-invalid-code, monitored
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: reichelt at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31141
[Bug c++/31141] [4.3 regression] ICE with ellipsis in template parameter list
-- reichelt at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31141
[Bug c++/31138] [4.3 regression] ICE with ellipsis
--- Comment #1 from reichelt at gcc dot gnu dot org 2007-03-11 23:01 --- I guess this is also related to your patch for variadic templates, Douglas, but I might be wrong: 2007-03-09 Douglas Gregor [EMAIL PROTECTED] PR c++/20599 * typeck.c (check_return_expr): Check for bare parameter packs. (comptypes): Compare template parameter packs and type pack expansions. ... -- reichelt at gcc dot gnu dot org changed: What|Removed |Added CC||doug dot gregor at gmail dot ||com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31138
[Bug c++/31138] [4.3 regression] ICE with ellipsis
--- Comment #2 from pinskia at gcc dot gnu dot org 2007-03-11 23:19 --- How is the first one valid? I thought you always needed a comma before the ellipsis for variable argument functions (I know in C you need it for sure). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31138
[Bug bootstrap/31142] New: Build with CC='gcc -pg' fails
Configuring with ../configure --enable-languages=c,fortran --with-gmp=/sw CC='gcc -pg' and optionally --disable-botstrap fails with # @multilib_dir@ is not really necessary, but sometimes it has # more uses than just a directory name. /bin/sh ../../../../libgcc/../mkinstalldirs x86_64 /Users/tobi/src/pristine/profile/./gcc/xgcc -B/Users/tobi/src/pristine/profile /gcc/ -B/usr/local/i386-apple-darwin8.8.3/bin/ -B/usr/local/i386-apple-darwin8 .3/lib/ -isystem /usr/local/i386-apple-darwin8.8.3/include -isystem /usr/local 386-apple-darwin8.8.3/sys-include -O2 -O2 -g -O2 -DIN_GCC-W -Wall -Wwrit strings -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -isys m ./include -fPIC -pipe -g -DHAVE_GTHR_DEFAULT -DIN_LIBGCC2 -D__GCC_FLOAT_NOT EEDED -dynamiclib -nodefaultlibs -install_name /usr/local/lib/libgcc_s`if tes x86_64 = ppc64 ; then echo _x86_64 ; fi`.1.dylib -single_module -o x86_64/libg _s.1.dylib.tmp -Wl,-exported_symbols_list,libgcc.map -compatibility_version 1 urrent_version 1.0 -g -fkeep-inline-functions -m64 -B./ _muldi3_s.o _negdi2_s. _lshrdi3_s.o _ashldi3_s.o _ashrdi3_s.o _cmpdi2_s.o _ucmpdi2_s.o _clear_cache_s _enable_execute_stack_s.o _trampoline_s.o __main_s.o _absvsi2_s.o _absvdi2_s. _addvsi3_s.o _addvdi3_s.o _subvsi3_s.o _subvdi3_s.o _mulvsi3_s.o _mulvdi3_s.o egvsi2_s.o _negvdi2_s.o _ctors_s.o _ffssi2_s.o _ffsdi2_s.o _clz_s.o _clzsi2_s. _clzdi2_s.o _ctzsi2_s.o _ctzdi2_s.o _popcount_tab_s.o _popcountsi2_s.o _popcou di2_s.o _paritysi2_s.o _paritydi2_s.o _powisf2_s.o _powidf2_s.o _powixf2_s.o _ witf2_s.o _mulsc3_s.o _muldc3_s.o _mulxc3_s.o _multc3_s.o _divsc3_s.o _divdc3_ o _divxc3_s.o _divtc3_s.o _bswapsi2_s.o _bswapdi2_s.o _fixunssfsi_s.o _fixunsd i_s.o _fixunsxfsi_s.o _fixsfdi_s.o _fixdfdi_s.o _fixxfdi_s.o _fixtfdi_s.o _fix ssfdi_s.o _fixunsdfdi_s.o _fixunsxfdi_s.o _fixunstfdi_s.o _floatdisf_s.o _floa idf_s.o _floatdixf_s.o _floatditf_s.o _floatundisf_s.o _floatundidf_s.o _float dixf_s.o _floatunditf_s.o _fixsfti_s.o _fixdfti_s.o _fixxfti_s.o _fixtfti_s.o ixunssfti_s.o _fixunsdfti_s.o _fixunsxfti_s.o _fixunstfti_s.o _floattisf_s.o _ oattidf_s.o _floattixf_s.o _floattitf_s.o _floatuntisf_s.o _floatuntidf_s.o _f atuntixf_s.o _floatuntitf_s.o _divdi3_s.o _moddi3_s.o _udivdi3_s.o _umoddi3_s. _udiv_w_sdiv_s.o _udivmoddi4_s.o darwin-64_s.o unwind-dw2_s.o unwind-dw2-fde-d win_s.o unwind-sjlj_s.o unwind-c_s.o emutls_s.o -lc i686-apple-darwin8-gcc-4.0.1: 1: No such file or directory i686-apple-darwin8-gcc-4.0.1: 1.0: No such file or directory i686-apple-darwin8-gcc-4.0.1: /usr/local/lib/libgcc_s.1.dylib: No such file or irectory i686-apple-darwin8-gcc-4.0.1: 10.4: No such file or directory collect2: ld returned 1 exit status make[5]: *** [libgcc_s.dylib] Error 1 make[4]: *** [multi-do] Error 1 make[3]: *** [all-multi] Error 2 make[2]: *** [all-stage1-target-libgcc] Error 2 make[1]: *** [stage1-bubble] Error 2 make: *** [all] Error 2 [1]- Donexchat (wd: ~) (wd now: ~/src/pristine/profile) tobias-schluters-computer:~/src/pristine/profile tobi$ -- Summary: Build with CC='gcc -pg' fails Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: tobi at gcc dot gnu dot org GCC host triplet: i386-darwin http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31142
[Bug bootstrap/31142] Build with CC='gcc -pg' fails
--- Comment #1 from tobi at gcc dot gnu dot org 2007-03-11 23:23 --- A few version numbers: tobias-schluters-computer:~/src/pristine/profile tobi$ make --version GNU Make 3.80 Copyright (C) 2002 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. tobias-schluters-computer:~/src/pristine/profile tobi$ ld -v Apple Computer, Inc. version cctools-622.3.obj~2 tobias-schluters-computer:~/src/pristine/profile tobi$ gcc -v Using built-in specs. Target: i686-apple-darwin8 Configured with: /private/var/tmp/gcc/gcc-5363.obj~28/src/configure --disable-checking -enable-werror --prefix=/usr --mandir=/share/man --enable-languages=c,objc,c++,obj-c++ --program-transform-name=/^[cg][^.-]*$/s/$/-4.0/ --with-gxx-include-dir=/include/c++/4.0.0 --with-slibdir=/usr/lib --build=powerpc-apple-darwin8 --with-arch=nocona --with-tune=generic --program-prefix= --host=i686-apple-darwin8 --target=i686-apple-darwin8 Thread model: posix gcc version 4.0.1 (Apple Computer, Inc. build 5363) tobias-schluters-computer:~/src/pristine/profile tobi$ -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31142
[Bug target/31142] Build with CC='gcc -pg' fails
--- Comment #2 from pinskia at gcc dot gnu dot org 2007-03-11 23:24 --- --disable-botstrap does not work on the mainline after toplevel libgcc. Also if you are doing profiling on Darwin, can I suggest you use Shark which is part of the CHUD tools from Apple. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Component|bootstrap |target GCC host triplet|i386-darwin | GCC target triplet||i386-darwin http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31142
[Bug objc++/31134] [4.3 Regression] Objective-C++ has ran into the tree number limit
--- Comment #4 from pcarlini at suse dot de 2007-03-11 23:48 --- (In reply to comment #3) Don't like to name people, but I suppose this patch should be reverted: Please, please, don't do that! Instead, let's solve the real issue with the tree-codes limit once and for all, because sooner or later we have to do that anyway (as Rth, among others, also maintained time ago, in the occasion of the GOMP additions) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31134
[Bug c++/31138] [4.3 regression] ICE with ellipsis
--- Comment #3 from schwab at suse dot de 2007-03-11 23:51 --- In C++ the comma before ... is optional. Where syntactically correct, #8220;, ...#8221; is synonymous with #8220;...#8221;. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31138
[Bug c++/30328] [4.2/4.3 Regression] bit-field: unassemblable assembly code
--- Comment #2 from mmitchel at gcc dot gnu dot org 2007-03-12 00:26 --- Subject: Bug 30328 Author: mmitchel Date: Mon Mar 12 00:26:39 2007 New Revision: 122829 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=122829 Log: PR c++/30328 * semantics.c (finish_typeof): Use unlowered_expr_type. PR c++/30328 * g++.dg/ext/bitfield1.C: New test. PR c++/31038 * parser.c (cp_parser_postfix_expression): Disallow compound literals in constant expressions. PR c++/31038 * g++.dg/template/complit2.C: New test. Added: trunk/gcc/testsuite/g++.dg/ext/bitfield1.C trunk/gcc/testsuite/g++.dg/template/complit2.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/parser.c trunk/gcc/cp/semantics.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30328
[Bug c++/31038] [4.1/4.2/4.3 regression] ICE with C99 style compound literal vs templates vs instiaiontion
--- Comment #3 from mmitchel at gcc dot gnu dot org 2007-03-12 00:26 --- Subject: Bug 31038 Author: mmitchel Date: Mon Mar 12 00:26:39 2007 New Revision: 122829 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=122829 Log: PR c++/30328 * semantics.c (finish_typeof): Use unlowered_expr_type. PR c++/30328 * g++.dg/ext/bitfield1.C: New test. PR c++/31038 * parser.c (cp_parser_postfix_expression): Disallow compound literals in constant expressions. PR c++/31038 * g++.dg/template/complit2.C: New test. Added: trunk/gcc/testsuite/g++.dg/ext/bitfield1.C trunk/gcc/testsuite/g++.dg/template/complit2.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/parser.c trunk/gcc/cp/semantics.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31038
[Bug objc++/31134] [4.3 Regression] Objective-C++ has ran into the tree number limit
--- Comment #5 from dave at hiauly1 dot hia dot nrc dot ca 2007-03-12 00:55 --- Subject: Re: [4.3 Regression] Objective-C++ has ran into the tree number limit Don't like to name people, but I suppose this patch should be reverted: Please, please, don't do that! Instead, let's solve the real issue with the tree-codes limit once and for all, because sooner or later we have to do that anyway (as Rth, among others, also maintained time ago, in the occasion of the GOMP additions) I recognize that the patch contains a very significant body of work. I also realize that the tree code limit needs fixing. However, that may require a significant increase in memory for trees. That's why I added the comment. It's not fair to trade one feature for another (variadic templates for obj-c++). There's been no discussion on the impact of fixing the tree code limit. I note that a 15% compile time memory usage regression, http://gcc.gnu.org/ml/gcc-patches/2007-03/msg00652.html, would be considered a release blocker. The patch was obviously not fully tested, or the problem was overlooked. As a backend maintainer, I've seen build and check times grow substantially with every new release. So, I'm highly suspicious of the process used to introduce major new features. The tree code limit should have been fixed first. Dave -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31134
[Bug objc++/31134] [4.3 Regression] Objective-C++ has ran into the tree number limit
--- Comment #6 from pcarlini at suse dot de 2007-03-12 01:04 --- It's not fair to trade one feature for another (variadic templates for obj-c++). I agree. There's been no discussion on the impact of fixing the tree code limit. I note that a 15% compile time memory usage regression, http://gcc.gnu.org/ml/gcc-patches/2007-03/msg00652.html, would be considered a release blocker. By the way, that issue has been already analyzed and seems solvable rather easily, Doug is working on it with Richard' help. The patch was obviously not fully tested, or the problem was overlooked. As a backend maintainer, I've seen build and check times grow substantially with every new release. So, I'm highly suspicious of the process used to introduce major new features. The tree code limit should have been fixed first. Yes, you have a point. But now, since because of our lazyness we never managed to attack the tree code limit, let's take this crisis as an occasion to do that, or at least let's try to our best, instead of reverting completely Doug' work, which is incredibly important for our implementation of C++0x features and, I would say, gives GCC a great competitive advantage. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31134
[Bug c/21438] Warning about division by zero depends on lexical form
--- Comment #4 from patchapp at dberlin dot org 2007-03-12 01:32 --- Subject: Bug number PR 21438 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-03/msg00700.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21438
[Bug c++/30328] [4.2 Regression] bit-field: unassemblable assembly code
--- Comment #3 from mmitchel at gcc dot gnu dot org 2007-03-12 01:32 --- Fixed in 4.3.0. -- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Summary|[4.2/4.3 Regression] bit- |[4.2 Regression] bit-field: |field: unassemblable|unassemblable assembly code |assembly code | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30328
[Bug c++/31038] [4.1/4.2 regression] ICE with C99 style compound literal vs templates vs instiaiontion
--- Comment #4 from mmitchel at gcc dot gnu dot org 2007-03-12 01:34 --- Fixed in 4.3.0. -- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Summary|[4.1/4.2/4.3 regression] ICE|[4.1/4.2 regression] ICE |with C99 style compound |with C99 style compound |literal vs templates vs |literal vs templates vs |instiaiontion |instiaiontion http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31038
[Bug c++/31038] [4.1/4.2 regression] ICE with C99 style compound literal vs templates vs instiaiontion
--- Comment #5 from mmitchel at gcc dot gnu dot org 2007-03-12 01:52 --- Subject: Bug 31038 Author: mmitchel Date: Mon Mar 12 01:52:45 2007 New Revision: 122830 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=122830 Log: PR c++/31038 * parser.c (cp_parser_postfix_expression): Disallow compound literals in constant expressions. PR c++/30328 * semantics.c (finish_typeof): Use unlowered_expr_type. PR c++/31038 * g++.dg/template/complit2.C: New test. PR c++/30328 * g++.dg/ext/bitfield1.C: New test. Added: branches/gcc-4_2-branch/gcc/testsuite/g++.dg/ext/bitfield1.C branches/gcc-4_2-branch/gcc/testsuite/g++.dg/template/complit2.C Modified: branches/gcc-4_2-branch/gcc/cp/ChangeLog branches/gcc-4_2-branch/gcc/cp/parser.c branches/gcc-4_2-branch/gcc/cp/semantics.c branches/gcc-4_2-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31038
[Bug c++/30328] [4.2 Regression] bit-field: unassemblable assembly code
--- Comment #4 from mmitchel at gcc dot gnu dot org 2007-03-12 01:52 --- Subject: Bug 30328 Author: mmitchel Date: Mon Mar 12 01:52:45 2007 New Revision: 122830 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=122830 Log: PR c++/31038 * parser.c (cp_parser_postfix_expression): Disallow compound literals in constant expressions. PR c++/30328 * semantics.c (finish_typeof): Use unlowered_expr_type. PR c++/31038 * g++.dg/template/complit2.C: New test. PR c++/30328 * g++.dg/ext/bitfield1.C: New test. Added: branches/gcc-4_2-branch/gcc/testsuite/g++.dg/ext/bitfield1.C branches/gcc-4_2-branch/gcc/testsuite/g++.dg/template/complit2.C Modified: branches/gcc-4_2-branch/gcc/cp/ChangeLog branches/gcc-4_2-branch/gcc/cp/parser.c branches/gcc-4_2-branch/gcc/cp/semantics.c branches/gcc-4_2-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30328
[Bug c++/30328] [4.2 Regression] bit-field: unassemblable assembly code
--- Comment #5 from mmitchel at gcc dot gnu dot org 2007-03-12 01:53 --- Fixed in 4.2.0. -- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30328
[Bug rtl-optimization/31143] New: bad argument passing on ARM
The attached code produces wrong-code on gcc-4.1.1 and gcc-4.1.2 on ARM. These codes are snippet from linux kernel, and this was found when linux v2.6.19 was built with gcc-4.1.1 with CONFIG_PRINK_TIME=y is set for ARM. $ arm-linux-gcc -O2 -c div64.S $ arm-linux-gcc -O2 -save-temps dodiv.c div64.o -o dodiv actual result: $ ./dodiv tbuf: 4[ 52.305419] expected result: tbuf: 4[0.305419] when compiled with -fno-tree-ter, the result was OK. The problem comes from bad argument passing to sprintf(), looking from dodiv.s: ... mov r2, r5 (1) mov ip, ip, lsr #6 mov r3, r5 (2) ldr r1, .L10+8 mov r0, r4 str ip, [sp, #0] bl sprintf Where (1) is loglev_char argument and (2) is (unsigned long)t argument in sprintf() in dodiv.c. Apparently, the loglev_char is also assigned to the first %5lu part of sprintf, which is the cause. -- Summary: bad argument passing on ARM Product: gcc Version: 4.1.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: rtl-optimization AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: kaminaga at sm dot sony dot co dot jp GCC target triplet: arm-*-linux http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31143
[Bug rtl-optimization/31143] bad argument passing on ARM
--- Comment #1 from kaminaga at sm dot sony dot co dot jp 2007-03-12 04:16 --- Created an attachment (id=13192) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13192action=view) code snippet to reproduce wrong code -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31143
[Bug rtl-optimization/31143] bad argument passing on ARM
--- Comment #2 from kaminaga at sm dot sony dot co dot jp 2007-03-12 04:27 --- Currently having bugzilla's Internal Error in attaching div64.S... -- kaminaga at sm dot sony dot co dot jp changed: What|Removed |Added Keywords||wrong-code http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31143
[Bug fortran/31144] New: Gfortran module names are not Standards compliant
Fortran Standards require that module symbol names are unique for a given module and procedure name pair. Gfortran uses an underscore prefix to prevent collisions with non-module procedures, but the double-underscore used to join the module and procedure name in not sufficient to ensure a unique symbol name. The following code snippet illustrates the problem: module m1 contains subroutine m2__m3() end subroutine m2__m3 end module m1 module m1__m2 contains subroutine m3() end subroutine m3 end module m1__m2 Compiling this code under gfortran produces a duplicate symbol error in the assembly code. The name pair should be joined with character(s) that cannot occur as part of a normal fortran name, either by using upper case (i.e. G95's _MP_) or some other character (I think one compiler uses a period). To be fair, a conflict is unlikely, and Intel Fortran has an equally broken system of module symbol names. But, the current Gfortran mechanism is clearly wrong, and should be changed the next time a binary incompatibility occurs that requires code to be recompiled anyhow. -- Summary: Gfortran module names are not Standards compliant Product: gcc Version: 4.1.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: jkrahn at nc dot rr dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31144
