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

instruction used the ReturnValue as pointer operand or value operand. This
led to wrong code gen - in later stages (load-store elision code) the found
store and its operand would be erased, causing ReturnValue to become a <badref>.

The patch adds a check that makes sure that ReturnValue is a pointer operand of
store instruction. Regression test is also added.

This fixes PR24386.
Differential Revision: http://reviews.llvm.org/D12400


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

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

Currently, the documentation for numSelectorArgs includes an incorrect
example. It shows a case where an argument of 1 will match a property
getter, but a getter will be matched only when N == 0.

This diff corrects the documentation and adds a test for numSelectorArgs(0).

Patch by Dave Lee.

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

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

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

coincidence on all bots.

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

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

separately from building the instruction so that it's
preserved even in -Asserts builds.

Employ C++'s mystical "comment" feature to discourage
breaking this in the future.

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

single-pointer overload instead of the ArrayRef one.

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

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

Introduce an Address type to bundle a pointer value with an
alignment.  Introduce APIs on CGBuilderTy to work with Address
values.  Change core APIs on CGF/CGM to traffic in Address where
appropriate.  Require alignments to be non-zero.  Update a ton
of code to compute and propagate alignment information.

As part of this, I've promoted CGBuiltin's EmitPointerWithAlignment
helper function to CGF and made use of it in a number of places in
the expression emitter.

The end result is that we should now be significantly more correct
when performing operations on objects that are locally known to
be under-aligned.  Since alignment is not reliably tracked in the
type system, there are inherent limits to this, but at least we
are no longer confused by standard operations like derived-to-base
conversions and array-to-pointer decay.  I've also fixed a large
number of bugs where we were applying the complete-object alignment
to a pointer instead of the non-virtual alignment, although most of
these were hidden by the very conservative approach we took with
member alignment.

Also, because IRGen now reliably asserts on zero alignments, we
should no longer be subject to an absurd but frustrating recurring
bug where an incomplete type would report a zero alignment and then
we'd naively do a alignmentAtOffset on it and emit code using an
alignment equal to the largest power-of-two factor of the offset.

We should also now be emitting much more aggressive alignment
attributes in the presence of over-alignment.  In particular,
field access now uses alignmentAtOffset instead of min.

Several times in this patch, I had to change the existing
code-generation pattern in order to more effectively use
the Address APIs.  For the most part, this seems to be a strict
improvement, like doing pointer arithmetic with GEPs instead of
ptrtoint.  That said, I've tried very hard to not change semantics,
but it is likely that I've failed in a few places, for which I
apologize.

ABIArgInfo now always carries the assumed alignment of indirect and
indirect byval arguments.  In order to cut down on what was already
a dauntingly large patch, I changed the code to never set align
attributes in the IR on non-byval indirect arguments.  That is,
we still generate code which assumes that indirect arguments have
the given alignment, but we don't express this information to the
backend except where it's semantically required (i.e. on byvals).
This is likely a minor regression for those targets that did provide
this information, but it'll be trivial to add it back in a later
patch.

I partially punted on applying this work to CGBuiltin.  Please
do not add more uses of the CreateDefaultAligned{Load,Store}
APIs; they will be going away eventually.

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

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

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

Transferred SSSE3 instructions from sse-builtins.c


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

Transferred SSE41 instructions from sse-builtins.c

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

Differential Revision: http://reviews.llvm.org/D11299

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

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

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

Expose the previously unexposed visibility attribute via the python and C
bindings.

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

Apparently there are many cast kinds that may cause implicit pointer
arithmetic to happen. In light of this, the cast ignoring logic
introduced in r246877 has been changed to only ignore a small set of
cast kinds, and a test for this behavior has been added.

Thanks to Richard for catching this before it became a bug report. :)



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

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

We were crashing in CodeGen given input like this:

  int self_alias(void) __attribute__((weak, alias("self_alias")));

such a self-alias is invalid, but instead of diagnosing the situation, we'd
proceed to produce IR for both the function declaration and the alias. Because
we already had a function named 'self_alias', the alias could not be named the
same thing, and so LLVM would pick a different name ('self_alias1' for example)
for that value. When we later called CodeGenModule::checkAliases, we'd look up
the IR value corresponding to the alias name, find the function declaration
instead, and then assert in a cast to llvm::GlobalAlias. The easiest way to prevent
this is simply to avoid creating the wrongly-named alias value in the first
place and issue the diagnostic there (instead of in checkAliases). We detect a
related cycle case in CodeGenModule::EmitAliasDefinition already, so this just
adds a second such check.

Even though the other test cases for this 'alias definition is part of a cycle'
diagnostic are in test/Sema/attr-alias-elf.c, I've added a separate regression
test for this case. This is because I can't add this check to
test/Sema/attr-alias-elf.c without disturbing the other test cases in that
file. In order to avoid construction of the bad IR values, this diagnostic
is emitted from within CodeGenModule::EmitAliasDefinition (and the relevant
declaration is not added to the Aliases vector). The other cycle checks are
done within the CodeGenModule::checkAliases function based on the Aliases
vector, called from CodeGenModule::Release.  However, if there have been errors
earlier, HandleTranslationUnit does not call Release, and so checkAliases is
never called, and so none of the other diagnostics would be produced.

Fixes PR23509.

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

directory, and our frontend action cares whether the frontend setup actually
succeeded.


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

This fixes an issue raised in D12412, where we generated invalid IR.

Thanks to Vedant Kumar for coming up with the initial work around.

Differential Revision: http://reviews.llvm.org/D12412

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

Improvements:

- For all types, we would give up in a case such as:
    __builtin_object_size((char*)&foo, N);
  even if we could provide an answer to
    __builtin_object_size(&foo, N);
  We now provide the same answer for both of the above examples in all
  cases.

- For type=1|3, we now support subobjects with unknown bases, as long
  as the designator is valid.

Thanks to Richard Smith for the review + design planning.

Review: http://reviews.llvm.org/D12169



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

They might technically have external linkage, but it still doesn't make sense
for the user to try and export such variables. This matches MSVC's and MinGW's
behaviour.

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

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

If we build with -Werror=implicit-function-declaration, only implicit
function declarations of non-library functions throw compiler errors.
For library functions, we only produce a warning. There is no way to
promote both of these cases to an error without promoting other
warnings.

It makes little sense to introduce an additional compiler flag just to
control this specific warning. In my opinion it should just be part of
the same group.


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

Some of instantiation-dependent expressions could cause false diagnostic to be emitted about unsupported atomic constructs. Relaxed rules for detection of incorrect expressions.


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

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

clang/test/SemaCXX/sourceranges.cpp: Appease win32. Class method is thiscall for targeting i686-(msvc|mingw32).

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

Fix processing of shared variables with reference types in OpenMP constructs. Previously, if the variable was not marked in one of the private clauses, the reference to this variable was emitted incorrectly and caused an assertion later.


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

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

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

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

Patch allows to recognize additional registers x8d, x8b, x8w - x15d, x15b, x15w in inline assembler, already recognized by backend
Differential Revision: http://reviews.llvm.org/D12594


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

simplify the implementation a bit.


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

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

Differential Revision: http://reviews.llvm.org/D12445 



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