[Bug libstdc++/18414] Performance problem in "operator new" and "operator new[]"

--- Additional Comments From dannysmith at users dot sourceforge dot net 2004-11-10 06:59 --- This is a duplicate of PR 14563 Danny -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18414

[Bug target/18380] [3.4 regression]: _Unwind_FindTableEntry shouldn't be exported from libunwind.so.7

--- Additional Comments From cvs-commit at gcc dot gnu dot org 2004-11-10 06:37 --- Subject: Bug 18380 CVSROOT:/cvs/gcc Module name:gcc Branch: gcc-3_4-branch Changes by: [EMAIL PROTECTED] 2004-11-10 06:37:03 Modified files: gcc: Change

[Bug target/18380] [3.4 regression]: _Unwind_FindTableEntry shouldn't be exported from libunwind.so.7

--- Additional Comments From cvs-commit at gcc dot gnu dot org 2004-11-10 06:33 --- Subject: Bug 18380 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2004-11-10 06:33:28 Modified files: gcc: ChangeLog unwind-dw2.c gcc/c

[Bug target/16975] Tremendous increase in compile times for 3.4.1 with -mcpu=G5

--- Additional Comments From pinskia at gcc dot gnu dot org 2004-11-10 05:14 --- Fixed on the mainline, we get the same compile time with both -mcpu=G4 and -mcpu=G5. -- What|Removed |Added -

[Bug target/6123] __pic__/__PIC__ not defined when -fpic/-fPIC is specified

--- Additional Comments From amodra at bigpond dot net dot au 2004-11-10 05:13 --- No, actually not the next day, but a few days later. Incidentally, the (a) and (b) are from an earlier reply of mine on this subject: On most other targets, -fpic, ie. flag_pic, means two things: a) gene

[Bug target/6123] __pic__/__PIC__ not defined when -fpic/-fPIC is specified

--- Additional Comments From amodra at bigpond dot net dot au 2004-11-10 05:07 --- I made the following reply the day after I said I'd poke around. Somehow it seems to be missing from the gcc-patches archive. Anyway, here it is again: I grepped through the entire slackware linux sour

[Bug target/16480] using -msdata causes internal compiler error

--- Additional Comments From amodra at bigpond dot net dot au 2004-11-10 03:20 --- Fixed mainline and 3.4 -- What|Removed |Added Status|ASSIGNED

[Bug target/16480] using -msdata causes internal compiler error

--- Additional Comments From cvs-commit at gcc dot gnu dot org 2004-11-10 03:14 --- Subject: Bug 16480 CVSROOT:/cvs/gcc Module name:gcc Branch: gcc-3_4-branch Changes by: [EMAIL PROTECTED] 2004-11-10 03:14:42 Modified files: gcc: Change

[Bug fortran/17423] gfortran segfault when compiling FM509.f from NIST testsuite

--- Additional Comments From jvdelisle at verizon dot net 2004-11-10 02:52 --- Argh! Five of the old, three new. Sorry about that. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17423

[Bug fortran/17423] gfortran segfault when compiling FM509.f from NIST testsuite

--- Additional Comments From jvdelisle at verizon dot net 2004-11-10 02:45 --- Latest run of NIST f77 testsuite. There appears to be 3 of the previously reported errors and 5 additional new ones. GNU Fortran 95 (GCC 4.0.0 20041108 (experimental)) Copyright (C) 2004 Free Software Founda

Re: No warning when breaking strict-aliasing rules despite -Wstrict-aliasing

