Commit Graph

561 Commits

Author SHA1 Message Date
Michael Kuperstein def554db45 [DebugInfo] Fix debug info generation for function static variables, typedefs, and records
Function static variables, typedefs and records (class, struct or union) declared inside
a lexical scope were associated with the function as their parent scope, rather than the
lexical scope they are defined or declared in.

This fixes PR19238

Patch by: amjad.aboud@intel.com
Differential Revision: http://reviews.llvm.org/D9760

llvm-svn: 241154
2015-07-01 12:34:39 +00:00
Alexander Kornienko ab9db51042 Revert r240270 ("Fixed/added namespace ending comments using clang-tidy").
llvm-svn: 240353
2015-06-22 23:07:51 +00:00
Alexander Kornienko 3d9d929e42 Fixed/added namespace ending comments using clang-tidy. NFC
The patch is generated using this command:

  $ tools/extra/clang-tidy/tool/run-clang-tidy.py -fix \
      -checks=-*,llvm-namespace-comment -header-filter='llvm/.*|clang/.*' \
      work/llvm/tools/clang

To reduce churn, not touching namespaces spanning less than 10 lines.

llvm-svn: 240270
2015-06-22 09:47:44 +00:00
Alexey Samsonov d918ff62e5 [CodeGen] Use IRBuilder to create llvm.lifetime intrinsics.
Summary:
In addition to easier syntax, IRBuilder makes sure to set correct
debug locations for newly added instructions (bitcast and
llvm.lifetime itself). This restores the original behavior, which
was modified by r234581 (reapplied as r235553).

Extend one of the tests to check for debug locations.

Test Plan: regression test suite

Reviewers: aadg, dblaikie

Subscribers: cfe-commits, majnemer

Differential Revision: http://reviews.llvm.org/D10418

llvm-svn: 239643
2015-06-12 22:31:32 +00:00
David Blaikie 43f9bb7371 API update for streamlining of IRBuilder::CreateCall to just use ArrayRef/initializer_list+braced init
llvm-svn: 237625
2015-05-18 22:14:03 +00:00
NAKAMURA Takumi c7da6da58e Revert r236879, "Do not emit thunks with available_externally linkage in comdats"
It broke pecoff, at least i686-cygwin.

llvm-svn: 236937
2015-05-09 21:10:07 +00:00
Derek Schuff 2312bd3811 Do not emit thunks with available_externally linkage in comdats
Functions with available_externally linkage will not be emitted to object
files (they will just be undefined symbols), so it does not make sense to
put them in comdats.

Creates a second overload of maybeSetTrivialComdat that uses the GlobalObject
instead of the Decl, and uses that in several places that had the faulty
logic.

Differential Revision: http://reviews.llvm.org/D9580

llvm-svn: 236879
2015-05-08 16:47:21 +00:00
Alexey Bataev 43f7439cf5 Fix for http://llvm.org/PR23392: magick/feature.c from ImageMagick-6.9.1-2 ICEs.
Fix for codegen of static variables declared inside of captured statements. Captured statements are actually a transparent DeclContexts, so we have to skip them when trying to get a mangled name for statics.
Differential Revision: http://reviews.llvm.org/D9522

llvm-svn: 236701
2015-05-07 06:28:46 +00:00
Reid Kleckner 1ef49218b3 Don't emit lifetime markers when msan is enabled
In r235553, Clang started emitting lifetime markers more often. This
caused false negative in MSan, because MSan only poisons all allocas
once at function entry. Eventually, MSan should poison allocas at
lifetime start and probably also lifetime end, but until then, let's not
emit markers that aren't going to be useful.

llvm-svn: 235613
2015-04-23 18:07:13 +00:00
David Majnemer dc012fa266 Revert "Revert r234581, it might have caused a few miscompiles in Chromium."
This reverts commit r234700.  It turns out that the lifetime markers
were not the cause of Chromium failing but a bug which was uncovered by
optimizations exposed by the markers.

llvm-svn: 235553
2015-04-22 21:38:15 +00:00
Nico Weber 1c565c31b1 Revert r234581, it might have caused a few miscompiles in Chromium.
If the revert helps, I'll get a repro this Monday.  Else I'll put the change
back in.

llvm-svn: 234700
2015-04-11 23:51:38 +00:00
Arnaud A. de Grandmaison 047a686d53 Remove threshold for inserting lifetime markers for named temporaries
Now that TailRecursionElimination has been fixed with r222354, the
threshold on size for lifetime marker insertion can be removed. This
only affects named temporary though, as the patch for unnamed temporaries
is still in progress.

My previous commit (r222993) was not handling debuginfo correctly, but
this could only be seen with some asan tests. Basically, lifetime markers
are just instrumentation for the compiler's usage and should not affect
debug information; however, the cleanup infrastructure was assuming it
contained only destructors, i.e. actual code to be executed, and was
setting the breakpoint for the end of the function to the closing '}', and
not the return statement, in order to show some destructors have been
called when leaving the function. This is wrong when the cleanups are only
lifetime markers, and this is now fixed.

llvm-svn: 234581
2015-04-10 10:13:52 +00:00
David Blaikie 2e80428dc5 clang-format my last commit
(sorry, keep forgetting that)

llvm-svn: 234129
2015-04-05 22:47:07 +00:00
David Blaikie 1ed728c499 [opaque pointer type] More GEP API migrations
Looks like the VTable code in particular will need some work to pass
around the pointee type explicitly.

llvm-svn: 234128
2015-04-05 22:45:47 +00:00
David Blaikie 17ea266bac [opaque pointer type] More GEP API migrations
llvm-svn: 234109
2015-04-04 21:07:17 +00:00
Richard Smith f19e12794d Replace Sema's map of locally-scoped extern "C" declarations with a DeclContext
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
2015-03-07 00:04:49 +00:00
Adrian Prantl 95b24e9b59 Address review feedback for r228003.
- use named constructors
- get rid of MarkAsPrologue

llvm-svn: 228021
2015-02-03 20:00:54 +00:00
Adrian Prantl 39428e74a0 Merge ArtificialLocation into ApplyDebugLocation and make a clear
distinction between the different use-cases. With the previous default
behavior we would occasionally emit empty debug locations in situations
where they actually were strictly required (= on invoke insns).
We now have a choice between defaulting to an empty location or an
artificial location.

Specifically, this fixes a bug caused by a missing debug location when
emitting C++ EH cleanup blocks from within an artificial function, such as
an ObjC destroy helper function.

rdar://problem/19670595

llvm-svn: 228003
2015-02-03 18:40:42 +00:00
David Blaikie 66e4197f07 Reapply r225000 (reverted in r225555): DebugInfo: Generalize debug info location handling (and follow-up commits).
Several pieces of code were relying on implicit debug location setting
which usually lead to incorrect line information anyway. So I've fixed
those (in r225955 and r225845) separately which should pave the way for
this commit to be cleanly reapplied.

The reason these implicit dependencies resulted in crashes with this
patch is that the debug location would no longer implicitly leak from
one place to another, but be set back to invalid. Once a call with
no/invalid location was emitted, if that call was ever inlined it could
produce invalid debugloc chains and assert during LLVM's codegen.

There may be further cases of such bugs in this patch - they're hard to
flush out with regression testing, so I'll keep an eye out for reports
and investigate/fix them ASAP if they come up.

Original commit message:

Reapply "DebugInfo: Generalize debug info location handling"

Originally committed in r224385 and reverted in r224441 due to concerns
this change might've introduced a crash. Turns out this change fixes the
crash introduced by one of my earlier more specific location handling
changes (those specific fixes are reverted by this patch, in favor of
the more general solution).

