Slashdot Mirror

For all practical purposes, CLANG is useless if you want to develop C++.

Are you high?

CLANG is incompatible with libstdc++

Are you high?

or microsoft's c++ library.

Are you high?

Which means you have to use the libc++ that they supply.

Are you high?

Unfortunately libc++ is not available on windows, so any app that uses C++ features is out.

Finally a vaguely true-ish statement. Nobody's maintained libc++ on Windows in years. Of course, you could just use clang with MSVC's C++ STL or the libstdc++ one, or Dinkumware, or ...

On linux, if you want to use the C++ features, it is pretty much impossible to cross-link against libc++ and the other libs on your distribution that may be complied with g++, so you have to compile every library you want with with CLANG to use and ship a static binary (or ship the libs and have your startup script setup library paths etc).

Clang and GCC are ABI compatible and always have been barring bugs (yes, GCC also has ABI bugs). You can link libraries built with either compiler, even picking individual .o files.

Of course, many of the common open source C++ libs do not compile with CLANG anyway so you are screwed.

Yes, GCC accepts invalid code, programmers write invalid code.

These days, most programs have fixed their code and build with clang just fine. For instance only 5.9% of Debian packages failed to build with clang.

In summary, unless you are writing console only apps and do not need to link to any c++ library other than libc++, CLANG is not even an option for you.

For example, Chrome build with clang on Linux, Mac and Windows, using libstdc++ on Linux, libc++ on Mac and the MSVC C++ libary on Windows. The Mac and LInux versions built with clang are what Google actually ships.

I don't think clang+llvm will just fail once Apple drops support. There are so many other companies supporting clang+llvm and use them to do important things. See: http://llvm.org/Users.html

1. There is a custom debugger for go: https://github.com/derekparker.... Also worrying this much about debuggers is kind of sad, what will happen when you literally can't use one or it doesn't help? Oh you have never done embedded or distributed work I see.

2. Nope (also [citation needed]). The go compiler is fast because it doesn't use modules/header files. See the C++ working group on the subject to understand why it is so slow: http://llvm.org/devmtg/2012-11...

3. "Built in functions". The built in "generics" are not functions, they are data types. And no you probably don't need them.

4. I'm sorry you don't catch your exceptions. Your coworkers are too.

5. A definition of systems that tons of people use.

6. Godeps. Or like 30 other ones. Java and C++ don't come with a version system either, but you probably assumed Maven was part of the core. 7. Guys CPU profiling for a server side language doesn't work on OSX (except it does).

8. Go doesn't have a virtual (byte code interpreted) runtime, so its nothing like the JVM. And yes every language has a runtime. I mean literally what?

9. Nothing of value here folks.

10. Or here.

There are things wrong with Go, but none of these are them. In fact this post shows such a stunning lack of understanding about programming languages it worries me.

Missing features maybe. Like OpenMP, which is not there yet. LLVM and GCC feed off each other. Some competition is good.

Meanwhile, all the other platforms for which LLVM would be the dominant platform and for which there aren't extant major backers are basically on the hook for whatever way LLVM wants to play it, including extinguishing support for their platform.

No, really, I mean it. Explain in detail how FreeBSD will become utterly unusable if LLVM went closed-source today and deleted any FreeBSD related code from their now-internal repository. Or AMD's OpenCL implementation. Or any other project using LLVM.

Sure, it's technically possible to start up a fork tomorrow. But, realistically, it's also just as possible to recreate MS Windows from scratch.

That comparison is utterly silly. You already have the entire source code for LLVM, and forking it is simply pushing it to another repository. That's the complete opposite of Windows, where you'd have to recreate it from scratch.

Well, either way, you're setting yourself up for the risk of the source going closed and you having to support development yourself.

Well yes, but all that does is put you in the same spot as if you had picked a closed-source component to begin with.

And don't think you're safe with GPL. Any GPL code can be re-licensed (and thus made closed-source) if the copyright holders agree. Of course, exactly as with BSD, the code already distributed under GPL/BSD will stay GPL/BSD.

You either don't know LLVM or you don't know Android.

