[Bug libstdc++/22388] When cross-compiling libstdc++ for mingw, enable large file support (LFS)

--- Additional Comments From ra at atterer dot net 2005-07-10 08:39 --- (In reply to comment #1) > mingw runtime does not have struct stat64 or fstat64(), so this define is not > correct. Hmm - but I've successfully cross-compiled libstdc++ on Linux with this #define, and I'm 100% sure

[Bug libstdc++/22388] When cross-compiling libstdc++ for mingw, enable large file support (LFS)

--- Additional Comments From pcarlini at suse dot de 2005-07-10 08:55 --- Note that the mentioned code in basic_file_stdio.cc does *not* exist in FSF GCC3.4.x, i.e., it's a local mingw modification. Probably, *there* the #define would make sense or, alternately, someone has to work on po

[Bug c/22391] xgcc: Internal error: Segmentation fault (program as)

--- Additional Comments From falk at debian dot org 2005-07-10 09:00 --- "as" is part of binutils, so please report it there. They will probably also want the actual assembly file, which you can obtain by adding -save-temps. -- What|Removed |Added --

[Bug c++/22392] New: Huge memory usage and infinite(?) loop with -fno-enforce-eh-specs

[ forwarded from http://bugs.debian.org/317563 ] The test case chews up 789m of memory and then doesn't seem to progress for at least 10 minutes with -O2 -fno-enforce-eh-specs. Functions showing up prominently in a profile are: samples %symbol name 3418822.3480 bitmap_set_bit 18170

[Bug c++/22392] Huge memory usage and infinite(?) loop with -fno-enforce-eh-specs

--- Additional Comments From debian-gcc at lists dot debian dot org 2005-07-10 12:01 --- Created an attachment (id=9237) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=9237&action=view) Test case -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22392

[Bug other/22393] New: ICE in emit_move_insn, at expr.c:3142

$ gcc s_ctan.i -c -std=gnu99 -O1 ../sysdeps/generic/s_ctan.c: In function '__ctan': ../sysdeps/generic/s_ctan.c:69: internal compiler error: in emit_move_insn, at expr.c:3142 without -std=gnu99 it works. (gcc-4.1.0-0.20050707T1814UTC). -- Summary: ICE in emit_move_insn, at exp

[Bug other/22393] ICE in emit_move_insn, at expr.c:3142

--- Additional Comments From pluto at agmk dot net 2005-07-10 12:22 --- Created an attachment (id=9238) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=9238&action=view) testcase -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22393

[Bug fortran/22327] [4.0 only] Wrong code in array constructor

--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-07-10 13:26 --- Subject: Bug 22327 CVSROOT:/cvs/gcc Module name:gcc Branch: gcc-4_0-branch Changes by: [EMAIL PROTECTED] 2005-07-10 13:26:08 Modified files: gcc/fortran: Change

[Bug c++/22394] New: floating point comparison fails with -O2

This problem exists in version 3.4.1; it doesn't in version 3.3.2 or 4.0.1, on Intel 586 architecture (both AMD Athlon and P4 cpus). I'm posting this note for reference, in case the change in the code generation inadvertently (as opposed to intentionally) fixed the problem. This program has diffe

[Bug c++/22394] floating point comparison fails with -O2

--- Additional Comments From glenn at aoi-industries dot com 2005-07-10 15:15 --- Created an attachment (id=9239) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=9239&action=view) save-temps file that demonstrates problem -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22394

[Bug fortran/20363] interface body has incorrect scope

--- Additional Comments From tobi at gcc dot gnu dot org 2005-07-10 15:37 --- Erik has posted a patch for this bug here: http://gcc.gnu.org/ml/fortran/2005-07/msg00081.html i'm looking into it, but I haven't yet understood how this changes something, and I'm currently rebuilding the com

Re: problem with large arrays

Quoting Peter Teuben <[EMAIL PROTECTED]>: > On Thu, 7 Jul 2005 [EMAIL PROTECTED] wrote: > > > > > Well, I need to work with large arrays that must be share by several > classes. I > > new into C/Objective-C. I'm a Fortran programmer. THere, I used to work > with > > dynamic allocation of memory.

[Bug fortran/20363] interface body has incorrect scope

--- Additional Comments From paulthomas2 at wanadoo dot fr 2005-07-10 16:57 --- Subject: Re: interface body has incorrect scope tobi at gcc dot gnu dot org wrote: >--- Additional Comments From tobi at gcc dot gnu dot org 2005-07-10 15:37 >--- >Erik has posted a patch for thi

