all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: David Kastrup <dak@gnu.org>
To: esr@snark.thyrsus.com (Eric S. Raymond)
Cc: emacs-devel@gnu.org
Subject: Re: Defending GCC considered futile
Date: Sat, 07 Feb 2015 22:24:43 +0100	[thread overview]
Message-ID: <87bnl5wh2c.fsf@fencepost.gnu.org> (raw)
In-Reply-To: <20150207202952.1042BC00A6@snark.thyrsus.com> (Eric S. Raymond's message of "Sat, 7 Feb 2015 15:29:52 -0500 (EST)")

esr@snark.thyrsus.com (Eric S. Raymond) writes:

> Speking as the original author of GUD, I'm in favor of it supporting
> LLVM and everything else imaginable.  But I hadn't been planning to
> weigh in on the question until I realize that Richard and everyone
> else may be carrying around a false premise: namely, that GCC's 
> dominance in its functional category *can* be preserved.

I don't see that this premise comes into play here.  If it did, there
would be no need to disadvantage it in its cooperation with Emacs.

Sadly, I think that the negative impact on both Emacs and GCC by
blocking both Emacs/anycompiler and anyIDE/GCC integration is larger
than what we can hope to achieve regarding negative impact on LLVM.

> I'm pretty sure this is not true.  If the clang/LLVM people decide
> they want to eat GCC's lunch, they *will* do it.

As far as I can tell, they are already doing it.  I consider it fully
understandable that we don't want to be serving at their table while
they are doing so.  But if the price for not doing that is that we stop
serving ourselves, it is too high.

> Already my own experiments suggest that LLVM is a superior compiler,
> by every metric I know of, at least in deployments that don't require
> bug-for-bug compatibility with GCC.

As far as I know, the metric "runtime performance" is not yet taken.
Which I do consider kind of surprising.  Nevertheless, the exact
performance never was our main metric.  Intel's proprietary compilers
tended to significantly outclass GCC on their processors.  That has not
stopped GCC from being worked on and deployed.

> I don't have to completely agree with FSF's strategic goals to advise
> that its planning needs to take this into account.  The probable near
> future obsolescence of GCC means the positive positioning of Emacs is
> *more* important.  The absolute last thing you want to do is make it
> less attractive to clang/LLVM users.

We have never let our opponents dictate our goals.  But the absolute
last thing we want to do is make GNU less attractive to Emacs/GCC users.
And the comparably ineffectual attempts to lash out at LLVM have a worse
impact for us than for LLVM.

And that's just stupid.  At least let our opponents work themselves for
any advantage they want to gain over us.

-- 
David Kastrup



  reply	other threads:[~2015-02-07 21:24 UTC|newest]

Thread overview: 45+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-02-07 20:29 Defending GCC considered futile Eric S. Raymond
2015-02-07 21:24 ` David Kastrup [this message]
2015-02-09  0:04   ` Richard Stallman
2015-02-07 22:30 ` Florian Weimer
2015-02-08 14:12   ` Stefan Monnier
2015-02-09 19:39     ` Florian Weimer
2015-02-09 22:04   ` Perry E. Metzger
2015-02-09  0:04 ` Richard Stallman
2015-02-09  4:13   ` Stefan Monnier
2015-02-09  5:50   ` Stephen J. Turnbull
2015-02-09 22:06     ` Richard Stallman
2015-02-09 22:24       ` Perry E. Metzger
2015-02-10  3:37         ` Eli Zaretskii
2015-02-10  8:30           ` Daniel Colascione
2015-02-10  8:47             ` Helmut Eller
2015-02-10 15:58               ` Eli Zaretskii
2015-02-10 15:57             ` Eli Zaretskii
2015-02-10 18:19               ` Daniel Colascione
2015-02-10 18:41                 ` David Kastrup
2015-02-10 19:27                   ` Eli Zaretskii
2015-02-10 19:23                 ` Eli Zaretskii
2015-02-10 20:05                   ` David Kastrup
2015-02-10 23:14                   ` Stefan Monnier
2015-02-11  3:46                     ` Eli Zaretskii
2015-02-11 23:11                     ` Richard Stallman
2015-02-10 22:48         ` Richard Stallman
2015-02-11  2:08           ` John Yates
2015-02-11 15:42           ` Perry E. Metzger
2015-02-11 16:14             ` Eli Zaretskii
2015-02-11 16:29               ` Perry E. Metzger
2015-02-11 16:44                 ` Eli Zaretskii
2015-02-11 16:54                   ` Eli Zaretskii
2015-02-11 20:50                     ` Perry E. Metzger
2015-02-12  3:37                       ` Eli Zaretskii
2015-02-12  3:54                         ` Perry E. Metzger
2015-02-11 19:14                 ` Florian Weimer
2015-02-11 19:19                 ` Stefan Monnier
2015-02-11 23:13                 ` Richard Stallman
2015-02-12  1:48               ` raman
2015-02-11 23:13             ` Richard Stallman
2015-02-09  7:41   ` Helmut Eller
2015-02-09 19:30   ` Florian Weimer
2015-02-09 22:41     ` Perry E. Metzger
2015-02-10 22:46     ` Richard Stallman
2015-02-09 22:19   ` Perry E. Metzger

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87bnl5wh2c.fsf@fencepost.gnu.org \
    --to=dak@gnu.org \
    --cc=emacs-devel@gnu.org \
    --cc=esr@snark.thyrsus.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.