Recommitted in r224941 and reverted in r224970 after it caused a crash
when building compiler-rt. Looks to be due to this change zeroing out
the debug location when emitting default arguments (which were meant to
inherit their outer expression's location) thus creating call
instructions without locations - these create problems for inlining and
must not be created. That is fixed and tested in this version of the
change.

Original commit message:

This is a more scalable (fixed in mostly one place, rather than many
places that will need constant improvement/maintenance) solution to
several commits I've made recently to increase source fidelity for
subexpressions.

This resetting had to be done at the DebugLoc level (not the
SourceLocation level) to preserve scoping information (if the resetting
was done with CGDebugInfo::EmitLocation, it would've caused the tail end
of an expression's codegen to end up in a potentially different scope
than the start, even though it was at the same source location). The
drawback to this is that it might leave CGDebugInfo out of sync. Ideally
CGDebugInfo shouldn't have a duplicate sense of the current
SourceLocation, but for now it seems it does... - I don't think I'm
going to tackle removing that just now.

I expect this'll probably cause some more buildbot fallout & I'll
investigate that as it comes up.

Also these sort of improvements might be starting to show a weakness/bug
in LLVM's line table handling: we don't correctly emit is_stmt for
statements, we just put it on every line table entry. This means one
statement split over multiple lines appears as multiple 'statements' and
two statements on one line (without column info) are treated as one
statement.

I don't think we have any IR representation of statements that would
help us distinguish these cases and identify the beginning of each
statement - so that might be something we need to add (possibly to the
lexical scope chain - a scope for each statement). This does cause some
problems for GDB and possibly other DWARF consumers.

llvm-svn: 225956
2015-01-14 07:38:27 +00:00
Rafael Espindola 0d4fb98504 [patch][pr19848] Produce explicit comdats in clang.
The llvm IR until recently had no support for comdats. This was a problem when
targeting C++ on ELF/COFF as just using weak linkage would cause quite a bit of
dead bits to remain on the executable (unless -ffunction-sections,
-fdata-sections and --gc-sections were used).

To fix the problem, llvm's codegen will just assume that any weak or linkonce
that is not in an explicit comdat should be output in one with the same name as
the global.

This unfortunately breaks cases like pr19848 where a weak symbol is not
xpected to be part of any comdat.

Now that we have explicit comdats in the IR, we can finally get both cases
right.

This first patch just makes clang give explicit comdats to GlobalValues where
t is allowed to.

A followup patch to llvm will then stop implicitly producing comdats.

llvm-svn: 225705
2015-01-12 22:13:53 +00:00
David Blaikie f353d3ecd0 Revert "DebugInfo: Generalize debug info location handling" and related commits
This reverts commit r225000, r225021, r225083, r225086, r225090.

The root change (r225000) still has several issues where it's caused
calls to be emitted without debug locations. This causes assertion
failures if/when those calls are inlined.

I'll work up some test cases and fixes before recommitting this.

llvm-svn: 225555
2015-01-09 23:00:28 +00:00
David Blaikie 84fe79cfc3 Reapply "DebugInfo: Generalize debug info location handling"
Originally committed in r224385 and reverted in r224441 due to concerns
this change might've introduced a crash. Turns out this change fixes the
crash introduced by one of my earlier more specific location handling
changes (those specific fixes are reverted by this patch, in favor of
the more general solution).

Recommitted in r224941 and reverted in r224970 after it caused a crash
when building compiler-rt. Looks to be due to this change zeroing out
the debug location when emitting default arguments (which were meant to
inherit their outer expression's location) thus creating call
instructions without locations - these create problems for inlining and
must not be created. That is fixed and tested in this version of the
change.

Original commit message:

This is a more scalable (fixed in mostly one place, rather than many
places that will need constant improvement/maintenance) solution to
several commits I've made recently to increase source fidelity for
subexpressions.

This resetting had to be done at the DebugLoc level (not the
SourceLocation level) to preserve scoping information (if the resetting
was done with CGDebugInfo::EmitLocation, it would've caused the tail end
of an expression's codegen to end up in a potentially different scope
than the start, even though it was at the same source location). The
drawback to this is that it might leave CGDebugInfo out of sync. Ideally
CGDebugInfo shouldn't have a duplicate sense of the current
SourceLocation, but for now it seems it does... - I don't think I'm
going to tackle removing that just now.

I expect this'll probably cause some more buildbot fallout & I'll
investigate that as it comes up.

Also these sort of improvements might be starting to show a weakness/bug
in LLVM's line table handling: we don't correctly emit is_stmt for
statements, we just put it on every line table entry. This means one
statement split over multiple lines appears as multiple 'statements' and
two statements on one line (without column info) are treated as one
statement.

I don't think we have any IR representation of statements that would
help us distinguish these cases and identify the beginning of each
statement - so that might be something we need to add (possibly to the
lexical scope chain - a scope for each statement). This does cause some
problems for GDB and possibly other DWARF consumers.

llvm-svn: 225000
2014-12-30 19:39:33 +00:00
David Blaikie 608a24501c Revert "DebugInfo: Generalize debug info location handling"
Asserting when building compiler-rt when using a GCC host compiler.
Reverting while I investigate.

This reverts commit r224941.

llvm-svn: 224970
2014-12-29 23:49:00 +00:00
David Blaikie 3945d1bd99 Reapply "DebugInfo: Generalize debug info location handling"
Originally committed in r224385 and reverted in r224441 due to concerns
this change might've introduced a crash. Turns out this change fixes the
crash introduced by one of my earlier more specific location handling
changes (those specific fixes are reverted by this patch, in favor of
the more general solution).

Original commit message:

This is a more scalable (fixed in mostly one place, rather than many
places that will need constant improvement/maintenance) solution to
several commits I've made recently to increase source fidelity for
subexpressions.

This resetting had to be done at the DebugLoc level (not the
SourceLocation level) to preserve scoping information (if the resetting
was done with CGDebugInfo::EmitLocation, it would've caused the tail end
of an expression's codegen to end up in a potentially different scope
than the start, even though it was at the same source location). The
drawback to this is that it might leave CGDebugInfo out of sync. Ideally
CGDebugInfo shouldn't have a duplicate sense of the current
SourceLocation, but for now it seems it does... - I don't think I'm
going to tackle removing that just now.

I expect this'll probably cause some more buildbot fallout & I'll
investigate that as it comes up.

Also these sort of improvements might be starting to show a weakness/bug
in LLVM's line table handling: we don't correctly emit is_stmt for
statements, we just put it on every line table entry. This means one
statement split over multiple lines appears as multiple 'statements' and
two statements on one line (without column info) are treated as one
statement.

I don't think we have any IR representation of statements that would
help us distinguish these cases and identify the beginning of each
statement - so that might be something we need to add (possibly to the
lexical scope chain - a scope for each statement). This does cause some
problems for GDB and possibly other DWARF consumers.

llvm-svn: 224941
2014-12-29 18:18:45 +00:00
David Blaikie 06b2c54db9 Revert "DebugInfo: Generalize debug info location handling"
Fails an ASan bootstrap - I'll try to reproduce locally & sort that out
before recommitting.

This reverts commit r224385.

llvm-svn: 224441
2014-12-17 18:02:04 +00:00
David Blaikie bf22a4eaee DebugInfo: Generalize debug info location handling
This is a more scalable (fixed in mostly one place, rather than many
places that will need constant improvement/maintenance) solution to
several commits I've made recently to increase source fidelity for
subexpressions.

This resetting had to be done at the DebugLoc level (not the
SourceLocation level) to preserve scoping information (if the resetting
was done with CGDebugInfo::EmitLocation, it would've caused the tail end
of an expression's codegen to end up in a potentially different scope
than the start, even though it was at the same source location). The
drawback to this is that it might leave CGDebugInfo out of sync. Ideally
CGDebugInfo shouldn't have a duplicate sense of the current
SourceLocation, but for now it seems it does... - I don't think I'm
going to tackle removing that just now.

I expect this'll probably cause some more buildbot fallout & I'll
investigate that as it comes up.

Also these sort of improvements might be starting to show a weakness/bug
in LLVM's line table handling: we don't correctly emit is_stmt for
statements, we just put it on every line table entry. This means one
statement split over multiple lines appears as multiple 'statements' and
two statements on one line (without column info) are treated as one
statement.

I don't think we have any IR representation of statements that would
help us distinguish these cases and identify the beginning of each
statement - so that might be something we need to add (possibly to the
lexical scope chain - a scope for each statement). This does cause some
problems for GDB and possibly other DWARF consumers.

llvm-svn: 224385
2014-12-16 22:49:17 +00:00
David Blaikie 00de22f963 DebugInfo: Correct location of initialization of auto __complex
llvm-svn: 223842
2014-12-09 22:15:02 +00:00
David Blaikie 7f138811cd DebugInfo: Correct the location of initializations of auto.
llvm-svn: 223839
2014-12-09 22:04:13 +00:00
David Blaikie 73ca56942d DebugInfo: Correctly identify the location of C++ member initializer list elements
This particularly helps the fidelity of ASan reports (which can occur
even in these examples - if, for example, one uses placement new over a
buffer of insufficient size - now ASan will correctly identify which
member's initialization went over the end of the buffer).

This doesn't cover all types of members - more coming.

llvm-svn: 223726
2014-12-09 00:32:22 +00:00
Arnaud A. de Grandmaison f3470cc979 Revert "Remove threshold for lifetime marker insertion of named temporaries"
Revert r222993 while I investigate some MemorySanitizer failures.

llvm-svn: 222995
2014-12-01 09:30:16 +00:00
Arnaud A. de Grandmaison f2730e2d22 Remove threshold for lifetime marker insertion of named temporaries
Now that TailRecursionElimination has been fixed with r222354, the
threshold on size for lifetime marker insertion can be removed. This
only affects named temporary though, as the patch for unnamed temporaries
is still in progress.

llvm-svn: 222993
2014-12-01 09:13:54 +00:00
Matt Arsenault 3f6469b4c6 Emit OpenCL local global variables without zeorinitializer
Local variables are not initialized, and every target has
been (incorrectly) ignoring the unnecessary request for
zero initialization.

llvm-svn: 221162
2014-11-03 16:51:53 +00:00
Nick Lewycky 5d1159ebe9 Revert r218865 because it introduced PR21236, a crash in codegen emitting the try block.
llvm-svn: 219470
2014-10-10 04:05:00 +00:00
Arnaud A. de Grandmaison e69ec55cda Revert "Remove threshold on object size for inserting lifetime begin / end"
Revert this patch while I investigate some sanitizer failures off-line.

llvm-svn: 219307
2014-10-08 14:04:26 +00:00
Alexey Bataev 4a5bb772c3 [OPENMP] Codegen for 'firstprivate' clause.
This patch generates some helper variables that used as private copies of the corresponding original variables inside an OpenMP 'parallel' directive. These generated variables are initialized by copy using values of the original variables (with the copy constructor, if any). For arrays, initializator is generated for single element and in the codegen procedure this initial value is automatically propagated between all elements of the private copy.
In outlined function, references to original variables are replaced by the references to these private helper variables. At the end of the initialization of the private variables an implicit barier is generated by calling __kmpc_barrier(...) runtime function to be sure that all threads were initialized using original values of the variables.
Differential Revision: http://reviews.llvm.org/D5140

llvm-svn: 219306
2014-10-08 14:01:46 +00:00
Arnaud A. de Grandmaison 1b175e4098 Remove threshold on object size for inserting lifetime begin / end
Boostrapping LLVM+Clang+LLDB without threshold on object size for
lifetime markers insertion has shown there was no significant change
in compile time, so let the stack slot colorizer do its optimization
for all slots.

llvm-svn: 219303
2014-10-08 12:49:16 +00:00
Alexey Bataev 8068b643c4 Revert commit r219297.
Still troubles with OpenMP/parallel_firstprivate_codegen.cpp (now in ARM buildbots).

llvm-svn: 219298
2014-10-08 12:00:22 +00:00
Alexey Bataev 3854f63aaf [OPENMP] Codegen for 'firstprivate' clause.
This patch generates some helper variables that used as private copies of the corresponding original variables inside an OpenMP 'parallel' directive. These generated variables are initialized by copy using values of the original variables (with the copy constructor, if any). For arrays, initializator is generated for single element and in the codegen procedure this initial value is automatically propagated between all elements of the private copy.
In outlined function, references to original variables are replaced by the references to these private helper variables. At the end of the initialization of the private variables an implicit barier is generated by calling __kmpc_barrier(...) runtime function to be sure that all threads were initialized using original values of the variables.
Differential Revision: http://reviews.llvm.org/D5140

llvm-svn: 219297
2014-10-08 11:35:04 +00:00
Alexey Bataev bdef50e1ad Revert back r219295.
To fix issues with test OpenMP/parallel_firstprivate_codegen.cpp

llvm-svn: 219296
2014-10-08 11:12:35 +00:00
Alexey Bataev e7a5517a58 [OPENMP] Codegen for 'firstprivate' clause.
This patch generates some helper variables that used as private copies of the corresponding original variables inside an OpenMP 'parallel' directive. These generated variables are initialized by copy using values of the original variables (with the copy constructor, if any). For arrays, initializator is generated for single element and in the codegen procedure this initial value is automatically propagated between all elements of the private copy.
In outlined function, references to original variables are replaced by the references to these private helper variables. At the end of the initialization of the private variables an implicit barier is generated by calling __kmpc_barrier(...) runtime function to be sure that all threads were initialized using original values of the variables.
Differential Revision: http://reviews.llvm.org/D5140

llvm-svn: 219295
2014-10-08 10:42:55 +00:00
Reid Kleckner 453e056467 Fix IRGen for referencing a static local before emitting its decl
Summary:
Previously CodeGen assumed that static locals were emitted before they
could be accessed, which is true for automatic storage duration locals.
However, it is possible to have CodeGen emit a nested function that uses
a static local before emitting the function that defines the static
local, breaking that assumption.

Fix it by creating the static local upon access and ensuring that the
deferred function body gets emitted. We may not be able to emit the
initializer properly from outside the function body, so don't try.

Fixes PR18020.  See also previous attempts to fix static locals in
PR6769 and PR7101.

Reviewers: rsmith

Subscribers: cfe-commits

Differential Revision: http://reviews.llvm.org/D4787

llvm-svn: 219265
2014-10-08 01:07:54 +00:00
Arnaud A. de Grandmaison 42d314d1ba Emit lifetime.start / lifetime.end markers for unnamed temporary objects.
This will give more information to the optimizers so that they can reuse stack slots
and reduce stack usage.

llvm-svn: 218865
2014-10-02 12:19:51 +00:00
David Blaikie 77bbb5fd0b DebugInfo: Blocks: Do not depend on LLVM argument numbering when choosing the debug info argument numbering.
Due to the possible presence of return-by-out parameters, using the LLVM
argument number count when numbering debug info arguments can end up
off-by-one. This could produce two arguments with the same number, which
would in turn cause LLVM to emit only one of those arguments (whichever
it found last) or assert (r215157).

llvm-svn: 215227
2014-08-08 17:10:14 +00:00
Reid Kleckner fe5b4ed822 Remove separator parameter from static local naming code
It was always set to ".", which was duplicated in a few places.

llvm-svn: 214792
2014-08-04 22:35:30 +00:00
Alexey Samsonov 4b8de11c81 [Sanitizer] Introduce SanitizerMetadata class.
It is responsible for generating metadata consumed by sanitizer instrumentation
passes in the backend. Move several methods from CodeGenModule to SanitizerMetadata.
For now the class is stateless, but soon it won't be the case.

Instead of creating globals providing source-level information to ASan, we will create
metadata nodes/strings which will be turned into actual global variables in the
backend (if needed).

No functionality change.

llvm-svn: 214564
2014-08-01 21:35:28 +00:00
Reid Kleckner 19819446eb MS ABI: Don't push destructor cleanups for aggregate parameters in thunks
The target method of the thunk will perform the cleanup.  This can't be
tested in 32-bit x86 yet because passing something by value would create
an inalloca, and we refuse to generate broken code for that.

llvm-svn: 213976
2014-07-25 21:39:46 +00:00
Arnaud A. de Grandmaison 6e24a46572 Revert "Emit lifetime.start / lifetime.end markers for unnamed temporary objects."
This commit did break the sanitizer-x86 bot. Revert it while
investigating.

llvm-svn: 213579
2014-07-21 19:47:02 +00:00
Arnaud A. de Grandmaison 17a83cf4b6 Emit lifetime.start / lifetime.end markers for unnamed temporary objects.
This will give more information to the optimizers so that they can reuse stack slots.

llvm-svn: 213576
2014-07-21 18:54:21 +00:00
NAKAMURA Takumi 215f3b7f02 Revert r213415, "Merge two lines". It broke tests in -Asserts builds.
CGBuilder doesn't name instructions with Name. We should use Inst::setName() to name an instruction explicitly here.

llvm-svn: 213431
2014-07-18 23:46:16 +00:00
Alexey Samsonov ad2e0352f0 Merge two lines
llvm-svn: 213415
2014-07-18 21:29:55 +00:00
Arnaud A. de Grandmaison 18bc4fff48 Revert "Emit lifetime.start / lifetime.end markers for unnamed temporary objects."
This reverts commit dbf785a6432f78a8ec229665876647c4cc610d3d, while I qm
investigating a buildbot failure.

llvm-svn: 213380
2014-07-18 14:23:58 +00:00
Arnaud A. de Grandmaison 1be89f4977 Emit lifetime.start / lifetime.end markers for unnamed temporary objects.
This will give more information to the optimizers so that they can reuse stack slots.

llvm-svn: 213379
2014-07-18 13:36:33 +00:00
Alexey Samsonov 15c9669615 [ASan] Collect unmangled names of global variables in Clang to print them in error reports.
Currently ASan instrumentation pass creates a string with global name
for each instrumented global (to include global names in the error report). Global
name is already mangled at this point, and we may not be able to demangle it
at runtime (e.g. there is no __cxa_demangle on Android).

Instead, create a string with fully qualified global name in Clang, and pass it
to ASan instrumentation pass in llvm.asan.globals metadata. If there is no metadata
for some global, ASan will use the original algorithm.

This fixes https://code.google.com/p/address-sanitizer/issues/detail?id=264.

llvm-svn: 212872
2014-07-12 00:42:52 +00:00
Alexey Samsonov 4f319cca42 [ASan] Print exact source location of global variables in error reports.
See https://code.google.com/p/address-sanitizer/issues/detail?id=299 for the
original feature request.

Introduce llvm.asan.globals metadata, which Clang (or any other frontend)
may use to report extra information about global variables to ASan
instrumentation pass in the backend. This metadata replaces
llvm.asan.dynamically_initialized_globals that was used to detect init-order
bugs. llvm.asan.globals contains the following data for each global:
  1) source location (file/line/column info);
  2) whether it is dynamically initialized;
  3) whether it is blacklisted (shouldn't be instrumented).

Source location data is then emitted in the binary and can be picked up
by ASan runtime in case it needs to print error report involving some global.
For example:

  0x... is located 4 bytes to the right of global variable 'C::array' defined in '/path/to/file:17:8' (0x...) of size 40

These source locations are printed even if the binary doesn't have any
debug info.

This is an ABI-breaking change. ASan initialization is renamed to
__asan_init_v4(). Pre-built libraries compiled with older Clang will not work
with the fresh runtime.

llvm-svn: 212188
2014-07-02 16:54:41 +00:00
Hans Wennborg ef2272c49e Inherit dll attributes to static locals
This makes us handle static locals in exported/imported functions correctly.

Differential Revision: http://reviews.llvm.org/D4136

llvm-svn: 211173
2014-06-18 15:55:13 +00:00
Alexey Samsonov e595e1ade0 Remove top-level Clang -fsanitize= flags for optional ASan features.
Init-order and use-after-return modes can currently be enabled
by runtime flags. use-after-scope mode is not really working at the
moment.

The only problem I see is that users won't be able to disable extra
instrumentation for init-order and use-after-scope by a top-level Clang flag.
But this instrumentation was implicitly enabled for quite a while and
we didn't hear from users hurt by it.

llvm-svn: 210924
2014-06-13 17:53:44 +00:00
Alp Toker fb8d02b179 Implement -Wframe-larger-than backend diagnostic
Add driver and frontend support for the GCC -Wframe-larger-than=bytes warning.
This is the first GCC-compatible backend diagnostic built around LLVM's
reporting feature.

This commit adds infrastructure to perform reverse lookup from mangled names
emitted after LLVM IR generation. We use that to resolve precise locations and
originating AST functions, lambdas or block declarations to produce seamless
codegen-guided diagnostics.

An associated change, StringMap now maintains unique mangled name strings
instead of allocating copies. This is a net memory saving in C++ and a small
hit for C where we no longer reuse IdentifierInfo storage, pending further
optimisation.

llvm-svn: 210293
2014-06-05 22:10:59 +00:00
Alp Toker 0e64e0d4fd Eliminate redundant MangleBuffer class
The only remaining user didn't actually use the non-dynamic storage facility
this class provides.

The std::string is transitional and likely to be StringRefized shortly.

llvm-svn: 210058
2014-06-03 02:13:57 +00:00
Craig Topper 8a13c4180e [C++11] Use 'nullptr'. CodeGen edition.
llvm-svn: 209272
2014-05-21 05:09:00 +00:00
David Majnemer 27d69dbbd0 CodeGen: Fix linkage of reference temporaries
Summary:
A reference temporary should inherit the linkage of the variable it
initializes.  Otherwise, we may hit cases where a reference temporary
wouldn't have the same value in all translation units.

Reviewers: rsmith

Subscribers: cfe-commits

Differential Revision: http://reviews.llvm.org/D3515

llvm-svn: 207451
2014-04-28 22:17:59 +00:00
Reid Kleckner 5e8edbac4f Fix type mismatch assertion related to inalloca and PR19287
Augment the test case from r205217 to catch this related bug.

Fixes the Windows self-host which was failing on VariantValue.cpp.

llvm-svn: 205378
2014-04-02 00:16:53 +00:00
Eli Bendersky cb39943f6f Proper handling of static local variables with address space qualifiers.
Similar to the implementation for globals in r157167.

Patch by Jingyue Wu.

llvm-svn: 204677
2014-03-24 22:05:38 +00:00
Aaron Ballman c7e4e219b5 [C++11] Replacing CompoundStmt iterators body_begin() and body_end() with iterator_range body(). Updating all of the usages of the iterators with range-based for loops.
llvm-svn: 204040
2014-03-17 14:19:37 +00:00
Aaron Ballman 9371dd2287 [C++11] Replacing BlockDecl iterators capture_begin() and capture_end() with iterator_range captures(). Updating all of the usages of the iterators with range-based for loops.
llvm-svn: 203958
2014-03-14 18:34:04 +00:00
Aaron Ballman 535bbcccb1 [C++11] Replacing DeclStmt iterators decl_begin() and decl_end() with iterator_range decls(). Updating all of the usages of the iterators with range-based for loops.
llvm-svn: 203947
2014-03-14 17:01:24 +00:00
Fariborz Jahanian a5a469efbd Objective-C++ IRGen. Due to change to AST for initialization of c++11’s
data members by addition of CXXDefaultInitExpr node to the initializer expression, 
it has broken treatment of arc code for such initializations. Reviewed by John McCall.
// rdar://16299964

llvm-svn: 203935
2014-03-14 15:40:54 +00:00
Craig Topper 4f12f10de4 [C++11] Add 'override' keyword to virtual methods that override their base class.
llvm-svn: 203643
2014-03-12 06:41:41 +00:00
Rafael Espindola 060062a433 Use llvm.compiler.used instead of llvm.used for objc symbols.
LLVM currently has a hack (shouldEmitUsedDirectiveFor) that causes it to not
print no_dead_strip for symbols starting with 'l' or 'L'. These are exactly the
ones that the clang's objc codegen is producing. The net result, is that it is
equivalent to llvm.compiler.used.

The need for putting the private symbol in llvm.compiler.used should be clear
(the objc runtime uses them). The reason for also putting the weak symbols in
it is for LTO: ld64 will not ask us to preserve the it.

llvm-svn: 203172
2014-03-06 22:15:10 +00:00
Benjamin Kramer 867ea1d426 [C++11] Replace llvm::tie with std::tie.
llvm-svn: 202639
2014-03-02 13:01:17 +00:00
Reid Kleckner 314ef7bafd [ms-cxxabi] Use inalloca on win32 when passing non-trivial C++ objects
When a non-trivial parameter is present, clang now gathers up all the
parameters that lack inreg and puts them into a packed struct.  MSVC
always aligns each parameter to 4 bytes and no more, so this is a pretty
simple struct to lay out.

On win64, non-trivial records are passed indirectly.  Prior to this
change, clang was incorrectly using byval on win64.

I'm able to self-host a working clang with this change and additional
LLVM patches.

Reviewers: rsmith

Differential Revision: http://llvm-reviews.chandlerc.com/D2636

llvm-svn: 200597
2014-02-01 00:04:45 +00:00
Alp Toker f6a24ce40f Fix a tranche of comment, test and doc typos
llvm-svn: 196510
2013-12-05 16:25:25 +00:00
Reid Kleckner 739756c0f9 [ms-cxxabi] Construct and destroy call arguments in the correct order
Summary:
MSVC destroys arguments in the callee from left to right.  Because C++
objects have to be destroyed in the reverse order of construction, Clang
has to construct arguments from right to left and destroy arguments from
left to right.

This patch fixes the ordering by reversing the order of evaluation of
all call arguments under the MS C++ ABI.

Fixes PR18035.

Reviewers: rsmith

Differential Revision: http://llvm-reviews.chandlerc.com/D2275

llvm-svn: 196402
2013-12-04 19:23:12 +00:00
Mark Lacey a8e7df3602 Add CodeGenABITypes.h for use in LLDB.
CodeGenABITypes is a wrapper built on top of CodeGenModule that exposes
some of the functionality of CodeGenTypes (held by CodeGenModule),
specifically methods that determine the LLVM types appropriate for
function argument and return values.

I addition to CodeGenABITypes.h, CGFunctionInfo.h is introduced, and the
definitions of ABIArgInfo, RequiredArgs, and CGFunctionInfo are moved
into this new header from the private headers ABIInfo.h and CGCall.h.

Exposing this functionality is one part of making it possible for LLDB
to determine the actual ABI locations of function arguments and return
values, making it possible for it to determine this for any supported
target without hard-coding ABI knowledge in the LLDB code.

llvm-svn: 193717
2013-10-30 21:53:58 +00:00
Nick Lewycky 2d84e84236 Thread a SourceLocation into the EmitCheck for "load_invalid_value". This occurs
when scalars are loaded / undergo lvalue-to-rvalue conversion.

llvm-svn: 191808
2013-10-02 02:29:49 +00:00
Larisse Voufo 39a1e507ff Started implementing variable templates. Top level declarations should be fully supported, up to some limitations documented as FIXMEs or TODO. Static data member templates work very partially. Static data member templates of class templates need particular attention...
llvm-svn: 187762
2013-08-06 01:03:05 +00:00
Eli Friedman c48d31c31c Simplify linkage code for static local vars.
The key insight here is that weak linkage for a static local variable
should always mean linkonce_odr, because every file that needs it will
generate a definition.  We don't actually care about the precise linkage
of the parent context.  I feel a bit silly that I didn't realize this before.

llvm-svn: 185381
2013-07-01 20:53:07 +00:00
Eli Friedman 7e346a8127 Fix mangling for block literals.
Blocks, like lambdas, can be written in contexts which are required to be
treated as the same under ODR.  Unlike lambdas, it isn't possible to actually
take the address of a block, so the mangling of the block itself doesn't
matter. However, objects like static variables inside a block do need to
be mangled in a consistent way.

There are basically three components here. One, block literals need a
consistent numbering.  Two, objects/types inside a block literal need
to be mangled using it.  Three, objects/types inside a block literal need
to have their linkage computed correctly.

llvm-svn: 185372
2013-07-01 20:22:57 +00:00
Reid Kleckner 23f4c4b64f [ms-cxxabi] Destroy temporary record arguments in the callee
Itanium destroys them in the caller at the end of the full expression,
but MSVC destroys them in the callee.  This is further complicated by
the need to emit EH-only destructor cleanups in the caller.

This should help clang compile MSVC's debug iterators more correctly.
There is still an outstanding issue in PR5064 of a memcpy emitted by the
LLVM backend, which is not correct for C++ records.

Fixes PR16226.

Reviewers: rjmccall

Differential Revision: http://llvm-reviews.chandlerc.com/D929

llvm-svn: 184543
2013-06-21 12:45:15 +00:00
Eli Friedman 40a4becb11 Compute the visibility of static local variables consistently. Fixes PR16208.
llvm-svn: 184137
2013-06-17 21:51:45 +00:00
Rafael Espindola a418418f63 Cleanup linkage computation for static locals.
With this patch we assign VisibleNoLinkage to static locals in inline functions.
This lets us simplify CodeGen a bit.

llvm-svn: 184114
2013-06-17 20:04:51 +00:00
Eli Friedman d4b6e7a9b7 Fix the linkage of static locals inside a CapturedStmt. (Found in the
process of trying to fix the related issue for block literals.)

llvm-svn: 183951
2013-06-13 21:50:44 +00:00
Richard Smith a1c9d4d932 Simplify: we don't need any special-case lifetime extension when initializing
declarations of reference type; they're handled by the general case handling of
MaterializeTemporaryExpr.

llvm-svn: 183875
2013-06-12 23:38:09 +00:00
Richard Smith cc1b96d356 PR12086, PR15117
Introduce CXXStdInitializerListExpr node, representing the implicit
construction of a std::initializer_list<T> object from its underlying array.
The AST representation of such an expression goes from an InitListExpr with a
flag set, to a CXXStdInitializerListExpr containing a MaterializeTemporaryExpr
containing an InitListExpr (possibly wrapped in a CXXBindTemporaryExpr).

This more detailed representation has several advantages, the most important of
which is that the new MaterializeTemporaryExpr allows us to directly model
lifetime extension of the underlying temporary array. Using that, this patch
*drastically* simplifies the IR generation of this construct, provides IR
generation support for nested global initializer_list objects, fixes several
bugs where the destructors for the underlying array would accidentally not get
invoked, and provides constant expression evaluation support for
std::initializer_list objects.

llvm-svn: 183872
2013-06-12 22:31:48 +00:00
Richard Smith 736a947bdc Reapply r183721, reverted in r183776, with a fix for a bug in the former (we
were lacking ExprWithCleanups nodes in some cases where the new approach to
lifetime extension needed them).

Original commit message:

Rework IR emission for lifetime-extended temporaries. Instead of trying to walk
into the expression and dig out a single lifetime-extended entity and manually
pull its cleanup outside the expression, instead keep a list of the cleanups
which we'll need to emit when we get to the end of the full-expression. Also
emit those cleanups early, as EH-only cleanups, to cover the case that the
full-expression does not terminate normally. This allows IR generation to
properly model temporary lifetime when multiple temporaries are extended by the
same declaration.

We have a pre-existing bug where an exception thrown from a temporary's
destructor does not clean up lifetime-extended temporaries created in the same
expression and extended to automatic storage duration; that is not fixed by
this patch.

llvm-svn: 183859
2013-06-12 20:42:33 +00:00
Richard Smith 4a28f534e1 Revert r183721. It caused cleanups to be delayed too long in some cases.
Testcase to follow.

llvm-svn: 183776
2013-06-11 19:14:25 +00:00
Richard Smith 7c5d4dce49 Rework IR emission for lifetime-extended temporaries. Instead of trying to walk
into the expression and dig out a single lifetime-extended entity and manually
pull its cleanup outside the expression, instead keep a list of the cleanups
which we'll need to emit when we get to the end of the full-expression. Also
emit those cleanups early, as EH-only cleanups, to cover the case that the
full-expression does not terminate normally. This allows IR generation to
properly model temporary lifetime when multiple temporaries are extended by the
same declaration.

We have a pre-existing bug where an exception thrown from a temporary's
destructor does not clean up lifetime-extended temporaries created in the same
expression and extended to automatic storage duration; that is not fixed by
this patch.

llvm-svn: 183721
2013-06-11 02:41:00 +00:00
Richard Smith 2bcde3a74c PR12848: When emitting a local variable declared 'constexpr', always initialize it with a store or a memcpy, not by emitting the initializer expression. This is not required for correctness, but more closely aligns with people's expectations, and is cheap (since we've already evaluated the initializer).
llvm-svn: 183082
2013-06-02 00:09:52 +00:00
David Blaikie f121b9302e PR14606: Debug Info for namespace aliases/DW_TAG_imported_module
This resolves the last of the PR14606 failures in the GDB 7.5 test
suite. (but there are still unresolved issues in the imported_decl case
- we need to implement optional/lazy decls for functions & variables
like we already do for types)

