LLVM 2.9 released
| From: | Chris Lattner <clattner-AT-apple.com> | |
| To: | llvm-announce-AT-cs.uiuc.edu | |
| Subject: | LLVM 2.9 Release! | |
| Date: | Wed, 06 Apr 2011 23:15:54 -0700 | |
| Message-ID: | <49A8A4DF-1B00-4C5F-8328-CAB31374B196@apple.com> |
Hi LLVM Friends, Fans, Followers and Fanatics, LLVM 2.9 is out, get it while it is fresh and steaming! http://llvm.org/releases/ and read about it here: http://llvm.org/releases/2.9/docs/ReleaseNotes.html This release includes 6 months of development that provide major enhancements and new features over the LLVM 2.8 release. LLVM 2.9 includes much better optimization and code generation than LLVM 2.8 (particularly for modern ARM targets), improved support for C++'0x in Clang, and a much more mature LLDB (see http://lldb.llvm.org/). The LLVM 2.9 release notes cover the new features in LLVM in depth. Some of the major features include integrated assembler support for ELF targets (allowing direct object file writing), substantial improvements for Link Time Optimization (LTO) which make it build faster and able to compile large apps like Firefox 4, automatic recognition of memset and memcpy loops, debugging optimized code improvements, infrastructure for region based optimizations, better use of condition code registers, and progress on a major register allocator rewrite. One particularly notable aspect of this release is that it is the last of the 2.x series. One planned change in 3.0 is that we plan to drop the llvm-gcc 4.2 compiler. The Clang project provides a better solution for C based languages and the DragonEgg project provides a good solution for people interested in integrating LLVM with mainline GCC. This release would not be possible without our volunteer release team. Thanks to our release manager Bill Wendling, as well as Duncan Sands, Anton Korobeynikov, Dimitry Andric, and NAKAMURA Takumi for their work to qualify and shepherd the release. If you have questions or comments about this release, please contact the LLVMdev mailing list! Onward to LLVM 3.0! -Chris LLVM Release Announcement Linked List: http://lists.cs.uiuc.edu/pipermail/llvm-announce/2010-Oct...
Posted Apr 7, 2011 16:47 UTC (Thu)
by Hausvib6 (guest, #70606)
[Link] (15 responses)
Posted Apr 7, 2011 16:52 UTC (Thu)
by kripkenstein (guest, #43281)
[Link] (13 responses)
http://blog.mozilla.com/respindola/2011/02/04/clang-results/
Posted Apr 7, 2011 17:14 UTC (Thu)
by tao (subscriber, #17563)
[Link]
Posted Apr 7, 2011 17:28 UTC (Thu)
by tzafrir (subscriber, #11501)
[Link] (10 responses)
Next they'll compare Safary to the "latest Apple supported version of Firefox" (http://www.apple.com/downloads/macosx/internet_utilities/... - Firefox 3.6.12 ).
Interesting numbers (Datapoint: LLVM is good for building the Godzilla). But this is not a useful comparison. Any better one?
Posted Apr 7, 2011 17:47 UTC (Thu)
by zeekec (subscriber, #2414)
[Link] (9 responses)
Posted Apr 7, 2011 18:44 UTC (Thu)
by jetm (subscriber, #61129)
[Link] (7 responses)
Posted Apr 8, 2011 6:51 UTC (Fri)
by khim (subscriber, #9252)
[Link] (6 responses)
Posted Apr 8, 2011 8:08 UTC (Fri)
by renox (guest, #23785)
[Link] (5 responses)
Posted Apr 8, 2011 16:59 UTC (Fri)
by jwakely (subscriber, #60262)
[Link] (4 responses)
since most people just run "make" without changing CFLAGS that's not an unreasonable approach
Posted Apr 8, 2011 20:05 UTC (Fri)
by khim (subscriber, #9252)
[Link]
Well, sure. But we are not talking about most people. We are talking about people interested in benchmarks. These are not "most people". These people do care about flags so Phoronix benchmarks (as usual) are mostly useless. I suspected as much, but had no time to check, thnx for confirming that.
Posted Apr 10, 2011 7:22 UTC (Sun)
by salimma (subscriber, #34460)
[Link]
Posted Apr 14, 2011 10:43 UTC (Thu)
by cortana (subscriber, #24596)
[Link] (1 responses)
Posted Apr 14, 2011 13:12 UTC (Thu)
by ldarby (guest, #41318)
[Link]
If you're not going to squeeze the best performance out of it, what's the point of the benchmark? It would be like measuring how fast Olympic sprinters walk to the shops or something. Maybe that is what you want to measure, but it doesn't say who's fastest.
Posted Apr 8, 2011 3:12 UTC (Fri)
by Hausvib6 (guest, #70606)
[Link]
Posted Apr 7, 2011 17:28 UTC (Thu)
by jwakely (subscriber, #60262)
[Link]
I wonder what "things that you need to build Firefox on OS X" gcc doesn't support, as mentioned in the comments
Posted Apr 8, 2011 18:43 UTC (Fri)
by daglwn (guest, #65432)
[Link]
LLVM is a piece of the compiler. It's not the whole thing. But it's a necessary and very valuable piece. It's hard to overestimate the impact it's had in the programming tools field.
Posted Apr 7, 2011 20:45 UTC (Thu)
by scotthall (guest, #73671)
[Link] (29 responses)
Posted Apr 7, 2011 20:54 UTC (Thu)
by nix (subscriber, #2304)
[Link]
Posted Apr 7, 2011 23:08 UTC (Thu)
by cesarb (subscriber, #6266)
[Link] (26 responses)
Posted Apr 8, 2011 1:24 UTC (Fri)
by coriordan (guest, #7544)
[Link] (25 responses)
If any project wanted a compiler that just followed the spec, gcc has a "--pedantic" switch which disables all the extensions and deviations from the standard. I've never heard of anyone using this switch, so I guess everyone generally likes the design decisions of gcc.
Posted Apr 8, 2011 2:07 UTC (Fri)
by bk (guest, #25617)
[Link] (21 responses)
Actually I seem to remember one or two projects that use "-pedantic -ansi" by default, I just can't think of them off the top of my head.
Posted Apr 8, 2011 3:05 UTC (Fri)
by Trelane (subscriber, #56877)
[Link] (14 responses)
Posted Apr 10, 2011 8:33 UTC (Sun)
by lkundrak (subscriber, #43452)
[Link] (13 responses)
Posted Apr 11, 2011 8:25 UTC (Mon)
by mpr22 (subscriber, #60784)
[Link] (11 responses)
Posted Apr 11, 2011 17:01 UTC (Mon)
by wahern (subscriber, #37304)
[Link] (10 responses)
But I also disagree that -Werror shouldn't be used. I use it all the time. And when it breaks my code, rather than concede defeat I submit a patch. I submitted a patch to clang which added a switch to disable duplicate initializer warnings (like GCC has). It's valid and useful code and the C99 standard even specifies the behavior--the last initializer wins. I use it with compound literals and named initializers when I want an inline automatic object with default initializations:
struct options { int foo; int bar; };
do_blah(blah, opts(.foo = 14, .bar = 12))
It took me a couple of days to learn enough about clang to be able to submit the patch, but that's what the community is all about--scratching our own itches. It's a privilege but also a responsibility.
Posted Apr 11, 2011 18:03 UTC (Mon)
by mpr22 (subscriber, #60784)
[Link]
Posted Apr 12, 2011 8:04 UTC (Tue)
by jezuch (subscriber, #52988)
[Link] (8 responses)
The point of most of the warnings like that is that it *might* be a mistake, and the practice shows that it very often is. A variable that is assigned but not read might seem harmless, but it might mean that you intended to use it but made a typo and used something else instead. I tend to turn as many warnings like this as possible, not only for this reason, but also because I love removing unused code ;)
In the particular case quoted above it is of course a valid usage, but you should make it explicit, like this:
if ((foo = bar) == true) { ... }
No warning, no confusion. And BTW, an idiom like this is much more common in loops.
Posted Apr 12, 2011 9:05 UTC (Tue)
by dark (guest, #8483)
[Link] (2 responses)
Posted Apr 12, 2011 10:14 UTC (Tue)
by mpr22 (subscriber, #60784)
[Link]
Posted Apr 12, 2011 12:10 UTC (Tue)
by foom (subscriber, #14868)
[Link]
Posted Apr 12, 2011 10:47 UTC (Tue)
by cesarb (subscriber, #6266)
[Link] (2 responses)
What is wrong with
foo = bar;
I believe most cases of assignment within an if can be moved to just before the if.
This discussion makes more sense with a while, or perhaps with a more complex if condition. Even then, in a lot of cases I believe you could either move the assignment outside or use a for loop, without making the code more complex or writing the same assignment in two places.
Posted Apr 12, 2011 22:17 UTC (Tue)
by daglwn (guest, #65432)
[Link] (1 responses)
> foo = bar;
At least in C++, there's a scoping difference.
Posted Apr 13, 2011 10:26 UTC (Wed)
by mpr22 (subscriber, #60784)
[Link]
Posted Apr 13, 2011 20:12 UTC (Wed)
by vonbrand (subscriber, #4458)
[Link] (1 responses)
Just that it means something else entirely... if
Posted Apr 15, 2011 7:48 UTC (Fri)
by jezuch (subscriber, #52988)
[Link]
Doesn't matter; it's just an example. And since I come from a Java background, where this is a problem only in boolean context, I reflexively chose true :)
Posted Apr 12, 2011 17:33 UTC (Tue)
by hamjudo (guest, #363)
[Link]
It is easy to write a script in Perl, Python, or the scripting language of your choice to rewrite individual lines of code so they no longer trigger a warning. I'd re-enable one warning at a time. If it only showed up in a few places, I would rewrite them by hand. If there were hundreds or thousands of errors, then I would code a script. Keep in mind that gcc politely gives the line numbers and filenames for each warning. So the script didn't have to hunt down the noncompliant code, it just had to fix the lines known to trigger the warnings.
Being lazy, I coded the scripts to look for the most common safe ways that our programmers had annoyed gcc. When the script couldn't find a matching pattern, it would flag it for me to investigate. At least half of the time, the ones which didn't match my list of safe patterns were true bugs.
Likewise, in new code, the warnings were truly bad code at least half of the time.
Posted Apr 8, 2011 7:01 UTC (Fri)
by khim (subscriber, #9252)
[Link] (5 responses)
How can you prove that you code is correct WRT to pedantic if you don't use the flag? The project which care do use it: take a look here for example. The fact that most people out there don't care about quality can not change the fact that it's bad idea to blindly compile everything without -pedantic. In the rare cases where you REALLY need a GCC extension you can always use __extension__ - this way all such places are clearly marked in the code.
Posted Apr 8, 2011 7:45 UTC (Fri)
by mpr22 (subscriber, #60784)
[Link] (1 responses)
Posted Apr 8, 2011 20:21 UTC (Fri)
by khim (subscriber, #9252)
[Link]
Hmm... Perhaps it's recent change, but with GCC 4.4 everything works fine:
Posted Apr 8, 2011 11:24 UTC (Fri)
by coriordan (guest, #7544)
[Link] (2 responses)
"pedantic" is one dialect of C, and gnu99 is another. The former implements what some spec writers think developers should need, and the latter implements what developers have found necessary/useful. And practically everyone chooses the latter. No surprise, IMO.
Posted Apr 8, 2011 20:33 UTC (Fri)
by khim (subscriber, #9252)
[Link] (1 responses)
"Practically everyone"? Pushlease. Most developers chooses different dialect or C (and C++). The fact that people don't like to write standard-conformant code is unfotunate, but don't fool yourself: GCC users are still a minority. "Mobile revolution" looks promising, but then it'll introduce yet-another-dialect-of-C (the one discussed here today) so I'm not sure G99 will have any hope of obtaining majority, let alone reaching status of "practically everyone".
Posted Apr 9, 2011 8:26 UTC (Sat)
by mpr22 (subscriber, #60784)
[Link]
Posted Apr 8, 2011 10:46 UTC (Fri)
by cesarb (subscriber, #6266)
[Link] (1 responses)
Did you ever take a look at some of those things?
RELOC_HIDE
Not to mention all the code which depends on the optimizer eliminating dead code (often one of the dead branches is a reference to a nonexistent function, to make the linker complain if the dead branches were not eliminated). Often using __builtin_constant_p and variants.
There are several more; these are just the ones I could remember off the top of my head.
Posted Apr 8, 2011 10:50 UTC (Fri)
by cesarb (subscriber, #6266)
[Link]
The ones which do not follow the official C specification still abuse the gcc extensions.
Posted Apr 21, 2011 13:03 UTC (Thu)
by PaXTeam (guest, #24616)
[Link]
Posted Apr 8, 2011 6:17 UTC (Fri)
by danieldk (subscriber, #27876)
[Link]
Posted Apr 24, 2011 19:26 UTC (Sun)
by mlopezibanez (guest, #66088)
[Link]
http://events.linuxfoundation.org/events/collaboration-su...
I find interesting that there was a whole session about LLVM and, even more, that Mark Mitchell was there speaking about LLVM ecosystem.
LLVM 2.9 released
LLVM 2.9 released
LLVM 2.9 released
LLVM 2.9 released
LLVM 2.9 released
LLVM 2.9 released
Well, few years back GCC had a very clear lead, so that's good result. Not enough to switch to LLVM, obviously, but good nonetheless.
And this is GOOD
And this is GOOD
And this is GOOD
Well, yes and usual Phoronix should be taken with huge grain of salt...
since most people just run "make" without changing CFLAGS that's not an unreasonable approach
And this is GOOD
And this is GOOD
And this is GOOD
LLVM 2.9 released
LLVM 2.9 released
LLVM 2.9 released
LLVM 2.9 released
LLVM 2.9 released
LLVM 2.9 released
LLVM 2.9 released
LLVM 2.9 released
LLVM 2.9 released
LLVM 2.9 released
I'm sure that's a rhetorical question, but I don't think the answer to the last sentence of your comment is quite what you think it is. My answers are "maybe" and "yes", respectively.
LLVM 2.9 released
LLVM 2.9 released
#define FOO_DEFAULT 7
#define opts(...) (&(struct options){ .foo = FOO_DEFAULT, __VA_ARGS__ })
OK, I'll concede that it might merely be mindblowingly bad style instead of broken - but the compiler's warning profile does not have that luxury, thanks to the ease with which one can typo the equality operator as the simple-assignment operator. Anyone who knowingly uses "if (foo = bar) { ... }" shouldn't; to me, it smacks of "job security".
LLVM 2.9 released
LLVM 2.9 released
I think that depends on your idiom :) It's commonly used like this:
LLVM 2.9 released
if (result = check_something()) {
do_something_with(result);
}
It's particularly handy if "check_something" is a regexp match. As a matter of style, it's a good way of emphasizing the if-then logic of the check more than the role of 'result'.
I'm not a huge fan of that construct either. (What we really need is an alternative form for the simple assignment operator so that we don't need syntactic salt or "yes I meant to do that" comment annotations.)
LLVM 2.9 released
LLVM 2.9 released
<pre>
if (char *str = get_str()) {
do_something_with(str);
}
</pre>
is valid C++. Pretty handy. :)
LLVM 2.9 released
if (foo) { ... }
LLVM 2.9 released
> if (foo) { ... }
The C++ (think it works in C99 too, but not sure) construct that gives you the scoping restriction also gives the compiler (and any human observer reviewing the code) enough information to be absolutely sure you meant "assign" instead of "compare". (It's still fugly, but that's life. :-)
LLVM 2.9 released
LLVM 2.9 released
bar's value isn't the same as true, your version of the condition fails, while the original only fails if bar == 0.LLVM 2.9 released
I worked on a proprietary software package with 15 to 25 full time programmers. We used -Werror and -Wall on the nightly build for years, and they were still using it when I left. You can disable individual warnings, if desired. When we first turned on -Werror and -Wall, we had to disable many warnings. We were down to only about 4 when I left.LLVM 2.9 released
Hmm?
Haven't got a current GCC handy, but there are certainly extensions which you can't make -pedantic not complain about in 4.3.2 - case ranges being the one I just checked.
Hmm?
Are you sure?
$ cat test.c
#include <stdio.h>
int main(int argc, char **argv) {
__extension__ (({
switch (argc) {
case 0 ... 5:
printf("0 ... 5");
break;
default:
printf("default");
break;
}
}));
return 0;
}
$ gcc --version
gcc-4.4 (Ubuntu 4.4.3-4ubuntu5) 4.4.3
Copyright (C) 2009 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
$ gcc -ansi -pedantic ./test.c -o test
$ ./test 1
0 ... 5
$ ./test 1 2 3 4 5 6
defaultHmm?
Actually no.
And practically everyone chooses the latter.
The GNU compiler supports every platform that might conceivably be of interest to me, including the only one MSVC supports. I see no reason to go out of my way to ignore its extensions, or ram syntactic salt into my code to get their use approved. (As it happens, I largely avoid its extensions.)
Actually no.
Compiler abuse
"#define if" (CONFIG_PROFILE_ALL_BRANCHES)
BUILD_BUG_ON and variants
_THIS_IP_
asmlinkage_protect
Compiler abuse
LLVM 2.9 released
LLVM 2.9 released
LLVM 2.9 released