Defending GCC considered futile

Defending GCC considered futile

[Eric S. Raymond]

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'm pretty sure this is not true.  If the clang/LLVM people decide
they want to eat GCC's lunch, they *will* do it.  The reason has
nothing to do with any philosophical issue but merely the fact that
compiler technology has advanced significantly in ways that GCC is not
well positioned to exploit.  The clang/LLVM people have both a
clean-sheet technology advantage and Apple's money to fund a
high-quality implementation with; FSF cannot match either.

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.  If GCC were to vanish from
existence tomorrow I'm not sure I myself would be even seriously
inconvenienced.  CC=clang in one dotfile; problem solved, done.

Obsolescence happens; this is nobody's fault.  It will happen to
clang/LLVM someday, too, but today is not that day.

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.

TL;DR: You can't beat clang. Join it.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

Power concedes nothing without a demand. It never did, and it never will.
Find out just what people will submit to, and you have found out the exact
amount of injustice and wrong which will be imposed upon them; and these will
continue until they are resisted with either words or blows, or with both.
The limits of tyrants are prescribed by the endurance of those whom they
oppress.	-- Frederick Douglass, August 4, 1857

Re: Defending GCC considered futile

[David Kastrup]

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

Re: Defending GCC considered futile

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > 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.

GCC is a different issue -- as far as I know, this question does not
involve GCC in any way.  It may relate to GDB.

If we substitute GDB for GCC in what you wrote, your statement makes
sense.  And it might be correct.  But I want to see what's going on here
rather than assume.

-- 
Dr Richard Stallman
President, Free Software Foundation
51 Franklin St
Boston MA 02110
USA
www.fsf.org  www.gnu.org
Skype: No way! See stallman.org/skype.html.

Re: Defending GCC considered futile

[Florian Weimer]

* Eric S. Raymond:

> 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.  The reason has
> nothing to do with any philosophical issue but merely the fact that
> compiler technology has advanced significantly in ways that GCC is not
> well positioned to exploit.  The clang/LLVM people have both a
> clean-sheet technology advantage

LLVM was first relased in 2003, Clang was opened up in 2007 (but is
likely a bit older).  Those aren't young projects by any standard, and
I doubt their sheets are particularly clean by this point.

Re: Defending GCC considered futile

[Stefan Monnier]

> LLVM was first relased in 2003, Clang was opened up in 2007 (but is
> likely a bit older).  Those aren't young projects by any standard, and
> I doubt their sheets are particularly clean by this point.

Compare that to the age of GCC, and while I agree it's had time to grow
warts, it's still much cleaner than GCC and its structure is much better
adapted to current compiler technology needs.

GCC has also changed quite a bit during all those years, and not only by
accruing "stuff" but also by internal redesigns, which helped it stay
"on top of its game", but from the point of view of a someone wanting to
add some new optimization/feature, the technical attractiveness of GCC
is no match to LLVM.  Licenses and "control" have absolutely nothing to
do with it.


        Stefan

Re: Defending GCC considered futile

[Florian Weimer]

* Stefan Monnier:

>> LLVM was first relased in 2003, Clang was opened up in 2007 (but is
>> likely a bit older).  Those aren't young projects by any standard, and
>> I doubt their sheets are particularly clean by this point.
>
> Compare that to the age of GCC, and while I agree it's had time to grow
> warts, it's still much cleaner than GCC and its structure is much better
> adapted to current compiler technology needs.

I have not worked on both compilers, so I'm not sure if that's
accurate.  Considering that the “clean sheets” claim has been around
for five years, I do have my doubts that this is still based on fact
(if it ever was).

One definite advantage for LLVM is that they target GCC 4.7 and later
as the bootstrap compiler (or more precisely, the C++11 subset also
supported by Microsoft Visual C++ 2012 and Clang 3.1).  That does
allow for some clean-ups, but of course, it concerns rather
superficial matters.

> GCC has also changed quite a bit during all those years, and not only by
> accruing "stuff" but also by internal redesigns, which helped it stay
> "on top of its game", but from the point of view of a someone wanting to
> add some new optimization/feature, the technical attractiveness of GCC
> is no match to LLVM.

It depends on what you want to do.  GCC's architecture has its
benefits because it allows the introduction of optimizations which
know more about front-end constructs than what can be made explicit in
its IR.

Re: Defending GCC considered futile

[Perry E. Metzger]

On Sat, 07 Feb 2015 23:30:25 +0100 Florian Weimer <fw@deneb.enyo.de>
wrote:
> * Eric S. Raymond:
> 
> > 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.  The reason has
> > nothing to do with any philosophical issue but merely the fact
> > that compiler technology has advanced significantly in ways that
> > GCC is not well positioned to exploit.  The clang/LLVM people
> > have both a clean-sheet technology advantage
> 
> LLVM was first relased in 2003, Clang was opened up in 2007 (but is
> likely a bit older).  Those aren't young projects by any standard,
> and I doubt their sheets are particularly clean by this point.

