make_error_code(object_error) is slow because object::object_category()
uses a ManagedStatic variable. But the real problem is that the function is
called too frequently. This patch uses std::error_code() instead of
object_error::success. In most cases, we return "success", so this patch
reduces number of function calls to that function.
http://reviews.llvm.org/D10333
llvm-svn: 239409
I have not succeeded in writing a proper test case for this yet and we
also need to solve the underlying fundamental problem of trying too
many combinations with nested blocks (basically this somewhat works
around our Dijkstra algorithm). Preventing this linebreak is good
anyways as usually the penalties never make us choose it (that's why I
can't create a test) and it also looks ugly.
Also cleaned up state comparison code that I discovered while hunting
this down.
llvm-svn: 239398
Summary:
For some branches, GAS accepts an immediate instead of the 2nd register operand.
We only implement this for BNE and BEQ for now. Other branch instructions can be added later, if needed.
Reviewers: dsanders
Reviewed By: dsanders
Subscribers: seanbruno, emaste, llvm-commits
Differential Revision: http://reviews.llvm.org/D9666
llvm-svn: 239396
This matches the cl.exe behavior (tested with 18.00.31101). In order to
specify an output file for /P, use the /Fi option instead.
Differential Revision: http://reviews.llvm.org/D10313
llvm-svn: 239393
Summary:
If malloc/realloc fails then the SmallVector becomes unusable since begin() and
end() will return NULL. This is unlikely to occur but was the cause of recent
bugpoint test failures on my machine.
It is not clear whether not checking for malloc/realloc failure is a deliberate
decision and adding checks has the potential to impact compiler performance.
Therefore, this patch only adds the check to builds with assertions enabled for
the moment.
Reviewers: bkramer
Reviewed By: bkramer
Subscribers: bkramer, llvm-commits
Differential Revision: http://reviews.llvm.org/D9520
llvm-svn: 239392
The object file format is sometimes overridden for MSVC targets to use
ELF instead of COFF. Make sure we preserve this choice when setting the
msvc version number in the triple.
llvm-svn: 239388
The code generator may create references to runtime library symbols such as
__chkstk which were not visible via LTOModule. Handle these cases by loading
the object file from the library, but abort if we end up having loaded any
bitcode objects.
Because loading the object file may have introduced new undefined references,
call reportRemainingUndefines again to detect and report them.
Differential Revision: http://reviews.llvm.org/D10332
llvm-svn: 239386
The LLVM code generator can sometimes synthesize symbols, such as SSE
constants, that are not visible via the LTOModule interface. Allow such
symbols so long as they have definitions.
Differential Revision: http://reviews.llvm.org/D10331
llvm-svn: 239385
The machinery added to permit a static_cast from void-ptr to fn-ptr
unintentionally gets triggered for c-style casts and function-style
casts. The observable effect was a diagnostic issued inappropriately.
llvm-svn: 239382
Summary: I noticed an object file with `DW_OP_reg4 DW_OP_breg4 0` as a DWARF expression,
which I traced to a missing break (and `++I`) in this code snippet.
While I was at it, I also added support for a few other corner cases
along the same lines that I could think of.
Test Plan: Hand-crafted test case to exercises these cases is included.
Reviewers: echristo, dblaikie, aprantl
Reviewed By: aprantl
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D10302
llvm-svn: 239380
The following code triggers a fatal error in the compiler instrumentation
of ASan on Darwin because we place the attribute into llvm.metadata section,
which does not have the proper MachO section name.
void foo() __attribute__((annotate("custom")));
void foo() {;}
This commit reorders the checks so that we skip everything in llvm.metadata
first. It also removes the hard failure in case the section name does not
parse. That check will be done lower in the compilation pipeline anyway.
(Reviewed in http://reviews.llvm.org/D9093.)
llvm-svn: 239379
This is a follow-up to r225570 which enabled adding DLL attributes when a
class template goes from explicit instantiation declaration to explicit
instantiation definition.
llvm-svn: 239375
It is safe to add a dll attribute if the base class template previously only had
an explicit instantiation declaration, or was implicitly instantiated.
I both those cases, the members would not have been codegenned yet. In the case
of explicit instantiation declaration this is natural, and for implicit
instantiations, codegen is deferred (see r225570).
This is work towards fixing PR23770.
llvm-svn: 239373
Don't warn about not being able to propagate dll attribute to a base class template
when that base already has a different attribute.
MSVC doesn't actually try to do this; the first attribute that was propagated
takes precedence, so Clang is already doing the right thing and there's no
need to warn.
(This is a step towards fixing PR21718.)
llvm-svn: 239372
There are still problems here, but this is a better starting point.
The main part of the change is: when doing a lookup that would accept visible
or hidden declarations, prefer to produce the latest visible declaration if
there are any visible declarations, rather than always producing the latest
declaration.
Thus, when we inherit default arguments (and other properties) from a previous
declaration, we inherit them from the previous visible declaration; if the
previous declaration is hidden, we already suppress inheritance of default
arguments.
There are a couple of other changes here that fix latent bugs exposed by this
change.
llvm-svn: 239371
Summary:
This cleans up most allocas NVPTXLowerKernelArgs emits for byval
parameters.
Test Plan: makes bug21465.ll more stronger to verify no redundant local load/store.
Reviewers: eliben, jholewinski
Reviewed By: eliben, jholewinski
Subscribers: jholewinski, llvm-commits
Differential Revision: http://reviews.llvm.org/D10322
llvm-svn: 239368
We don't want to replace function A by Function B in one module and Function B
by Function A in another module.
If these functions are marked with linkonce_odr we would end up with a function
stub calling B in one module and a function stub calling A in another module. If
the linker decides to pick these two we will have two stubs calling each other.
rdar://21265586
llvm-svn: 239367
When pragma clang loop unroll() is specified without an argument the diagnostic message should inform that user that 'full' and 'disable' are valid arguments (not 'enable').
llvm-svn: 239363
Rui Ueyama