--- Additional Comments From nathan at gcc dot gnu dot org 2005-09-16
07:30 ---
I shall take a look
--
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |na
double _Complex *a;
const double _Complex b[10] = {0, 1, 2, 3, 4, 5, 6, 7, 8, 9};
void
test (void)
{
a[0] = b[0] + b[1];
a[1] = b[0] + b[1];
return;
}
-->
;; Function test (test)
test ()
{
double CI.17;
double CR.16;
complex double * D.1616;
complex double * a.
--
What|Removed |Added
BugsThisDependsOn||23911
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19721
--- Additional Comments From rguenth at gcc dot gnu dot org 2005-09-16
08:14 ---
For a cut-down testcase (the one attached takes too much memory for my box)
detailled mem-report shows
tree-dfa.c:175 (create_stmt_ann) 12749568: 2.0%2932228:
1.0% 52: 0.0%
$ cat a.f
integer*8 i
integer*4 j
i = mod(i,j)
end
$ g77 a.f
$ ifort a.f
$ pgf77 a.f
$ gfortran a.f
In file a.f:3
i = mod(i,j)
1
Error: 'p' argument of 'mod' intrinsic at (1) must be the same
--
What|Removed |Added
BugsThisDependsOn||23912
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19292
--- Additional Comments From bonzini at gcc dot gnu dot org 2005-09-16
09:11 ---
fold_const_aggregate_ref does not handle REALPART_EXPR and IMAGPART_EXPR.
Steven has a patch, or so I'm told.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23911
--- Additional Comments From steven at gcc dot gnu dot org 2005-09-16
09:58 ---
This fixes it. Sadly only store-ccp propagates constants out of
initializers right now, which is a separate bug -- we _do_ find the
constant in the initializer... but then we don't propagate it for
som
--- Additional Comments From steven at gcc dot gnu dot org 2005-09-16
10:39 ---
The reason why this only happens in store-ccp is this:
/* If we are not doing store-ccp, statements with loads
and/or stores will never fold into a constant. */
if (!do_store_ccp
&& (ann
Hello
I am facing a problem in a very simple C code using
pointers: The code is
#
1. #include
2. int main(void)
3. {
4. char *p1;
5. char *p2;
6.
7. char a = 65;
8. p1 = &a;
9. printf(" %d %d
Full example files are here:
http://www.pvv.ntnu.no/~larschri/cast-bug/
The compiled program fails to do binary conversion between float and int. Both
sizeof(int) and sizeof(float) is 4, so the two floats below should have the same
binary representation after being written/read to/from the integer
--- Additional Comments From larschri at pvv dot ntnu dot no 2005-09-16
11:12 ---
Created an attachment (id=9739)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=9739&action=view)
.i file that triggers the bug.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23913
--- Additional Comments From ebotcazou at gcc dot gnu dot org 2005-09-16
11:16 ---
Your code violates ISO C aliasing rules. See the docs about -fstrict-aliasing.
--
What|Removed |Added
-
Failing case comes from regression testing using Boost uBLAS with gcc4.0.2
prerelease:
Using built-in specs.
Target: x86_64-unknown-linux-gnu
Configured with: ../gcc-4.0.2-20050913/configure
--prefix=/home/michael/locacc402
Thread model: posix
gcc version 4.0.2 20050913 (prerelease)
The
--- Additional Comments From larschri at pvv dot ntnu dot no 2005-09-16
11:34 ---
I see - thanks!
I didn't use the -Wall options when changing from C++ to C. g++ had the same
problem, but didn't give any warnings with -Wall.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23913
I get warning when compiling the following program as C, but not as C++. I have
experienced that such casts can fail for both C and C++ programs when running
with option -O2. See also [Bug c/23913].
int main() {
float f = 4.5;
int i =*((int*)&f);
(void)i;
return 0;
}
$ g++ -Wstrict-a
--- Additional Comments From larschri at pvv dot ntnu dot no 2005-09-16
12:12 ---
I have filed this enhancment ticket: [Bug c++/23915]
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23913
--- Additional Comments From bangerth at dealii dot org 2005-09-16 13:21
---
I am pretty sure this is a duplicate of PR 23896, which was fixed last
night. Can you try with an updated compiler?
Thanks
Wolfgang
--
What|Removed |Added
---
--- Additional Comments From bangerth at dealii dot org 2005-09-16 13:25
---
Confirmed.
--
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever
--- Additional Comments From nathan at gcc dot gnu dot org 2005-09-16
13:37 ---
This is a piece of underspecification in the resolution of DR 214
(http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html#214). That
basically tells one to compare pairs of arguments. But in this case
--
What|Removed |Added
Component|c |target
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23909
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-16
14:04 ---
You should be using the SSE instrincs functions.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23909
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-16
14:11 ---
Confirmed.
--
What|Removed |Added
Severity|normal |minor
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-16
14:14 ---
This really a dup of bug 14024.
*** This bug has been marked as a duplicate of 14024 ***
--
What|Removed |Added
-
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-16
14:15 ---
*** Bug 23915 has been marked as a duplicate of this bug. ***
--
What|Removed |Added
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-16
14:18 ---
Reopening to ...
--
What|Removed |Added
Status|RESOLVED|UNCO
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-16
14:18 ---
Mark as a dup of bug 21920.
*** This bug has been marked as a duplicate of 21920 ***
--
What|Removed |Added
-
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-16
14:18 ---
*** Bug 23913 has been marked as a duplicate of this bug. ***
--
What|Removed |Added
--- Additional Comments From langel at redhat dot com 2005-09-16 14:28
---
Fixed
--
What|Removed |Added
Status|ASSIGNED|RESOLVED
Res
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-16
14:40 ---
This works for me with 4.1.0 but I really think it is just an accident.
/[EMAIL PROTECTED]@*/ int cr0; /* really, it's used, but lclint doesn't
"get" __asm__ */
This comment does not make sense.
Speci
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-16
14:42 ---
Nope this was not fixed by the patch for 23896, tested on the mainline.
--
What|Removed |Added
---
--- Additional Comments From cvs-commit at developer dot classpath dot org
2005-09-16 14:44 ---
Subject: Bug 22610
CVSROOT:/cvsroot/classpath
Module name:classpath
Branch:
Changes by: Lillian Angel <[EMAIL PROTECTED]> 05/09/16 14:28:17
Modified files:
--
What|Removed |Added
Severity|normal |critical
Keywords||rejects-valid
http://gcc.gnu.org/bugzilla/show_bug.c
--- Additional Comments From jeff at panasas dot com 2005-09-16 14:50
---
(In reply to comment #3)
> This works for me with 4.1.0 but I really think it is just an accident.
> /[EMAIL PROTECTED]@*/ int cr0; /* really, it's used, but lclint doesn't
> "get"
__asm__ */
> This comment d
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-09-16
15:11 ---
Subject: Bug 23903
CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED] 2005-09-16 15:11:22
Modified files:
gcc: ChangeLog passes.c
Log message:
--- Additional Comments From bonzini at gcc dot gnu dot org 2005-09-16
15:18 ---
fixed
--
What|Removed |Added
Status|ASSIGNED|RESOLVED
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-16
15:31 ---
Since this is only a diagnostic issue and it has been fixed on the mainline by
the new parser, closing as
fixed for 4.1.0.
--
What|Removed |Added
--
--- Additional Comments From mmitchel at gcc dot gnu dot org 2005-09-16
15:32 ---
It's the same idea, but a different bug.
--
What|Removed |Added
AssignedTo|unassign
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-09-16
15:42 ---
Subject: Bug 21514
CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED] 2005-09-16 15:41:45
Modified files:
gcc/cp : ChangeLog pt.c
gcc/testsuite
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-16
15:42 ---
Fixed.
--
What|Removed |Added
Status|ASSIGNED|RESOLVED
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-09-16
15:43 ---
Subject: Bug 21514
CVSROOT:/cvs/gcc
Module name:gcc
Branch: gcc-4_0-branch
Changes by: [EMAIL PROTECTED] 2005-09-16 15:43:14
Modified files:
gcc/cp : Change
--- Additional Comments From mmitchel at gcc dot gnu dot org 2005-09-16
15:47 ---
Fixed in 4.0.2.
--
What|Removed |Added
Status|SUSPENDED |RESO
--
Bug 21701 depends on bug 21514, which changed state.
Bug 21514 Summary: [DR 488] templates and anonymous enum
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21514
What|Old Value |New Value
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-16
16:01 ---
Since PR 21514 is now closed as fixed, I am just going to close this as a dup
of bug 21514 since we
accept the code unconditionally now.
*** This bug has been marked as a duplicate of 21514 ***
--
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-16
16:01 ---
*** Bug 21701 has been marked as a duplicate of this bug. ***
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21514
--- Additional Comments From kargl at gcc dot gnu dot org 2005-09-16 16:09
---
Switch Severity to enhanacement (although I disagree the basic premise).
--
What|Removed |Added
--- Additional Comments From janis at gcc dot gnu dot org 2005-09-16 16:19
---
A regression hunt using a cross compiler identified this patch from steven:
http://gcc.gnu.org/ml/gcc-cvs/2005-07/msg00960.html
--
What|Removed |Added
--
MODULE bug
IMPLICIT NONE
TYPE :: my_type
REAL :: x
END TYPE
TYPE (my_type), DIMENSION(3) :: t
CONTAINS
SUBROUTINE foo
INTEGER, DIMENSION(8):: c(3)
t(c)%x = t(c)%x
RETURN
END SUBROUTINE foo
END MODU
--
What|Removed |Added
BugsThisDependsOn||23922
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15502
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-16
16:42 ---
Confirmed, reduced testcase:
MODULE bug
IMPLICIT NONE
TYPE :: my_type
REAL :: x
END TYPE
TYPE (my_type) :: t(3)
CONTAINS
SUBROUTINE foo
INTEGER:: c(3)
t(c)%x = t(c)%x
RETUR
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-16
16:43 ---
Oh, this is a dup of bug 18157.
*** This bug has been marked as a duplicate of 18157 ***
--
What|Removed |Added
-
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-16
16:43 ---
*** Bug 23922 has been marked as a duplicate of this bug. ***
--
What|Removed |Added
--
Bug 15502 depends on bug 23922, which changed state.
Bug 23922 Summary: ICE trying to fold_convert a REAL_TYPE to a RECORD_TYPE
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23922
What|Old Value |New Value
--
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-16
16:47 ---
Backtrace:
#1 0x08179a9f in fancy_abort (file=Could not find the frame base for
"fancy_abort".
) at /home/peshtigo/pinskia/src/gnu/gcc/src/gcc/diagnostic.c:590
#2 0x081ff931 in fold_convert (type=0xb7c336
--- Additional Comments From steven at gcc dot gnu dot org 2005-09-16
16:53 ---
Huh, I better look at this bug then, eh?
--
What|Removed |Added
AssignedTo|unassigne
--- Additional Comments From steven at gcc dot gnu dot org 2005-09-16
17:01 ---
Not being a C++ fan, I reduced it to this C test case:
==
extern int *F2 (void) __attribute__ ((__const__));
void
S4 (int *i)
{
int *D2171;
D2171 = F2 ();
L0:
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-16
17:49 ---
(In reply to comment #9)
> ./configure...
>
> make -C obj-i686-pld-linux \
> STAGE1_CFLAGS="-march=i686 -O0" \
> BOOT_CFLAGS="-march=i686 -O2"
I am testing with these options right now.
--
http://
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-16
17:54 ---
MMIX is not a primary or secondary target.
--
What|Removed |Added
Target Milestone|4.1.0
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-16
17:55 ---
I am going to fix this since PR 22052 was really caused by me.
--
What|Removed |Added
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-16
17:56 ---
Since this sounds like a GNU ld bug and not a GCC bug, removing the regression
marker.
--
What|Removed |Added
---
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-16
17:59 ---
Since this is a fortran front-end bug, moving to 4.2.
--
What|Removed |Added
Keywo
--- Additional Comments From janis at gcc dot gnu dot org 2005-09-16 18:08
---
The ICE begins on mainline with this patch from giovannibajo:
http://gcc.gnu.org/ml/gcc-cvs/2004-03/msg00874.html
--
What|Removed |Added
--- Additional Comments From laurent at guerby dot net 2005-09-16 18:15
---
Also happens the same way (run time core dump) on 4.0.2 20050913 (prerelease) on
sparc-linux.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20753
--- Additional Comments From reichelt at gcc dot gnu dot org 2005-09-16
18:16 ---
Fixed on mainline.
--
What|Removed |Added
Status|NEW |
--
What|Removed |Added
CC||christian dot joensson at
||gmail dot com
http://gcc.gnu.org/bu
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-09-16
18:33 ---
Subject: Bug 23914
CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED] 2005-09-16 18:33:35
Modified files:
gcc/cp : parser.c ChangeLog
gcc/tests
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-09-16
18:36 ---
Subject: Bug 23914
CVSROOT:/cvs/gcc
Module name:gcc
Branch: gcc-4_0-branch
Changes by: [EMAIL PROTECTED] 2005-09-16 18:35:59
Modified files:
gcc/cp : parser
--- Additional Comments From mmitchel at gcc dot gnu dot org 2005-09-16
18:37 ---
Fixed in 4.0.2.
--
What|Removed |Added
Status|ASSIGNED|RESO
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-16
18:43 ---
I have a fix for the mainline which also fixes this and 23104 and reverting
back to the old code which
was added for 19152.
--
What|Removed |Added
-
--- Additional Comments From kargl at gcc dot gnu dot org 2005-09-16 18:46
---
http://gcc.gnu.org/ml/gcc-patches/2005-09/msg01004.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23516
--- Additional Comments From christian dot joensson at gmail dot com
2005-09-16 18:48 ---
on 4.0 branch, this passed Aug 13,
http://gcc.gnu.org/ml/gcc-testresults/2005-08/msg00840.html,
but failed Sept. 2,
http://gcc.gnu.org/ml/gcc-testresults/2005-09/msg00140.html.
checking further...
--- Additional Comments From ebotcazou at gcc dot gnu dot org 2005-09-16
18:50 ---
Present on SPARC/Solaris too. It's a bug in the runtime.
--
What|Removed |Added
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-16
18:55 ---
This bootstrap just fine with the options you gave.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22584
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-16
19:04 ---
3.3.5 also fails. I think this is also related to the message on the gcc
mailing list recently:
http://gcc.gnu.org/ml/gcc/2005-09/msg00429.html
This is looks related to 2 operand targets.
--
--- Additional Comments From dave at hiauly1 dot hia dot nrc dot ca
2005-09-16 19:09 ---
Subject: Re: s-taprop.adb:69:06: warning: cannot depend on
"Interrupt_Operations" (wrong categorization)
> May be this will work, could you try?
>
> *** s-tpinop.ads.~1.9.~ 2005-07-01 08:24
--- Additional Comments From janis at gcc dot gnu dot org 2005-09-16 19:14
---
The test case passes on mainline starting with this patch from dje:
http://gcc.gnu.org/ml/gcc-cvs/2005-03/msg01221.html
--
What|Removed |Added
--
--
What|Removed |Added
URL||http://gcc.gnu.org/ml/gcc-
||patches/2005-
|
--- Additional Comments From mrs at apple dot com 2005-09-16 19:39 ---
radr://3934846
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23125
The terminating here-document marker in the AAB_sun_memcpy fix doesn't match the
opening marker. It needs to have an underscore added at the end.
Thanks!
$ diff inclhack.def inclhack.orig
196c196
< _EndOfHeader_;
---
> _EndOfHeader;
--
Summary: Bug in inclhack.def preven
--
What|Removed |Added
Component|other |target
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23923
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-16
19:59 ---
Rereducing on the mainline for x86_64-pc-linux with -m32.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23651
--- Additional Comments From debian-gcc at lists dot debian dot org
2005-09-16 20:05 ---
the patch, when applied to the 4.0 branch, let the bootstrap fail in libjava on
at least i486-linux and ia64-linux
Matthias
/home/packages/gcc/4.0/gcc-4.0-4.0.1/build/gcc/gcj
-B/home/packages/gcc
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-09-16
20:18 ---
Subject: Bug 23871
CVSROOT:/cvs/gcc
Module name:gcc
Branch: gcc-4_0-branch
Changes by: [EMAIL PROTECTED] 2005-09-16 20:18:11
Modified files:
libstdc++-v3 : Change
--- Additional Comments From janis at gcc dot gnu dot org 2005-09-16 20:22
---
The testcase from comment #5 ICEs starting with this patch from kenner:
http://gcc.gnu.org/ml/gcc-cvs/2004-06/msg00881.html
--
What|Removed |Added
--
--- Additional Comments From reichelt at gcc dot gnu dot org 2005-09-16
20:34 ---
The backport of the fix for PR 18445 caused this.
I'll try to backport the fix for PR18803, too.
If that fails, reverting the patch for PR 18445 seems like the right thing
to me, because this was only an ic
--- Additional Comments From nathan at gcc dot gnu dot org 2005-09-16
20:57 ---
IMHO reverting 18445 would be the most prudent thing to do. The combination of
18845+18803 are touching too many things for my liking.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18803
--- Additional Comments From reichelt at gcc dot gnu dot org 2005-09-16
21:04 ---
On 16 Sep, nathan at gcc dot gnu dot org wrote:
> IMHO reverting 18445 would be the most prudent thing to do. The combination
> of 18845+18803 are touching too many things for my liking.
Gaby, would that
$ cat erik.f90
program test
type t
real :: a = 3.1
end type t
type(t), pointer :: p
type(t), allocatable :: q(:)
allocate(p)
print *, p%a
allocate(q(1))
print *, q(1)%a
end program test
$ gfortran erik.f90
$ a.out
0.00
0.00
The output I had expected
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-16
21:49 ---
Hmm, I get:
In file t.f90:2
type t
1
Error: Pointer assignment target is neither TARGET nor POINTER at (1)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23924
--- Additional Comments From erik dot edelmann at iki dot fi 2005-09-16
21:59 ---
(In reply to comment #1)
> Hmm, I get:
> In file t.f90:2
>
> type t
>1
> Error: Pointer assignment target is neither TARGET nor POINTER at (1)
>
Oh! I'm terribly sorry; I used a locally modif
--- Additional Comments From gdr at integrable-solutions dot net
2005-09-16 22:40 ---
Subject: Re: [3.4 regression] rejects access to operator() in template
"reichelt at gcc dot gnu dot org" <[EMAIL PROTECTED]> writes:
| On 16 Sep, nathan at gcc dot gnu dot org wrote:
| > IMHO reverti
Build of hdf5-1.6.4 with Fortran module fails checks, although same build with
Intel 8.1 pass. Looks like it's primarily with conversions between particular
data types.
See http://hdf.ncsa.uiuc.edu/HDF5/
./configure --enable-fortran
make
make check
I want to emphasize that HDF5 is a very import
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-16
22:58 ---
lets look at the backtrace:
gt_ggc_mx_cp_binding_level
gt_ggc_mx_cxx_binding
Why are there are references to C++ front-end stuff. This is a front-end bug
make us still reference a
BasicBlock.
--
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-16
23:01 ---
How does it fail and is there a simple testcase?
--
What|Removed |Added
CC|
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-16
23:05 ---
(In reply to comment #3)
> Patch posted.
And approved.
--
What|Removed |Added
Assig
--- Additional Comments From erik dot edelmann at iki dot fi 2005-09-16
23:07 ---
Patch posted to mailinglist:
http://gcc.gnu.org/ml/gcc-patches/2005-09/msg01032.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15975
--- Additional Comments From erik dot edelmann at iki dot fi 2005-09-16
23:08 ---
Patch posted to the mailing list:
http://gcc.gnu.org/ml/gcc-patches/2005-09/msg01032.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16606
--- Additional Comments From green at redhat dot com 2005-09-16 23:10
---
(In reply to comment #1)
> Created an attachment (id=9352)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=9352&action=view)
> Proposed patch
>
> This patch makes your test program emit an absolute path.
>
>
--- Additional Comments From swhite at aei dot mpg dot de 2005-09-16 23:12
---
Andrew,
The "make check" command runs through a battery of tests. With gfortran, it
reports 72 failures, while with the Intel compiler, it passes everything.
I'm not sure what you're referring to regarding
--- Additional Comments From cvs-commit at developer dot classpath dot org
2005-09-16 23:12 ---
Subject: Bug 20198
CVSROOT:/cvsroot/classpath
Module name:classpath
Branch:
Changes by: Anthony Green <[EMAIL PROTECTED]> 05/09/16 22:52:18
Modified files:
1 - 100 of 133 matches
Mail list logo