llvm-svn: 182329
2013-05-20 22:50:41 +00:00
David Blaikie bd4837665b Revert "Revert "Debug Info: Using declarations/DW_TAG_imported_declaration of variables, types, and functions.""
This reverts commit r181947 (git d2990ce56a16050cac0d7937ec9919ff54c6df62 )

This addresses one of the two issues identified in r181947, ensuring
that types imported via using declarations only result in a declaration
being emitted for the type, not a definition. The second issue (emitting
using declarations that are unused) is hopefully an acceptable increase
as the real fix for this would be a bit difficult (probably at best we
could record which using directives were involved in lookups - but may
not have been the result of the lookup).

This also ensures that DW_TAG_imported_declarations (& directives) are
not emitted in line-tables-only mode as well as ensuring that typedefs
only require/emit declarations (rather than definitions) for referenced
types.

llvm-svn: 182231
2013-05-20 04:58:53 +00:00
Enea Zaffanella cf51a8ac3f Let CodeGenFunction::EmitVarDecl query the semantic storage class info.
Added testcase corresponding to PR15991.

llvm-svn: 181998
2013-05-16 11:27:56 +00:00
David Blaikie db35281468 Revert "Debug Info: Using declarations/DW_TAG_imported_declaration of variables, types, and functions."
This reverts commit r181393 (git 3923d6a87fe7b2c91cc4a7dbd90c4ec7e2316bcd).

