[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

[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 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 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 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 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 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 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++/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 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 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 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 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 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++/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++/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 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 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 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: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/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 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 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 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 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/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 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/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 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] 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 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 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: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 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/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 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 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 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 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 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 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 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 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/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 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 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 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/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 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 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 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 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: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 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 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 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 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 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 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 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 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 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 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 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 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 libgcj/19677] New: invalid "may not have been initialized" error

Following Eclipse code snippet that fails: protected void join(InternalJob job) { final IJobChangeListener listener; synchronized (lock) { listener = new JobChangeAdapter() { public void done(IJobChangeEvent event) {

[Bug target/19676] Loop optimizer fails to reverse simple loop

--- Additional Comments From andrewhutchinson at cox dot net 2005-01-28 19:14 --- Created an attachment (id=8094) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8094&action=view) Optimised RTL Final Optimised RTL before asm code generation. -- http://gcc.gnu.org/bugzilla/show_b

[Bug target/19676] Loop optimizer fails to reverse simple loop

-- What|Removed |Added Component|c |target Keywords||missed-optimization http://gcc.gnu.org/bugzilla/show_b

[Bug c/19676] Loop optimizer fails to reverse simple loop

--- Additional Comments From andrewhutchinson at cox dot net 2005-01-28 19:13 --- Created an attachment (id=8093) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8093&action=view) Expanded RTL Expanded RTL from looprv testcase source -- http://gcc.gnu.org/bugzilla/show_bug.cgi?i

[Bug c/19676] Loop optimizer fails to reverse simple loop

--- Additional Comments From andrewhutchinson at cox dot net 2005-01-28 19:12 --- Created an attachment (id=8092) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8092&action=view) Testcase c source Testloop3() is NOT reversed. Others for reference are. -- http://gcc.gnu.org/bu

[Bug middle-end/19661] unnecessary atexit calls emitted for static objects with empty destructors

--- Additional Comments From bangerth at dealii dot org 2005-01-28 19:11 --- Why do you think the front-end doesn't know that the destructor is empty? It sees its definition, and it knows about potential destructors of member objects and base classes, so it should have all the informat

[Bug c/19676] New: Loop optimizer fails to reverse simple loop

AVR Target 20041205 snapshot gcc version 4.0.0 20041205 (experimental) /avrdev/libexec/gcc/avr/4.0.0/cc1.exe -quiet -v looprv.c -quiet -dumpbase looprv.c -mmcu=atmega169 -auxbase looprv -Os -Wall -version -funsigned-char -funsigned-bitfields -fpack-struct -fshort-enums -o looprv.s Loop optimise

[Bug rtl-optimization/323] optimized code gives strange floating point results

--- Additional Comments From pinskia at gcc dot gnu dot org 2005-01-28 19:07 --- *** Bug 19675 has been marked as a duplicate of this bug. *** -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=323

[Bug target/19675] wrong double comparison result if taken from function result.

--- Additional Comments From pinskia at gcc dot gnu dot org 2005-01-28 19:07 --- Really comparing two floating point with equallity is not a good thing to do. This again is a dup of bug 323. *** This bug has been marked as a duplicate of 323 *** -- What|Removed

[Bug target/19675] wrong double comparison result if taken from function result.

--- Additional Comments From cognot at earthdecision dot com 2005-01-28 19:04 --- (In reply to comment #3) > Only happens on x86. True. But only with gcc. Under Windows M$ .NET and DevStudio 6 give a correct result if "Improve float consitency" is turned on. Haven't tried with the Int

[Bug java/19674] Empty declaration through semicolon (;) causes compile failure

--- Additional Comments From pinskia at gcc dot gnu dot org 2005-01-28 19:04 --- Confirmed. -- What|Removed |Added Status|UNCONFIRMED |NEW E

[Bug regression/19672] [3.4/4.0? Regression] Performance regression in simple loop code

--- Additional Comments From pinskia at gcc dot gnu dot org 2005-01-28 19:03 --- I cannot test this right now but this might be fixed on the mainline. -- What|Removed |Added

[Bug target/19675] wrong double comparison result if taken from function result.

--- Additional Comments From pinskia at gcc dot gnu dot org 2005-01-28 18:59 --- Only happens on x86. -- What|Removed |Added Severity|critical|

[Bug c++/19675] wrong double comparison result if taken from function result.

--- Additional Comments From cognot at earthdecision dot com 2005-01-28 18:54 --- (In reply to comment #1) > This is a dup of bug 323. The problem is excessive precission. > > *** This bug has been marked as a duplicate of 323 *** Hi, Looking at the thread for bug #323 it would seem

[Bug middle-end/19661] unnecessary atexit calls emitted for static objects with empty destructors

--- Additional Comments From pinskia at gcc dot gnu dot org 2005-01-28 18:53 --- (In reply to comment #5) > I'll move this bug back to the C++ component. Consider the following C++ code: struct Foo { ~Foo() {} int i; }; struct A { Foo foo[2]; }; void foo () { static A a; } We don'

[Bug rtl-optimization/13931] [3.3/3.4/4.0 Regression] combiner much slower on big basic blocks

--- Additional Comments From ian at airs dot com 2005-01-28 18:49 --- We aren't waiting for anything, so move out of WAITING state. -- What|Removed |Added CC|

[Bug rtl-optimization/323] optimized code gives strange floating point results

--- Additional Comments From pinskia at gcc dot gnu dot org 2005-01-28 18:47 --- *** Bug 19675 has been marked as a duplicate of this bug. *** -- What|Removed |Added

[Bug c++/19675] wrong double comparison result if taken from function result.

--- Additional Comments From pinskia at gcc dot gnu dot org 2005-01-28 18:47 --- This is a dup of bug 323. The problem is excessive precission. *** This bug has been marked as a duplicate of 323 *** -- What|Removed |Added ---

[Bug c++/19675] New: wrong double comparison result if taken from function result.

Hi, The small example below gives an incorrect result on 32 bit platforms. Both tests should lead to the same result, but one is false, the other is true. tested with the following compilers, all of them exhibiting the bug: Reading specs from /usr/lib/gcc-lib/i386-redhat-linux/2.96/specs gcc ver

[Bug java/19674] Empty declaration through semicolon (;) causes compile failure

--- Additional Comments From dog at bluezoo dot org 2005-01-28 18:19 --- The relevant JLS production is ClassMemberDeclaration: http://java.sun.com/docs/books/jls/second_edition/html/classes.doc.html#18988 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19674

[Bug java/19674] New: Empty declaration through semicolon (;) causes compile failure

The following program doesn't compile: public interface OutSideInterface { public interface InsideInterface { void m(int p, int p2); }; } Note the empty statement (semicolon) on line 6. This is legal (jikes accepts it) but deprecated. Compiling with -C gives: OutSideInterface.java:6:

[Bug target/16201] Assembler messages:Error: bad immediate value for offset (4116)

-- What|Removed |Added Attachment #6629|text/plain |application/x-zip mime type|| http://gcc.gnu.org/bugzilla/show_bug.cgi?i

[Bug middle-end/16558] [4.0 Regression]: bogus missing-return warning

--- Additional Comments From ian at airs dot com 2005-01-28 17:35 --- Fixed in mainline. -- What|Removed |Added Status|NEW |RESOLVED

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

--- Additional Comments From marco at gnome dot org 2005-01-28 17:35 --- Colin, is this one the cause of the setTimeStamp/getTimeStamp mismatch with postgre jdbc? I have a testcase for that one in case it's of any use... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19649

[Bug middle-end/16558] [4.0 Regression]: bogus missing-return warning

--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-01-28 17:34 --- Subject: Bug 16558 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2005-01-28 17:33:54 Modified files: gcc/testsuite : ChangeLog Added files: gcc/t

[Bug middle-end/16558] [4.0 Regression]: bogus missing-return warning

--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-01-28 17:33 --- Subject: Bug 16558 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2005-01-28 17:32:58 Modified files: gcc: ChangeLog gimple-low.c Log message:

[Bug middle-end/19583] [4.0 Regression] Incorrect diagnostic: control may reach end of non-void function '...' being inlined

--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-01-28 17:33 --- Subject: Bug 19583 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2005-01-28 17:32:58 Modified files: gcc: ChangeLog gimple-low.c Log message:

[Bug tree-optimization/14741] missing transformations lead to poorly optimized code

--- Additional Comments From dberlin at gcc dot gnu dot org 2005-01-28 17:22 --- Subject: Re: missing transformations lead to poorly optimized code On Fri, 28 Jan 2005, jv244 at cam dot ac dot uk wrote: > > --- Additional Comments From jv244 at cam dot ac dot uk 2005-01-28 16:

Re: [Bug tree-optimization/14741] missing transformations lead to poorly optimized code

On Fri, 28 Jan 2005, jv244 at cam dot ac dot uk wrote: --- Additional Comments From jv244 at cam dot ac dot uk 2005-01-28 16:31 --- You could try "gfortran -O3 -mtune=pentium4 -ffast-math -mfpmath=sse -ftree-loop-linear -ftree-vectorize yourcode.f90" and see if it helps. Unhappily, seem

[Bug fortran/18714] Runtime hang in LAPACK routine SLAMC1 - in Quetzal benchmark suite

--- Additional Comments From coudert at clipper dot ens dot fr 2005-01-28 17:20 --- (reply to comments #3 and #4) The print statement in the code induces I/O, which in some sense "disrupt the flow of code" and has the effect of making unaware of possible optimizations. I can't offer a d

[Bug fortran/18714] Runtime hang in LAPACK routine SLAMC1 - in Quetzal benchmark suite

--- Additional Comments From paulthomas2 at wanadoo dot fr 2005-01-28 17:08 --- Francois-Xavier Coudert's comment is spot on. Reducing the optimisation to -O0 removes the need for this peculiar fix. We could do with a repository for funnies that are not quite bugs. I SAY REMOVE THIS

[Bug fortran/18714] Runtime hang in LAPACK routine SLAMC1 - in Quetzal benchmark suite

--- Additional Comments From prthomas at drfccad dot cea dot fr 2005-01-28 17:02 --- Subject: RE: Runtime hang in LAPACK routine SLAMC1 - i n Quetzal benchmark suite Bon soir François-Xavier, Tu as raison! Même -O1 fait coincer le programme. Je suis étonné quand-même que le

[Bug c++/19661] unnecessary atexit calls emitted for static objects with empty destructors

--- Additional Comments From bangerth at dealii dot org 2005-01-28 17:01 --- atexit only takes a pointer to a function to be run on exit of the program. The fact that this is an empty function is unbeknownst to it, and probably the code in the middle-end that has to deal with that. I

[Bug fortran/19673] New: pointer function with RESULT specified returns pointer to "ptr" rather than "*ptr"

This is a bug that is specific to functions where RESULT is specified in the function statement(function foo). In this case, the pointer itself is printed. Where RESULT is not specified, functions return a pointer result correctly(function bar). Here the value pointed too is printed. $ cat re

[Bug tree-optimization/19643] "0 % variable" isn't optimized to 0 at tree level

--- Additional Comments From law at redhat dot com 2005-01-28 16:36 --- Should be fixed with today's change to fold-const.c. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19643

  1   2   >