[Bug bootstrap/18974] error in compiling gcc 4.0 for i686-pc-linux-gnu: gengtype-lex.c

[bbeck4gofls at hotmail dot com]

--- Additional Comments From bbeck4gofls at hotmail dot com  2004-12-14 
08:11 ---
Thanks Andrew,
   There were two warnings before the earlier-mentioned error, saying bison and
flex are missing on my system, but that they were only needed if I modified a .y
or .l file.  After emailing gcc-help I installed bison and flex, and tried
compiling again, but kept getting errors referencing a missing 'lexer_line',
when gcc was (I think in stage1) was trying to build build/gengtype from
gengtype.o, gengtype-lex.o, gengtype-yacc.o, errors.o, and libiberty.a.  Again,
I'm using the 11-28-04 tarball, which is not a release, so it doesn't have
gengtype-lex.c, but I just wanted to let the developers know not to forget it in
the eventual release since I'm getting errors bootstrapping even with both bison
and flex installed.  I can give more information if you need it.
Thanks!
Brandon

-- 
   What|Removed |Added

 Status|WAITING |NEW
 Ever Confirmed||1


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18974

[Bug middle-end/15486] [3.3/3.4/4.0 regression] -fdata-sections moves common vars to .bss

[ebotcazou at gcc dot gnu dot org]

--- Additional Comments From ebotcazou at gcc dot gnu dot org  2004-12-14 
08:21 ---
Patch at http://gcc.gnu.org/ml/gcc-patches/2004-12/msg00909.html


-- 
   What|Removed |Added

   Keywords||patch


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15486

[Bug libstdc++/17789] [3.4/4.0 Regression] Cannot 'make check' inside libstdc++-v3

[ebotcazou at gcc dot gnu dot org]

--- Additional Comments From ebotcazou at gcc dot gnu dot org  2004-12-14 
08:47 ---
This is not critical according to the criteria.


-- 
   What|Removed |Added

   Severity|critical|normal


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17789

[Bug target/14981] [3.4/4.0 Regression] ICE in _mm_xor_pd for SSE2 with -O1

[ebotcazou at gcc dot gnu dot org]

--- Additional Comments From ebotcazou at gcc dot gnu dot org  2004-12-14 
08:52 ---
A bug involving SSE intrinsics is not critical.


-- 
   What|Removed |Added

   Severity|critical|normal


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14981

[Bug middle-end/18882] [3.3/3.4 Regression] wrong results with complex long double

[ebotcazou at gcc dot gnu dot org]

--- Additional Comments From ebotcazou at gcc dot gnu dot org  2004-12-14 
09:34 ---
Investigating.


-- 
   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |ebotcazou at gcc dot gnu dot
   |dot org |org
 Status|NEW |ASSIGNED


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18882

[Bug middle-end/18882] [3.3/3.4 Regression] wrong results with complex long double

[ebotcazou at gcc dot gnu dot org]

--- Additional Comments From ebotcazou at gcc dot gnu dot org  2004-12-14 
09:35 ---
This is the same problem as PR middle-end/14988.  I'll backport the fix.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18882

[Bug target/18713] Large program size due to uninitialised global data

[bygoh at genting dot com dot my]

--- Additional Comments From bygoh at genting dot com dot my  2004-12-14 
10:03 ---
Have been trying to upgrade to a newer version of gcc (3.3.3 and above). But I 
am getting an error during compilation:

checking whether the C compiler ( /usr/byg/src/bld-gcc/gcc/xgcc -B/usr/byg/src/b
ld-gcc/gcc/ -B/usr/local/gcc-3.3.4/i386-pc-sco3.2v5.0.5/bin/ -B/usr/local/gcc-3.
3.4/i386-pc-sco3.2v5.0.5/lib/ -isystem /usr/local/gcc-3.3.4/i386-pc-sco3.2v5.0.5
/include -O2 -O2 ) works... no
configure: error: installation or configuration problem: C compiler cannot creat
e executables.
gmake: *** [configure-target-libiberty] Error 1

Any idea how to get past this?

Configured and built with:
$ configure --prefix=/usr/local/gcc-3.3.4 --enable-languages="c++"
$ gmake CFLAGS="-O2" LANGUAGES="c c++"

-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18713

[Bug fortran/18977] New: LAPACK test xeigtsts segfaults

[Thomas dot Koenig at online dot de]

I was running the LAPACK with -O3
with 20041212 (snapshot) with Steve Kargl's I/O patch
from http://gcc.gnu.org/ml/gcc-patches/2004-12/msg00844.html
applied.   The test ran OK until xeigtsts segfaulted:

make[1]: Entering directory `/home/zfkts/zfkts/LAPACK/TESTING'
Testing REAL LAPACK linear equation routines
./xlintsts < stest.in > stest.out 2>&1
NEP: Testing Nonsymmetric Eigenvalue Problem routines
./xeigtsts < nep.in > snep.out 2>&1
SEP: Testing Symmetric Eigenvalue Problem routines
./xeigtsts < sep.in > ssep.out 2>&1
SVD: Testing Singular Value Decomposition routines
./xeigtsts < svd.in > ssvd.out 2>&1
SEC: Testing REAL Eigen Condition Routines
./xeigtsts < sec.in > sec.out 2>&1
make[1]: *** [sec.out] Error 139
make[1]: Leaving directory `/home/zfkts/zfkts/LAPACK/TESTING'
make: *** [testing] Error 2
$ gdb ./xeigtsts
GNU gdb Red Hat Linux (6.1post-1.20040607.17rh)
Copyright 2004 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 "ia64-redhat-linux-gnu"...Using host libthread_db
library "/lib/tls/libthread_db.so.1".

(gdb) r < sec.in
Starting program: /home/zfkts/zfkts/LAPACK/TESTING/xeigtsts < sec.in
 Tests of the Nonsymmetric eigenproblem condition estimation routines
 SLALN2, SLASY2, SLANV2, SLAEXC, STRSYL, STREXC, STRSNA, STRSEN, SLAQTR

 Relative machine precision (EPS) = 0.119209E-06
 Safe minimum (SFMIN) = 0.117549E-37

 Routines pass computational tests if test ratio is less than   20.00


 SEC routines passed the tests of the error exits ( 35 tests done)

Program received signal SIGSEGV, Segmentation fault.
slasy2_ (ltranl=Variable "ltranl" is not available.
) at slasy2.f:362
362 TMP( K ) = TMP( K ) - ( TEMP*T16( K, J ) )*TMP( J )
Current language:  auto; currently fortran
(gdb) p tmp
$1 = (0, -nan(0x7f6f34), 10797277, -1437623.12)

Reverting Steve's patch, bubblestrapping and rerunning it made
no difference.

This is a regression from about a month ago, and possibly a target
problem.

-- 
   Summary: LAPACK test xeigtsts segfaults
   Product: gcc
   Version: 4.0.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P2
 Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: Thomas dot Koenig at online dot de
CC: gcc-bugs at gcc dot gnu dot org
  GCC host triplet: ia64-unknown-linux-gnu


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18977

[Bug c/18978] New: Segmentation fault after a warning about 'struct sigaction'

[patrick dot hingrez at atosorigin dot com]

Command line and compiler output :
--

gcc -c -Wall -ansi -DGnu -g -DDETECT_BUGS -v -save-temps
-I/picsou2/users/hingrez/mercatorII/diffusion/inc 
-I/picsou2/users/hingrez/mercatorII/global/inc 
-I/picsou2/users/hingrez/mercatorII/commun_c/inc
-I/picsou2/users/hingrez/mercatorII/param_ctrl_donnee/inc 
-I/picsou2/users/hingrez/mercatorII/gst_don_mad/inc
-I/picsou2/users/hingrez/libmadona/Sun/inc -I/usr/dt/include -o
/picsou2/users/hingrez/mercatorII/diffusion/obj/diss_stat.o
/picsou2/users/hingrez/mercatorII/diffusion/src/diss_stat.c
Reading specs from
/picsou2/GNU/gcc/3.4.2/bin/../lib/gcc/sparc-sun-solaris2.8/3.4.2/specs
Configured with: ../gcc-3.4.2/configure --prefix=/opt/GNU/gcc/3.4.2
Thread model: posix
gcc version 3.4.2
 /picsou2/GNU/gcc/3.4.2/bin/../libexec/gcc/sparc-sun-solaris2.8/3.4.2/cc1 -E
-quiet -v -I/picsou2/users/hingrez/mercatorII/diffusion/inc
-I/picsou2/users/hingrez/mercatorII/global/inc
-I/picsou2/users/hingrez/mercatorII/commun_c/inc
-I/picsou2/users/hingrez/mercatorII/param_ctrl_donnee/inc
-I/picsou2/users/hingrez/mercatorII/gst_don_mad/inc
-I/picsou2/users/hingrez/libmadona/Sun/inc -I/usr/dt/include -iprefix
/picsou2/GNU/gcc/3.4.2/bin/../lib/gcc/sparc-sun-solaris2.8/3.4.2/ -DGnu
-DDETECT_BUGS /picsou2/users/hingrez/mercatorII/diffusion/src/diss_stat.c
-mcpu=v7 -ansi -Wall -fworking-directory -o diss_stat.i
ignoring nonexistent directory
"/picsou2/GNU/gcc/3.4.2/bin/../lib/gcc/sparc-sun-solaris2.8/3.4.2/../../../../sparc-sun-solaris2.8/include"
ignoring duplicate directory
"/opt/GNU/gcc/3.4.2/lib/gcc/sparc-sun-solaris2.8/3.4.2/include"
ignoring nonexistent directory
"/opt/GNU/gcc/3.4.2/lib/gcc/sparc-sun-solaris2.8/3.4.2/../../../../sparc-sun-solaris2.8/include"
#include "..." search starts here:
#include <...> search starts here:
 /picsou2/users/hingrez/mercatorII/diffusion/inc
 /picsou2/users/hingrez/mercatorII/global/inc
 /picsou2/users/hingrez/mercatorII/commun_c/inc
 /picsou2/users/hingrez/mercatorII/param_ctrl_donnee/inc
 /picsou2/users/hingrez/mercatorII/gst_don_mad/inc
 /picsou2/users/hingrez/libmadona/Sun/inc
 /usr/dt/include
 /picsou2/GNU/gcc/3.4.2/bin/../lib/gcc/sparc-sun-solaris2.8/3.4.2/include
 /usr/local/include
 /opt/GNU/gcc/3.4.2/include
 /usr/include
End of search list.
 /picsou2/GNU/gcc/3.4.2/bin/../libexec/gcc/sparc-sun-solaris2.8/3.4.2/cc1