This seems to be emitting too much extra debug info for two (known)
reasons:
* full class definitions are emitted when only declarations are expected
* unused using declarations still produce DW_TAG_imported_declarations

llvm-svn: 181947
2013-05-15 23:46:19 +00:00
David Blaikie b0b645cad1 Debug Info: Using declarations/DW_TAG_imported_declaration of variables, types, and functions.
Basic support is implemented here - it still doesn't account for
declared-but-not-defined variables or functions. It cannot handle out of
order (declared, 'using', then defined) cases for variables, but can
handle that for functions (& can handle declared, 'using'd, and not
defined at all cases for types).

llvm-svn: 181393
2013-05-08 06:01:46 +00:00
David Blaikie 9f88fe865c Revert "Revert "PR14606: Debug info for using directives/DW_TAG_imported_module""
This reverts commit 179839 now that the corresponding LLVM patch has been fixed.

llvm-svn: 179997
2013-04-22 06:13:21 +00:00
Eric Christopher 3669c3c603 Revert "PR14606: Debug info for using directives/DW_TAG_imported_module"
This reverts commit r179837 as it seems to be causing test failures.

llvm-svn: 179839
2013-04-19 07:46:36 +00:00
David Blaikie cf5e5bade1 PR14606: Debug info for using directives/DW_TAG_imported_module
More changes later for using declarations/DW_TAG_imported_declaration.

