[Bug libgcj/19677] invalid "may not have been initialized" error

--- Additional Comments From wasabi at larvalstage dot net 2005-01-28 19:23 --- Oh yes, of course: runtime.jar: [mkdir] Created dir: /tmp/ram/eclipse-3.0.1/source-tree/plugins/org.eclipse.core.runtime/temp.folder/runtime.jar.bin [javac] Compiling 158 source files to /tmp/ram/ecl

[Bug java/19677] invalid "may not have been initialized" error

--- Additional Comments From pinskia at gcc dot gnu dot org 2005-01-28 19:35 --- Confirmed, reduced to: class a1 { public int f(){return 1;} } class t { Object f; void g(a1 a) {} void f() { final a1 a; a = new a1 () { public int f(){return 0;}}; g(a); } } --

[Bug java/19677] invalid "may not have been initialized" error

--- Additional Comments From pinskia at gcc dot gnu dot org 2005-01-28 19:43 --- Related to bug 16839. The problem might be the same problem after all because final are collected for anonymous inner classes. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19677

[Bug tree-optimization/19676] Loop optimizer fails to reverse simple loop

--- Additional Comments From pinskia at gcc dot gnu dot org 2005-01-28 19:54 --- Confirmed, we should be able to do this on the tree level but don't for testloop2, testloop3, testloop4. To answer this question: * - why is gcc inconsistent in loop reversal bounds Because sometimes

[Bug tree-optimization/19676] Loop optimizer fails to reverse simple loop

--- Additional Comments From andrewhutchinson at cox dot net 2005-01-28 20:15 --- Subject: Re: Loop optimizer fails to reverse simple loop GCC 3.3.1 did reverse testloop3 but not testloop2() or testloop(4). So 4.0 gets 4/5 right an 3.3.1 3/5 right. Its complicated by other optimisa

[Bug libgcj/19649] java.util.Date.getTimezoneOffset returns negated output

--- Additional Comments From walters at redhat dot com 2005-01-28 20:16 --- Yeah, I'm almost positive it's the cause. At least I narrowed down this behavior difference in JDK versus gcj, but it's possible there's another bug in there. Is the test suite patch for mauve? I think they'd

[Bug c++/19628] [3.4/4.0 Regression] g++ no longer accepts __builtin_constant_p in constant-expressions

--- Additional Comments From austern at apple dot com 2005-01-28 20:17 --- This was undoubtedly caused by Mark's large checkin on 2003-01-29, which included changes to constant-expression handling. I do not believe the __builtin_constant_p change was deliberate. The intent behind th

[Bug target/15384] Lines witout effect in t-m68hc11-gas file

--- Additional Comments From ciceron at gcc dot gnu dot org 2005-01-28 20:31 --- Mine. The bug is present since 3.0 I guess and should be fixed in 3.3.6, 3.4.4 and 4.0. It does not affect the behavior but increases a little the size of libgcc. -- What|Removed

[Bug target/16925] ICE when building a m68hc11 cross-compiler on 64-bit architectures

--- Additional Comments From ciceron at gcc dot gnu dot org 2005-01-28 20:34 --- Mine. -- What|Removed |Added AssignedTo|unassigned at gcc dot gnu |ciceron at gcc

[Bug c++/19662] [FEATURE REQUEST] Need an option preventing any atexit object destructions

--- Additional Comments From yuri at tsoft dot com 2005-01-28 20:54 --- > If your objects are simple and do not need destruction, just don't > define destructors. > > -- Gaby Disagree, it may only be determined after the optimization that destructor is actuall empty. Yuri -- http:/

[Bug libgcj/10353] [3.3/3.4/4.0 regression] Java testsuite failures

--- Additional Comments From pinskia at gcc dot gnu dot org 2005-01-28 21:04 --- Removing target milestone as this is a java related problem and per: . -- What|Removed |Added -

[Bug libgcj/19649] java.util.Date.getTimezoneOffset returns negated output

-- What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed||1 Last reconfirmed|-00-00 00:00:00 |2005-01-

[Bug target/15384] Lines witout effect in t-m68hc11-gas file