Well obviously you either don't know these projects as well as you do or you are willing to lie about them.

They are not the same.

Obviously they are not Android is an Operating system and LLVM is a set of compiler tools. The point of analogies is to compare similar things that are different. Analogies comparing the same thing really don't work. For example, if doesn't make sense to draw an analogy between the digestive system of a Guernsey cow and the digestive system of a Guernsey cow does it?

LLVM was a postgrad student project,

A student whose name is Chris Lattner. Who has been the project maintainer his whole life. Who went to work for Apple to bring the code up to snuff and created a team there to maintain it.

and remains an open project, that anyone can contribute to http://llvm.org./

Android was a commercial product bought by Google

and whose core was open sourced. It's called AOSP. and like LLVM anyone can contribute to it.

You either don't know LLVM or you don't know Android. They are not the same.

LLVM was a postgrad student project, and remains an open project, that anyone can contribute to http://llvm.org./

Android was a commercial product bought be Google, and they occasionally offer source copies of parts of the project.

RMS isn't against commercial (for profit) software at all. He's against software that is not completely transparent to the user about what it's doing (and that you can't fix yourself if it breaks).

The software that he is objecting to supporting is completely transparent.

You can also fix it if it breaks.

Here is the god damned svn: http://llvm.org/svn/llvm-proje...

So why is he complaining here? What we can take from this is that your comments are worthless shit.

Your complaint is shit, because the point is both well known, and obvious to anybody who bothered to understand the background.

The point of the Free Software movement embodied in the Free Software Foundation is to create and support software that actively protects the users freedom by ensuring not only that the original software was transparent and user-modifiable, but also that it would protect you from being embraced, extended, and extinguished. Not everybody agrees with this position, but it is a well known and easy to understand position.

The counter argument isn't just, "hurr, whu? huh? you're shit." The counter argument is actually that if users have enough freedom available, that they can simply switch to something else and that "embrace, extend, extinguish" has been countered mostly by user demand for portable data formats, and SCOTUS decisions protecting the right to inter-operate.

The counter-counter argument is that users who really want Software Freedom can choose GPL software and not have to remain vigilant about each little example, each case where somebody is trying to include some proprietary bit and then get you to "need" it. They can instead simply remain vigilant about one thing; using Free Software. And then they're protected, and they can make business decisions with a higher level of predictability.

Most people can read these arguments and easily choose which one they prefer. The subjective choice, as with most subjective choices, are easy. But not everybody arrives at the same choices! And it is clearly in error to claim that one side didn't have a good point, or is "shit." They're just different points, based on different values and concerns.

I just wish there was a version of the debate where becoming a package maintainer and thrusting a new paradigm on the users was recognized as a removal of freedom, a form of "embrace, extend, extinguish."

RMS isn't against commercial (for profit) software at all. He's against software that is not completely transparent to the user about what it's doing (and that you can't fix yourself if it breaks).

The software that he is objecting to supporting is completely transparent.
You can also fix it if it breaks.

Here is the god damned svn: http://llvm.org/svn/llvm-proje...

So why is he complaining here? What we can take from this is that your comments are worthless shit.

You've made a good point, and I want to emphasize that the LLVM License *IS* an open source license, it's just not as restrictive as the GPLv3 license in terms of how the software can be used. RMS wants software to be free, but GPLv2 is more free than GPLv3 because GPLv2 has fewer restrictions on how the software can be used. RMS is marginalizing himself with his crusade against commercial software.

Yup, that's exactly why they chose "Clang" as the name for the C frontend for LLVM.

If Swift was "open source", programmers would make it better. Then Apple would exploit their work to make another billion dollars. This is the flaw in "open source" - why would I work for free to make Apple another billion?

Try asking these people.

Not really. GCC is inconvenient in several ways. See this comparison for details. Most of them are technical, but a couple are related to the license being GPL. Clang and LLVM are "truly free software" as well, so Apple clearly aren't averse to "truly free software".

OK, I think I found it - by downloading the clang source, opening the release notes file in the archive, and doing a google search for the exact phrase.

