[Bug rtl-optimization/21804] gcc generates incorrect code on x86_64 with -O2
-- What|Removed |Added Component|c |rtl-optimization Keywords||wrong-code http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21804
[Bug tree-optimization/21639] [4.1 Regression] poisoned ggc memory used for -ftree-vectorize
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-05-29 06:47 --- Subject: Bug 21639 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2005-05-29 06:47:08 Modified files: gcc: ChangeLog tree-complex.c Log message: PR tree-optimization/21639 * tree-complex.c (pass_lower_vector_s): Remove TODO_ggc_collect. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gccr1=2.8936r2=2.8937 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/tree-complex.c.diff?cvsroot=gccr1=2.24r2=2.25 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21639
[Bug tree-optimization/21805] New: loop optimizers are not GC safe
Following PR21639 (and http://gcc.gnu.org/ml/gcc-patches/2005-05/msg02604.html): there are several places in loop opts that are not GGC-safe (in particular the tree nodes refered from loop structures are not seen by garbage collector, and I think there are some other instances). This PR is an enhancement request for making loop optimizations GGC-safe. -- Summary: loop optimizers are not GC safe Product: gcc Version: 4.1.0 Status: UNCONFIRMED Severity: normal Priority: P2 Component: tree-optimization AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: dorit at il dot ibm dot com CC: gcc-bugs at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21805
[Bug middle-end/19699] [4.0/4.1 Regression] warning about not returning from end of a non-void function because of dead code
--- Additional Comments From ismail at kde dot org dot tr 2005-05-29 07:41 --- Will the patch be applied to 4.0 branch too? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19699
[Bug fortran/21063] ICE in gfc_conv_ss_descriptor, at fortran/trans-array.c:1224 after using maxloc function
--- Additional Comments From aj at gcc dot gnu dot org 2005-05-29 08:44 --- This ICE happens also with one of the SPEC CPU 2005 candidate benchmarks. I used: GNU Fortran 95 (GCC 4.0.1 20050529 (prerelease)) on Linux/x86-64. -- What|Removed |Added OtherBugsDependingO|21359 |15502 nThis|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21063
[Bug libfortran/20006] $ format extension doesn't work
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-05-29 12:23 --- Subject: Bug 20006 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2005-05-29 12:22:50 Modified files: gcc/fortran: ChangeLog io.c libgfortran: ChangeLog libgfortran/io : format.c transfer.c Log message: PR libfortran/20006 * io.c (format_item_1): Add check and extension warning for $ edit descriptor. * io/format.c (parse_format_list): Set repeat count of $ format node to 1. * io/transfer.c (read_sf): Add g.seen_dollar to the test concerning advancing I/O. (data_transfer_init): Likewise. (finalize_transfer): Likewise. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/fortran/ChangeLog.diff?cvsroot=gccr1=1.437r2=1.438 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/fortran/io.c.diff?cvsroot=gccr1=1.22r2=1.23 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libgfortran/ChangeLog.diff?cvsroot=gccr1=1.230r2=1.231 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libgfortran/io/format.c.diff?cvsroot=gccr1=1.12r2=1.13 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libgfortran/io/transfer.c.diff?cvsroot=gccr1=1.41r2=1.42 --- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-05-29 12:23 --- Subject: Bug 20006 CVSROOT:/cvs/gcc Module name:gcc Branch: gcc-4_0-branch Changes by: [EMAIL PROTECTED] 2005-05-29 12:22:54 Modified files: gcc/fortran: ChangeLog io.c libgfortran: ChangeLog libgfortran/io : format.c transfer.c Log message: PR libfortran/20006 * io.c (format_item_1): Add check and extension warning for $ edit descriptor. * io/format.c (parse_format_list): Set repeat count of $ format node to 1. * io/transfer.c (read_sf): Add g.seen_dollar to the test concerning advancing I/O. (data_transfer_init): Likewise. (finalize_transfer): Likewise. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/fortran/ChangeLog.diff?cvsroot=gcconly_with_tag=gcc-4_0-branchr1=1.335.2.56r2=1.335.2.57 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/fortran/io.c.diff?cvsroot=gcconly_with_tag=gcc-4_0-branchr1=1.19.10.2r2=1.19.10.3 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libgfortran/ChangeLog.diff?cvsroot=gcconly_with_tag=gcc-4_0-branchr1=1.163.2.44r2=1.163.2.45 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libgfortran/io/format.c.diff?cvsroot=gcconly_with_tag=gcc-4_0-branchr1=1.9.12.1r2=1.9.12.2 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libgfortran/io/transfer.c.diff?cvsroot=gcconly_with_tag=gcc-4_0-branchr1=1.32.2.3r2=1.32.2.4 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20006
[Bug libfortran/20006] $ format extension doesn't work
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-05-29 12:23 --- Subject: Bug 20006 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2005-05-29 12:22:50 Modified files: gcc/fortran: ChangeLog io.c libgfortran: ChangeLog libgfortran/io : format.c transfer.c Log message: PR libfortran/20006 * io.c (format_item_1): Add check and extension warning for $ edit descriptor. * io/format.c (parse_format_list): Set repeat count of $ format node to 1. * io/transfer.c (read_sf): Add g.seen_dollar to the test concerning advancing I/O. (data_transfer_init): Likewise. (finalize_transfer): Likewise. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/fortran/ChangeLog.diff?cvsroot=gccr1=1.437r2=1.438 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/fortran/io.c.diff?cvsroot=gccr1=1.22r2=1.23 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libgfortran/ChangeLog.diff?cvsroot=gccr1=1.230r2=1.231 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libgfortran/io/format.c.diff?cvsroot=gccr1=1.12r2=1.13 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libgfortran/io/transfer.c.diff?cvsroot=gccr1=1.41r2=1.42 --- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-05-29 12:23 --- Subject: Bug 20006 CVSROOT:/cvs/gcc Module name:gcc Branch: gcc-4_0-branch Changes by: [EMAIL PROTECTED] 2005-05-29 12:22:54 Modified files: gcc/fortran: ChangeLog io.c libgfortran: ChangeLog libgfortran/io : format.c transfer.c Log message: PR libfortran/20006 * io.c (format_item_1): Add check and extension warning for $ edit descriptor. * io/format.c (parse_format_list): Set repeat count of $ format node to 1. * io/transfer.c (read_sf): Add g.seen_dollar to the test concerning advancing I/O. (data_transfer_init): Likewise. (finalize_transfer): Likewise. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/fortran/ChangeLog.diff?cvsroot=gcconly_with_tag=gcc-4_0-branchr1=1.335.2.56r2=1.335.2.57 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/fortran/io.c.diff?cvsroot=gcconly_with_tag=gcc-4_0-branchr1=1.19.10.2r2=1.19.10.3 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libgfortran/ChangeLog.diff?cvsroot=gcconly_with_tag=gcc-4_0-branchr1=1.163.2.44r2=1.163.2.45 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libgfortran/io/format.c.diff?cvsroot=gcconly_with_tag=gcc-4_0-branchr1=1.9.12.1r2=1.9.12.2 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libgfortran/io/transfer.c.diff?cvsroot=gcconly_with_tag=gcc-4_0-branchr1=1.32.2.3r2=1.32.2.4 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20006
[Bug libfortran/15160] Generated files don't regenerate
--- Additional Comments From tkoenig at gcc dot gnu dot org 2005-05-29 12:40 --- Configuring with --enable-maintainer-mode fails: /home/ig25/gcc-4.0-bin/gcc/xgcc -B/home/ig25/gcc-4.0-bin/gcc/ -B/home/ig25/i686-pc-linux-gnu/bin/ -B/home/ig25/i686-pc-linux-gnu/lib/ -isystem /home/ig25/i686-pc-linux-gnu/include -isystem /home/ig25/i686-pc-linux-gnu/sys-include -DHAVE_CONFIG_H -I. -I../../../gcc-4.0/libgfortran -I. -iquote../../../gcc-4.0/libgfortran/io -std=gnu99 -Wall -O2 -g -O2 -c ../../../gcc-4.0/libgfortran/runtime/environ.c -fPIC -DPIC -o .libs/environ.o In file included from ../../../gcc-4.0/libgfortran/runtime/environ.c:35: ../../../gcc-4.0/libgfortran/libgfortran.h:63: error: conflicting types for 'int8_t' /usr/include/sys/types.h:191: error: previous declaration of 'int8_t' was here make[3]: *** [environ.lo] Error 1 make[3]: Leaving directory `/home/ig25/gcc-4.0-bin/i686-pc-linux-gnu/libgfortran' make[2]: *** [all] Error 2 make[2]: Leaving directory `/home/ig25/gcc-4.0-bin/i686-pc-linux-gnu/libgfortran' make[1]: *** [all-target-libgfortran] Error 2 make[1]: Leaving directory `/home/ig25/gcc-4.0-bin' make: *** [bootstrap] Error 2 -- What|Removed |Added Status|RESOLVED|REOPENED Resolution|WORKSFORME | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15160
[Bug c++/21806] New: Incorrect stack allocation of complex objects
The bug leads to corruption of program's data. Two objects on the stack overlap
so that the constructor of the second one erases some data of the first one.
I've checked the whole program with valgrind and it didn't report anything
incorrect that I might have done with memory allocation, pointers etc. Bug
exists independently from optimization flags.
Incorrect program fragment:
-
int main(int argc, char* argv[])
{
THttpServer HttpServer;
THttpSessionBroker SessionBroker;// error occurs at this line
SessionBroker.SetServletConstructor(TMainServlet::Create);
HttpServer.RegisterServlet(SessionBroker, /);
HttpServer.SetLocalPort();
HttpServer.Run();
}
GDB session that proves objects are not placed on the
stack as they should be:
--
GNU gdb 5.3
Copyright 2002 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type show copying to see the conditions.
There is absolutely no warranty for GDB. Type show warranty for details.
This GDB was configured as i386-slackware-linux...
(gdb) break main.cpp:25
Breakpoint 1 at 0x80492a4: file main.cpp, line 25.
(gdb) run
Starting program: /home/pkolaczk/projects/dns/dns
[New Thread 16384 (LWP 5218)]
[New Thread 32769 (LWP 5219)]
[New Thread 16386 (LWP 5220)]
[New Thread 32771 (LWP 5221)]
[New Thread 49154 (LWP 5222)]
[Switching to Thread 16384 (LWP 5218)]
Breakpoint 1, main (argc=1, argv=0xb7f4) at main.cpp:26
26 THttpServer HttpServer;
(gdb) next
[New Thread 65539 (LWP 5223)]
[New Thread 81924 (LWP 5224)]
[New Thread 98309 (LWP 5225)]
[New Thread 114694 (LWP 5226)]
[New Thread 131079 (LWP 5227)]
27 THttpSessionBroker SessionBroker;
(gdb) print HttpServer
$1 = (THttpServer *) 0xb760
(gdb) print sizeof(HttpServer)
$2 = 48
(gdb) print SessionBroker
$3 = (THttpSessionBroker *) 0xb6a0
(gdb) print sizeof(SessionBroker)
$4 = 272
(gdb) print SessionBroker.SessionTimer
$5 = (class TTimer *) 0xb6e0
(gdb) print SessionBroker.SessionTimer.Stopper
$6 = (TMutex *) 0xb758
(gdb) print SessionBroker.SessionTimer.TaskListProtection
$7 = (TMutex *) 0xb774 // ITS BEYOND 0xb760 !!!
(gdb) x/8xa 0xb760
0xb760: 0x804e2d8 0x804e2d0 0x804e670 0x804e668
0xb770: 0x804e3d0 0x804e3c8 0x804e200 0x804e1f8
(gdb) next// create the second object
[New Thread 147464 (LWP 5228)]
29 HttpServer.RegisterServlet(SessionBroker, /);
(gdb) x/8xa 0xb760
0xb760: 0x0 0x0 0xbebff990 0x0
0xb770: 0x804e3d0 0x804e3c8 0x0 0x0
(gdb)
Seems the overlapping area is at least 28 bytes large.
By more extensive debugging I've found out that the stack corruption occurs in
the constructor of SessionBroker.SessionTimer.Stopper object which only sets
some of its fields and doesn't do any pointer arithmetic or anything that
could write to memory it shouldn't. Everytime I run the program, everything
goes the same way. The bug is not random as opposed to ordinary memory
bugs.
I've also made some experiments - putting an array between the two objects
helps:
int main(int argc, char* argv[])
{
THttpServer HttpServer;
int a[8];
THttpSessionBroker SessionBroker;
//SessionBroker.SetServletConstructor(TMainServlet::Create);
HttpServer.RegisterServlet(SessionBroker, /);
HttpServer.SetLocalPort();
HttpServer.Run();
}
Also if compiled with gcc 2.95.3, everything worked fine.
Having this evidence (especially the gdb output), can it be the fault of my
program or is it rather a compiler bug? Have I missed something?
I can send you a complete source code if needed.
Additional information:
system type: Linux 2.6.11.7
processor: i686 (Pentium Celeron 2.4 GHz / 128k L2 cache)
gcc version: 3.4.4 built from sources in a default way: ./configure without
any additional options
--
Summary: Incorrect stack allocation of complex objects
Product: gcc
Version: 3.4.4
Status: UNCONFIRMED
Severity: critical
Priority: P2
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: pkolaczk at elka dot pw dot edu dot pl
CC: gcc-bugs at gcc dot gnu dot org
GCC build triplet: 3.4.4
GCC host triplet: 3.4.4
GCC target triplet: 3.4.4
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21806
[Bug c/21807] New: gcc 4.1.0 20050522 segfaults (internal compiler error) on various GNU/Linux builds
Using a host system of Linux 2.6.8.1, binutils version 2.16 and the aforementioned GCC, I have observed the following gcc segmentation faults: util-linux-2.12q: -pipe -O2 -mtune=i486 -fomit-frame-pointer (defaults) fdiskbsdlabel.c: In function 'bselect' (void): fdiskbsdlabel.c: 164: internal compiler error: Segmentation fault sfdisk.c: In function 'do_fdisk (static void)': sfdisk.c:3006: internal compiler error: Segmentation fault I have also found that many variations of '-march=pentium4 -OX' segfault when compiling different instantiations of quotearg. For example: patch-2.5.9: quotearg.c: In function 'quotearg_char' quotearg.c:619: internal compiler error: Segmentation fault when -O3 was used, but worked fine with a -O2 optimization. (I realize that optimizations greater than -O2 are risky but I didn't expect the compiler to choke with a segmentation fault). I marked this as critical because it causes a seg fault and thought that someone might want to know. Sean McLinden Allegheny County Health Department -- Summary: gcc 4.1.0 20050522 segfaults (internal compiler error) on various GNU/Linux builds Product: gcc Version: 4.1.0 Status: UNCONFIRMED Severity: critical Priority: P2 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: mclinden at informed dot net CC: gcc-bugs at gcc dot gnu dot org GCC build triplet: i686-pc-linux GCC host triplet: i686-pc-linux GCC target triplet: i696-pc-linux http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21807
[Bug c++/21806] Incorrect stack allocation of complex objects
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-29 14:06 --- Could you attach the preprocessed source? -- What|Removed |Added Severity|critical|normal Summary|Incorrect stack allocation |Incorrect stack allocation |of complex objects |of complex objects http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21806
[Bug middle-end/21807] gcc 4.1.0 20050522 segfaults (internal compiler error) on various GNU/Linux builds
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-29 14:09 --- *** This bug has been marked as a duplicate of 21790 *** -- What|Removed |Added Status|UNCONFIRMED |RESOLVED Component|c |middle-end Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21807
[Bug middle-end/21790] gcc 4.1.0 20050522 segfaults (internal compiler error) on various GNU/Linux builds
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-29 14:09 --- *** Bug 21807 has been marked as a duplicate of this bug. *** -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21790
[Bug middle-end/19699] [4.0/4.1 Regression] warning about not returning from end of a non-void function because of dead code
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-29 14:16 --- (In reply to comment #12) Will the patch be applied to 4.0 branch too? No because it is too big in that it also changes the inliner to be a CFG aware inliner. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19699
[Bug tree-optimization/21805] loop optimizers are not GC safe
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-29 14:40 --- Confirmed. -- What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed||1 Last reconfirmed|-00-00 00:00:00 |2005-05-29 14:40:46 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21805
[Bug tree-optimization/21639] [4.1 Regression] poisoned ggc memory used for -ftree-vectorize
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-29 14:40 --- Fixed. -- What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21639
[Bug c++/21808] New: Uninformative diagnostic for name lookup from template function
Template code that used to work prior to gcc-3.4
fails in very uninformative ways. Diagnostic should
be improved.
For example:
$ cat t.cpp
template class T struct A { T t; };
// Swap following 2 functions to get conforming C++
template class T void foo(const AT data)
{
foo((int)data.t);
}
void foo(int data);
$ g++ t2.cpp
t2.cpp: In function `void foo(const AT)':
t2.cpp:5: error: no matching function for call to `foo(int)'
As an exaple for a good diagnostic:
int f()
{
for (int i=0 ; i 4 ; ++i)
{}
return i;
}
t4.cpp: In function `int f()':
t4.cpp:5: name lookup of `i' changed for new ISO `for' scoping
t4.cpp:3: using obsolete binding at `i'
It would be nice to have something like:
t2.cpp: In function `void foo(const AT)':
t2.cpp:5: error: name lookup of `foo(int)' changed for new ISO `template'
functions.
t2.cpp:9: error: using not dependent `foo(int)' is no longer supported.
--
Summary: Uninformative diagnostic for name lookup from template
function
Product: gcc
Version: 4.0.0
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: veksler at il dot ibm dot com
CC: gcc-bugs at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21808
[Bug c++/17166] Improve diagnostic for empty overload set listing the rejected overloads
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-29
16:02 ---
The testcase really boils down to:
template typename T int foo ();
int i = foo(1);
OR
template typename T struct f{};
template typename T int foo (fT);
int i = foo(1);
--
What|Removed |Added
Last reconfirmed|2004-10-28 03:58:46 |2005-05-29 16:02:02
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17166
[Bug fortran/17193] [meta-bug] Pointer arguments not working correctly
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-05-29 16:02 --- Subject: Bug 17193 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2005-05-29 16:02:11 Modified files: gcc/fortran: trans-array.c trans-expr.c Log message: 2005-05-29 Paul Thomas [EMAIL PROTECTED] PR fortran/16939 PR fortran/17192 PR fortran/17193 PR fortran/17202 PR fortran/18689 PR fortran/18890 PR fortran/21297 * fortran/trans-array.c (gfc_conv_resolve_dependencies): Add string length to temp_ss for character pointer array assignments. * fortran/trans-expr.c (gfc_conv_variable): Correct errors in dereferencing of characters and character pointers. * fortran/trans-expr.c (gfc_conv_function_call): Provide string length as return argument for various kinds of handling of return. Return a char[]* temporary for character pointer functions and dereference the temporary upon return. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/fortran/trans-array.c.diff?cvsroot=gccr1=1.45r2=1.46 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/fortran/trans-expr.c.diff?cvsroot=gccr1=1.44r2=1.45 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17193
[Bug c++/17166] Improve diagnostic for empty overload set listing the rejected overloads
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-29 16:02 --- *** Bug 21808 has been marked as a duplicate of this bug. *** -- What|Removed |Added CC||veksler at il dot ibm dot ||com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17166
[Bug c++/21808] Uninformative diagnostic for name lookup for template functions
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-29
16:02 ---
If you called a different function name instead of a template one, I get the
following error:
t.cc: In function void foo(const AT):
t.cc:7: error: there are no arguments to foo1 that depend on a template
parameter, so a declaration of
foo1 must be available
t.cc:7: error: (if you use -fpermissive, G++ will accept your code, but
allowing the use of an
undeclared name is deprecated)
template class T struct A { T t; };
// Swap following 2 functions to get conforming C++
template int i struct B {static const int t = i;};
templateclass T void foo(const AT data)
{
foo1((int)data.t);
}
void foo1(int data);
In fact this has nothing to do with dependent or not, see the following code
(which gives the same error
message in 3.3.3 also):
template class T struct A { T t; };
// Swap following 2 functions to get conforming C++
template int i struct B {static const int t = i;};
templateclass T void foo1(const AT data);
void foo(const Aint data)
{
foo1((int)data.t);
}
void foo1(int data);
So the error message problem, in fact that is PR 17166 which I am going to mark
this as a dup of.
*** This bug has been marked as a duplicate of 17166 ***
--
What|Removed |Added
Severity|normal |enhancement
Status|UNCONFIRMED |RESOLVED
Keywords||diagnostic
Resolution||DUPLICATE
Summary|Uninformative diagnostic for|Uninformative diagnostic for
|name lookup from template |name lookup for template
|function|functions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21808
[Bug fortran/17192] Functions returning character pointer via argument are broken
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-05-29 16:02 --- Subject: Bug 17192 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2005-05-29 16:02:11 Modified files: gcc/fortran: trans-array.c trans-expr.c Log message: 2005-05-29 Paul Thomas [EMAIL PROTECTED] PR fortran/16939 PR fortran/17192 PR fortran/17193 PR fortran/17202 PR fortran/18689 PR fortran/18890 PR fortran/21297 * fortran/trans-array.c (gfc_conv_resolve_dependencies): Add string length to temp_ss for character pointer array assignments. * fortran/trans-expr.c (gfc_conv_variable): Correct errors in dereferencing of characters and character pointers. * fortran/trans-expr.c (gfc_conv_function_call): Provide string length as return argument for various kinds of handling of return. Return a char[]* temporary for character pointer functions and dereference the temporary upon return. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/fortran/trans-array.c.diff?cvsroot=gccr1=1.45r2=1.46 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/fortran/trans-expr.c.diff?cvsroot=gccr1=1.44r2=1.45 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17192
[Bug fortran/16939] Pointers not passed as subroutine arguments
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-05-29 16:02 --- Subject: Bug 16939 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2005-05-29 16:02:11 Modified files: gcc/fortran: trans-array.c trans-expr.c Log message: 2005-05-29 Paul Thomas [EMAIL PROTECTED] PR fortran/16939 PR fortran/17192 PR fortran/17193 PR fortran/17202 PR fortran/18689 PR fortran/18890 PR fortran/21297 * fortran/trans-array.c (gfc_conv_resolve_dependencies): Add string length to temp_ss for character pointer array assignments. * fortran/trans-expr.c (gfc_conv_variable): Correct errors in dereferencing of characters and character pointers. * fortran/trans-expr.c (gfc_conv_function_call): Provide string length as return argument for various kinds of handling of return. Return a char[]* temporary for character pointer functions and dereference the temporary upon return. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/fortran/trans-array.c.diff?cvsroot=gccr1=1.45r2=1.46 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/fortran/trans-expr.c.diff?cvsroot=gccr1=1.44r2=1.45 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16939
[Bug fortran/18689] Internal compiler error with character pointer association in module subroutine
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-05-29 16:02 --- Subject: Bug 18689 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2005-05-29 16:02:11 Modified files: gcc/fortran: trans-array.c trans-expr.c Log message: 2005-05-29 Paul Thomas [EMAIL PROTECTED] PR fortran/16939 PR fortran/17192 PR fortran/17193 PR fortran/17202 PR fortran/18689 PR fortran/18890 PR fortran/21297 * fortran/trans-array.c (gfc_conv_resolve_dependencies): Add string length to temp_ss for character pointer array assignments. * fortran/trans-expr.c (gfc_conv_variable): Correct errors in dereferencing of characters and character pointers. * fortran/trans-expr.c (gfc_conv_function_call): Provide string length as return argument for various kinds of handling of return. Return a char[]* temporary for character pointer functions and dereference the temporary upon return. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/fortran/trans-array.c.diff?cvsroot=gccr1=1.45r2=1.46 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/fortran/trans-expr.c.diff?cvsroot=gccr1=1.44r2=1.45 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18689
[Bug fortran/17202] ice-on-valid-code, trans-array.c:217: gfc_conv_descriptor_dtype Assertion failed
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-05-29 16:02 --- Subject: Bug 17202 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2005-05-29 16:02:11 Modified files: gcc/fortran: trans-array.c trans-expr.c Log message: 2005-05-29 Paul Thomas [EMAIL PROTECTED] PR fortran/16939 PR fortran/17192 PR fortran/17193 PR fortran/17202 PR fortran/18689 PR fortran/18890 PR fortran/21297 * fortran/trans-array.c (gfc_conv_resolve_dependencies): Add string length to temp_ss for character pointer array assignments. * fortran/trans-expr.c (gfc_conv_variable): Correct errors in dereferencing of characters and character pointers. * fortran/trans-expr.c (gfc_conv_function_call): Provide string length as return argument for various kinds of handling of return. Return a char[]* temporary for character pointer functions and dereference the temporary upon return. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/fortran/trans-array.c.diff?cvsroot=gccr1=1.45r2=1.46 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/fortran/trans-expr.c.diff?cvsroot=gccr1=1.44r2=1.45 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17202
[Bug fortran/18890] ICE at assign CHARACTER POINTER array to POINTER or ALLOCATABLE one
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-05-29 16:02 --- Subject: Bug 18890 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2005-05-29 16:02:11 Modified files: gcc/fortran: trans-array.c trans-expr.c Log message: 2005-05-29 Paul Thomas [EMAIL PROTECTED] PR fortran/16939 PR fortran/17192 PR fortran/17193 PR fortran/17202 PR fortran/18689 PR fortran/18890 PR fortran/21297 * fortran/trans-array.c (gfc_conv_resolve_dependencies): Add string length to temp_ss for character pointer array assignments. * fortran/trans-expr.c (gfc_conv_variable): Correct errors in dereferencing of characters and character pointers. * fortran/trans-expr.c (gfc_conv_function_call): Provide string length as return argument for various kinds of handling of return. Return a char[]* temporary for character pointer functions and dereference the temporary upon return. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/fortran/trans-array.c.diff?cvsroot=gccr1=1.45r2=1.46 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/fortran/trans-expr.c.diff?cvsroot=gccr1=1.44r2=1.45 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18890
[Bug target/21297] [4.0 Regression] buf[i+i]=0 stores buf[i] when -O2
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-05-29 16:02 --- Subject: Bug 21297 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2005-05-29 16:02:11 Modified files: gcc/fortran: trans-array.c trans-expr.c Log message: 2005-05-29 Paul Thomas [EMAIL PROTECTED] PR fortran/16939 PR fortran/17192 PR fortran/17193 PR fortran/17202 PR fortran/18689 PR fortran/18890 PR fortran/21297 * fortran/trans-array.c (gfc_conv_resolve_dependencies): Add string length to temp_ss for character pointer array assignments. * fortran/trans-expr.c (gfc_conv_variable): Correct errors in dereferencing of characters and character pointers. * fortran/trans-expr.c (gfc_conv_function_call): Provide string length as return argument for various kinds of handling of return. Return a char[]* temporary for character pointer functions and dereference the temporary upon return. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/fortran/trans-array.c.diff?cvsroot=gccr1=1.45r2=1.46 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/fortran/trans-expr.c.diff?cvsroot=gccr1=1.44r2=1.45 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21297
[Bug rtl-optimization/21809] New: [3.4/4.0/4.1 Regression] Floating Optimization Bug
This problems occurs with GCC 3.4.4, gcc-4.0-20050521 snapshot and
gcc-4.1-20050528 snapshot.
test-case.c:
#include assert,h
volatile float x = 3;
int main()
{
float a = 1 / x;
x = a;
assert(a == x);
}
This case (test-case.c) works with gcc -O0 without a problem.
But with gcc {-O1,-O2,-O3,-Os} causes the following error:
test: test.c:9: main: Assertion 'a == x' failed'
--
Summary: [3.4/4.0/4.1 Regression] Floating Optimization Bug
Product: gcc
Version: 4.0.0
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: rtl-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: themis_hv at yahoo dot co dot uk
CC: gcc-bugs at gcc dot gnu dot org,themis_hv at yahoo dot
co dot uk
GCC build triplet: i686-pc-linux-gnu
GCC host triplet: i686-pc-linux-gnu
GCC target triplet: i686-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21809
[Bug rtl-optimization/21809] [3.4/4.0/4.1 Regression] Floating Optimization Bug
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-29 16:24 --- *** This bug has been marked as a duplicate of 323 *** -- What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21809
[Bug rtl-optimization/323] optimized code gives strange floating point results
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-29 16:24 --- *** Bug 21809 has been marked as a duplicate of this bug. *** -- What|Removed |Added CC||themis_hv at yahoo dot co ||dot uk http://gcc.gnu.org/bugzilla/show_bug.cgi?id=323
[Bug rtl-optimization/21809] [3.4/4.0/4.1 Regression] Floating Optimization Bug
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-29 16:39 --- Note every GCC from 2.95.3 gives the same result. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21809
[Bug rtl-optimization/21809] [3.4/4.0/4.1 Regression] Floating Optimization Bug
--- Additional Comments From themis_hv at yahoo dot co dot uk 2005-05-29 16:44 --- x and a should be identical, so assertion should not fail at all. since a is assigned to x, it has *SAME* rounding precision. -- What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|DUPLICATE | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21809
[Bug target/21809] Floating Optimization Bug
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-29 17:04 --- This is a target problem, as the RTL is correct. Looks like there is a forgotten rounding back to float. -- What|Removed |Added Component|rtl-optimization|target GCC build triplet|i686-pc-linux-gnu | GCC host triplet|i686-pc-linux-gnu | Summary|[3.4/4.0/4.1 Regression]|Floating Optimization Bug |Floating Optimization Bug | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21809
[Bug c++/17413] [3.4 regression] local classes as template argument
--- Additional Comments From mark at codesourcery dot com 2005-05-29 17:18
---
Subject: Re: [3.4 regression] local classes as template argument
Geoffrey Keating wrote:
Hi Mark,
Consider this code:
struct Attribute { };
template class T void fun (const Attribute attr, const T value);
extern void fun (int attr, int value);
enum { anon = 666 };
void test(int foo)
{ fun (foo, anon); }
I believe this is valid C++. Template argument deduction will fail
when it compares the type of the *first* parameter of fun(), since no
value of T can be found that will make the first parameter match.
As you've discovered, we don't perform template argument deduction on
arguments that do not involve template types. I agree that there's
nothing in the standard to support that behavior. However, there are a
lot of DRs in this area, and we should check the behavior of other
compilers before making any changes here. Those checks should be done
without using anonymous enums, since there's additional controversy
around that particular issue; instead, some way to isolate what set of
template functions can be deduced is required.
I don't remember the origin of the comment in the code that refers to
infinite recursion. I don't think adding DEDUCE_CALL to the condition
makes sense, though; either we should always do the comparsion, or only
when DEDUCE_EXACT. Furthermore, your change is not correct, in that
deduction permits non-exact matches for calls; see [temp.deduct.call].
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17413
[Bug target/21809] Floating Optimization Bug
--- Additional Comments From themis_hv at yahoo dot co dot uk 2005-05-29
17:58 ---
This also occurs with double, using test-case.c but with float replaced with
double, so code fragment looks like:
test-case.c:
#include assert,h
volatile double x = 3;
int main()
{
double a = 1 / x;
x = a;
assert(a == x);
}
Should I put this as separate PR?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21809
[Bug java/21695] ICE when building gnu-xml.lo in libjava directory
-- What|Removed |Added Keywords||build http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21695
[Bug target/21809] Floating Optimization Bug
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-29 18:27 --- (In reply to comment #5) Should I put this as separate PR? Actually this is all a dup of bug 323. The problem is excessive pression, which most non fp developers will not know about, read the full PR 323 and the references to papers which talk about this. *** This bug has been marked as a duplicate of 323 *** -- What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21809
[Bug rtl-optimization/323] optimized code gives strange floating point results
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-29 18:27 --- *** Bug 21809 has been marked as a duplicate of this bug. *** -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=323
[Bug target/21809] Floating Optimization Bug
--- Additional Comments From themis_hv at yahoo dot co dot uk 2005-05-29 19:01 --- It should be logical equivalent regardless of how it stored in memory. -- What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|DUPLICATE | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21809
[Bug target/21809] Floating Optimization Bug
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-29 19:06 --- when you store it to memory the precission goes down (aka rounding) read 323 and all the rest of the problems related to it. *** This bug has been marked as a duplicate of 323 *** -- What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21809
[Bug rtl-optimization/323] optimized code gives strange floating point results
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-29 19:06 --- *** Bug 21809 has been marked as a duplicate of this bug. *** -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=323
[Bug target/21809] Floating Optimization Bug
--- Additional Comments From themis_hv at yahoo dot co dot uk 2005-05-29 19:18 --- Surely assigning a float value to another float variable should not cause any rounding as they are same data type. -- What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|DUPLICATE | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21809
[Bug target/21809] Floating Optimization Bug
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-29 19:24 --- Please go read the papers. Basically x87 is broken in this respect, use either a different machine or use SSE. *** This bug has been marked as a duplicate of 323 *** -- What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21809
[Bug rtl-optimization/323] optimized code gives strange floating point results
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-29 19:24 --- *** Bug 21809 has been marked as a duplicate of this bug. *** -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=323
[Bug target/21809] Floating Optimization Bug
--- Additional Comments From themis_hv at yahoo dot co dot uk 2005-05-29
19:28 ---
Read the code carefully:
test-case.c:
#include assert,h
volatile float x = 3;
int main()
{
float a = 1 / x;
x = a;
assert(a == x);
}
Notice x = a before assertion, both of these variables are of the same data
type.
This is *not* related to precission.
This is behaviour, you would expect from a compiler.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21809
[Bug target/21809] Floating Optimization Bug
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-29 19:31 --- (In reply to comment #11) This is *not* related to precission. This is behaviour, you would expect from a compiler. For non floating point, yes but floating point is different with respect with precission. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21809
[Bug target/21809] Floating Optimization Bug
--- Additional Comments From themis_hv at yahoo dot co dot uk 2005-05-29 19:32 --- (In reply to comment #10) Please go read the papers. Basically x87 is broken in this respect, use eithera different machine or use SSE. It be good idea to do that by default then? -- What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|DUPLICATE | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21809
[Bug libfortran/15160] Generated files don't regenerate
--- Additional Comments From tkoenig at gcc dot gnu dot org 2005-05-29 19:32 --- To be more precise, on i686-pc-linux-gnu, I created an empty directory, cd'd into it, and then ran ../gcc-4.0/configure --prefix=$HOME --enable-maintainer-mode --enable-languages=c,f95 make bootstrap Same thing for 4.1. Thomas -- What|Removed |Added CC||tkoenig at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15160
[Bug target/21809] Floating Optimization Bug
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-29 19:35 --- (In reply to comment #13) (In reply to comment #10) Please go read the papers. Basically x87 is broken in this respect, use eithera different machine or use SSE. It be good idea to do that by default then? It is on x86_64, remember SSE is not every where. Just use -ffloat-store instead. *** This bug has been marked as a duplicate of 323 *** -- What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21809
[Bug rtl-optimization/323] optimized code gives strange floating point results
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-29 19:35 --- *** Bug 21809 has been marked as a duplicate of this bug. *** -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=323
[Bug target/21809] Floating Optimization Bug
--- Additional Comments From themis_hv at yahoo dot co dot uk 2005-05-29 19:36 --- It be good idea to do that by default then? It is on x86_64, remember SSE is not every where. x86-64 has support for SSE3 so it would use that instead. -- What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|DUPLICATE | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21809
[Bug target/21809] Floating Optimization Bug
--- Additional Comments From joseph at codesourcery dot com 2005-05-29
19:37 ---
Subject: Re: New: [3.4/4.0/4.1 Regression]
Floating Optimization Bug
On Sun, 29 May 2005, themis_hv at yahoo dot co dot uk wrote:
This case (test-case.c) works with gcc -O0 without a problem.
But with gcc {-O1,-O2,-O3,-Os} causes the following error:
test: test.c:9: main: Assertion 'a == x' failed'
Not if you use -ffloat-store, as is required if you wish to avoid such
instances of paradoxical excess precision.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21809
[Bug target/21809] Floating Optimization Bug
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-29 19:43 --- (In reply to comment #15) x86-64 has support for SSE3 so it would use that instead. Actually that is wrong, the subset which is supported by AMD and Intel (EM64T) only have SSE, SSE2, and MMX. AMD's x86_64 which in my mind the true x86_64 has also support for 3dnow. Intel's EM64t have SSE3. Again just use -ffloat-store as required not get the excessive precision. *** This bug has been marked as a duplicate of 323 *** -- What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21809
[Bug rtl-optimization/323] optimized code gives strange floating point results
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-29 19:43 --- *** Bug 21809 has been marked as a duplicate of this bug. *** -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=323
[Bug target/21809] Floating Optimization Bug
--- Additional Comments From themis_hv at yahoo dot co dot uk 2005-05-29 19:46 --- Again just use -ffloat-store as required not get the excessive precision. This should included in gcc spec file by defaults. -- What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|DUPLICATE | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21809
[Bug target/21809] Floating Optimization Bug
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-29 19:47 --- That is not going to change, the assert is allowed to fail by the standard by the way. *** This bug has been marked as a duplicate of 323 *** -- What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21809
[Bug rtl-optimization/323] optimized code gives strange floating point results
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-29 19:47 --- *** Bug 21809 has been marked as a duplicate of this bug. *** -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=323
[Bug target/21809] Floating Optimization Bug
--- Additional Comments From themis_hv at yahoo dot co dot uk 2005-05-29 19:51 --- (In reply to comment #19) That is not going to change, the assert is allowed to fail by the standard by the way. Yes, assert fails in some cases (I think of a hundred at moment!). -- What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|DUPLICATE | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21809
[Bug target/21809] Floating Optimization Bug
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-29 19:56 --- (In reply to comment #20) Yes, assert fails in some cases (I think of a hundred at moment!). See now you did not read my comment, I said it is _ALLOWED by the standard to ___FAIL___. How much clearer do you need it? ALSO READ UP on excessive precision. You seem like someone who does not want to do the leg work of getting your programs fixed so you don't depend on this. Note this is how x87 works, live with it. Just stop buying x86 machines if you don't like this. *** This bug has been marked as a duplicate of 323 *** -- What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21809
[Bug rtl-optimization/323] optimized code gives strange floating point results
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-29 19:56 --- *** Bug 21809 has been marked as a duplicate of this bug. *** -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=323
[Bug target/20191] ICE in reload_cse_simplify_operands, on powerpc linux
-- What|Removed |Added GCC build triplet|powerpc-unknown-linux-gnu | GCC host triplet|powerpc-unknown-linux-gnu | GCC target triplet|powerpc-unknown-linux-gnu |powerpc-*-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20191
[Bug target/21809] Floating Optimization Bug
--- Additional Comments From themis_hv at yahoo dot co dot uk 2005-05-29 20:09 --- You seem like someone who does not want to do the leg work of getting your programs fixed so you don't depend on this. Regardless, other poeple dependant on it. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21809
[Bug c++/21808] Uninformative diagnostic for name lookup for template functions
--- Additional Comments From veksler at il dot ibm dot com 2005-05-29
20:33 ---
I disagree.
1. Because it is a template the correct error is supressed.
2. It passes with gcc-3.3, but fails with gcc-3.4.3
This is unlike your example:
template class T struct A { T t; };
// Swap following 2 functions to get conforming C++
template int i struct B {static const int t = i;};
templateclass T void foo1(const AT data);
void foo(const Aint data)
{
foo1((int)data.t);
}
void foo1(int data);
Which works neither with gcc-3.3 nor with gcc-3.4.4
--
What|Removed |Added
Status|RESOLVED|UNCONFIRMED
Resolution|DUPLICATE |
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21808
[Bug c++/21808] Uninformative diagnostic for name lookup for template functions
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-29 20:37 --- But the problem with the error message is the same which is why I closed it as a dup. My point is that being in a template have nothing to do with it here and the error message could be improved yes which is why 17166 is not closed. *** This bug has been marked as a duplicate of 17166 *** -- What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21808
[Bug c++/17166] Improve diagnostic for empty overload set listing the rejected overloads
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-29 20:37 --- *** Bug 21808 has been marked as a duplicate of this bug. *** -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17166
[Bug target/19933] Problem with define of HUGE_VAL in math_c99.
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-05-29 20:45 --- Subject: Bug 19933 CVSROOT:/cvs/gcc Module name:gcc Branch: gcc-3_4-branch Changes by: [EMAIL PROTECTED] 2005-05-29 20:45:44 Modified files: gcc: ChangeLog gcc/testsuite : ChangeLog gcc/fixinc : fixincl.x inclhack.def Added files: gcc/testsuite/gcc.dg: c99-math-double-1.c c99-math-float-1.c c99-math.h c99-math-long-double-1.c gcc/fixinc/tests/base/iso: math_c99.h Log message: PR target/19933 * fixinc/inclhack.def (solaris_math_6_1): New fix. (solaris_math_9): Rewrite and guard with #ifdef __sparc__. * fixinc/fixincl.x: Regenerate. * fixinc/tests/base/iso/math_c99.h: Adjust for above changes. Backport from mainline: 2005-05-19 Eric Botcazou [EMAIL PROTECTED] Joseph S. Myers [EMAIL PROTECTED] * fixinc/inclhack.def: New fixes solaris_math_[1-9]. * fixinc/fixincl.x: Regenerate. * fixinc/tests/base/iso/math_c99.h: New. Backport from mainline: 2005-05-10 Joseph S. Myers [EMAIL PROTECTED] * fixinc/inclhack.def (stdio_stdarg_h, stdio_va_list): Bypass on *-*-solaris2.1[0-9]*, not just *-*-solaris2.1[0-9]. * fixinc/fixincl.x: Regenerate. Backport from mainline: 2004-11-26 Mark Mitchell [EMAIL PROTECTED] * fixinc/inclhack.def (gnu_types): Do not use on Solaris 2.1x. (stdio_va_list): Likewise. (stdio_stdarg.h): Likewise. (solaris_stdio_tag): Add bypass. * fixinc/fixincl.x: Regenerated. testsuite/ * gcc.dg/c99-math.h: New * gcc.dg/c99-math-float-1.c: New test. * gcc.dg/c99-math-double-1.c: Likewise. * gcc.dg/c99-math-long-double-1.c: Likewise. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcconly_with_tag=gcc-3_4-branchr1=2.2326.2.872r2=2.2326.2.873 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gcconly_with_tag=gcc-3_4-branchr1=1.3389.2.398r2=1.3389.2.399 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gcc.dg/c99-math-double-1.c.diff?cvsroot=gcconly_with_tag=gcc-3_4-branchr1=NONEr2=1.1.8.1 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gcc.dg/c99-math-float-1.c.diff?cvsroot=gcconly_with_tag=gcc-3_4-branchr1=NONEr2=1.1.8.1 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gcc.dg/c99-math.h.diff?cvsroot=gcconly_with_tag=gcc-3_4-branchr1=NONEr2=1.1.8.1 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gcc.dg/c99-math-long-double-1.c.diff?cvsroot=gcconly_with_tag=gcc-3_4-branchr1=NONEr2=1.1.8.1 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/fixinc/fixincl.x.diff?cvsroot=gcconly_with_tag=gcc-3_4-branchr1=1.177.4.10r2=1.177.4.11 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/fixinc/inclhack.def.diff?cvsroot=gcconly_with_tag=gcc-3_4-branchr1=1.190.4.10r2=1.190.4.11 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/fixinc/tests/base/iso/math_c99.h.diff?cvsroot=gcconly_with_tag=gcc-3_4-branchr1=NONEr2=1.1.2.1 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19933
[Bug target/19933] Problem with define of HUGE_VAL in math_c99.
--- Additional Comments From ebotcazou at gcc dot gnu dot org 2005-05-29 20:52 --- Patch backported to 3.4 branch. -- What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19933
[Bug target/21315] Unable to link Fortran executables: __builtin_isfinite is undefined
-- Bug 21315 depends on bug 19933, which changed state. Bug 19933 Summary: Problem with define of HUGE_VAL in math_c99. http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19933 What|Old Value |New Value Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21315
[Bug c++/21210] [4.0/4.1 Regression] Trouble with __complex__ types default construction
--- Additional Comments From mmitchel at gcc dot gnu dot org 2005-05-29 21:27 --- See: http://gcc.gnu.org/ml/gcc-patches/2005-05/msg02777.html for additional analysis regarding this PR. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21210
[Bug c++/21784] [3.4/4.0/4.1 Regression] Using vs builtin names
-- 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=21784
[Bug gcov/profile/21810] New: -pg causes libexpat code to crash
When you compile a program with -pg against libexpat 1.95.8 and you call XML_ParserCreate() it does crash. this is not happening, if you don't add -pg. The source I used was distributed with the official MAME source code package (http://www.mame.net/downmain.html - win32 sourcecode, but the related source should be platform-independent). The easiest way to test it, is just to compile the xml2info tool, that part is of MAME, add -pg to compiler and linkers flags and run it, it will crash immediately. Here is the backtrace: Program received signal SIGSEGV, Segmentation fault. 0x0040e456 in poolInit (pool=0x40e44d, ms=0x0) at src/expat/xmlparse.c:5874 5874 pool-blocks = NULL; (gdb) bt #0 0x0040e456 in poolInit (pool=0x40e44d, ms=0x0) at src/expat/xmlparse.c:5874 #1 0x0040d339 in dtdCreate (ms=0x3f2554) at src/expat/xmlparse.c:5428 #2 0x00403193 in parserCreate (encodingName=0x0, memsuite=0x0, nameSep=0x0, dtd=0x0) at src/expat/xmlparse.c:737 #3 0x00402fb7 in XML_ParserCreate_MM (encodingName=0x0, memsuite=0x0, nameSep=0x0) at src/expat/xmlparse.c:671 #4 0x00402f4b in XML_ParserCreate (encodingName=0x0) at src/expat/xmlparse.c:648 #5 0x00402b7c in process (is=0x7803a690, os=0x7803a6b0) at src/xml2info.c:766 #6 0x00402efe in main (argc=1, argv=0x3f24c8) at src/xml2info.c:835 My GCC version: Reading specs from C:/MINGW/BIN/../lib/gcc/mingw32/3.4.2/specs Configured with: ../gcc/configure --with-gcc --with-gnu-ld --with-gnu-as --host= mingw32 --target=mingw32 --prefix=/mingw --enable-threads --disable-nls --enable -languages=c,c++,f77,ada,objc,java --disable-win32-registry --disable-shared --e nable-sjlj-exceptions --enable-libgcj --disable-java-awt --without-x --enable-ja va-gc=boehm --disable-libgcj-debug --enable-interpreter --enable-hash-synchroniz ation --enable-libstdcxx-debug Thread model: win32 gcc version 3.4.2 (mingw-special) -- Summary: -pg causes libexpat code to crash Product: gcc Version: 3.4.2 Status: UNCONFIRMED Severity: normal Priority: P2 Component: gcov/profile AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: oliverst at online dot de CC: gcc-bugs at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21810
[Bug c++/19756] -Wparentheses doesn't warn on ambiguous if in C++
--- Additional Comments From oliverst at online dot de 2005-05-29 23:38 --- If this is not going to be added any time soon for C++, maybe at least the manual should reflect, that it is a C-only warning. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19756
[Bug gcov/profile/21810] -pg causes libexpat code to crash
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-29 23:41 --- Are you sure that this is not a newlib/cygwin bug? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21810
[Bug c/21811] New: Union of odd byte array with integer causes asm constraint to fail
-- Compiler ---
Reading specs from C:/WinAVR/bin/../lib/gcc/avr/3.4.3/specs
Configured with: ../gcc-3.4.3/configure --prefix=m:/WinAVR --build=mingw32
--host=mingw32 --target=avr --enable-languages=c,c++ --with-dwarf2
Thread model: single
gcc version 3.4.3
-- Error message --
avr-gcc -g -Wall -Os -mmcu=atmega16 -DARC -DLED_DDR=DDRB -DLED=PB4
-DLED_PORT=PORTB -DSW_DDR=DDRB -DSW_PORT=PORTB -DSW_PIN=PINB -DSW=PB6
-DF_CPU=1600 -gdwarf-2 -mshort-calls -c -o foo.o foo.c
foo.c: In function `foo':
foo.c:12: internal compiler error: in emit_move_insn, at expr.c:2809
Please submit a full bug report,
with preprocessed source if appropriate.
See URL:http://gcc.gnu.org/bugs.html for instructions.
make: *** [foo.o] Error 1
--- Source ---
#include inttypes.h
void foo (void)
{
union
{
uint16_t word;
uint8_t byte[3];// HERE IS THE BUG
}
bar;
asm volatile (
\tnop\n
: :r (bar) );
}
commentary --
I simplified the test case to the bare essentials.
The error occurs if the union is in SRAM or Registers, but
oddly enough, NOT if it is on the stack (put it there by
taking an address of the union...) If the array byte is
made two long, then this doesn't occur. If word is a long,
then byte needs to be 4 long (or it breaks).
Someone from the avr-gcc list tried this out on the x86 compiler and it failed
there as well (with the union in static ram rather than automatic) so it seems
more generic than just an avr-gcc bug.
--
Summary: Union of odd byte array with integer causes asm
constraint to fail
Product: gcc
Version: 3.4.3
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: larry at barello dot net
CC: gcc-bugs at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21811
[Bug gcov/profile/21810] -pg causes libexpat code to crash
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-29 23:41 --- Also do you have a simple testcase? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21810
[Bug c/21811] Union of odd byte array with integer causes asm constraint to fail
--- Additional Comments From larry at barello dot net 2005-05-29 23:42 --- Created an attachment (id=8987) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8987action=view) test case -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21811
[Bug c/21811] Union of odd byte array with integer causes asm constraint to fail
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-29 23:48 --- *** This bug has been marked as a duplicate of 8788 *** -- What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21811
[Bug inline-asm/8788] ICE in emit_move_insn, at expr.c:3089
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-29 23:48 --- *** Bug 21811 has been marked as a duplicate of this bug. *** -- What|Removed |Added CC||larry at barello dot net http://gcc.gnu.org/bugzilla/show_bug.cgi?id=8788
[Bug inline-asm/8788] ICE in emit_move_insn, at expr.c:3089
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-29 23:48 --- Fixed on the mainline for 4.1.0. -- What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED Target Milestone|--- |4.1.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=8788
[Bug gcov/profile/21810] -pg causes libexpat code to crash
--- Additional Comments From oliverst at online dot de 2005-05-29 23:52 --- I attached a stripped down version of the source. You have to call make maketree and then make xml2info.exe. The resulting executable with the backtrace seen in the initial post. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21810
[Bug gcov/profile/21810] -pg causes libexpat code to crash
--- Additional Comments From oliverst at online dot de 2005-05-29 23:54 --- Created an attachment (id=8988) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8988action=view) isolated source from MAME 0.96u3 call make maketree and then make xml2info.exe -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21810
[Bug target/21810] -pg causes libexpat code to crash
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-29 23:57 --- Hmm, I want to say this is a bug dealing with FASTCALL. -- What|Removed |Added Component|gcov/profile|target http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21810
[Bug target/21810] -pg causes libexpat code to crash
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-30
00:00 ---
Could you try this testcase with -pg on cygwin?
typedef struct STRING_POOL
{
int a;
} STRING_POOL;
typedef struct XML_Memory_Handling_Suite
{
int t;
} XML_Memory_Handling_Suite;
#define FASTCALL __attribute__((stdcall, regparm(3)))
static void FASTCALL
poolInit(STRING_POOL *pool, const XML_Memory_Handling_Suite *ms)
{
pool-a = 1;
}
int main(void)
{
STRING_POOL a;
XML_Memory_Handling_Suite d;
poolInit(a, d);
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21810
[Bug target/21810] -pg causes libexpat code to crash
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-30 00:01 --- I mean mingw32. -- What|Removed |Added GCC target triplet||i686-pc-mingw32 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21810
[Bug gcov/profile/21810] -pg causes libexpat code to crash
--- Additional Comments From oliverst at online dot de 2005-05-30 00:03 --- With -pg: Program received signal SIGSEGV, Segmentation fault. 0x00401329 in [EMAIL PROTECTED] () (gdb) bt #0 0x00401329 in [EMAIL PROTECTED] () #1 0x00401375 in main () Without -pg: Program exited with code 010577614 -- What|Removed |Added Component|target |gcov/profile http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21810
[Bug target/21810] -pg causes libexpat code to crash
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-30 00:04 --- (In reply to comment #8) With -pg: This works on i686-pc-linux-gnu. Hopefully someone will look into this then, this is a target problem. -- What|Removed |Added Component|gcov/profile|target Keywords||wrong-code http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21810
[Bug gcov/profile/21810] -pg causes libexpat code to crash
--- Additional Comments From oliverst at online dot de 2005-05-30 00:05 --- Maybe you should add Danny Smith to the CC list. -- What|Removed |Added Component|target |gcov/profile http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21810
[Bug fortran/20846] inquire(FILE=..., UNIT=...) not flagged as error
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-05-30 00:19 --- Subject: Bug 20846 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2005-05-30 00:19:44 Modified files: gcc/testsuite : ChangeLog Added files: gcc/testsuite/gfortran.dg: inquire_8.f90 Log message: PR fortran/20846 * gfortran.dg/inquire_8.f90: New test. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gccr1=1.r2=1.5556 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gfortran.dg/inquire_8.f90.diff?cvsroot=gccr1=NONEr2=1.1 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20846
[Bug fortran/20846] inquire(FILE=..., UNIT=...) not flagged as error
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-05-30 00:21 --- Subject: Bug 20846 CVSROOT:/cvs/gcc Module name:gcc Branch: gcc-4_0-branch Changes by: [EMAIL PROTECTED] 2005-05-30 00:21:34 Modified files: gcc/fortran: ChangeLog io.c Log message: PR fortran/20846 * io.c (gfc_match_inquire): Implement constraints on UNIT and FILE usage. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/fortran/ChangeLog.diff?cvsroot=gcconly_with_tag=gcc-4_0-branchr1=1.335.2.57r2=1.335.2.58 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/fortran/io.c.diff?cvsroot=gcconly_with_tag=gcc-4_0-branchr1=1.19.10.3r2=1.19.10.4 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20846
[Bug fortran/20846] inquire(FILE=..., UNIT=...) not flagged as error
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-05-30 00:23 --- Subject: Bug 20846 CVSROOT:/cvs/gcc Module name:gcc Branch: gcc-4_0-branch Changes by: [EMAIL PROTECTED] 2005-05-30 00:23:46 Modified files: gcc/testsuite : ChangeLog Added files: gcc/testsuite/gfortran.dg: inquire_8.f90 Log message: PR fortran/20846 * gfortran.dg/inquire_8.f90: New test. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gcconly_with_tag=gcc-4_0-branchr1=1.5084.2.208r2=1.5084.2.209 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gfortran.dg/inquire_8.f90.diff?cvsroot=gcconly_with_tag=gcc-4_0-branchr1=NONEr2=1.1.2.1 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20846
[Bug fortran/20846] inquire(FILE=..., UNIT=...) not flagged as error
--- Additional Comments From kargl at gcc dot gnu dot org 2005-05-30 00:30 --- Fixed. -- What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20846
[Bug fortran/20846] inquire(FILE=..., UNIT=...) not flagged as error
-- What|Removed |Added Target Milestone|--- |4.0.1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20846
[Bug libgcj/20273] LinkedHashMap breaks linked list when access() is called
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-05-30 02:02 --- Subject: Bug 20273 CVSROOT:/cvs/gcc Module name:gcc Branch: gcc-4_0-branch Changes by: [EMAIL PROTECTED] 2005-05-30 02:02:03 Modified files: libjava: ChangeLog libjava/java/util: LinkedHashMap.java Log message: 2005-05-29 Michael Koch [EMAIL PROTECTED] PR libgcj/20273: * java/util/LinkedHashMap.java (access): Set 'root.pred'. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libjava/ChangeLog.diff?cvsroot=gcconly_with_tag=gcc-4_0-branchr1=1.3391.2.79r2=1.3391.2.80 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libjava/java/util/LinkedHashMap.java.diff?cvsroot=gcconly_with_tag=gcc-4_0-branchr1=1.6r2=1.6.2.1 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20273
[Bug target/21760] [4.1 Regression] Powerpc atomic builtins missing PPC405 errata
--- Additional Comments From dje at gcc dot gnu dot org 2005-05-30 01:40 --- This is a regression because libstdc++ previously worked correctly on PPC405 and now it does not. -- What|Removed |Added Summary|Powerpc atomic builtins |[4.1 Regression] Powerpc |missing PPC405 errata |atomic builtins missing ||PPC405 errata http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21760
[Bug libgcj/20273] LinkedHashMap breaks linked list when access() is called
--- Additional Comments From tromey at gcc dot gnu dot org 2005-05-30 02:08 --- I checked this in to 4.0, the trunk, and Classpath. I put the test case in Mauve. I'm not planning to put the fix into 3.4.x, but someone could if they wanted to. -- What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED Target Milestone|--- |4.0.1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20273
[Bug libgcj/20273] LinkedHashMap breaks linked list when access() is called
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-05-30 02:01 --- Subject: Bug 20273 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2005-05-30 02:01:15 Modified files: libjava: ChangeLog libjava/java/util: LinkedHashMap.java Log message: 2005-05-29 Michael Koch [EMAIL PROTECTED] PR libgcj/20273: * java/util/LinkedHashMap.java (access): Set 'root.pred'. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libjava/ChangeLog.diff?cvsroot=gccr1=1.3638r2=1.3639 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libjava/java/util/LinkedHashMap.java.diff?cvsroot=gccr1=1.6r2=1.7 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20273
[Bug gcov/profile/21810] -pg causes libexpat code to crash
--- Additional Comments From dannysmith at users dot sourceforge dot net 2005-05-30 02:55 --- Hello, this is a mingw runtime bug. The mingw version of mcount does not take enough care with saving call-clobbered registers. Please close this bug and submit to mingw.org. Danny -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21810
[Bug other/21812] New: libgcc could use some target specific optimizations
libgcc is currently contains pure C functions with simple (i.e. non-optimal implementations). Allowing individual targets to provide their own versions of the functions could boost performance. i.e. comparing the libgcc C implementation of __popcountdi2 to the assembly version provided in the Opteron optimization manual, we find that the AMD supplied version is half the instructions, branchless, uses no data tables (and thus causes no cache misses), and runs in about 1/3 to 1/2 less time. -- Summary: libgcc could use some target specific optimizations Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P2 Component: other AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: nmiell at comcast dot net CC: gcc-bugs at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21812
