[Bug fortran/29837] INTERFACE overloading INTENT problem - valid code is rejected
--- Comment #4 from pault at gcc dot gnu dot org 2006-11-16 08:01 ---
This is due to a trivial error in:
Index: /svn/trunk/gcc/fortran/interface.c
===
*** /svn/trunk/gcc/fortran/interface.c (revision 118704)
--- /svn/trunk/gcc/fortran/interface.c (working copy)
*** compare_actual_formal (gfc_actual_arglis
*** 1379,1386
(f-sym-attr.intent == INTENT_OUT
|| f-sym-attr.intent == INTENT_INOUT))
{
! gfc_error (Actual argument at %L must be definable to
!match dummy INTENT = OUT/INOUT, a-expr-where);
return 0;
}
--- 1383,1391
(f-sym-attr.intent == INTENT_OUT
|| f-sym-attr.intent == INTENT_INOUT))
{
! if (where)
! gfc_error (Actual argument at %L must be definable to
! match dummy INTENT = OUT/INOUT, a-expr-where);
return 0;
}
I will submit the patch and a testcase just as soon as I have a moment this
afternoon.
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|UNCONFIRMED |ASSIGNED
Ever Confirmed|0 |1
Last reconfirmed|-00-00 00:00:00 |2006-11-16 08:01:03
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29837
[Bug rtl-optimization/29864] New: Folding conversion unsigned long long to float
In Funktion expand_float the libcall generated for a conversion from unsigned long long to float gets a wrong EQUIV note. See line optabs.c:4712 in the 4.3-2006 snapshot. The equiv note is set to gen_rtx_FLOAT regardless of the unsignedp flag. When that flag is set, it should be a gen_rtx_UNSIGNED_FLOAT note. The error is also present in 4.2. In 4.1 it was hidden because the code was only executed with unsignedp being false. I found the problem while working on a private port. I do not have a confirmed testcase for a public port. The problem surfaced when GCSE eliminated the libcall using the note for the conversion. -- Summary: Folding conversion unsigned long long to float Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: rtl-optimization AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: Erwin dot Unruh at fujitsu-siemens dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29864
[Bug libfortran/29866] New: building libgfortran fails because of kinds.h
/bin/sh ../.././libgfortran/mk-kinds-h.sh Here is the last message displayed by make: '/home/jp/src/gcc-4.2-20061114/host-x86_64-unknown-linux-gnu/gcc/gfortran -B/home/jp/src/gcc-4.2-20061114/host-x86_64-unknown-linux-gnu/gcc/ -B/usr/local/x86_64-unknown-linux-gnu/bin/ -B/usr/local/x86_64-unknown-linux-gnu/lib/ -isystem /usr/local/x86_64-unknown-linux-gnu/include -isystem /usr/local/x86_64-unknown-linux-gnu/sys-include -I . -Wall -fno-repack-arrays -fno-underscoring ' kinds.h || rm kinds.h ../.././libgfortran/mk-kinds-h.sh: Unknown type grep '^#' kinds.h kinds.inc /bin/sh: kinds.h: Aucun fichier ou répertoire de ce type (this is the french message for no such file or directory if I run mk-kinds-h.sh separately, I get: sh mk-kinds-h.sh #define GFC_INTEGER_LARGEST GFC_INTEGER_ #define GFC_UINTEGER_LARGEST GFC_UINTEGER_ mk-kinds-h.sh: Unknown type I work on an amd64 machine (dual opteron) with Suse Linux 10.1 previous versions of gcc-4.2 (before 20061107 ) had no such problem. -- Summary: building libgfortran fails because of kinds.h Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libfortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: Jean-pierre dot vial at wanadoo dot fr GCC build triplet: host-x86_64-unknown-linux-gnu GCC host triplet: host-x86_64-unknown-linux-gnu GCC target triplet: host-x86_64-unknown-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29866
[Bug libfortran/29867] New: building libgfortran fails because of multiple definitions gcc-4.3-20061111
linking libgfortran fails becaus of multiple definitions. Here are le last lines of error messages. there are several hundred such lines /usr/include/stdlib.h:342: multiple definition of `strtoul' .libs/environ.o:/usr/include/stdlib.h:342: first defined here .libs/in_unpack_generic.o: In function `strtol': /usr/include/stdlib.h:336: multiple definition of `strtol' .libs/environ.o:/usr/include/stdlib.h:336: first defined here .libs/in_unpack_generic.o: In function `strtod': /usr/include/stdlib.h:330: multiple definition of `strtod' .libs/environ.o:/usr/include/stdlib.h:330: first defined here .libs/in_unpack_generic.o: In function `atoi': /usr/include/stdlib.h:403: multiple definition of `atoi' .libs/environ.o:/usr/include/stdlib.h:403: first defined here .libs/in_unpack_generic.o: In function `strtol': /usr/include/stdlib.h:336: multiple definition of `atol' .libs/environ.o:/usr/include/stdlib.h:336: first defined here .libs/in_unpack_generic.o: In function `strtoll': /usr/include/stdlib.h:384: multiple definition of `atoll' .libs/environ.o:/usr/include/stdlib.h:384: first defined here .libs/in_unpack_generic.o: In function `strtod': /usr/include/stdlib.h:330: multiple definition of `atof' .libs/environ.o:/usr/include/stdlib.h:330: first defined here collect2: ld returned 1 exit status make[3]: *** [libgfortran.la] Erreur 1 This problem did not exist in the previous edition of gcc-4.3 it is new in 2006 -- Summary: building libgfortran fails because of multiple definitions gcc-4.3-2006 Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libfortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: Jean-pierre dot vial at wanadoo dot fr GCC build triplet: host-x86_64-unknown-linux-gnu GCC host triplet: host-x86_64-unknown-linux-gnu GCC target triplet: host-x86_64-unknown-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29867
[Bug rtl-optimization/29864] Folding conversion unsigned long long to float
--- Comment #1 from rguenth at gcc dot gnu dot org 2006-11-16 09:54 --- Confirmed. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Keywords||wrong-code Last reconfirmed|-00-00 00:00:00 |2006-11-16 09:54:40 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29864
[Bug c/29868] New: Incorrect code generated for comparison
Incorrect code is generated for the following program which I believe should
finish with return 0 and not abort.
This was compiled with
gcc test.c
(no options).
I believe this bug is also present in gcc 4.0.3
int f(int x) __attribute__((noinline));
int f(int x)
{
if (x 0)
abort();
}
int main(void)
{
int x;
for (x = 0; x 0x7fff; x += 0x1001)
f(x);
return 0;
}
--
Summary: Incorrect code generated for comparison
Product: gcc
Version: 3.4.3
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: michael dot chapman at cortus dot com
GCC host triplet: i386-redhat-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29868
[Bug c/29868] Incorrect code generated for comparison
--- Comment #1 from michael dot chapman at cortus dot com 2006-11-16 11:24 --- Created an attachment (id=12630) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12630action=view) test case -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29868
[Bug c/29868] Incorrect code generated for comparison
--- Comment #2 from rguenth at gcc dot gnu dot org 2006-11-16 11:42 --- This is invalid. Adding 0x1001 to 7 * 0x1001 invokes undefined behavior (so you get the wrapped result, which is negative and you abort). -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29868
[Bug tree-optimization/29122] ICE with -ipa-cp and -m64 (tail calls)
--- Comment #8 from patchapp at dberlin dot org 2006-11-16 11:50 --- Subject: Bug number PR29122 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/2006-11/msg01140.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29122
[Bug libfortran/29867] building libgfortran fails because of multiple definitions gcc-4.3-20061111
--- Comment #1 from rguenth at gcc dot gnu dot org 2006-11-16 11:50 --- This is because of the C99 inline changes and your glibc. 2006-11-07 Richard Guenther [EMAIL PROTECTED] * inclhack.def (glibc_c99_inline_2): Adjust for glibc 2.3 systems. * fixincl.x: Regenerate. and 2006-11-02 Geoffrey Keating [EMAIL PROTECTED] * inclhack.def (glibc_c99_inline_1): New. * inclhack.def (glibc_c99_inline_2): New. * inclhack.def (glibc_c99_inline_3): New. * inclhack.def (glibc_c99_inline_4): New. * fixincl.x: Regenerate. * tests/base/bits/string2.h: New. * tests/base/sys/sysmacros.h: New. * tests/base/sys/stat.h: Update. were supposed to fix it. Please provide your stdlib.h header and/or glibc version. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC||geoffk at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29867
[Bug c/29868] Incorrect code generated for comparison
--- Comment #3 from michael dot chapman at cortus dot com 2006-11-16 11:52 --- Subject: Re: Incorrect code generated for comparison rguenth at gcc dot gnu dot org wrote: --- Comment #2 from rguenth at gcc dot gnu dot org 2006-11-16 11:42 --- This is invalid. Adding 0x1001 to 7 * 0x1001 invokes undefined behavior (so you get the wrapped result, which is negative and you abort). I was expecting to see a branch less than (or its inverse) somewhere in the code, and not a branch not equal to 0x7fff. This would have given the expected behaviour. But I think your are right. Legalisticly of course overflowing gives an undefined result, so the result of the compiler is not incorrect. Ok. Please kill the bug report. Mike -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29868
[Bug fortran/29489] LBOUND (array) and LBOUND (array, DIM) give different results.
--- Comment #7 from fxcoudert at gcc dot gnu dot org 2006-11-16 12:25 --- Subject: Bug 29489 Author: fxcoudert Date: Thu Nov 16 12:25:11 2006 New Revision: 11 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=11 Log: PR fortran/29391 PR fortran/29489 * simplify.c (simplify_bound): Fix the simplification of LBOUND/UBOUND intrinsics. * trans-intrinsic.c (simplify_bound): Fix the logic, and remove an erroneous assert. * gcc/testsuite/gfortran.dg/bound_2.f90: Add more checks. * gcc/testsuite/gfortran.dg/bound_3.f90: New test. Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/simplify.c trunk/gcc/fortran/trans-intrinsic.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gfortran.dg/bound_2.f90 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29489
[Bug fortran/29391] LBOUND and UBOUND are broken
--- Comment #15 from fxcoudert at gcc dot gnu dot org 2006-11-16 12:25 --- Subject: Bug 29391 Author: fxcoudert Date: Thu Nov 16 12:25:11 2006 New Revision: 11 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=11 Log: PR fortran/29391 PR fortran/29489 * simplify.c (simplify_bound): Fix the simplification of LBOUND/UBOUND intrinsics. * trans-intrinsic.c (simplify_bound): Fix the logic, and remove an erroneous assert. * gcc/testsuite/gfortran.dg/bound_2.f90: Add more checks. * gcc/testsuite/gfortran.dg/bound_3.f90: New test. Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/simplify.c trunk/gcc/fortran/trans-intrinsic.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gfortran.dg/bound_2.f90 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29391
[Bug c/29868] Incorrect code generated for comparison
--- Comment #4 from rguenth at gcc dot gnu dot org 2006-11-16 12:53 --- Well, for integers i 0x7fff is equal to i != 0x7fff as 0x7fff is the most positive number, any other bit-pattern will be less than that. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29868
[Bug libgcj/29869] New: LogManager class loading failure with Tomcat
I'm trying to run Tomcat 5.5 with gij. It tries to load a log manager through the java.util.logging.manager property. Apparently the class loading code in java.util.logging.LogManager fails to load the correct class, even though it is on the classpath. The exact same invocation with Sun JDK works correctly. $ /usr/lib/jvm/java-gcj/bin/java -Djava.util.logging.manager=org.apache.juli.ClassLoaderLogManager -Djava.util.logging.config.file=/home/marcus/apache-tomcat-5.5.20/conf/logging.properties -Djava.endorsed.dirs=/home/marcus/apache-tomcat-5.5.20/common/endorsed -classpath :/home/marcus/apache-tomcat-5.5.20/bin/bootstrap.jar:/home/marcus/apache-tomcat-5.5.20/bin/commons-logging-api.jar:/home/marcus/apache-tomcat-5.5.20/bin/tomcat-juli.jar -Dcatalina.base=/home/marcus/apache-tomcat-5.5.20 -Dcatalina.home=/home/marcus/apache-tomcat-5.5.20 -Djava.io.tmpdir=/home/marcus/apache-tomcat-5.5.20/temp org.apache.catalina.startup.Bootstrap start WARNING: error instantiating 'org.apache.juli.ClassLoaderLogManager' referenced by java.util.logging.manager, class not found java.lang.ClassNotFoundException: org.apache.juli.ClassLoaderLogManager not found No stacktrace available WARNING: error instantiating '1catalina.org.apache.juli.FileHandler,' referenced by handlers, class not found java.lang.ClassNotFoundException: 1catalina.org.apache.juli.FileHandler, No stacktrace available Exception during runtime initialization java.lang.ExceptionInInitializerError No stacktrace available Caused by: java.lang.NullPointerException No stacktrace available This is with a Tomcat 5.5.20 binary distribution from http://tomcat.apache.org, and gij on Debian i386: A workaround is to disable the java.util.logging.manager property. Tomcat appears to run correctly then. $ gij --version java version 1.4.2 gij (GNU libgcj) version 4.1.2 20061020 (prerelease) (Debian 4.1.1-17) -- Summary: LogManager class loading failure with Tomcat Product: gcc Version: 4.1.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libgcj AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: marcus at better dot se GCC host triplet: i486-linux-gnu GCC target triplet: i486-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29869
[Bug rtl-optimization/25514] [4.0/4.1 regression] internal consistency failure
--- Comment #13 from ebotcazou at gcc dot gnu dot org 2006-11-16 13:08 --- Ping. :-) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25514
[Bug c++/29570] [4.1/4.2/4.3 regression] ICE with brace-enclosed initializer
--- Comment #2 from jzhang918 at gmail dot com 2006-11-16 13:44 --- I narrowed the cause to this change 2006-06-04 Mark Mitchell [EMAIL PROTECTED] PR c++/27819 * decl.c (cp_finish_decl): Process initializers for static data members with non-dependent initializers, even in templates. of this patch http://gcc.gnu.org/ml/gcc-patches/2006-06/msg00198.html -- jzhang918 at gmail dot com changed: What|Removed |Added CC||mark at codesourcery dot ||com, jzhang918 at gmail dot ||com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29570
Was gcc-2.95.2 EH thread-safe ?
I shall maintain an HW/SW configuration running Linux 2.2.14 / glibc 2.1.2 / LinuxThread 0.8 I have a C++ application compiled using gcc 2.95.2 which has several thread that may throw exception. I experience weird and not 100% repeatable mis-behaviour of the application which is hogging all CPU-time. (some threads are SCHED_RR) Which leads me to the question: Was the C++ Exception Handling thread-safe in gcc 2.95.2. I wonder because gcc-2.95.2/gcc/except.c tells: The mechanism in C++ for handling data associated with the exception is clearly not thread-safe. For a thread-based environment, another mechanism must be used (possibly using a per-thread allocation mechanism if the size of the area that needs to be allocated isn't known at compile time.) Whereas gcc-4.1.1/gcc/except.c does not. I know there are MANY gcc release between those two but I would be glad if any GCC historian may tell me what was the first C++ EH thread-safe version of gcc? -- Erk
[Bug middle-end/29846] impossible to both expand store flag operations and use a cbranch handler
--- Comment #2 from rearnsha at gcc dot gnu dot org 2006-11-16 14:16 --- (In reply to comment #0) cstore patterns are recognized by genopinit, but cause a compiler crash their presence influences code generation. Cstore operations should now work after the patch I committed yesterday. See the ARM port. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29846
[Bug middle-end/29584] [4.0/4.1 Regression] internal compiler error on optimization
--- Comment #6 from jakub at gcc dot gnu dot org 2006-11-16 14:45 ---
This has nothing to do with overflows, there are none.
Here is a simplified testcase:
extern void *foo1 (void);
extern void foo2 (void);
extern void foo3 (void *, void *);
extern int foo4 (void);
void
bar (void)
{
int i;
void *s;
for (i = 1; i 4; i++)
{
if (foo4 ())
foo2 ();
switch (0x800UL + i * 0x400)
{
case 0x8000UL ... 0x8000UL + 0x3a00UL - 1:
s = 0;
break;
default:
s = foo1 ();
}
foo3 ((void *) (0x800UL + i * 0x400), s);
}
}
The problem is different, dom3 transforms:
void * ivtmp.40;
long unsigned int D.1646;
...
D.1646_28 = (long unsigned int) ivtmp.40_26;
D.1646_7 = D.1646_28;
switch (D.1646_7)
{
case 2147483648 ... 3120562175: goto L5;
default : goto L4;
}
into:
void * ivtmp.40;
long unsigned int D.1646;
...
D.1646_28 = (long unsigned int) ivtmp.40_26;
D.1646_7 = D.1646_28;
switch (ivtmp.40_26)
{
case 2147483648 ... 3120562175: goto L5;
default : goto L4;
}
(note, void * type of switch control expression) and expand isn't able to cope
with that.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29584
[Bug target/29201] [4.2/4.3 Regression] ICE in create_recovery_block, at haifa-sched.c:3692 at -O3
--- Comment #5 from mkuvyrkov at gcc dot gnu dot org 2006-11-16 15:11 --- Subject: Bug 29201 Author: mkuvyrkov Date: Thu Nov 16 15:10:57 2006 New Revision: 118893 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=118893 Log: 2006-11-16 Maxim Kuvyrkov [EMAIL PROTECTED] PR target/29201 * cfgrtl.c (rtl_delete_block): Move the code for getting last insn of bb to ... (get_last_bb_insn): ... new global function. (basic_block.h): Declare it. * haifa-sched.c (create_recovery_block): Use it. 2006-11-16 Maxim Kuvyrkov [EMAIL PROTECTED] PR target/29201 * gcc.c-torture/compile/pr29201.c: New test for ia64 target. Added: branches/gcc-4_2-branch/gcc/testsuite/gcc.c-torture/compile/pr29201.c Modified: branches/gcc-4_2-branch/gcc/ChangeLog branches/gcc-4_2-branch/gcc/basic-block.h branches/gcc-4_2-branch/gcc/cfgrtl.c branches/gcc-4_2-branch/gcc/haifa-sched.c branches/gcc-4_2-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29201
[Bug target/29201] [4.2/4.3 Regression] ICE in create_recovery_block, at haifa-sched.c:3692 at -O3
--- Comment #6 from mkuvyrkov at gcc dot gnu dot org 2006-11-16 15:17 --- Fixed by the above commits. -- mkuvyrkov at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29201
[Bug libfortran/29867] building libgfortran fails because of multiple definitions gcc-4.3-20061111
--- Comment #2 from jpvial at nerim dot net 2006-11-16 15:19 --- Subject: Re: building libgfortran fails because of multiple definitions gcc-4.3-2006 rguenth at gcc dot gnu dot org wrote: --- Comment #1 from rguenth at gcc dot gnu dot org 2006-11-16 11:50 --- This is because of the C99 inline changes and your glibc. 2006-11-07 Richard Guenther [EMAIL PROTECTED] * inclhack.def (glibc_c99_inline_2): Adjust for glibc 2.3 systems. * fixincl.x: Regenerate. and 2006-11-02 Geoffrey Keating [EMAIL PROTECTED] * inclhack.def (glibc_c99_inline_1): New. * inclhack.def (glibc_c99_inline_2): New. * inclhack.def (glibc_c99_inline_3): New. * inclhack.def (glibc_c99_inline_4): New. * fixincl.x: Regenerate. * tests/base/bits/string2.h: New. * tests/base/sys/sysmacros.h: New. * tests/base/sys/stat.h: Update. were supposed to fix it. Please provide your stdlib.h header and/or glibc version. here is /usr/include/stdlib.h and /usr/include/bits/stdlib.h (as tar.gz) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29867
[Bug target/29682] ICE: in change_pattern, at haifa-sched.c:4066 with -O3 -msched-control-spec
--- Comment #2 from mkuvyrkov at gcc dot gnu dot org 2006-11-16 15:20 --- The patch for this bug was posted in http://gcc.gnu.org/ml/gcc-patches/2006-11/msg01138.html -- mkuvyrkov at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |mkuvyrkov at gcc dot gnu dot |dot org |org Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2006-11-16 15:20:37 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29682
[Bug libfortran/29867] building libgfortran fails because of multiple definitions gcc-4.3-20061111
--- Comment #3 from Jean-pierre dot vial at wanadoo dot fr 2006-11-16 15:27 --- Created an attachment (id=12631) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12631action=view) stdlib.h and bits/stdlib.h Linux Suse 10.1 amd64 from linux Suse/Novell 10.1, amd64 version -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29867
[Bug middle-end/29584] [4.0/4.1 Regression] internal compiler error on optimization
--- Comment #7 from jakub at gcc dot gnu dot org 2006-11-16 15:30 --- Testing a fix. -- jakub at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |jakub at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED Last reconfirmed|2006-10-24 18:56:28 |2006-11-16 15:30:58 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29584
[Bug libfortran/29867] building libgfortran fails because of multiple definitions gcc-4.3-20061111
--- Comment #4 from Jean-pierre dot vial at wanadoo dot fr 2006-11-16 15:36 --- (In reply to comment #1) This is because of the C99 inline changes and your glibc. Please provide your stdlib.h header and/or glibc version. glibc-2.4-31.1 (Suse/Novell 10.1, x86_64) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29867
[Bug libfortran/29867] [4.3 Regression] building libgfortran fails because of multiple definitions gcc-4.3-20061111
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||pinskia at gcc dot gnu dot ||org Severity|normal |blocker GCC build triplet|host-x86_64-unknown-linux- |x86_64-unknown-linux-gnu |gnu | GCC host triplet|host-x86_64-unknown-linux- |x86_64-unknown-linux-gnu |gnu | GCC target triplet|host-x86_64-unknown-linux- |x86_64-unknown-linux-gnu |gnu | Keywords||build Summary|building libgfortran fails |[4.3 Regression] building |because of multiple |libgfortran fails because of |definitions gcc-4.3-2006|multiple definitions gcc- ||4.3-2006 Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29867
[Bug libfortran/29866] building libgfortran fails because of kinds.h
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-11-16 16:38 --- This is a bug in your instation of GMP/MPFR. It is causing gfortran to crash. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID Summary|building libgfortran fails |building libgfortran fails |because of kinds.h |because of kinds.h http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29866
[Bug fortran/29837] INTERFACE overloading INTENT problem - valid code is rejected
--- Comment #5 from patchapp at dberlin dot org 2006-11-16 17:10 --- Subject: Bug number PR29837 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/2006-11/msg01186.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29837
[Bug tree-optimization/29788] [4.1/4.2 Regression] ICE in var_ann, at tree-flow-inline.h:130
--- Comment #15 from pinskia at gcc dot gnu dot org 2006-11-16 17:14 --- Subject: Bug 29788 Author: pinskia Date: Thu Nov 16 17:14:27 2006 New Revision: 118897 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=118897 Log: 2006-11-16 Andrew Pinski [EMAIL PROTECTED] PR tree-opt/29788 * fold-const.c (fold_indirect_ref_1): Fold *CONST_DECL down to what is the const decl is a place holder for. 2006-11-16 Andrew Pinski [EMAIL PROTECTED] PR tree-opt/29788 * gfortran.fortran-torture/compile/inline_1.f90: New testcase. Added: branches/gcc-4_2-branch/gcc/testsuite/gfortran.fortran-torture/compile/inline_1.f90 - copied unchanged from r118861, trunk/gcc/testsuite/gfortran.fortran-torture/compile/inline_1.f90 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=29788
Re: Was gcc-2.95.2 EH thread-safe ?
Eric Noulard wrote: I shall maintain an HW/SW configuration running Linux 2.2.14 / glibc 2.1.2 / LinuxThread 0.8 I have a C++ application compiled using gcc 2.95.2 which has several thread that may throw exception. I experience weird and not 100% repeatable mis-behaviour of the application which is hogging all CPU-time. (some threads are SCHED_RR) Which leads me to the question: Was the C++ Exception Handling thread-safe in gcc 2.95.2. Based on the result of our configuration test I would have to say no. Try it and see: http://tinyurl.com/yl5dxw. Martin I wonder because gcc-2.95.2/gcc/except.c tells: The mechanism in C++ for handling data associated with the exception is clearly not thread-safe. For a thread-based environment, another mechanism must be used (possibly using a per-thread allocation mechanism if the size of the area that needs to be allocated isn't known at compile time.) Whereas gcc-4.1.1/gcc/except.c does not. I know there are MANY gcc release between those two but I would be glad if any GCC historian may tell me what was the first C++ EH thread-safe version of gcc?
[Bug fortran/29870] New: Arithmetic IF, existing label and label not defined
SUBROUTINE ACFI(X,ARG,VAL,Y,NDIM,EPS,IER) ACFI 730 IF(Q3)11,12,11 ACFI1320 11 Y=P3/Q3 ACFI1330 12 Y=1.E75 ACFI1350 END ACFI1580 This is part of http://www.ecalculations.com/SSP.EXE (this is a ZIP file). Error message of gfortran ACFI.FOR: ACFI.FOR:2.72: IF(Q3)11,12,11 1 Warning: Obsolete: arithmetic IF statement at (1) ACFI.FOR:4.13: 12 Y=1.E75 1 Error: Real constant overflows its kind at (1) ACFI.FOR:2.72: IF(Q3)11,12,11 1 Error: Label 12 referenced at (1) is never defined -- Summary: Arithmetic IF, existing label and label not defined Product: gcc Version: 4.3.0 Status: UNCONFIRMED Keywords: rejects-valid Severity: normal 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=29870
[Bug fortran/29870] Arithmetic IF, existing label and label not defined
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-11-16 19:43 --- If we change 12 Y=1.E75 to 12 Y=1.E7 we don't get an extra error. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Severity|normal |minor Keywords|rejects-valid |diagnostic http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29870
[Bug fortran/29870] Arithmetic IF, existing label and label not defined
--- Comment #2 from burnus at gcc dot gnu dot org 2006-11-16 19:49 --- Created an attachment (id=12632) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12632action=view) ACFI.FOR -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29870
[Bug c++/29871] New: Allocating 8Mb structure on the stack causes segmentation fault in output program
If the following tiny program is built, the resulting executable will seg fault
upon the construction of a.
class a {
public:
a() {}
~a() {}
char c[(8*1024*1024)];
};
int main(void) {
a _a;
return 0;
}
I've got this to occur in Suse Enterprise 10 32-bit, but got similar results in
open Suse 10.1 64-bit.
--
Summary: Allocating 8Mb structure on the stack causes
segmentation fault in output program
Product: gcc
Version: 4.1.0
Status: UNCONFIRMED
Severity: major
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: angus at uducat dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29871
[Bug middle-end/26306] [4.0/4.1/4.2/4.3 regression] ICE on volatile array with non-constant bounds
--- Comment #10 from ebotcazou at gcc dot gnu dot org 2006-11-16 21:25 --- Subject: Bug 26306 Author: ebotcazou Date: Thu Nov 16 21:25:16 2006 New Revision: 118900 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=118900 Log: PR middle-end/26306 * gimplify.c (gimplify_expr): Only force a load for references to non-BLKmode volatile values. * doc/implement-c.texi (Qualifiers implementation): Document the interpretation of what a volatile access is. * doc/extend.texi (C++ Extensions): Rework same documentation. Added: trunk/gcc/testsuite/gnat.dg/volatile_aggregate.adb Modified: trunk/gcc/ChangeLog trunk/gcc/doc/extend.texi trunk/gcc/doc/implement-c.texi trunk/gcc/gimplify.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26306
[Bug middle-end/26306] [4.0/4.1/4.2/4.3 regression] ICE on volatile array with non-constant bounds
--- Comment #11 from ebotcazou at gcc dot gnu dot org 2006-11-16 21:27 --- Subject: Bug 26306 Author: ebotcazou Date: Thu Nov 16 21:27:32 2006 New Revision: 118901 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=118901 Log: PR middle-end/26306 * gimplify.c (gimplify_expr): Only force a load for references to non-BLKmode volatile values. * doc/implement-c.texi (Qualifiers implementation): Document the interpretation of what a volatile access is. * doc/extend.texi (C++ Extensions): Rework same documentation. Added: branches/gcc-4_2-branch/gcc/testsuite/gnat.dg/volatile_aggregate.adb Modified: branches/gcc-4_2-branch/gcc/ChangeLog branches/gcc-4_2-branch/gcc/doc/extend.texi branches/gcc-4_2-branch/gcc/doc/implement-c.texi branches/gcc-4_2-branch/gcc/gimplify.c branches/gcc-4_2-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26306
[Bug middle-end/26306] [4.0/4.1/4.2/4.3 regression] ICE on volatile array with non-constant bounds
--- Comment #12 from ebotcazou at gcc dot gnu dot org 2006-11-16 21:30 --- Subject: Bug 26306 Author: ebotcazou Date: Thu Nov 16 21:30:22 2006 New Revision: 118902 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=118902 Log: PR middle-end/26306 * gimplify.c (gimplify_expr): Only force a load for references to non-BLKmode volatile values. * doc/implement-c.texi (Qualifiers implementation): Document the interpretation of what a volatile access is. * doc/extend.texi (C++ Extensions): Rework same documentation. Modified: branches/gcc-4_1-branch/gcc/ChangeLog branches/gcc-4_1-branch/gcc/doc/extend.texi branches/gcc-4_1-branch/gcc/doc/implement-c.texi branches/gcc-4_1-branch/gcc/gimplify.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26306
[Bug middle-end/26306] [4.0 regression] ICE on volatile array with non-constant bounds
--- Comment #13 from ebotcazou at gcc dot gnu dot org 2006-11-16 21:34 --- Fixed in 4.1.2 and later. -- ebotcazou at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Summary|[4.0/4.1/4.2/4.3 regression]|[4.0 regression] ICE on |ICE on volatile array with |volatile array with non- |non-constant bounds |constant bounds Target Milestone|--- |4.1.2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26306
[Bug c++/29871] Allocating 8Mb structure on the stack causes segmentation fault in output program
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-11-16 21:46 --- You should look at the stack limit which is set by either ulimit or limit depending on which shell you use. This is not a bug. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29871
[Bug fortran/29872] New: GNU Fortran 95 (GCC) 4.1.1 (Gentoo 4.1.1-r2 not compatible with gdb
Problem occurs when using gdb. All works fine with GNU Fortran 95 (GCC) 4.1.1
(Gentoo 4.1.1-r1) but not with GNU Fortran 95 (GCC) 4.1.1 (Gentoo 4.1.1-r2).
(I'm assuming the bug was not introduced by Gentoo.) Get failure like this
test.f
i = 1
print '(''i='', i1)', i
end
gfortran -g -o test test.f
gdb test
b test.f:2
run
p i
With the result
Could not find the frame base for MAIN__.
I have also posted this on the gentoo bug site.
--
Summary: GNU Fortran 95 (GCC) 4.1.1 (Gentoo 4.1.1-r2 not
compatible with gdb
Product: gcc
Version: 4.1.1
Status: UNCONFIRMED
Severity: major
Priority: P3
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: fkrogh#gcc at mathalacarte dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29872
[Bug c++/29873] New: need to rework behaviour of 'typedef struct { ... } x;'
GCC rejects this code:
template void (*p)() struct pp
{
static void (*the_p)();
};
template void (*p)() void (* ppp::the_p )() = p;
typedef struct
{
static void f() { }
struct ppf mypp;
} f_struct;
void g()
{
ppf_struct::f::the_p = 0;
}
with
t9.cc:10: error: 'anonymous struct::f' is not a valid template argument for
type 'void (*)()' because function 'static voidanonymous struct::f()' has not
external linkage
t9.cc: In function 'void g()':
t9.cc:15: error: 'f_struct::f' is not a valid template argument for type 'void
(*)()' because function 'static void f_struct::f()' has not external linkage
t9.cc:15: error: invalid type in declaration before '=' token
I believe this is incorrect. f_struct has external linkage by [basic.link]
paragraph 4 item 3, and then f_struct::f has external linkage by paragraph 5.
There is a FIXME in decl.c that says:
/* FIXME remangle member functions; member functions of a
type with external linkage have external linkage. */
which is related but not quite the same thing; it's not just the mangling that
is a problem.
--
Summary: need to rework behaviour of 'typedef struct { ... } x;'
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Keywords: rejects-valid
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: geoffk at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29873
[Bug fortran/24783] Implicit none in module overwrite explicit in procedure
-- aldot at gcc dot gnu dot org changed: What|Removed |Added CC||aldot at gcc dot gnu dot org AssignedTo|unassigned at gcc dot gnu |aldot at gcc dot gnu dot org |dot org | URL||http://gcc.gnu.org/ml/fortra ||n/2006-11/msg00401.html Status|NEW |ASSIGNED Keywords||patch Known to fail||4.1.2 4.2.0 4.3.0 Last reconfirmed|2006-10-30 08:24:25 |2006-11-16 22:12:08 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24783
[Bug c++/29873] need to rework behaviour of 'typedef struct { ... } x;'
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-11-16 22:13 --- I think this is really a dup of bug 7221. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29873
[Bug fortran/29872] GNU Fortran 95 (GCC) 4.1.1 (Gentoo 4.1.1-r2 not compatible with gdb
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-11-16 22:15 --- This is a gentoo specific bug since it worked in one version of gentoo's 4.1.1 but did not in another. Also this works fine for me with the trunk as of today. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29872
[Bug c++/29356] typedef name denoting unnamed class should have external linkage
--- Comment #2 from geoffk at gcc dot gnu dot org 2006-11-16 23:46 --- Yes, it definitely is. Thank you! -- geoffk at gcc dot gnu dot org changed: What|Removed |Added Status|RESOLVED|VERIFIED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29356
[Bug c++/7221] wrong linkage in member functions of typedef-named classes
--- Comment #3 from geoffk at gcc dot gnu dot org 2006-11-16 23:47 --- See rejects-valid example in 29356. -- geoffk at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |geoffk at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Keywords||rejects-valid Last reconfirmed|2005-12-11 23:01:14 |2006-11-16 23:47:01 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=7221
[Bug fortran/29391] [4.2/4.1 only] LBOUND and UBOUND are broken
-- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|4.1.2 |4.1.3 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29391
[Bug fortran/29489] [4.1/4.2 only] LBOUND (array) and LBOUND (array, DIM) give different results.
-- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added Keywords||patch Known to fail||4.1.2 4.2.0 Known to work||4.3.0 Summary|LBOUND (array) and LBOUND |[4.1/4.2 only] LBOUND |(array, DIM) give different |(array) and LBOUND (array, |results.|DIM) give different results. Target Milestone|--- |4.1.3 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29489
[Bug c++/7221] wrong linkage in member functions of typedef-named classes
--- Comment #4 from geoffk at gcc dot gnu dot org 2006-11-17 00:04 --- *** Bug 29873 has been marked as a duplicate of this bug. *** -- geoffk at gcc dot gnu dot org changed: What|Removed |Added CC||geoffk at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=7221
[Bug c++/29873] need to rework behaviour of 'typedef struct { ... } x;'
--- Comment #2 from geoffk at gcc dot gnu dot org 2006-11-17 00:04 --- Yes, this is a duplicate of 7221 as well. (This is the rejects-valid case.) *** This bug has been marked as a duplicate of 7221 *** -- geoffk at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29873
[Bug c++/7221] wrong linkage in member functions of typedef-named classes
--- Comment #5 from geoffk at gcc dot gnu dot org 2006-11-17 00:04 --- I mean, see rejects-valid example in bug 29873. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=7221
[Bug bootstrap/25438] [4.2/4.3 Regression] make: *** No rule to make target `bubblestrap'. Stop.
-- jbuck at gcc dot gnu dot org changed: What|Removed |Added Severity|blocker |normal http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25438
[Bug c/29129] [4.2/4.3 Regression] [DR needed] unnamed parameters using [*]
-- jbuck at gcc dot gnu dot org changed: What|Removed |Added Severity|blocker |normal http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29129
[Bug rtl-optimization/29874] New: gcc-4.1.1 generates consistently worse performming SSE code than gcc-3.4.6
Hello, this is in a sense continuation of http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29818 , the discussion on performance. Here I'll present performance numbers obtained with widely available GPL'ed code - fftw-3.1.2. I did the following: 1) built gcc-3.4.6; 2) ran 10 times this command line: /usr/bin/time /maxtor5/sergei/AppsFromScratchWD/build/fftw-3.1.2/tests/bench --speed if524288 -v4 -oexhaustive - 'fftw-3.1.2/tests/bench' comes with fftw-3.1.2. 3) built gcc-4.1.1; 4) repeated '2)'. Here are the results. gcc-3.4.6: Problem: if524288, setup: 30.90 s, time: 88.12 ms, ``mflops'': 565.2 31.26user 0.21system 0:31.76elapsed 99%CPU (0avgtext+0avgdata 0maxresident)k 0inputs+0outputs (0major+5107minor)pagefaults 0swaps Problem: if524288, setup: 30.90 s, time: 88.33 ms, ``mflops'': 563.86 31.32user 0.21system 0:31.75elapsed 99%CPU (0avgtext+0avgdata 0maxresident)k 0inputs+0outputs (0major+5136minor)pagefaults 0swaps Problem: if524288, setup: 30.89 s, time: 88.51 ms, ``mflops'': 562.76 31.20user 0.24system 0:31.69elapsed 99%CPU (0avgtext+0avgdata 0maxresident)k 0inputs+0outputs (0major+5134minor)pagefaults 0swaps Problem: if524288, setup: 30.93 s, time: 88.49 ms, ``mflops'': 562.86 31.41user 0.20system 0:31.84elapsed 99%CPU (0avgtext+0avgdata 0maxresident)k 0inputs+0outputs (0major+5130minor)pagefaults 0swaps Problem: if524288, setup: 30.90 s, time: 88.55 ms, ``mflops'': 562.45 31.35user 0.22system 0:31.82elapsed 99%CPU (0avgtext+0avgdata 0maxresident)k 0inputs+0outputs (0major+5133minor)pagefaults 0swaps Problem: if524288, setup: 31.25 s, time: 90.50 ms, ``mflops'': 550.37 82.48user 0.46system 1:23.56elapsed 99%CPU (0avgtext+0avgdata 0maxresident)k 0inputs+0outputs (0major+13044minor)pagefaults 0swaps Problem: if524288, setup: 30.89 s, time: 88.11 ms, ``mflops'': 565.29 31.24user 0.21system 0:31.70elapsed 99%CPU (0avgtext+0avgdata 0maxresident)k 0inputs+0outputs (0major+5130minor)pagefaults 0swaps Problem: if524288, setup: 30.89 s, time: 88.29 ms, ``mflops'': 564.15 31.25user 0.24system 0:31.75elapsed 99%CPU (0avgtext+0avgdata 0maxresident)k 0inputs+0outputs (0major+5134minor)pagefaults 0swaps Problem: if524288, setup: 30.85 s, time: 87.81 ms, ``mflops'': 567.2 31.26user 0.21system 0:31.70elapsed 99%CPU (0avgtext+0avgdata 0maxresident)k 0inputs+0outputs (0major+5130minor)pagefaults 0swaps Problem: if524288, setup: 30.89 s, time: 88.71 ms, ``mflops'': 561.45 87.62user 0.44system 1:28.72elapsed 99%CPU (0avgtext+0avgdata 0maxresident)k 0inputs+0outputs (0major+13294minor)pagefaults 0swaps ; gcc-4.1.1: Problem: if524288, setup: 32.13 s, time: 91.64 ms, ``mflops'': 543.53 32.51user 0.23system 0:33.01elapsed 99%CPU (0avgtext+0avgdata 0maxresident)k 0inputs+0outputs (0major+5114minor)pagefaults 0swaps Problem: if524288, setup: 32.11 s, time: 92.67 ms, ``mflops'': 537.45 84.25user 0.45system 1:25.31elapsed 99%CPU (0avgtext+0avgdata 0maxresident)k 0inputs+0outputs (0major+13295minor)pagefaults 0swaps Problem: if524288, setup: 32.16 s, time: 92.33 ms, ``mflops'': 539.44 84.84user 0.46system 1:25.94elapsed 99%CPU (0avgtext+0avgdata 0maxresident)k 0inputs+0outputs (0major+13301minor)pagefaults 0swaps Problem: if524288, setup: 32.18 s, time: 92.54 ms, ``mflops'': 538.22 85.41user 0.49system 1:27.18elapsed 98%CPU (0avgtext+0avgdata 0maxresident)k 0inputs+0outputs (0major+13299minor)pagefaults 0swaps Problem: if524288, setup: 32.19 s, time: 91.40 ms, ``mflops'': 544.91 32.54user 0.22system 0:33.03elapsed 99%CPU (0avgtext+0avgdata 0maxresident)k 0inputs+0outputs (0major+5139minor)pagefaults 0swaps Problem: if524288, setup: 32.17 s, time: 92.60 ms, ``mflops'': 537.9 91.29user 0.45system 1:32.42elapsed 99%CPU (0avgtext+0avgdata 0maxresident)k 0inputs+0outputs (0major+13301minor)pagefaults 0swaps Problem: if524288, setup: 32.20 s, time: 91.83 ms, ``mflops'': 542.37 32.60user 0.24system 0:33.08elapsed 99%CPU (0avgtext+0avgdata 0maxresident)k 0inputs+0outputs (0major+5140minor)pagefaults 0swaps Problem: if524288, setup: 32.15 s, time: 91.82 ms, ``mflops'': 542.42 32.60user 0.22system 0:33.04elapsed 99%CPU (0avgtext+0avgdata 0maxresident)k 0inputs+0outputs (0major+5138minor)pagefaults 0swaps Problem: if524288, setup: 32.16 s, time: 91.37 ms, ``mflops'': 545.12 32.54user 0.23system 0:32.99elapsed 99%CPU (0avgtext+0avgdata 0maxresident)k 0inputs+0outputs (0major+5140minor)pagefaults 0swaps Problem: if524288, setup: 32.11 s, time: 91.24 ms, ``mflops'': 545.89 32.48user 0.21system 0:32.92elapsed 99%CPU (0avgtext+0avgdata 0maxresident)k 0inputs+0outputs (0major+5141minor)pagefaults 0swaps . IMO difference in favor of gcc-3.4.6 is seen with naked eye (see, for example, ``mflops'' - larger numbers are better). Say, let's compare worst numbers: gcc-3.4.6 : 550.37 gcc-4.1.1 : 537.45 . I think it's worth porting gcc-3.4.6 x86 optimization engine to gcc-4.* series. -- Summary: gcc-4.1.1 generates consistently worse performming SSE code than gcc-3.4.6 Product: gcc
[Bug c/29875] New: build of gcc-4.1.1 fails
The build of gcc-4.1.1 for the avr platform on an x86_64 fails. ../configure --prefix=$PREFIX --target=avr --enable-languages=c --disable-nls --disable-libssp --with-dwarf2 make /root/avr_toolchain/gcc-4.1.1/obj-avr/./gcc/xgcc -B/root/avr_toolchain/gcc-4.1.1/obj-avr/./gcc/ -B/usr/local/avr/avr/bin/ -B/usr/local/avr/avr/lib/ -isystem /usr/local/avr/avr/include -isystem /usr/local/avr/avr/sys-include -O2 -O2 -g -O2 -DIN_GCC -DCROSS_COMPILE -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -isystem ./include -DDF=SF -Dinhibit_libc -mcall-prologues -g -DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED -Dinhibit_libc -I. -I. -I../../gcc -I../../gcc/. -I../../gcc/../include -I../../gcc/../libcpp/include -DL_fixunssfsi -c ../../gcc/libgcc2.c -o libgcc/./_fixunssfsi.o ../../gcc/libgcc2.c: In function '__fixunssfsi': ../../gcc/libgcc2.c:1499: internal compiler error: in compute_frame_pointer_to_cfa_displacement, at dwarf2out.c:10446 -- Summary: build of gcc-4.1.1 fails Product: gcc Version: 4.1.1 Status: UNCONFIRMED Severity: critical Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: lenlen at zoellich dot de GCC host triplet: x86_64 GCC target triplet: avr http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29875
[Bug target/29818] code with SSE segfaults with gcc-3.4.6, runs fine with gcc-4.1.1
--- Comment #8 from sergstesh at yahoo dot com 2006-11-17 01:27 --- Please see http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29874 - another proof that gcc-3.4.6 generates better SSE code than gcc-4.1.1, and the proof uses only widely available and well known GPL'ed code. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29818
[Bug c/29875] build of gcc-4.1.1 fails
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-11-17 01:41 --- *** This bug has been marked as a duplicate of 26504 *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Severity|critical|normal Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29875
[Bug target/26504] [4.1/4.2 Regression] compute_frame_pointer_to_cfa_displacement error for avr target with --with-dwarf2
--- Comment #19 from pinskia at gcc dot gnu dot org 2006-11-17 01:41 --- *** Bug 29875 has been marked as a duplicate of this bug. *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||lenlen at zoellich dot de http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26504
[Bug target/29818] code with SSE segfaults with gcc-3.4.6, runs fine with gcc-4.1.1
--- Comment #9 from pinskia at gcc dot gnu dot org 2006-11-17 01:45 --- (In reply to comment #8) Please see Can you try the patch mentioned in: http://gcc.gnu.org/ml/gcc-patches/2006-11/msg01005.html (I am about to submit a new version of the patch but it does not change functionality of the patch, just some style issues). If that does not work, this is most likely an issue with unions and vector accesses which is really PR 28367. I am working slowly on these two issues because I have other work I need to do for Sony. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29818
[Bug target/29818] code with SSE segfaults with gcc-3.4.6, runs fine with gcc-4.1.1
--- Comment #10 from sergstesh at yahoo dot com 2006-11-17 02:03 --- (In reply to comment #9) (In reply to comment #8) Please see Can you try the patch mentioned in: http://gcc.gnu.org/ml/gcc-patches/2006-11/msg01005.html (I am about to submit a new version of the patch but it does not change functionality of the patch, just some style issues). If that does not work, this is most likely an issue with unions and vector accesses which is really PR 28367. I am working slowly on these two issues because I have other work I need to do for Sony. I am confused. Is this patch supposed to fix segmentation fault described in this report, so the patch needs to be applied to gcc-3.4.6 OR this patch is supposed to improve performance of gcc-4.1.1 WRT SSE ? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29818
[Bug target/29818] code with SSE segfaults with gcc-3.4.6, runs fine with gcc-4.1.1
--- Comment #11 from bangerth at dealii dot org 2006-11-17 02:09 --- I'm only a bug master and don't do any work on the compiler anyway, so my say isn't worth much, but here's my take: You propose that you can give us 15,000 lines of obfuscated code through which we will have to dig ourselves to find out what is causing the slowdown, and then fix the problem. At the same time you sit at the sidelines and wait for us to work on the code that you have purposefully made hard to read. What you apparently don't understand is that many of us work on gcc in our spare time. If you want us to do something for you, you will have to help us some. That might include trying to find out which part of the code slowed down, or to make the code significantly slower. Typically, the bug reports that come with the smallest testcases receive the most attention. You just have to realize that you don't pay us to do the crappy work of taking apart an obfuscated code. Since nobody pays us to work on random bug reports, we typically pick the ones that are the most interesting or that are the easiest to tackle since they come with a short testcase. We do have an interest in making gcc better, but we reserve the right to decide which parts of the compiler to make better, unless you pay someone to do some specific piece of work. I am simply saying I do not want to spend my time changing the code to be able to publish it if you are not going to deal with the performance issue anyway. We may. You can increase your chances by helping us. W. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29818
[Bug target/29818] code with SSE segfaults with gcc-3.4.6, runs fine with gcc-4.1.1
--- Comment #12 from bangerth at dealii dot org 2006-11-17 02:12 --- (In reply to comment #11) down, or to make the code significantly slower. Typically, the bug reports ^^ smaller, sorry W. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29818
[Bug target/29818] code with SSE segfaults with gcc-3.4.6, runs fine with gcc-4.1.1
--- Comment #13 from sergstesh at yahoo dot com 2006-11-17 02:23 --- (In reply to comment #11) I'm only a bug master and don't do any work on the compiler anyway, so my say isn't worth much, but here's my take: You propose that you can give us 15,000 lines of obfuscated code through which we will have to dig ourselves to find out what is causing the slowdown, and then fix the problem. At the same time you sit at the sidelines and wait for us to work on the code that you have purposefully made hard to read. What you apparently don't understand is that many of us work on gcc in our spare time. If you want us to do something for you, you will have to help us some. That might include trying to find out which part of the code slowed down, or to make the code significantly slower. Typically, the bug reports that come with the smallest testcases receive the most attention. You just have to realize that you don't pay us to do the crappy work of taking apart an obfuscated code. Since nobody pays us to work on random bug reports, we typically pick the ones that are the most interesting or that are the easiest to tackle since they come with a short testcase. We do have an interest in making gcc better, but we reserve the right to decide which parts of the compiler to make better, unless you pay someone to do some specific piece of work. I am simply saying I do not want to spend my time changing the code to be able to publish it if you are not going to deal with the performance issue anyway. We may. You can increase your chances by helping us. W. I opened another bug report, and mentioned it above, specifically devoted to the performance issue: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29874 . The example is based on FFTW, which is GPL - not a line of my code. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29818
[Bug fortran/29870] Arithmetic IF, existing label and label not defined
--- Comment #3 from jvdelisle at gcc dot gnu dot org 2006-11-17 05:15 --- This also compiles fine or you can use -fno-range-check SUBROUTINE ACFI(X,ARG,VAL,Y,NDIM,EPS,IER) REAL(KIND=8) Y IF(Q3)11,12,11 11 Y=P3/Q3 12 Y=1.E75_8 END This is not a gfortran bug. 1.E75 can not be represented as a KIND=4 Use -fno-range-check on the following to see what I mean. REAL(KIND=4) Y Y=1.E75 PRINT *, Y PRINT *, HUGE(Y) END -- jvdelisle at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29870
[Bug fortran/29872] GNU Fortran 95 (GCC) 4.1.1 (Gentoo 4.1.1-r2 not compatible with gdb
--- Comment #2 from vapier at gentoo dot org 2006-11-17 06:24 --- ideally this shouldnt have happened since the only things added between 4.1.1-r1 and 4.1.1-r2 were patches cut from the gcc-4.1 branch to address specific PR's in gcc-4.1.1 ... but yes, this is something that should be handled in the Gentoo domain -- vapier at gentoo dot org changed: What|Removed |Added CC||vapier at gentoo dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29872
[Bug fortran/29813] -std=F95/F2003: Warn or error when using a non-declared variable with implicit none
-- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2006-11-17 06:28:55 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29813
[Bug fortran/29779] [4.3 Regression] vectorizer fortran testcases failing
--- Comment #7 from dorit at il dot ibm dot com 2006-11-17 06:46 --- (In reply to comment #6) This patch should fix the problem: indeed it does, thanks! are you going to submit it to mainline? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29779
