clang comparison webpage

http://clang.llvm.org/comparison.html compares clang versus three other
compilers, one of them gcc, and invites mail to cfe-dev "if you think
some characterization is unfair here".

But the comparison to gcc leaves off the major reason clang is a
complete nonstarter for me: lack of support for gcc extensions. (In my
case nested function support is the biggest one; clang appears to be
under the impression that they are "infrequently used", which, true or
not in general, is not true of my code.)

Not that it's a screaming big deal. But I do think it's at least
somewhat unfair to gcc to fail to at least mention clang's lack of
support for some of gcc's extensions when comparing the two.

/~\ The ASCII Mouse
\ / Ribbon Campaign
X Against HTML mouse@rodents-montreal.org
/ \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B

Mouse <mouse@Rodents-Montreal.ORG> writes:

http://clang.llvm.org/comparison.html compares clang versus three other
compilers, one of them gcc, and invites mail to cfe-dev "if you think
some characterization is unfair here".

But the comparison to gcc leaves off the major reason clang is a
complete nonstarter for me: lack of support for gcc extensions. (In my
case nested function support is the biggest one; clang appears to be
under the impression that they are "infrequently used", which, true or
not in general, is not true of my code.)

Is it feasible for you to use lambdas instead of nested functions?

Not that it's a screaming big deal. But I do think it's at least
somewhat unfair to gcc to fail to at least mention clang's lack of
support for some of gcc's extensions when comparing the two.

If you are comparing C/C++ compilers you base the comparison on
universal goals such as standards compliance, code quality, etc. I would
never assume that compiler A is a drop-in replacement for compiler B wrt
extensions.

Sure, it would be nice to support every GCC extension, but the time
invested on implementing those extensions would slow-down the
development of the features that makes Clang so attractive as a C++
compiler on every other aspect.

Thanks for the suggestion; I've updated the comparison to note that GCC
provides some language extensions that Clang does not (and vice versa).
Please let us know if there's anything else you think should be adjusted in
the comparison page; I also spotted another couple of places where it was
out of date (listing Clang advantages in areas where GCC has caught up). We
should probably also weaken some of our claims about diagnostics, since GCC
4.9 has got a lot better in that area.

http://clang.llvm.org/comparison.html compares clang versus three other
compilers, one of them gcc, and invites mail to cfe-dev "if you think
some characterization is unfair here".

But the comparison to gcc leaves off the major reason clang is a
complete nonstarter for me: lack of support for gcc extensions. (In my
case nested function support is the biggest one; clang appears to be
under the impression that they are "infrequently used"

On this matter specifically, clang is a lot better set up nowadays to parse the old GNU nested functions thanks to work that was done do support closures like blocks and other function declarators that appear in funny places.

I just tried and you can get them to parse with a one-line change in clang/lib/Parse/ParseDecl.cpp, and you can get some degree of semantic support for nested variable scope with another small change to ScopeInfo.h and SemaDecl.cpp. Probably with one more tweak to lib/CodeGen you could get this up and running.

I think the policy not to support this extension made sense in the early days, but since then we've added support for all kinds of good (and dubious) extensions from GCC, MSVC and others so this is small fry.

So if there is a good case for it and someone volunteers their weekend to implement it complete with tests, I can't imagine there would be vociferous objection from current maintainers of the code to be honest.

Alp.

Right. Early on, it just wasn’t important. Beyond that, I still think that gnu nested functions are bad because 1) the cases that require trampolines on the stack are back for security (needing an executable stack) and 2) because error recovery/QoI is worse with them (in principle) when a } is forgotten.

That said, if someone were motivated to implement this extension (or a subset of it) then that would be really great. IMO, I just think that -fnested-functions should be off by default.

-Chris

http://clang.llvm.org/comparison.html compares clang versus three other
compilers, one of them gcc, and invites mail to cfe-dev "if you think
some characterization is unfair here".