[Bug fortran/18022] problem with structure and calling a function

--- Additional Comments From tobi at gcc dot gnu dot org 2005-07-10 16:58 --- I had an IRC conversation with Paul Brook about this. Here's what we concluded: There are two solutions. (a) Align all components of derived types to component size boundaries. (b) Express pointer strides in

[Bug fortran/18022] problem with structure and calling a function

--- Additional Comments From paulthomas2 at wanadoo dot fr 2005-07-10 17:22 --- Subject: Re: problem with structure and calling a function tobi at gcc dot gnu dot org wrote: >IOW, fixing the underlying bug is out-of-reach. The original bug can be fixed >by forcing the function result

[Bug fortran/18022] problem with structure and calling a function

--- Additional Comments From paulthomas2 at wanadoo dot fr 2005-07-10 17:25 --- Subject: Re: problem with structure and calling a function I notice that I did not change the comment - I though that it was a waste of time to clean it up! Paul T -- http://gcc.gnu.org/bugzilla/sh

[Bug fortran/18022] problem with structure and calling a function

--- Additional Comments From Tobias dot Schlueter at physik dot uni-muenchen dot de 2005-07-10 17:37 --- Subject: Re: problem with structure and calling a function paulthomas2 at wanadoo dot fr wrote: > --- 2213,2226 > tree tmp; > stmtblock_t block; > stmtblock_t body;

[Bug fortran/18022] problem with structure and calling a function

--- Additional Comments From paulthomas2 at wanadoo dot fr 2005-07-10 17:52 --- Subject: Re: problem with structure and calling a function > > >I should probably have said why I don't like this: this will probably not work >with derived types which have a component of the same type as

[Bug c++/22394] floating point comparison fails with -O2

--- Additional Comments From pinskia at gcc dot gnu dot org 2005-07-10 18:09 --- *** This bug has been marked as a duplicate of 323 *** -- What|Removed |Added

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

--- Additional Comments From pinskia at gcc dot gnu dot org 2005-07-10 18:09 --- *** Bug 22394 has been marked as a duplicate of this bug. *** -- What|Removed |Added

[Bug rtl-optimization/22392] Huge memory usage and infinite(?) loop with -fno-enforce-eh-specs

--- Additional Comments From pinskia at gcc dot gnu dot org 2005-07-10 18:12 --- This is the scheduler messing up which is normal with big BBs. -- What|Removed |Added

[Bug fortran/22327] [4.0 only] Wrong code in array constructor

--- Additional Comments From pinskia at gcc dot gnu dot org 2005-07-10 18:22 --- Fixed in 4.0.2. -- What|Removed |Added Status|ASSIGNED|RESOL

[Bug other/22393] ICE in emit_move_insn, at expr.c:3142

--- Additional Comments From pinskia at gcc dot gnu dot org 2005-07-10 18:26 --- I think this was fixed by: 2005-07-08 Andrew Pinski <[EMAIL PROTECTED]> PR tree-opt/22356 * tree-complex.c (expand_complex_libcall): Produce REALPART_EXPR/IMAGPART_EXPR with the co

[Bug tree-optimization/22216] [4.1 regression] ICE during GC

--- Additional Comments From pinskia at gcc dot gnu dot org 2005-07-10 18:34 --- So closing as fixed. -- What|Removed |Added Status|UNCONFIRMED |

[Bug c++/22395] New: -Weffc++ shouldn't warn about non-virtual dtor of private subclasses

When using -Weffc++, private inheritance signals a warning about base class dtor non-virtualness: class Foo { public: ~Foo() {} }; class Bar : public Foo {}; warning: base class 'class Foo' has a non-virtual destructor. This, of course, is a useless warning since Bar can never be deleted

[Bug c++/22395] -Weffc++ shouldn't warn about non-virtual dtor of private subclasses

--- Additional Comments From mutz at kde dot org 2005-07-10 18:54 --- > class Bar : public Foo {}; Of course, that should read: class Bar : private Foo {}; -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22395

[Bug c++/22395] -Weffc++ shouldn't warn about non-virtual dtor of private subclasses

--- Additional Comments From pinskia at gcc dot gnu dot org 2005-07-10 19:05 --- I think this is a dup of bug 16168 or at least a related issue. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22395

[Bug tree-optimization/22336] [4.1 Regression] ICE Segfault in record_block_change at function.c:5498

--- Additional Comments From laurent at guerby dot net 2005-07-10 19:07 --- The following patch suggested by Richard Kenner messages "fixes" the bootstrap problem. Index: function.c === RCS file: /cvs/gcc/gcc/gcc/function.c