Hope this helps. It's actually great quality work, if they only made it possible to FIND it on the website.

Yeah, somebody please PLEASE track them down. Frankly LLVM itself is boring (don't hit me). The clang part is where the interesting stuff is. Why in hell doesn't somebody fix that miserable horror of a website?

Look at this fucking page. As I write this the title says "Clang 3.5 (In-Progress) Release Notes - Clang 3.6 documentation". The top heading says "Clang 3.6 documentation". The level 2 subheading says "Clang 3.5 (In-Progress) Release Notes". The level 3 heading says "Clang 3.5 (In-Progress) Release Notes". And the virtually empty content clearly relates to day 1 of the development of 3.6. Psst - nobody CARES about 3.6 on the day 3.5 is released. Meanwhile (again, as I write this) there is not a single occurrence of "3.5" on this other page on clang C++ compliance.

I. Kid. You. Not.

I wouldn't ride them this hard, but that page has been borked in that general fashion for months, if not YEARS. I know this documentation stuff is anathema to the guys doing the real programming work, but they should delegate at least ONE guy whose only job is documentation and the website.

Yeah, somebody please PLEASE track them down. Frankly LLVM itself is boring (don't hit me). The clang part is where the interesting stuff is. Why in hell doesn't somebody fix that miserable horror of a website?

Look at this fucking page. As I write this the title says "Clang 3.5 (In-Progress) Release Notes - Clang 3.6 documentation". The top heading says "Clang 3.6 documentation". The level 2 subheading says "Clang 3.5 (In-Progress) Release Notes". The level 3 heading says "Clang 3.5 (In-Progress) Release Notes". And the virtually empty content clearly relates to day 1 of the development of 3.6. Psst - nobody CARES about 3.6 on the day 3.5 is released. Meanwhile (again, as I write this) there is not a single occurrence of "3.5" on this other page on clang C++ compliance.

I. Kid. You. Not.

I wouldn't ride them this hard, but that page has been borked in that general fashion for months, if not YEARS. I know this documentation stuff is anathema to the guys doing the real programming work, but they should delegate at least ONE guy whose only job is documentation and the website.

Where are the CLang release notes? They are not where I expect them to be. I was really hoping they've implemented C11's _atomic keyword, but I have my doubts.

The article pointed to the very very very very very incomplete release notes for stuff after 3.5.

You wanted to link to the 3.5 release notes.

You can already ask some compilers to do what you are asking - it's just often not on in shipped builds.

At compilation time warnings can be generated for out of bounds accesses that can be determined statically. Clang has -fsanitize=bounds, GCC has -Warray-bounds.

As an Anonymous Coward pointed out, it can be hard to detect runtime allocations overruns at compilation time. For these something like Clang's AddressSanitizer (GCC has added it too will help but at a cost of both time (slow down factor of 2) and space which is why you're unlikely to find it enabled on your precompiled SSH server binary. It's true there are cheaper checks (such as GCC's FORTIFY_SOURCE) that are less thorough/specialized that are often enabled by distros.

You can already ask some compilers to do what you are asking - it's just often not on in shipped builds.

At compilation time warnings can be generated for out of bounds accesses that can be determined statically. Clang has -fsanitize=bounds, GCC has -Warray-bounds.

As an Anonymous Coward pointed out, it can be hard to detect runtime allocations overruns at compilation time. For these something like Clang's AddressSanitizer (GCC has added it too will help but at a cost of both time (slow down factor of 2) and space which is why you're unlikely to find it enabled on your precompiled SSH server binary. It's true there are cheaper checks (such as GCC's FORTIFY_SOURCE) that are less thorough/specialized that are often enabled by distros.

May I point out that the LLVM logo is a wyvern? http://llvm.org/Logo.html

