| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
| |
llvm-svn: 232559
|
| |
|
|
|
|
| |
This was an omission from r232229.
llvm-svn: 232554
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
The HandlerMap describes, to the runtime, what sort of catches surround
the try. In principle, this structure has to be emitted by the backend
because only it knows the layout of the stack (the runtime needs to know
where on the stack the destination of a copy lives, etc.) but there is
some C++ specific information that the backend can't reason about.
Stick this information in special LLVM globals with the relevant
"const", "volatile", "reference" info mangled into the name.
llvm-svn: 232538
|
| |
|
|
| |
llvm-svn: 232537
|
| |
|
|
|
| |
Review: http://reviews.llvm.org/D8097
llvm-svn: 232533
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
scope ends
Previously, we would error out on this code because the default argument
wasn't parsed until the end of Outer:
struct __declspec(dllexport) Outer {
struct __declspec(dllexport) Inner {
Inner(void *p = 0);
};
};
Now we do the checking on the closing brace of Outer instead of Inner.
llvm-svn: 232519
|
| |
|
|
|
|
|
|
| |
initializer list reference temporaries to global variables."
This caused PR22940.
llvm-svn: 232496
|
| |
|
|
|
|
| |
to global variables.
llvm-svn: 232454
|
| |
|
|
|
|
|
|
|
| |
This exposes the optional exit block placement logic from r232438 as a
clang -cc1 option. There is a test on the llvm side, but there isn't
really a way to inspect the gcov options from clang to test it here as
well.
llvm-svn: 232439
|
| |
|
|
| |
llvm-svn: 232353
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Qualifiers are located next to the TypeDescriptor in order to properly
ensure that a pointer type can only be caught by a more qualified catch
handler. This means that a catch handler of type 'const int *' requires
an RTTI object for 'int *'. We got this correct for 'throw' but not for
'catch'.
N.B. We don't currently have the means to store the qualifiers because
LLVM's EH strategy is tailored to the Itanium scheme. The Itanium ABI
stores qualifiers inside the type descriptor in such a way that the
manner of qualification is stored in addition to the pointee type's
descriptor. Perhaps the best way of modeling this for the MS ABI is
using an aggregate type to bundle the qualifiers with the descriptor?
This is tricky because we want to make it clear to the optimization
passes which catch handlers invalidate other handlers.
My current thoughts on a design for this is along the lines of:
{ { TypeDescriptor* TD, i32 QualifierFlags }, i32 MiscFlags }
The idea is that the inner most aggregate is all that is needed to
communicate that one catch handler might supercede another. The
'MiscFlags' field would be used to hold the bitpattern for the notion
that the 'catch' handler does not need to invoke a copy-constructor
because we are catching by reference.
llvm-svn: 232318
|
| |
|
|
|
|
|
| |
CGCXXABI has a handy getContext() method. Use that instead of
explicitly going through the CodeGenModule.
llvm-svn: 232289
|
| |
|
|
|
|
|
|
| |
It is possible to construct an initializer for a bitfield which is not
constant. Instead of emitting code to initialize the field before the
execution of main, clang would crash.
llvm-svn: 232285
|
| |
|
|
|
|
|
|
|
|
|
| |
This scheme checks that pointer and lvalue casts are made to an object of
the correct dynamic type; that is, the dynamic type of the object must be
a derived class of the pointee type of the cast. The checks are currently
only introduced where the class being casted to is a polymorphic class.
Differential Revision: http://reviews.llvm.org/D8312
llvm-svn: 232241
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The MS ABI utilizes a compiler generated function called the "vector
constructor iterator" to construct arrays of objects with
non-trivial constructors/destructors. For this to work, the constructor
must follow a specific calling convention. A thunk must be created if
the default constructor has default arguments, is variadic or is
otherwise incompatible. This thunk is called the default constructor
closure.
N.B. Default constructor closures are only generated if the default
constructor is exported because clang itself does not utilize vector
constructor iterators. Failing to export the default constructor
closure will result in link/load failure if a translation unit compiled
with MSVC is on the import side.
Differential Revision: http://reviews.llvm.org/D8331
llvm-svn: 232229
|
| |
|
|
|
|
|
|
|
| |
std::make_exception_ptr calls std::__GetExceptionInfo in order to figure
out how to properly copy the exception object.
Differential Revision: http://reviews.llvm.org/D8280
llvm-svn: 232188
|
| |
|
|
| |
llvm-svn: 232154
|
| |
|
|
| |
llvm-svn: 232130
|
| |
|
|
| |
llvm-svn: 232122
|
| |
|
|
|
|
|
|
|
|
|
| |
This is complicated by the fact that we can't simply use side-effecting
calls in an argument list without losing all guarantees about the order
they're emitted. To keep things deterministic we use tuples and brace
initialization, which thankfully guarantees evaluation order.
No functionality change intended.
llvm-svn: 232121
|
| |
|
|
|
|
|
|
|
| |
A nullptr exception object can be caught by any pointer type catch
handler. However, it is not possible to express this in the exception
info for the MS ABI. As a middle ground, allow such exception objects
to be caught with pointer-to-void catch handlers.
llvm-svn: 232069
|
| |
|
|
|
|
| |
assertions in debug builds with Visual Studio), use data() + size() to calculate the end iterator. Amends r231952.
llvm-svn: 232037
|
| |
|
|
|
|
| |
Differential Revision: http://reviews.llvm.org/D7138
llvm-svn: 232036
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
If only one section is found in the sections region, it is emitted just like single region.
Otherwise it is emitted as a static non-chunked loop.
#pragma omp sections
{
#pragma omp section
{1}
...
#pragma omp section
{n}
}
is translated to something like
i32 <iter_var>
i32 <last_iter> = 0
i32 <lower_bound> = 0
i32 <upper_bound> = n-1
i32 <stride> = 1
call void @__kmpc_for_static_init_4(<loc>, i32 <gtid>, i32 34/*static non-chunked*/, i32* <last_iter>, i32* <lower_bound>, i32* <upper_bound>, i32* <stride>, i32 1/*increment always 1*/, i32 1/*chunk always 1*/)
<upper_bound> = min(<upper_bound>, n-1)
<iter_var> = <lb>
check:
br <iter_var> <= <upper_bound>, label cont, label exit
continue:
switch (IV) {
case 0:
{1};
break;
...
case <NumSection> - 1:
{n};
break;
}
++<iter_var>
br label check
exit:
call void @__kmpc_for_static_fini(<loc>, i32 <gtid>)
Differential Revision: http://reviews.llvm.org/D8244
llvm-svn: 232021
|
| |
|
|
|
|
| |
__builtin_longjmp to Sema as requested by John McCall.
llvm-svn: 231986
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Support for the QPX vector instruction set, used on the IBM BG/Q supercomputer,
has recently been added to the LLVM PowerPC backend. This vector instruction
set requires some ABI modifications because the ABI on the BG/Q expects
<4 x double> vectors to be provided with 32-byte stack alignment, and to be
handled as native vector types (similar to how Altivec vectors are handled on
mainline PPC systems). I've named this ABI variant elfv1-qpx, have made this
the default ABI when QPX is supported, and have updated the ABI handling code
to provide QPX vectors with the correct stack alignment and associated
register-assignment logic.
llvm-svn: 231960
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This adds support for copy-constructor closures. These are generated
when the C++ runtime has to call a copy-constructor with a particular
calling convention or with default arguments substituted in to the call.
Because the runtime has no mechanism to call the function with a
different calling convention or know-how to evaluate the default
arguments at run-time, we create a thunk which will do all the
appropriate work and package it in a way the runtime can use.
Differential Revision: http://reviews.llvm.org/D8225
llvm-svn: 231952
|
| |
|
|
|
|
|
| |
This patch allows using of ExprWithCleanups expressions and other complex expressions in 'omp atomic' construct
Differential Revision: http://reviews.llvm.org/D8200
llvm-svn: 231905
|
| |
|
|
|
|
| |
[-Wdocumentation]
llvm-svn: 231903
|
| |
|
|
|
|
|
|
| |
Because the catchable type has a reference to its name, mangle the
location to ensure that two catchable types with different locations are
distinct.
llvm-svn: 231819
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The task region is emmitted in several steps:
Emit a call to kmp_task_t *__kmpc_omp_task_alloc(ident_t *, kmp_int32 gtid, kmp_int32 flags, size_t sizeof_kmp_task_t, size_t sizeof_shareds, kmp_routine_entry_t *task_entry).
Here task_entry is a pointer to the function:
kmp_int32 .omp_task_entry.(kmp_int32 gtid, kmp_task_t *tt) {
TaskFunction(gtid, tt->part_id, tt->shareds);
return 0;
}
Copy a list of shared variables to field shareds of the resulting structure kmp_task_t returned by the previous call (if any).
Copy a pointer to destructions function to field destructions of the resulting structure kmp_task_t.
Emit a call to kmp_int32 __kmpc_omp_task(ident_t *, kmp_int32 gtid, kmp_task_t *new_task), where new_task is a resulting structure from previous items.
Differential Revision: http://reviews.llvm.org/D7560
llvm-svn: 231762
|
| |
|
|
|
|
|
|
|
| |
regions in termination scope
Patch adds proper generation of debug info for all OpenMP regions. Also, all OpenMP regions are generated in a termination scope, because standard does not allow to throw exceptions out of structured blocks, associated with the OpenMP regions
Differential Revision: http://reviews.llvm.org/D7935
llvm-svn: 231757
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
OpenMP regions in termination scope Patch adds proper generation of debug info for all OpenMP regions. Also, all OpenMP regions are generated in a termination scope, because standard does not allow to throw exceptions out of structured blocks, associated with the OpenMP regions Differential Revision: http://reviews.llvm.org/D7935"
This reverts commit r231752.
It was failing to link with cmake:
lib64/libclangCodeGen.a(CGOpenMPRuntime.cpp.o):/home/espindola/llvm/llvm/tools/clang/lib/CodeGen/CGOpenMPRuntime.cpp:function clang::CodeGen::InlinedOpenMPRegionRAII::~InlinedOpenMPRegionRAII(): error: undefined reference to 'clang::CodeGen::EHScopeStack::popTerminate()'
clang-3.7: error: linker command failed with exit code 1 (use -v to see invocation)
llvm-svn: 231754
|
| |
|
|
|
|
|
|
|
| |
regions in termination scope
Patch adds proper generation of debug info for all OpenMP regions. Also, all OpenMP regions are generated in a termination scope, because standard does not allow to throw exceptions out of structured blocks, associated with the OpenMP regions
Differential Revision: http://reviews.llvm.org/D7935
llvm-svn: 231752
|
| |
|
|
|
| |
From: Mehdi Amini <mehdi.amini@apple.com>
llvm-svn: 231739
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
-fsanitize=shift-exponent.
This is a recommit of r231150, reverted in r231409. Turns out
that -fsanitize=shift-base check implementation only works if the
shift exponent is valid, otherwise it contains undefined behavior
itself.
Make sure we check that exponent is valid before we proceed to
check the base. Make sure that we actually report invalid values
of base or exponent if -fsanitize=shift-base or
-fsanitize=shift-exponent is specified, respectively.
llvm-svn: 231711
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When passing a type with large alignment byval, we were specifying the type's
alignment rather than the alignment that the backend is actually capable of
producing (ABIAlign).
This would be OK (if odd) assuming the backend dealt with it prooperly,
unfortunately it doesn't and trying to pass types with "byval align 16" can
cause it to set fp incorrectly and trash the stack during the prologue. I'll be
fixing that in a separate patch, but Clang should still be emitting IR that's
as close to its intent as possible.
rdar://20059039
llvm-svn: 231706
|
| |
|
|
|
|
|
|
|
|
|
|
| |
I disabled putting the new global into the same COMDAT as the function for now.
There's a fundamental problem when we inline references to the global but still
have the global in a COMDAT linked to the inlined function. Since this is only
an optimization there may be other versions of the COMDAT around that are
missing the new global and hell breaks loose at link time.
I hope the chromium build doesn't break this time :)
llvm-svn: 231564
|
| |
|
|
|
|
|
|
|
| |
This broke the Chromium build. Links were failing with messages like:
obj/dbus/libdbus_test_support.a(obj/dbus/dbus_test_support.mock_object_proxy.o):../../dbus/mock_object_proxy.cc:function dbus::MockObjectProxy::Detach(): warning: relocation refers to discarded section
/usr/local/google/work/chromium/src/third_party/binutils/Linux_x64/Release/bin/ld.gold: error: treating warnings as errors
llvm-svn: 231541
|
| |
|
|
|
|
|
|
|
|
| |
of extern "C" declarations. This is simpler and vastly more efficient for
modules builds (we no longer need to load *all* extern "C" declarations to
determine if we have a redeclaration).
No functionality change intended.
llvm-svn: 231538
|
| |
|
|
|
|
|
| |
This is a little nicer as it keeps the contents of .xdata away from
normal .rdata; we expect .xdata to be far colder than .rdata.
llvm-svn: 231534
|
| |
|
|
|
|
|
| |
We didn't create type info based on the unqualified pointee type,
causing RTTI mismatches.
llvm-svn: 231533
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Instead of creating a copy on the stack just stash them in a private
constant global. This saves both the copying overhead and the stack
space, and gives the optimizer more room to constant fold.
This tries to make array temporaries more similar to regular arrays,
they can't use the same logic because a temporary has no VarDecl to be
bound to so we roll our own version here.
The original use case for this optimization was code like
for (int i : {1, 2, 3, 4, 5, 6, 7, 8, 10})
foo(i);
where without this patch (assuming that the loop is not unrolled) we
would alloca an array on the stack, copy the 10 values over and
iterate on that. With this patch we put the array in .text use it
directly. Apart from that case this helps on virtually any passing of
a constant std::initializer_list as a function argument.
Differential Revision: http://reviews.llvm.org/D8034
llvm-svn: 231508
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Find all unambiguous public classes of the exception object's class type
and reference all of their copy constructors. Yes, this is not
conforming but it is necessary in order to implement their ABI. This is
because the copy constructor is actually referenced by the metadata
describing which catch handlers are eligible to handle the exception
object.
N.B. This doesn't yet handle the copy constructor closure case yet,
that work is ongoing.
Differential Revision: http://reviews.llvm.org/D8101
llvm-svn: 231499
|
| |
|
|
|
|
|
|
|
|
|
| |
-fsanitize=shift-exponent."
It's not that easy. If we're only checking -fsanitize=shift-base we
still need to verify that exponent has sane value, otherwise
UBSan-inserted checks for base will contain undefined behavior
themselves.
llvm-svn: 231409
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Throwing a C++ exception, under the MS ABI, is implemented using three
components:
- ThrowInfo structure which contains information like CV qualifiers,
what destructor to call and a pointer to the CatchableTypeArray.
- In a significant departure from the Itanium ABI, copying by-value
occurs in the runtime and not at the catch site. This means we need
to enumerate all possible types that this exception could be caught as
and encode the necessary information to convert from the exception
object's type to the catch handler's type. This includes complicated
derived to base conversions and the execution of copy-constructors.
N.B. This implementation doesn't support the execution of a
copy-constructor from within the runtime for now. Adding support for
that functionality is quite difficult due to things like default
argument expressions which may evaluate arbitrary code hiding in the
copy-constructor's parameters.
Differential Revision: http://reviews.llvm.org/D8066
llvm-svn: 231328
|
| |
|
|
|
|
| |
Review: http://reviews.llvm.org/D7951
llvm-svn: 231291
|
| |
|
|
|
|
|
|
| |
Opt in Win64 to supporting sjlj lowering. We have the backend lowering,
so I think this was just an oversight because WinX86_64TargetCodeGenInfo
doesn't inherit from X86_64TargetCodeGenInfo.
llvm-svn: 231280
|
| |
|
|
| |
llvm-svn: 231278
|
| |
|
|
|
|
|
| |
__builtin_setjmp/__builtin_longjmp and don't fall back to the libc
functions.
llvm-svn: 231245
|