[Bug tree-optimization/22336] [4.1 Regression] ICE Segfault in record_block_change at function.c:5498

--- Additional Comments From kenner at vlsi1 dot ultra dot nyu dot edu 2005-07-10 19:09 --- Subject: Re: [4.1 Regression] ICE Segfault in record_block_change at function.c:5498 The following patch suggested by Richard Kenner messages "fixes" the bootstrap problem. To be pr

[Bug c++/22395] -Weffc++ shouldn't warn about non-virtual dtor of private subclasses

--- Additional Comments From mutz at kde dot org 2005-07-10 19:16 --- Related it may be, but different it is. bug 16168 is about subclasses that don't have virtual methods, but even in the case of the private inheritance from a base class having virtual methods, the warning should not b

[Bug ada/22387] [4.0/4.1 Regression] GCC Ada compiler crash.

--- Additional Comments From pinskia at gcc dot gnu dot org 2005-07-10 19:34 --- Confirmed. 3.3 gave the following error: descriptor.ads:43:08: expected type "Type_T" defined at line 2 descriptor.ads:43:08: found type "Standard.Boolean" -- What|Removed

[Bug rtl-optimization/20945] [4.0/4.1 Regresson] about 2x perfomance regression in comparision with 3.4.2

-- What|Removed |Added BugsThisDependsOn||18427 Summary|about 2x perfomance |[4.0/4.1 Regresson] about 2x |regressi

[Bug c++/15006] error: too few template-parameter-lists

--- Additional Comments From beorn_johnson at yahoo dot com 2005-07-10 19:55 --- Addendum for those who continue to have difficulty: I found that the order of the "template ..." vs. "template<> ..." made a difference, but in linking, not in compiling. From the previous example: tem

[Bug bootstrap/22396] New: bootstrap of f95 enabled gcc fails because gfortran.1 is missing