-fpreprocessed diss_stat.i -quiet -dumpbase diss_stat.c -mcpu=v7 -ansi
-auxbase-strip /picsou2/users/hingrez/mercatorII/diffusion/obj/diss_stat.o -g
-Wall -ansi -version -o diss_stat.s
GNU C version 3.4.2 (sparc-sun-solaris2.8)
compiled by GNU C version 3.4.2.
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
In file included from
/picsou2/users/hingrez/mercatorII/diffusion/src/diss_stat.c:60:
/picsou2/users/hingrez/mercatorII/global/inc/Gst_File_Sig.h:102: warning:
"struct sigaction" declared inside parameter list
/picsou2/users/hingrez/mercatorII/global/inc/Gst_File_Sig.h:102: warning: its
scope is only this definition or declaration, which is probably not what you
want
/picsou2/users/hingrez/mercatorII/diffusion/src/diss_stat.c: In function `main':
/picsou2/users/hingrez/mercatorII/diffusion/src/diss_stat.c:259: internal
compiler error: Segmentation Fault
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html> for instructions.
*** Error code 1

Preprocessed file :
---

How can I include it ?!?

-- 
   Summary: Segmentation fault after a warning about 'struct
sigaction'
   Product: gcc
   Version: 3.4.2
Status: UNCONFIRMED
  Severity: critical
  Priority: P2
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: patrick dot hingrez at atosorigin dot com
CC: gcc-bugs at gcc dot gnu dot org


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18978

[Bug middle-end/18424] [3.4/4.0 Regression] ~6x+ performance regression, constant trees not being computed.

[schlie at comcast dot net]

--- Additional Comments From schlie at comcast dot net  2004-12-14 12:33 
---
Subject: Re:  [3.4/4.0 Regression] ~6x+ performance
 regression, constant trees not being computed.

Nope, unfortunately not as of yesterday, since reload.c was tweaked last
week.




-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18424

[Bug pch/18980] -MD doesn't report compiled headers as dependencies when using pch ?

[trick at icculus dot org]

--- Additional Comments From trick at icculus dot org  2004-12-14 12:52 
---
This only affects precompiled headers.  Continuing from before:

$ echo '#define TEST2' > test2.h
$ echo '#include "test2.h"' >> test.c
$ cat test.c
#include "test.h"
#include "test2.h"
$ gcc -MD -MF test.c.d -c test.c
$ cat test.c.d
test.o: test.c test2.h

^ missing test.h (since test.h.gch exists and is used), but not test2.h


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18980

[Bug c++/18981] New: [4.0 regression] ICE in cp_parser_lookup_name

[schwab at suse dot de]

$ cat tree.cc 
template  
struct tree { 
  struct iterator; 
  struct sibling_iterator { 
friend struct tree::iterator; 
  }; 
}; 
$ gcc tree.cc 
tree.cc:5: internal compiler error: tree check: expected typename_type, have 
record_type in cp_parser_lookup_name, at cp/parser.c:14210 
Please submit a full bug report, 
with preprocessed source if appropriate. 
See http://gcc.gnu.org/bugs.html> for instructions.

-- 
   Summary: [4.0 regression] ICE in cp_parser_lookup_name
   Product: gcc
   Version: 4.0.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P2
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: schwab at suse dot de
CC: gcc-bugs at gcc dot gnu dot org


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18981

[Bug pch/14933] missing pre-compiled header depends with -MD

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2004-12-14 
13:18 ---
*** Bug 18980 has been marked as a duplicate of this bug. ***

-- 
   What|Removed |Added

 CC||trick at icculus dot org


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14933

[Bug libfortran/18982] New: open(status="new") does not generate an error if the file exists

[Thomas dot Koenig at online dot de]

$ cat open.f90
  nout = 10
  open(nout, file="foo.dat", status="new")
  close(nout)
  open(nout, file="foo.dat", status="new",err=100)  ! This should fail
  write(nout,*) "Hello" ! and not this.
100 continue
end
$ rm -f foo.dat
$ gfortran open.f90
$ ./a.out
At line 5 of file open.f90
Fortran runtime error: Cannot write to file opened for READ

-- 
   Summary: open(status="new") does not generate an error if the
file exists
   Product: gcc
   Version: 4.0.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P2
 Component: libfortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: Thomas dot Koenig at online dot de
CC: gcc-bugs at gcc dot gnu dot org


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18982

[Bug c++/18975] Copying objects with mutable non-static data members

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2004-12-14 
13:25 ---
XYZ (PTR& p) : ptr(p) {}

That will always call the constructor for ptr so this is invalid.

-- 
   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18975

[Bug target/18592] [3.3/3.4 regression] [m68k] ICE in output_operand: invalid expression as operand

[corsepiu at gcc dot gnu dot org]

--- Additional Comments From corsepiu at gcc dot gnu dot org  2004-12-14 
13:58 ---
PR18542 and this PR are not identical:

Proof:
* Compiling the example from comment #3
# m68k-rtems4.7-gcc -m68020 -O2 -o tmp.o -c pr18549.c
pr18549.c: In function `foo':
pr18549.c:31: internal compiler error: output_operand: invalid expression as 
operand

# m68k-rtems4.7-gcc -m68000 -O2 -o tmp.o -c pr18549.c
[No ICE]

* Compling the example from PR18542:
# m68k-rtems4.7-gcc -m68000 -O2 -o tmp.o -c cpuboot.c
cpuboot.c: In function `boot_phase_1':
cpuboot.c:8: internal compiler error: output_operand: invalid expression as 
operand

# m68k-rtems4.7-gcc -m68020 -O2 -o tmp.o -c cpuboot.c
cpuboot.c: In function `boot_phase_1':
cpuboot.c:8: internal compiler error: output_operand: invalid expression as 
operand

=> The ICE from the example in PR15492 is independent of -m68020

Furthermore, no ICE occurs for the example from comment #3 with avr-*:
# avr-rtems4.7-gcc -O2 -o tmp.o -c pr18549.c

-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18592

[Bug target/17990] [3.4/4.0 Regression] sse used for negate without -mfpmath=sse

[bangerth at dealii dot org]

--- Additional Comments From bangerth at dealii dot org  2004-12-14 14:09 
---
In response to comment #30: it is libpthread's responsibility to align the 
stack of subthreads properly. It doesn't do that, however, but I believe 
that we have another PR for that (this is something that we can't really 
do anything about, however). 
 
If Uros' first testcase now works, then I think we have fixed the part that 
we could fix, so I'm closing the PR. Eric, if there are more problems, 
please open another PR and have a link in it to this PR. 
 
Thanks 
  Wolfgang 

-- 
   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17990

[Bug bootstrap/18972] Regression: bootstrap failure of gcc-4.0-20041212 on OpenDarwin 7.2.1/x86 (i686-apple-darwin7.2.1): Bootstrap comparison failure

[lars dot sonchocky-helldorf at hamburg dot de]

--- Additional Comments From lars dot sonchocky-helldorf at hamburg dot de  
2004-12-14 13:46 ---
Well next time I better read http://gcc.gnu.org/install/build.html thoroughly
instead of just banking on the "word of irc" instead:
It had to be 'BOOT_CFLAGS' instead of 'BOOTCFLAGS' of course.

Anyway, surprisingly 'make bootstrap STAGE1_CFLAGS="-no-cpp-precomp
-Wa,-force_cpusubtype_ALL" BOOT_CFLAGS="-O2 -g -save-temps"' worked flawlessly -
no Bootstrap comparison failure any more.

I also came to know that '-save-temps' doesn't save the .i and .s files in the
stageX directories but just in the gcc directory (so the stage2 .i and .s files
would get erased by a bootstrap or bubblestrap)

So I started over like this:

cd GCC/FSF/gcc-build/
rm -rf *
../gcc-4.0-20041212/configure --prefix=/tmp/gcc
make bootstrap STAGE1_CFLAGS="-no-cpp-precomp -Wa,-force_cpusubtype_ALL"
cd gcc

redoing stage 2 (note the additional '-fomit-frame-pointer' (which I omitted in
the first place too ;-))):

touch ../../gcc-4.0-20041212/gcc/reload.c
make restage2 BOOT_CFLAGS="-O2 -g -fomit-frame-pointer -save-temps"

now I moved reload.i and reload.s into a safe place and then redoing stage 3:

touch ../../gcc-4.0-20041212/gcc/reload.c
make restage3 BOOT_CFLAGS="-O2 -g -fomit-frame-pointer -save-temps"

then I saved the "other" reload.i and reload.s too

The comparison of all stage2 vs. stage3 files yieled absolutelly no difference
(even the .o files are similar)


Heisenbug?

Next thing I'll do is a clean 'make bootstrap STAGE1_CFLAGS="-no-cpp-precomp
-Wa,-force_cpusubtype_ALL" BOOT_CFLAGS="-O2 -g -fomit-frame-pointer"' and then
again the same with '-save-temps' added to see which (if?) one of those fails.

-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18972

[Bug middle-end/18424] [3.4/4.0 Regression] ~6x+ performance regression, constant trees not being computed.

[ericw at evcohs dot com]

--- Additional Comments From ericw at evcohs dot com  2004-12-14 14:18 
---
Subject: Re:  [3.4/4.0 Regression] ~6x+ performance regression, constant trees 
not being computed.

On 14 Dec 2004 at 12:33, schlie at comcast dot net wrote:

> 
> --- Additional Comments From schlie at comcast dot net  2004-12-14 12:33 
> ---
> Subject: Re:  [3.4/4.0 Regression] ~6x+ performance
>  regression, constant trees not being computed.
> 
> Nope, unfortunately not as of yesterday, since reload.c was tweaked last
> week.

Please file a separate bug report about this ASAP.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18424

[Bug c++/18975] Copying objects with mutable non-static data members

[wolfgang dot roehrl at de dot gi-de dot com]

--- Additional Comments From wolfgang dot roehrl at de dot gi-de dot com  
2004-12-14 14:19 ---
Subject: Antwort:  Copying objects with mutable non-static data
 members





Hi all,

I'm responding to  Comments From nathan at gcc dot gnu dot org  2004-12-14
13:57 (bug 18975):

I just tried the code fragment with the Comeau online compiler. The
compiler does generate implicitly the copy contructor but it refuses to
generate
implicitly the copy assignment operator. That means the Comeau compiler
translates the mentioned code fragment if line 20 is un-commented, i.e. if
we have an user-defined copy assignment operator. But it is not necessary
to un-comment line 19, i.e. we don't need an user-defined copy constructor.

Regards,
W. Roehrl



-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18975

[Bug c/18715] [4.0 Regression] warning: "enumeration value not handled in switch" for '...' ranges

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2004-12-14 
14:34 ---
Patch here: .

-- 
   What|Removed |Added

   Keywords||patch


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18715

[Bug c++/18986] New: GCC Manual does not specify standard for C++

[llewins at raytheon dot com]

Section 2 of the GCC manual details the standards followed for each language 
supported by gcc. Notably absent is any reference for the C++ language.

I assume the basic answer is ISO/IEC 14882-1998. What about Technical 
Corrigendum 1 (TC1) is that also supported? Further, I note that several DRs 
which are not part of TC1 are currently supported by 3.4.3 (for example DR45 
and DR77). Since these DRs are at WP status, they are not officially part of 
the ISO standard. Therefore they should at least be seperately listed so that 
users and maintainers alike know what language is being supported. Better yet, 
a flag (ala C -ansi) should be available to disable DRs which are not part of 
the standard.

-- 
   Summary: GCC Manual does not specify standard for C++
   Product: gcc
   Version: 3.4.3