But the comparison to gcc leaves off the major reason clang is a
complete nonstarter for me: lack of support for gcc extensions. (In my
case nested function support is the biggest one; clang appears to be
under the impression that they are "infrequently used"

On this matter specifically, clang is a lot better set up nowadays to parse the old GNU nested functions thanks to work that was done do support closures like blocks and other function declarators that appear in funny places.

I just tried and you can get them to parse with a one-line change in clang/lib/Parse/ParseDecl.cpp, and you can get some degree of semantic support for nested variable scope with another small change to ScopeInfo.h and SemaDecl.cpp. Probably with one more tweak to lib/CodeGen you could get this up and running.

I think the policy not to support this extension made sense in the early days, but since then we've added support for all kinds of good (and dubious) extensions from GCC, MSVC and others so this is small fry.

So if there is a good case for it and someone volunteers their weekend to implement it complete with tests, I can't imagine there would be vociferous objection from current maintainers of the code to be honest.

Right. Early on, it just wasn’t important. Beyond that, I still think that gnu nested functions are bad because 1) the cases that require trampolines on the stack are back for security (needing an executable stack)

So back when I investigated this a few years ago, it turned out a lot of people asking for nested functions were in fact just using them as syntactic sugar to get local scoping for things like unit tests in C.

We could avoid most of the unpleasant stuff if we restrict support to direct calling as I think the trampolines are only needed to take the address as a function pointer. Ditto cross-function goto with local labels.

Mouse, would this "safe" but limited implementation of nested functions meet your use-case?

If so we can just plug in to the existing closure support, in fact I have a really old patch for that lying about somewhere.

  and 2) because error recovery/QoI is worse with them (in principle) when a } is forgotten.

That said, if someone were motivated to implement this extension (or a subset of it) then that would be really great. IMO, I just think that -fnested-functions should be off by default.

Agree if this ever happens it should be behind a flag.

Alp.

Right. Early on, it just wasn?t important. Beyond that, I still think that$

As for trampolines, that's a reason to dislike gcc's implementation
(the ABI, if you will); it's not a reason to dislike the API, the
programmer-visible form they take.

As for error recovery, perhaps I'm just an outlier in this respect, but
it seems to me that they're no different from "if" or "for" in that
respect - IOW, even to the extent that's true, I don't see that as
enough of a problem to justify not implementing them. (Of course, the
extent "justify" is really an appropriate verb there is debatable....)

That said, if someone were motivated to implement this extension (or a subse$

For my purposes, I don't much care if it takes a command-line option to
enable them - I already throw a wrapper script around the compiler
anyway, to deal with the pile of gcc variants, or more precisely te
correct flag cluster to get the warnings I want, I'm faced with.

If that's a way of suggesting I should be the "someone"? That
certainly makes sense, but the activation energy is high enough it's
unlikely to happen soon, especially since there is another extension I
use moderately heavily which is actually my own, so switching to clang
would mean getting my head around its internals enough to add it there,
a significantly higher effort than just getting it to build.

/~\ The ASCII Mouse
\ / Ribbon Campaign
X Against HTML mouse@rodents-montreal.org
/ \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B

If the user wants to capture locals from outside the inner function, it is
impossible to implement the API that nested functions provide securely
while conforming to existing function pointer ABIs. Blocks and lambdas
don't have this problem.

So back when I investigated this a few years ago, it turned out a lot
of people asking for nested functions were in fact just using them as
syntactic sugar to get local scoping for things like unit tests in C.

We could avoid most of the unpleasant stuff if we restrict support to
direct calling as I think the trampolines are only needed to take the
address as a function pointer.

Yes.

Ditto cross-function goto with local labels.

Yes; they are hard only when control passes outside the outermost scope
involved, in between setup and goto.

Mouse, would this "safe" but limited implementation of nested
functions meet your use-case?

Some but definitely not all of them. Some of them are cases like
wanting a recursive function which references lexically local things
like function arguments; those would be fine with such an
implementation. But some of my use cases are, basically, currying,
things like turning a three-argument "compare X and Y with context Z"
function into something that can be passed to an external API like
qsort. And some are essentially "better longjmp" things like

...
{
__label__ out;

void throw_out(void)
  { goto out;
  }

if (0)
  {
out:;
    ...maybe do a little cleanup...
    return;
  }
...
errthrow = &throw_out; /* errthrow is file- or program-global */
/* or */
something(...,&throw_out); /* last arg is called to abort processing */
...
}

(one of the two real uses I've found for "if (0)").

/~\ The ASCII Mouse
\ / Ribbon Campaign
X Against HTML mouse@rodents-montreal.org
/ \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B