1<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" 2 "http://www.w3.org/TR/html4/strict.dtd"> 3<html> 4<head> 5 <meta http-equiv="Content-Type" content="text/html; charset=utf-8"> 6 <title>How To Release LLVM To The Public</title> 7 <link rel="stylesheet" href="_static/llvm.css" type="text/css"> 8</head> 9<body> 10 11<h1>How To Release LLVM To The Public</h1> 12<ol> 13 <li><a href="#introduction">Introduction</a></li> 14 <li><a href="#criteria">Qualification Criteria</a></li> 15 <li><a href="#introduction">Release Timeline</a></li> 16 <li><a href="#process">Release Process</a></li> 17</ol> 18<div class="doc_author"> 19 <p>Written by <a href="mailto:tonic@nondot.org">Tanya Lattner</a>, 20 <a href="mailto:rspencer@x10sys.com">Reid Spencer</a>, 21 <a href="mailto:criswell@cs.uiuc.edu">John Criswell</a>, & 22 <a href="mailto:wendling@apple.com">Bill Wendling</a> 23 </p> 24</div> 25 26<!-- *********************************************************************** --> 27<h2><a name="introduction">Introduction</a></h2> 28<!-- *********************************************************************** --> 29 30<div> 31 32<p>This document contains information about successfully releasing LLVM — 33 including subprojects: e.g., <tt>clang</tt> and <tt>dragonegg</tt> — to 34 the public. It is the Release Manager's responsibility to ensure that a high 35 quality build of LLVM is released.</p> 36 37</div> 38 39<!-- *********************************************************************** --> 40<h2><a name="process">Release Timeline</a></h2> 41<!-- *********************************************************************** --> 42<div> 43 44<p>LLVM is released on a time based schedule — roughly every 6 months. We 45 do not normally have dot releases because of the nature of LLVM's incremental 46 development philosophy. That said, the only thing preventing dot releases for 47 critical bug fixes from happening is a lack of resources — testers, 48 machines, time, etc. And, because of the high quality we desire for LLVM 49 releases, we cannot allow for a truncated form of release qualification.</p> 50 51<p>The release process is roughly as follows:</p> 52 53<ul> 54 <li><p>Set code freeze and branch creation date for 6 months after last code 55 freeze date. Announce release schedule to the LLVM community and update 56 the website.</p></li> 57 58 <li><p>Create release branch and begin release process.</p></li> 59 60 <li><p>Send out release candidate sources for first round of testing. Testing 61 lasts 7-10 days. During the first round of testing, any regressions found 62 should be fixed. Patches are merged from mainline into the release 63 branch. Also, all features need to be completed during this time. Any 64 features not completed at the end of the first round of testing will be 65 removed or disabled for the release.</p></li> 66 67 <li><p>Generate and send out the second release candidate sources. Only 68 <em>critial</em> bugs found during this testing phase will be fixed. Any 69 bugs introduced by merged patches will be fixed. If so a third round of 70 testing is needed.</p></li> 71 72 <li><p>The release notes are updated.</p></li> 73 74 <li><p>Finally, release!</p></li> 75</ul> 76 77</div> 78 79<!-- *********************************************************************** --> 80<h2><a name="process">Release Process</a></h2> 81<!-- *********************************************************************** --> 82 83<div> 84 85<ol> 86 <li><a href="#release-admin">Release Administrative Tasks</a> 87 <ol> 88 <li><a href="#branch">Create Release Branch</a></li> 89 <li><a href="#verchanges">Update Version Numbers</a></li> 90 </ol> 91 </li> 92 <li><a href="#release-build">Building the Release</a> 93 <ol> 94 <li><a href="#dist">Build the LLVM Source Distributions</a></li> 95 <li><a href="#build">Build LLVM</a></li> 96 <li><a href="#clangbin">Build the Clang Binary Distribution</a></li> 97 <li><a href="#target-build">Target Specific Build Details</a></li> 98 </ol> 99 </li> 100 <li><a href="#release-qualify">Release Qualification Criteria</a> 101 <ol> 102 <li><a href="#llvm-qualify">Qualify LLVM</a></li> 103 <li><a href="#clang-qualify">Qualify Clang</a></li> 104 <li><a href="#targets">Specific Target Qualification Details</a></li> 105 </ol> 106 </li> 107 108 <li><a href="#commTest">Community Testing</a></li> 109 <li><a href="#release-patch">Release Patch Rules</a></li> 110 <li><a href="#release-final">Release final tasks</a> 111 <ol> 112 <li><a href="#updocs">Update Documentation</a></li> 113 <li><a href="#tag">Tag the LLVM Final Release</a></li> 114 <li><a href="#updemo">Update the LLVM Demo Page</a></li> 115 <li><a href="#webupdates">Update the LLVM Website</a></li> 116 <li><a href="#announce">Announce the Release</a></li> 117 </ol> 118 </li> 119</ol> 120 121<!-- ======================================================================= --> 122<h3><a name="release-admin">Release Administrative Tasks</a></h3> 123 124<div> 125 126<p>This section describes a few administrative tasks that need to be done for 127 the release process to begin. Specifically, it involves:</p> 128 129<ul> 130 <li>Creating the release branch,</li> 131 <li>Setting version numbers, and</li> 132 <li>Tagging release candidates for the release team to begin testing</li> 133</ul> 134 135<!-- ======================================================================= --> 136<h4><a name="branch">Create Release Branch</a></h4> 137 138<div> 139 140<p>Branch the Subversion trunk using the following procedure:</p> 141 142<ol> 143 <li><p>Remind developers that the release branching is imminent and to refrain 144 from committing patches that might break the build. E.g., new features, 145 large patches for works in progress, an overhaul of the type system, an 146 exciting new TableGen feature, etc.</p></li> 147 148 <li><p>Verify that the current Subversion trunk is in decent shape by 149 examining nightly tester and buildbot results.</p></li> 150 151 <li><p>Create the release branch for <tt>llvm</tt>, <tt>clang</tt>, 152 the <tt>test-suite</tt>, and <tt>dragonegg</tt> from the last known good 153 revision. The branch's name is <tt>release_<i>XY</i></tt>, 154 where <tt>X</tt> is the major and <tt>Y</tt> the minor release 155 numbers. The branches should be created using the following commands:</p> 156 157<div class="doc_code"> 158<pre> 159$ svn copy https://llvm.org/svn/llvm-project/llvm/trunk \ 160 https://llvm.org/svn/llvm-project/llvm/branches/release_<i>XY</i> 161 162$ svn copy https://llvm.org/svn/llvm-project/cfe/trunk \ 163 https://llvm.org/svn/llvm-project/cfe/branches/release_<i>XY</i> 164 165$ svn copy https://llvm.org/svn/llvm-project/dragonegg/trunk \ 166 https://llvm.org/svn/llvm-project/dragonegg/branches/release_<i>XY</i> 167 168$ svn copy https://llvm.org/svn/llvm-project/test-suite/trunk \ 169 https://llvm.org/svn/llvm-project/test-suite/branches/release_<i>XY</i> 170</pre> 171</div></li> 172 173 <li><p>Advise developers that they may now check their patches into the 174 Subversion tree again.</p></li> 175 176 <li><p>The Release Manager should switch to the release branch, because all 177 changes to the release will now be done in the branch. The easiest way to 178 do this is to grab a working copy using the following commands:</p> 179 180<div class="doc_code"> 181<pre> 182$ svn co https://llvm.org/svn/llvm-project/llvm/branches/release_<i>XY</i> llvm-<i>X.Y</i> 183 184$ svn co https://llvm.org/svn/llvm-project/cfe/branches/release_<i>XY</i> clang-<i>X.Y</i> 185 186$ svn co https://llvm.org/svn/llvm-project/dragonegg/branches/release_<i>XY</i> dragonegg-<i>X.Y</i> 187 188$ svn co https://llvm.org/svn/llvm-project/test-suite/branches/release_<i>XY</i> test-suite-<i>X.Y</i> 189</pre> 190</div></li> 191</ol> 192 193</div> 194 195<!-- ======================================================================= --> 196<h4><a name="verchanges">Update LLVM Version</a></h4> 197 198<div> 199 200<p>After creating the LLVM release branch, update the release branches' 201 <tt>autoconf</tt> and <tt>configure.ac</tt> versions from '<tt>X.Ysvn</tt>' 202 to '<tt>X.Y</tt>'. Update it on mainline as well to be the next version 203 ('<tt>X.Y+1svn</tt>'). Regenerate the configure scripts for both 204 <tt>llvm</tt> and the <tt>test-suite</tt>.</p> 205 206<p>In addition, the version numbers of all the Bugzilla components must be 207 updated for the next release.</p> 208 209</div> 210 211<!-- ======================================================================= --> 212<h4><a name="dist">Build the LLVM Release Candidates</a></h4> 213 214<div> 215 216<p>Create release candidates for <tt>llvm</tt>, <tt>clang</tt>, 217 <tt>dragonegg</tt>, and the LLVM <tt>test-suite</tt> by tagging the branch 218 with the respective release candidate number. For instance, to 219 create <b>Release Candidate 1</b> you would issue the following commands:</p> 220 221<div class="doc_code"> 222<pre> 223$ svn mkdir https://llvm.org/svn/llvm-project/llvm/tags/RELEASE_<i>XY</i> 224$ svn copy https://llvm.org/svn/llvm-project/llvm/branches/release_<i>XY</i> \ 225 https://llvm.org/svn/llvm-project/llvm/tags/RELEASE_<i>XY</i>/rc1 226 227$ svn mkdir https://llvm.org/svn/llvm-project/cfe/tags/RELEASE_<i>XY</i> 228$ svn copy https://llvm.org/svn/llvm-project/cfe/branches/release_<i>XY</i> \ 229 https://llvm.org/svn/llvm-project/cfe/tags/RELEASE_<i>XY</i>/rc1 230 231$ svn mkdir https://llvm.org/svn/llvm-project/dragonegg/tags/RELEASE_<i>XY</i> 232$ svn copy https://llvm.org/svn/llvm-project/dragonegg/branches/release_<i>XY</i> \ 233 https://llvm.org/svn/llvm-project/dragonegg/tags/RELEASE_<i>XY</i>/rc1 234 235$ svn mkdir https://llvm.org/svn/llvm-project/test-suite/tags/RELEASE_<i>XY</i> 236$ svn copy https://llvm.org/svn/llvm-project/test-suite/branches/release_<i>XY</i> \ 237 https://llvm.org/svn/llvm-project/test-suite/tags/RELEASE_<i>XY</i>/rc1 238</pre> 239</div> 240 241<p>Similarly, <b>Release Candidate 2</b> would be named <tt>RC2</tt> and so 242 on. This keeps a permanent copy of the release candidate around for people to 243 export and build as they wish. The final released sources will be tagged in 244 the <tt>RELEASE_<i>XY</i></tt> directory as <tt>Final</tt> 245 (c.f. <a href="#tag">Tag the LLVM Final Release</a>).</p> 246 247<p>The Release Manager may supply pre-packaged source tarballs for users. This 248 can be done with the following commands:</p> 249 250<div class="doc_code"> 251<pre> 252$ svn export https://llvm.org/svn/llvm-project/llvm/tags/RELEASE_<i>XY</i>/rc1 llvm-<i>X.Y</i>rc1 253$ svn export https://llvm.org/svn/llvm-project/cfe/tags/RELEASE_<i>XY</i>/rc1 clang-<i>X.Y</i>rc1 254$ svn export https://llvm.org/svn/llvm-project/dragonegg/tags/RELEASE_<i>XY</i>/rc1 dragonegg-<i>X.Y</i>rc1 255$ svn export https://llvm.org/svn/llvm-project/test-suite/tags/RELEASE_<i>XY</i>/rc1 llvm-test-<i>X.Y</i>rc1 256 257$ tar -cvf - llvm-<i>X.Y</i>rc1 | gzip > llvm-<i>X.Y</i>rc1.src.tar.gz 258$ tar -cvf - clang-<i>X.Y</i>rc1 | gzip > clang-<i>X.Y</i>rc1.src.tar.gz 259$ tar -cvf - dragonegg-<i>X.Y</i>rc1 | gzip > dragonegg-<i>X.Y</i>rc1.src.tar.gz 260$ tar -cvf - llvm-test-<i>X.Y</i>rc1 | gzip > llvm-test-<i>X.Y</i>rc1.src.tar.gz 261</pre> 262</div> 263 264</div> 265 266</div> 267 268<!-- ======================================================================= --> 269<h3><a name="release-build">Building the Release</a></h3> 270 271<div> 272 273<p>The builds of <tt>llvm</tt>, <tt>clang</tt>, and <tt>dragonegg</tt> 274 <em>must</em> be free of errors and warnings in Debug, Release+Asserts, and 275 Release builds. If all builds are clean, then the release passes Build 276 Qualification.</p> 277 278<p>The <tt>make</tt> options for building the different modes:</p> 279 280<table> 281 <tr><th>Mode</th><th>Options</th></tr> 282 <tr align="left"><td>Debug</td><td><tt>ENABLE_OPTIMIZED=0</tt></td></tr> 283 <tr align="left"><td>Release+Asserts</td><td><tt>ENABLE_OPTIMIZED=1</tt></td></tr> 284 <tr align="left"><td>Release</td><td><tt>ENABLE_OPTIMIZED=1 DISABLE_ASSERTIONS=1</tt></td></tr> 285</table> 286 287<!-- ======================================================================= --> 288<h4><a name="build">Build LLVM</a></h4> 289 290<div> 291 292<p>Build <tt>Debug</tt>, <tt>Release+Asserts</tt>, and <tt>Release</tt> versions 293 of <tt>llvm</tt> on all supported platforms. Directions to build 294 <tt>llvm</tt> are <a href="GettingStarted.html#quickstart">here</a>.</p> 295 296</div> 297 298<!-- ======================================================================= --> 299<h4><a name="clangbin">Build Clang Binary Distribution</a></h4> 300 301<div> 302 303<p>Creating the <tt>clang</tt> binary distribution 304 (Debug/Release+Asserts/Release) requires performing the following steps for 305 each supported platform:</p> 306 307<ol> 308 <li>Build clang according to the directions 309 <a href="http://clang.llvm.org/get_started.html">here</a>.</li> 310 311 <li>Build both a Debug and Release version of clang. The binary will be the 312 Release build.</lI> 313 314 <li>Package <tt>clang</tt> (details to follow).</li> 315</ol> 316 317</div> 318 319<!-- ======================================================================= --> 320<h4><a name="target-build">Target Specific Build Details</a></h4> 321 322<div> 323 324<p>The table below specifies which compilers are used for each Arch/OS 325 combination when qualifying the build of <tt>llvm</tt>, <tt>clang</tt>, 326 and <tt>dragonegg</tt>.</p> 327 328<table> 329 <tr><th>Architecture</th> <th>OS</th> <th>compiler</th></tr> 330 <tr><td>x86-32</td> <td>Mac OS 10.5</td> <td>gcc 4.0.1</td></tr> 331 <tr><td>x86-32</td> <td>Linux</td> <td>gcc 4.2.X, gcc 4.3.X</td></tr> 332 <tr><td>x86-32</td> <td>FreeBSD</td> <td>gcc 4.2.X</td></tr> 333 <tr><td>x86-32</td> <td>mingw</td> <td>gcc 3.4.5</td></tr> 334 <tr><td>x86-64</td> <td>Mac OS 10.5</td> <td>gcc 4.0.1</td></tr> 335 <tr><td>x86-64</td> <td>Linux</td> <td>gcc 4.2.X, gcc 4.3.X</td></tr> 336 <tr><td>x86-64</td> <td>FreeBSD</td> <td>gcc 4.2.X</td></tr> 337</table> 338 339</div> 340 341</div> 342 343<!-- ======================================================================= --> 344<h3><a name="release-qualify">Building the Release</a></h3> 345 346<div> 347 348<p>A release is qualified when it has no regressions from the previous release 349 (or baseline). Regressions are related to correctness first and performance 350 second. (We may tolerate some minor performance regressions if they are 351 deemed necessary for the general quality of the compiler.)</p> 352 353<p><b>Regressions are new failures in the set of tests that are used to qualify 354 each product and only include things on the list. Every release will have 355 some bugs in it. It is the reality of developing a complex piece of 356 software. We need a very concrete and definitive release criteria that 357 ensures we have monotonically improving quality on some metric. The metric we 358 use is described below. This doesn't mean that we don't care about other 359 criteria, but these are the criteria which we found to be most important and 360 which must be satisfied before a release can go out</b></p> 361 362<!-- ======================================================================= --> 363<h4><a name="llvm-qualify">Qualify LLVM</a></h4> 364 365<div> 366 367<p>LLVM is qualified when it has a clean test run without a front-end. And it 368 has no regressions when using either <tt>clang</tt> or <tt>dragonegg</tt> 369 with the <tt>test-suite</tt> from the previous release.</p> 370 371</div> 372 373<!-- ======================================================================= --> 374<h4><a name="clang-qualify">Qualify Clang</a></h4> 375 376<div> 377 378<p><tt>Clang</tt> is qualified when front-end specific tests in the 379 <tt>llvm</tt> dejagnu test suite all pass, clang's own test suite passes 380 cleanly, and there are no regressions in the <tt>test-suite</tt>.</p> 381 382</div> 383 384<!-- ======================================================================= --> 385<h4><a name="targets">Specific Target Qualification Details</a></h4> 386 387<div> 388 389<table> 390 <tr><th>Architecture</th> <th>OS</th> <th>clang baseline</th> <th>tests</th></tr> 391 <tr><td>x86-32</td> <td>Linux</td> <td>last release</td> <td>llvm dejagnu, clang tests, test-suite (including spec)</td></tr> 392 <tr><td>x86-32</td> <td>FreeBSD</td> <td>last release</td> <td>llvm dejagnu, clang tests, test-suite</td></tr> 393 <tr><td>x86-32</td> <td>mingw</td> <td>none</td> <td>QT</td></tr> 394 <tr><td>x86-64</td> <td>Mac OS 10.X</td> <td>last release</td> <td>llvm dejagnu, clang tests, test-suite (including spec)</td></tr> 395 <tr><td>x86-64</td> <td>Linux</td> <td>last release</td> <td>llvm dejagnu, clang tests, test-suite (including spec)</td></tr> 396 <tr><td>x86-64</td> <td>FreeBSD</td> <td>last release</td> <td>llvm dejagnu, clang tests, test-suite</td></tr> 397</table> 398 399</div> 400 401</div> 402 403<!-- ======================================================================= --> 404<h3><a name="commTest">Community Testing</a></h3> 405<div> 406 407<p>Once all testing has been completed and appropriate bugs filed, the release 408 candidate tarballs are put on the website and the LLVM community is 409 notified. Ask that all LLVM developers test the release in 2 ways:</p> 410 411<ol> 412 <li>Download <tt>llvm-<i>X.Y</i></tt>, <tt>llvm-test-<i>X.Y</i></tt>, and the 413 appropriate <tt>clang</tt> binary. Build LLVM. Run <tt>make check</tt> and 414 the full LLVM test suite (<tt>make TEST=nightly report</tt>).</li> 415 416 <li>Download <tt>llvm-<i>X.Y</i></tt>, <tt>llvm-test-<i>X.Y</i></tt>, and the 417 <tt>clang</tt> sources. Compile everything. Run <tt>make check</tt> and 418 the full LLVM test suite (<tt>make TEST=nightly report</tt>).</li> 419</ol> 420 421<p>Ask LLVM developers to submit the test suite report and <tt>make check</tt> 422 results to the list. Verify that there are no regressions from the previous 423 release. The results are not used to qualify a release, but to spot other 424 potential problems. For unsupported targets, verify that <tt>make check</tt> 425 is at least clean.</p> 426 427<p>During the first round of testing, all regressions must be fixed before the 428 second release candidate is tagged.</p> 429 430<p>If this is the second round of testing, the testing is only to ensure that 431 bug fixes previously merged in have not created new major problems. <i>This 432 is not the time to solve additional and unrelated bugs!</i> If no patches are 433 merged in, the release is determined to be ready and the release manager may 434 move onto the next stage.</p> 435 436</div> 437 438<!-- ======================================================================= --> 439<h3><a name="release-patch">Release Patch Rules</a></h3> 440 441<div> 442 443<p>Below are the rules regarding patching the release branch:</p> 444 445<ol> 446 <li><p>Patches applied to the release branch may only be applied by the 447 release manager.</p></li> 448 449 <li><p>During the first round of testing, patches that fix regressions or that 450 are small and relatively risk free (verified by the appropriate code 451 owner) are applied to the branch. Code owners are asked to be very 452 conservative in approving patches for the branch. We reserve the right to 453 reject any patch that does not fix a regression as previously 454 defined.</p></li> 455 456 <li><p>During the remaining rounds of testing, only patches that fix critical 457 regressions may be applied.</p></li> 458</ol> 459 460</div> 461 462<!-- ======================================================================= --> 463<h3><a name="release-final">Release Final Tasks</a></h3> 464 465<div> 466 467<p>The final stages of the release process involves tagging the "final" release 468 branch, updating documentation that refers to the release, and updating the 469 demo page.</p> 470 471<!-- ======================================================================= --> 472<h4><a name="updocs">Update Documentation</a></h4> 473 474<div> 475 476<p>Review the documentation and ensure that it is up to date. The "Release 477 Notes" must be updated to reflect new features, bug fixes, new known issues, 478 and changes in the list of supported platforms. The "Getting Started Guide" 479 should be updated to reflect the new release version number tag available from 480 Subversion and changes in basic system requirements. Merge both changes from 481 mainline into the release branch.</p> 482 483</div> 484 485<!-- ======================================================================= --> 486<h4><a name="tag">Tag the LLVM Final Release</a></h4> 487 488<div> 489 490<p>Tag the final release sources using the following procedure:</p> 491 492<div class="doc_code"> 493<pre> 494$ svn copy https://llvm.org/svn/llvm-project/llvm/branches/release_XY \ 495 https://llvm.org/svn/llvm-project/llvm/tags/RELEASE_<i>XY</i>/Final 496 497$ svn copy https://llvm.org/svn/llvm-project/cfe/branches/release_XY \ 498 https://llvm.org/svn/llvm-project/cfe/tags/RELEASE_<i>XY</i>/Final 499 500$ svn copy https://llvm.org/svn/llvm-project/dragonegg/branches/release_XY \ 501 https://llvm.org/svn/llvm-project/dragonegg/tags/RELEASE_<i>XY</i>/Final 502 503$ svn copy https://llvm.org/svn/llvm-project/test-suite/branches/release_XY \ 504 https://llvm.org/svn/llvm-project/test-suite/tags/RELEASE_<i>XY</i>/Final 505</pre> 506</div> 507 508</div> 509 510</div> 511 512<!-- ======================================================================= --> 513<h3><a name="updemo">Update the LLVM Demo Page</a></h3> 514 515<div> 516 517<p>The LLVM demo page must be updated to use the new release. This consists of 518 using the new <tt>clang</tt> binary and building LLVM.</p> 519 520<!-- ======================================================================= --> 521<h4><a name="webupdates">Update the LLVM Website</a></h4> 522 523<div> 524 525<p>The website must be updated before the release announcement is sent out. Here 526 is what to do:</p> 527 528<ol> 529 <li>Check out the <tt>www</tt> module from Subversion.</li> 530 531 <li>Create a new subdirectory <tt>X.Y</tt> in the releases directory.</li> 532 533 <li>Commit the <tt>llvm</tt>, <tt>test-suite</tt>, <tt>clang</tt> source, 534 <tt>clang binaries</tt>, <tt>dragonegg</tt> source, and <tt>dragonegg</tt> 535 binaries in this new directory.</li> 536 537 <li>Copy and commit the <tt>llvm/docs</tt> and <tt>LICENSE.txt</tt> files 538 into this new directory. The docs should be built with 539 <tt>BUILD_FOR_WEBSITE=1</tt>.</li> 540 541 <li>Commit the <tt>index.html</tt> to the <tt>release/X.Y</tt> directory to 542 redirect (use from previous release.</li> 543 544 <li>Update the <tt>releases/download.html</tt> file with the new release.</li> 545 546 <li>Update the <tt>releases/index.html</tt> with the new release and link to 547 release documentation.</li> 548 549 <li>Finally, update the main page (<tt>index.html</tt> and sidebar) to point 550 to the new release and release announcement. Make sure this all gets 551 committed back into Subversion.</li> 552</ol> 553 554</div> 555 556<!-- ======================================================================= --> 557<h4><a name="announce">Announce the Release</a></h4> 558 559<div> 560 561<p>Have Chris send out the release announcement when everything is finished.</p> 562 563</div> 564 565</div> 566 567</div> 568 569<!-- *********************************************************************** --> 570<hr> 571<address> 572 <a href="http://jigsaw.w3.org/css-validator/check/referer"><img 573 src="http://jigsaw.w3.org/css-validator/images/vcss-blue" alt="Valid CSS"></a> 574 <a href="http://validator.w3.org/check/referer"><img 575 src="http://www.w3.org/Icons/valid-html401-blue" alt="Valid HTML 4.01"></a> 576 <a href="http://llvm.org/">The LLVM Compiler Infrastructure</a> 577 <br> 578 Last modified: $Date$ 579</address> 580</body> 581</html> 582