llvm-svn: 179837
2013-04-19 07:04:02 +00:00
John McCall c8e0170578 Standardize accesses to the TargetInfo in IR-gen.
Patch by Stephen Lin!

llvm-svn: 179638
2013-04-16 22:48:15 +00:00
Tareq A. Siraj 6dfa25a19f Sema for Captured Statements
Add CapturedDecl to be the DeclContext for CapturedStmt, and perform semantic
analysis. Currently captures all variables by reference.

TODO: templates

Author: Ben Langmuir <ben.langmuir@intel.com>

Differential Revision: http://llvm-reviews.chandlerc.com/D433

llvm-svn: 179618
2013-04-16 19:37:38 +00:00
John McCall 5e77d76c95 Basic support for Microsoft property declarations and
references thereto.

Patch by Tong Shen!

llvm-svn: 179585
2013-04-16 07:28:30 +00:00
Richard Smith fd3834f7a1 Annotate flavor of TLS variable (statically or dynamically initialized) onto the AST.
llvm-svn: 179447
2013-04-13 02:43:54 +00:00
Rafael Espindola 6ae7e50be4 Add 178663 back.
http://lab.llvm.org:8011/builders/clang-x86_64-darwin10-gdb went back green
before it processed the reverted 178663, so it could not have been the culprit.