Status: UNCONFIRMED
  Severity: normal
  Priority: P2
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: llewins at raytheon dot com
CC: gcc-bugs at gcc dot gnu dot org,llewins at raytheon dot
com


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18986

[Bug c++/18984] [4.0 regression] ICE in check_pointer_types_r

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2004-12-14 
15:39 ---
Patch here: .

-- 
   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |pinskia at gcc dot gnu dot
   |dot org |org
 Status|NEW |ASSIGNED
   Keywords||patch


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18984

[Bug middle-end/18952] [3.3 only] compiler internal error

[pinskia at gcc dot gnu dot org]

-- 
   What|Removed |Added

Summary|compiler internal error |[3.3 only] compiler internal
   ||error
   Target Milestone|--- |3.3.6


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18952

[Bug fortran/18977] LAPACK test xeigtsts segfaults with optimization

[sgk at troutmask dot apl dot washington dot edu]

--- Additional Comments From sgk at troutmask dot apl dot washington dot 
edu  2004-12-14 16:06 ---
My success with LAPACK is on i386-*-FreeBSD.  LAPACK
dies a horrible death on amd64-*-FreeBSD.  Your segfault
is a BUS ERROR for me.  I believe this is a x86_64 target
problem.

-- 
steve

-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18977

[Bug fortran/5900] [g77 & gfortran] Lapack regressions since g77 2.95.2

[Thomas dot Koenig at online dot de]

--- Additional Comments From Thomas dot Koenig at online dot de  2004-12-14 
16:13 ---
... I forgot to add, on a ia64-unknown-linux-gnu running
RedHat ES 3.0.

-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=5900

[Bug libstdc++/18889] Unable to build libstdc++-v3

[mike at tedder dot com]

--- Additional Comments From mike at tedder dot com  2004-12-14 16:24 
---
Created an attachment (id=7741)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=7741&action=view)
requested config.log from failed compile (in nof)

taken from
"/usr/src/gcc-3.4.3-objdir/powerpc-unknown-linux-gnu/nof/libstdc++-v3"


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18889

[Bug target/18989] A few potentially ominous, and several likely harmless warnings during 4.0 build

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2004-12-14 
16:51 ---
This one cannot be fixed:
gcc -c   -g -O2  -DIN_GCC -DCROSS_COMPILE  -W -Wall -Wwrite-strings 
-Wstrict-prototypes 
-Wmissing-prototypes  -fno-common -Wno-error  -DHAVE_CONFIG_H -DGENERATOR_FILE  
  -I. 
-Ibuild -I../../gcc/gcc -I../../gcc/gcc/build -I../../gcc/gcc/../include 
-I../../gcc/gcc/../libcpp/include  
\
 -o build/gengtype-yacc.o gengtype-yacc.c
/usr/share/bison.simple: In function `yyparse':
/usr/share/bison.simple:614: warning: comparison between signed and unsigned
/usr/share/bison.simple:626: warning: comparison between signed and unsigned


The following is a target one:
gcc -c   -g -O2  -DIN_GCC -DCROSS_COMPILE  -W -Wall -Wwrite-strings 
-Wstrict-prototypes 
-Wmissing-prototypes  -fno-common   -DHAVE_CONFIG_H-I. -I. -I../../gcc/gcc 
-I../../gcc/gcc/. 
-I../../gcc/gcc/../include -I../../gcc/gcc/../libcpp/include  
../../gcc/gcc/varasm.c -o varasm.o
../../gcc/gcc/varasm.c: In function `assemble_variable':
../../gcc/gcc/varasm.c:1699: warning: empty body in an if-statement
../../gcc/gcc/varasm.c: In function `const_rtx_hash_1':
../../gcc/gcc/varasm.c:2843: warning: right shift count >= width of type


The long double bugs cannot be fixed, they are warnings only from the Apple's 
gcc.

The warnings from gengtype cannot be fixed.



-- 
   What|Removed |Added

 Status|UNCONFIRMED |NEW
  Component|c   |target
 Ever Confirmed||1
   Last reconfirmed|-00-00 00:00:00 |2004-12-14 16:51:18
   date||


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18989

[Bug c/18989] New: A few potentially ominous, and several likely harmless warnings during 4.0 build

[schlie at comcast dot net]

Warnings generated during a failed avr target build of 4.0 as of today, on a 
mac/dwawin-7.6 host 
which should likely be verified as being harmless, and then silenced if so. 
(sending the report just in 
case the build failure may be related to one of the more ominous warnings, and 
for reference: built via
../gcc/configure --target=avr --disable-nls --enable-languages=c )

[ other more target specific warnings/errors noted via PR:18988, and noted at 
the end ]

--- don't know where the below should have been defined, but seems fragile?:

gcc   -g -O2  -DIN_GCC -DCROSS_COMPILE  -W -Wall -Wwrite-strings 
-Wstrict-prototypes -Wmissing-
prototypes  -fno-common   -DHAVE_CONFIG_H -DGENERATOR_FILE  -o build/gengtype \
 build/gengtype.o build/gengtype-lex.o build/gengtype-yacc.o \
 build/errors.o ../build-powerpc-apple-darwin7.6.0/libiberty/libiberty.a
build/gengtype
warning: structure `c_arg_info' used but not defined
warning: structure `c_switch' used but not defined
warning: structure `reorder_block_def' used but not defined
warning: structure `et_node' used but not defined
warning: structure `loop' used but not defined
warning: structure `reg_info_def' used but not defined
warning: structure `value_set' used but not defined
warning: structure `alias_var_def' used but not defined
warning: structure `c_arg_info' used but not defined
warning: structure `c_switch' used but not defined
warning: structure `reorder_block_def' used but not defined
warning: structure `et_node' used but not defined
warning: structure `loop' used but not defined
warning: structure `reg_info_def' used but not defined
warning: structure `value_set' used but not defined
warning: structure `alias_var_def' used but not defined
echo timestamp > s-gtype

--- the last two warnings below imply something's fragile?:

gcc  -I../../gcc/libcpp -I. -I../../gcc/libcpp/../include 
-I../../gcc/libcpp/include  -g -O2  -W -Wall 
-Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -pedantic 
-Wno-long-long  -I../../gcc/
libcpp -I. -I../../gcc/libcpp/../include -I../../gcc/libcpp/include  -c 
../../gcc/libcpp/macro.c
In file included from ../../gcc/libcpp/system.h:269,
 from ../../gcc/libcpp/macro.c:27:
../../gcc/include/libiberty.h:80: warning: function declaration isn't a 
prototype
../../gcc/libcpp/macro.c: In function `padding_token':
../../gcc/libcpp/macro.c:913: warning: assignment discards qualifiers from 
pointer target type
../../gcc/libcpp/macro.c: In function `create_iso_definition':
../../gcc/libcpp/macro.c:1422: warning: assignment from incompatible pointer 
type

--- likely not a big deal, but would be nicer if verified/silenced:

gcc -c   -g -O2  -DIN_GCC -DCROSS_COMPILE  -W -Wall -Wwrite-strings 
-Wstrict-prototypes 
-Wmissing-prototypes  -fno-common -Wno-error  -DHAVE_CONFIG_H -DGENERATOR_FILE  
  -I. 
-Ibuild -I../../gcc/gcc -I../../gcc/gcc/build -I../../gcc/gcc/../include 
-I../../gcc/gcc/../libcpp/include  
\
 -o build/gengtype-yacc.o gengtype-yacc.c
/usr/share/bison.simple: In function `yyparse':
/usr/share/bison.simple:614: warning: comparison between signed and unsigned
/usr/share/bison.simple:626: warning: comparison between signed and unsigned

--- not a big deal, but would be nicer if prototypes were added to silence:

gcc  -I../../gcc/libcpp -I. -I../../gcc/libcpp/../include 
-I../../gcc/libcpp/include  -g -O2  -W -Wall 
-Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -pedantic 
-Wno-long-long  -I../../gcc/
libcpp -I. -I../../gcc/libcpp/../include -I../../gcc/libcpp/include  -c 
../../gcc/libcpp/charset.c
In file included from ../../gcc/libcpp/system.h:269,
 from ../../gcc/libcpp/charset.c:22:
../../gcc/include/libiberty.h:80: warning: function declaration isn't a 
prototype
gcc  -I../../gcc/libcpp -I. -I../../gcc/libcpp/../include 
-I../../gcc/libcpp/include  -g -O2  -W -Wall 
-Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -pedantic 
-Wno-long-long  -I../../gcc/
libcpp -I. -I../../gcc/libcpp/../include -I../../gcc/libcpp/include  -c 
../../gcc/libcpp/directives.c
In file included from ../../gcc/libcpp/system.h:269,
 from ../../gcc/libcpp/directives.c:23:
../../gcc/include/libiberty.h:80: warning: function declaration isn't a 
prototype
gcc  -I../../gcc/libcpp -I. -I../../gcc/libcpp/../include 
-I../../gcc/libcpp/include  -g -O2  -W -Wall 
-Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -pedantic 
-Wno-long-long  -I../../gcc/
libcpp -I. -I../../gcc/libcpp/../include -I../../gcc/libcpp/include  -c 
../../gcc/libcpp/errors.c
In file included from ../../gcc/libcpp/system.h:269,
 from ../../gcc/libcpp/errors.c:27:
../../gcc/include/libiberty.h:80: warning: function declaration isn't a 
prototype
gcc  -I../../gcc/libcpp -I. -I../../gcc/libcpp/../include 
-I../../gcc/libcpp/include  -g -O2  -W -Wall 
-Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -pedantic 
-Wno-long-long  -I../../gcc/
libcpp -I. -I../../gcc/libcpp/../include -I..

[Bug c++/18975] Copying objects with mutable non-static data members

[nathan at gcc dot gnu dot org]