--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-01-28 22:08 --- Subject: Bug 15384 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2005-01-28 22:08:17 Modified files: gcc: ChangeLog gcc/config/m68hc11

[Bug target/15384] Lines witout effect in t-m68hc11-gas file

--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-01-28 22:18 --- Subject: Bug 15384 CVSROOT:/cvs/gcc Module name:gcc Branch: gcc-3_4-branch Changes by: [EMAIL PROTECTED] 2005-01-28 22:18:27 Modified files: gcc: Change

[Bug target/15384] Lines witout effect in t-m68hc11-gas file

--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-01-28 22:21 --- Subject: Bug 15384 CVSROOT:/cvs/gcc Module name:gcc Branch: gcc-3_3-branch Changes by: [EMAIL PROTECTED] 2005-01-28 22:21:39 Modified files: gcc: Change

[Bug target/15384] Lines witout effect in t-m68hc11-gas file

--- Additional Comments From ciceron at gcc dot gnu dot org 2005-01-28 22:25 --- Fixed in 3_3, 3_4 and main. -- What|Removed |Added Status|ASSIGNED

[Bug c++/19662] [FEATURE REQUEST] Need an option preventing any atexit object destructions

--- Additional Comments From gdr at integrable-solutions dot net 2005-01-28 22:41 --- Subject: Re: [FEATURE REQUEST] Need an option preventing any atexit object destructions "yuri at tsoft dot com" <[EMAIL PROTECTED]> writes: | > If your objects are simple and do not need destruction

[Bug libfortran/19668] endless loop on read(10,*) with DOS file

--- Additional Comments From Thomas dot Koenig at online dot de 2005-01-28 22:47 --- Ouch, I should read my test programs before I post bug reports. Resolving as invalid. Thomas -- What|Removed |Added

[Bug libfortran/19678] New: DOS files don't work for list directed input

This time, the right bug report... CR-LF (the DOS convenction for text files) as record separators don't work for list-directed input. $ cat dosfile.f program main write (10,'(2A)') '1',achar(13) rewind(10) read(10,*) n print *,n end $ gfortran dosfile.f $ ./a.

[Bug libfortran/19679] New: DOS files don't work for formatted input if line length is exceeded

CR-LF (the DOS convenction for text files) as record separators don't work well for formatted input, either: $ cat dosfile-2.f program main write (12,'(2A)') ' 1',achar(13) write (12,'(2A)') ' 2',achar(13) rewind(12) read(12,'(I4)') n1 print *,n1 read(

[Bug libstdc++/19656] libstdc++ testsuite results differ if bootstrap gcc 4.0 using some gcc 4.0 version or early (gcc 3.4.3) gcc version at FreeBSD

--- Additional Comments From ljrittle at gcc dot gnu dot org 2005-01-28 23:32 --- Yes, the issue involves how the compiler used to bootstrap stage 1 is configured and itself installed (is it in /usr/local? what ports have headers installed there?). On FreeBSD 5.3, I see this problem whe

[Bug rtl-optimization/13300] [3.3/3.4/4.0 regression] Variable incorrectly identified as a biv

--- Additional Comments From echristo at redhat dot com 2005-01-28 23:33 --- I just tried this in mainline and it appears to be fixed (at least the testcase works without error). -- What|Removed |Added -

[Bug rtl-optimization/19680] New: [missed-optimization] gcc4 is really reluctant to use fancy x86 addressing modes

When comparing the kind of code ICC outputs vs gcc, it's really obvious gcc could make a better use of x86 baroque addressing modes. More specifically i rarely ever see it using the *8 scale factor, even when addressing nicely power-of-2 sized stuff, and that's definitely a performance problem when

[Bug rtl-optimization/19680] [missed-optimization] gcc4 is really reluctant to use fancy x86 addressing modes

--- Additional Comments From tbptbp at gmail dot com 2005-01-28 23:35 --- Created an attachment (id=8095) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8095&action=view) Various address generation snippets -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19680

[Bug debug/8354] Incorrect DWARF-2/3 emitted for const + array

--- Additional Comments From wilson at gcc dot gnu dot org 2005-01-28 23:54 --- Here is the corrected link http://gcc.gnu.org/ml/gcc-patches/2004-02/msg01995.html or follow the link to the patch and click on followups. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=8354

