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
Roger Sayle wrote:
Hopefully everyone should find this satisfactory. Mark, are you
OK with this single source file exception/tweak to the current
plan/rules? I'd expect few, if any, of the development branches
contain any changes to fold, and they're welcome to maintain those
chang
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
Giovanni Bajo wrote:
Mark, how does this port fit in the 4.1 plan? Since it is totally
self-contained (it does not modify anything in GCC proper but the usual
configuration additions), I think it could be merged any time, assuming a
global maintainer can spend some time on a review. To be fair
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
Kazu Hirata wrote:
Hi,
First off, Mark, if you think this stuff is too late for 4.0, I'll
postpone this to 4.1. Please note that all we have to do is add a few
lines to config.gcc as far as printing the "obsolete" message is
concerned.
I think that if you get no objections to your
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
ew
These are PRs (also included in the lists above in some cases) which
have patches posted, and need review.
* Already Fixed
These are PRs that have been approved for 4.0, but aren't applied yet.
I'm still shooting for an April 15th release. As I indicated
previously, plea
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
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 feel that negatively.
I think that a #pragma (or attribute) that affects only optimization
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
Kelley Cook wrote:
Mark,
I nominate PR libgcj/20155 for a "less critical" bug since it is
actually a bootstrap regression on numerous platforms albeit easily
worked around with a configure --disable-libgcj.
Yes, it would be good to get that fixed.
Kelly, is your patch, attached to the
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
e:/,file:/usr/],
parent=gnu.gcj.runtime.ExtensionClassLoader{urls=[], parent=null}}
So on my system (Debian GNU/Linux testing/x86) setting CLASSPATH seems
to work as expected. (Note that /random gets dropped since it doesn't
exist.)
Cheers,
Mark
signature.asc
Description: This is a digitally signed message part
Aha. Thanks. As a workaround you can use the GCJ_PROPERTIES environment
variable for now:
GCJ_PROPERTIES='java.class.path=../..' ./CL
gnu.gcj.runtime.SystemClassLoader{urls=[file:../../],
parent=gnu.gcj.runtime.ExtensionClassLoader{urls=[], parent=null}}
I am looking for a real solution.
C
Hi Per,
On Tue, 2005-04-12 at 20:45 +0200, Mark Wielaard wrote:
> I am looking for a real solution.
Does the following work for you?
2005-04-02 Mark Wielaard <[EMAIL PROTECTED]>
* java/lang/natRuntime.cc (insertSystemProperties): Set
java.class.path to CLASSPA
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
Per Bothner wrote:
Mark Wielaard wrote:
Hi Per,
On Tue, 2005-04-12 at 20:45 +0200, Mark Wielaard wrote:
I am looking for a real solution.
Does the following work for you?
2005-04-02 Mark Wielaard <[EMAIL PROTECTED]>
* java/lang/natRuntime.cc (insertSystemProperties
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
Richard Sandiford wrote:
Richard Sandiford <[EMAIL PROTECTED]> writes:
Mark,
I tried running some MIPS16 tests against RC1 and found a regression
from 3.4. The problem is the following hack in mips.h:
[...]
The patch reduces the number of mips64 {-mips16}{-EL,-EB} C failures
from 203 to 5
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
Richard Sandiford wrote:
Mark,
I tried running some MIPS16 tests against RC1 and found a regression
from 3.4. The problem is the following hack in mips.h:
/* When generating mips16 code we want to put the jump table in
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
201 - 300 of 1839 matches
Mail list logo