Revert "Revert 178663."

This reverts commit 4f8a3eb2ce5d4ba422483439e20c8cbb4d953a41.

llvm-svn: 178682
2013-04-03 19:27:57 +00:00
Rafael Espindola 985a3abee4 Revert 178663.
Looks like it broke http://lab.llvm.org:8011/builders/clang-x86_64-darwin10-gdb

Revert "Don't compute a patched/semantic storage class."

This reverts commit 8f187f62cb0487d31bc4afdfcd47e11fe9a51d05.

llvm-svn: 178681
2013-04-03 19:22:20 +00:00
Rafael Espindola adea16bd9e Don't compute a patched/semantic storage class.
For variables and functions clang used to store two storage classes. The one
"as written" in the code and a patched one, which, for example, propagates
static to the following decls.

This apparently is from the days clang lacked linkage computation. It is now
redundant and this patch removes it.

llvm-svn: 178663
2013-04-03 15:50:00 +00:00
Alexey Samsonov 262f05bab0 [ASan] Emit lifetime markers for local variables in -fsanitize=use-after-scope mode
llvm-svn: 178538
2013-04-02 13:19:46 +00:00
Adrian Prantl 0f6df00e4d Bugfix/Followup for r177086.
* Store the .block_descriptor (instead of self) in the alloca so we
  can guarantee that all captured variables are available at -O0.