--- Additional Comments From nathan at gcc dot gnu dot org  2004-12-14 
16:55 ---
(In reply to comment #4)
I can't tell what's being said here.  IIUC, you're saying that
Comeau (which uses the edg frontend) also rejects the code.

-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18975

[Bug c++/18492] [4.0 regression] mmix-knuth-mmixware,HP-UX testsuite failure: g++.old-deja/g++.other/thunk1.C

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2004-12-14 
16:30 ---
Here is a reduced testcase at least for mmix:
struct X{ ~X(); };
struct B
{
  virtual void a( X ) = 0;
}; 
struct D : public virtual B 
{
  void a( X );
}; 
void D::a( X ){};

-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18492

A few potentially ominous, and several likely harmless warnings during 4.0 build

[Paul Schlie]

Warnings generated during a failed avr target build of 4.0 as of today, on a
mac/dwawin-7.6 host which should likely be verified as being harmless, and
then silenced if so. (sending the report just in case the build failure may
be related to one of the more ominous warnings, and for reference: built via
../gcc/configure --target=avr --disable-nls --enable-languages=c )

[ other more target specific warnings/failures noted via another PR ]

--- don't know where the below should have been defined, but seems fragile?:

gcc   -g -O2  -DIN_GCC -DCROSS_COMPILE  -W -Wall -Wwrite-strings
-Wstrict-prototypes -Wmissing-prototypes  -fno-common   -DHAVE_CONFIG_H
-DGENERATOR_FILE  -o build/gengtype \
 build/gengtype.o build/gengtype-lex.o build/gengtype-yacc.o \
 build/errors.o ../build-powerpc-apple-darwin7.6.0/libiberty/libiberty.a
build/gengtype
warning: structure `c_arg_info' used but not defined
warning: structure `c_switch' used but not defined
warning: structure `reorder_block_def' used but not defined
warning: structure `et_node' used but not defined
warning: structure `loop' used but not defined
warning: structure `reg_info_def' used but not defined
warning: structure `value_set' used but not defined
warning: structure `alias_var_def' used but not defined
warning: structure `c_arg_info' used but not defined
warning: structure `c_switch' used but not defined
warning: structure `reorder_block_def' used but not defined
warning: structure `et_node' used but not defined
warning: structure `loop' used but not defined
warning: structure `reg_info_def' used but not defined
warning: structure `value_set' used but not defined
warning: structure `alias_var_def' used but not defined
echo timestamp > s-gtype

--- the last two warnings below imply something's fragile?:

gcc  -I../../gcc/libcpp -I. -I../../gcc/libcpp/../include
-I../../gcc/libcpp/include  -g -O2  -W -Wall -Wwrite-strings
-Wstrict-prototypes -Wmissing-prototypes -pedantic -Wno-long-long
-I../../gcc/libcpp -I. -I../../gcc/libcpp/../include
-I../../gcc/libcpp/include  -c ../../gcc/libcpp/macro.c
In file included from ../../gcc/libcpp/system.h:269,
 from ../../gcc/libcpp/macro.c:27:
../../gcc/include/libiberty.h:80: warning: function declaration isn't a
prototype
../../gcc/libcpp/macro.c: In function `padding_token':
../../gcc/libcpp/macro.c:913: warning: assignment discards qualifiers from
pointer target type
../../gcc/libcpp/macro.c: In function `create_iso_definition':
../../gcc/libcpp/macro.c:1422: warning: assignment from incompatible pointer
type

--- likely not a big deal, but would be nicer if verified/silenced:

gcc -c   -g -O2  -DIN_GCC -DCROSS_COMPILE  -W -Wall -Wwrite-strings
-Wstrict-prototypes -Wmissing-prototypes  -fno-common -Wno-error
-DHAVE_CONFIG_H -DGENERATOR_FILE-I. -Ibuild -I../../gcc/gcc
-I../../gcc/gcc/build -I../../gcc/gcc/../include
-I../../gcc/gcc/../libcpp/include  \
 -o build/gengtype-yacc.o gengtype-yacc.c
/usr/share/bison.simple: In function `yyparse':
/usr/share/bison.simple:614: warning: comparison between signed and unsigned
/usr/share/bison.simple:626: warning: comparison between signed and unsigned

--- not a big deal, but would be nicer if prototypes were added to silence:

gcc  -I../../gcc/libcpp -I. -I../../gcc/libcpp/../include
-I../../gcc/libcpp/include  -g -O2  -W -Wall -Wwrite-strings
-Wstrict-prototypes -Wmissing-prototypes -pedantic -Wno-long-long
-I../../gcc/libcpp -I. -I../../gcc/libcpp/../include
-I../../gcc/libcpp/include  -c ../../gcc/libcpp/charset.c
In file included from ../../gcc/libcpp/system.h:269,
 from ../../gcc/libcpp/charset.c:22:
../../gcc/include/libiberty.h:80: warning: function declaration isn't a
prototype
gcc  -I../../gcc/libcpp -I. -I../../gcc/libcpp/../include
-I../../gcc/libcpp/include  -g -O2  -W -Wall -Wwrite-strings
-Wstrict-prototypes -Wmissing-prototypes -pedantic -Wno-long-long
-I../../gcc/libcpp -I. -I../../gcc/libcpp/../include
-I../../gcc/libcpp/include  -c ../../gcc/libcpp/directives.c
In file included from ../../gcc/libcpp/system.h:269,
 from ../../gcc/libcpp/directives.c:23:
../../gcc/include/libiberty.h:80: warning: function declaration isn't a
prototype
gcc  -I../../gcc/libcpp -I. -I../../gcc/libcpp/../include
-I../../gcc/libcpp/include  -g -O2  -W -Wall -Wwrite-strings
-Wstrict-prototypes -Wmissing-prototypes -pedantic -Wno-long-long
-I../../gcc/libcpp -I. -I../../gcc/libcpp/../include
-I../../gcc/libcpp/include  -c ../../gcc/libcpp/errors.c
In file included from ../../gcc/libcpp/system.h:269,
 from ../../gcc/libcpp/errors.c:27:
../../gcc/include/libiberty.h:80: warning: function declaration isn't a
prototype
gcc  -I../../gcc/libcpp -I. -I../../gcc/libcpp/../include
-I../../gcc/libcpp/include  -g -O2  -W -Wall -Wwrite-strings
-Wstrict-prototypes -Wmissing-prototypes -pedantic -Wno-long-long
-I../../gcc/libcpp -I. -I../../gcc/libcpp/../include
-I../../gcc/libcpp/include  -c ../../gcc/libcpp/expr.c
In file included 

[Bug c/18988] 4.0 build failure resulting in internal compiler error, not diagnostic.

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2004-12-14 
16:40 ---
I don't know why someone asked you to file another bug but anyways, this is a 
dup of bug 18887.

*** This bug has been marked as a duplicate of 18887 ***

-- 
   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||DUPLICATE


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18988

[Bug middle-end/18887] [4.0 Regression] libgcc2.h Improperly determines required built-in function size requirements.

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2004-12-14 
16:40 ---
*** Bug 18988 has been marked as a duplicate of this bug. ***

-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18887

[Bug fortran/18990] New: ICE in gfc_get_derived_type, at fortran/trans-types.c

[tow21 at cam dot ac dot uk]

The attached (invalid) code gives the following error message: 
 
parabrisas% gfortran -c -g core.f90 
core.f90:12: internal compiler error: in gfc_get_derived_type, at 
fortran/trans-types.c:1399 
Please submit a full bug report, 
with preprocessed source if appropriate. 
 
(The code is invalid since MAX_BUFF_SIZE is undeclared.) 
 
This is using gcc cvs from yesterday: 
 
parabrisas% gfortran --version 
GNU Fortran 95 (GCC 4.0.0 20041213 (experimental)) 
Copyright (C) 2004 Free Software Foundation, Inc. 
 
parabrisas% cat core.f90 
module core 
 
  type, public  :: buffer_t 
 private 
 character(len=MAX_BUFF_SIZE)  :: str 
  end type buffer_t 
 
  private 
 
CONTAINS 
 
  function buffer_to_str(buffer) result(a) 
type(buffer_t), intent(in)  :: buffer 
integer :: a 
 
 a = 1 
  end function buffer_to_str 
 
end module core

-- 
   Summary: ICE in gfc_get_derived_type, at fortran/trans-types.c
   Product: gcc
   Version: 4.0.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P2
 Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: tow21 at cam dot ac dot uk
CC: gcc-bugs at gcc dot gnu dot org


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18990

[Bug fortran/18991] New: ICE in gfc_conv_descriptor_data with character array pointer.

[tow21 at cam dot ac dot uk]

attached code fails with: 
 
parabrisas% gfortran -c -g bug3.F90 
bug3.F90: In function 'de': 
bug3.F90:1: internal compiler error: in gfc_conv_descriptor_data, at 
fortran/trans-array.c:183 
Please submit a full bug report, 
with preprocessed source if appropriate. 
 
parabrisas% cat bug3.F90 
SUBROUTINE de( array ) 
character(len=*), dimension(:), pointer :: array 
logical :: a 
a = associated(array)  
END SUBROUTINE de 
 
 
This is probably related to PR 17202, but is not the same. (in this, the 
strings are assumed length, and the ICE is in a different routine.)

-- 
   Summary: ICE in gfc_conv_descriptor_data with character array
pointer.
   Product: gcc
   Version: 4.0.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P2
 Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: tow21 at cam dot ac dot uk
CC: gcc-bugs at gcc dot gnu dot org


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18991

[Bug middle-end/17340] [4.0 Regression] Internal error compiling with -O3

[steven at gcc dot gnu dot org]

--- Additional Comments From steven at gcc dot gnu dot org  2004-12-14 
17:49 ---
Thread with patch and discussion starts here:
http://gcc.gnu.org/ml/gcc-patches/2004-12/msg01041.html

-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17340

[Bug target/18912] FW: gcc 3.3.1 for Powerpc optimzation flag -Os generates bad code

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2004-12-14 
17:55 ---
Closing as fixed then.

-- 
   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution||FIXED
   Target Milestone|--- |3.4.1


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18912

[Bug rtl-optimization/18992] delete_trivially_dead_insns made ineffective for two-address targets

[pinskia at gcc dot gnu dot org]

-- 
   What|Removed |Added

   Severity|normal  |minor
 Status|UNCONFIRMED |NEW
 Ever Confirmed||1
   Keywords||missed-optimization, patch
   Last reconfirmed|-00-00 00:00:00 |2004-12-14 18:25:07
   date||
   Target Milestone|--- |4.1.0


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18992

[Bug rtl-optimization/18992] New: delete_trivially_dead_insns made ineffective for two-address targets

[amylaar at gcc dot gnu dot org]

delete_trivially_dead_insns is no longer able to remove sequences
where the same register is first set and then modifed in a sequence of
instructions to compute a particular value, as it is common on two-address
machines.  This affects both the 3.4 series and 4.0 .  Details of the
problem and a patch are here:

http://gcc.gnu.org/ml/gcc-patches/2004-05/msg01037.html

-- 
   Summary: delete_trivially_dead_insns made ineffective for two-
address targets
   Product: gcc
   Version: 4.0.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P2
 Component: rtl-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: amylaar at gcc dot gnu dot org
CC: gcc-bugs at gcc dot gnu dot org


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18992

[Bug libgcj/18996] New: java.util.zip giving corrupt data or throwing ZipException on correct archives

[nlite at users dot sf dot net]

gcj (GCC) 4.0.0 20040924 (experimental)
Windows XP on a Pentium 4
I'm using Mohan's build (thisiscool.com)

Using a ZipFile, especially to open a "large" archive (43 files, ~90kb), often
results in ZipExceptions ("Deflated stream ends early.") or corrupted data. I
tried several archivers such as 7zip, WinRAR, Sun's jar and fastjar (renaming
.jar to .zip) but it only really works on 1-file-archives. The testcase i'll
attach can be compiled with
gcj --main=Main Main.java
With the test archive i'll also attach, it'll give an
Exception in thread "main" java.util.zip.ZipException: Deflated stream ends 
early.

-- 
   Summary: java.util.zip giving corrupt data or throwing
ZipException on correct archives
   Product: gcc
   Version: 4.0.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P2
 Component: libgcj
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: nlite at users dot sf dot net
CC: gcc-bugs at gcc dot gnu dot org,java-prs at gcc dot gnu
dot org
 GCC build triplet: i686-win32
  GCC host triplet: i686-win32
GCC target triplet: i686-win32


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18996

[Bug libgcj/18996] java.util.zip giving corrupt data or throwing ZipException on correct archives

[nlite at users dot sf dot net]

--- Additional Comments From nlite at users dot sf dot net  2004-12-14 
19:07 ---
Created an attachment (id=7743)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=7743&action=view)
an archive belonging to the testcase


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18996

[Bug c++/18793] [4.0 regression] ICE in cp_expr_size

[cvs-commit at gcc dot gnu dot org]

--- Additional Comments From cvs-commit at gcc dot gnu dot org  2004-12-14 
19:38 ---
Subject: Bug 18793

CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED]   2004-12-14 19:38:26

Modified files:
gcc/testsuite  : ChangeLog 
gcc/cp : ChangeLog cp-objcp-common.c 
Added files:
gcc/testsuite/g++.dg/init: aggr3.C 

Log message:
PR c++/18793
* cp-objcp-common.c (cp_expr_size): Loosen assertion.

PR c++/18793
* g++.dg/init/aggr3.C: New test.

Patches:
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gcc&r1=1.4754&r2=1.4755
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/g++.dg/init/aggr3.C.diff?cvsroot=gcc&r1=NONE&r2=1.1
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/ChangeLog.diff?cvsroot=gcc&r1=1.4533&r2=1.4534
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/cp-objcp-common.c.diff?cvsroot=gcc&r1=1.4&r2=1.5



-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18793

[Bug fortran/18998] New: Gfortran produces wrong output (c/f to g77)

[deji_aking at yahoo dot ca]

I'm sorry the summary seems so vague, I'm not so sure why it's behaving that 
way.
Executing the attached code (a simple i/o around a numerical recipe FFT
subroutine) produces the following;
[EMAIL PROTECTED] ~]$ gfortran fft2.for -o resu2
[EMAIL PROTECTED] ~]$ ./resu2
   0.00   0.00
   0.00   0.00
   4.00   0.00
   0.00   0.00
   0.00   0.00
   0.00   0.00
   0.00   4.00
   0.00   0.00
STOP 0
Doing the same using g77 produces;
[EMAIL PROTECTED] ~]$ g77 fft2.for -o resu2
[EMAIL PROTECTED] ~]$ ./resu2
  0.  0.
  0.  0.
  4.  0.
  0.  0.
  0.  0.
  0.  0.
  4.  0.
  0.  0.

The g77 output is actually right and the gfortran one, wrong (swaping the
imaginary part for the real).

-- 
   Summary: Gfortran produces wrong output (c/f to g77)
   Product: gcc
   Version: 4.0.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P2
 Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: deji_aking at yahoo dot ca
CC: gcc-bugs at gcc dot gnu dot org
  GCC host triplet: i686-pc-linux


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18998

[Bug fortran/18998] Gfortran produces wrong output (c/f to g77)

[deji_aking at yahoo dot ca]

--- Additional Comments From deji_aking at yahoo dot ca  2004-12-14 19:30 
---
Created an attachment (id=7744)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=7744&action=view)
FFT code


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18998

[Bug fortran/18998] Gfortran produces wrong output (c/f to g77)

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2004-12-14 
20:07 ---
(In reply to comment #3)
> (In reply to comment #2)
> > This works for me on ppc-darwin with gcc 4.0.0 (20041214).
> 
> I should add that I noticed the problem with gcc 4.0.0 (20041211) on FC3

That still does not give enough information.  What target is this, x86?

-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18998

[Bug libgcj/14670] [win32] gcj & high ascii: incorrectly translated / linux: fails to compile

[tromey at gcc dot gnu dot org]

--- Additional Comments From tromey at gcc dot gnu dot org  2004-12-14 
20:13 ---
If by "high ascii" you mean byte with the high bit
set, then you want to compile those with "--encoding ISO-8859-1"
or the like.

Whether this works on Windows, I don't know.  It depends on
whether iconv is available on that platform (or if you are
using libiconv)

What happens if you compile with "gcj -C" and then run the
resulting bytecode using Sun's "java"?  If this works, then the
problem is not in the compiler at all but is in the runtime's
choice of default character set.



-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14670

[Bug libstdc++/18997] Segmentation Violation in pthread_getspecific

[dannysmith at users dot sourceforge dot net]

--- Additional Comments From dannysmith at users dot sourceforge dot net  
2004-12-14 19:58 ---
What happens if you revert this patch
http://gcc.gnu.org/ml/gcc-cvs/2004-11/msg00265.html

Alternatively, does adding 
#define GTHREAD_USE_WEAK 0 
to config/i386/cygwin.h 

and 
to libstdc++-v3/config/os/newlib/os_defines.h

help?

Danny

-- 
   What|Removed |Added

 CC||dannysmith at users dot
   ||sourceforge dot net


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18997

[Bug fortran/18998] Gfortran produces wrong output (c/f to g77)

[deji_aking at yahoo dot ca]

--- Additional Comments From deji_aking at yahoo dot ca  2004-12-14 20:06 
---
(In reply to comment #2)
> This works for me on ppc-darwin with gcc 4.0.0 (20041214).

I should add that I noticed the problem with gcc 4.0.0 (20041211) on FC3

-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18998

[Bug libstdc++/18997] Segmentation Violation in pthread_getspecific

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2004-12-14 
19:34 ---
I really doubt that libstdc++ is at fault here, lets look at the backtrace:
#0  0x00405ec0 in pthread_getspecific ()
#1  0x0040528d in _Unwind_SjLj_Register (fc=0x22eee8)
at /home/User/cvsroot/gcc/gcc/gthr-posix.h:496
#2  0x00430f26 in std::ios_base::Init::Init() ()

See how we are in registering a exception handling, I think this is just a case 
where we are trying to 
setup the exception location but exception handling is not initialized.

-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18997

[Bug fortran/18998] Gfortran produces wrong output (c/f to g77)

[deji_aking at yahoo dot ca]

--- Additional Comments From deji_aking at yahoo dot ca  2004-12-14 20:55 
---
(In reply to comment #4)

> > I should add that I noticed the problem with gcc 4.0.0 (20041211) on FC3
> 
> That still does not give enough information.  What target is this, x86?

Yes. I thought I put that in the original bug report.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18998

[Bug fortran/18998] Gfortran produces wrong output (c/f to g77)

[sgk at troutmask dot apl dot washington dot edu]

--- Additional Comments From sgk at troutmask dot apl dot washington dot 
edu  2004-12-14 20:35 ---
The compiles and runs correctly on amd64-*-FreeBSD.

-- 
steve

-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18998

[Bug libfortran/18985] opening unit 6 messes up print

[tobi at gcc dot gnu dot org]

--- Additional Comments From tobi at gcc dot gnu dot org  2004-12-14 22:19 
---
I think that's what intended, g77 behaves the same way. I'm somewhat torn
between INVALID and WONTFIX. If the user wants to use unit 6 for something else,
and still have PRINT * print to the console, he can preconnect stdout to some
other unit via the GFORTRAN_STDOUT_UNIT environment variable.

-- 
   What|Removed |Added

 CC||tobi at gcc dot gnu dot org
 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18985

[Bug libfortran/18982] open(status="new") does not generate an error if the file exists

[tobi at gcc dot gnu dot org]

-- 
   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed||1
   Last reconfirmed|-00-00 00:00:00 |2004-12-14 22:13:28
   date||


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18982

[Bug fortran/18993] gfortran fails to recognise comment line.

[tobi at gcc dot gnu dot org]

--- Additional Comments From tobi at gcc dot gnu dot org  2004-12-14 22:24 
---
This is unrelated to preprocessing (changing the extension to .f doesn't solve
the problem). Changing 'C' to '!' fixes the problem.

It looks like the scanner is mistaken about the column count.

-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18993

[Bug libfortran/18924] segfault in dot_product with missing interface information

[tobi at gcc dot gnu dot org]

--- Additional Comments From tobi at gcc dot gnu dot org  2004-12-14 22:41 
---
The code as given is not valid, but since we segfault at runtime even with
-fbounds-check one can argue that this is a real deficiency.

-- 
   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed||1
   Last reconfirmed|-00-00 00:00:00 |2004-12-14 22:41:25
   date||


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18924

[Bug target/18910] [4.0 Regression] unrecognisable insn in regclass on x86/amd64

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2004-12-14 
23:35 ---
*** Bug 19000 has been marked as a duplicate of this bug. ***

-- 
   What|Removed |Added

 CC||hjl at lucon dot org


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18910

[Bug target/19000] [4.0 regression] ICE with -O and -O -fPIC

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2004-12-14 
23:35 ---
This is an exact dup of bug 18910.

*** This bug has been marked as a duplicate of 18910 ***

-- 
   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||DUPLICATE


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19000

[Bug c++/18738] [3.4/4.0 Regression] typename not allowed with non-dependent qualified name

[mmitchel at gcc dot gnu dot org]

--- Additional Comments From mmitchel at gcc dot gnu dot org  2004-12-15 
00:45 ---
Fixed in GCC 4.0.

-- 
   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18738

[Bug ada/19002] New: GNAT BUG DETECTED, unqualified record aggregate triggers

[bauhaus at futureapps dot de]

The code appended below triggers a bug box.

$ gcc -v
Reading specs from /opt/GCC/4/lib/gcc/i686-pc-linux-gnu/4.0.0/specs
Configured with: /opt/gcc/configure --prefix=/opt/GCC/4 --enable-languages=c,ada
--enable-werror
Thread model: posix
gcc version 4.0.0 20041214 (experimental)


The box does not appear if -gnatc is used.
The offending(?) line is in the procedure Space_Info.mark, in the
body of Space_Info. (The file space_info.adb is not listed below the
box but must be present to trigger the bug).
The line has an unqualified record aggregate.
If the aggregate is qualified, the bug box goes away.

The AI302 sources used are as of 2004-12-14 (from the tigris site via CVS).

Systems:
  Debian/GNU testing, 2.6.8-1-686-smp, GCC 4.0.0 as above
(The same error on Debian with gcc 3.4.2-2, 
and W2K, MinGW 1.0? (gcc 3.4.2))


$ gnatmake matter
gcc -c matter.ads
+===GNAT BUG DETECTED==+
| 4.0.0 20041214 (experimental) (i686-pc-linux-gnu) Assert_Failure 
sinfo.adb:2474|
| Error detected at space_info.adb:19:48 [matter.ads:5:4]  |
| Please submit a bug report; see http://gcc.gnu.org/bugs.html.|
| Include the entire contents of this bug box in the report.   |
| Include the exact gcc or gnatmake command that you entered.  |
| Also include sources listed below in gnatchop format |
| (concatenated together with no headers between files).   |
+==+

Please include these source files with error report
Note that list may not be accurate in some cases, 
so please double check that the problem can still 
be reproduced with the set of files listed.

matter.ads
space_info.ads
coordinate_system.ads
ai302.ads
ai302-containers.ads
ai302-containers-vectors.ads
list may be incomplete
compilation abandoned
gnatmake: "matter.ads" compilation error
$

(no *.ali files, no *.s files are written)

with Coordinate_System;
with AI302.Containers.Vectors;

generic
   farthest_east_west: Natural := 100;
   -- number of rectangles in the direction

   farthest_north_south: Natural := 100;
   -- number of rectangles in the direction

package Space_Info is

   pragma preelaborate;

   subtype Extent is
 Natural range 1 .. Natural'max(farthest_east_west, farthest_north_south);
   -- possible number of a space cube in one dimension

   package Space is new Coordinate_System (Extent, Dim => 2);


   type Obstacle is (None, Rock);
   --
   for Obstacle'size use 1;


   type Known_Space is
  array(Extent range <>, Extent range <>) of Obstacle;
   --  all that counts in space is that you don't try to
   -- fly through rocks.
   -- the number of dimensions should be kept in sync with
   -- the instantiation of `Coordinate_System`

   pragma Pack(Known_Space);

   subtype Space_Section is Known_Space(Extent'first .. farthest_east_west,
Extent'first .. farthest_north_south);


   --  The space map is available to the ships as a shared resource.
   --  If the map is declared to have a log, then any task may request
   --  a list of recently marked points.

   package Cartographic is

  type Discovery is record
 here: Space.Point;
 -- this `Point` has recently been discovered. (Or a ship could have
 -- discovered that the previous `Obstacle` is no longer there.
 -- This is not currently implemented.)

 marked: Obstacle;
 -- what kind of `Obstacle` the ship has found `here`

  end record;


  package Lists_of_Points is new AI302.Containers.Vectors
(Element_Type => Discovery,
 Index_Type => Natural);


  type Discoveries is tagged record
 logged: Lists_of_Points.Vector;
 -- acts a lot like a queue

  end record;

   end Cartographic;


   protected type Map(logging_requested: Boolean) is

  --  An area is divided into small rectangles/cubes.  Note that a Map
  --  need not cover all known space, depending on the constraints on
  --  `Space_Section`


  procedure mark(here: Space.Point; item: Obstacle := Rock);

  function read(here: Space.Point) return Obstacle;

  procedure diff(result: out Cartographic.Discoveries);
  -- A copy of the list of `Point`s recently `mark`ed. The internal
  -- list is cleared.
  pragma Precondition(logging_requested);

   private
  grid: Space_Section;
  log: Cartographic.Lists_of_Points.Vector;
   end Map;



end Space_Info;

package body Space_Info is




   protected body Map is

  -- 
  -- mark
  -- 

  procedure mark(here: Space.Point; item: Obstacle := Rock) is
 use Cartographic.Lists_of_Points;
  begin
 grid(here(1), here(2)) := item;

 -- This line is reported:
 if 

[Bug rtl-optimization/19001] [3.4/4.0 Regression] Loops with power of two step and variable bounds not unrolled

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2004-12-15 
04:55 ---
Confirmed as a regression from 3.3.2, this happens in libstdc++ as mentioned 
other places.
And I also check that 3.3.2 did not unroll a loop with non power of two step 
aka:
int check(int a,int b, char *c)
{
for(;ahttp://gcc.gnu.org/bugzilla/show_bug.cgi?id=19001

[Bug fortran/5900] [g77 & gfortran] Lapack regressions since g77 2.95.2

[Thomas dot Koenig at online dot de]

--- Additional Comments From Thomas dot Koenig at online dot de  2004-12-14 
16:07 ---
Lapack on the IA-64 does not look good right now.

Here are the results with 20041212 snapshot, with Steve Kargl's I/O
patch from http://gcc.gnu.org/ml/gcc-patches/2004-12/msg00844.html
applied:

CES:   24 out of  3276 tests failed to pass the threshold
 CEV:   92 out of   970 tests failed to pass the threshold
 CSX:   54 out of  3406 tests failed to pass the threshold
 CVX:  580 out of  5484 tests failed to pass the threshold
 CGG:1 out of  2184 tests failed to pass the threshold
 CHS:   35 out of  2058 tests failed to pass the threshold
 CHS:   39 out of  2058 tests failed to pass the threshold
 CHS:   31 out of  2058 tests failed to pass the threshold
 CHS:   35 out of  2058 tests failed to pass the threshold
 CHS:   31 out of  2058 tests failed to pass the threshold
 CST:1 out of  4662 tests failed to pass the threshold
 CST:1 out of  4662 tests failed to pass the threshold
 CST drivers:  1 out of  11664 tests failed to pass the threshold
 CGE:246 out of   3653 tests failed to pass the threshold
 CGE drivers:146 out of   4866 tests failed to pass the threshold
 CGB:   2481 out of  28893 tests failed to pass the threshold
 CGB drivers:   2642 out of  29094 tests failed to pass the threshold
 CGT:262 out of   2694 tests failed to pass the threshold
 CGT drivers:282 out of   2033 tests failed to pass the threshold
 CPO:228 out of   1628 tests failed to pass the threshold
 CPO drivers:144 out of   1910 tests failed to pass the threshold
 CPP:211 out of   1242 tests failed to pass the threshold
 CPP drivers:154 out of   1865 tests failed to pass the threshold
 CPB:657 out of   3458 tests failed to pass the threshold
 CPB drivers:432 out of   4750 tests failed to pass the threshold
 DXV drivers:200 out of   5000 tests failed to pass the threshold
 SXV drivers: 37 out of   5000 tests failed to pass the threshold
 SST:1 out of  4662 tests failed to pass the threshold
 SST drivers:  1 out of  14256 tests failed to pass the threshold
 ZES:   24 out of  3276 tests failed to pass the threshold
 ZEV:   92 out of   970 tests failed to pass the threshold
 ZSX:   51 out of  3406 tests failed to pass the threshold
 ZVX:  556 out of  5472 tests failed to pass the threshold
 ZXV drivers: 24 out of   5000 tests failed to pass the threshold
 ZHS:   39 out of  2058 tests failed to pass the threshold
 ZHS:   35 out of  2058 tests failed to pass the threshold
 ZHS:   35 out of  2058 tests failed to pass the threshold
 ZHS:   31 out of  2058 tests failed to pass the threshold
 ZHS:   35 out of  2058 tests failed to pass the threshold
 ZGE:246 out of   3653 tests failed to pass the threshold
 ZGE drivers:146 out of   4866 tests failed to pass the threshold
 ZGB:   2481 out of  28893 tests failed to pass the threshold
 ZGB drivers:   2642 out of  29094 tests failed to pass the threshold
 ZGT:262 out of   2694 tests failed to pass the threshold
 ZGT drivers:282 out of   2033 tests failed to pass the threshold
 ZPO:228 out of   1628 tests failed to pass the threshold
 ZPO drivers:144 out of   1910 tests failed to pass the threshold
 ZPP:211 out of   1242 tests failed to pass the threshold
 ZPP drivers:154 out of   1865 tests failed to pass the threshold
 ZPB:657 out of   3458 tests failed to pass the threshold
 ZPB drivers:432 out of   4750 tests failed to pass the threshold

Without the I/O patch, the following additionall failures occur:

+ CPT:120 out of   1778 tests failed to pass the threshold
+ CPT drivers: 40 out of788 tests failed to pass the threshold
+ CHE: 62 out of   1624 tests failed to pass the threshold
+ CHE drivers: 60 out of   1072 tests failed to pass the threshold
+ CHP: 60 out of   1404 tests failed to pass the threshold
+ CHP drivers: 60 out of   1072 tests failed to pass the threshold
+ CSY:169 out of   1864 tests failed to pass the threshold
+ CSY drivers:168 out of   1240 tests failed to pass the threshold
+ CSP:155 out of   1620 tests failed to pass the threshold
+ CSP drivers:168 out of   1240 tests failed to pass the threshold
+ CTR:348 out of   7672 tests failed to pass the threshold
+ CTP:316 out of   7392 tests failed to pass the threshold
+ CTB:494 out of  19888 tests failed to pass the threshold
+ CLS drivers:900 out of  65268 tests failed to pass the threshold
+ ZPT:120 out of   1778 tests failed to pass the threshold
+ ZPT drivers: 40 out of788 tests failed to pass the threshold
+ ZHE: 62 out of   1624 tests failed to pass the threshold
+ ZHE drivers: 60 out of   1072 tests failed to pass the threshold
+ ZHP: 60 out of   1404 tests failed to pass the threshold
+ ZHP drivers: 60 out of   1072 tests failed to pass the threshold
+ ZSY:169 out of   1864 tests failed to pass the threshold
+ ZSY drivers:

[Bug c++/18949] [4.0 Regression] trouble with const_cast in templates

[cvs-commit at gcc dot gnu dot org]

--- Additional Comments From cvs-commit at gcc dot gnu dot org  2004-12-14 
15:39 ---
Subject: Bug 18949

CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED]   2004-12-14 15:39:12

Modified files:
gcc/cp : ChangeLog pt.c typeck.c 
gcc/testsuite  : ChangeLog 
Added files:
gcc/testsuite/g++.dg/template: cast1.C 

Log message:
cp:
PR c++/18949
* pt.c (tsubst_copy_and_build):  Check that a
REFERENCE_REF_P is dereferencing a reference type.
* typeck.c (build_static_cast): Convert from reference even in a
template.
(build_reinterpret_cast, build_const_cast, build_c_cast): Likewise.
testsuite:
PR c++/18949
* g++.dg/template/cast1.C: New.

Patches:
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/ChangeLog.diff?cvsroot=gcc&r1=1.4532&r2=1.4533
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/pt.c.diff?cvsroot=gcc&r1=1.956&r2=1.957
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/typeck.c.diff?cvsroot=gcc&r1=1.603&r2=1.604
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gcc&r1=1.4749&r2=1.4750
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/g++.dg/template/cast1.C.diff?cvsroot=gcc&r1=NONE&r2=1.1



-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18949

[Bug bootstrap/18972] Regression: bootstrap failure of gcc-4.0-20041212 on OpenDarwin 7.2.1/x86 (i686-apple-darwin7.2.1): Bootstrap comparison failure

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2004-12-14 
16:21 ---
(In reply to comment #5)
> Indeed a Heisenbug:
> 
> Does anyone know how I could disassemble those .o files to get something more
> human readable?

Use otool.

-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18972

[Bug bootstrap/18972] Regression: bootstrap failure of gcc-4.0-20041212 on OpenDarwin 7.2.1/x86 (i686-apple-darwin7.2.1): Bootstrap comparison failure

[lars dot sonchocky-helldorf at hamburg dot de]

--- Additional Comments From lars dot sonchocky-helldorf at hamburg dot de  
2004-12-14 16:18 ---
Indeed a Heisenbug:

reload.o from stage2 and stage3 differ when produced like this:

touch ../../gcc-4.0-20041212/gcc/reload.c
make restage2 BOOT_CFLAGS="-O2 -g -fomit-frame-pointer"
make restage3 BOOT_CFLAGS="-O2 -g -fomit-frame-pointer"

the resultingg reload.o differ just in one byte at offset B577h:

for stage2 it is: D0
for stage3 it is: C4

now in context:

stage2:  B570h: 7E B9 31 C0 8B 8C 24 D0 00 00 00 89 84 24 6C 02
stage3:  B570h: 7E B9 31 C0 8B 8C 24 C4 00 00 00 89 84 24 6C 02

Does anyone know how I could disassemble those .o files to get something more
human readable?

-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18972

[Bug libstdc++/18889] Unable to build libstdc++-v3

[mike at tedder dot com]

--- Additional Comments From mike at tedder dot com  2004-12-14 16:31 
---
I attached the config.log file you requested.  I wasn't sure if you were 
interested in the one also located in nof/, so I attached them both.

If it matters at all, I'm using binutils-2.13.90.0.10 (built with gcc-3.4.3) 
and 
 glibc-2.2.3.

Let me know if I can be of any more help.  I'm still trying to trace it down on 
my end here.  Thanks!


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18889

[Bug c/18988] New: 4.0 build failure resulting in internal compiler error, not diagnostic.

[schlie at comcast dot net]

Build as of today's cvs 4.0 ~10:10am est, configured with:
../gcc/configure --target=avr --disable-nls --enable-languages=c 

Resulting with failure:

/Applications/avr/gcc-build/gcc/xgcc -B/Applications/avr/gcc-build/gcc/ 
-B/usr/local/avr/bin/ -B/
usr/local/avr/lib/ -isystem /usr/local/avr/include -isystem 
/usr/local/avr/sys-include -O2  -DIN_GCC 
-DCROSS_COMPILE   -W -Wall -Wwrite-strings -Wstrict-prototypes 
-Wmissing-prototypes -Wold-
style-definition  -isystem ./include  -DDF=SF -Dinhibit_libc -mcall-prologues 
-g  -DIN_LIBGCC2 
-D__GCC_FLOAT_NOT_NEEDED -Dinhibit_libc -I. -I -I../../gcc/gcc -I../../gcc/gcc/ 
-I../../gcc/gcc/../
include -I../../gcc/gcc/../libcpp/include  -DL_fixdfdi -c 
../../gcc/gcc/libgcc2.c -o libgcc/./_fixdfdi.o
../../gcc/gcc/libgcc2.c: In function '__fixdfdi':
../../gcc/gcc/libgcc2.c:1198: internal compiler error: in find_valid_class, at 
reload.c:712
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html> for instructions.
make[2]: *** [libgcc/./_fixdfdi.o] Error 1
make[1]: *** [stmp-multilib] Error 2
make: *** [all-gcc] Error 2

In addition to general hopefully benign warrnings reported via another PR, these
seem more target specific than not, and may have contributed to the failure?:

--- would seem that the code in varasm.c may be broken/fragile?:

gcc -c   -g -O2  -DIN_GCC -DCROSS_COMPILE  -W -Wall -Wwrite-strings 
-Wstrict-prototypes 
-Wmissing-prototypes  -fno-common   -DHAVE_CONFIG_H-I. -I. -I../../gcc/gcc 
-I../../gcc/gcc/. 
-I../../gcc/gcc/../include -I../../gcc/gcc/../libcpp/include  
../../gcc/gcc/varasm.c -o varasm.o
../../gcc/gcc/varasm.c: In function `assemble_variable':
../../gcc/gcc/varasm.c:1699: warning: empty body in an if-statement
../../gcc/gcc/varasm.c: In function `const_rtx_hash_1':
../../gcc/gcc/varasm.c:2843: warning: right shift count >= width of type

--- wouldn't expect a long double type to be referanced if not required by the 
target?

gcc -c   -g -O2  -DIN_GCC -DCROSS_COMPILE  -W -Wall -Wwrite-strings 
-Wstrict-prototypes 
-Wmissing-prototypes  -fno-common   -DHAVE_CONFIG_H-I. -I. -I../../gcc/gcc 
-I../../gcc/gcc/. 
-I../../gcc/gcc/../include -I../../gcc/gcc/../libcpp/include  
../../gcc/gcc/alloc-pool.c -o alloc-pool.o
../../gcc/gcc/alloc-pool.c:48: warning: use of `long double' type; its size may 
change in a future 
release
../../gcc/gcc/alloc-pool.c:48: warning: (Long double usage is reported only 
once for each file.
../../gcc/gcc/alloc-pool.c:48: warning: To disable this warning, use 
-Wno-long-double.)

gcc -c   -g -O2  -DIN_GCC -DCROSS_COMPILE  -W -Wall -Wwrite-strings 
-Wstrict-prototypes 
-Wmissing-prototypes  -fno-common   -DHAVE_CONFIG_H-I. -I. -I../../gcc/gcc 
-I../../gcc/gcc/. 
-I../../gcc/gcc/../include -I../../gcc/gcc/../libcpp/include  
../../gcc/gcc/ggc-page.c -o ggc-page.o
../../gcc/gcc/ggc-page.c:208: warning: use of `long double' type; its size may 
change in a future 
release
../../gcc/gcc/ggc-page.c:208: warning: (Long double usage is reported only once 
for each file.
../../gcc/gcc/ggc-page.c:208: warning: To disable this warning, use 
-Wno-long-double.)

-- 
   Summary: 4.0 build failure resulting in internal compiler error,
not diagnostic.
   Product: gcc
   Version: 4.0.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P2
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: schlie at comcast dot net
CC: gcc-bugs at gcc dot gnu dot org
 GCC build triplet: powerpc-apple-darwin7.6.0
  GCC host triplet: powerpc-apple-darwin7.6.0
GCC target triplet: avr-unknown-none


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18988

[Bug middle-end/18952] compiler internal error

[rearnsha at gcc dot gnu dot org]

--- Additional Comments From rearnsha at gcc dot gnu dot org  2004-12-14 
15:47 ---
Your testcase compiles without error with gcc 3.4 and the development build.  On
my pre-release of gcc-3.3.4 I get an unrecognized internal instruction, but no
segmentation fault.

I'd strongly recommend that you switch to using gcc 3.4 if you want Thumb code.
 A number of bugs have been fixed over previous releases.

-- 
   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed||1
  Known to fail||3.3.4
  Known to work||3.4.1 4.0.0
   Last reconfirmed|-00-00 00:00:00 |2004-12-14 15:47:25
   date||


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18952

[Bug c/18988] 4.0 build failure resulting in internal compiler error, not diagnostic.

[schlie at comcast dot net]

--- Additional Comments From schlie at comcast dot net  2004-12-14 16:51 
---
Subject: Re:  4.0 build failure resulting in internal
 compiler error, not diagnostic.

> From: pinskia at gcc dot gnu dot org <[EMAIL PROTECTED]>
> --- Additional Comments From pinskia at gcc dot gnu dot org  2004-12-14
> I don't know why someone asked you to file another bug but anyways, this is a
> dup of bug 18887.

I basically agree, but you did?

 --- Additional Comment  #6 From  Andrew Pinski  2004-12-12 03:09 -
Also could you file another bug for not rejecting the use of these modes
because that seems like something which should have happened instead of the
current ICE.  Please attach the preprocessed  source for libgcc2.c when
compiling for _fixdfdi.





-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18988

[Bug c++/18981] [4.0 regression] ICE in cp_parser_lookup_name

[nathan at gcc dot gnu dot org]

-- 
   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |nathan at gcc dot gnu dot
   |dot org |org
 Status|NEW |ASSIGNED


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18981

[Bug fortran/18990] ICE in gfc_get_derived_type, at fortran/trans-types.c

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2004-12-14 
17:20 ---
Confirmed.

-- 
   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed||1
   Keywords||accepts-invalid, ice-
   ||checking, ice-on-invalid-
   ||code
   Last reconfirmed|-00-00 00:00:00 |2004-12-14 17:20:31
   date||


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18990

[Bug tree-optimization/18888] [4.0 regression] loops miscompiled

[law at redhat dot com]

--- Additional Comments From law at redhat dot com  2004-12-14 15:49 ---
Definitely a different problem than 18694.  I'm looking at it now.


-- 
   What|Removed |Added

  BugsThisDependsOn|18694   |


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=1

[Bug tree-optimization/18888] [4.0 regression] loops miscompiled

[law at redhat dot com]

--- Additional Comments From law at redhat dot com  2004-12-14 17:33 ---
This appears to be a bug in how we coalesce objects appearing in abnormal
PHIs.  [ We get abnormal PHIs because of the computed gotos. ]

I've got a patch which appears to generate the right code for this testcase
and I'll be testing today.  I will (of course) post a more detailed analysis
when I officially submit the patch.

Jeff

-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=1

[Bug c++/18793] [4.0 regression] ICE in cp_expr_size

[mmitchel at gcc dot gnu dot org]

--- Additional Comments From mmitchel at gcc dot gnu dot org  2004-12-14 
17:46 ---
Upon further reflection, I don't see a problem with what the gimplifier is
doing, because it does not actually try to construct the S component in the
temporary variable.

-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18793

[Bug target/18153] [3.4/4.0 Regression] -static-libgcc links in libunwind.so.7

[hjl at lucon dot org]

--- Additional Comments From hjl at lucon dot org  2004-12-14 17:52 ---
Mark, can you take a look at the patch? Thanks.

-- 
   What|Removed |Added

 CC||mark at codesourcery dot com


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18153

[Bug fortran/18991] ICE in gfc_conv_descriptor_data with character array pointer.

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2004-12-14 
17:53 ---


*** This bug has been marked as a duplicate of 15809 ***

-- 
   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||DUPLICATE


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18991

[Bug fortran/15809] ICE Using Pointer Functions

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2004-12-14 
17:53 ---
*** Bug 18991 has been marked as a duplicate of this bug. ***

-- 
   What|Removed |Added

 CC||tow21 at cam dot ac dot uk


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15809

[Bug target/18912] FW: gcc 3.3.1 for Powerpc optimzation flag -Os generates bad code

[atul dot sabharwal at tek dot com]

--- Additional Comments From atul dot sabharwal at tek dot com  2004-12-14 
17:53 ---
This bug is fixed in 3.4.1 version of gcc. I received a cross compiled version 
of gcc for MPC8540 platform with the 3.4.1 gcc based tool chain and all 
busybox apps work correctly.

-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18912

[Bug tree-optimization/18888] [4.0 regression] loops miscompiled

[law at redhat dot com]

--- Additional Comments From law at redhat dot com  2004-12-14 17:55 ---
BTW, it's pretty easy now that I've sat down and analyzed this test to see
that my tree-ssa-dom.c patch from yesterday to fix pr18694 merely masked this
bug (pr1) on Darwin.

As I mentioned earlier today, pr1 is a problem in how we handle
coalescing and abnormal edges and is going to be very sensitive to the
precise order in which we decide to coalesce objects.

Yesterday's tree-ssa-dom.c patch for 18694 can very easily change coalescing
orderings and thus could easily mask this bug.



-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=1

[Bug middle-end/18951] Invalid code generated by expand_errno_check

[cvs-commit at gcc dot gnu dot org]

--- Additional Comments From cvs-commit at gcc dot gnu dot org  2004-12-14 
18:05 ---
Subject: Bug 18951

CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED]   2004-12-14 18:04:56

Modified files:
gcc: ChangeLog builtins.c 
gcc/testsuite  : ChangeLog 
Added files:
gcc/testsuite/gcc.c-torture/execute: 20041213-1.c 

Log message:
PR middle-end/18951
* builtins.c (expand_builtin_mathfn, expand_builtin_mathfn_2,
expand_builtin_mathfn_3): Avoid using arguments passed to
save_expr after that call.

* gcc.c-torture/execute/20041213-1.c: New test.

Patches:
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcc&r1=2.6824&r2=2.6825
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/builtins.c.diff?cvsroot=gcc&r1=1.409&r2=1.410
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gcc&r1=1.4752&r2=1.4753
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gcc.c-torture/execute/20041213-1.c.diff?cvsroot=gcc&r1=NONE&r2=1.1



-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18951

[Bug fortran/18993] gfortran fails to recognise comment line.

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2004-12-14 
18:34 ---
Confirmed.

-- 
   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed||1
   Keywords||rejects-valid
   Last reconfirmed|-00-00 00:00:00 |2004-12-14 18:34:09
   date||


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18993

[Bug target/18994] New: storage class in debugging strings

[dje at gcc dot gnu dot org]

Some debugging information for AIX contains the storage class suffix because 
it is not stripped by strip_name_encoding.  See libgfortran/io/transfer.c for 
example.

-- 
   Summary: storage class in debugging strings
   Product: gcc
   Version: 4.0.0
Status: UNCONFIRMED
  Keywords: wrong-debug
  Severity: normal
  Priority: P1
 Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dje at gcc dot gnu dot org
CC: gcc-bugs at gcc dot gnu dot org
 GCC build triplet: *-*-*
  GCC host triplet: *-*-*
GCC target triplet: powerpc-ibm-aix


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18994

[Bug fortran/18993] New: gfortran fails to recognise comment line.

[tow21 at cam dot ac dot uk]

With the attached code, gfortran fails to understand that the second comment 
is a comment, and complains about an unclassified statement. 
 
parabrisas% gfortran -c bug5.F  
 In file bug5.F:5 
 
C Set default sizes for order N arrays  
1 
Error: Non-numeric character in statement label at (1) 
 In file bug5.F:5 
 
C Set default sizes for order N arrays  
1 
Error: Unclassifiable statement at (1) 
 
parabrisas% cat bug5.F 
  subroutine ordern( ) 
  real, pointer :: aux(:,:) 
C Nullify pointers 
nullify(aux) 
C Set default sizes for order N arrays 
  end subroutine ordern

-- 
   Summary: gfortran fails to recognise comment line.
   Product: gcc
   Version: 4.0.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P2
 Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: tow21 at cam dot ac dot uk
CC: gcc-bugs at gcc dot gnu dot org


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18993

[Bug rtl-optimization/18992] delete_trivially_dead_insns made ineffective for two-address targets

[amylaar at gcc dot gnu dot org]

-- 
   What|Removed |Added

OtherBugsDependingO||18995
  nThis||


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18992

[Bug middle-end/18951] Invalid code generated by expand_errno_check

[cvs-commit at gcc dot gnu dot org]

--- Additional Comments From cvs-commit at gcc dot gnu dot org  2004-12-14 
18:12 ---
Subject: Bug 18951

CVSROOT:/cvs/gcc
Module name:gcc
Branch: gcc-3_4-branch
Changes by: [EMAIL PROTECTED]   2004-12-14 18:12:32

Modified files:
gcc: ChangeLog builtins.c 
gcc/testsuite  : ChangeLog 
Added files:
gcc/testsuite/gcc.c-torture/execute: 20041213-1.c 

Log message:
PR middle-end/18951
* builtins.c (expand_builtin_mathfn, expand_builtin_mathfn_2): Avoid
using arguments passed to save_expr after that call.

* gcc.c-torture/execute/20041213-1.c: New test.

Patches:
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcc&only_with_tag=gcc-3_4-branch&r1=2.2326.2.733&r2=2.2326.2.734
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/builtins.c.diff?cvsroot=gcc&only_with_tag=gcc-3_4-branch&r1=1.275.2.4&r2=1.275.2.5
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gcc&only_with_tag=gcc-3_4-branch&r1=1.3389.2.323&r2=1.3389.2.324
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gcc.c-torture/execute/20041213-1.c.diff?cvsroot=gcc&only_with_tag=gcc-3_4-branch&r1=NONE&r2=1.1.2.1



-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18951

[Bug rtl-optimization/18995] New: delete_trivially_dead_insns fails to update the liveness information

[amylaar at gcc dot gnu dot org]

When a register is set outside of a loop and referenced inside,
update_life_info can't figure out that the set is dead because
the loop appears to still use the register according to the
lifeness information which is propagated circularily around the
loop.
delete_trivially_dead_insns can detect that such sets are dead,
and thus remove them.  However, it does not update the liveness
information. This leads to a checking ICE when doing the next
global update.

The gcc 3.2 version of this patch (short version) for this problem
looks like this: 

2004-05-17  J"orn Rennecke <[EMAIL PROTECTED]>

* cse.c (basic-block.h): #include.
(trivially_dead_nonlocal_regs): New variable.
(note_dead_set): New function.
(delete_trivially_dead_insns): If life info is available, update it.

The patch in its current form is conceptually dependent on the patch for
gcc/18992 being applied first and also has some bits to support highpart
liveness information optimizations.  It is about 100 lines of unidiff.
If someone is prepared to review the patch, I can extract an independent
patch against the then-current mainline.

-- 
   Summary: delete_trivially_dead_insns fails to update the liveness
information
   Product: gcc
   Version: 4.0.0
Status: UNCONFIRMED
  Keywords: ice-checking
  Severity: normal
  Priority: P2
 Component: rtl-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: amylaar at gcc dot gnu dot org
CC: gcc-bugs at gcc dot gnu dot org
 BugsThisDependsOn: 18992


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18995

[Bug libgcj/18996] java.util.zip giving corrupt data or throwing ZipException on correct archives

[nlite at users dot sf dot net]

--- Additional Comments From nlite at users dot sf dot net  2004-12-14 
19:06 ---
Created an attachment (id=7742)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=7742&action=view)
a testcase


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18996

[Bug libstdc++/18889] Unable to build libstdc++-v3

[mike at tedder dot com]

--- Additional Comments From mike at tedder dot com  2004-12-14 16:23 
---
Created an attachment (id=7740)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=7740&action=view)
requested config.log from failed compile

taken from "/usr/src/gcc-3.4.3-objdir/powerpc-unknown-linux-gnu/libstdc++-v3"


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18889

[Bug libgcj/18996] java.util.zip giving corrupt data or throwing ZipException on correct archives

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2004-12-14 
19:14 ---
It works on ppc-darwin.

-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18996

[Bug libgcj/18996] java.util.zip giving corrupt data or throwing ZipException on correct archives

[ovidr at users dot sourceforge dot net]

--- Additional Comments From ovidr at users dot sourceforge dot net  
2004-12-14 19:27 ---
Works on win32 for me.
gcc version 4.0.0 20041213 (experimental)

-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18996

[Bug libgcj/18996] java.util.zip giving corrupt data or throwing ZipException on correct archives

[tromey at gcc dot gnu dot org]

--- Additional Comments From tromey at gcc dot gnu dot org  2004-12-14 
19:26 ---
This also works on x86-linux.

One way I think it could fail on Windows is if the 
zip contains extended time stamps and we try to load
some locale data and can't find it.  This might cause
the failure, though I'm not sure.  Can you get a more
complete stack trace somehow?



-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18996

[Bug c++/18279] [4.0 regression] missing function bodies from -fdump-translation-unit

[mmitchel at gcc dot gnu dot org]

--- Additional Comments From mmitchel at gcc dot gnu dot org  2004-12-14 
19:42 ---
This is a low-priority issue.

-- 
   What|Removed |Added

   Priority|P2  |P3


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18279

[Bug libgcj/18996] java.util.zip giving corrupt data or throwing ZipException on correct archives

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2004-12-14 
19:35 ---
So this is already fixed, so closing.

-- 
   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||FIXED
   Target Milestone|--- |4.0.0


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18996

[Bug fortran/18998] Gfortran produces wrong output (c/f to g77)

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2004-12-14 
19:40 ---
This works for me on ppc-darwin with gcc 4.0.0 (20041214).

-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18998

[Bug java/17231] verification error 3.4.1/3.5 : compile .class with embedded try blocks

[tromey at gcc dot gnu dot org]

--- Additional Comments From tromey at gcc dot gnu dot org  2004-12-14 
20:17 ---
FYI, this will only work with the new verifier,
which is only available via -findirect-dispatch.
The new verifier doesn't yet work with the old ABI, AFAIK.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17231

[Bug middle-end/18965] [4.0 regression] ICE in gimplify_init_ctor_eval

[cvs-commit at gcc dot gnu dot org]

--- Additional Comments From cvs-commit at gcc dot gnu dot org  2004-12-14 
20:13 ---
Subject: Bug 18965

CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED]   2004-12-14 20:13:16

Modified files:
gcc/cp : init.c ChangeLog 
gcc/testsuite  : ChangeLog 
Added files:
gcc/testsuite/g++.dg/init: array17.C 

Log message:
2004-12-14  Andrew Pinski  <[EMAIL PROTECTED]>

PR c++/18965
* init.c (build_zero_init): If the max_index is 0, there is no
need to create a RANGE_EXPR.

2004-12-14  Andrew Pinski  <[EMAIL PROTECTED]>

PR c++/18965
* g++.dg/init/array17.C: New test.

Patches:
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/init.c.diff?cvsroot=gcc&r1=1.404&r2=1.405
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/ChangeLog.diff?cvsroot=gcc&r1=1.4534&r2=1.4535
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gcc&r1=1.4755&r2=1.4756
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/g++.dg/init/array17.C.diff?cvsroot=gcc&r1=NONE&r2=1.1



-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18965

[Bug middle-end/18999] New: gimplify_init_ctor_eval does not support RANGE_EXPRs

[pinskia at gcc dot gnu dot org]

Even though the C++ front-end no longer produces RANGE_EXPR which would cause 
an ICE.  I think we 
should support RANGE_EXPR in gimplify_init_ctor_eval.

-- 
   Summary: gimplify_init_ctor_eval does not support RANGE_EXPRs
   Product: gcc
   Version: 4.0.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: minor
  Priority: P2
 Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: pinskia at gcc dot gnu dot org
CC: gcc-bugs at gcc dot gnu dot org


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18999

[Bug middle-end/18951] Invalid code generated by expand_errno_check

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2004-12-14 
20:31 ---
Fixed.

-- 
   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED
   Target Milestone|--- |3.4.4


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18951

[Bug tree-optimization/18888] [4.0 regression] loops miscompiled

[law at redhat dot com]

--- Additional Comments From law at redhat dot com  2004-12-14 20:07 ---
Should be fixed with today's checkin to tree-outof-ssa.c.

-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=1

[Bug tree-optimization/18888] [4.0 regression] loops miscompiled

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2004-12-14 
20:29 ---
Fixed.

-- 
   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=1