[Bug c++/19188] friend funtion inside a template class seems to have a problem

--- Additional Comments From max656 at hotmail dot com 2004-12-30 07:41 --- Thanks for the reply. In this one line of code tstack::link* p; "tstack::link " is a typename. so I can not give another name. Actually, I got other ways to get around this problem. But I am interested in thi

[Bug c++/9783] [DR433] Can't forward reference class in argument to templated method.

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

[Bug c++/4403] incorrect class becomes a friend in template

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

[Bug c++/1016] [DR 166] friend class declarations not observing namespace rules.

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

[Bug c++/9783] [DR433] Can't forward reference class in argument to templated method.

--- Additional Comments From lerdsuwa at gcc dot gnu dot org 2004-12-30 07:38 --- Patch for PR4403 also includes a fix to this bug (the while-loop hunk in pushtag). -- What|Removed |Added ---

[Bug c++/19189] A derived template cannot access base template members without using this

--- Additional Comments From amos at ilogix dot com 2004-12-30 07:32 --- (In reply to comment #3): I agree that this is the expected behavior, although such a change, without any backward compatibility, makes it hard to upgrade to a new version of the compiler. In our specific case, we

[Bug rtl-optimization/19198] ICE in copyprop_hardreg_forward_1

--- Additional Comments From pinskia at gcc dot gnu dot org 2004-12-30 05:22 --- What exact version of 3.4.4 is this aka give the output of "gcc34 -v". Also if this is a three week old snapshot, try a newer snapshot as I think this has been fixed already. -- What|Remov

[Bug debug/19124] [4.0 regression] gcc generates incorrect dwarf2 debug info

--- Additional Comments From dberlin at gcc dot gnu dot org 2004-12-30 05:10 --- Subject: Re: [4.0 regression] gcc generates incorrect dwarf2 debug info After talking with gdb folks and dwarf2 folks (who say this isn't the actual bug, there is some other gdb bug causing the crashe

[Bug debug/19197] Cygwin's gdb turns up its nose at DWARF debug info...

--- Additional Comments From pinskia at gcc dot gnu dot org 2004-12-30 05:10 --- Why this is filed here. This is not a gcc bug but a gdb one, report it to them. Also the gdb which you are using is old, newer ones I think support dwarf-2 for windows. -- What|Removed

[Bug tree-optimization/14329] [tree-ssa] badly formatted warnings for SRA replacements

--- Additional Comments From pinskia at gcc dot gnu dot org 2004-12-30 05:08 --- *** Bug 19196 has been marked as a duplicate of this bug. *** -- What|Removed |Added

[Bug tree-optimization/19196] Confusing identifiers in diagnostics

--- Additional Comments From pinskia at gcc dot gnu dot org 2004-12-30 05:08 --- This is a dup of bug 14329. SR.20649 comes from an unnamed DECL is SRA'd. *** This bug has been marked as a duplicate of 14329 *** -- What|Removed |Added --

[Bug target/19187] [4.0 Regression] CVS broken for sparc-sun-solaris2.9

--- Additional Comments From pinskia at gcc dot gnu dot org 2004-12-30 05:06 --- Fixed by: * config/sparc/sparc.c (TARGET_RELAXED_ORDERING): True. -- What|Removed |Added

[Bug c++/19185] [3.3 only] ICE: cp_expr_size, at cp/cp-lang.c:308

--- Additional Comments From danglin at gcc dot gnu dot org 2004-12-30 04:35 --- FWIW, I'm able to duplicate with an x86 cross to vax-ultrix. It looks as if the problem lies here: /* If store_expr stores a DECL whose DECL_RTL(exp) == TARGET, but TARGET is not valid

[Bug c++/19190] [4.0 regression] warning "value computed is not used" emitted too often

--- Additional Comments From mueller at kde dot org 2004-12-30 03:51 --- Many thanks for your quick fix! -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19190

[Bug c/19198] ICE in copyprop_hardreg_forward_1

--- Additional Comments From matt at gsicomp dot on dot ca 2004-12-30 03:44 --- The ICE goes away when compiling without -O2. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19198

[Bug c/19198] ICE in copyprop_hardreg_forward_1

--- Additional Comments From matt at gsicomp dot on dot ca 2004-12-30 03:42 --- Created an attachment (id=7843) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=7843&action=view) Pre-processed output from file causing the ICE gzipped pre-processed output. (Bugzilla didn't like it un

[Bug debug/19124] [4.0 regression] gcc generates incorrect dwarf2 debug info

--- Additional Comments From hjl at lucon dot org 2004-12-30 03:38 --- While fixing the readelf bug: http://sources.redhat.com/bugzilla/show_bug.cgi?id=615 I added a warning for bad location list. Even with your gcc patch applied, I still get [EMAIL PROTECTED] gcc]$ /export/build/linux

[Bug c/19198] New: ICE in copyprop_hardreg_forward_1

[EMAIL PROTECTED] gcc -v Using builtin specs. gcc version 2.95.4 20020320 [FreeBSD] -- [EMAIL PROTECTED] uname -a FreeBSD penelope.gsicomp.on.ca 4.10-RELEASE-p5 FreeBSD 4.10-RELEASE-p5 #0: Wed Dec 8 22:11:29 EST 2004 [EMAIL PROTECTED]:/usr/obj/us

[Bug ada/19128] Bug box while building asharp

--- Additional Comments From gccbugs at sohailsomani dot com 2004-12-30 02:46 --- reply from the gcc-patches list shows that my patch does fix *that* problem. It was just a typo really. Not enough caffine I suppose. -- What|Removed |Added

[Bug ada/19128] Bug box while building asharp

--- Additional Comments From gccbugs at sohailsomani dot com 2004-12-30 02:44 --- (In reply to comment #15) > Is there a simplified testcase for this? Unfortunately no, but a reply from the gcc-patches list shows that my patch does fix *that* problem. It was just a typo really. Not eno

[Bug debug/19197] New: Cygwin's gdb turns up its nose at DWARF debug info...

--enable-dwarf2 seems to work just fine on Cygwin32, except for the fact that GDB turns up its nose at the presence of DWARF debug info in files that aren't ELF (such as WindowsNT PE files). This problem reared its UGLY head when I was trying to debug the built-but-not-installed GCC 4 I keep on ha

[Bug tree-optimization/19196] New: Confusing identifiers in diagnostics

Variables fabricated by tree-ssa passes get used in diagnostics instead of those written by users in their codes. That can lead to really confusing diagnostics. I noticed this wen compiling my own applications that I cannot reduce to manageabe size. The snippet below reproduces the basic problem

[Bug ada/19128] Bug box while building asharp

--- Additional Comments From phython at gcc dot gnu dot org 2004-12-30 01:44 --- Is there a simplified testcase for this? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19128

[Bug middle-end/19171] causes segfault ICE in GCC 4

--- Additional Comments From bsdfan3 at users dot sourceforge dot net 2004-12-30 01:25 --- Fresh co as of 10-28-04 works. It was a patching glitch. =P Thanks! -- What|Removed |Added

[Bug libfortran/19194] Missing RECL parameter in OPEN statement

--- Additional Comments From bdavis at gcc dot gnu dot org 2004-12-30 01:24 --- this is a run time library bug. -- What|Removed |Added Status|UNCONFIRMED

[Bug c++/19190] [4.0 regression] warning "value computed is not used" emitted too often

--- Additional Comments From mmitchel at gcc dot gnu dot org 2004-12-30 00:31 --- Fixed in GCC 4.0. -- What|Removed |Added Status|NEW |RE

[Bug c++/19190] [4.0 regression] warning "value computed is not used" emitted too often

--- Additional Comments From cvs-commit at gcc dot gnu dot org 2004-12-30 00:31 --- Subject: Bug 19190 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2004-12-30 00:31:01 Modified files: gcc/cp : ChangeLog cvt.c gcc/testsuit

[Bug fortran/19195] gfortran: ICE in final_scan_insn, at final.c:1843

--- Additional Comments From pinskia at gcc dot gnu dot org 2004-12-29 22:08 --- Confirmed: [t.f : -2] return; We are using the wrong line number for the return statement. This usually means that cfun->function_end_locus is not set correctly. -- What|Removed

[Bug fortran/19195] gfortran: ICE in final_scan_insn, at final.c:1843

-- What|Removed |Added Version|unknown |4.0.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19195

[Bug fortran/19195] New: gfortran: ICE in final_scan_insn, at final.c:1843

Hi, there must be some funny screw-up in the parser that shows up under very special circumstances. Compile the example below with debugging. There must *not* be any lines before the "subroutine" in that file, otherwise the ICE does not show up. % gfortran -c -g gfc-dbg-bug.f90 gfc-dbg-bug.f90:

[Bug fortran/19194] New: Missing RECL parameter in OPEN statement

Executing on host: /test/gnu/gcc-3.3/objdir/gcc/testsuite/../gfortran -B/test/gn u/gcc-3.3/objdir/gcc/testsuite/../ /test/gnu/gcc-3.3/gcc/gcc/testsuite/gfortran. dg/direct_io_2.f90 -O0 -pedantic-errors -L/test/gnu/gcc-3.3/objdir/hppa64-h p-hpux11.11/./libgfortran/.libs -L/test/gnu/gcc-3.3/objd

[Bug middle-end/19193] Segmentation fault in gcc while compiling the 2.6.9 kernel

--- Additional Comments From pinskia at gcc dot gnu dot org 2004-12-29 21:31 --- Make sure that you read http://gcc.gnu.org/bugs.html and provide all the information. Also can you try a new compiler like say 3.4.x or 3.3.x as 3.2.3 is old and that series is not being updated. --

[Bug c/19193] New: Segmentation fault in gcc while compiling the 2.6.9 kernel

This is a Slackware 9.1 system running kernel 2.4.26 glibc 2.3.2 Crash occurs after issuing "make" to compile 2.6.9 kernel. GCC crashed with a segmentation fault at fs/namei.c:1520 I think this was just a one-time anomaly. I retyped "make', and it happily resumed. Please let me know what ot

[Bug tree-optimization/19038] [4.0 Regression] out-of ssa causing loops to have more than one BB

--- Additional Comments From law at redhat dot com 2004-12-29 21:06 --- Subject: Re: [4.0 Regression] out-of ssa causing loops to have more than one BB On Wed, 2004-12-29 at 20:50 +, pinskia at gcc dot gnu dot org wrote: > --- Additional Comments From pinskia at gcc dot

[Bug debug/19191] [4.0 Regression] No DWARF2 DW_TAG_inlined_subroutine entry generated

--- Additional Comments From pinskia at gcc dot gnu dot org 2004-12-29 20:54 --- Patch here: . -- What|Removed |Added

[Bug debug/17924] [4.0 Regression] gcc.dg/debug/dwarf2/dwarf-die7.c fails

--- Additional Comments From pinskia at gcc dot gnu dot org 2004-12-29 20:54 --- Patch posted here: . -- What|Removed |Added -

[Bug tree-optimization/19038] [4.0 Regression] out-of ssa causing loops to have more than one BB

--- Additional Comments From pinskia at gcc dot gnu dot org 2004-12-29 20:52 --- (In reply to comment #29) > The reference patch does not fix the problem all the time, see PR 14741 for a > testcase where the patch > fails, and it fails still for sixtrack but I should note that this wo

[Bug tree-optimization/19038] [4.0 Regression] out-of ssa causing loops to have more than one BB

--- Additional Comments From pinskia at gcc dot gnu dot org 2004-12-29 20:50 --- The reference patch does not fix the problem all the time, see PR 14741 for a testcase where the patch fails, and it fails still for sixtrack but I should note that this would be now caused by IV-OPTs. -

[Bug c++/19190] [4.0 regression] warning "value computed is not used" emitted too often

--- Additional Comments From mark at codesourcery dot com 2004-12-29 20:40 --- Subject: Re: [4.0 regression] warning "value computed is not used" emitted too often pinskia at gcc dot gnu dot org wrote: > --- Additional Comments From pinskia at gcc dot gnu dot org 2004-12-29 > 18

[Bug debug/19191] [4.0 Regression] No DWARF2 DW_TAG_inlined_subroutine entry generated

--- Additional Comments From dberlin at gcc dot gnu dot org 2004-12-29 20:17 --- The lexical block that contains the arguments (and the subblocks for the other inlined parameters) is marked as asm_written but not *used* in 4.0, so we ignore it. block 0x4009b784 asm_written vars http

[Bug target/18321] [3.3/3.4/4.0 regression] mmix-knuth-mmixware testsuite failure: gcc.c-torture/compile/20031023-4.c -O0, -O1

--- Additional Comments From hp at gcc dot gnu dot org 2004-12-29 20:11 --- > If HP believs that he has no interest in having the bug fixed on the > branches for mmix-knuth-xx users, let's close the PR. I have interest, but only a little, not even as much as doing the minimal work myse

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

--- Additional Comments From berndtrog at yahoo dot com 2004-12-29 19:38 --- > Minimal changes required to get avr to build: OK, building a avr-gcc works with this patch. Thanks! But I can no longer bootstrap the compiler with this patch (comment #11) applied: /tmp/HEAD/gcc/gcc/confi

[Bug tree-optimization/19038] [4.0 Regression] out-of ssa causing loops to have more than one BB

--- Additional Comments From steven at gcc dot gnu dot org 2004-12-29 19:33 --- http://gcc.gnu.org/ml/gcc-patches/2004-12/msg02063.html -- What|Removed |Added Key

[Bug c++/19163] __attribute__((aligned)) not working in template

--- Additional Comments From pcarlini at suse dot de 2004-12-29 19:05 --- > Did I already open a PR for this misbehaviour in the past? What > happened? Yes, Gaby, the issue at large is clear, by now: see c++/17743. Here, we are just trying to achieve *minimal* functionality, when the e

[Bug target/18321] [3.3/3.4/4.0 regression] mmix-knuth-mmixware testsuite failure: gcc.c-torture/compile/20031023-4.c -O0, -O1

--- Additional Comments From gdr at integrable-solutions dot net 2004-12-29 19:01 --- Subject: Re: [3.3/3.4/4.0 regression] mmix-knuth-mmixware testsuite failure: gcc.c-torture/compile/20031023-4.c -O0, -O1 "giovannibajo at libero dot it" <[EMAIL PROTECTED]> writes: | Hans: our polic

[Bug c++/19163] __attribute__((aligned)) not working in template

--- Additional Comments From gdr at integrable-solutions dot net 2004-12-29 18:57 --- Subject: Re: New: __attribute__((aligned)) not working in template "pcarlini at suse dot de" <[EMAIL PROTECTED]> writes: | Unfortunately, it looks like even the very limited functionality of aligned

[Bug c++/18384] [3.3/3.4/4.0 Regression] ICE on zero-length array with empty initializer...

--- Additional Comments From gdr at integrable-solutions dot net 2004-12-29 18:54 --- Subject: Re: [3.3/3.4/4.0 Regression] ICE on zero-length array with empty initializer... "mark at codesourcery dot com" <[EMAIL PROTECTED]> writes: | > As for designated_index, this differs between

[Bug c++/19190] [4.0 regression] warning "value computed is not used" emitted too often

--- Additional Comments From pinskia at gcc dot gnu dot org 2004-12-29 18:00 --- Confirmed, I wonder if this is because there are casts added by the front-end: (void) (unsigned int) -- What|Removed |Added -

[Bug target/19046] [4.0 Regression] MOVE_RATIO should be tweaked on ppc

--- Additional Comments From dje at gcc dot gnu dot org 2004-12-29 18:00 --- Increasing the value of MOVE_RATIO and CLEAR_RATIO decreases SPEC performance. The uses of the macro may be overloaded and confusing the cost model. Or it could be harmed by register allocator and spilling.

[Bug debug/19191] [4.0 Regression] No DWARF2 DW_TAG_inlined_subroutine entry generated

-- What|Removed |Added Keywords||wrong-debug Summary|No DWARF2 |[4.0 Regression] No DWARF2 |DW_T

[Bug debug/19192] [4.0 Regression] Current development gcc generates incorrect line info for example code

--- Additional Comments From pinskia at gcc dot gnu dot org 2004-12-29 17:56 --- This is caused by ter. Confirmed, easier way to find this out is to look at the tree dump with -lineno as an option. -- What|Removed |Added

[Bug debug/19192] New: Current development gcc generates incorrect line info for example code

For the supplied example, the current development gcc generates incorrect line number information for one instruction from the inlined subroutine. The Fedora Core 3 gcc, which identifies itself as "gcc version 3.4.2 20041017 (Red Hat 3.4.2-6.fc3)", generates correct line information. Environmen

[Bug target/18916] [4.0 Regression] mis-aligned vector code with copy memory (-maltivec)

--- Additional Comments From fjahanian at apple dot com 2004-12-29 17:34 --- (In reply to comment #8) > Why can't we make sure that temporaries which should be aligned to 128 bits > are actually aligned to > 128 bits? Surely failing to do so will cause other problems. Yes, this is t

[Bug target/18321] [3.3/3.4/4.0 regression] mmix-knuth-mmixware testsuite failure: gcc.c-torture/compile/20031023-4.c -O0, -O1

--- Additional Comments From giovannibajo at libero dot it 2004-12-29 17:10 --- Hans: our policy prescribes that a regression in Bugzilla be kept open until it is fixed on all the active release branches, *or* the maintainter of the code affected by the bug explicitally decides that th

[Bug c++/19189] A derived template cannot access base template members without using this

--- Additional Comments From giovannibajo at libero dot it 2004-12-29 17:04 --- BTW, I just added the standard reference to the release notes as well. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19189

[Bug c++/19189] A derived template cannot access base template members without using this

--- Additional Comments From giovannibajo at libero dot it 2004-12-29 16:59 --- Specifically, [temp.dep]/3. Besides, even if the release notes do not point you to a specific place in the standard, the fact that we even documented that it's a *wanted* change in behaviour, it means it ha

[Bug debug/19191] New: No DWARF2 DW_TAG_inlined_subroutine entry generated

The current gcc 4 development compiler does not generate DWARF2 DW_TAG_inlined_subroutine entries for concrete instances of inlined subroutines. The correct entries are generated by the compiler included in Fedora Core 3, which identifies itself as "gcc version 3.4.2 20041017 (Red Hat 3.4.2-6.fc

[Bug c++/19190] New: [4.0 regression] warning "value computed is not used" emitted too often

after the fix for #11224 it now emits the warning almost everywhere.. e.g. === cut === struct breakme { void setAction( unsigned char a ) { act = a; } unsigned int act:8; }; === cut === $ g++ -Wall -c test.cc test.cc: In member function ‘void breakme::setAction(unsigned char)’

[Bug c++/19189] A derived template cannot access base template members without using this

--- Additional Comments From pinskia at physics dot uc dot edu 2004-12-29 14:58 --- Subject: Re: A derived template cannot access base templat e members without using this On Dec 29, 2004, at 9:54 AM, Amos Ortal wrote: > Hi Andrew, > > Thank you for your fast reply, I saw the entry

[Bug c++/19189] A derived template cannot access base template members without using this

--- Additional Comments From pinskia at gcc dot gnu dot org 2004-12-29 14:33 --- Does anyone read the release notes? Yes this is required by the C++ standard. -- What|Removed |Added

[Bug ada/19128] Bug box while building asharp

-- What|Removed |Added Status|WAITING |NEW Last reconfirmed|2004-12-29 05:19:29 |2004-12-29 14:32:17 date|

[Bug c++/19189] New: A derived template cannot access base template members without using this

If you try to access a member of a base template from a derived template (event if the member is public) you are getting a compilation error. This is a regression related to previous versions of the compiler (worked in 3.3.3) and I think its not ANSI C++ as well. For example, compiling the followi

[Bug c++/19184] Octave compilation is failing during running "make"

-- What|Removed |Added Status|UNCONFIRMED |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19184

[Bug target/19187] [4.0 Regression] CVS broken for sparc-sun-solaris2.9

--- Additional Comments From pinskia at gcc dot gnu dot org 2004-12-29 14:29 --- Confirmed, caused by: 2004-12-27 Jason Merrill <[EMAIL PROTECTED]> * doc/tm.texi (TARGET_RELAXED_ORDERING): Document. * target.h (struct gcc_target): Add relaxed_ordering field. *

[Bug bootstrap/19186] internal compiler error: virtual array prologue[3]: element 1 out of bounds in contains, at function.c:4660

--- Additional Comments From pinskia at gcc dot gnu dot org 2004-12-29 14:28 --- This is a dup of bug 19103 which is already fixed by: 2004-12-28 Zdenek Dvorak <[EMAIL PROTECTED]> PR rtl-optimization/19103 * loop-iv.c (iv_number_of_iterations): Fix typo. *** This bug

[Bug rtl-optimization/19103] [4.0 Regression] Current CVS (2004/12/21) doesn't compile with profiledbootstrap

--- Additional Comments From pinskia at gcc dot gnu dot org 2004-12-29 14:28 --- *** Bug 19186 has been marked as a duplicate of this bug. *** -- What|Removed |Added

[Bug c++/19188] friend funtion inside a template class seems to have a problem

--- Additional Comments From lerdsuwa at gcc dot gnu dot org 2004-12-29 14:20 --- Not a bug. You have to replace the code at line 68: tstack::link* p; with typename tstack::link* p; Check out the web page and search for "You mustnow use

[Bug c++/19188] New: friend funtion inside a template class seems to have a problem

A template class(tstack class) has a singly-linked list "struct" declaration in private section. Another template class(tstackIterator) - iterator class is declared and defined in global space. If the iterator template class trys to get access to the linked list structure inside the previous class

[Bug tree-optimization/18179] vectorizer: wrong alignment/step/initial-address computed for struct accesses

--- Additional Comments From cvs-commit at gcc dot gnu dot org 2004-12-29 13:39 --- Subject: Bug 18179 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2004-12-29 13:38:34 Modified files: gcc: ChangeLog tree-vectorizer.c Log mes

[Bug tree-optimization/18179] vectorizer: wrong alignment/step/initial-address computed for struct accesses

--- Additional Comments From cvs-commit at gcc dot gnu dot org 2004-12-29 13:20 --- Subject: Bug 18179 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2004-12-29 13:20:38 Modified files: gcc: ChangeLog tree-vectorizer.c Log mes

[Bug tree-optimization/18179] vectorizer: wrong alignment/step/initial-address computed for struct accesses

--- Additional Comments From cvs-commit at gcc dot gnu dot org 2004-12-29 13:16 --- Subject: Bug 18179 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2004-12-29 13:16:09 Modified files: gcc: ChangeLog tree-vectorizer.h tree-vect

[Bug tree-optimization/18179] vectorizer: wrong alignment/step/initial-address computed for struct accesses

--- Additional Comments From cvs-commit at gcc dot gnu dot org 2004-12-29 13:12 --- Subject: Bug 18179 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2004-12-29 13:11:59 Modified files: gcc: ChangeLog tree-vectorizer.c Log mes

[Bug c++/12850] memory consumption for heavy template instantiations tripled since 3.3

--- Additional Comments From steven at gcc dot gnu dot org 2004-12-29 13:09 --- Trivial 6MB win: Index: parser.c === RCS file: /cvs/gcc/gcc/gcc/cp/parser.c,v retrieving revision 1.298 diff -u -r1.298 parser.c --- par

[Bug c++/12850] memory consumption for heavy template instantiations tripled since 3.3

--- Additional Comments From steven at gcc dot gnu dot org 2004-12-29 12:57 --- I've been looking at a bunch of C++ codes, 16 or 32 seems like a reasonable value for CP_LEXER_BUFFER_SIZE. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=12850

[Bug regression/19174] wrong code regression or library problem in gcc-4.0-20041226

--- Additional Comments From andre dot maute at gmx dot de 2004-12-29 11:14 --- Sorry no cvs available, and only a modem dial-up connection, i'll try it when the new snapshot diff is available. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19174

Difference in assembly

Hello, I am building cross compilers for SPARC variant for Cygwin and MingW hosts. In the process I am faced with a very peculiar problem. For the code shown below, though I am getting same assembly instructions in same sequence, but the registers used in add are swapped. O0 has no problem, but

[Bug target/18329] [4.0 regression] mmix-knuth-mmixware testsuite failure: execute/920501-7.c

--- Additional Comments From hp at gcc dot gnu dot org 2004-12-29 11:04 --- I'm going in. -- What|Removed |Added AssignedTo|unassigned at gcc dot gnu |hp at gcc do

[Bug target/18321] [3.3/3.4/4.0 regression] mmix-knuth-mmixware testsuite failure: gcc.c-torture/compile/20031023-4.c -O0, -O1

--- Additional Comments From hp at gcc dot gnu dot org 2004-12-29 10:51 --- In response to comment #11: You should clarify what clarification you expect besides what I say in comment #7 and the target milestone setting. Perhaps you missed it, because it was said in passing? In http://g

[Bug c/19187] New: CVS broken for sparc-sun-solaris2.9

CVS sources checked out on 2004-12-29, 04:00 MET, doesn't build cleanly on sparc-sun-solaris2.9 while all previous days they did (nightly automated builds, simple configure && make). The error lines are: ../../gcc/gcc/config/sparc/sparc.c:502: error: initializer element is not constant ../../gcc/

[Bug libfortran/18983] can't open /dev/null as an output file

--- Additional Comments From bdavis at gcc dot gnu dot org 2004-12-29 09:58 --- http://gcc.gnu.org/ml/fortran/2004-12/msg00252.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18983

[Bug ada/19128] Bug box while building asharp

-- What|Removed |Added Status|NEW |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19128

[Bug bootstrap/19186] internal compiler error: virtual array prologue[3]: element 1 out of bounds in contains, at function.c:4660

--- Additional Comments From pluto at pld-linux dot org 2004-12-29 08:45 --- Created an attachment (id=7841) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=7841&action=view) buildlog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19186

[Bug bootstrap/19186] New: internal compiler error: virtual array prologue[3]: element 1 out of bounds in contains, at function.c:4660

# installed gcc: Reading specs from /usr/lib/gcc/i686-pld-linux/3.4.4/specs Configured with: ../configure --prefix=/usr --libdir=/usr/lib --libexecdir=/usr/lib --infodir=/usr/share/info --mandir=/usr/share/man --enable-shared --enable-threads=posix --enable-__cxa_atexit --enable-languages=c,c++,f7

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

--- Additional Comments From aoliva at redhat dot com 2004-12-29 08:04 --- Subject: Re: New: [4.0 regression] ICE on invalid template parameter On Dec 23, 2004, "reichelt at gcc dot gnu dot org" <[EMAIL PROTECTED]> wrote: > The following invalid code snippet triggers an ICE on mainlin

[Bug libfortran/19064] runtime error when reading complex*16 using formatted I/O

--- Additional Comments From bdavis at gcc dot gnu dot org 2004-12-29 07:59 --- closing, as all interested report it fixed. -- What|Removed |Added Status|NEW