There is a diversity of approaches to GC, with different trade-offs. The short-object-lifetime conjecture works out pretty well in practice (and can be explicitly coded and/or compiled towards), and extremely fast handling of a small first generation arena has led to many approaches which takes advantage of what underlying hardware actually does (stack->hidden registers, cacheline colouring, etc.). Threading is commonplace in modern GCs, so there is no need to stop the world even for a full collection; anti-collision approaches involving write barriers, random selection of which page at a given hotness should be scanned, and so forth, mean that one has to try hard to hit the worst case of the the GC scan & sweep or scan & move with one's code.

The important point about GC is that it reduces the time to allocate memory initially; the typical case is a pointer increment and no further bookkeeping. The cost of freeing and compacting can be amortized over time during idle periods, or where there is room for one or more GC threads to sift through older objects to see if they're still referenced.

Reference Counting is not real GC.

That's an unusual opinion. Automated reference counting implementations are essentially an optimization over simple mark & sweep; you can skip tracing down through objects who have nonzero reference counts until you are desperately short of memory, at which point you can trace down through those object trees and prune them (and there is where automated reference counting can really win with weak referencing, low-memory handlers or finalizers, and so forth - objects which are referenced but which are permitted to be purged in response to system behaviour are almost always part of a modern ref counting design.) Such approaches are orthogonal to precise vs conservative collection strategies.

Not very many languages can have tens or even hundreds of gigabytes (yes GB) of heap with GC pause times of 10 ms.

There are several large functional programming runtime environments which have worst-case bounded pauses measured in tens of machine instructions, and there is active research into avoiding ccNUMA waits during those worst-case periods.

JVM GC is getting better and is benefiting from the ongoing and diverse work in automatic memory management. However not even Hotspot is not a shining beacon of awesome memory management modernness. Its performance is poor compared to proprietary JVMs such as Azul Zing, which benefits from its continuous concurrent compacting collection (C4) GC system.