Bootstrapping gcc with --enable-languages=f95,... fails with: gmake[2]: *** No rule to make target `doc/gfortran.1', needed by `f95.man'. Stop. gmake[2]: Leaving directory `/software/gcc-obj/gcc' gmake[1]: *** [stage1_build] Error 2 gmake[1]: Leaving directory `/software/gcc-obj/gcc' gmake: ***

[Bug bootstrap/22396] bootstrap of f95 enabled gcc fails because gfortran.1 is missing

--- Additional Comments From pinskia at gcc dot gnu dot org 2005-07-10 20:05 --- This is related to PR 21350. -- What|Removed |Added BugsThisDependsOn|

[Bug ada/22387] [4.0/4.1 Regression] GCC Ada compiler crash.

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

[Bug c/22391] xgcc: Internal error: Segmentation fault (program as)

--- Additional Comments From diskman at kc dot rr dot com 2005-07-10 20:41 --- Well actually I found out what the issue was... It wasn't necessarily Binutils but the fact that it was compiled using Compaq C. When I went with a standard GCC roll of Binutils, everything in the GCC-4.0.1 bu

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

--- Additional Comments From mckelvey at maskull dot com 2005-07-10 21:09 --- Fails a little differently now, with latest CVS: Fixed: Xm/BaseClassI.h Fixed: Xm/Traversal.h math.h /home/mckelvey/software/gcc/fixincludes/tests/base/math.h differ: char 501, line 22 *** math.h Sun Ju

[Bug libfortran/21593] FAIL: gfortran.dg/dev_null.f90

--- Additional Comments From tkoenig at gcc dot gnu dot org 2005-07-10 22:18 --- The comments in fd_truncate (line 505 ff. in unix.c) read if (lseek (s->fd, s->logical_offset, SEEK_SET) == -1) return FAILURE; /* non-seekable files, like terminals and fifo's fail the lseek.

[Bug ada/22387] [4.0/4.1 Regression] GCC Ada compiler crash.

--- Additional Comments From ramsgar-gccbug at yahoo dot com 2005-07-10 22:23 --- The problem also happens with GCC 3.4.1 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22387

[Bug ada/22387] [4.0/4.1 Regression] GCC Ada compiler crash.

--- Additional Comments From ramsgar-gccbug at yahoo dot com 2005-07-10 22:59 --- Regression? The behaviour with GCC 3.3 is bogus as well. There should be no error message. In addition, both the error message with GCC 3.3 and the crash with GCC 3.4/4.0 go away by commenting the represen

[Bug fortran/21875] [meta-bug] NIST test suite failures

--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-07-10 23:22 --- Subject: Bug 21875 CVSROOT:/cvs/gcc Module name:gcc Branch: gcc-4_0-branch Changes by: [EMAIL PROTECTED] 2005-07-10 23:22:23 Modified files: libgfortran: Change

[Bug middle-end/22379] [4.1 Regression] ICE in cgraph_early_inlining, at ipa-inline.c:990

--- Additional Comments From pinskia at gcc dot gnu dot org 2005-07-11 01:12 --- Patch posted here: . -- What|Removed |Added -

[Bug c/22397] New: Extension to initialize enum using pointers to const strings.

I should be able to cast a const string pointer to an int so that one could do: enum {hash = (int)"the first enum"}. It's cleaner than #defines and easier to debug. The reason that it's useful is so that one can use the enum values anywhere, and be guaranteed to get the same value, unlike usin

[Bug c/22397] Extension to initialize enum using pointers to const strings.

--- Additional Comments From pinskia at gcc dot gnu dot org 2005-07-11 01:48 --- This is not going to be added. Use a "static const char*" will work also. And debugging with defines is easy add -g3 and you will get debuging info for defines. -- What|Removed

[Bug middle-end/22398] New: ICE in compare_values, at tree-vrp.c:445

Compiling arch/sparc/kernel/process.c from linux-2.6.11.3 with gcc-4.1-20050709 fails with arch/sparc/kernel/process.c: In function '__show_backtrace': arch/sparc/kernel/process.c:204: internal compiler error: in compare_values, at tree-vrp.c:445 Here's the command I use to reproduce: sparc-unkn

[Bug middle-end/22398] [4.1 Regression] ICE in compare_values, at tree-vrp.c:445

--- Additional Comments From pinskia at gcc dot gnu dot org 2005-07-11 02:00 --- Confirmed, reduced testcase: void __show_backtrace(void *rw) { while(rw && (((unsigned long) rw) >= 0xf000) ) {} } looks like a fold bug with respect of type issues. This is target independent. --

[Bug middle-end/22398] [4.1 Regression] ICE in compare_values, at tree-vrp.c:445

--- Additional Comments From pinskia at gcc dot gnu dot org 2005-07-11 02:12 --- And here is a testcase which fails on LP64 targets: void __show_backtrace(void *rw) { while(rw && (((unsigned long) rw) >= 0xf000) ) {} } -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22

[Bug fortran/19365] Internal compiler error in gfortran

--- Additional Comments From pinskia at gcc dot gnu dot org 2005-07-11 02:19 --- Fixed in 4.0.2 and above by: 2005-07-07 Jakub Jelinek <[EMAIL PROTECTED]> * scanner.c (preprocessor_line): Only set current_file->line when errors have not been encountered. Warn and don'

[Bug middle-end/20939] [4.1 Regression] ld segmentation fault linking libgfortran.sl.0.0

--- Additional Comments From pinskia at gcc dot gnu dot org 2005-07-11 02:22 --- Does this happen any more? -- What|Removed |Added Target Milestone|---

[Bug middle-end/20939] [4.1 Regression] ld segmentation fault linking libgfortran.sl.0.0

--- Additional Comments From dave at hiauly1 dot hia dot nrc dot ca 2005-07-11 02:27 --- Subject: Re: [4.1 Regression] ld segmentation fault linking libgfortran.sl.0.0 > Does this happen any more? Probably. As noted in comment #3, this is likely a GNU linker bug for this target. Hav

[Bug rtl-optimization/22239] [4.0/4.1 Regression] i-cobol.adb:482: error: unrecognizable insn

--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-07-11 03:56 --- Subject: Bug 22239 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2005-07-11 03:56:14 Modified files: gcc: ChangeLog loop.c Log message:

[Bug target/20126] [3.4 Regression] Inlined memcmp makes one argument null on entry

--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-07-11 03:56 --- Subject: Bug 20126 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2005-07-11 03:56:14 Modified files: gcc: ChangeLog loop.c Log message:

[Bug middle-end/21137] Convert (a >> 2) & 1 != 0 into a & 4 != 0

--- Additional Comments From phython at gcc dot gnu dot org 2005-07-11 03:56 --- This should actually be "Convert (a >> c1) & 2**c2" to a & (c2 << c1)". -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21137

[Bug fortran/22399] New: Segfault while compiling R fortran code

Got several ICEs while trying to compile the fortran parts of R with gfortran. gcc version 4.1.0 20050702 (experimental) t.f: In function ‘dsbmv’: t.f:1: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bu

[Bug fortran/22399] Segfault while compiling R fortran code

--- Additional Comments From ak at muc dot de 2005-07-11 04:16 --- Created an attachment (id=9240) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=9240&action=view) Test case extracted from R blas.f -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22399

[Bug fortran/22400] New: ICE while compiling lapack from R

gcc version 4.1.0 20050702 (experimental) Segfaults with -O2, compiles with -O0 t2.f: In function ‘dlaein’: t2.f:1: 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. --

[Bug fortran/22400] ICE while compiling lapack from R

--- Additional Comments From ak at muc dot de 2005-07-11 04:22 --- Created an attachment (id=9241) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=9241&action=view) test case -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22400

[Bug fortran/22400] ICE while compiling lapack from R

--- Additional Comments From pinskia at gcc dot gnu dot org 2005-07-11 04:24 --- *** This bug has been marked as a duplicate of 21963 *** -- What|Removed |Added

[Bug fortran/22399] Segfault while compiling R fortran code

--- Additional Comments From pinskia at gcc dot gnu dot org 2005-07-11 04:24 --- *** This bug has been marked as a duplicate of 21963 *** -- What|Removed |Added

[Bug tree-optimization/21963] [4.1 Regression] ICE (seg fault) with -m64 (in IV-OPTS)

--- Additional Comments From pinskia at gcc dot gnu dot org 2005-07-11 04:24 --- *** Bug 22400 has been marked as a duplicate of this bug. *** --- Additional Comments From pinskia at gcc dot gnu dot org 2005-07-11 04:24 --- *** Bug 22399 has been marked as a duplicate of this b

[Bug tree-optimization/21963] [4.1 Regression] ICE (seg fault) with -m64 (in IV-OPTS)

--- Additional Comments From pinskia at gcc dot gnu dot org 2005-07-11 04:24 --- *** Bug 22400 has been marked as a duplicate of this bug. *** -- What|Removed |Added

[Bug tree-optimization/22401] New: DOM messes up the profiling info

Take the following simple example loop: void __show_backtrace(void *rw) { while(rw); } We get invalid warnings in the tree dumps about profiling info being wrong: __show_backtrace (rw) { :; if (rw_1 != 0B) goto ; else goto ; Invalid sum of incoming frequencies 9879, should be 8900 :; goto

[Bug middle-end/22398] [4.1 Regression] ICE in compare_values, at tree-vrp.c:445

--- Additional Comments From pinskia at gcc dot gnu dot org 2005-07-11 05:14 --- I have a fix. -- What|Removed |Added AssignedTo|unassigned at gcc dot gnu |pinskia

[Bug middle-end/22398] [4.1 Regression] ICE in compare_values, at tree-vrp.c:445

--- Additional Comments From dank at kegel dot com 2005-07-11 05:20 --- Deity on a crutch! That was fast. Thanks; I can test if you like, or just wait for the next snapshot. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22398

[Bug middle-end/21076] [4.1 Regression] ACATs ICE cxh1001 at tree-vrp.c:124 (fold bug)

--- Additional Comments From pinskia at gcc dot gnu dot org 2005-07-11 05:45 --- I am taking care of this since I am touching build_range_check already for another type problem. -- What|Removed |Added -

[Bug c++/22352] [3.4/4.0/4.1 Regression] ICE in lookup_member

--- Additional Comments From pinskia at gcc dot gnu dot org 2005-07-11 05:48 --- Confirmed. -- What|Removed |Added Status|UNCONFIRMED |NEW E

[Bug fortran/22390] Implement FLUSH statement

--- Additional Comments From jblomqvi at cc dot hut dot fi 2005-07-11 05:55 --- Proposed patch here: http://gcc.gnu.org/ml/gcc-patches/2005-07/msg00698.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22390

[Bug c/22402] New: Error during the build on AIX 5.2.0 ML5

During the make install -bnoquiet I have the following errors: SHLIB_EXT='.a' \ SHLIB_MULTILIB='' \ SHLIB_MKMAP='../../gcc-4.0.0/gcc/mkmap-flat.awk' \ SHLIB_MKMAP_OPTS='' \ SHLIB_MAPFILES='../../gcc-4.0.0/gcc/libgcc-std.ver ../../gcc- 4.0.0/gcc/config/rs6000/libgcc-ppc64.ver' \ SHLIB_NM_FLAGS='-Bp

[Bug c++/10611] operations on vector mode not recognized in C++

--- Additional Comments From dirtyepic dot sk at gmail dot com 2005-07-11 06:24 --- Has this been backported to the 4.0 branch now that it's open again? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=10611