[Bug c++/19667] [4.0 Regression] ICE on (very trivial) invalid

-- What|Removed |Added AssignedTo|unassigned at gcc dot gnu |mark at codesourcery dot com |dot org | Status|NEW

[Bug c++/19605] [4.0 Regression] Wrong member offset in inherited classes

--- Additional Comments From mmitchel at gcc dot gnu dot org 2005-01-29 00:00 --- This is undefined behavior, and it is not worthwhile to try to make this work. There are existing ways (offsetof and poiners-to-members) to accomplish what the submitter wants to do. -- What

[Bug libstdc++/19656] libstdc++ testsuite results differ if bootstrap gcc 4.0 using some gcc 4.0 version or early (gcc 3.4.3) gcc version at FreeBSD

--- Additional Comments From wanderer at rsu dot ru 2005-01-29 00:03 --- > Yes, the issue involves how the compiler used > to bootstrap stage 1 is configured > and itself installed (is it in /usr/local? > what ports have headers installed there?). In m case used gcc configure options

[Bug preprocessor/13726] [3.3/3.4/4.0 regression]cpp -C -dI loses comments on same line as #include directives

--- Additional Comments From echristo at redhat dot com 2005-01-29 00:25 --- Current mainline does this: [EMAIL PROTECTED] ~/tmp]$ /dzur/sourceware/builds-gcc/build-dzur/gcc/cc1 -dI -C test.c In file included from test.c:1: test.h:1: internal compiler error: in c_lex_with_flags, at c-l

[Bug preprocessor/13726] [3.3/3.4/4.0 regression]cpp -C -dI loses comments on same line as #include directives

--- Additional Comments From echristo at redhat dot com 2005-01-29 00:26 --- The previous was because i'm an idiot. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13726

[Bug libgcj/19681] New: extension loading currently incorrect

We have two bugs in our handling of java.ext.dirs First, technically I think we should have a separate extension class loader that is the parent of the system class loader. Second, as implied by the above, extensions should be searched first, whereas in our implementation they are searched after

[Bug libgcj/19621] Network-performance issue in java.io.PrintStream

--- Additional Comments From mckinlay at redhat dot com 2005-01-29 00:26 --- This is probably due to the 100-byte character conversion buffer in java/io/PrintStream.java. The buffer size could be increased if it will improve network efficiency. Any idea what size the Sun implementation u

[Bug libgcj/19649] java.util.Date.getTimezoneOffset returns negated output

--- Additional Comments From mckinlay at redhat dot com 2005-01-29 00:30 --- I've put a test case for this in mauve: gnu/testlet/java/util/Date/getTimezoneOffset.java This test case also exposes some problems with libgcj's underlying TimeZone data. This patch looks correct, though.

[Bug preprocessor/13726] [3.3/3.4/4.0 regression]cpp -C -dI loses comments on same line as #include directives

-- What|Removed |Added AssignedTo|unassigned at gcc dot gnu |echristo at redhat dot com |dot org | Status|NEW

[Bug libgcj/19649] java.util.Date.getTimezoneOffset returns negated output

--- Additional Comments From mckinlay at redhat dot com 2005-01-29 00:37 --- Turns out its already fixed in GNU Classpath. Re-syncing with their version. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19649

[Bug libgcj/19682] New: TimeZone data needs to be regenerated

The TimeZones in TimeZone.java are out-of-date and buggy. For example: America/Toronto is missing Europe/London is an alias for GMT We need to fix up the scripts and regenerate the timezones from Olsen's latest tzdata. -- Summary: TimeZone data needs to be regenerated Pro

[Bug libgcj/19649] java.util.Date.getTimezoneOffset returns negated output

--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-01-29 00:44 --- Subject: Bug 19649 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2005-01-29 00:43:51 Modified files: libjava: ChangeLog libjava/java/util:

[Bug libgcj/19682] TimeZone data needs to be regenerated

-- What|Removed |Added OtherBugsDependingO||16990 nThis|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19682

[Bug libgcj/19649] java.util.Date.getTimezoneOffset returns negated output