Speaking as someone who works inside LLVM a bunch: the LLVM people
are fanatical, absolutely fanatical, about refactoring and keeping
their architecture clean. The whole thing is kept extremely modular,
very easily modified, very well documented. LLVM *is* clean. It is, in
fact, architecturally beautiful. I wish it wasn't written in C++, and
the AST format seems unnecessarily complicated to me, but that aside,
I have few complaints.

Perry
-- 
Perry E. Metzger		perry@piermont.com

Re: Defending GCC considered futile

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > Speking as the original author of GUD, I'm in favor of it supporting
  > LLVM and everything else imaginable.

The question at hand is not about LLVM, or GCC.  It is whether to
install support for something called LLDB.  What exactly is LLDB?

From its name, I guess that LLDB is a noncopylefted debugger and that
some might intend it to replace GDB.  But I don't know if that is so.

Depending on the answers to this questions, and others I don't know
enough to ask yet, it might be good or bad to install this patch.

I know enough to think that bigger things MAY be at stake here.  I
don't know enough to determine whether that is really so, or what
importance they have.  I want to find out.

Does anyone here know enough about LLDB to answer my questions?

-- 
Dr Richard Stallman
President, Free Software Foundation
51 Franklin St
Boston MA 02110
USA
www.fsf.org  www.gnu.org
Skype: No way! See stallman.org/skype.html.

Re: Defending GCC considered futile

[Stefan Monnier]

> Does anyone here know enough about LLDB to answer my questions?

As mentioned earlier, in any case I will happily accept and install LLDB
support into gud.el.  So as long as I'm Emacs maintainer, your opinion
on whether this might ruin the FSF's goals are not relevant.


        Stefan

Re: Defending GCC considered futile

[Stephen J. Turnbull]

Richard Stallman writes:

 > From its name, I guess that LLDB is a noncopylefted debugger

It is.

 > and that some might intend it to replace GDB.

I think everyone working on it does, in the sense that lldb should
include any functionality that's useful in a debugger, which
presumably will be a superset of current gdb features.

 > Does anyone here know enough about LLDB to answer my questions?

Beyond that I can say that on one platform (Mac OS X using clang 3.5)
where the available gdb throws so many <optimized out> values for
function arguments and local variables as to be nearly useless in
debugging code optimized to the production configuration, lldb usually
can tell actual values and is thus much more useful.  I can't say
whether this extends to GNU/Linux as I only use gdb there, although
the frequency of <optimized out> is indeed a PITA on GNU/Linux too.

Ah, it appears that a reasonably recent gdb has appeared in MacPorts
since I last checked.  I'll have to try that.

Re: Defending GCC considered futile

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > I think everyone working on it does, in the sense that lldb should
  > include any functionality that's useful in a debugger, which
  > presumably will be a superset of current gdb features.

This indicates that it is a potential problem.

  > Beyond that I can say that on one platform (Mac OS X using clang 3.5)
  > where the available gdb throws so many <optimized out> values for
  > function arguments and local variables as to be nearly useless in
  > debugging code optimized to the production configuration, lldb usually
  > can tell actual values and is thus much more useful.

This means it is more than a potential problem.

The possible harm is to replace copylefted GNU package
with noncopylefted code.  They must have worked for a long long time
to replace the capabilities GDB already had.

What we should do about this, I don't know yet.  I will talk
with the GDB developers and seee what they think.

-- 
Dr Richard Stallman
President, Free Software Foundation
51 Franklin St
Boston MA 02110
USA
www.fsf.org  www.gnu.org
Skype: No way! See stallman.org/skype.html.

Re: Defending GCC considered futile

[Perry E. Metzger]

On Mon, 09 Feb 2015 17:06:52 -0500 Richard Stallman <rms@gnu.org>
wrote:
> They must have worked for a long long time
> to replace the capabilities GDB already had.

No, actually. Because the rest of the compiler wasn't intentionally
made non-modular, it was possible for the LLDB team to re-use the
code from the rest of the toolchain. LLDB doesn't need things like its
own expression parsing and interpretation code because it can call
into Clang/LLVM at will.

LLDB is itself modular and fully scriptable, and it will be
interesting to see what sort of new ideas its users come up with. One
of the pleasures of working with well architected free software is
seeing the ways people find interesting uses for tools that the
designers had never thought of to begin with.

Perry
-- 
Perry E. Metzger		perry@piermont.com

Re: Defending GCC considered futile

[Eli Zaretskii]

> Date: Mon, 9 Feb 2015 17:24:45 -0500
> From: "Perry E. Metzger" <perry@piermont.com>
> Cc: esr@snark.thyrsus.com, "Stephen J. Turnbull" <stephen@xemacs.org>,
> 	emacs-devel@gnu.org
> 
> On Mon, 09 Feb 2015 17:06:52 -0500 Richard Stallman <rms@gnu.org>
> wrote:
> > They must have worked for a long long time
> > to replace the capabilities GDB already had.
> 
> No, actually. Because the rest of the compiler wasn't intentionally
> made non-modular, it was possible for the LLDB team to re-use the
> code from the rest of the toolchain. LLDB doesn't need things like its
> own expression parsing and interpretation code because it can call
> into Clang/LLVM at will.