* Add the missing OpDeref for the alloca.
rdar://problem/12767564

llvm-svn: 178361
2013-03-29 19:20:35 +00:00
Rafael Espindola 609f5d98d4 Remove useGlobalsForAutomaticVariables.
It is unused since pic support went away.

llvm-svn: 178055
2013-03-26 18:41:47 +00:00
Nadav Rotem 1da30944a6 Make clang to mark static stack allocations with lifetime markers to enable a more aggressive stack coloring.
Patch by John McCall with help by Shuxin Yang.
rdar://13115369

llvm-svn: 177819
2013-03-23 06:43:35 +00:00
Alexey Bataev a769e07232 OpenMP threadprivate directive parsing and semantic analysis
llvm-svn: 177705
2013-03-22 06:34:35 +00:00
Adrian Prantl 51936dd0bc Allocate stack storage for .block_descriptor and captured self at -O0.
This way the register allocator will not optimize away the debug info
for captured variables.

Fixes rdar://problem/12767564

llvm-svn: 177086
2013-03-14 17:53:33 +00:00
John McCall cdda29c968 Tighten up the rules for precise lifetime and document
the requirements on the ARC optimizer.

rdar://13407451

llvm-svn: 176924
2013-03-13 03:10:54 +00:00
John McCall a8ec7eb9cf Promote atomic type sizes up to a power of two, capped by
MaxAtomicPromoteWidth.  Fix a ton of terrible bugs with
_Atomic types and (non-intrinsic-mediated) loads and stores
thereto.

llvm-svn: 176658
2013-03-07 21:37:17 +00:00
John McCall 47fb950871 Change hasAggregateLLVMType, which conflates complex and
aggregate types in a profoundly wrong way that has to be
worked around in every call site, to getEvaluationKind,
which classifies and distinguishes between all of these
cases.

Also, normalize the API for loading and storing complexes.

I'm working on a larger patch and wanted to pull these
changes out, but it would have be annoying to detangle
them from each other.

llvm-svn: 176656
2013-03-07 21:37:08 +00:00
Michael Han 84324357b8 [Sema] Semantic analysis for empty-declaration and attribute-declaration.
Introduce a new AST Decl node "EmptyDecl" to model empty-declaration. Have attributes from attribute-declaration appertain
to the EmptyDecl node by creating the AST representations of these attributes and attach them to the EmptyDecl node so these
attributes can be sema checked just as attributes attached to "normal" declarations.

llvm-svn: 175900
2013-02-22 17:15:32 +00:00
Fariborz Jahanian 134cec62ab objective-C arc IR-gen. Retaining of strong
arguments in function prologue is done
with objc_StoreStrong to pair it with
similar objc_StoreStrong for release in function
epilogue. This is done with -O0 only.
// rdar://13145317

llvm-svn: 175698
2013-02-21 00:40:10 +00:00
David Blaikie b7d1e1ff57 Revert r174246, accidentally committed.
This reverts commit 1513eb9284c23acfd19cf742b95996fbb11ca741.

llvm-svn: 174249
2013-02-02 00:39:32 +00:00
David Blaikie ef50169a03 Basics
llvm-svn: 174246
2013-02-02 00:34:16 +00:00
John McCall 12cc42aa1b Destroy arrays and ARC fields when throwing out of ctors.
Previously we were only handling non-array fields of class type.

Testcases derived from a patch by WenHan Gu.

llvm-svn: 174146
2013-02-01 05:11:40 +00:00
Douglas Gregor 6153500517 When we're emitting a constructor or destructor call from a delegating
constructor, retrieve our VTT parameter directly. Fixes PR14588 /
<rdar://problem/12867962>.

llvm-svn: 174042
2013-01-31 05:50:40 +00:00
Chandler Carruth ffd5551bc7 Rewrite #includes for llvm/Foo.h to llvm/IR/Foo.h as appropriate to
reflect the migration in r171366.

Re-sort the #include lines to reflect the new paths.

llvm-svn: 171369
2013-01-02 11:45:17 +00:00
NAKAMURA Takumi 320c1f8806 CGDecl.cpp: Prune three descriptions in two methods, CodeGenFunction::pushIrregularPartialArrayCleanup() and CodeGenFunction::pushRegularPartialArrayCleanup(). [-Wdocumentation]
/// \param array - a value of type elementType*
/// \param destructionKind - the kind of destruction required
/// \param initializedElementCount - a value of type size_t* holding the number of successfully-constructed elements

llvm-svn: 171013
2012-12-24 01:48:59 +00:00
Rafael Espindola 2be6b72ce0 Don't eagerly emit a global static merged with a local extern.
When we are visiting the extern declaration of 'i' in

static int i = 99;
int foo() {
  extern int i;
  return i;
}

We should not try to handle it as if it was an function static. That is, we
must consider the written storage class.

Fixing this then exposes that the assert in EmitGlobalVarDeclLValue and the
if leading to its call are not completely accurate. They were passing before
because the second decl was marked as having external storage. I changed them
to check the linkage, which I find easier to understand.

Last but not least, there is something strange going on with cuda and opencl.
My guess is that the linkage computation for these languages needs to be
audited, but I didn't want to change that in this patch so I just updated
the storage classes to keep the current behavior.

Thanks to Reed Kotler for reporting this.

llvm-svn: 170827
2012-12-21 01:21:33 +00:00
Chandler Carruth 3a02247dc9 Sort all of Clang's files under 'lib', and fix up the broken headers
uncovered.

This required manually correcting all of the incorrect main-module
headers I could find, and running the new llvm/utils/sort_includes.py
script over the files.

I also manually added quite a few missing headers that were uncovered by
shuffling the order or moving headers up to be main-module-headers.

llvm-svn: 169237
2012-12-04 09:13:33 +00:00
Richard Smith 9c6890a792 Simplify: replace getContext().getLangOpts() with just getLangOpts().
llvm-svn: 167261
2012-11-01 22:30:59 +00:00
Douglas Gregor b0eea8b54b Switch CodeGenOptions over to a .def file, like we do with LangOptions.
llvm-svn: 166497
2012-10-23 20:05:01 +00:00
Micah Villmow dd31ca10ef Move TargetData to DataLayout.
llvm-svn: 165395
2012-10-08 16:25:52 +00:00
Sylvestre Ledru 33b5baf189 Revert 'Fix a typo 'iff' => 'if''. iff is an abreviation of if and only if. See: http://en.wikipedia.org/wiki/If_and_only_if Commit 164766
llvm-svn: 164769
2012-09-27 10:16:10 +00:00
Sylvestre Ledru a876013dc9 Fix a typo 'iff' => 'if'
llvm-svn: 164766
2012-09-27 09:57:10 +00:00
Peter Collingbourne ee0502d551 CUDA: give correct address space to globals declared in functions
llvm-svn: 162787
2012-08-28 20:37:10 +00:00
Benjamin Kramer 29f9a00732 CodeGen: Hoist check from recursive function to its only callsite.
Suggested by Roman Divacky.

llvm-svn: 162702
2012-08-27 22:07:02 +00:00
Benjamin Kramer 46cbe77b49 CodeGen: When emitting stores for an initializer, only emit a GEP if we really need the store.
This avoids emitting many dead GEPs for large zero-initialized arrays.

