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
to LLVM_LIBRARY_VISIBILITY and introduce LLVM_GLOBAL_VISIBILITY, which is
the opposite, for future use by dragonegg.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@103495 91177308-0d34-0410-b5e6-96231b3b80d8
mainly used in debugging and/or assert situations. It should make the compiler
and the static analyzer stop nagging us about them.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@92181 91177308-0d34-0410-b5e6-96231b3b80d8
as the isSigned bool to CreateIntCast by having this resolve to a call
to a private method, rather than by using a gcc attribute.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@89067 91177308-0d34-0410-b5e6-96231b3b80d8
parameter of CreateIntCast then they get an error from the compiler
(or from the linker with a non-gcc compiler). Another possibility
is to flip the order of the DestTy and isSigned parameters, since you
should then get a compiler warning if you try to use a char* for a
Type*.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@88913 91177308-0d34-0410-b5e6-96231b3b80d8
This will replace exit()/abort() style error handling with an API
that allows clients to register custom error handling hooks.
The default is to call exit(1) when no error handler is provided.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@74922 91177308-0d34-0410-b5e6-96231b3b80d8
- Use for exceptional buffer conditions in raw_ostream:write to shave
off a cycle or two.
- Please rename if you have a better one.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@67103 91177308-0d34-0410-b5e6-96231b3b80d8