--- Additional Comments From mckinlay at redhat dot com 2005-01-29 00:45 --- Fixed -- What|Removed |Added Status|NEW |RESOLVED R

[Bug libgcj/16990] [meta-bug] TimeZone Issues in libgcj/classpath

-- Bug 16990 depends on bug 19649, which changed state. Bug 19649 Summary: java.util.Date.getTimezoneOffset returns negated output http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19649 What|Old Value |New Value --

[Bug c++/19667] [4.0 Regression] ICE on (very trivial) invalid

--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-01-29 00:48 --- Subject: Bug 19667 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2005-01-29 00:47:57 Modified files: gcc/cp : ChangeLog pt.c gcc/testsuite

[Bug libgcj/11941] gcj handles timezones wrongly with new Date().toString()

--- Additional Comments From mckinlay at redhat dot com 2005-01-29 00:48 --- This appears to be fixed: $ TZ='Europe/Moscow' gij TZMain Sat Jan 29 03:46:38 GMT+03:00 2005 $ TZ='Europe/Kaliningrad' gij TZMain Sat Jan 29 02:47:07 GMT+02:00 2005 -- What|Removed

[Bug libgcj/16990] [meta-bug] TimeZone Issues in libgcj/classpath

-- Bug 16990 depends on bug 11941, which changed state. Bug 11941 Summary: gcj handles timezones wrongly with new Date().toString() http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11941 What|Old Value |New Value -

[Bug c++/19667] [4.0 Regression] ICE on (very trivial) invalid

--- Additional Comments From mmitchel at gcc dot gnu dot org 2005-01-29 00:48 --- Fixed in GCC 4.0. -- What|Removed |Added Status|ASSIGNED|RE

[Bug target/19683] New: MIPS wrong-code for 64-bit multiply from java program.

The testcase that I will attach when compiled with -O3 generates incorrect results. Good results are obtained at -O0 The testcase should be compiled like this: $ mipsel-linux-gcj --main=TestMultSimple -O2 TestMultSimple.java -o TestMultSimple-O2 $ mipsel-linux-gcj --main=TestMultSimple -O0 Test

[Bug target/19683] MIPS wrong-code for 64-bit multiply from java program.

--- Additional Comments From daney at gcc dot gnu dot org 2005-01-29 01:00 --- Created an attachment (id=8096) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8096&action=view) Testcase -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19683

[Bug target/19664] -fvisibility-inlines-hidden fails with gcc's extern template extension on amd64

--- Additional Comments From hjl at lucon dot org 2005-01-29 01:05 --- It is a compiler bug. VisTest::VisTest() is never defined. R_X86_64_PC32 relocation may not reach it at runtime when it is called. The new linker catches this particular bug at linktime. -- http://gcc.gnu.org/bugzi

[Bug target/19683] MIPS wrong-code for 64-bit multiply from java program.

--- Additional Comments From daney at gcc dot gnu dot org 2005-01-29 01:16 --- I should probably add the the compiler was configured with: configure --target=mipsel-linux --with-sysroot=/usr/local/mipsel-linux --with-arch=mips32 --with-float=soft --enable-languages=c,c++,java --prefix=/

[Bug rtl-optimization/19680] [missed-optimization] gcc4 is really reluctant to use fancy x86 addressing modes

-- What|Removed |Added Attachment #8095|text/x-c|text/plain mime type|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19680

[Bug c++/19143] [4.0 regression] ICE on invalid template parameter

--- Additional Comments From mmitchel at gcc dot gnu dot org 2005-01-29 02:03 --- *** This bug has been marked as a duplicate of 19667 *** -- What|Removed |Added

[Bug c++/19667] [4.0 Regression] ICE on (very trivial) invalid

--- Additional Comments From mmitchel at gcc dot gnu dot org 2005-01-29 02:03 --- *** Bug 19143 has been marked as a duplicate of this bug. *** -- What|Removed |Added

[Bug c++/19253] [3.4/4.0 regression] bad error message / ICE for invalid template parameter

--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-01-29 02:07 --- Subject: Bug 19253 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2005-01-29 02:07:19 Modified files: gcc/cp : ChangeLog parser.c gcc/tests

[Bug c++/19253] [3.4 regression] bad error message / ICE for invalid template parameter

