--- Additional Comments From rmathew at gcc dot gnu dot org 2005-02-22
08:02 ---
I *hate* to be doing this, but once again, this is fixed
on current mainline.
--
What|Removed |Added
In gcc4 only djgpp and cygming targets have
HANDLE_PRAGMA_PACK_PUSH_POP defined, the gcc4 documentation does not say
these #pragmas are target spesific, there is also no configure option to
enable this for other (e.g *-elf) targets.
--
Summary: HANDLE_PRAGMA_PACK_PUSH_POP
Hi,
save the following dummy program as gfcbug24.F90 (capital F):
program gfcbug24_F90
print *, Hey, it works now!
end program gfcbug24_F90
Then compile with:
% gfortran -C gfcbug24.F90
I get:
gfortran: GCC does not support -C or -CC without -E
Preprocessing normally works, but the -C
--- Additional Comments From anlauf at hep dot tu-darmstadt dot de
2005-02-22 08:48 ---
It looks very much like a driver problem, because the option -std=f95
instead of -C makes it even funnier:
cc1: warning: command line option -std=f95 is valid for F95 but not for C
But at least it
--- Additional Comments From anlauf at hep dot tu-darmstadt dot de
2005-02-22 08:54 ---
While I'm at it: the option -pipe also has a funny side effect:
f951: error: unrecognized command line option -95
And it produces a file -95 in the current directory that contains
the preprocessed
--- Additional Comments From ebotcazou at gcc dot gnu dot org 2005-02-22
09:31 ---
Arno, any objection to moving them to norun.lst until after the issue is
resolved?
--
What|Removed |Added
--- Additional Comments From charlet at adacore dot com 2005-02-22 09:46
---
Subject: Re: ACATS cxa3004 cxb3006 fail at compile time ambiguous expression
Arno, any objection to moving them to norun.lst until after the issue is
resolved?
Actually I do not see the interest, since
--- Additional Comments From ebotcazou at gcc dot gnu dot org 2005-02-22
09:47 ---
Hum, this one is really tricky. It's indeed an aliasing problem and I think
your reduced, reduced testcase demonstrates that there might be a hole in the
flow-insensitive alias analysis for pointers that
--- Additional Comments From ebotcazou at gcc dot gnu dot org 2005-02-22
09:51 ---
Actually I do not see the interest, since the test is wrong.
I would simply cvs remove it.
I was under the impression that moving it to the norun.lst was the canonical
procedure when waiting for an
--- Additional Comments From charlet at adacore dot com 2005-02-22 09:55
---
Subject: Re: ACATS cxa3004 cxb3006 fail at compile time ambiguous expression
I was under the impression that moving it to the norun.lst was the canonical
procedure when waiting for an ACAA's response (did
--- Additional Comments From jakub at gcc dot gnu dot org 2005-02-22 10:25
---
Looks like a strength reduction bug.
Smaller self-contained testcase:
extern void abort (void);
typedef struct { int a; char b[3]; } S;
S c = { 2, aa }, d = { 2, aa };
void *
bar (const void *x, int y, int
--- Additional Comments From gniccolai at yahoo dot com 2005-02-22 10:27
---
You say a hypothetical multithreaded C++ should state this as the semantics
for
static locals, and I don't disagree with you, provided we are not talking
about
one based on POSIX threads. POSIX
--- Additional Comments From dieterbmeier at yahoo dot com 2005-02-22
10:32 ---
Andy's patch works great for HEAD, but I get
patching file avr.md
Hunk #1 FAILED at 344.
1 out of 1 hunk FAILED -- saving rejects to file avr.md.rej
when patching 3_4 branch.
--
--- Additional Comments From coudert at clipper dot ens dot fr 2005-02-22
10:33 ---
This is really weird:
$ cat a.f90
integer :: i
open (unit=20, file='data')
read(20,*) i
write(*,*) ' foo '
backspace(20)
read(20,*) i
end
$ cat data
1
2
3
$ gfortran a.f90 ./a.out
foo
*
end
$ gfortran -std=f95 a.f90 ./a.out
hello world
$ ifort a.f90 ./a.out
hello world
$ gfortran -v
Using built-in specs.
Target: i686-pc-linux-gnu
Configured with: ../gcc/configure --prefix=/tmp/gfortran-20050222/irun
--enable-languages=c,f95
Thread model: posix
gcc version
--- Additional Comments From dieterbmeier at yahoo dot com 2005-02-22
10:41 ---
Try patch attached to PR 18251. Good chance it will fix.
I still fails. (18251.patch.bz2 applied)
If not, pass me the source for a llok at.
Its already attached to this pr.
--- Additional Comments From uros at kss-loka dot si 2005-02-22 10:49
---
The problem in mainline is that 'tree type' of RECORD_TYPE enters fold_convert()
and triggers gcc_unreachable() in line 2003.
However Borland C++ exits with error: Call to function 'g' with no prototype.
on line
--- Additional Comments From pcarlini at suse dot de 2005-02-22 11:24
---
Richard, your fix is causing the regression of libstdc++/14026, can you please
have a look again to both?!? Thanks in advance...
--
What|Removed |Added
--- Additional Comments From jakub at gcc dot gnu dot org 2005-02-22 11:32
---
I think the bug is in loop_giv_rescan assumes validate_change in:
if (v-giv_type == DEST_ADDR)
/* Store reduced reg as the address in the memref where we found
this giv. */
With LAST_UPDATED: Mon Feb 21 15:56:07 UTC 2005, these tests succeeded.
With LAST_UPDATED: Tue Feb 22 00:07:00 UTC 2005 they fail:
Running
/home/hp/cvs_areas/combined/combined/gcc/testsuite/gcc.c-torture/execute/execute.exp
...
FAIL: gcc.c-torture/execute/20020720-1.c compilation, -O1
FAIL:
--- Additional Comments From hp at gcc dot gnu dot org 2005-02-22 12:02
---
Huh, forgot to fill in host and target...
This test used to be xfailed, btw, but should now pass due to generic
fabs optimizations.
--
What|Removed |Added
Hello,
this is my code:
templatetypename T void foo() {
unsigned char s[] = ;
(void)s;
}
int main() {
/* removing either of the calls below makes the error disappear */
fooint();
foochar();
}
Compiling this program with g++[0] results in
try.cc: In function `void foo()
--- Additional Comments From andrewhutchinson at cox dot net 2005-02-22
12:31 ---
Subject: Re: unable to find a register to spill in class
`POINTER_REGS'
if you can wait 12hrs I'll create 3.4 version.
Alternatively cut n paste from a 4.0 avr.md
the change is local to one area.
--- Additional Comments From reichelt at gcc dot gnu dot org 2005-02-22
12:56 ---
Confirmed.
This fails since gcc 2.95.3 or earlier.
--
What|Removed |Added
making a simple standalone/embedable editor I fall on a strange behavior.
code crashing the compiler with -03 level of optimisation, no complaints with -
O2
It's still very bugged, but it's a pre_alpha code
this is quite a small programm
(less than 4000 words in the .i file)
should be good for
--- Additional Comments From stephane dot bosio at vendeeconcept dot com
2005-02-22 13:07 ---
Created an attachment (id=8254)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8254action=view)
pre processed sources
this source file crashes with -03
--
--
What|Removed |Added
Component|c |middle-end
Summary|crashing the compiler with -|crashing the compiler with -
|03
--- Additional Comments From ericw at evcohs dot com 2005-02-22 13:19
---
Subject: Re: unable to find a register to spill in class
`POINTER_REGS'
dieterbmeier at yahoo dot com wrote:
--- Additional Comments From dieterbmeier at yahoo dot com 2005-02-22
10:32 ---
Andy's
Problem:
If a struct has a member which is a multi-dimensionnal array of class with an
explicit assignment operator, a trivial implicit operator is generated instead
of a non trivial one.
Code:
//
#include stdio.h
class Manager
{
public:
Manager (void);
Manager (const Manager );
--- Additional Comments From falk at debian dot org 2005-02-22 13:40
---
Confirmed, this is an ICE on invalid code. This is a test case for 4.0 (but
for some reason it doesn't work for 3.4):
struct ED_Ligne { int x; };
void dealloue_ligne();
void dealloue_buff(struct ED_Ligne
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-02-22
13:45 ---
Basically this is the same as PR 16876.
*** This bug has been marked as a duplicate of 16876 ***
--
What|Removed |Added
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-02-22
13:45 ---
*** Bug 20141 has been marked as a duplicate of this bug. ***
--
What|Removed |Added
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-02-22
13:48 ---
Caused by:
2005-02-21 Kazu Hirata [EMAIL PROTECTED]
* tree-cfg.c (fold_cond_expr_cond): New.
(make_edges): Call fold_cond_expr_cond.
(find_taken_edge): Accept nothing but
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-02-22
13:52 ---
This was fixed by the patch which fixed PR 18663 so closing as a dup.
*** This bug has been marked as a duplicate of 18663 ***
--
What|Removed |Added
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-02-22
13:52 ---
*** Bug 18705 has been marked as a duplicate of this bug. ***
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18663
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-02-22
14:00 ---
(In reply to comment #17)
Richard, your fix is causing the regression of libstdc++/14026, can you please
have a look again to both?!? Thanks in advance...
PR 20091 was opened for this regression.
--
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-02-22
14:06 ---
-C is not valid option at all for bound checking. -fbounds-check is the
correct option.
*** This bug has been marked as a duplicate of 18452 ***
--
What|Removed
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-02-22
14:06 ---
*** Bug 20138 has been marked as a duplicate of this bug. ***
--
What|Removed |Added
--- Additional Comments From jakub at gcc dot gnu dot org 2005-02-22 14:15
---
This is a DOM bug.
Comment above lookup_avail_expr says:
NOTE: This function assumes that STMT is a MODIFY_EXPR node that
contains no CALL_EXPR on its RHS and makes no volatile nor
aliased
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-02-22
14:16 ---
Huh: For compatibility with Win32
Pragmas are C front-end and not preprocessor bugs.
Confirmed.
--
What|Removed |Added
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-02-22
14:19 ---
Note this was cause by:
2005-01-26 Diego Novillo [EMAIL PROTECTED]
PR tree-optimization/19633
* tree-ssa-alias.c (ptr_is_dereferenced_by): Also handle
CALL_EXPRs.
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-02-22
14:21 ---
Also note that DOM is doing the correct thing as the DOM does not know that
func_other could
change the value of func_pure.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20115
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-02-22
14:44 ---
If we changed the function in comment #0 like so:
int f(int a)
{
a=(a|1)^1;
return a;
}
Fold should do this simplification.
And likewise for comment #1 (which is just general case):
int f(int a,int b)
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-02-22
14:56 ---
For pure calls the code would need to invalidate
all recorded pure calls whenever a stmt might modify global state.
Yes this was done with GLOBAL_VAR before Diego's patch but now it is not done
with
--
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |dnovillo at gcc dot gnu dot
|dot org |org
Status|NEW
--
What|Removed |Added
CC||tromey at redhat dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20104
--- Additional Comments From aph at gcc dot gnu dot org 2005-02-22 15:05
---
The failure is here:
package org.eclipse.jdt.internal.compiler.impl;
public class CompilerOptions ...
{
void updateSeverity(long irritant, Object severityString) {
if
--- Additional Comments From overholt at redhat dot com 2005-02-22 15:09
---
(In reply to comment #3)
1. Why was aload_3 generated? Which compiler genrated it?
snip
overholt, please let me know how this jar file was generated.
This jar file was generated by ecj.
--
Although I don't believe this is a regression, I do believe it's a bug which
should
ideally be remedied as soon as reasonably possible; as it seems unreasonable to
require any target to support data types more than twice as large as it's
pointer
type, or required by the language standards; so
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-02-22
15:19 ---
Dwarf2 unwinding requires long long.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20143
--- Additional Comments From aph at gcc dot gnu dot org 2005-02-22 15:23
---
Ok, so the file was generated by ecj, but was ecj precompiled or interpreted?
What VM was ecj running on?
Does ecj generate this same bogus file for
org.eclipse.jdt.internal.compiler.impl.CompilerOptions
--- Additional Comments From overholt at redhat dot com 2005-02-22 15:25
---
(In reply to comment #5)
Ok, so the file was generated by ecj, but was ecj precompiled or interpreted?
ecj was running interpreted at the time
What VM was ecj running on?
gij
Does ecj generate this
I think that -r8 is supposed work, but with gfortran 02-20 on the macintosh -
[dranta:~/tests/gfortran] dir% gfortran -i8 -r8 -o test test.f
gfortran: unrecognized option '-r8'
[dranta:~/tests/gfortran] dir% cat test.f
program main
stop
end
--
Summary: gfortran:
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-02-22
15:55 ---
*** This bug has been marked as a duplicate of 13464 ***
--
What|Removed |Added
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-02-22
15:55 ---
*** Bug 20144 has been marked as a duplicate of this bug. ***
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13464
When an include dir is given to gcc with the -isystem option the
warning: 'class CppUnit::ConcretTestFixtureFactoryErrorValueTest' has virtual
functions but non-virtual destructor is not suppressed as other warnings are.
This warning is new, with gcc34 or snapshot 20050116 this warning does not
--- Additional Comments From aph at gcc dot gnu dot org 2005-02-22 16:04
---
Forget that, second arg is a long. My mistake.
The compiled code is OK.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20104
It does not like this construction -
[dranta:~/tests/gfortran] dir% gfortran -o common common.f90
common.f90:0: internal compiler error: backend decl for module variable pc
already exists
Please submit a full bug report,
with preprocessed source if appropriate.
See
The C++ frontend issues an ICE when compiling the following invalid
code snippet:
void foo()
{
({x;});
}
bug.cc: In function 'void foo()':
bug.cc:3: error: 'x' was not declared in this scope
bug.cc:3: internal compiler error: tree check: expected class
--- Additional Comments From law at redhat dot com 2005-02-22 16:58 ---
Subject: Re: paradoxical subreg problem
On Mon, 2005-02-21 at 17:34 +, joseph at codesourcery dot com wrote:
--- Additional Comments From joseph at codesourcery dot com 2005-02-21
17:34 ---
--
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |kazu at cs dot umass dot edu
|dot org |
Status|NEW
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-02-22
17:02 ---
Confirmed, only happens when checking is turned on.
--
What|Removed |Added
--- Additional Comments From jakub at gcc dot gnu dot org 2005-02-22 17:03
---
That's not a problem. The SUBREG is SUBREG_PROMOTED_VAR_P and
SUBREG_PROMOTED_UNSIGNED_P, which is a promise that the upper 32 bits are all 0.
The problem is that when using the KR style function
The diagnostic for the following invalid code snippet is hosed on mainline
(this only affects the C++ frontend):
==
void foo()
{
if (({int c[2];})) ;
}
==
bug.cc: In function 'void foo()':
bug.cc:3: error: could not convert '{#'decl_expr' not
I don't know if you want reports when these are hit or not -
[dranta:~/tests/gfortran] dir% gfortran -o transfer transfer.f90
transfer.f90: In function 'MAIN__':
transfer.f90:5: fatal error: gfc_todo: Not Implemented: Scalarization of
non-elemental intrinsic: __transfer1
compilation terminated.
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-02-22
17:06 ---
Confirmed.
--
What|Removed |Added
Status|UNCONFIRMED |NEW
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-02-22
17:13 ---
*** Bug 20149 has been marked as a duplicate of this bug. ***
--
What|Removed |Added
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-02-22
17:13 ---
*** This bug has been marked as a duplicate of 17298 ***
--
What|Removed |Added
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-02-22
17:15 ---
Confirmed, related to PR 17917.
--
What|Removed |Added
BugsThisDependsOn|
--- Additional Comments From reichelt at gcc dot gnu dot org 2005-02-22
17:16 ---
The following code snippet shows a similar problem:
void foo()
{
if (({})) ;
}
bug.cc: In function 'void foo()':
bug.cc:3: error: could not convert
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-02-22
17:24 ---
I cannot reproduce this with 4.0 (20050222).
tin:~/src/gnu/gcctest/pr20145cat include/t.h
class t
{
virtual void f();
};
tin:~/src/gnu/gcctest/pr20145cat t.cc
#include t.h
class t1
{
virtual void f
=i686-pc-linux-gnu --enable-__cxa_atexit
--enable-languages=c++,objc,java,f95 --prefix=/
home/gates/pinskia/linux --enable-threads=posix --enable-shared
Thread model: posix
gcc version 4.0.0 20050222 (experimental)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20145
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-02-22
17:26 ---
Can you include the preprocessed source (the preprocessed source will have the
thing if a header is a
system header or not)?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20145
--
What|Removed |Added
Keywords||ice-on-valid-code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20025
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-02-22
17:53 ---
Confirmed.
--
What|Removed |Added
Status|UNCONFIRMED |NEW
--- Additional Comments From reichelt at gcc dot gnu dot org 2005-02-22
17:56 ---
Here's a slightly reduced testcase.
===
#includestdio.h
struct A
{
A() : i() {}
A (const A);
~A()
{
printf (Destructor: i = %d\n,
Regression from 3.2/3.3, calling allocate with n==0 leads to a call of new.
Fixup all ext allocators, port to 3.4
--
Summary: allocate(0) consistency checks
Product: gcc
Version: 3.4.3
Status: UNCONFIRMED
Severity: normal
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-02-22
18:14 ---
Subject: Bug 20056
CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED] 2005-02-22 18:14:04
Modified files:
libjava: ChangeLog verify.cc
Log message:
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-02-22
18:14 ---
Subject: Bug 20056
CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED] 2005-02-22 18:14:37
Modified files:
gcc/java : ChangeLog verify-impl.c
Log
--- Additional Comments From jakub at gcc dot gnu dot org 2005-02-22 18:14
---
The testcase is indeed invalid. KR definition can't serve as a prototype
and whether a 32-bit argument is on PPC64 sign or zero extended to 64-bit
depends on whether the argument is signed or unsigned.
So,
--- Additional Comments From dnovillo at gcc dot gnu dot org 2005-02-22
18:26 ---
Testing patch.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20115
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-02-22
18:27 ---
Confirmed.
--
What|Removed |Added
Status|UNCONFIRMED |NEW
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-02-22
18:27 ---
Confirmed.
--
What|Removed |Added
Status|UNCONFIRMED |NEW
I have no clue as to what the problem is here, but if I change almost anything
it goes away.
[dranta:~/tests/gfortran] dir% gfortran -c module_plot_hdf.f90
module_plot_hdf.f90: In function 'hdfsds_r8':
module_plot_hdf.f90:15: internal compiler error: Bus error
Please submit a full bug report,
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-02-22
18:41 ---
Confirmed, thanks for the reduced testcase (and all the other testcases too).
Here is the backtrace:
#0 translate_common (common=0x42305ab0, var_list=0x42305b10) at
/Users/pinskia/src/local3/
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-02-22
19:01 ---
Subject: Bug 19823
CVSROOT:/cvs/gcc
Module name:gcc
Branch: gcc-3_4-branch
Changes by: [EMAIL PROTECTED] 2005-02-22 19:00:40
Modified files:
boehm-gc :
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-02-22
19:02 ---
Fixed in 3.4.4.
--
What|Removed |Added
Status|NEW
--
What|Removed |Added
Severity|critical|normal
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20152
--
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |rth at gcc dot gnu dot org
|dot org |
Status|NEW
--- Additional Comments From rth at gcc dot gnu dot org 2005-02-22 20:01
---
No, the link error is unrelated. And I strongly suspect that you simply didn't
install the snapshot correctly, since the symbol does in fact exist and is
exported.
--
--- Additional Comments From andreast at gcc dot gnu dot org 2005-02-22
20:07 ---
I'll add a tc in libffi soon. It is ready here but I have a bunch of other tests
I'll submit when I finished my other libffi stuff.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20104
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-02-22
20:14 ---
Confirmed, reduced to:
struct KrSelectionMode { virtual void init() = 0; };
struct KrKDESelectionMode : public KrSelectionMode { void init() { } };
struct KrSelectionMode { virtual void init() = 0; };
The following program causes an internal compiler error when compiled with
gcc-3.4.3 or gcc-4.0 (CVS):
template typename T
class C
{
public:
void foo();
};
template typename T
void
CT::foo()
{
union {
struct {
};
};
};
int main()
{
return 0;
}
--
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-02-22
20:22 ---
Reduced to:
template typename T
void
foo()
{
union { struct { }; };
}
This is invalid code, if we do without template function we get an error:
t.cc: In function void foo():
t.cc:8: error:
--
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |mark at codesourcery dot com
|dot org |
Status|NEW
Hi,
there is a problem with the scope of (at least) implicit none
in gfortran. It falsely extends into interface definitions.
The following is a minimal legal example related to a discussion
I started on comp.lang.fortran today:
program gfcbug25
implicit none
interface
subroutine foo
--- Additional Comments From daney at gcc dot gnu dot org 2005-02-22 21:40
---
Created an attachment (id=8257)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8257action=view)
C testcase
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19683
--- Additional Comments From daney at gcc dot gnu dot org 2005-02-22 21:41
---
Created an attachment (id=8258)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8258action=view)
C testcase driver.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19683
--- Additional Comments From mmitchel at gcc dot gnu dot org 2005-02-22
21:47 ---
Fixed in 4.0.
--
What|Removed |Added
Status|ASSIGNED
--
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |mark at codesourcery dot com
|dot org |
Status|NEW
1 - 100 of 147 matches
Mail list logo