A better example of a big and popular open-source project beginning to use modern memory management techniques (and has actually been using even more modern JIT compilation (and dataflow-driven and profile-driven recompilation in frequently used code paths)) is the work Pizlo et al have been doing in WebKit (e.g. https://www.webkit.org/blog/33... or http://blog.llvm.org/2014/07/f... ). One of his slide decks makes the (pretty accurate) claim: "We took a dynamic language and made it fast!". Node.js is also a good example of increasing use of modern memory management in open source, lifting lots of material from V8.

And yet again you uncritically take promotional language as true. As someone who actually uses one of the languages supposedly supported by Dragonegg, I would say it would behoove you to look beyond the advertising copy.

Interesting, so you knew non-C languages were supported when you claimed otherwise. From dragon egg's current status, it works very well with Fortran and works well with Ada when using gcc 4.6. http://dragonegg.llvm.org/

Some benchmarks from 2011, so working with Fortran isn't a recent achievement. http://lists.cs.uiuc.edu/piper...

MacRuby (Apple is a contributor to the project) would be another example. http://macruby.org/

Me calling you a dumb fanboi is not angry name calling. It's a statement of fact, which you thankfully keep proving with every post.

As unreliable a "fact" as your "fact" of not being able to use non-C languages. Seriously, what gets you so outraged over the idea of being able to use either gcc or llvm, over the idea that llvm is usable with Fortran, Ruby, etc?

All they're offering are some existing tools, ones you can get for free. The main ones are the Clang static analyzer and Cppcheck. They're not offering free access to some of the better, and expensive, commercial tools.

Cppcheck is basically a list of common errors, expressed as rules with regular expressions. Clang is a little more advanced, but it's still looking for a short list of local bugs. Neither will detect all, or even most, buffer overflows. They'll detect the use of "strcpy", but not a wrong size to "strncpy".

All they're offering are some existing tools, ones you can get for free. The main ones are the Clang static analyzer and Cppcheck. They're not offering free access to some of the better, and expensive, commercial tools.

Cppcheck is basically a list of common errors, expressed as rules with regular expressions. Clang is a little more advanced, but it's still looking for a short list of local bugs. Neither will detect all, or even most, buffer overflows. They'll detect the use of "strcpy", but not a wrong size to "strncpy".

Development state doesn't matter? An incomplete frontend means I can't use LLVM for that language, so that makes LLVM specific to the frontends that actually do produce production-quality code: C-derived stuff and Haskell.

Actually the gcc front ends are available.
"dragonegg integrates the LLVM optimizers and code generator with the GCC parsers. This allows LLVM to compile Ada, Fortran, and other languages supported by the GCC compiler frontends, and access to C features not supported by Clang (such as OpenMP)." http://llvm.org/

I think you should see someone for those projection issues.

Says the angry name calling man ... seriously, re-evaluate.

Languages we have. Add on emscripten (a back end for LLVM) we have a healthy number of language. But do we have a framework for these to live in which can allow apps to expand out of the browser? And are the frameworks designed for anything other than the Java script world the browsers live in.

> Web applications may one day surpass desktop applications in function

An app built on top of a app on top of a framework will not surpass an app build directly on the framework in function. It may be easier to develop, but that is a different thing.

A setback yes, as now Xcode isn't free,

Xcode was and still is free-as-in-beer to Mac users, and was never free-as-in-speech.

The command-line compilers are still, as far as I know, free, but under the University of Illinois/NCSA Open Source License, which is "a lax, permissive non-copyleft free software license, compatible with the GNU GPL", rather than the GPL.

Clang is slightly faster than GCC, when compiling at the same optimization level.

Clang is written in C++ and modular, and as result of this, it is more embeddable in third party projects and it can target multiple platforms with a single executable. Work is being done in GCC to address this but I'm talking about released code here.

But when we consider less "hip" features, GCC makes faster code (which is usually the foremost interest of a compiler's user). And GCC supports more target platforms. And GCC supports more language features (FORTRAN, OpenMP, VLAIS).

A GCC developer's benchmark about GCC's vs clang's speed of compilation and of the resulting code.

Ah, thanks for the link to Chris! Found these 2 interesting docs.

* LLVM: A Compilation Framework for Lifelong Program Analysis & Transformation
http://llvm.org/pubs/2004-01-3...

* LLVA: A Low-level Virtual Instruction Set Architecture
http://llvm.org/pubs/2003-10-0...

Ah, thanks for the link to Chris! Found these 2 interesting docs.

* LLVM: A Compilation Framework for Lifelong Program Analysis & Transformation
http://llvm.org/pubs/2004-01-3...

* LLVA: A Low-level Virtual Instruction Set Architecture
http://llvm.org/pubs/2003-10-0...

Why does Apple use LLVM?
1. They hired Chris Lattner
2. LLVM has a more modern back-end (better suited to leverage high level optimization techniques across architectures, say x86, x86-64, PowerPC, Arm)

Of course copyright reassignment (or release to the public domain) is required for GCC contributions, LLVM only requires that copyright holder to agree to release the code under the terms of the LLVM license. Tight integration of the XCODE developer tools might be problematic had Apple stuck with GCC.

LLVM / Clang's acceptance of patent encumbered code from Apple, Qualcomm, and others makes LLVM technically unlawful to use for anyone who doesn't have a cross license agreement with these corporations.

The LLVM Developer Policy page section on patents says:

If you or your employer own the rights to a patent and would like to contribute code to LLVM that relies on it, we require that the copyright owner sign an agreement that allows any other user of LLVM to freely use your patent. Please contact the oversight group for more details.

Are you saying that Apple, Qualcomm, and others have not signed such an agreement? Or are you saying that such an agreement isn't sufficient to allow anyone who doesn't have a cross-license agreement with the patent holders to use LLVM?

Please update your FUD. GCC has supported a plugin architecture since 2010. You can use any GPL-compatible license for your plugin. This includes BSD, and in fact, there's a LLVM plugin for gcc.

What they can't do is micro-compile snippets of code to find errors, do auto-completion, etc...

I'll let the clang guys explain it better.

Why can't they just eliminate header files first?
Why is C/C++ practically the only language that requires headers?
Why do I need to type each function declaration twice. It is so cumbersome!

They are

Secondly, are their really compilers that would optimize away that if statement?

Probably. Here's an even more impressive example.

What bad habits? Logic of whatever type you want to implement is inherently sequential.

No, it is not. Logic is inherently reflexive and transitive. It's a major failing in math education, that people think it is about performing algorithms in sequence. Most people never learn the relations that allow you to rearrange the equations and create new algorithms.

In programming, the idea of sequential programming has problems. CPython guarantees that only one bytecode is executing at one time, and therefore they find it extremely difficult to remove the Global Interpreter Lock. C guarantees sequence only between sequence points, and makes liberal use of undefined behavior. Even Javascript, with its relatively simple model, has variable hoisting that catches beginners by surprise. Locking limits scalability, and shared-memory multi-threading is so difficult that it's believed that almost nobody knows how to do it properly. I think it was Crockford who said that the programmers who understand multi-threading should be captured and compelled to do systems programming, but I'm not sure.

Declarative and functional programming don't require execution in a particular sequence. The canonical example of this is Haskell, with its lazy evaluation, but logic programming is based on this idea, and even event-driven programming is like programming inside-out for a sequential programmer.

You really, really ought to read the link he gave you. It's quite eye-opening.

http://blog.llvm.org/2011/05/what-every-c-programmer-should-know_14.html

Okay, maybe it's too early in the morning but where exactly did this function cast an int* to a float*? Where's the "undefined behavior"?

Part 1 of the series has more. Here's the result, and then I'll explain:

"[The strict-aliasing rule] allows clang to optimize [zero_array] into "memset(P, 0, 40000)". This optimization also allows many loads to be hoisted out of loops, common subexpressions to be eliminated, etc. This class of undefined behavior can be disabled by passing the -fno-strict-aliasing flag, which disallows this analysis. When this flag is passed, Clang is required to compile this loop into 10000 4-byte stores (which is several times slower) because it has to assume that it is possible for any of the stores to change the value of P."

Now, for the explaination (I don't think the LLVM blog explains well):

That code, taken on its own, doesn't invoke violate the strict-aliasing rules or have UB. The UB would arise (unrelated, so far, to zero_array) if you wrote something like

P[0] = (float)&P;

If you did that and then called zero_array, what would happen (practically speaking, when there is no optimization) is that on the first iteration of the loop the compiler would write 0.0f at the address of P[0] = *(P+0) = *((float&P) = P, thus changing the value of P itself. On the next loop iteration, P would have changed.

The strict-aliasing rule allows the compiler to assume that P does not change between loop iterations, which allows it to generate better code.

And anyway, how is casting int* to float* undefined behavior?

The short answer is because "the standard says so".

But here's a very realistic situation for which forcing semantics would be very detrimental. Assume you're on a platform with 32-bit ints, 64-bit doubles, and for which a 64-bit memory load must be aligned to 8 bytes. (This is a very realistic architecture.) Now suppose you do a somewhat different type-punning cast:

void foo(double * pd) {
    printf("%f\n", *pd); // or whatever, I don't use printf much
}
 
void bar() {
    int x, y;
    foo((double*)&y);
}

What should this code do? If you run it on the architecture I said above with a naive compilation, it will probably bus error: probably x will be nicely-aligned but then y will probably be exactly not on an 8-byte boundary and when foo dereferences pd it will be a misaligned load.

In the absence of the strict-aliasing rule -- if the load from address pd had to produce at least some value -- the compiler would have to assume that every memory access it could not establish safe could potentially be misaligned, and either insert code to catch the trap if possible or perform the appropriate correction.

There are other ways in which the strict-aliasing rule makes sense (e.g. similar code but y is at the end of a page for which the next page isn't mapped), but that's probably the most convincing one I can come up with off the top of my head because most of the others would involve made up memory models and stuff that have probably never been built but are permitted by the standard anyway. :-)

No. You are confusing dereferencing a null pointer, which is in fact undefined, with checking a pointer for null which is 100% defined.

No, I'm not.You, I think, are confusing removing the null check because it's a null check (which of course doesn't make sense) with removing the null check because it is never false.

But please, feel free to explain what specific part of the post you replied to is wrong. And maybe you want to also inform Chris Lattner (director of Apple's Developer Tools division and founding author of LLVM, which was the subject of his Master's and PhD theses) about how he is confusing dereferencing a null pointer with checking a pointer for null (immediately after "This would give us these two steps:" he shows the optimization that you're claiming I'm wrong about, though he doesn't explicitly explain it), and maybe also John Regehr (CS prof at the Univ. of Utah who does program analysis research) about how his explanation is also wrong (see "A Fun Case Analysis").

You're never going to see this comment but one of the LLVM lead programmers outlines the reasons why the compiler can't always warn that the programmer has invoked undefined behaviour in C. He outlines three reasons:

1. Too many spurious warnings (warning generated when there's no bug)
2. It's hard to generate said warnings ONLY when people want them
3. No good way to tell the user how the situation occurred after X optimisations

The article outlines some steps programmers can take but ultimately concludes that C just isn't a "safe" language (but that's partly why it can go so fast).

Yes, you didn't RTFA, because your definition actually makes sense. TFA defines "unstable code" as code with undefined behavior.

...and undefined behavior is exactly what causes the things I listed.

TFA also claims that many compilers simply DELETE such code. I have never seen a compiler that does that, and I seriously doubt if is really common.

You probably haven't used any desktop compilers.

Just a sampling:

• During MS's security push a decade ago, they discovered that the compiler was optimizing away the memset in code such as memset(password, '\0', len); free(password); that was limiting the lifetime of sensitive information, because the assignment to password in the memset was a dead assignment -- it was never read from (not actually undefined behavior, but it is an example of the compiler deleting unused code that was actually there for a purpose)
• I linked part 3 of this series to you in another response, but the first example in here discusses such an optimization that GCC did which removed security checks in the Linux kernel (see also this series -- look down at "A Fun Case Analysis")
• GCC has long turned on -fno-strict-aliasing because optimizations based on the strict aliasing assumption break the kernel (more precisely: code that violates the standard's strict aliasing rules was being "mis-"optimized), though I don't know if it led to security implications

This blog post explains why they can't always warn about it.

Clang includes a number of compilation flags that can be used to make sure, or at least as sure as it can, that your code never hits any undefined behaviour at run time.

But normally, yes the compiler may change the behaviour of your application if you are depending on undefined behaviour.

"What every C programmer should know about undefined behaviour" (part 3, see links for first 2 parts).

For example, overflows of unsigned values is undefined behaviour in the C standard. Compilers can make decisions like using an instruction that traps on overflow if it would execute faster, or if that is the only operator available. Since overflowing might trap, and thus cause undefined behaviour, the compiler may assume that the programmer didn't intend for that to ever happen. Therefore this test will always evaluate to true, this code block is dead and can be eliminated.

This is why there are a number of compilation optimisations that gcc can perform, but which are disabled when building the linux kernel. With those optimisations, almost every memory address overflow test would be eliminated.

I think you're right about the importance of individual players, but the overall trend is unstoppable. Google, Apple, Microsoft, Yahoo and Mozilla all want JS to take over for different reasons. In contrast, none of those companies care about client-side Java, and some actively hate it.

I do think it's a bummer for groups with a lot of legacy Java. I wonder if it's possible to go from Java -> LLVM -> JS, using VMKit and Emscripten as starting points. Obviously it would be quite a process, but it could be less work than scrapping millions of lines of code.

For a good overview, take a look at Jakob Olesen's talk from EuroLLVM. Be warned, the talk contains a lot of simplifications (and is completely wrong if you're targeting anything like a GPU or DSP), but it's a good overview. For very recent chips and scientific workloads, it's also interesting that it often uses a lot less power (and is faster) to recompute intermediate results than to store them, if they won't fit in cache (sometimes even if they won't fit in L1 cache).

Does clang handle all the GCC extensions to C yet?

Clang Extensions

Writing a gtk-to-Qt translator say re-using the LLVM frontend would be a very nice Ph.D. project :)

No it wouldn't. I doubt that would even be a publishable paper in a decent conference. (I appear on both http://llvm.org/developers.cgi and http://llvm.org/pubs/ )