llvm-svn: 162701
2012-08-27 21:35:58 +00:00
Hans Wennborg f60f6af9e8 Add -ftls-model command-line flag.
This allows for setting the default TLS model. (PR9788)

llvm-svn: 159336
2012-06-28 08:01:44 +00:00
Hans Wennborg d3b01bc7c6 Support the tls_model attribute (PR9788)
This adds support for the tls_model attribute. This allows the user to
choose a TLS model that is better than what LLVM would select by
default. For example, a variable might be declared as:

  __thread int x __attribute__((tls_model("initial-exec")));

if it will not be used in a shared library that is dlopen'ed.

This depends on LLVM r159077.

llvm-svn: 159078
2012-06-23 11:51:46 +00:00
Fariborz Jahanian a36cbeb464 objc-arc: captured block variable accessed in its block literal
initializer need be null initialized before initializer takes
hold, just like any other initialized retainable object pointer. 
// rdar://11016025

llvm-svn: 158738
2012-06-19 20:53:26 +00:00
Alexey Samsonov 74a3868dbb This patch adds a new Clang compiler flag "-gline-tables-only".
It reduces the amount of emitted debug information:
1) DIEs in .debug_info have types DW_TAG_compile_unit, DW_TAG_subprogram,
DW_TAG_inlined_subroutine (for opt builds) and DW_TAG_lexical_block only.
2) .debug_str contains only function names.
3) No debug data for types/namespaces/variables is emitted.
4) The data in .debug_line is enough to produce valid stack traces with
function names and line numbers.

Reviewed by Eric Christopher.

llvm-svn: 156160
2012-05-04 07:39:27 +00:00
John McCall 8c38d35b05 Don't enter cleanups for unreachable variables. It's impossible to
jump into these scopes, and the cleanup-entering code sometimes wants
to do some operations first (e.g. a GEP), which can leave us with
unparented IR.

llvm-svn: 154684
2012-04-13 18:44:05 +00:00
John McCall b88a566cc1 Make sure we unique static-local decls across multiple emissions of
the function body, but do so in a way that doesn't make any assumptions
about the static local actually having a proper, unique mangling,
since apparently we don't do that correctly at all.

llvm-svn: 153776
2012-03-30 21:00:39 +00:00
Chandler Carruth 8453795255 Revert r153723, and its follow-ups r153728 and r153733.
These patches cause us to miscompile and/or reject code with static
function-local variables in an extern-C context. Previously, we were
papering over this as long as the variables are within the same
translation unit, and had not seen any failures in the wild. We still
need a proper fix, which involves mangling static locals inside of an
extern-C block (as GCC already does), but this patch causes pretty
widespread regressions. Firefox, and many other applications no longer
build.

Lots of test cases have been posted to the list in response to this
commit, so there should be no problem reproducing the issues.

llvm-svn: 153768
2012-03-30 19:44:53 +00:00
John McCall 87590e60c0 Do the static-locals thing properly in the face of unions and
other things which might mess with the variable's type.

llvm-svn: 153733
2012-03-30 07:09:50 +00:00
John McCall 947c1830e4 When emitting a static local variable in C++, handle
the case that the variable already exists.  Partly this is just
protection against people making crazy declarations with custom
asm labels or extern "C" names that intentionally collide with
the manglings of such variables, but the main reason is that we
can actually emit a static local variable twice with the
requirement that it match up.  There may be other cases with
(e.g.) the various nested functions, but the main exemplar is
with constructor variants, where we can be forced into
double-emitting the function body under certain circumstances
like (currently) the presence of virtual bases.

llvm-svn: 153723
2012-03-30 04:25:14 +00:00
Chad Rosier 615ed1a3a6 Revert r153613 as it's causing large compile-time regressions on the nightly testers.
llvm-svn: 153660
2012-03-29 17:37:10 +00:00
John McCall 1a0877f99d When we can't prove that the target of an aggregate copy is
a complete object, the memcpy needs to use the data size of
the structure instead of its sizeof() value.  Fixes PR12204.

llvm-svn: 153613
2012-03-28 23:30:44 +00:00
David Blaikie bbafb8a745 Unify naming of LangOptions variable/get function across the Clang stack (Lex to AST).
The member variable is always "LangOpts" and the member function is always "getLangOpts".

Reviewed by Chris Lattner

llvm-svn: 152536
2012-03-11 07:00:24 +00:00
John McCall 113bee0536 Remove BlockDeclRefExpr and introduce a bit on DeclRefExpr to
track whether the referenced declaration comes from an enclosing
local context.  I'm amenable to suggestions about the exact meaning
of this bit.

llvm-svn: 152491
2012-03-10 09:33:50 +00:00
Eli Friedman 1c8d2ca829 Make sure we update the static local decl address map when we are forced to rebuild a global because of the initializer. <rdar://problem/10957867>.
llvm-svn: 152372
2012-03-09 03:27:46 +00:00
Sebastian Redl d026dc499c Make heap-allocation of std::initializer_list 'work'.
llvm-svn: 150931
2012-02-19 16:03:09 +00:00
Chad Rosier 1d9cdb6c42 Fix comment.
llvm-svn: 150859
2012-02-18 01:20:35 +00:00
Sebastian Redl c83ed8248e Basic code generation support for std::initializer_list.
We now generate temporary arrays to back std::initializer_list objects
initialized with braces. The initializer_list is then made to point at
the array. We support both ptr+size and start+end forms, although
the latter is untested.

Array lifetime is correct for temporary std::initializer_lists (e.g.
call arguments) and local variables. It is untested for new expressions
and member initializers.

Things left to do:
Massively increase the amount of testing. I need to write tests for
start+end init lists, temporary objects created as a side effect of
initializing init list objects, new expressions, member initialization,
creation of temporary objects (e.g. std::vector) for initializer lists,
and probably more.
Get lifetime "right" for member initializers and new expressions. Not
that either are very useful.
Implement list-initialization of array new expressions.

llvm-svn: 150803
2012-02-17 08:42:25 +00:00
Richard Smith e070fd2ac8 Bug fix: do not emit static const local variables with mutable members
as constants.

Refactor and simplify all the separate checks for whether a type can be
emitted as a constant.

llvm-svn: 150793
2012-02-17 06:48:11 +00:00
John McCall a729c62b81 Whether an argument is required (in contrast with being an
optional argument passed through the variadic ellipsis)
potentially affects how we need to lower it.  Propagate
this information down to the various getFunctionInfo(...)
overloads on CodeGenTypes.  Furthermore, rename those
overloads to clarify their distinct purposes, and make
sure we're calling the right one in the right place.
This has a nice side-effect of making it easier to construct
a function type, since the 'variadic' bit is no longer
separable.

This shouldn't really change anything for our existing
platforms, with one minor exception --- we should now call
variadic ObjC methods with the ... in the "right place"
(see the test case), which I guess matters for anyone
running GNUStep on MIPS.  Mostly it's just a substantial
clean-up.

llvm-svn: 150788
2012-02-17 03:33:10 +00:00
Richard Smith 6331c408b5 Deal with a horrible C++11 special case. If a non-literal type has a constexpr
constructor, and that constructor is used to initialize an object of static
storage duration such that all members and bases are initialized by constant
expressions, constant initialization is performed. In this case, the object
can still have a non-trivial destructor, and if it does, we must emit a dynamic
initializer which performs no initialization and instead simply registers that
destructor.

llvm-svn: 150419
2012-02-13 22:16:19 +00:00
Richard Smith 5a294e6a2c CWG issue 1405: mutable members are allowed in literal types, but can't undergo
lvalue-to-rvalue conversions in constant expressions.

llvm-svn: 150145
2012-02-09 03:29:58 +00:00