Parsing source-code expression is a very small part of what GDB does.
So this is a red herring.

> LLDB is itself modular and fully scriptable, and it will be
> interesting to see what sort of new ideas its users come up with.

GDB is scriptable in Python as well, and also in Guile.

Re: Defending GCC considered futile

[Daniel Colascione]

[-- Attachment #1: Type: text/plain, Size: 1223 bytes --]

On 02/09/2015 07:37 PM, Eli Zaretskii wrote:
>> Date: Mon, 9 Feb 2015 17:24:45 -0500
>> From: "Perry E. Metzger" <perry@piermont.com>
>> Cc: esr@snark.thyrsus.com, "Stephen J. Turnbull" <stephen@xemacs.org>,
>> 	emacs-devel@gnu.org
>>
>> On Mon, 09 Feb 2015 17:06:52 -0500 Richard Stallman <rms@gnu.org>
>> wrote:
>>> They must have worked for a long long time
>>> to replace the capabilities GDB already had.
>>
>> No, actually. Because the rest of the compiler wasn't intentionally
>> made non-modular, it was possible for the LLDB team to re-use the
>> code from the rest of the toolchain. LLDB doesn't need things like its
>> own expression parsing and interpretation code because it can call
>> into Clang/LLVM at will.
> 
> Parsing source-code expression is a very small part of what GDB does.
> So this is a red herring.

It's also one of the most frustrating parts of GDB. Subtle problems in
parsing C++ (who can blame GDB for that?) often make it difficult to
produce certain expressions in that language, especially in programs
with complicated templates. If GDB were able to reuse a common parsing
system, AST library, and completion engine, it would be both smaller and
more robust.


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: Defending GCC considered futile

[Helmut Eller]

On Tue, Feb 10 2015, Daniel Colascione wrote:

> On 02/09/2015 07:37 PM, Eli Zaretskii wrote:
>> Parsing source-code expression is a very small part of what GDB does.
>> So this is a red herring.
>
> It's also one of the most frustrating parts of GDB. Subtle problems in
> parsing C++ (who can blame GDB for that?) often make it difficult to
> produce certain expressions in that language, especially in programs
> with complicated templates. If GDB were able to reuse a common parsing
> system, AST library, and completion engine, it would be both smaller and
> more robust.

Recent GDB versions (can) use a GCC plugin to parse source-code; I think
completion is still done by GDB itself.
https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;a=blob_plain;f=include/gcc-c-fe.def;hb=HEAD

Helmut

Re: Defending GCC considered futile

[Eli Zaretskii]

> From: Helmut Eller <eller.helmut@gmail.com>
> CC: Daniel Colascione <dancol@dancol.org>, Eli Zaretskii <eliz@gnu.org>
> Date: Tue, 10 Feb 2015 09:47:21 +0100
> 
> Recent GDB versions (can) use a GCC plugin to parse source-code;
> https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;a=blob_plain;f=include/gcc-c-fe.def;hb=HEAD

This is used for a different feature: to be able to inject code into a
program being debugged.  See gdb/compile/ in the GDB repository (and
the corresponding docs in the manual, gdb/doc/gdb.texinfo).

And I don't think this is implemented as a GCC plugin.  AFAIU, GDB
dynamically loads libcc1.so to invoke the compiler functions.

> I think completion is still done by GDB itself.

That's correct, GDB completes on symbols using its own code.
File-name completion uses Readline functions.

Re: Defending GCC considered futile

[Eli Zaretskii]

> Date: Tue, 10 Feb 2015 00:30:03 -0800
> From: Daniel Colascione <dancol@dancol.org>
> CC: esr@snark.thyrsus.com, stephen@xemacs.org, rms@gnu.org, 
>  emacs-devel@gnu.org
> 
> >> No, actually. Because the rest of the compiler wasn't intentionally
> >> made non-modular, it was possible for the LLDB team to re-use the
> >> code from the rest of the toolchain. LLDB doesn't need things like its
> >> own expression parsing and interpretation code because it can call
> >> into Clang/LLVM at will.
> > 
> > Parsing source-code expression is a very small part of what GDB does.
> > So this is a red herring.
> 
> It's also one of the most frustrating parts of GDB.

I guess we have very different GDB experiences and/or needs, if this
is a significant issue for you.  I almost never need to type complex
source-level expressions into a debugger.  The reason is simple:
almost every interesting value is already assigned to some variable,
so most expressions I type are simple references to variables.

If you want to explore a complex data structure, you should use Python
or Guile scripting anyway.

> If GDB were able to reuse a common parsing system, AST library, and
> completion engine, it would be both smaller and more robust.

I'm entirely not sure about "smaller" (code bloat imported from
another project is still bloat) and "more robust" (what, only GDB has
bugs in its parsing of C++ monstrosities?).  Anyway, at 5.8MB
_stripped_ size, not including Python and Guile shared libraries, the
"smaller" ship sailed long ago and won't be coming back, certainly
once GDB becomes a C++ program (which happens as we speak).