Anders Torger <[EMAIL PROTECTED]> wrote: > I found a case where GCC does not warn even with > -Wstrict-aliasing, but makes incorrect asm code anyway. > unsigned long > hash(void *key) > { > unsigned long long u[1]; > u[0] = *(unsigned long long *)key; > return ((unsigned long *)u)

[Bug target/17493] [3.3 Regression] powerpc-linux build failure

--- Additional Comments From amodra at bigpond dot net dot au 2004-11-10 02:30 --- Closing, since the binutils patch that rejects cmpi has now been reverted. It doesn't seem worth backporting to 3.3 -- What|Removed |Added -

[Bug fortran/14993] RAN (extension) intrinsic/function not supported

-- Bug 14993 depends on bug 17590, which changed state. Bug 17590 Summary: Standard conformance should take intrinsics into account. http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17590 What|Old Value |New Value

[Bug fortran/17590] Standard conformance should take intrinsics into account.

--- Additional Comments From pbrook at gcc dot gnu dot org 2004-11-10 02:25 --- Fixed. -- What|Removed |Added Status|REOPENED|RESOLVED

[Bug tree-optimization/18412] missed vectorization opportunity

--- Additional Comments From pinskia at gcc dot gnu dot org 2004-11-10 02:21 --- Yes but it is not done right, note that if I do this: #include #include static int size; int main() { int *x; x = (int *)malloc(sizeof(int) * size); for (int i = 0; i < size; i++) x[i] = 7; r

[Bug fortran/18218] Miscompare in sixtrack benchmark caused by loss of precision

--- Additional Comments From cvs-commit at gcc dot gnu dot org 2004-11-10 02:19 --- Subject: Bug 18218 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2004-11-10 02:19:27 Modified files: libgfortran: config.h.in configure configure.ac

[Bug tree-optimization/18412] missed vectorization opportunity

--- Additional Comments From giovannibajo at libero dot it 2004-11-10 02:18 --- Isn't that what attribute malloc stands for? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18412

[Bug fortran/18218] Miscompare in sixtrack benchmark caused by loss of precision

--- Additional Comments From cvs-commit at gcc dot gnu dot org 2004-11-10 02:16 --- Subject: Bug 18218 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2004-11-10 02:16:08 Modified files: gcc/testsuite : ChangeLog libgfortran: C

[Bug c++/11078] [ABI] ICE in write_type with typeof and templates

--- Additional Comments From pinskia at gcc dot gnu dot org 2004-11-10 02:00 --- *** Bug 18413 has been marked as a duplicate of this bug. *** -- What|Removed |Added

[Bug c++/18413] error in cp/mangle.c:write_type

--- Additional Comments From pinskia at gcc dot gnu dot org 2004-11-10 02:00 --- *** This bug has been marked as a duplicate of 11078 *** -- What|Removed |Added

[Bug c++/18413] error in cp/mangle.c:write_type

--- Additional Comments From kong at ece dot ucdavis dot edu 2004-11-10 01:57 --- Created an attachment (id=7512) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=7512&action=view) test.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18413

[Bug c++/18410] GCC does not warn about hidden methods

--- Additional Comments From tron dot thomas at verizon dot net 2004-11-10 01:56 --- Subject: Re: GCC does not warn about hidden methods I tried a serach before I entered the bug. I couldn't find any results. pinskia at gcc dot gnu dot org wrote: >--- Additional Comments From pi

[Bug c++/18413] New: error in cp/mangle.c:write_type

"cc1plus test.c" gives this error: test.c:161: internal compiler error: in write_type, at cp/mangle.c:1579 Please submit a full bug report, -- Summary: error in cp/mangle.c:write_type Product: gcc Version: 3.4.3 Status: UNCONFIRMED Severity:

[Bug c/18411] Warning not legitimate

--- Additional Comments From joseph at codesourcery dot com 2004-11-10 01:41 --- Subject: Re: Warning not legitimate On Wed, 10 Nov 2004, manus at eiffel dot com wrote: > I believe we do not have the right definition of unspecified behavior. Going We're talking about undefined behav

[Bug c/18411] Warning not legitimate

--- Additional Comments From pinskia at gcc dot gnu dot org 2004-11-10 01:26 --- extern void f(); really means extern void f(...); -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18411

[Bug c/18411] Warning not legitimate

