me wheels. All the more reason to
get this into libiberty... :-)
Thanks,
--
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713
Here is a sample program which does the right thing (no spurious console
windows, all output visible) when run either from a console or from a
console-free environment, such as a Cygwin xterm. This is the code
we'll be working into libiberty -- unless someone has a better solution!
--
Mark Mitchell wrote:
> What cygcheck output would be helpful? I've never run cygcheck until
> just now, and it seems to have lots of options.
By the way, I don't see any reason to suspect that there's a Cygwin bug.
The situation is:
1. A Cygwin xterm does not have an a
- as
> an attachment, please.
What cygcheck output would be helpful? I've never run cygcheck until
just now, and it seems to have lots of options.
Thanks,
--
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713
term issue per se. And, even if this
considered a Cygwin X client bug, avoiding the bug seems clearly desirable.
CodeSourcery will fix this on our branches, and contribute the patch;
hopefully we can work something out that will make the libiberty
maintainers happy.
--
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713
f "current changes"
> for 4.1.0 on the main page?
Now corrected, thanks.
--
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713
/gcc-4.0.3, (there is no such page). That
> link should be http://gcc.gnu.org/gcc-4.0 instead.
Fixed with the obvious patch.
Thanks!
--
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713
-C compiler as objcp depends on c++ also?
Yes, but so what? :-)
Creating these separate modules seems somewhat pointless given the core
is 80% of the total. Why not simplify things a bit and just package it
all up together?
--
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713
-4.2-20060304.tar.bz2 = 3606941
>
> I'd really suggest to make this part of gcc-objc instead of adding
> another one.
Definitely.
--
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713
The GCC 4.0 branch is now open, under the usual release-branch rules.
However, I do not plan to make any further releases from the 4.0
branch.
Thanks,
--
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713
, please do not send
them directly to me. Instead, please http://gcc.gnu.org/ for
information about getting help and filing problem reports.
As usual, a vast number of people contributed to this release -- far
too many to thank by name!
--
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385
s:
Cygwin Xterm
parent spawn: Pops up DOS window.
parent nostd: No output from child.
parent std: Works.
DOS Console
===
parent spawn: Works.
parent nostd: No output from child.
parent std: No output from child.
--
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-33
Ross Ridge wrote:
> Mark Mitchell wrote:
>> The new pex-win32.c code doesn't operate correctly when used for
>> MinGW-hosted tools invoked from a Cygwin window. In particular, process
>> creation ("gcc" invoking "as", say) results in a DOS console
t linking with -mwindows would work, and, indeed that
avoids the DOS windows popping up in Cygwin -- but they you get no
output at all under Windows.
I guess I have two questions: (a) do you feel like fixing this, and (b)
if not, do you have any objection to using CreateProcess?
--
Mark Mitchell
I am not aware of any showstoppers for the 4.0.3 release.
Therefore, I plan to spin the release tomorrow evening, GMT - 8. Speak
now or forever hold your peace! :-)
--
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713
t; on x86 cross sh4-unknown-linux-gnu
> looks fine.
If these patches show an improvement on SH4, please go ahead and check
them in. Please inform me of the status ASAP.
Thanks,
--
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713
tual
prerelease tarballs on the FTP site. The modified release script has
not been checked in, but will be shortly.
Assuming that there are no major problems, I expect the final release in
the middle part of next work.
Thanks,
--
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713
Roman Belenov wrote:
> David Edelsohn <[EMAIL PROTECTED]> writes:
>
>> Upgrading GNU tar to 1.15.1 fixed the problem for me.
>
> So what is the actual requirement - 1.14 or "1.14 or above" ?
The latter.
--
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713
riendly about my patch, but I
can believe there's a problem in there somewhere. I never run "make
install" in parallel because, frankly, it's *never* worked for me; I
just thought all of our makefiles were generally broken for parallel
installation. :-(
--
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713
ps, for all time, users have been expected to specify
their target CPU in order to get good performance. It's swell that GCC
4.2 will work better by default on IA32, but that's not a compelling
argument for a backport.
--
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713
ackported patch is the cause.
The first step is to address regressions on the mainline. I have not
myself verified the claim, but there has been a suggestion that there is
at least one open regression due to the patch. If there are any known
regressions from the patch, it's certainly not eligible
e
adding value in precisely such ways!) but it's better to be safe than
sorry, and I didn't have the resources to verify exactly which versions
might or might not work.
--
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713
ot a thick skin, and I feel omfortable
exercising my own non-algorithmic discretion to do what I believe is the
right thing. But, I will also be sensitive to the developer community's
desire for predictability of decision-making.
--
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713
The GCC 4.1 branch is now open, under the usual branch rules: fixes for
regressions only.
Remember: the GCC 4.0 branch will freeze at midnight tonight, GMT-8, in
preparation for GCC 4.0.3.
Thanks,
--
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713
René Rebe wrote:
> As expected the headers are in the correct location now.
Good. Have you filed a bug in Bugzilla about this issue? If not, would
you care to do so? To do so, please visit gcc.gnu.org, and look for the
link on the left side of the page.
Thanks,
--
Mark Mitch
As usual, a vast number of people contributed to this release -- far
too many to thank by name!
--
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713
le.am is
incorrect; users of TL_AC_GXX_INCLUDE_DIR must define libsubdir.
--
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713
René Rebe wrote:
> Hi,
>
> On Tuesday 28 February 2006 19:50, Mark Mitchell wrote:
>> René Rebe wrote:
>>> Hi all,
>>>
>>> in my tests gcc 4.1.0-RC{1,2} install headers into a root (/) include
>>> directory:
>> Are you sure? The lo
der switches, but I have verified that the headers end up in
$prefix/include/c++ for me. The SSP patch I applied yesterday will have
no affect on this situation, as it applied only to the libssp headers.
Thanks,
--
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713
Mark Mitchell wrote:
> Joseph thinks these should go in $libsubdir; I'm going to try that now.
With much help from Daniel and Joseph, I have a patch for this problem,
which I am now testing.
This will be the final patch for GCC 4.1.0. I plan to work through the
release checklist toni
Mark Mitchell wrote:
> My current expectation is that I will apply your patch, test locally,
> but not produce an RC3.
I built a native compiler with the patch. I
The ssp include files ended up in $prefix/lib/include/ssp. There are no
other files in $prefix/lib/include. The C++ header
want to be able to stay close to the 4.1 release date.
So, as of midnight Wednesday, GMT - 8, the 4.0.x branch will be frozen.
Please do not apply patches for problems not fixed in 4.1.0. Then,
I'll build RC1 on Thursday.
Thanks,
--
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713
week.
The other regressions have been retargeted at GCC 4.1.1. They will not
be fixed in GCC 4.1.0.
--
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713
nal include dir
> ($libdir/gcc/$target_alias/$version/include)
I will review this issue before the final release.
My current expectation is that I will apply your patch, test locally,
but not produce an RC3.
Thanks,
--
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713
ical approach is that it might let us start incoporating the leaner
trees into the rest of our IL; we'd start having the idea of
trees-without-a-TREE_CHAIN.
--
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713
rings. Assuming
that no disasters are reported, I will make the final release early next
week.
--
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713
Paolo Bonzini wrote:
> Mark Mitchell wrote:
>> I will spin GCC 4.1 RC2 tonight.
>>
>> The only patch I plan to apply, relative to current sources, is Paolo
>> Bonzini's Ada patch.
>
> ... which is revision 108058. I gather that you want to apply it yours
I will spin GCC 4.1 RC2 tonight.
The only patch I plan to apply, relative to current sources, is Paolo
Bonzini's Ada patch.
GCC 4.1 RC2 will become the final GCC 4.1.0 release within a few days,
unless disaster occurs.
Thanks,
--
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331
Paolo Bonzini wrote:
> Yes, http://gcc.gnu.org/ml/gcc-patches/2005-12/msg00342.html was not
> applied on the branch. It only affects Ada so it shuld be safe.
Yes. Do you have a revision number handy?
Thanks,
--
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713
already submitted changes, spin RC2, and declare that
all-but-final. However, I am not fully committed to this plan; I might
still decide that RC1 is good enough.
Therefore, if you have any strong feelings on this topic, now would be a
good time to speak up!
Thanks,
--
Mark Mitchell
CodeSourcery
t; }
you can happily assign "5" to this enum. The C++ front end correctly
sets TYPE_MAX_VALUE in this case.
I'm not sure what the situation is in C.
--
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713
that the
object actually have that value if the program has invoked undefined
behavior. So, if you have an 5-bit type, stored in a byte, and you
manage to get 255 in that byte, and you read the value, you might see
255 at runtime -- but only because your program was busted anyhow.
--
Mark
,
file a bug in Bugzilla, and add me to the CC: list.
Enjoy!
--
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713
Matthias Klose wrote:
> Mark Mitchell writes:
>> and the 3.4.x branch is official dead at this point.
>
> No, see http://gcc.gnu.org/ml/gcc/2005-12/msg00189.html
My mistake; thanks for the pointer.
However, that doesn't change the general thrust of my mail; the only
issue
with the
proposed plan is that it means that more scarce resources (RM, testers,
etc.) are required over a shorter period, rather than being spread
across time.
Thoughts?
--
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713
mitters to apply to other branches.
--
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713
I plan to spin RC1 on Sunday morning, California time.
Therefore, if you have outstanding patches, already approved for 4.1,
please check them in Saturday.
Thanks,
--
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713
Olivier Hainque wrote:
>>Mark, is it ok for Olivier to apply the patch mentioned here on
>>4.1?
>
>> http://gcc.gnu.org/ml/gcc/2006-02/msg00251.html
Yes, thanks.
--
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713
PROTECTED] That's where discussion and patches will appear.
--
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713
ae as much time as I'd hoped. My expectation is
that RC1 will be available over the weekend.
Thanks,
--
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713
Aldy Hernandez wrote:
> Do we keep a hash of functions that have been written out somewhere?
Not to my knowledge.
> I'd hate to walk the entire hash table each time we write out a function
> searching for the types that function uses.
Agreed.
--
Mark Mitchell
CodeSourcery
[E
6-02/msg00933.html
I see Diego has now reviewed it.
We'll proceed with the freeze as previously announced, at midnight,
tonight, here in California.
Thanks,
--
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713
roval; please attach patches to PRs, and Cc: to me. Hopefully, the
two P1s will be fixed tomorrow, and I can make a release candidate as
early as Wednesday evening.
Thanks,
--
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713
ge than the per-function vectors. Then,
you'd have to walk the entire hash table, writing out each type for
which at least one of the associated functions was written out,
including being inlined into another function.
--
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713
owever, whether or not that
proposal will be implemented is still an open question, dependent on
demand, technological evaluation relative to other approaches for
link-time optimization (notably, LLVM), and available resources.
--
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713
various outstanding issues.
Thanks for being patient.
--
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713
Geoffrey Keating wrote:
> Mark Mitchell <[EMAIL PROTECTED]> writes:
>
>
>>However, the PowerPC GNU/Linux community seems to want this feature very
>>badly, and has suggested that failure to incorporate these patches in
>>GCC 4.1 would be very bad. My
fway in between is just confusing.
Let's make it happen.
I'll help review patches in this direction, to the extent I can do so
competently. However, I'll of course defer to the build system
maintainers -- either on particular patches, or in general, if they
determine I'm incompetent.
--
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713
Howard Hinnant wrote:
> Let me rephrase: It seems to me that fvisibility-inlines-hidden should
> apply to all inline functions (both member and non-member). Does
> anyone have an argument for why it should not be this way?
I certainly do not.
--
Mark Mitchell
CodeSourcery
[EMAIL
again. Each platform will either change by the first
> 2.4 release, or it will not change until the next ABI-changing release
> (presumably 2.5, and not especially soon).
Thanks for the clarification and explanation.
--
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713
Mark Mitchell wrote:
>>it misses the point that many important resources in GCC are being used in
>>fixing and testing this new feature, instead of putting GCC in shape for the
>>release. So the release has been already delayed because of this, and will be
>>even more
cision, criticize it, or ask the SC to
intervene.
--
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713
or quite some time. If there were significant
objections, they should have been made immediately, and, if necessary,
the SC involved at that point.
Jakub has already indicated that the libstdc++ changes will not go on
the 4.1 branch. I, too, believe those changes are too risky.
--
Mark Mitchell
now-or-never change in GLIBC.)
Given that the GLIBC with the support is fully backwards-compatible with
older GLIBCs, it seems that it would be possible to enable the support
later on the GLIBC 2.4 branch, when compilers that can support the
feature become available.
Thanks,
--
Mark Mitchell
Cod
er, and we certainly don't
assume a GPL problem because GCC on Solaris invokes the Solaris assembler!
Of course, we should definitely get the SC's buy in before making such a
change of this magnitude.
--
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713
Joern RENNECKE wrote:
> OK to backport to 4.1 if bootstrap on i686-pc-linux-gnu succeeds?
Yes.
--
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713
for previously registered Stage 1 projects that have not yet been
comitted for whatever reason.
--
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713
at that point until our backs are
against the wall right before a release.
--
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713
Upon reading the thread carefully, so do I.
Would anyone care to prepare such a patch?
Thanks,
--
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713
Jan 2006 16:55:54 - GOMP - Diego Novillo
>
> So I am requesting that we go through a 48 hour period starting Monday
> (as the weekends are usually quiet for patch committing) for a stage 3
> type regression only/bug fixes.
I'm inclined to agree. Any objections?
--
Mark Mit
Joe Buck wrote:
> It is PR 25892.
Thanks,
--
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713
Richard Henderson wrote:
> On Fri, Jan 20, 2006 at 01:26:51PM -0800, Mark Mitchell wrote:
>
>>I guess a secondary question is: is the workaround sufficiently useful
>>in many of the problematic cases and sufficiently non-harmful in other
>>cases as to merit inclusion, gi
f the problematic cases and sufficiently non-harmful in other
cases as to merit inclusion, given that we don't have a better solution?
--
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713
Richard Guenther wrote:
>>patch needs a paragraph-long comment explaining what the problem is and
>>how this approach solves it.
>
> Ok, I'll try to come up with an explanation.
Thanks!
--
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713
Steven Bosscher wrote:
> On Friday 20 January 2006 18:21, Mark Mitchell wrote:
>
>>Richard Guenther wrote:
>>
>>>A patch was also posted based on ideas in the audit trail. It's third
>>>incarnation at
>>>http://gcc.gnu.org/ml/gcc-patches/2006-
In general, I think the
patch needs a paragraph-long comment explaining what the problem is and
how this approach solves it.
Thanks,
--
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713
nce you seem to have a handle on the outcome of the discussion, would
you please create a Bugzilla entry for this, targeted at 4.1, explaining
what it is the SC agreed to do? Otherwise, I'm certain to forget about
this issue...
Thanks,
--
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713
ments. Therefore, while we will
enter Stage 1 as scheduled, we'll permit those projects already on the
4.1 projects list to be submitted and/or reviewed during Stage 2.
However, because we will be in Stage 2, other patches of similar
magnitude will need to wait until until GCC 4.3.
--
Mar
hat
4.1.0 is in reasonably good shape.
After 4.0.3 has been released, I do not plan to make any more releases
from the 4.0 branch, although (as with previous branches) another RM may
step in to do that.
--
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713
n about a week of RC1; if there are problems reported for
RC1, then we'll iterate.
Therefore, if there are other regressions which you would like to see
fixed for 4.1, now is the time!
--
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713
s you say, it's just
a recipe for trouble to be doing any code generation at all when errors
have ocurred. At worst, we miss some diagnostics -- which we will then
issue when the user recompiles after fixing whatever errors they had in
the original code.
--
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713
k we should do the complete patch. I know it's going to be
tedious to fix the uses of SSA_NAME_VAR, but I think that would be much
cleaner, and will also avoid problems where we have a DECL (GVAR_DECL)
that is missing fields that other parts of the compiler might expect a
DECL to have.
--
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713
o that f will construct the
value directly into s.
--
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713
he
cleanups should not be run. However, if it were just "b ? TARGET_EXPR :
something", then the cleanups should be run; that would be an orphaned use.
--
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713
E (decl)) != REFERENCE_TYPE);
>
> where one wanted to check that the decl is not a reference type?
Yes.
--
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713
up, and to look at this bug. Thanks for the analysis
regarding the cause; that should help.
--
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713
Ben --
The GCC SC has appointed you as a maintainer of libdecnumber.
Please add yourself to MAINTAINERS.
Thanks,
--
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713
ecl. Was this
> change intended?
I'm not sure; please send me preprocessed source, and I will look into
it. It's certainly possible that those changes broke something.
What do you think the above code is supposed to mean? Are you declaring
a constructor for CflFunctor, or an unname
the load.
My guess at a solution is that when A (with alias set S_a) and B (with
alias set S_b) are given the same stack slot, we should create a new
alias set S_c which is a subset of both S_a and S_b, and give the
combined stack slot that aliase set.
--
Mark Mitchell
CodeSourcery, LLC
[EMAIL P
begin work on that release shortly. The GCC 4.0.x branch is
stable, so it's relatively easy to make a release.
Thanks,
--
Mark Mitchell
CodeSourcery, LLC
[EMAIL PROTECTED]
(650) 331-3385 x713
ntention is to create the first 4.1 release candidate when (a) we've
eliminated the P1s, and (b) it's at least January 19th.
Thanks,
--
Mark Mitchell
CodeSourcery, LLC
[EMAIL PROTECTED]
(650) 331-3385 x713
a few days. So, any disagreements?
Thanks,
--
Mark Mitchell
CodeSourcery, LLC
[EMAIL PROTECTED]
(650) 331-3385 x713
Nathan Sidwell wrote:
> Mark Mitchell wrote:
>
>> struct Foo { void operator=(Foo const &);};
>> struct Baz __attribute__((packed))
>> {
>>char c;
>>Foo m;
>> }
>>
>> void Bar (Baz *ptr)
>> {
>>ptr->m = s
s code to be invalid, and
either issue a diagnostic, or at least be considered undefined behavior.
(In my idea world, ptr->m has type "packed Foo" in this case, and it's
not permissible to binding a "packed Foo" to a "Foo const&", so this
would be invalid, but I could live with undefined.)
--
Mark Mitchell
CodeSourcery, LLC
[EMAIL PROTECTED]
(916) 791-8304
The SC has approved Aldy's nomination of Nathan as a co-maintainer for
the Morpho Technologies port.
Nathan, please updated MAINTAINERS.
Thanks,
--
Mark Mitchell
CodeSourcery, LLC
[EMAIL PROTECTED]
(916) 791-8304
nction? As Gaby says, perhaps we could mark the function
inline, if you're worried about performance?
Thanks,
--
Mark Mitchell
CodeSourcery, LLC
[EMAIL PROTECTED]
(916) 791-8304
hared was not.
That's why I think we should be talking about the effort required to
implement the approaches before us, and the payoffs from where those
approaches lead us, rather than generalities about design. (And, if you
really want a prize, you can put "risk-adjusted" in fron
and of itself a problem
-- but I'm happy to switch to LLVM, if we think that it's easier to make
LLVM do what we want than it is to make Tree-SSA do what we want.
--
Mark Mitchell
CodeSourcery, LLC
[EMAIL PROTECTED]
(916) 791-8304
r as I know?)
funded by any companies.
You're correct that LTO, were it to proceed, might make this a killer
issue, and then we'd have to attack it -- and so that work should go on
the cost list for LTO. You're also correct that some of this work would
also benefit GCC as a whole, in
but that I do agree that one wants the right
representation for the job, and that Tree-SSA is not the best
representation for optimization. So, if Tree-SSA is not replaced, it
will almost certainly need to evolve.
--
Mark Mitchell
CodeSourcery, LLC
[EMAIL PROTECTED]
(916) 791-8304
901 - 1000 of 1433 matches
Mail list logo