This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: gcc 3.5 integration branch proposal

On 12 Jan, 2004, at 16.40, Steven Bosscher wrote:

On Tuesday 13 January 2004 01:23, Ziemowit Laski wrote:
On 12 Jan, 2004, at 16.18, Steven Bosscher wrote:
On Tuesday 13 January 2004 01:11, Ziemowit Laski wrote:
On 12 Jan, 2004, at 15.49, Mark Mitchell wrote:
Apple (and some other vendors, including CodeSourcery) is in the
position of doing its own release management and bug-fixing based on
various versions of GCC. Therefore, having high-quality FSF releases
may not make much of a difference to Apple; Apple doesn't use it
directly anyhow.

And the reason we don't is because the FSF keeps shooting down our patches. You just can't have it both ways.

And Apple keeps ignoring existing infrastructure. I understand the inconvenience for you, but you should _fix_ patches, not force in.

Please explain what you mean by 'infrastucture' and just how evil Apple
is ignoring it.

Not evil. I never said that. I wish I had an Apple. Ask Pinski, he knows ;-)

What I mean is that most patches I've seen so far were shot down on
technical grounds, on bad timing (stage3), for not using existing
functions to perform certain actions (feedback-based prefetching),
apparently patents (?) for hot/cold, etc.

 Also please explain how to fix patches that were shot
down _on principle_, such as my recent AltiVec work.

That's a language issue that I have no opinion on other than that I think it would have been wise if Motorola had consulted language lawyers, but that's the past. Others seem to have them. Do you think branching 3.4 will suddenly make these people change their mind?

The "language lawyer" argument is beside the point. AltiVec is just
one of many real-world, platform-specific C/C++ idiosyncracies out there.
In my opinion, one of the duties of the RM (currently Mark) is to devise
architectural solutions to accommodate such idiosyncracies in the same
source base. To the extent that he failed to do this, Apple
(and I suspect many others) wound up maintaining their own branches, and
obviously have a lesser and lesser incentive to care about the quality
of the mainline FSF product (which is where this discussion started).

Ziemowit Laski                 1 Infinite Loop, MS 301-2K
Mac OS X Compiler Group        Cupertino, CA USA  95014-2083
Apple Computer, Inc.           +1.408.974.6229  Fax .5477

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]