https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102619
Mikael Morin changed:
What|Removed |Added
CC||mikael at gcc dot gnu.org
--- Comment
at gcc dot gnu.org |mikael at gcc dot
gnu.org
--- Comment #3 from Mikael Morin ---
I'm working on it.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114922
Mikael Morin changed:
What|Removed |Added
CC||mikael at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111293
--- Comment #4 from Mikael Morin ---
For what's worth adding -fno-tree-vrp "fixes" this and enables removal of the
call to 'foo' with trunk.
Here is a minimal revert of the regressing revision, but it may just make the
problem latent.
diff
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111293
Mikael Morin changed:
What|Removed |Added
CC||mikael at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92178
Mikael Morin changed:
What|Removed |Added
Assignee|mikael at gcc dot gnu.org |unassigned at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111781
Mikael Morin changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114475
Mikael Morin changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107426
Mikael Morin changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107426
Mikael Morin changed:
What|Removed |Added
Status|NEW |ASSIGNED
--- Comment #10 from Mikael
at gcc dot gnu.org |mikael at gcc dot
gnu.org
--- Comment #3 from Mikael Morin ---
(In reply to anlauf from comment #2)
> (In reply to Jürgen Reuter from comment #1)
> > I suspect this commit here,
> > https://gcc.gnu.org/git/?p=gcc.git;
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103472
Mikael Morin changed:
What|Removed |Added
Known to work||14.0
Known to fail|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105547
Mikael Morin changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105547
--- Comment #2 from Mikael Morin ---
Created attachment 57739
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57739=edit
Patch fixing the problem
This small patch fixes the problem.
Unfortunately allowing more errors seems
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111781
--- Comment #9 from Mikael Morin ---
(In reply to anlauf from comment #8)
> (In reply to Mikael Morin from comment #7)
> > FAIL: gfortran.dg/pr98016.f90 -O (test for excess errors)
> > Excess errors:
> >
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111781
--- Comment #7 from Mikael Morin ---
(In reply to Mikael Morin from comment #6)
> I need to reevaluate it; there were other regressions if I remember
> correctly.
The changes are these:
PASS->FAIL: gfortran.dg/graphite/pr107865.f90 -O
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111781
--- Comment #6 from Mikael Morin ---
Created attachment 57571
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57571=edit
Tentative patch
(In reply to anlauf from comment #5)
> (In reply to anlauf from comment #4)
> > Thus I suggest to fix
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114141
--- Comment #6 from Mikael Morin ---
(In reply to kargl from comment #5)
> (In reply to Mikael Morin from comment #4)
>
> > (In reply to kargl from comment #3)
> > > Yep, agreed. I went back an re-read the section about ASSOCIATE.
> > > Not
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114141
Mikael Morin changed:
What|Removed |Added
CC||mikael at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113799
Mikael Morin changed:
What|Removed |Added
Known to fail||10.5.0, 11.4.0, 12.3.0,
||2024-02-07
Status|UNCONFIRMED |NEW
CC||mikael at gcc dot gnu.org
--- Comment #1 from Mikael Morin ---
Reduced:
module m
implicit none
real, parameter :: inf = real(z'7F80')
real, parameter :: someInf
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86656
Bug 86656 depends on bug 111291, which changed state.
Bug 111291 Summary: ASAN error: heap-use-after-free gcc/fortran/parse.cc:359 in
decode_statement
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111291
What|Removed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111291
Mikael Morin changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113377
--- Comment #6 from Mikael Morin ---
(In reply to anlauf from comment #4)
>
> Note that the following scalar example also fails:
>
"Fortunately", it is invalid. :-)
>From 15.5.2.12 (Argument presence and restrictions on arguments not
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113377
--- Comment #5 from Mikael Morin ---
(In reply to anlauf from comment #2)
> Note that adding a scalar call in function one:
>
> r(1) = two (i(1), j)
>
> generates sane code:
>
> *((integer(kind=4) *) __result.0 + (sizetype) ((offset.1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=46244
Mikael Morin changed:
What|Removed |Added
Status|ASSIGNED|NEW
Assignee|mikael at gcc dot
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113377
Mikael Morin changed:
What|Removed |Added
CC||mikael at gcc dot gnu.org
--- Comment
at gcc dot gnu.org |mikael at gcc dot
gnu.org
--- Comment #4 from Mikael Morin ---
Mine, I guess.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113152
Mikael Morin changed:
What|Removed |Added
CC||mikael at gcc dot gnu.org
--- Comment
at gcc dot gnu.org |mikael at gcc dot
gnu.org
--- Comment #16 from Mikael Morin ---
This missed the gcc stage 1 deadline, but I'm still working on it.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112412
Mikael Morin changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112371
Mikael Morin changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
|ASSIGNED
Last reconfirmed||2023-11-08
Assignee|unassigned at gcc dot gnu.org |mikael at gcc dot
gnu.org
--- Comment #1 from Mikael Morin ---
Patches submitted (and accepted):
https://gcc.gnu.org/pipermail/fortran/2023-November/059904.html
|1
Last reconfirmed||2023-11-08
Assignee|unassigned at gcc dot gnu.org |mikael at gcc dot
gnu.org
Component|fortran |libfortran
--- Comment #4 from Mikael Morin ---
Patches submitted (and accepted
Severity: normal
Priority: P3
Component: libfortran
Assignee: unassigned at gcc dot gnu.org
Reporter: mikael at gcc dot gnu.org
Target Milestone: ---
Non-masked reduction functions work, but their masked variant don't allocate if
the result is empty, so the result
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112371
--- Comment #3 from Mikael Morin ---
Possible culprit:
ifunction.m4 has this code:
retarray->base_addr = xmallocarray (alloc_size, sizeof (rtype_name));
if (alloc_size == 0)
{
/* Make sure we have a zero-sized
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112371
--- Comment #2 from Mikael Morin ---
If dim == 3, the ubound and shape are (/ 9, 3, 7 /) as expected.
That is, the problem only arises if the resulting array is empty.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112371
--- Comment #1 from Mikael Morin ---
(In reply to Mikael Morin from comment #0)
> i = 1
> (...)
> r = sum(a, dim=i)
If i is inlined, that is
r = sum(a, dim=1)
the shape and ubound are (/ 3, 0, 7 /) as expected.
The difference is
: normal
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: mikael at gcc dot gnu.org
Target Milestone: ---
In the following example, I expect the ubound to be (/ 3, 0, 7 /), but the
printed values are (/ 0, 0, 7 /).
program
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90608
Mikael Morin changed:
What|Removed |Added
Attachment #56094|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111781
--- Comment #3 from Mikael Morin ---
I'm trying to remove the formal_arg_flag global variables, which seem to just
disable all the checks on dummy arguments.
Unfortunately, it regresses a bit, say pr101026.f for example can be simplified
to
at gcc dot gnu.org |mikael at gcc dot
gnu.org
--- Comment #2 from Mikael Morin ---
I'm on it.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90608
--- Comment #13 from Mikael Morin ---
(In reply to Tamar Christina from comment #12)
> (In reply to Mikael Morin from comment #11)
> > Created attachment 56094 [details]
> > Improved patch
> >
> > This improved patch (still single argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90608
Mikael Morin changed:
What|Removed |Added
Attachment #56091|0 |1
is obsolete|
|NEW
Keywords||patch
CC||mikael at gcc dot gnu.org
Last reconfirmed||2023-10-12
--- Comment #1 from Mikael Morin ---
Confirmed.
This should fix it:
diff --git a/gcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90608
--- Comment #10 from Mikael Morin ---
(In reply to Mikael Morin from comment #8)
> (...) that is it was using too loops in a row in some cases.
>
... *two* loops in a row ...
(In reply to Tamar Christina from comment #9)
>
> Thanks Mikael!
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90608
--- Comment #8 from Mikael Morin ---
Created attachment 56091
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56091=edit
Rough patch
Here is a rough patch to make the scalarizer support minloc calls.
It regresses on minloc_1.f90 at least,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107716
Mikael Morin changed:
What|Removed |Added
CC||mikael at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110996
Mikael Morin changed:
What|Removed |Added
Target Milestone|--- |14.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108957
Mikael Morin changed:
What|Removed |Added
Target Milestone|--- |14.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106050
Mikael Morin changed:
What|Removed |Added
Target Milestone|--- |14.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108957
Mikael Morin changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106050
Mikael Morin changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110996
Mikael Morin changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: mikael at gcc dot gnu.org
CC: anlauf at gcc dot gnu.org, dfranke at gcc dot gnu.org,
gcc-bugs at gcc dot gnu.org,
P.Schaffnit at access dot rwth-aachen.de
|UNCONFIRMED |ASSIGNED
Assignee|unassigned at gcc dot gnu.org |mikael at gcc dot
gnu.org
Ever confirmed|0 |1
--- Comment #5 from Mikael Morin ---
(In reply to anlauf from comment #4)
> Mikael,
>
> are you still onto it
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89891
Bug 89891 depends on bug 48776, which changed state.
Bug 48776 Summary: ICE(segfault) after -std=f95 diagnostic error involving
PROCEDURE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=48776
What|Removed |Added
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=48776
Mikael Morin changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
||mikael at gcc dot gnu.org
Status|UNCONFIRMED |RESOLVED
--- Comment #3 from Mikael Morin ---
All the testcases here have been fixed by the fix for pr48776.
Closing as duplicate.
*** This bug has been marked as a duplicate of bug 48776 ***
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=48776
Mikael Morin changed:
What|Removed |Added
CC||gs...@t-online.de
--- Comment #10 from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110996
Mikael Morin changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |mikael at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=48776
Mikael Morin changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |mikael at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=48776
--- Comment #7 from Mikael Morin ---
(In reply to Mikael Morin from comment #6)
> Can't reproduce with a recent master (14.0.0 20230814).
Sorry, missed the -std=f95 flag.
Confirmed on recent master.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=48776
Mikael Morin changed:
What|Removed |Added
CC||mikael at gcc dot gnu.org
--- Comment #6
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86657
Mikael Morin changed:
What|Removed |Added
CC||mikael at gcc dot gnu.org
--- Comment #6
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68152
Mikael Morin changed:
What|Removed |Added
CC||mikael at gcc dot gnu.org
--- Comment #3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110996
--- Comment #8 from Mikael Morin ---
(In reply to JuzheZhong from comment #7)
> Do you have a solution that we can fix RISC-V backend?
No, this is not RISC-V specific.
> Or you will fix it in Fortran front-end?
Yes, the fix will have to be
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110996
--- Comment #6 from Mikael Morin ---
(In reply to Mikael Morin from comment #5)
> Here sym->formal_ns is NULL because the symbol C has not been completely
> setup.
This makes the following an "obvious" fix:
diff --git a/gcc/fortran/decl.cc
|NEW
Last reconfirmed||2023-08-17
CC||mikael at gcc dot gnu.org
--- Comment #5 from Mikael Morin ---
Confirmed on the reduced example from comment #2.
The problem arises because of the bogus subroutine statement
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110360
--- Comment #42 from Mikael Morin ---
(In reply to anlauf from comment #41)
> (In reply to Mikael Morin from comment #40)
> > Harald, I have just closed the followup PR110419.
> > I think this PR can be closed as well, or is there something
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110360
--- Comment #40 from Mikael Morin ---
Harald, I have just closed the followup PR110419.
I think this PR can be closed as well, or is there something left to be done?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110419
Mikael Morin changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
at gcc dot gnu.org |mikael at gcc dot
gnu.org
--- Comment #19 from Mikael Morin ---
Patch submitted:
https://gcc.gnu.org/pipermail/fortran/2023-August/059666.html
https://gcc.gnu.org/pipermail/gcc-patches/2023-August/626870.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110419
--- Comment #18 from Mikael Morin ---
Created attachment 55662
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55662=edit
Updated tentative patch
This fixes comment #4 as well, but the failure on value_9 remains on 32 bit
powerpc.
It is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110419
--- Comment #17 from Mikael Morin ---
Created attachment 55660
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55660=edit
Update function type patch
This patch changes the dummy argument declaration type.
It changes the dump as follows.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87142
Bug 87142 depends on bug 110618, which changed state.
Bug 110618 Summary: Dependency between arguments when one is allocatable array
whose dummy is intent(out)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110618
What|Removed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110618
Mikael Morin changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110419
--- Comment #15 from Mikael Morin ---
rs6000_pass_by_reference returns true with -m32, and false with -m64.
So the second argument is passed by reference with -m32, and by value with
-m64.
So the code in val looks right, it is the code in p
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92178
Mikael Morin changed:
What|Removed |Added
CC||mikael at gcc dot gnu.org
--- Comment
|UNCONFIRMED |ASSIGNED
Ever confirmed|0 |1
Assignee|unassigned at gcc dot gnu.org |mikael at gcc dot
gnu.org
--- Comment #2 from Mikael Morin ---
Patches submitted:
https://gcc.gnu.org/pipermail/fortran/2023-July/059596.html
https://gcc.gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99798
Mikael Morin changed:
What|Removed |Added
CC||mikael at gcc dot gnu.org
--- Comment #2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106050
Mikael Morin changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |mikael at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110618
--- Comment #1 from Mikael Morin ---
Created attachment 55517
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55517=edit
Draft patch
This seems to work for this case, but I'm not sure how reliable it is.
Keywords: wrong-code
Severity: normal
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: mikael at gcc dot gnu.org
CC: abensonca at gcc dot gnu.org, anlauf at gcc dot gnu.org,
burnus
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106050
Mikael Morin changed:
What|Removed |Added
CC||mikael at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110419
--- Comment #14 from Mikael Morin ---
The tree optimized dumps are almost the same for 32 and 64 bits.
The expand dumps show more significant differences.
The 64 bits dump shows the register r4 is saved to memory with:
(insn 3 2 4 2 (set
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110419
--- Comment #13 from Mikael Morin ---
Created attachment 55488
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55488=edit
-m64 rtl final dump at -O0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110419
--- Comment #12 from Mikael Morin ---
Created attachment 55487
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55487=edit
-m64 rtl expand dump at -O0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110419
--- Comment #11 from Mikael Morin ---
Created attachment 55486
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55486=edit
-m64tree optimized (at -O0) dump
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110419
--- Comment #10 from Mikael Morin ---
The three previous dumps are generated with the example in comment #4.
The problem seems to turn around the val function needing to take the address
of the c argument, which is passed by value.
On powerpc,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110419
--- Comment #9 from Mikael Morin ---
Created attachment 55480
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55480=edit
-m32 final rtl dump at -O0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110419
--- Comment #8 from Mikael Morin ---
Created attachment 55479
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55479=edit
-m32 rtl exand dump at -O0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110419
--- Comment #7 from Mikael Morin ---
Created attachment 55478
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55478=edit
-m32 tree optimized (at -O0) dump
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110419
--- Comment #6 from Mikael Morin ---
I finally got my access on gcc110 working.
(gdb) r
Starting program: /home/mmorin/gcc-pr110360/pr110360/pr110419_comment4
Program received signal SIGSEGV, Segmentation fault.
0x1684 in val (x=...,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110419
--- Comment #2 from Mikael Morin ---
(In reply to Mikael Morin from comment #1)
> Harald committed an additional fix to the PR:
>
Unfortunately, the failure on big endian power remains.
Is the execution output the same as before?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110419
Mikael Morin changed:
What|Removed |Added
CC||mikael at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110360
--- Comment #23 from Mikael Morin ---
(In reply to anlauf from comment #22)
> Created attachment 55418 [details]
> Slighty revised version of 3rd patch
>
> I've looked at gfc_conv_string_parameter, which I was not aware of.
> This can be used
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110360
--- Comment #21 from Mikael Morin ---
(In reply to anlauf from comment #20)
> Created attachment 55407 [details]
> Third patch set
>
> Here's a lightly tested 3rd patch that tries to handle the chaos I created...
>
> Can you have a look?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110360
--- Comment #19 from Mikael Morin ---
(In reply to Mikael Morin from comment #18)
> There is the "obvious" problem that gfc_build_wide_string_const creates a
> bare array, whereas gfc_string_to_single_character expects a pointer
> wrapping
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110360
--- Comment #18 from Mikael Morin ---
(In reply to Mikael Morin from comment #15)
> I have asked for an account on the compile farm (see
> https://gcc.gnu.org/wiki/CompileFarm) to have access to a powerpc machine.
It was pretty fast to get the
1 - 100 of 956 matches
Mail list logo