Hi All, The first draft of the llvm 2.2 release notes are now available: http://llvm.org/docs/ReleaseNotes.html The release is scheduled for Monday, so please take a look at them and send me your feedback, or (better yet) just commit fixes directly to the document in llvm/docs/ReleaseNotes.html. In addition to editing improvements I'm particularly interested in adding missing things to the document and getting credit to the right people. Please don't be shy about letting me know if I got something wrong. The release is an amazing release, LLVM 2.2 rocks! -Chris
On Feb 10, 2008, at 12:25 AM, Chris Lattner wrote:> Hi All, > > The first draft of the llvm 2.2 release notes are now available: > http://llvm.org/docs/ReleaseNotes.html > > The release is scheduled for Monday, so please take a look at them and > send me your feedback, or (better yet) just commit fixes directly to > the document in llvm/docs/ReleaseNotes.html. In addition to editing > improvements I'm particularly interested in adding missing things to > the document and getting credit to the right people. Please don't be > shy about letting me know if I got something wrong.This is a matter of presentation, but some of the "GCC extensions" are standard C99 (now, at least). I noticed long long, C++-style comments and designated initializers. I have plenty of complaints about the GCC documentation you're pointing at, but this probably isn't the right forum for that. I do think dropping "as fast as macros" from the "inline" description would be a good idea, that's pure propaganda: sometimes it's true and sometimes it isn't. The miscompilation of code containing both MMX vectors and long double may be worth a mention, but it probably isn't going to bite very many people. (llvm does not insert EMMS everywhere it needs to, or from a different viewpoint, uses MMX when the user didn't tell it to.) Giving me credit for darwin x86-64 EH is an overstatement, I just made minor mods to existing EH code (Anton's I think). Looks good overall.
> This is a matter of presentation, but some of the "GCC extensions" are > standard C99 (now, at least). I noticed long long, C++-style comments > and designated initializers. > > I have plenty of complaints about the GCC documentation you're > pointing at, but this probably isn't the right forum for that. I do > think dropping "as fast as macros" from the "inline" description would > be a good idea, that's pure propaganda: sometimes it's true and > sometimes it isn't.I completely agree with you here. It looks like the GCC docs were written vs C90 not C99. That whole section of the documentation was more useful when there were a lot of GCC features we didn't support. Now it looks like it can be ripped out and we can just keep a list of things that don't work in our own words. Lets do this for the llvm 2.3 release notes though, after Monday.> The miscompilation of code containing both MMX vectors and long double > may be worth a mention, but it probably isn't going to bite very many > people. (llvm does not insert EMMS everywhere it needs to, or from a > different viewpoint, uses MMX when the user didn't tell it to.)AFAIK, many commonly used GCC versions don't do this either. If that's the case, I don't think it's worth mentioning, because most people will be concerned with "llvm regressions vs gcc" or something. I believe that if you explicitly use mmx intrinsics you have to insert emms yourself, and that the only other way to get mmx badness is through use of the gcc generic vector extension. If this is true, I think we should be ok.> Giving me credit for darwin x86-64 EH is an overstatement, I just made > minor mods to existing EH code (Anton's I think).Ok, I'll say 'dale and anton' thanks! -Chris