git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@195236 91177308-0d34-0410-b5e6-96231b3b80d8

Summary:
Currently with clang:
$ clang -O20 foo.c
error: invalid value '20' in '-O20'

With the patch:
$ clang -O20 foo.c
warning: optimization level '-O20' is unsupported; using '-O3' instead.
1 warning generated.

This matches the gcc behavior (with a warning added)

Pass all tests:
Testing: 0 .. 10.. 20.. 30.. 40.. 50.. 60.. 70.. 80.. 90..
Testing Time: 94.14s
  Expected Passes    : 6721
  Expected Failures  : 20
  Unsupported Tests  : 17

(which was not the case of http://llvm-reviews.chandlerc.com/D2125)

Differential Revision: http://llvm-reviews.chandlerc.com/D2212

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@195009 91177308-0d34-0410-b5e6-96231b3b80d8

Trying to fix test failures since earlier today.

One of the tests added in this commit is outputting test/Driver/clang_f_opts.s
which the builders that build in-tree (eg. clang-native-arm-cortex-a9) are
trying to run as a test case, causing failures.

clang_f_opts.c:
  If -### doesn't emit the warning then this test probably shouldn't be in
  here in the first place. Frontend maybe?

invalid-o-level.c:
  Running %clang_cc1 in the Driver tests doesn't make sense because -cc1
  bypasses the driver. (I'm not reverting the commit that introduced this but
  please fix instead of keeping it this way.)

Reverting to fix the build failures and also so that the tests can be thought
out more thoroughly.

This reverts commit r194817.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@194845 91177308-0d34-0410-b5e6-96231b3b80d8

Summary:
Currently with clang:
$ clang -O20 foo.c
error: invalid value '20' in '-O20'

With the patch:
$ clang -O20 foo.c
warning: optimization level '-O20' is unsupported; using '-O3' instead.
1 warning generated.

This matches the gcc behavior (with a warning added)

Pass all tests:
Testing: 0 .. 10.. 20.. 30.. 40.. 50.. 60.. 70.. 80.. 90..
Testing Time: 94.14s
  Expected Passes    : 6721
  Expected Failures  : 20
  Unsupported Tests  : 17

(which was not the case of http://llvm-reviews.chandlerc.com/D2125)

Reviewers: chandlerc, rafael, rengolin, hfinkel

Reviewed By: rengolin

CC: cfe-commits

Differential Revision: http://llvm-reviews.chandlerc.com/D2152

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@194817 91177308-0d34-0410-b5e6-96231b3b80d8

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@194368 91177308-0d34-0410-b5e6-96231b3b80d8

limited ways) after the next release. See the lengthy discussions (which
are on-going) and the corresponding commit to LLVM's release notes.
Nothing is actually changing at this point, this is just further
spreading the plan.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@194184 91177308-0d34-0410-b5e6-96231b3b80d8

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@192808 91177308-0d34-0410-b5e6-96231b3b80d8

 - "clang -O3 -flto a.c -c", and 
 - "clang -emit-llvm a.c -c" 

Thank Rafael for tips.


git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@189150 91177308-0d34-0410-b5e6-96231b3b80d8

We now saturate at -O3.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@189149 91177308-0d34-0410-b5e6-96231b3b80d8

A class with a field of non-POD-for-layout type is not POD-for-layout.
This computation should not depend on whether the field is of POD type
in the language sense.

Fixes PR16537.

Patch by Josh Magee.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@186741 91177308-0d34-0410-b5e6-96231b3b80d8

This will enable users in security critical applications to perform
checked-arithmetic in a fast safe manner that is amenable to c.

Tests/an update to Language Extensions is included as well.

rdar://13421498.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@184497 91177308-0d34-0410-b5e6-96231b3b80d8

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@184148 91177308-0d34-0410-b5e6-96231b3b80d8

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@183211 91177308-0d34-0410-b5e6-96231b3b80d8

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@182294 91177308-0d34-0410-b5e6-96231b3b80d8

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@182280 91177308-0d34-0410-b5e6-96231b3b80d8

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@180585 91177308-0d34-0410-b5e6-96231b3b80d8

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@180582 91177308-0d34-0410-b5e6-96231b3b80d8

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@180178 91177308-0d34-0410-b5e6-96231b3b80d8

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@179094 91177308-0d34-0410-b5e6-96231b3b80d8

http://lab.llvm.org:8011/builders/clang-x86_64-darwin10-gdb went back green
before it processed the reverted 178663, so it could not have been the culprit.

Revert "Revert 178663."

This reverts commit 4f8a3eb2.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@178682 91177308-0d34-0410-b5e6-96231b3b80d8

Looks like it broke http://lab.llvm.org:8011/builders/clang-x86_64-darwin10-gdb

Revert "Don't compute a patched/semantic storage class."

This reverts commit 8f187f62.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@178681 91177308-0d34-0410-b5e6-96231b3b80d8

For variables and functions clang used to store two storage classes. The one
"as written" in the code and a patched one, which, for example, propagates
static to the following decls.

This apparently is from the days clang lacked linkage computation. It is now
redundant and this patch removes it.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@178663 91177308-0d34-0410-b5e6-96231b3b80d8

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@175971 91177308-0d34-0410-b5e6-96231b3b80d8

After changing the way several value inheritance hierarchies (TypeLoc,
CFGelement, ProgramPoint and SVal) handle casting, this documentation describes
how 3rd party code may need to be updated to compile with the new APIs.

As suggested by Sean Silva on cfe-dev.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@175970 91177308-0d34-0410-b5e6-96231b3b80d8

I'm using the name "Extended Identifiers" for the feature because that's
what GCC calls them. According to the standard, the new feature is
"universal character names are now allowed in identifiers", but the more
interesting "feature" is that identifiers can now contain Unicode characters,
however they are written.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@174798 91177308-0d34-0410-b5e6-96231b3b80d8

Even though we do have a `.. warning::` directive on the page, hopefully
having "In-Progress" in the title will help to condition people's
expectations a bit for when they run into the extremely bare-bones
release notes.

Also, when release season comes around again, maybe this will get
people's attention and avoid confusion about what is going into the
upcoming release, and what is for changes to trunk for the next version.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@171419 91177308-0d34-0410-b5e6-96231b3b80d8

This is the last of the "regular" documents to convert to reST, and so
I'm declaring the initial clang reST conversion "done".

However,

- There are some documents in clang/www/ which probably should
  be migrated into clang/docs/, such as www/OpenProjects.html

  The primary thing blocking me from doing this right now is not knowing
  how to set up a redirect so that the old URL's continue to work.

- LibASTMatchersReference.html is not reST. This page is auto-generated
  by clang/docs/tools/dump_ast_matchers.py from the source and has some
  collapse/expand logic that isn't expressible directly with Sphinx, so
  just converting it to reST is not really a good strategy.

  Manuel Klimek and I discussed this and the general agreed-upon
  direction is making that page data-driven so that it, say, pulls in an
  auto-generated blob of JSON which describes the matchers and builds up
  the "matcher reference" part of the page with a small amount of JS.

- There are some rogue .txt files hanging around.

Also, I dropped the little dragon logo at the top because Sphinx was
warning about an external image reference (not sure why, but meh, I
didn't want to fight it). If anything, we would want such a logo
integrated into the site's overall theme, rather than hardcoded here.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@170994 91177308-0d34-0410-b5e6-96231b3b80d8