The underlying type of all plain enums in MSVC is 'int', even if the
enumerator contains large 32-bit unsigned values or values greater than
UINT_MAX. The only way to get a large or unsigned enum type is to
request it explicitly with the C++11 strong enum types feature.
However, since LLVM isn't C++11 yet, I had to add a conditional
LLVM_ENUM_INT_TYPE to Compiler.h to control its usage.
The motivating true positive for this change is compiling PointerIntPair
with MSVC for win64. The PointerIntMask value is supposed to be pointer
sized value of all ones with some low zeros. Instead, it's truncated to
32-bits! We are only saved later because it is sign extended back in
the AND with int64_t, and we happen to want all ones.
This silences lots of -Wmicrosoft warnings during a clang self-host
targeting Windows.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@191241 91177308-0d34-0410-b5e6-96231b3b80d8
This reverts r185841 and relands r185831 without using
__has_attribute(const).
Clang prior to r161767 (between 3.1 and 3.2) does not accept
__has_attribute(const) due to rdar://10253857. __const and __const__
are both keyword aliases of const, so they don't work either.
I was able to repro the buildbot failure using clang 3.1 and this patch
fixes it. Various important versions of XCode use clang 2.9-ish, so
this workaround is necessary.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@185850 91177308-0d34-0410-b5e6-96231b3b80d8
I tested r185831 by self-hosting clang with a recent clang, and got no
warnings. I haven't been able to reproduce the problem locally.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@185833 91177308-0d34-0410-b5e6-96231b3b80d8
When targetting Windows, clang does not define __GNUC__, and as a result
we don't use our attributes with it. This leads to warnings about
unused functions that are already annotated with LLVM_ATTRIBUTE_UNUSED.
Rather than testing for __clang__, we can use its __has_attribute and
__has_builtin macros directlty.
While I'm here, conditionally define and use __GNUC_PREREQ for gcc
version checks. Spelling the check out with three comparisons is
verbose and error prone.
Reviewers: aaron.ballman
Differential Revision: http://llvm-reviews.chandlerc.com/D1080
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@185831 91177308-0d34-0410-b5e6-96231b3b80d8
This change lets us bootstrap LLVM/Clang under ASan and MSan. It contains
fixes for 2 issues:
- X86JIT reads return address from stack, which MSan does not know is
initialized.
- bugpoint tests run binaries with RLIMIT_AS. This does not work with certain
Sanitizers.
We are no longer including config.h in Compiler.h with this change.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@174306 91177308-0d34-0410-b5e6-96231b3b80d8
Users of LLVM_BUILTIN_UNREACHABLE should be responsible in the case when LLVM_BUILTIN_UNREACHABLE is undefined.
Actually, (0, (p)) in LLVM_ASSUME_ALIGNED(p, a) caused thousands of warnings on g++-4.4. It was a motivation in this commit.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@171455 91177308-0d34-0410-b5e6-96231b3b80d8
* Add support for specifying the alignment to use.
* Add the concept of native endianness. Used for unaligned native types.
The native alignment and read/write simplification is based on a patch by Richard Smith.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@171406 91177308-0d34-0410-b5e6-96231b3b80d8
Rationale:
1) This was the name in the comment block. ;]
2) It matches Clang's __has_feature naming convention.
3) It matches other compiler-feature-test conventions.
Sorry for the noise. =]
I've also switch the comment block to use a \brief tag and not duplicate
the name.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@168996 91177308-0d34-0410-b5e6-96231b3b80d8
references from whether it supports an R-value reference *this. No
version of GCC today supports the latter, which breaks GCC C++11
compiles of LLVM and Clang now.
Also add doxygen comments clarifying what's going on here, and update
the usage in Optional. I'll update the usages in Clang next.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@168993 91177308-0d34-0410-b5e6-96231b3b80d8
This expands to '&', and is intended to be used when an /optional/ rvalue
override is available.
Before:
void foo() const { ... }
After:
void foo() const LLVM_LVALUE_FUNCTION { ... }
void foo() && { ... }
This is used to allow moving the contents of an Optional.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@168963 91177308-0d34-0410-b5e6-96231b3b80d8
Rationale: For each preprocessor macro, either the definedness is what's
meaningful, or the value is what's meaningful, or both. If definedness is
meaningful, we should use #ifdef. If the value is meaningful, we should use
and #ifdef interchangeably for the same macro, seems ugly to me, even if
undefined macros are zero if used.
This also has the benefit that including an LLVM header doesn't prevent
you from compiling with -Wundef -Werror.
Patch by John Garvin!
<rdar://problem/12189979>
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@163148 91177308-0d34-0410-b5e6-96231b3b80d8
Note that support for rvalue references does not imply support
for the full set of move-related STL operations.
I've preserved support for an odd little thing in insert() where
we're trying to support inserting a new element from an existing
one. If we actually want to support that, there's a lot more we
need to do: insert can call either grow or push_back, neither of
which is safe against this particular use pattern.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@155979 91177308-0d34-0410-b5e6-96231b3b80d8
It triggers generating insane executables with both binutils-2.19.1(msysgit) and 2.22.51.20111013(cygwin).
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@144621 91177308-0d34-0410-b5e6-96231b3b80d8
doesn't return, so just go back to using the old runtime function instead
of trying to use abort() when __builtin_unreachable (or an equivalent) isn't
supported.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@127629 91177308-0d34-0410-b5e6-96231b3b80d8
where none was before. Just don't declare it and hope it's declared
in every translation unit that needs it.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@127612 91177308-0d34-0410-b5e6-96231b3b80d8
smooshlab build. The breakage seems to be due to a collision
between LLVM's ATTRIBUTE_UNUSED and gcc's which was previously
hidden due to header files being included in a lucky order.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@117260 91177308-0d34-0410-b5e6-96231b3b80d8
The problem was that the test for whether a compiler supports it or not was
inaccurate, but has to be accurate: LLVM_LOCAL_VISIBILITY is an optimization
and not needed for correctness, so wrongly thinking a compiler doesn't support
it is not a big deal, but LLVM_GLOBAL_VISIBILITY is for correctness, and not
an optimization: getting it wrong is fatal: it needs to be set based on a
configure test not testing the gcc version. Since dragonegg has moved to a
different scheme, and it was the only user of LLVM_GLOBAL_VISIBILITY, just
remove this macro.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@113959 91177308-0d34-0410-b5e6-96231b3b80d8