--- Additional Comments From mmitchel at gcc dot gnu dot org 2005-01-29 02:10 --- Fixed in GCC 4.0. -- What|Removed |Added Summary|[3.4/4.0 regression] bad|[3

[Bug rtl-optimization/19680] [missed-optimization] gcc4 is really reluctant to use fancy x86 addressing modes

--- Additional Comments From steven at gcc dot gnu dot org 2005-01-29 02:34 --- *** This bug has been marked as a duplicate of 18463 *** -- What|Removed |Added

[Bug tree-optimization/18463] [4.0 Regression] Moving floating point through an integer register

--- Additional Comments From steven at gcc dot gnu dot org 2005-01-29 02:34 --- *** Bug 19680 has been marked as a duplicate of this bug. *** -- What|Removed |Added

[Bug tree-optimization/18463] [4.0 Regression] suboptimal use of fancy x86 addressing modes

--- Additional Comments From steven at gcc dot gnu dot org 2005-01-29 02:37 --- This problem is bigger than just the int<-->fp problem of the original bug report. It's basically the same problem, namely a poor choice of addressing modes. -- What|Removed

[Bug c++/19457] [4.0 Regression] Warning depends on cached constant

--- Additional Comments From mmitchel at gcc dot gnu dot org 2005-01-29 02:46 --- The C++ front-end has a TREE_NEGATED_INT flag; it is that flag which is getting cached incorrectly. The C++ front end is intentionally trying to warn about conversions from negated integer constants, but n

[Bug tree-optimization/18463] [4.0 Regression] suboptimal use of fancy x86 addressing modes

--- Additional Comments From tbptbp at gmail dot com 2005-01-29 03:15 --- Some recent discussion about related symptoms. http://gcc.gnu.org/ml/gcc/2005-01/msg01667.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18463

[Bug c++/16166] -Weffc++ finer granularity

-- What|Removed |Added Keywords||diagnostic Last reconfirmed|2004-10-30 17:49:38 |2005-01-29 03:19:30 date|

[Bug target/19684] New: avr-gcc 4.0 (and 3.3.4): wrong size in asm comment

Comment about function `foo' size: 27/* function foo size 10 (9) */ show wrong value. (Compare it with next function.) Compiler: avr-gcc (GCC) 4.0.0 20050109 (experimental) Options: -W -Wall -Os -Wa,-ahl The same error (for `foo') in 3.3.4 . Certainly, it is n

[Bug target/19530] MMX load intrinsic produces SSE superfluous instructions (movlps)

--- Additional Comments From guardia at sympatico dot ca 2005-01-29 04:47 --- Hum, there apparently seems to be a problem with the optimization stages.. I cooked up another snippet : void moo(__m64 i, unsigned int *r) { unsigned int tmp = __builtin_ia32_vec_ext_v2si (i, 0); *r = t

[Bug c/19685] New: ICE, in verify_local_live_at_start, at flow.c:574

[EMAIL PROTECTED]:~/cis/research/ripower$ gcc -O3 sim-ri.i sim-ri.c: In function `ruu_commit': sim-ri.c:4591: internal compiler error: in verify_local_live_at_start, at flow.c:574 -- Summary: ICE, in verify_local_live_at_start, at flow.c:574 Product: gcc Ver

[Bug c/19685] ICE, in verify_local_live_at_start, at flow.c:574

--- Additional Comments From vlad at petric dot cc 2005-01-29 06:34 --- Created an attachment (id=8097) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8097&action=view) preprocessed sourcecode -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19685

[Bug target/19686] New: avr-gcc 4.0: loop performance decrease (extra conversion)

Program: int foo (int x) { int i= x; do { x *= 2; } while (--i); return x; } avr-gcc 4.0 (20050116) with `-Os' option: foo: /* prologue: frame size=0 */ /* prologue end (size=0) */ ldi r18,lo8(0) ldi r19,hi8(0) clr r20 cl

[Bug middle-end/19687] New: [4.0 Regression] ICE with union initializer

Compile this with "-O0 -march=i386" to get segmenation fault: -- typedef union { int i, j[4]; } foo; void bar () { foo t = {}; } -- Caused by

<    1   2