MSVC 2013 requires the argument to __declspec(align()) to be an integer
constant expression that doesn't involve any identifiers like sizeof.
For GCC and Clang, LLVM_PTR_SIZE is equivalent to __SIZEOF_POINTER__,
which dates back to GCC 4.6 and Clang 2010. If that's not available, we
get sizeof(void*), which works with alignas() and
__attribute__((aligned())).
For MSVC, LLVM_PTR_SIZE is 4 or 8 depending on _WIN64.
llvm-svn: 233929
We wrap __attribute((aligned)) for GCC 4.7 and __declspec(align) for
MSVC. The latter behaves weird in some contexts so this should be used
carefully.
llvm-svn: 233910
On Windows, we now use RaiseException to generate the kind of trap we require (one which calls our vectored exception handler), and fall back to using a volatile write to simulate a trap elsewhere.
llvm-svn: 228691
between the linker's TLS optimizations and Clang's TLS code generation.
For now, Clang has been changed to disable linker TLS optimizations
until it (and LLVM more generally) are emitting TLS code sequences
compatible with the old bugs found in the linkers. That's a better fix
to handle bootstrapping on that platform.
llvm-svn: 227511
to get a powerpc64 host so that I can reproduce and test this, but it
only impacts that platform so trying the only other realistic option.
According to Ulrich, who debugged this initially, initial-exec is likely
to be sufficient for our needs and not subject to this bug. Will watch
the build bots to see.
If this doesn't work, I'll be forced to cut a really ugly pthread-based
approach into the primary user (our stack trace printing) as that user
cannot use the ThreadLocal implementation due to lifetime issues.
llvm-svn: 227414
entirely when threads are not enabled. This should allow anyone who
needs to bootstrap or cope with a host loader without TLS support to
limp along without threading support.
There is still some bug in the PPC TLS stuff that is not worked around.
I'm getting access to a machine to reproduce and debug this further.
There is some chance that I'll have to add a terrible workaround for
PPC.
There is also some problem with iOS, but I have no ability to really
evaluate what the issue is there. I'm leaving it to folks maintaining
that platform to suggest a path forward -- personally I don't see any
useful path forward that supports threading in LLVM but does so without
support for *very basic* TLS. Note that we don't need more than some
pointers, and we don't need constructors, destructors, or any of the
other fanciness which remains widely unimplemented.
llvm-svn: 227411
We shouldn't put this kind of attribute stuff in DataTypes.h.
Leave the END_WITH_NULL name for now so I can update clang without
making build spam.
llvm-svn: 221215
Unconditional noexcept support was added in the VS 2013 Nov CTP. Given
that there have been three CTPs since then, I don't think we need
careful macro magic to target that specific tech preview. Instead,
target the major release version number of 1900, which corresponds to
the as-yet unreleased VS "14".
llvm-svn: 221169
We have to use _MSC_FULL_VER here as CTP 2 and earlier didn't define
noexcept to my knowledge.
Fixes build error in lib/Support/Error.cpp when inheriting from
std::error_category, which has a noexcept virtual method.
llvm-svn: 221013
This requires incorporating __GNUC_PATCHLEVEL__ into our prerequisite
check, and renaming our __GNUC_PREREQ to LLVM_GNUC_PREREQ, since it is
now functionally different.
Patch by Chilledheart!
Differential Revision: http://reviews.llvm.org/D5879
llvm-svn: 220332
In both Clang and LLVM, this is a common pattern:
Size = sizeof(DeclRefExpr) + SomeExtraStuff;
void *Mem = Context.Allocate(Size, llvm::alignOf<DeclRefExpr>());
return new (Mem) DeclRefExpr(...);
The annoying thing is that because the default placement-new operator has a
nothrow specification, the compiler will insert a null check of Mem before
calling the DeclRefExpr constructor. This null check is redundant for us,
because we expect the allocation functions to never return null.
By annotating the allocator functions with returns_nonnull, we can optimize
away these checks. Compiling clang with a recent version of Clang and measuring
with:
$ perf stat -r20 bin/clang.patch -fsyntax-only -w gcc.c && perf stat -r20 bin/clang.orig -fsyntax-only -w gcc.c
Shows a 2.4% speed-up (+- 0.8%).
The pattern occurs in LLVM too. Measuring with -O3 (and now using bzip2.c
instead, because it's smaller):
$ perf stat -r20 bin/clang.patch -O3 -w bzip2.c && perf stat -r20 bin/clang.orig -O3 -w bzip2.c
Shows 4.4 % speed-up (+- 1%).
If anyone knows of a similar attribute we can use for MSVC, or some other
technique to get rid off the null check there, please let me know.
Differential Revision: http://reviews.llvm.org/D4989
llvm-svn: 216192
to the build being C++11.
There is clearly still plenty of simplification than can be done here by
using standard type traits instead of rolling our own in many places.
llvm-svn: 202586
on the fact that we now build in C++11 mode with modern compilers. This
should flush out any issues. If the build bots are happy with this, I'll
GC all the code for coping without R-value references.
llvm-svn: 202574
According to http://gcc.gnu.org/projects/cxx0x.html,
override and final keyword was added in gcc 4.7. Thus,
we should not use these keywords in gcc 4.6 even when
__GXX_EXPERIMENTAL_CXX0X__ is available.
llvm-svn: 201679
The motivation is to mark dump methods as used in debug builds so that they can
be called from lldb, but to not do so in release builds so that they can be
dead-stripped.
There's lots of potential follow-up work suggested in the thread
"Should dump methods be LLVM_ATTRIBUTE_USED only in debug builds?" on cfe-dev,
but everyone seems to agreen on this subset.
Macro name chosen by fair coin toss.
llvm-svn: 198456
Back out the part of r198399 that enabled LLVM_FINAL/LLVM_OVERRIDE on VS 2010.
DwarfUnit.h legitimately uses them on destructors which unfortunately triggers
Compiler Error C3665 (override specifier not allowed on a destructor/finalizer)
prior to MSVC 2012:
virtual ~DwarfCompileUnit() LLVM_OVERRIDE;
llvm-svn: 198401
The 'sealed' definition of LLVM_FINAL can be dropped once VS 2010 is
decommissioned.
Some of this is speculative so will keep an eye on the waterfall -- ping me if
you see failures.
Incremental work towards C++11 migration.
llvm-svn: 198399
lib/Support/ThreadLocal.cpp:53:15: error: typedef 'SIZE_TOO_BIG' locally defined but not used [-Werror=unused-local-typedefs]
typedef int SIZE_TOO_BIG[sizeof(pthread_key_t) <= sizeof(data) ? 1 : -1];
Done the C++11 way, switching on and using LLVM_STATIC_ASSERT() instead of LLVM_ATTRIBUTE_UNUSED.
llvm-svn: 198255
