eport
===
While normally the next report would be given by Richard, I'd like to
skip ahead to Joseph, so that the same RM isn't responsible for two
reports in the same week.
Thanks,
--
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713
agnostics would be an improvement. Some of these
problems that we consistently struggle with (printing complex
expressions, using the same spellings of keywords and types that the
user did, etc.) would be significantly improved by using carets -- even
if the carets didn't point in exactly the right
o-member, but merely the name of a member function. I think
that's an intentional tightening; C++ doesn't allow you to do anything
with the name of a member function, except call it. And, the tightening
goes back at least to G++ 3.2, as far as I can tell. So, I think
removing t
Geoffrey Keating wrote:
Mark Mitchell <[EMAIL PROTECTED]> writes:
Steven Bosscher wrote:
Or should the development plan beupdated to reflect your new way of
working (ie. the projects info collecting thing) and the actual
development schedule that we seem to be working on.
It would proba
in the way of this plan. All he's doing
is making a change that will reduce memory usage, without making major
changes to the existing interface. I think the key obstacle to the plan
expressed here is not fold, but rather than the gimplifier doesn't do
the transformations required.
--
t;need" in
the above means "required to be made into a constant by the semantics of
the language".
Yes.
--
Mark Mitchell
CodeSourcery, LLC
[EMAIL PROTECTED]
(916) 791-8304
Andrew Haley wrote:
Mark Mitchell writes:
> >
> 1. Front ends should build up trees, calling fold only when/if they
> want. For example, in C++, we would want to call fold when we finish
> processing an "integral constant expression", which is a term of art
Neil Booth wrote:
Mark Mitchell wrote:-
However, while that may be necessary for Java, it's not necessary for
C++. In C++, fold should only be called for "integral constant
expressions", which, by definition, are made up of simple operations on
integers. (It's a little m
munication between a proposer and Mark
should only be a first step; real development discussions should take
place on this list.
I completely agree.
--
Mark Mitchell
CodeSourcery, LLC
[EMAIL PROTECTED]
(916) 791-8304
_TICK (-1 if not a
SUBREG). */
#define SUBREG_TICKED(N) (get_cse_reg_info (N)->subreg_ticked)
I don't see anything wrong with getting rid of these macros, and having
the callers do:
info = get_cse_reg_info (N);
info->tick ... info->reg_in_table ...
--
Mark Mitchell
CodeSource
ou don't pass down post_p.
--
Mark Mitchell
CodeSourcery, LLC
[EMAIL PROTECTED]
(916) 791-8304
REF, and then modify the OBJ_TYPE_REF
documentation to indicate that.
--
Mark Mitchell
CodeSourcery, LLC
[EMAIL PROTECTED]
(916) 791-8304
ou
that, than to waste everyone's time pretending I've not come to a
conclusion. Even then, I'm always willing to be persuaded otherwise --
but the way to do that is to write a well-reasoned description of why
I'm wrong that convinces others. If lots of other people think
differently, that's a suggestion I should rethink my position.
--
Mark Mitchell
CodeSourcery, LLC
[EMAIL PROTECTED]
(916) 791-8304
eem to do some kind
of majority-rules thing.
That's exactly what happened with respect to making G++ compile with a
C++ compiler; enough other people seemed convinced that it was
worthwhile that I re-thought. That occurred through the passage of time
and lots of conversation, not through an argument with you.
--
Mark Mitchell
CodeSourcery, LLC
[EMAIL PROTECTED]
(916) 791-8304
that, using and detecting a different
error code for an ICE is an excellent idea.
I definitely agree. I think that would be great.
--
Mark Mitchell
CodeSourcery, LLC
[EMAIL PROTECTED]
(916) 791-8304
ifornia".
I've received a lot of good proposals for 4.1, and am working on
ordering them as best I can. I'll be posting that information later
today -- before I create the branch.
FYI,
--
Mark Mitchell
CodeSourcery, LLC
[EMAIL PROTECTED]
(916) 791-8304
As of now please refrain from further checkins to the mainline, until I
post a message announcing that the 4.0 branch has been created.
I'll post a message re. 4.1 as soon as the branch has been made.
--
Mark Mitchell
CodeSourcery, LLC
[EMAIL PROTECTED]
(916) 791-8304
n ELF toolchain; use a linker script instead.
I did fix at least one bug, such that -Ttext does something useful with
ELF toolchains, if your linker script it set up to use it. I think the
ARM BPABI script may be the only one set up that way, though.
--
Mark Mitchell
CodeSourcery, LLC
[
se don't try to do anything with that until I give the thumbs-up.
--
Mark Mitchell
CodeSourcery, LLC
[EMAIL PROTECTED]
(916) 791-8304
tried to put these projects early; we don't want to stuff to miss
two release cycles.
For 4.1, I'm going to try (again) to keep to the six-month schedule in
our development plan. So, Stage 1 will end April 25th, Stage 2 will end
June 25th (or a little later, given Ottawa), etc.
--
Mark Mitchell
CodeSourcery, LLC
[EMAIL PROTECTED]
(916) 791-8304
/scripttempl/armbpabi.sc.
Search for SEGMENT_START, in particular. This is an expression you can
use in a linker script that will honor the -T flags. I've been meaning
to add that support to the elf.sc linker script (used on GNU/Linux, for
example), but I've never gotten around to it
Nathan Sidwell wrote:
Mark Mitchell wrote:
I have posted the GCC 4.1 project submissions I received here:
http://gcc.gnu.org/wiki/GCC%204.1%20Projects
You've not included the completion of gcc_assertification, did you miss
that email, or did you not think it necessary to add it as a spe
problems without requiring any tuning of the inlining algorithms. Has
anybody experimented with that potentially much less intrusive fix?
--
Mark Mitchell
CodeSourcery, LLC
[EMAIL PROTECTED]
(916) 791-8304
acceptable for 4.0 that would give people an easy to understand way of
getting the compiler to do what they want: put "inline" on functions
they really want to have inlined. That's in addition to the existing
heuristics. I think that's a plausible way of mitigating the pr
Nathan Sidwell wrote:
Mark Mitchell wrote:
Nathan Sidwell wrote:
You've not included the completion of gcc_assertification, did you miss
that email, or did you not think it necessary to add it as a specific
project, or ... ?
The former; I thought we'd corresponded about that previ
in this branch, as it
would seem to be in their best interest to do so?
--
Mark Mitchell
CodeSourcery, LLC
[EMAIL PROTECTED]
(916) 791-8304
ister
a lot.
In the case or "register", we now have a compiler which seems to
generate just as good code by ignoring the keyword as it did by honoring
it, we avoid the kinds of ICEs you discuss. We don't know whether those
things are true about "inline" or not.
--
Mark Mit
Daniel Jacobowitz wrote:
On Sun, Feb 27, 2005 at 02:57:05PM -0800, Mark Mitchell wrote:
Nathanael said it did not interfere with any of the other _projects_,
not that it would be disjoint from all Stage 1 _patches_.
Fair point.
I would certainly prefer that you hold off until Stage 2, as
upon submission. Since that seems to be the consensus,
I'll implement that in the next release cycle.)
I think the constraints on the process ought to include (a) relatively
little effort invested by relatively few people in the decision making
process, and (b) clear termination condition
rhaps it will become obvious before then, one way or the other.
--
Mark Mitchell
CodeSourcery, LLC
[EMAIL PROTECTED]
(916) 791-8304
Giovanni Bajo wrote:
Mark Mitchell <[EMAIL PROTECTED]> wrote:
1. The C++ community has split into two sub-communities. One is very
heavily focused on template metaprogramming. The other is doing more
"traditional" object-oriented programming.
I would postulate that most of the
tested and completely
ready to go before Stage 1 started.
I'd like to think that the fact that I've expressed willingness to
reconsider Nathanael's patch would be encouraging to those who might try
to game the system. If I'm wrong about the risk level of Nathanael's
rying to
make the whole thing work; while I have my objections against the idea,
it may turn out that most of the people work in a different way
and will actually prefer it (I admit to enjoy a controlled amount of
chaos :-)
Thank you for the kind words.
--
Mark Mitchell
CodeSourcery, LLC
[EMAIL PROT
over the years. However, I think
that this was an inappropriate action on your part. I'd appreciate your
assurance that you will not take this kind of preemptive action again.
--
Mark Mitchell
CodeSourcery, LLC
[EMAIL PROTECTED]
(916) 791-8304
copies of mail, though, and so CC'ing directly to
me is always a good bet, if you think I might be interested.
Regards,
--
Mark Mitchell
CodeSourcery, LLC
[EMAIL PROTECTED]
(916) 791-8304
Gabriel Dos Reis wrote:
And, yes, I appreciate your work a lot. That does not rule out
occasional disagreements.
I agree.
And, I think Nathanael and I have resolved the situation very
satisfactorily, so, as far as I'm concerned, everything worked as well
as could be hoped.
--
Mark Mit
ke it work better on more systems, such as
those with DWARF. I think that Joern's objections can be dealt with
after you get those fixes in place; I would imagine that you would just
mark small basic blocks directly reachable from hot blocks as "hot",
whether or not profiling data act
probably
something that could be done via range propagation.
--
Mark Mitchell
CodeSourcery, LLC
[EMAIL PROTECTED]
(916) 791-8304
progress in realizing it...)
--
Mark Mitchell
CodeSourcery, LLC
[EMAIL PROTECTED]
(916) 791-8304
act
that someone's willing to maintain it; we ought to convince ourselves
that the benefit to users will be sufficiently great that it's worth
imposing these costs.
--
Mark Mitchell
CodeSourcery, LLC
[EMAIL PROTECTED]
(916) 791-8304
Helge Bahmann wrote:
On Tue, 1 Mar 2005 Mark Mitchell wrote:
Helge Bahmann wrote:
void (A::*function2)(void) throw()=&A::function2;
(a.*function2)();
however for the call through pointer function2 gcc will always generate an
indirect call, i386 assembly for example looks like:
Yes
es locally until the prescribed time, but I thought I'd make
the offer anyway.
Yes, that's eminently sensible. Thanks for making yourself available!
--
Mark Mitchell
CodeSourcery, LLC
[EMAIL PROTECTED]
(916) 791-8304
r the RM to declare at this
point what a future decision would be. I suspect that if done well, the
RM would entertain allowing it in 4.0.[n+1]; but that is just speculation.
I have it on good authority that the RM agrees with all of the
statements above.
--
Mark Mitchell
CodeSourcery, LLC
[
bout possibly broken interfaces,
or late about definitely broken usage? I think that warning early,
together with what DJ is calling fine-grained warning control is the
best solution.
--
Mark Mitchell
CodeSourcery, LLC
[EMAIL PROTECTED]
(916) 791-8304
le actually make the same argument sometimes about things like:
void f() {
int *p = 0;
*p = 3;
}
saying "but I never call f, so I don't want a warning for it".
Languages like Python or LISP are the (extreme) logical extension of
your point of view: just start running the program and
ibute you can put
on the class to say "don't issue this warning about this class."
--
Mark Mitchell
CodeSourcery, LLC
[EMAIL PROTECTED]
(916) 791-8304
ode in any substantial way, and I don't
see any reason to modify this policy. The same certainly goes for 4.1.
As you say, what's needed is a reviewer.
--
Mark Mitchell
CodeSourcery, LLC
[EMAIL PROTECTED]
(916) 791-8304
rst place, rather than putting them in ChangeLog
and moving them, but I realize that this is (a) contrary to the GNU
coding standards, and (b) not as friendly to some editors.)
--
Mark Mitchell
CodeSourcery, LLC
[EMAIL PROTECTED]
(916) 791-8304
natural way.
Finally, the third approach would be to introduce new tree codes for
LCOND_EXPR, LMIN_EXPR and LMAX_EXPR that reflect the subtley different
semantics of these operators when uses as lvalues.
Swee above; I don't think you can now this at the time at which the
front end is presently calling fold.
--
Mark Mitchell
CodeSourcery, LLC
[EMAIL PROTECTED]
(916) 791-8304
cxx_fold (op2));
...
}
and use it in fold_non_dependent_expr, and other similar places. (Since
we're no longer calling fold, tsubst_copy_and_build will give us back a
tree that needs to be simplified; that's were we call cxx_fold.)
--
Mark Mitchell
CodeSourcery, LLC
[EMAIL PROTECTED]
(916) 791-8304
m. In fact, the C++ front end already contains code to
massage these COND_EXPRs so that the back end doesn't see COND_EXPRs
used as lvalues; it's just not getting a chance to run before fold!
--
Mark Mitchell
CodeSourcery, LLC
[EMAIL PROTECTED]
(916) 791-8304
Roger Sayle wrote:
On Mon, 7 Mar 2005, Mark Mitchell wrote:
Roger Sayle wrote:
I truly hope you're not trying to suggest that it was me that introduced
the concept of MIN_EXPR and MAX_EXPR as lvalues into the C++ front-end:
I thought you were the person who introduced changes to fold that c
Steven Bosscher wrote:
On Monday 07 March 2005 19:49, Mark Mitchell wrote:
The way I think about this is that G++ has long supported the GNU
min/max expression extension -- and it's long been broken. Over the
years, I've fielded several bug reports about that extension, and we&#x
ser community before we do that. Of all the extensions we've had, this
one really hasn't been that problematic.
(Removing the extension is separate from the question of whether MIN_EXPR
and MAX_EXPR are useful parts of GENERIC to facilitate some
optimizations.)
Indeed.
--
Mark Mitc
rid of 99% of the
dependencies in our Makefiles, and avoid most of the cases where
something either (a) fails to get rebuilt, or (b) gets rebuilt too often.
My two cents,
--
Mark Mitchell
CodeSourcery, LLC
[EMAIL PROTECTED]
(916) 791-8304
NERIC tree and I see absolutely no
reason to avoid calling fold as part of that process: it's far more efficient
to do it then and build simpler trees than to burden the gimplication
process with junk trees.
I think you're in violent agreement with the rest of us.
--
Mark Mitchell
CodeSourcery, L
at in situations where you're using PCH, you'll
likely see a better improvement, as you'll need to access fewer PCH
pages when later on. Thanks for working on this cleanup; it's a
long-standing issue.
--
Mark Mitchell
CodeSourcery, LLC
[EMAIL PROTECTED]
(916) 791-8304
Daniel Jacobowitz wrote:
On Mon, Mar 07, 2005 at 07:56:05PM -0800, Mark Mitchell wrote:
We do need a story for generated headers. I'd be happy with explicit
dependencies in the Makefiles indicating what source files depend on
what generated headers. We'd still be able to get rid of
y uses it. So, SH is broken, at least
for C++.
I'm not sure what that means, but I'd be tempted just to declare it broken.
--
Mark Mitchell
CodeSourcery, LLC
[EMAIL PROTECTED]
(916) 791-8304
hange the C++ ABI on
those platforms where this makes a difference.
I would call this sufficiently much a corner case as to say that we
should just go ahead and do it. If we're truly paranoid, we can make
this dependent on flag_abi_version.
--
Mark Mitchell
CodeSourcery, LLC
[EMAIL PROTECTED]
(916) 791-8304
Zack Weinberg wrote:
So, in other words,
if (current_function_stdarg)
data->last_named = true;
Actually, no:
data->last_named = !TREE_CHAIN (parm);
(This is the last "named" parameter iff it's the last parameter.)
But, right idea. :-)
--
Mark Mitchell
CodeSourcery,
x release
which I will manage; I want to focus exclusively on 4.0 and 4.1 after
that point.
--
Mark Mitchell
CodeSourcery, LLC
[EMAIL PROTECTED]
Otherwise, stuff in either the compiler or
the program itself could make the justified assumption that things of
that type are aligned more strictly than they actually are.
--
Mark Mitchell
CodeSourcery, LLC
[EMAIL PROTECTED]
(916) 791-8304
x27;m
just checking that we're not breaking the ABI.)
--
Mark Mitchell
CodeSourcery, LLC
[EMAIL PROTECTED]
(916) 791-8304
ority. It would be good to fix this (by modifying fixincludes), but
in the end, if push comes to shove, we'll probably just not bother.
So, I would suggest that you try to fix this yourself, and submit a patch.
--
Mark Mitchell
CodeSourcery, LLC
[EMAIL PROTECTED]
(916) 791-8304
Jason Merrill wrote:
On Mon, 07 Mar 2005 11:49:05 -0800, Mark Mitchell <[EMAIL PROTECTED]> wrote:
IMO, if these are C++-only, it's relatively easy to deprecate these
extension -- but I'd like to hear from Jason and Nathan, and also the user
community before we do that. Of al
Razya Ladelsky wrote:
Mark Mitchell <[EMAIL PROTECTED]> wrote on 11/03/2005 04:55:38:
Daniel Berlin wrote:
As for why the new name doesn't work, it's not clear from the above.
I'd need to see the assembly and the error.
:)
Likewise. I assume these functions have only inter
ld rather than crossjumping be run on calls to
"abort". I use "abort" only when I've already issued a useful
diagnostic, and want to dump core. Otherwise, I use "assert", or an
exception. So, I would not support this change.
--
Mark Mitchell
CodeSourcery, LLC
[EMAIL PROTECTED]
(916) 791-8304
l to the size of the base type in those instances where we are
creating an array.
That could be fixed by adding the check you suggest, and then just
discarding the attribute.
--
Mark Mitchell
CodeSourcery, LLC
[EMAIL PROTECTED]
(916) 791-8304
s use is
common enough that it appears in tests.
If there is a lot of code out there that does this, that might indeed be
necessary, ugly though it would be.
--
Mark Mitchell
CodeSourcery, LLC
[EMAIL PROTECTED]
(916) 791-8304
Gabriel Dos Reis wrote:
Mark Mitchell <[EMAIL PROTECTED]> writes:
| Joe Buck wrote:
| > On Tue, Mar 15, 2005 at 04:42:03PM -0800, Steve Ellcey wrote:
| >
| >>The simplest solution would probably be to ignore __aligned__ attributes
| >>completely when we have an array.
aligned, but
the object pointed to is just a float not an aligned float.
> If we changed GCC to pad
the array elements (in order to obey the alignment request) wouldn't we
actually break our ability to vectorize things?
Yes.
--
Mark Mitchell
CodeSourcery, LLC
[EMAIL PROTECTED]
(916) 791-8304
for a while. Not simple, I realize.
--
Mark Mitchell
CodeSourcery, LLC
[EMAIL PROTECTED]
(916) 791-8304
correctly on the decimal format. I
definitely agree that translating into the binary format is likely to
result in various errors.
I don't have an opinion on exactly what method of modifying real.c would
be cleanest.
--
Mark Mitchell
CodeSourcery, LLC
[EMAIL PROTECTED]
(916) 791-8304
Robert Dewar wrote:
Mark Mitchell wrote:
What I would hope would work would be modifying real.c to (a) directly
suport the decimal format for storage, and (b) update the emulation of
floating-point operations to work correctly on the decimal format. I
definitely agree that translating into the
Robert Dewar wrote:
Mark Mitchell wrote:
I would expect that some decimal floating point values are not
precisely representable in the binary format.
OK, I agree that decimal floating-point needs its own format. But still
you can store the decimal mantissa and decimal exponent in binary format
message within a week,
it's fine to obsolete these for 4.0. You might consider leaving the
ports in 4.1 until after 4.0 has been out for a month or so. That will
give users a chance to speak up, if they really do want these old ports.
--
Mark Mitchell
CodeSourcery, LLC
[EMAIL PROTECTED]
(916) 791-8304
R says, this was changed by,
That's an optimization regression, of course...
My inclination is to simply add an additional check in the dwarf outputter,
verifying that the initializer is indeed an INT_CST.
Seems reasonable to me, but Jason and Jim know the DWARF code better.
--
Mark Mitchell
exported?
Let's do that when and if there is something that needs to use them.
Thanks,
--
Mark Mitchell
CodeSourcery, LLC
[EMAIL PROTECTED]
(916) 791-8304
se do not mark any new non-critical regressions with
the 4.0 target milestone; use 4.0.1 instead. There are about 70
non-critical regressions; it would of course be good to fix these, but
realistically we're not going to get them all.
--
Mark Mitchell
CodeSourcery, LLC
[EMAIL PROTECTED]
Truly Cri
d Joseph are the C front end maintainers, so you probably do. :-)
--
Mark Mitchell
CodeSourcery, LLC
[EMAIL PROTECTED]
(916) 791-8304
TYPE_NAME (TYPE_MAIN_VARIANT (origin)) is NULL, and it shouldn't be.
Or at least, that is what jason says.
Thanks, I've updated the PR to reflect that.
--
Mark Mitchell
CodeSourcery, LLC
[EMAIL PROTECTED]
(916) 791-8304
asbolute path; we want to make sure that
the data ends up there, not in the directory where the user happens to
run the program. So, I intend to disable these tests when $host !=
$target. Any objections, or better ideas?
--
Mark Mitchell
CodeSourcery, LLC
[EMAIL PROTECTED]
(916) 791-8304
n.
However the same problem is present in 3.4.x for the C++ compiler (but is not
a regression there) so I'd like you to make a decision for that branch too.
I'd prefer not to apply this for 3.4.
Thanks,
--
Mark Mitchell
CodeSourcery, LLC
[EMAIL PROTECTED]
(916) 791-8304
ow, without the assembler providing some kind of
special support. (I'm not actually sure what the assembler does with
the name; presumably puts it in debug information.)
--
Mark Mitchell
CodeSourcery, LLC
[EMAIL PROTECTED]
(916) 791-8304
Jason Merrill wrote:
On Thu, 24 Mar 2005 11:29:09 -0800, Mark Mitchell <[EMAIL PROTECTED]> wrote:
19317 C++ problems with temporary return values
This patch breaks Qt builds. One of my patches is implicated, but I
believe that the consensus is that this is an NRV bug. Jason made
s
(The first one fixed "make install",
but made "make check" worse.) So, I think this will get sorted shortly.
--
Mark Mitchell
CodeSourcery, LLC
[EMAIL PROTECTED]
(916) 791-8304
s, etc., should be disallowed.
Also, you need to say what happens in the situation where the user has
done "-O2 -fno-gcse" and the #pragma now says "-O2". Does that reenable
GCSE? (I think it should.)
--
Mark Mitchell
CodeSourcery, LLC
[EMAIL PROTECTED]
(916) 791-8304
Diego Novillo wrote:
On Fri, Apr 01, 2005 at 11:24:06AM -0800, Mark Mitchell wrote:
Dale Johannesen wrote:
So I guess question 1 is, Mark, do you feel negatively enough about this
feature to block its acceptance in mainline?
I'm not sure that I *could* block it, but, no, I don't
Richard Guenther wrote:
On Apr 1, 2005 9:36 PM, Mark Mitchell <[EMAIL PROTECTED]> wrote:
Diego Novillo wrote:
On Fri, Apr 01, 2005 at 11:24:06AM -0800, Mark Mitchell wrote:
Dale Johannesen wrote:
So I guess question 1 is, Mark, do you feel negatively enough about this
feature to blo
there are cases where it makes sense: you could ask that a
particular call be
inlined, or a particular loop be unrolled N times.
True. Consider my remark regarding insanity qualified to whole-function
optimizations. :-)
Thanks,
--
Mark Mitchell
CodeSourcery, LLC
[EMAIL PROTECTED]
(916) 791-8304
e, without refactoring their code, or losing all
optimization for a translation unit.
Finer-grained optimization control seems like something that should
indeed have to pass a relatively strong utility test.
--
Mark Mitchell
CodeSourcery, LLC
[EMAIL PROTECTED]
(916) 791-8304
elpful both to
me and to users who will build the release.
--
Mark Mitchell
CodeSourcery, LLC
[EMAIL PROTECTED]
(916) 791-8304
Truly Critical
--
19317 C++ problems with temporary return values
This patch breaks Qt builds. This is an NRV bug. Assigned to Merrill.
20126 Wrong memcmp c
Andrew Pinski wrote:
On Apr 4, 2005, at 7:26 PM, Mark Mitchell wrote:
20734 rejects valid pointer to member
Not yet assigned.
How is this less Critical?
This would breaks lots of code, it is template related too as it is not
rejected when not in templates.
Clearly this is a judgement call
id it wasn't as critical.
--
Mark Mitchell
CodeSourcery, LLC
[EMAIL PROTECTED]
(916) 791-8304
Andrew Pinski wrote:
On Apr 4, 2005, at 8:09 PM, Giovanni Bajo wrote:
Mark Mitchell <[EMAIL PROTECTED]> wrote:
I've attached a revised summary of the critical bugs open against
4.0. The good news is that there are fewer than last week.
Earlier today, Andrew Haley posted a small
I'll try to deal with the other two tomorrow.
Thanks!
--
Mark Mitchell
CodeSourcery, LLC
[EMAIL PROTECTED]
(916) 791-8304
PR, still a candidate fix, now
that Roger's change has been undone?
--
Mark Mitchell
CodeSourcery, LLC
[EMAIL PROTECTED]
(916) 791-8304
8 port. I
think the criteria should be the same as any other port.
However, I do think that it's late to be making this decision, and I
can't see any harm in delaying obsoletion until 4.0.1. That will give
potential maintainers a fair chance to step forward.
--
Mark Mitchell
Code
Joe Buck wrote:
Kazu Hirata wrote:
I would like to propose that the c4x port be obsoleted for 4.0.
...
The primary reason is that the port doesn't build.
On Tue, Apr 05, 2005 at 02:44:38PM -0700, Mark Mitchell wrote:
I'm unpersuaded by the arguments later in the thread that we should
401 - 500 of 1305 matches
Mail list logo