Re: Defending GCC considered futile

[Daniel Colascione]

[-- Attachment #1: Type: text/plain, Size: 1484 bytes --]

On 02/10/2015 07:57 AM, Eli Zaretskii wrote:
>> Date: Tue, 10 Feb 2015 00:30:03 -0800
>> From: Daniel Colascione <dancol@dancol.org>
>> CC: esr@snark.thyrsus.com, stephen@xemacs.org, rms@gnu.org, 
>>  emacs-devel@gnu.org
>>
>>>> No, actually. Because the rest of the compiler wasn't intentionally
>>>> made non-modular, it was possible for the LLDB team to re-use the
>>>> code from the rest of the toolchain. LLDB doesn't need things like its
>>>> own expression parsing and interpretation code because it can call
>>>> into Clang/LLVM at will.
>>>
>>> Parsing source-code expression is a very small part of what GDB does.
>>> So this is a red herring.
>>
>> It's also one of the most frustrating parts of GDB.
> 
> I guess we have very different GDB experiences and/or needs, if this
> is a significant issue for you.  I almost never need to type complex
> source-level expressions into a debugger.  The reason is simple:
> almost every interesting value is already assigned to some variable,
> so most expressions I type are simple references to variables.

<optimized out>

> If you want to explore a complex data structure, you should use Python
> or Guile scripting anyway.

That scripting is still incomplete.   See
https://sourceware.org/ml/gdb-patches/2014-10/msg00102.html, where I try
to fix it to some extent. At least IME, sooner or later, when scripting
GDB, you fall down to issuing textual commands and parsing their textual
output.


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: Defending GCC considered futile

[David Kastrup]

Daniel Colascione <dancol@dancol.org> writes:

> On 02/10/2015 07:57 AM, Eli Zaretskii wrote:
>>> Date: Tue, 10 Feb 2015 00:30:03 -0800
>>> From: Daniel Colascione <dancol@dancol.org>
>>> CC: esr@snark.thyrsus.com, stephen@xemacs.org, rms@gnu.org, 
>>>  emacs-devel@gnu.org
>>>
>>>>> No, actually. Because the rest of the compiler wasn't intentionally
>>>>> made non-modular, it was possible for the LLDB team to re-use the
>>>>> code from the rest of the toolchain. LLDB doesn't need things like its
>>>>> own expression parsing and interpretation code because it can call
>>>>> into Clang/LLVM at will.
>>>>
>>>> Parsing source-code expression is a very small part of what GDB does.
>>>> So this is a red herring.
>>>
>>> It's also one of the most frustrating parts of GDB.
>> 
>> I guess we have very different GDB experiences and/or needs, if this
>> is a significant issue for you.  I almost never need to type complex
>> source-level expressions into a debugger.  The reason is simple:
>> almost every interesting value is already assigned to some variable,
>> so most expressions I type are simple references to variables.
>
> <optimized out>

Most STL structures are also sort of a nuisance to examine in gdb.
I don't actually have any point of comparison, but I would imagine that
closer ties to a compiler could help here.

Though much may be a question of how much can be stuffed into the
debugging info.

-- 
David Kastrup

Re: Defending GCC considered futile

[Eli Zaretskii]

> From: David Kastrup <dak@gnu.org>
> Cc: Eli Zaretskii <eliz@gnu.org>,  esr@snark.thyrsus.com,  stephen@xemacs.org,  perry@piermont.com,  rms@gnu.org,  emacs-devel@gnu.org
> Date: Tue, 10 Feb 2015 19:41:27 +0100
> 
> Most STL structures are also sort of a nuisance to examine in gdb.

Use Python or Guile for that.  Python scripts to do that float around,
AFAIR.

> I don't actually have any point of comparison, but I would imagine that
> closer ties to a compiler could help here.

Red herring: GDB is as closely tied with GCC as possible in this
respect.  All the problems with <optimized out> etc. are GCC
bugs/misfeatures or insufficient expressive power of DWARF debug info,
which simply cannot describe accurately enough where a variable is
held at some values of PC.

Re: Defending GCC considered futile

[Eli Zaretskii]

> Date: Tue, 10 Feb 2015 10:19:58 -0800
> From: Daniel Colascione <dancol@dancol.org>
> CC: esr@snark.thyrsus.com, stephen@xemacs.org, emacs-devel@gnu.org, 
>  rms@gnu.org, perry@piermont.com
> 
> > I guess we have very different GDB experiences and/or needs, if this
> > is a significant issue for you.  I almost never need to type complex
> > source-level expressions into a debugger.  The reason is simple:
> > almost every interesting value is already assigned to some variable,
> > so most expressions I type are simple references to variables.
> 
> <optimized out>

-Og

> > If you want to explore a complex data structure, you should use Python
> > or Guile scripting anyway.
> 
> That scripting is still incomplete.   See
> https://sourceware.org/ml/gdb-patches/2014-10/msg00102.html, where I try
> to fix it to some extent. At least IME, sooner or later, when scripting
> GDB, you fall down to issuing textual commands and parsing their textual
> output.

That description doesn't strike me as "the most frustrating part",
rather as a rare and marginal annoyance.

Re: Defending GCC considered futile

[David Kastrup]

Eli Zaretskii <eliz@gnu.org> writes:

>> Date: Tue, 10 Feb 2015 10:19:58 -0800
>> From: Daniel Colascione <dancol@dancol.org>
>> CC: esr@snark.thyrsus.com, stephen@xemacs.org, emacs-devel@gnu.org, 
>>  rms@gnu.org, perry@piermont.com
>> 
>> > I guess we have very different GDB experiences and/or needs, if this
>> > is a significant issue for you.  I almost never need to type complex
>> > source-level expressions into a debugger.  The reason is simple:
>> > almost every interesting value is already assigned to some variable,
>> > so most expressions I type are simple references to variables.
>> 
>> <optimized out>
>
> -Og

Not overly useful for finding code generation problems caused in
connection with optimization.  And yes, I have about 1 to 2 reports of
that kind per year.

-- 
David Kastrup

Re: Defending GCC considered futile

[Stefan Monnier]

>> <optimized out>
> -Og

I use -Og but still regularly see "optimized out".


        Stefan

Re: Defending GCC considered futile

[Eli Zaretskii]

> From: Stefan Monnier <monnier@IRO.UMontreal.CA>
> Cc: Daniel Colascione <dancol@dancol.org>, esr@snark.thyrsus.com,
>         stephen@xemacs.org, perry@piermont.com, rms@gnu.org,
>         emacs-devel@gnu.org
> Date: Tue, 10 Feb 2015 18:14:14 -0500
> 
> >> <optimized out>
> > -Og
> 
> I use -Og but still regularly see "optimized out".

That's because DWARF cannot express the location.  LLDB will hit the
same problems when the LLVM optimiziers start optimizing well enough
to compete with GCC.  Back in GCC 2.8 days, I could compile with -O2
and never see any such problems.

Re: Defending GCC considered futile

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

I will ask the GCC maintainers to think about support for examining
variables that are optimized out.

-- 
Dr Richard Stallman
President, Free Software Foundation
51 Franklin St
Boston MA 02110
USA
www.fsf.org  www.gnu.org
Skype: No way! See stallman.org/skype.html.

Re: Defending GCC considered futile

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  >		  Because the rest of the compiler wasn't intentionally
  > made non-modular,

Neither was GCC.

I wrote GCC to be as modular as I knew how to do -- while getting it
to work as fast as I could.  Maybe I could have made it more modular
if I had worked on it slowly for ten years aiming for elegance, but it
was imperative to have a compiler as soon as possible
so as to have a GNU system as soon as possible.

-- 
Dr Richard Stallman
President, Free Software Foundation
51 Franklin St
Boston MA 02110
USA
www.fsf.org  www.gnu.org
Skype: No way! See stallman.org/skype.html.

Re: Defending GCC considered futile

[John Yates]

[-- Attachment #1: Type: text/plain, Size: 765 bytes --]

On Tue, Feb 10, 2015 at 5:48 PM, Richard Stallman <rms@gnu.org> wrote:

>   >               Because the rest of the compiler wasn't intentionally
>   > made non-modular,
>
> Neither was GCC.
>
> I wrote GCC to be as modular as I knew how to do.


Richard,

It is hard to tell whether you are being so literal by intention or because
"you simply do not get it".  What those who embrace LLVM for its modularity
value (cherish?) is that the interfaces induced by modularity are exposed,
leveragable and unencumbered.  Though as a programmer you may take umbrage
at the suggestion that you creation is non-modular this LLVM community
could not care less how modular your design and code were / are so long as
you refuse to allow that modularity to be exploited.

/john

[-- Attachment #2: Type: text/html, Size: 1162 bytes --]

Re: Defending GCC considered futile

[Perry E. Metzger]

On Tue, 10 Feb 2015 17:48:11 -0500 Richard Stallman <rms@gnu.org>
wrote:
> 
>   > Because the rest of the compiler wasn't intentionally
>   > made non-modular,
> 
> Neither was GCC.
> 
> I wrote GCC to be as modular as I knew how to do -- while getting it
> to work as fast as I could.  Maybe I could have made it more modular
> if I had worked on it slowly for ten years aiming for elegance, but
> it was imperative to have a compiler as soon as possible
> so as to have a GNU system as soon as possible.

Yes, but that was long ago. More recently people have worked to make
GCC more modular and to re-use of GCC for other work, but much such
work seems to have been discouraged.

As just one example, there was a big debate recently about allowing
access to GCC's internal ASTs in order to permit Emacs completion.
You were a participant in that debate. You indicated during that
debate that you did not want just any program to get access to GCC
internal interfaces.

Whether you knew how to make GCC more modular or not at the start, we
now know how to make such code far more reusable, but you have
explicitly said that doing so is dangerous and that you don't want it
very general modular compiler architectures. 

If I am mischaracterizing your position, I'm doing it in some subtle
way that I am unaware of and would appreciate further clarification
of your position.

Perry
-- 
Perry E. Metzger		perry@piermont.com

Re: Defending GCC considered futile

[Eli Zaretskii]

> Date: Wed, 11 Feb 2015 10:42:29 -0500
> From: "Perry E. Metzger" <perry@piermont.com>
> Cc: esr@snark.thyrsus.com, emacs-devel@gnu.org
> 
> On Tue, 10 Feb 2015 17:48:11 -0500 Richard Stallman <rms@gnu.org>
> wrote:
> > 
> >   > Because the rest of the compiler wasn't intentionally
> >   > made non-modular,
> > 
> > Neither was GCC.
> > 
> > I wrote GCC to be as modular as I knew how to do -- while getting it
> > to work as fast as I could.  Maybe I could have made it more modular
> > if I had worked on it slowly for ten years aiming for elegance, but
> > it was imperative to have a compiler as soon as possible
> > so as to have a GNU system as soon as possible.
> 
> Yes, but that was long ago. More recently people have worked to make
> GCC more modular and to re-use of GCC for other work, but much such
> work seems to have been discouraged.

Modularizing GCC is not discouraged.  It actually happens as we speak,
check out the latest developments in GCC 5 and GDB.

Re: Defending GCC considered futile

[Perry E. Metzger]

On Wed, 11 Feb 2015 18:14:17 +0200 Eli Zaretskii <eliz@gnu.org> wrote:
> Modularizing GCC is not discouraged.  It actually happens as we
> speak, check out the latest developments in GCC 5 and GDB.

If this is the case, what is the problem with Emacs directly linking
against the GCC front end to get access to the C and C++ AST?

Perry
-- 
Perry E. Metzger		perry@piermont.com

Re: Defending GCC considered futile

[Eli Zaretskii]

> Date: Wed, 11 Feb 2015 11:29:41 -0500
> From: "Perry E. Metzger" <perry@piermont.com>
> Cc: emacs-devel@gnu.org
> 
> On Wed, 11 Feb 2015 18:14:17 +0200 Eli Zaretskii <eliz@gnu.org> wrote:
> > Modularizing GCC is not discouraged.  It actually happens as we
> > speak, check out the latest developments in GCC 5 and GDB.
> 
> If this is the case, what is the problem with Emacs directly linking
> against the GCC front end to get access to the C and C++ AST?

I don't know, you tell me.

Re: Defending GCC considered futile

[Eli Zaretskii]

> Date: Wed, 11 Feb 2015 18:44:44 +0200
> From: Eli Zaretskii <eliz@gnu.org>
> Cc: emacs-devel@gnu.org
> 
> > Date: Wed, 11 Feb 2015 11:29:41 -0500
> > From: "Perry E. Metzger" <perry@piermont.com>
> > Cc: emacs-devel@gnu.org
> > 
> > On Wed, 11 Feb 2015 18:14:17 +0200 Eli Zaretskii <eliz@gnu.org> wrote:
> > > Modularizing GCC is not discouraged.  It actually happens as we
> > > speak, check out the latest developments in GCC 5 and GDB.
> > 
> > If this is the case, what is the problem with Emacs directly linking
> > against the GCC front end to get access to the C and C++ AST?
> 
> I don't know, you tell me.

Btw, I don't really know what you mean by "front end" above, but if
you think the modularization of GCC means separating the back-end,
i.e. the part that is target-dependent, then that's not what how it's
done in this case.  There's more than one way to make a compiler
modular and easy to use by other programs.

Re: Defending GCC considered futile

[Perry E. Metzger]

On Wed, 11 Feb 2015 18:54:37 +0200 Eli Zaretskii <eliz@gnu.org> wrote:
> > > > Modularizing GCC is not discouraged.  It actually happens as
> > > > we speak, check out the latest developments in GCC 5 and GDB.
> > > 
> > > If this is the case, what is the problem with Emacs directly
> > > linking against the GCC front end to get access to the C and
> > > C++ AST?
> > 
> > I don't know, you tell me.
> 
> Btw, I don't really know what you mean by "front end" above, but if
> you think the modularization of GCC means separating the back-end,
> i.e. the part that is target-dependent, then that's not what how
> it's done in this case.  There's more than one way to make a
> compiler modular and easy to use by other programs.

I mostly just meant "getting API access to the part that parses things
and generates an AST", nothing about GCC's architecture in
particular was implied.

Perry
-- 
Perry E. Metzger		perry@piermont.com

Re: Defending GCC considered futile

[Eli Zaretskii]

> Date: Wed, 11 Feb 2015 15:50:06 -0500
> From: "Perry E. Metzger" <perry@piermont.com>
> Cc: emacs-devel@gnu.org
> 
> On Wed, 11 Feb 2015 18:54:37 +0200 Eli Zaretskii <eliz@gnu.org> wrote:
> > > > > Modularizing GCC is not discouraged.  It actually happens as
> > > > > we speak, check out the latest developments in GCC 5 and GDB.
> > > > 
> > > > If this is the case, what is the problem with Emacs directly
> > > > linking against the GCC front end to get access to the C and
> > > > C++ AST?
> > > 
> > > I don't know, you tell me.
> > 
> > Btw, I don't really know what you mean by "front end" above, but if
> > you think the modularization of GCC means separating the back-end,
> > i.e. the part that is target-dependent, then that's not what how
> > it's done in this case.  There's more than one way to make a
> > compiler modular and easy to use by other programs.
> 
> I mostly just meant "getting API access to the part that parses things
> and generates an AST", nothing about GCC's architecture in
> particular was implied.

Then we shouldn't care if it's front end, back end, or "middle-end"
that provides that.

Re: Defending GCC considered futile

[Perry E. Metzger]

On Thu, 12 Feb 2015 05:37:25 +0200 Eli Zaretskii <eliz@gnu.org> wrote:
> > Date: Wed, 11 Feb 2015 15:50:06 -0500
> > From: "Perry E. Metzger" <perry@piermont.com>
> > Cc: emacs-devel@gnu.org
> > 
> > On Wed, 11 Feb 2015 18:54:37 +0200 Eli Zaretskii <eliz@gnu.org>
> > wrote:
> > > > > > Modularizing GCC is not discouraged.  It actually happens
> > > > > > as we speak, check out the latest developments in GCC 5
> > > > > > and GDB.
> > > > > 
> > > > > If this is the case, what is the problem with Emacs directly
> > > > > linking against the GCC front end to get access to the C and
> > > > > C++ AST?
> > > > 
> > > > I don't know, you tell me.
> > > 
> > > Btw, I don't really know what you mean by "front end" above,
> > > but if you think the modularization of GCC means separating the
> > > back-end, i.e. the part that is target-dependent, then that's
> > > not what how it's done in this case.  There's more than one way
> > > to make a compiler modular and easy to use by other programs.
> > 
> > I mostly just meant "getting API access to the part that parses
> > things and generates an AST", nothing about GCC's architecture in
> > particular was implied.
> 
> Then we shouldn't care if it's front end, back end, or "middle-end"
> that provides that.

Clearly. All that matters is getting convenient access to
complete information about the syntactic structure of the code
in the buffer, not what we name the chunk of code that we call to
provide that data, or what people consider that code to be part of. :)


Perry
-- 
Perry E. Metzger		perry@piermont.com

Re: Defending GCC considered futile

[Florian Weimer]

* Perry E. Metzger:

> On Wed, 11 Feb 2015 18:14:17 +0200 Eli Zaretskii <eliz@gnu.org> wrote:
>> Modularizing GCC is not discouraged.  It actually happens as we
>> speak, check out the latest developments in GCC 5 and GDB.
>
> If this is the case, what is the problem with Emacs directly linking
> against the GCC front end to get access to the C and C++ AST?

The C front end does not produce an AST, it lowers immediately to
GENERIC, whose only control flow constructs are conditional
expressions and gotos.  The C++ front end extends GENERIC with
additional trees, preserving more information, but I do not know if it
is sufficiently complete to qualify as an AST.

I don't know if this can be fixed so that the result is still
maintainable and there is no observable speed difference no matter
what compiler flags you use.

(I looked at this because I wanted to introduce syntax-driven
unreachable code warnings, including a switch-case fallthrough
warning.)

Re: Defending GCC considered futile

[Stefan Monnier]

>> Modularizing GCC is not discouraged.  It actually happens as we
>> speak, check out the latest developments in GCC 5 and GDB.
> If this is the case, what is the problem with Emacs directly linking
> against the GCC front end to get access to the C and C++ AST?

AFAIK, there is no technical problem with it (even GCC's license allows
for it).  The problem is with Richard refusal to develop&distribute such
a thing.


        Stefan

Re: Defending GCC considered futile

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > If this is the case, what is the problem with Emacs directly linking
  > against the GCC front end to get access to the C and C++ AST?

I have nothing against that.

On the other hand, it might be easier to run GCC in a child process,
have it keep the AST inside it, and ask it questions about completion
at any given point.

-- 
Dr Richard Stallman
President, Free Software Foundation
51 Franklin St
Boston MA 02110
USA
www.fsf.org  www.gnu.org
Skype: No way! See stallman.org/skype.html.

Re: Defending GCC considered futile

[raman]

All this feels like "We've seen this movie before"  AKA GCC 2.7.2 --
Cygnus GCC1.xx -- and finally GCC started moving forward again. I hope
 the present version of this movie has a similar conclusion ...

Re: Defending GCC considered futile

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > Yes, but that was long ago. More recently people have worked to make
  > GCC more modular

I don't know of any such work, but the GCC developers wouldn't normally
discuss it with me -- they would just do it.

		     and to re-use of GCC for other work, 

That's something else -- or, I should say, a broad range of many
different something elses.  Some of them are good and some are bad.

We want the modules of GCC to be combined with other modules _only by
linking_ so that the GPLm= must apply to the other modules.

On the other hand, connecting modules of GCC to other separate
programs is potentially dangerous.  For instance, outputting complete
ASTs from GCC is potentially dangerous.

People have presented arguments that it isn't really dangerous
nowadays.  They might be valid, and I want to consider them under calm
circumstances -- no pressure.

If I conclude it is ok for GCC to output the AST, are you interested
in working with that?

-- 
Dr Richard Stallman
President, Free Software Foundation
51 Franklin St
Boston MA 02110
USA
www.fsf.org  www.gnu.org
Skype: No way! See stallman.org/skype.html.

Re: Defending GCC considered futile

[Helmut Eller]

On Sun, Feb 08 2015, Richard Stallman wrote:

> The question at hand is not about LLVM, or GCC.  It is whether to
> install support for something called LLDB.  What exactly is LLDB?

LLDB is a debugger, written by the folks behind LLVM.  LLDB is linked to
Clang/LLVM to parse C expressions and to generate code if necessary.
Everybody who supports LLDB indirectly supports LLVM.

Helmut

Re: Defending GCC considered futile

[Florian Weimer]

* Richard Stallman:

>   > Speking as the original author of GUD, I'm in favor of it supporting
>   > LLVM and everything else imaginable.
>
> The question at hand is not about LLVM, or GCC.  It is whether to
> install support for something called LLDB.  What exactly is LLDB?

It's the system debugger on MacOS X.

“With the release of Xcode 5, the LLDB debugger becomes the foundation
for the debugging experience on OS X.”

<https://developer.apple.com/library/ios/documentation/IDEs/Conceptual/gdb_to_lldb_transition_guide/document/Introduction.html>

It's difficult to understand why LLDB support is unacceptable, but
MacOS X support is fine.

Re: Defending GCC considered futile

[Perry E. Metzger]

On Mon, 09 Feb 2015 20:30:15 +0100 Florian Weimer <fw@deneb.enyo.de>
wrote:
> It's the system debugger on MacOS X.

It is indeed, and in that sense, it is not unlike things like the
non-gdb system debuggers found on other OSes like Solaris. One nice
distinction is that LLDB is itself free software.

> It's difficult to understand why LLDB support is unacceptable, but
> MacOS X support is fine.
 
I quite agree. It isn't even like one can't quite easily use LLDB
with Emacs already -- many do, in fact. It is just a question of
installing the right .el file from the LLVM people, which is not
particularly difficult to do.

(If Apple cared enough, they could supply that .el file with the
version of Emacs that is shipped with Mac OS X, though they don't
seem to have cared to do so thus far, probably because they likely
don't view Emacs as a significant development tool for OS X even
though they do provide it.)

Perry
-- 
Perry E. Metzger		perry@piermont.com

Re: Defending GCC considered futile

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > It's difficult to understand why LLDB support is unacceptable, but
  > MacOS X support is fine.

I don't know whether the cases are similar.  I am still waiting for
more information.

And I don't know whether support for LLDB is unacceptable.

I can tell you that IF I conclude that LLDB support is unacceptable
it will be because of factors that are different from MacOS.

-- 
Dr Richard Stallman
President, Free Software Foundation
51 Franklin St
Boston MA 02110
USA
www.fsf.org  www.gnu.org
Skype: No way! See stallman.org/skype.html.

Re: Defending GCC considered futile

[Perry E. Metzger]

On Sun, 08 Feb 2015 19:04:47 -0500 Richard Stallman <rms@gnu.org>
wrote:
>   > Speking as the original author of GUD, I'm in favor of it
>   > supporting LLVM and everything else imaginable.
> 
> The question at hand is not about LLVM, or GCC.  It is whether to
> install support for something called LLDB.  What exactly is LLDB?

It is a debugger. It is part of the LLVM ecosystem and tightly
integrated with it. It understands things like LLVM's IR and can
make use of the LLVM JIT and the like.

The home page for LLDB is http://lldb.llvm.org/

As with the rest of LLVM, it is extremely modular and can be used as
components, and exposes a well architected library interface. It
makes use of other parts of LLVM via the modular interfaces of
the rest of LLVM. For example, it uses Clang directly to do things
like parsing source code expressions, which it can do because LLVM is
highly modular, and it can invoke the back end of the compiler to
produce executable code for source expressions entered.

LLDB is also fully scriptable using Python, and the library APIs
exposed by LLDB are fully available as Python interfaces so a Python
script can do quite advanced things, indeed, arbitrary things
without restriction.

LLDB is free software but is not copyleft. I am unaware of any
proprietary forks of LLDB in existence.

Perry
-- 
Perry E. Metzger		perry@piermont.com