--- Additional Comments From manus at eiffel dot com 2004-11-10 01:24 --- I believe we do not have the right definition of unspecified behavior. Going back to my initial post: extern void f(); void g(char a) { ((void (*) (char)) f)(a); } Knowing that actually `f' has been declared

[Bug rtl-optimization/18294] [4.0 Regression] ICE in rtl_verify_flow_info during bootstrap

--- Additional Comments From wilson at gcc dot gnu dot org 2004-11-10 01:22 --- See comments in http://gcc.gnu.org/ml/gcc/2004-11/msg00316.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18294

[Bug tree-optimization/18412] missed vectorization opportunity

--- Additional Comments From pinskia at gcc dot gnu dot org 2004-11-10 01:17 --- The problem is that we don't record that malloc returns a new current unaliasable memory location and that loop im is not moving out because the aliasing info says they can alias when that is not true. -

[Bug c/18411] Warning not legitimate

--- Additional Comments From joseph at codesourcery dot com 2004-11-10 01:15 --- Subject: Re: Warning not legitimate On Wed, 10 Nov 2004, manus at eiffel dot com wrote: > Ok, so why don't you generate the warning only when it makes sense. In my > original case, I was passing a char a

[Bug tree-optimization/18412] New: missed vectorization opportunity

I'm not sure if this is a missed case or is just not yet implemented. I'm using gcc 4.0.0 20041108 with -O3 -ftree-vectorize -fdump-tree-vect-stats -march=pentium4 -g -ggdb: the following *is* vectorizable: #include #include void foo(int n, int *x) { for (int i = 0; i < n; i++) x[i] = 7;

[Bug c/18411] Warning not legitimate

--- Additional Comments From manus at eiffel dot com 2004-11-10 00:59 --- Ok, so why don't you generate the warning only when it makes sense. In my original case, I was passing a char and tell the C compiler it was a function pointer expecting a char. In this scenario it should not pro

[Bug c/18411] Warning not legitimate

--- Additional Comments From pinskia at gcc dot gnu dot org 2004-11-10 00:47 --- We cannot do 1 as that is not allowed by the C standard (or at least a DR report of it). Also the reason why this was changed was because the tree inliner was crashing on things like this if the type was

[Bug c/18411] Warning not legitimate

--- Additional Comments From manus at eiffel dot com 2004-11-10 00:42 --- Thanks for your answer. I see that following the ANSI C standard forces you to do something. But I believe the right thing to do is: 1 - make it a compile time error (better to catch those errors at compile time

[Bug c/18411] Warning not legitimate

--- Additional Comments From pinskia at gcc dot gnu dot org 2004-11-09 23:51 --- As said before this is undefined code. -- What|Removed |Added Status|UNCONFIRMED

[Bug c/18411] Warning not legitimate

--- Additional Comments From joseph at codesourcery dot com 2004-11-09 23:47 --- Subject: Re: Warning not legitimate On Tue, 9 Nov 2004, manus at eiffel dot com wrote: > extern void f(); > > void g(int a) { > void * fnptr = f; > > ((void (*) (int)) fnptr) (a); /* Ok. */

[Bug c/18411] Warning not legitimate

--- Additional Comments From manus at eiffel dot com 2004-11-09 23:34 --- Also one thing I forgot to add. Is that if you replace `char' by `int' then there is no warning at all: extern void f(); void g(int a) { void * fnptr = f; ((void (*) (int)) fnptr) (a); /* Ok. */

[Bug objc/18408] [4.0 Regression] ICE compiling code that involves casting classes

--- Additional Comments From zlaski at apple dot com 2004-11-09 23:34 --- I'll take a look. -- What|Removed |Added Status|NEW |ASSIGNED

[Bug c/18411] Warning not legitimate

--- Additional Comments From manus at eiffel dot com 2004-11-09 23:32 --- This is not undefined, I know which feature I'm calling. It is `f'. Moreover I provide the right function cast which matches how `f' is actually declared. What strikes me the most is that you reject: ((void (*)

[Bug AWT/16825] Bad results for QuadCurve2D.solveQuadratic

--- Additional Comments From pinskia at gcc dot gnu dot org 2004-11-09 23:32 --- Note the java "standard" does not require the FPU set to double-precision except when working in strict mode (this was changed after 1.0 IIRC). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16825

[Bug c/18411] Warning not legitimate

--- Additional Comments From pinskia at gcc dot gnu dot org 2004-11-09 23:29 --- The warning is correct: extern void f(); void g(void) { ((void (*) (char)) f)(a); } this is undefined code which means we could anything at runtime (even wipe out your HD). -- What|Remo

[Bug objc/18408] [4.0 Regression] ICE compiling code that involves casting classes

--- Additional Comments From pinskia at gcc dot gnu dot org 2004-11-09 23:26 --- This is a recent regression because it was fine with 20041019. I think it was caused by: 2004-11-02 Ziemowit Laski <[EMAIL PROTECTED]> * c-lang.c (LANG_HOOKS_TYPES_COMPATIBLE_P): Remove.

[Bug c/18411] New: Warning not legitimate

I'm getting the following compilation warning output: gcc -c a.c -save-temps a.c: In function `g': a.c:8: warning: function called through a non-compatible type a.c:8: note: if this code is reached, the program will abort while compiling the following code (content of a.i): # 1 "a.c" # 1 "" # 1

[Bug AWT/16825] Bad results for QuadCurve2D.solveQuadratic

--- Additional Comments From sven at physto dot se 2004-11-09 23:22 --- This isn't a Awt or libgcj bug itself, but rather an effect of the extended-mode of FPU being the default leading to inconsistent results with 64-bit doubles. A suggestion for a 'fix' is to set the FPU to 64-bit dou

[Bug c++/18410] GCC does not warn about hidden methods

--- Additional Comments From pinskia at gcc dot gnu dot org 2004-11-09 23:21 --- Confirmed, I thought I saw this in a different bug. -- What|Removed |Added Statu

[Bug c++/18410] GCC does not warn about hidden methods

-- What|Removed |Added Severity|normal |enhancement Keywords||diagnostic http://gcc.gnu.org/bugzilla/show_bug.c

[Bug objc/18408] [4.0 Regression] ICE compiling code that involves casting classes

--- Additional Comments From pinskia at gcc dot gnu dot org 2004-11-09 23:16 --- Confirmed, reduced testcase: @interface List { @public int firstLink; } @end @interface ListIndex_linked { @public List *collection; int link; } @end @interface List_linked: List @end @implementatio

[Bug c++/18410] New: GCC does not warn about hidden methods

GCC will not issue a compiler warning when a virtual inheritted method is hidden Steps: Use the following code to create a file named HideMethod.cpp class Parent { public: virtual ~Parent(){} virtual void Method(){} }; class Child : public Parent { public: virtual v

[Bug c++/11393] Initializer of static const float class member is not legal in c++98

--- Additional Comments From pinskia at gcc dot gnu dot org 2004-11-09 23:09 --- *** Bug 18409 has been marked as a duplicate of this bug. *** -- What|Removed |Added

[Bug c++/18409] Invalid C++ accepted

--- Additional Comments From pinskia at gcc dot gnu dot org 2004-11-09 23:09 --- Yes it was/is G++ extension, use -pedantic to get error/warning. This is a dup of bug 11393. *** This bug has been marked as a duplicate of 11393 *** -- What|Removed |A

[Bug c++/18409] New: Invalid C++ accepted

Consider the following: cut here class Foo { public: static const double d = 3.3; // Invalid see 9.4.2.1 }; end Is this possibly a g++ extension? -- Summary: Invalid C++ accepted Product: gcc Version: 3.4.2 Status: UNCONFIRME

[Bug objc/18408] ICE compiling code that involves casting classes

cs from /packages/gcc/lib/gcc/i686-pc-linux-gnu/4.0.0/specs Configured with: /src/gcc/configure --prefix=/packages/gcc --srcdir=/src/gcc Thread model: posix gcc version 4.0.0 20041109 (experimental) $ gcc in.m -lobjc in.m: In function '-[ListIndex(linked) _next]': in.m:35: internal c

[Bug objc/18408] New: ICE compiling code that involves casting classes

This program causes an ICE in today's sources. -- Summary: ICE compiling code that involves casting classes Product: gcc Version: 4.0.0 Status: UNCONFIRMED Severity: normal Priority: P2 Component: objc AssignedTo: u

[Bug libgcj/18405] implement java.lang.Package#isCompatibleWith(String)

--- Additional Comments From tromey at gcc dot gnu dot org 2004-11-09 22:18 --- Actually we have Package.isCompatibleWith, what we don't have is any version setting on java.lang or other built-in packages. Strangely the BEA JRE dies on this: opsy. java t java.lang.NumberFormatException

[Bug fortran/18218] Miscompare in sixtrack benchmark caused by loss of precision

--- Additional Comments From pbrook at gcc dot gnu dot org 2004-11-09 22:11 --- I suspect this is an IO library bug. -- What|Removed |Added AssignedTo|unassigned at

[Bug libgcj/18376] java.io.BufferedWriter outputing extraneous characters?

--- Additional Comments From tromey at gcc dot gnu dot org 2004-11-09 22:11 --- I downloaded the test case and modified it to print the number of characters it read. I can confirm that for me it does in fact loop: opsy. gij TestGcj.IoTest ../demo/buildlog.txt Out.txt fileLength = 2290

[Bug fortran/18218] Miscompare in sixtrack benchmark caused by loss of precision

-- What|Removed |Added Status|NEW |ASSIGNED Last reconfirmed|2004-11-08 14:54:16 |2004-11-09 22:09:51 date|

Re: -O2 bug in gcc 3.2, 3.3 and 3.4 with 64 bit integers on x86

Anders Torger <[EMAIL PROTECTED]> writes: > Perhaps GCC should not accept code that will result in undefined > behaviour This is impossible because there is nothing wrong when the code is never executed. Andreas. -- Andreas Schwab, SuSE Labs, [EMAIL PROTECTED] SuSE Linux AG, Maxfeldstraße 5,

[Bug middle-end/18293] Redundant copy operation introduced by expand

--- Additional Comments From pinskia at gcc dot gnu dot org 2004-11-09 21:33 --- Patch posted here: . Mine. -- What|Removed |Added -

[Bug c/18322] [3.3/3.4/4.0 Regression] __func__ diagnostic in bad location

--- Additional Comments From cvs-commit at gcc dot gnu dot org 2004-11-09 21:22 --- Subject: Bug 18322 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2004-11-09 21:22:27 Modified files: gcc: ChangeLog c-common.c gcc/tes

[Bug target/18019] [4.0 Regression] -march=pentium4 generates word fetch instead of byte fetch

--- Additional Comments From roger at eyesopen dot com 2004-11-09 20:56 --- I agree with Stuart :> Although both of the patches he investigated will cure the problem, reverting mine will generate a movzbl, whilst disabling the TARGET_PARTIAL_... bits will generate a "movb". As hinted i

[Bug target/18342] mmix-knuth-mmixware testsuite failure: gcc.dg/builtins-20.c

--- Additional Comments From pinskia at gcc dot gnu dot org 2004-11-09 20:21 --- Both this and PR 18341 can be "fixed" by editing "gcc.dg/builtins-config.h" or make sure that _NEWLIB_VERSION is define when including limits. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18342

[Bug c++/18386] ICE in __static_initialization_and_destruction_0

-- What|Removed |Added Keywords||ice-on-valid-code http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18386

[Bug target/18309] ICE on valid code in print_operand_address, at config/rs6000/rs6000.c:9678 (procps-3.2.4)

-- What|Removed |Added CC||pinskia at gcc dot gnu dot ||org Severity|critical

[Bug objc/18406] [3.4 Regression] ICE compiling Objective C code with long double arguments

--- Additional Comments From pinskia at gcc dot gnu dot org 2004-11-09 19:45 --- Fixed on the mainline, will apply to the 3.4 branch when I get home. -- What|Removed |Added

[Bug objc/18406] [3.4/4.0 Regression] ICE compiling Objective C code with long double arguments

--- Additional Comments From cvs-commit at gcc dot gnu dot org 2004-11-09 19:44 --- Subject: Bug 18406 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2004-11-09 19:44:38 Modified files: gcc/objc : ChangeLog objc-act.c gcc/tes

[Bug target/18019] [4.0 Regression] -march=pentium4 generates word fetch instead of byte fetch

--- Additional Comments From stuart at apple dot com 2004-11-09 19:34 --- I agree with Roger. I'm suspicious of the "0,1,2 ... TARGET_PARTIAL_xx" clauses of the "*movqi_1" pattern. (Also the analogous parts of "*movhi_1".) I've tried reverting Roger's patch, and excising the TARGET_

Re: No warning when breaking strict-aliasing rules despite -Wstrict-aliasing

On Nov 9, 2004, at 2:23 PM, Anders Torger wrote: gcc 2.95 generates correct code. It just generates code which you expected not the code which the C standard says it is undefined (oh by the way we could wipe your HD if you invoke undefined behavior). Also a DR report says we cannot error out on u

[Bug objc/18406] [3.4/4.0 Regression] ICE compiling Objective C code with long double arguments

--- Additional Comments From pinskia at gcc dot gnu dot org 2004-11-09 19:24 --- Patch here: . Mine. -- What|Removed |Added --

No warning when breaking strict-aliasing rules despite -Wstrict-aliasing

/* on x86, sizeof(long long) == 8, sizeof(long) == 4 Ok, I'm back. While fixing my strict aliasing breakerage as Andreas told me to, I found a case where GCC does not warn even with -Wstrict-aliasing, but makes incorrect asm code anyway. So I started to investigate which optimisation

[Bug objc/18406] [3.4/4.0 Regression] ICE compiling Objective C code with long double arguments

--- Additional Comments From pinskia at gcc dot gnu dot org 2004-11-09 19:15 --- Confirmed on x86 the size of a long double is 96bits which is what is causing the ICE. -- What|Removed |Added ---

[Bug c++/18407] [3.4/4.0 Regression] ICE with mem-fun-ptr as template parameter for nested function template (build_base_path, cp/class.c)

--- Additional Comments From pinskia at gcc dot gnu dot org 2004-11-09 19:10 --- : Search converges between 2002-12-14-trunk (#159) and 2002-12-29-trunk (#160). Confirmed. -- What|Removed |Added ---

[Bug c++/18407] New: [Regression] ICE with mem-fun-ptr as template parameter for nested function template (build_base_path, cp/class.c)

ICE in g++ 3.4.0 (cygwin) and 3.4.3 ("GNU C++ version 3.4.3 (i686-pc-cygwin)"). OK for g++ 3.3.1 ("GNU C++ version 3.3.1 (mingw special 20030804-1) (mingw32)" and "GNU C++ version 3.3.1 (cygming special) (i686-pc-cygwin)"). Test case (legal code!): template struct the_base{ template void foo(

[Bug objc/18406] ICE compiling Objective C code with long double arguments

--- Additional Comments From mgd at santafe dot edu 2004-11-09 18:15 --- Created an attachment (id=7505) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=7505&action=view) Objective C file that crashes compiler -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18406

[Bug objc/18406] New: ICE compiling Objective C code with long double arguments

gcc test.m -lobjc test.m:12: internal compiler error: in encode_type, at objc/objc-act.c:7249 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html> for instructions. -- Summary: ICE compiling Objective C code with long double

[Bug target/18019] [4.0 Regression] -march=pentium4 generates word fetch instead of byte fetch

--- Additional Comments From roger at eyesopen dot com 2004-11-09 18:10 --- I believe that the bug is a latent problem that was only exposed by my patch. The *movqi_1 (and *movhi_1) pattern(s) have two attributes "type" and "mode". The mode attribute indicates the RTL machine mode the mo

Re: -O2 bug in gcc 3.2, 3.3 and 3.4 with 64 bit integers on x86

Aha, I see the problem now, I'll go fix my code. Not entirely obvious to a novice like me... Perhaps GCC should not accept code that will result in undefined behaviour (that is with -fstrict-aliasing, -Wstrict-aliasing should be automatically enabled and any such warnings should be considered

[Bug fortran/17472] namelist does not handle arrays

--- Additional Comments From tobi at gcc dot gnu dot org 2004-11-09 18:00 --- *** Bug 18396 has been marked as a duplicate of this bug. *** -- What|Removed |Added

[Bug fortran/18396] namelist of array in derived type unimplemented

--- Additional Comments From tobi at gcc dot gnu dot org 2004-11-09 18:00 --- *** This bug has been marked as a duplicate of 17472 *** -- What|Removed |Added S

[Bug rtl-optimization/18401] [4.0.0 Regression] Bootstrap failure on all ARM targets due to incorrect GCSE

-- What|Removed |Added Component|bootstrap |rtl-optimization http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18401

[Bug tree-optimization/18403] FAILs to vectorize testcases on ppc64-linux

--- Additional Comments From pinskia at gcc dot gnu dot org 2004-11-09 17:55 --- Confirmed. -- What|Removed |Added CC||spop at gc

[Bug java/18305] Class initialization optimization is not done when compiled from .class

--- Additional Comments From pinskia at gcc dot gnu dot org 2004-11-09 17:50 --- Mine, I posted a patch here: . -- What|Removed |Added --

[Bug target/18230] SPARC VIS instructions are not generated by GCC

--- Additional Comments From cvs-commit at gcc dot gnu dot org 2004-11-09 17:06 --- Subject: Bug 18230 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2004-11-09 17:06:04 Modified files: gcc: ChangeLog gcc/doc: m

[Bug libgcj/18405] implement java.lang.Package#isCompatibleWith(String)

--- Additional Comments From pinskia at gcc dot gnu dot org 2004-11-09 16:57 --- Confirmed. -- What|Removed |Added CC||pinskia at

Re: -O2 bug in gcc 3.2, 3.3 and 3.4 with 64 bit integers on x86

Anders Torger <[EMAIL PROTECTED]> writes: > Compiler makes same mistake Fix your code. > the only difference is the warning Which is the whole point. Your example is violating the strict aliasing rules and thus invoking undefined behaviour. http://gcc.gnu.org/onlinedocs/gcc-3.4.3/gcc/Optimize

[Bug libgcj/18405] New: implement java.lang.Package#isCompatibleWith(String)

We've run into a piece of code that refuses to run under GIJ due to the following check: Package p = Package.getPackage("java.lang"); if (!p.isCompatibleWith("1.4")) { // ... refuse to run } Tom Tromey says Package#isCompatibleWith is not implemented. (I haven't looked at the relevan

[Bug target/18402] [3.3 regression] ICE in in gen_split_1204 on i686-pc-linux-gnu target

--- Additional Comments From reichelt at gcc dot gnu dot org 2004-11-09 16:35 --- Here's a smaller testcase: === double c, d, e; void foo() { if (e-1) d=0; else d=0; c=d; if (e) d=0; } === It crashes GCC 3.3.x when co

[Bug c++/18123] [3.4/4.0 regression] ICE on templated enum

--- Additional Comments From lerdsuwa at gcc dot gnu dot org 2004-11-09 16:18 --- Old patch retracted, new patch in progress. -- What|Removed |Added Keywords|patch

Re: -O2 bug in gcc 3.2, 3.3 and 3.4 with 64 bit integers on x86

Compiler makes same mistake, the only difference is the warning at compile time, which can be avoided with this casting trick: return ((unsigned long *)(void *)&ull)[0] ^ ((unsigned long *)(void *)&ull)[1]; /Anders On Tuesday 09 November 2004 16.56, you wrote: > Anders Torger <[EMAIL PROTEC

[Bug bootstrap/18367] make check fails with fixinclude problem

--- Additional Comments From James dot W dot Mckelvey at jpl dot nasa dot gov 2004-11-09 16:10 --- I see this also on sparc-sun-solaris2.7. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18367

Re: -O2 bug in gcc 3.2, 3.3 and 3.4 with 64 bit integers on x86

Anders Torger <[EMAIL PROTECTED]> writes: > unsigned long > hash(void *key) > { > unsigned long long ull; > ull = *(unsigned long long *)key; > return ((unsigned long *)&ull)[0] ^ ((unsigned long *)&ull)[1]; Try -Wstrict-aliasing. Andreas. -- Andreas Schwab, SuSE Labs, [EMAIL PROTE

[Bug c++/18276] [4.0 Regression] template classes that are friends of template classes

--- Additional Comments From lerdsuwa at gcc dot gnu dot org 2004-11-09 16:00 --- Taking care of it. -- What|Removed |Added AssignedTo|unassigned at gcc dot gnu |l

[Bug target/18402] [3.3 regression] ICE in in gen_split_1204 on i686-pc-linux-gnu target

-- What|Removed |Added Target Milestone|--- |3.3.6 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18402

[Bug target/18404] unnecessary sll when -mint64 (MIPS)

-- What|Removed |Added Summary|unnecessary sll when -mint64|unnecessary sll when -mint64 ||(MIPS) http://gcc.gnu.org/bugzil

[Bug target/18404] New: unnecessary sll when -mint64

Configured with: --target=mips-elf --program-suffix=.mips --with-newlib --without-headers --enable-languages=c,c++,objc -v Thread model: single gcc version 3.4.2 File /tmp/gcctest_01.c: typedef signed char t_SI __attribute__ ((__mode__(SI))); t_SI inc_SI (t_SI v) { return ++v; } Command li

[Bug regression/18403] New: FAILs to vectorize testcases on ppc64-linux

We get the following failures on powerpc64-suse-linux: FAIL: gcc.dg/vect/vect-46.c scan-tree-dump-times vectorized 1 loops 1 FAIL: gcc.dg/vect/vect-50.c scan-tree-dump-times vectorized 1 loops 1 FAIL: gcc.dg/vect/vect-52.c scan-tree-dump-times vectorized 1 loops 1 FAIL: gcc.dg/vect/vect-58.c scan-t

[Bug target/18402] New: [3.3 regression] ICE in in gen_split_1204 on i686-pc-linux-gnu target

Hi, i get an ICE with this reduced testcase: --- typedef struct _Parameters Parameters; typedef double real_T; typedef struct _BlockIO { real_T bio1; real_T bio2; real_T bio3; real_T bio4; real_T bio5; real_T bio6; real_T bio7; real_T bio8;

[Bug target/17982] [4.0 regression] asm declaration ignored due to conflict with previous rename

--- Additional Comments From schwab at suse dot de 2004-11-09 15:47 --- This is the change that broke this: 2004-06-20 Zack Weinberg <[EMAIL PROTECTED]> * c-common.h (has_c_linkage): New interface. ... -- What|Removed |Added -

[Bug bootstrap/18401] [4.0.0 Regression] Bootstrap failure on all ARM targets due to incorrect GCSE

--- Additional Comments From rearnsha at gcc dot gnu dot org 2004-11-09 15:47 --- Subject: Re: [4.0.0 Regression] Bootstrap failure on all ARM targets due to incorrect GCSE On Tue, 2004-11-09 at 15:09, rearnsha at gcc dot gnu dot org wrote: > --- Additional Comments From re

-O2 bug in gcc 3.2, 3.3 and 3.4 with 64 bit integers on x86

/* C program below. This mail can be extracted into test.c on x86, sizeof(long long) == 8, sizeof(long) == 4 gcc -O2 -S test.c hash: pushl %ebp movl%esp, %ebp subl$8, %esp movl-4(%ebp), %eax xorl-8(%ebp), %eax

[Bug bootstrap/18401] [4.0.0 Regression] Bootstrap failure on all ARM targets due to incorrect GCSE

-- What|Removed |Added CC||pinskia at gcc dot gnu dot ||org Target Milestone|---

  1   2   3   >