Try out LLVM: no C++0x & crash

Hello,

Following a question about POD-ness on StackOverflow, I tried the following snippet on Clang via the Try Out LLVM page:

#include <type_traits>

struct B
{
int a;
B(int aa) : a(aa) {}
B() = default;
};

static_assert(std::is_pod::value, “B should be POD”);

2 problems arose:

  1. Clang does not use C++0x, and there is no option to make it so, thus the header cannot be parsed
  2. It caused a crash (probably because the header could not be parsed)

Here is the output generated:

Hello,

Following a question about POD-ness on StackOverflow, I tried the following
snippet on Clang via the Try Out LLVM page:

#include <type_traits>

struct B
{
  int a;
  B(int aa) : a(aa) {}
  B() = default;
};

static_assert(std::is_pod<B>::value, "B should be POD");

2 problems arose:

1. Clang does not use C++0x, and there is no option to make it so, thus the
header cannot be parsed
2. It caused a crash (probably because the header could not be parsed)

...

0. Program arguments: /opt/clang-releases/llvm-2.7/bin/clang -cc1

This would seem to imply that the version of Clang running on the
demo page is 2.7, which had quite poor C++ support. This was backed
up by my own experiments in which I tried to compile the following
(which fails to compile; enumerator_attributes was introduced between
2.7 and 2.9):

#if !__has_feature(enumerator_attributes)
test
#endif

Are we really running 2.7? And if so, we should certainly consider
upgrading LLVM/Clang on the demo machine.

Thanks,

  1. Clang does not use C++0x, and there is no option to make it so, thus the
    header cannot be parsed

I’ve got some experiments that could add this support - though it’s a slightly more involved problem. Clang can’t parse libstdc++'s C++11 headers - it needs libc++ for that. So you’d need the option to choose the stdlib (& preferably have that option be forced upon you if you chose to compile as C++11) as well as the language spec.

  1. It caused a crash (probably because the header could not be parsed)

That is a bit strange - I assume clang shouldn’t be trying to continue compiling after it finds a #error directive, but I’m not sure.

  1. Program arguments: /opt/clang-releases/llvm-2.7/bin/clang -cc1

This would seem to imply that the version of Clang running on the
demo page is 2.7, which had quite poor C++ support. This was backed
up by my own experiments in which I tried to compile the following
(which fails to compile; enumerator_attributes was introduced between
2.7 and 2.9):

#if !__has_feature(enumerator_attributes)
test
#endif

I don’t have access to my own dev account right now so I can’t verify this - but does that successfully compile on 2.9 even without specifying a spec version (ie: using the default -std=c++98)?

Are we really running 2.7? And if so, we should certainly consider
upgrading LLVM/Clang on the demo machine.

I believe the intent was to upgrade to 2.9 when Tanya switched over to using clang for the demo page a few weeks ago: https://llvm.org/viewvc/llvm-project/www/trunk/demo/index.cgi?r1=102895&r2=136820&diff_format=h

But perhaps the machine never got the latest version rebuilt…

Which could explain why my colored clang diagnostic change never worked for her, if clang didn’t have colored diagnostic support back in 2.7 (I don’t know which revision that was - could someone confirm whether that’s true? I’ll poke around in ViewVC to see if I can make sense of it, though)

  • David

Which could explain why my colored clang diagnostic change never worked for her, if clang didn’t have colored diagnostic support back in 2.7 (I don’t know which revision that was - could someone confirm whether that’s true? I’ll poke around in ViewVC to see if I can make sense of it, though)

Yep. That seems to explain it - clang didn’t respect forcibly turning colored diagnostics on in the absence of terminal colors until relatively recently: https://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Driver/Tools.cpp?revision=114638&view=markup

If you pop the below into the demo you can see that it’s between 2.7 and 2.8 before r102686, so it’s probably 2.7.

#include <stdio.h>

int main() {
#ifdef clang_version
printf("%s\n", clang_version);
#endif
return 0;
}

You know this because clang_version was defined in r102686.

FYI, on my machine that code spits out “3.0 (trunk 137973)”.

Thanks,
Jon

Yes, this is the problem. I had a symlink (used by the script) to the clang release that I apparently didn’t update.

Sorry for my mistake.

Thanks,
Tanya

2011/8/24 Tanya Lattner <lattner@apple.com>

2011/8/24 Tanya Lattner <lattner@apple.com>

Which could explain why my colored clang diagnostic change never worked for her, if clang didn’t have colored diagnostic support back in 2.7 (I don’t know which revision that was - could someone confirm whether that’s true? I’ll poke around in ViewVC to see if I can make sense of it, though)

Yep. That seems to explain it - clang didn’t respect forcibly turning colored diagnostics on in the absence of terminal colors until relatively recently: https://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Driver/Tools.cpp?revision=114638&view=markup

Yes, this is the problem. I had a symlink (used by the script) to the clang release that I apparently didn’t update.

Thanks - looks great. (side note to anyone who’s interested: copy/pasting from the website in IE & FF doesn’t keep the coloring, unfortunately (I believe it’s because it’s in CSS & these browsers don’t bother to go & gather the CSS & inline it into the copied snippet) - but Chrome does the right thing. So if you want to put colored output in webpages, emails, etc - copy/paste from the demo while using Chrome!)

Thanks for the help, Tanya.

I confirm it is now working correctly (as much as it can work in C++03).

I’ll see if I can send out a CR to add C++11 support to the website tonight - though it’ll require deploying libc++ to the demo server for any library usage, of course.

  • David

Have you tried a recent clang against libstdc++-4.6.1? A simple test I
just tried succeeds, but it's possible more complex files will fail.
If you see failures that aren't clang bugs, mail me and I'll try to
get fixes upstream.

Resurrecting the old thread. Two releases have gone by, could someone
update the demo to 3.2 and enable C++11?

Tanya - would you mind updating the demo to 3.2?

I'll try to resurrect my work to add a language specification option
to the demo page.

Yes. I just got back from vacation and can do it tomorrow.

-Tanya

We really ought to have a web developer/designer we can talk to help
with things like this. I suspect that someone with solid web-design
skills in-core could make a big difference to the usability/prettiness
of LLVM's web presence with just a few days' effort.

Maybe Google, Apple, etc. could loan us a web developer for a week or so?

-- Sean Silva