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
Richard Earnshaw wrote:
On Wed, 2005-04-06 at 00:30, Mark Mitchell wrote:
Joe Buck wrote:
But if it won't even build, then users should be warned.
I suppose -- but we have relatively many configurations that probably
won't build, at least if you start combining various options, and
change, but not instantly. If someone files a
PR, and assigns to me, I'll get to it at some not-too-distant point.
--
Mark Mitchell
CodeSourcery, LLC
[EMAIL PROTECTED]
(916) 791-8304
Please treat the GCC 4.0 branch as frozen as of this time. All
non-documentation changes now need my explicit approval.
I'll spin prerelease bits soon.
Thanks,
--
Mark Mitchell
CodeSourcery, LLC
[EMAIL PROTECTED]
(916) 791-8304
as long until
gfortran is compliant with Fortran 77."
I think you mean:
"We assume that distributors will provide access to g77 until gfortran
is compliant with Fortran 77."
The extra "as long" isn't actually grammatical. :-)
--
Mark Mitchell
CodeSourcery, LLC
[EMAIL PROTECTED]
(916) 791-8304
t, meaning that I might elect to ship
GCC 4.0 without receiving information about one of the primary or
secondary platforms. Therefore, if you're a user of one of these
platforms, it's in your best interest to put the release candidate
through its paces.
Thanks,
--
Mark Mitchell
Code
/criteria.html
for primary and secondary platforms.
sparc-sun-solaris2.9 is OK for C/C++/Objective-C/Ada/F95, except
FAIL: gcc.dg/builtin-apply4.c execution test
in 32-bit mode. Patch in testing.
We severely regressed for Java (22*2 new failures) 3 days ago.
Thanks!
--
Mark Mitchell
CodeSourcery
understand what's wrong here.
--
Mark Mitchell
CodeSourcery, LLC
[EMAIL PROTECTED]
(916) 791-8304
Jakub Jelinek wrote:
On Sun, Apr 10, 2005 at 03:05:17PM -0700, Mark Mitchell wrote:
The first GCC 4.0 candidate is available from:
/pub/gcc/prerelease-4.0.0-20050410/
on the usual gcc.gnu.org mirrors:
http://gcc.gnu.org/mirrors.html
I would like to know whether or not we have achieved the
ncurses (all
platforms)
PR/20929 triggers a miscompilation of Mozilla.
Those are all on the Wiki page as possible patches for an RC2.
Thanks,
--
Mark Mitchell
CodeSourcery, LLC
[EMAIL PROTECTED]
(916) 791-8304
java-patches/2005-q2/msg00088.html
Java library patch.
Thanks,
--
Mark Mitchell
CodeSourcery, LLC
[EMAIL PROTECTED]
(916) 791-8304
annoying.
I don't think that's so bad. Heck, it means we'll have less code.
Another option, is whether the type and allocation parameters of the
API calls are themselves parenthesized into a single macro argument,
as in
VEC_append ((tree,gc),v,t)
I don't think it's necssary
): Set
java.class.path to CLASSPATH if not already set.
Yes, Kawa builds with this patch. Thanks!
This is OK for 4.0 if approved for mainline.
--
Mark Mitchell
CodeSourcery, LLC
[EMAIL PROTECTED]
(916) 791-8304
Jason Merrill wrote:
On Tue, 12 Apr 2005 10:59:42 -0700, Mark Mitchell <[EMAIL PROTECTED]> wrote:
Sadly, it's become clear there's going to have to be a second release
candidate. In particular, there are some wrong-code bugs that are popping
up on real packages on primary p
not fully
done or settled on mainline. So, we'll fix it in 4.0.1, at the earliest.
--
Mark Mitchell
CodeSourcery, LLC
[EMAIL PROTECTED]
(916) 791-8304
o RC2 as well if possible. Is it OK to add the
patch to the wiki page?
Yes, please.
--
Mark Mitchell
CodeSourcery, LLC
[EMAIL PROTECTED]
(916) 791-8304
nch
(as a doc patch for which the branch is still open).
Thanks!
In checking for any similar references which should be fixed I noticed
that config/arm/libgcc-bpabi.ver defines a GCC_3.5 symbol version, but
it's probably rather too late to change that and may not be desirable to
change i
Steven Bosscher wrote:
On Tuesday 12 April 2005 19:59, Mark Mitchell wrote:
Therefore, I'm going to allow some of the queued patches into 4.0 at
this time. If your patch isn't on this list, but is here:
http://gcc.gnu.org/wiki/Last-Minute%20Requests%20for%204.0.0
I'm still consid
ssing that
you have an assembler with COMDAT and a linker without, or a broken
assembler.
Thanks,
--
Mark Mitchell
CodeSourcery, LLC
[EMAIL PROTECTED]
(916) 791-8304
a 68K maintainer.
--
Mark Mitchell
CodeSourcery, LLC
[EMAIL PROTECTED]
(916) 791-8304
0 RC2.
--
Mark Mitchell
CodeSourcery, LLC
[EMAIL PROTECTED]
(916) 791-8304
inters.
(lower_try_finally_switch): Likewise.
Ok.
Mark, ok for 4.0 as well?
Richard, what's your level of confidence here? I'd rather not break C++
or Java...
--
Mark Mitchell
CodeSourcery, LLC
[EMAIL PROTECTED]
(916) 791-8304
Richard Henderson wrote:
On Thu, Apr 14, 2005 at 05:26:15PM -0700, Mark Mitchell wrote:
Richard, what's your level of confidence here? I'd rather not break C++
or Java...
I think it's pretty safe.
OK, Alexandre, please install the patch.
--
Mark Mitchell
CodeSourcery, LLC
[EMAIL
4.0.0.
--
Mark Mitchell
CodeSourcery, LLC
[EMAIL PROTECTED]
(916) 791-8304
even for this bug, though. Instead, I'm
going to get 4.0.0 out the door, and move on to 4.0.1, sticking as close
to the announced schedule as possible.
So, there will be a 4.0.0 release within the next week.
--
Mark Mitchell
CodeSourcery, LLC
[EMAIL PROTECTED]
(916) 791-8304
out the door in the next few days; then on to 4.0.1...
--
Mark Mitchell
CodeSourcery, LLC
[EMAIL PROTECTED]
too. I'm not sure why it wasn't, but perhaps
your "OK for 4.0.0" didn't specify mainline and Paolo was being
conservative. I think we should fix it there also.
Yes, indeed. The patch is certainly OK for mainline as well.
--
Mark Mitchell
CodeSourcery, LLC
[EMAIL PROTECTED]
(916) 791-8304
Richard Sandiford wrote:
Results for mips-elf are here:
http://gcc.gnu.org/ml/gcc-testresults/2005-04/msg01331.html
and look good. No regressions.
Thanks; added to the Wiki.
--
Mark Mitchell
CodeSourcery, LLC
[EMAIL PROTECTED]
(916) 791-8304
, but I do think any fix will be too
intrusive for 4.0.0. I'd suggest that we try to fix it for 4.0.1.
Thanks,
--
Mark Mitchell
CodeSourcery, LLC
[EMAIL PROTECTED]
(916) 791-8304
Andrew Haley wrote:
Geoffrey Keating writes:
> Mark Mitchell <[EMAIL PROTECTED]> writes:
>
> > RC2 is available here:
> >
> > ftp://gcc.gnu.org/pub/gcc/prerelease-4.0.0-20050417/
> >
> > As before, I'd very much appreciate it if p
Geoffrey Keating wrote:
Mark Mitchell <[EMAIL PROTECTED]> writes:
RC2 is available here:
ftp://gcc.gnu.org/pub/gcc/prerelease-4.0.0-20050417/
As before, I'd very much appreciate it if people would test these bits
on primary and secondary platforms, post test results with the
contrib/t
Eric Botcazou wrote:
SPARC/Solaris is OK:
Thanks; I've added your information to the Wiki.
--
Mark Mitchell
CodeSourcery, LLC
[EMAIL PROTECTED]
(916) 791-8304
. Based on the follow-up, and the fact that Java is not
release-critical, this is not a showstopper. FWIW, we've seen similar
problems on HP-UX; there's confusion about which paths will be searched
by the build compiler vis a vis the compiler we're building.
--
Mark Mitchell
Co
ss.c for remove_zero_width_bitfields. (Spelling might be a
little off.)
--
Mark Mitchell
CodeSourcery, LLC
[EMAIL PROTECTED]
(916) 791-8304
Joe Buck wrote:
On Mon, Apr 18, 2005 at 07:44:03AM -0700, Mark Mitchell wrote:
RC2 is available here:
ftp://gcc.gnu.org/pub/gcc/prerelease-4.0.0-20050417/
x86_64-unknown-linux-gnu results (for RHEL v3) are at
http://gcc.gnu.org/ml/gcc-testresults/2005-04/msg01333.html
The failures are almost all
Joseph S. Myers wrote:
Results for hppa2.0w-hp-hpux11.11, no regressions:
http://gcc.gnu.org/ml/gcc-testresults/2005-04/msg01379.html
Thanks; posted on the Wiki.
--
Mark Mitchell
CodeSourcery, LLC
[EMAIL PROTECTED]
(916) 791-8304
is a fine value to represent "unknown" -- the fact
that it's likely to cause crashes is probably a feature, in that any
parts of the compiler that go trying to use the field will probably be
found more quickly. So, your original patch is fine for mainline. It's
also OK for
The GCC 4.0 branch is now open for regression fixes only, under the
usual release branch rules.
--
Mark Mitchell
CodeSourcery, LLC
[EMAIL PROTECTED]
(916) 791-8304
/changes.html
This release is available from the FTP servers listed here:
http://www.gnu.org/order/ftp.html
The release is in the gcc/gcc-4.0.0 subdirectory.
As usual, a vast number of people contributed to this release -- far too
many to thank by name!
--
Mark Mitchell
CodeSourcery, LLC
[EMAIL
Toon Moene wrote:
Mark Mitchell wrote:
The GCC 4.0 branch is now open for regression fixes only, under the
usual release branch rules.
I presume this means that we (The Fortran Illuminati) can fix any bug in
the gfortran frontend, as we don't have any regressions yet (at least
not ag
ay
enough to be useful in some circumstances.
--
Mark Mitchell
CodeSourcery, LLC
[EMAIL PROTECTED]
(916) 791-8304
ful -- except for testing GCC. I'd build GCC on
some fast workstation, even if I eventually wanted it to run native on
the target.
--
Mark Mitchell
CodeSourcery, LLC
[EMAIL PROTECTED]
(916) 791-8304
s
look like? In the meantime, I'm trying to plan 3.4.4
--
Mark Mitchell
CodeSourcery, LLC
[EMAIL PROTECTED]
(916) 791-8304
itical C++ bugs that I fixed, and
backport the patches. I'd encourage others to do the same, and
to look in particular at wrong-code problems that affect your favorite
platforms.
--
Mark Mitchell
CodeSourcery, LLC
[EMAIL PROTECTED]
e case-by-case judgements. But, I do think
that preference should be given to those projects that were previously
announced, and that if your changes seem too invasive, it might be
reasonable to hold them for 4.2. We shall have to see.
--
Mark Mitchell
CodeSourcery, LLC
[EMAIL PROTECTED]
(916) 791-8304
doesn't seem so attractive.
--
Mark Mitchell
CodeSourcery, LLC
[EMAIL PROTECTED]
(916) 791-8304
; it might make sense to
use WONTFIX if the bug was introduced on the 3.4 branch and never
present elsewhere.
--
Mark Mitchell
CodeSourcery, LLC
[EMAIL PROTECTED]
(916) 791-8304
Richard Guenther wrote:
On 4/29/05, Mark Mitchell <[EMAIL PROTECTED]> wrote:
Joseph S. Myers wrote:
What's the position on closing 3.4 regression bugs which are fixed in 4.0
and where it doesn't seem worthwhile to attempt to backport a fix?
They should be closed as FIXED, with a no
201 - 300 of 1433 matches
Mail list logo
