Mostly short-circuits some conditionals. Adds target validation of
sections passed to these pragmas.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@231317 91177308-0d34-0410-b5e6-96231b3b80d8
They cannot be written to, so marking them const makes sense and may improve
optimisation.
As a side-effect, SectionInfos has to be moved from Sema to ASTContext.
It also fixes this problem, that occurs when compiling ATL:
warning LNK4254: section 'ATL' (C0000040) merged into '.rdata' (40000040) with different attributes
The ATL headers are putting variables in a special section that's marked
read-only. However, Clang currently can't model that read-onlyness in the IR.
But, by making the variables const, the section does become read-only, and
the linker warning is avoided.
Differential Revision: http://reviews.llvm.org/D5812
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@219960 91177308-0d34-0410-b5e6-96231b3b80d8
Test Plan: I noticed this through code inspection. The callers use the return value to remove the SectionAttr if a diagnostic is emitted, but I don't think the failure to do so is observable right now.
Reviewers: rnk
Subscribers: cfe-commits
Differential Revision: http://reviews.llvm.org/D5438
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@218265 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
This pragma is very rare. We could *hypothetically* lower some uses of
it down to @llvm.global_ctors, but given that GlobalOpt isn't able to
optimize prioritized global ctors today, there's really no point.
If we wanted to do this in the future, I would check if the section used
in the pragma started with ".CRT$XC" and had up to two characters after
it. Those two characters could form the 16-bit initialization priority
that we support in @llvm.global_ctors. We would have to teach LLVM to
lower prioritized global ctors on COFF as well.
This should let us compile some silly uses of this pragma in WebKit /
Blink.
Reviewers: rsmith, majnemer
Subscribers: cfe-commits
Differential Revision: http://reviews.llvm.org/D4549
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@213593 91177308-0d34-0410-b5e6-96231b3b80d8
This patch implements support for selectively disabling optimizations on a
range of function definitions through a pragma. The implementation is that
all function definitions in the range are decorated with attribute
'optnone'.
#pragma clang optimize off
// All function definitions in here are decorated with 'optnone'.
#pragma clang optimize on
// Compilation resumes as normal.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@209510 91177308-0d34-0410-b5e6-96231b3b80d8
This patch adds support for the msvc pragmas section, bss_seg, code_seg,
const_seg and data_seg as well as support for __declspec(allocate()).
Additionally it corrects semantics and adds diagnostics for
__attribute__((section())) and the interaction between the attribute
and the msvc pragmas and declspec. In general conflicts should now be
well diganosed within and among these features.
In supporting the pragmas new machinery for uniform lexing for
msvc pragmas was introduced. The new machinery always lexes the
entire pragma and stores it on an annotation token. The parser
is responsible for parsing the pragma when the handling the
annotation token.
There is a known outstanding bug in this implementation in C mode.
Because these attributes and pragmas apply _only_ to definitions, we
process them at the time we detect a definition. Due to tentative
definitions in C, we end up processing the definition late. This means
that in C mode, everything that ends up in a BSS section will end up in
the _last_ BSS section rather than the one that was live at the time of
tentative definition, even if that turns out to be the point of actual
definition. This issue is not known to impact anything as of yet
because we are not aware of a clear use or use case for #pragma bss_seg
but should be fixed at some point.
Differential Revision=http://reviews.llvm.org/D3065#inline-16241
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@205810 91177308-0d34-0410-b5e6-96231b3b80d8
These features are new in VS 2013 and are necessary in order to layout
std::ostream correctly. Currently we have an ABI incompatibility when
self-hosting with the 2013 stdlib in our convertible_fwd_ostream wrapper
in gtest.
This change adds another implicit attribute, MSVtorDispAttr, because
implicit attributes are currently the best way to make sure the
information stays on class templates through instantiation.
Reviewers: majnemer
Differential Revision: http://llvm-reviews.chandlerc.com/D2746
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@201274 91177308-0d34-0410-b5e6-96231b3b80d8
Introduce a notion of a 'current representation method' for
pointers-to-members.
When starting out, this is set to 'best case' (representation method is
chosen by examining the class, selecting the smallest representation
that would work given the class definition or lack thereof).
This pragma allows the translation unit to dictate exactly what
representation to use, similar to how the inheritance model keywords
operate.
N.B. PCH support is forthcoming.
Differential Revision: http://llvm-reviews.chandlerc.com/D2723
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@201105 91177308-0d34-0410-b5e6-96231b3b80d8
Additionally, remove the optional nature of the spelling list index when creating attributes. This is supported by table generating a Spelling enumeration when the spellings for an attribute are distinct enough to warrant it.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@199378 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
Most of this change is wiring the pragma all the way through from the
lexer, parser, and sema to codegen. I considered adding a Decl AST node
for this, but it seemed too heavyweight.
Mach-O already uses a metadata flag called "Linker Options" to do this
kind of auto-linking. This change follows that pattern.
LLVM knows how to forward the "Linker Options" metadata into the COFF
.drectve section where these flags belong. ELF support is not
implemented, but possible.
This is related to auto-linking, which is http://llvm.org/PR13016.
CC: cfe-commits
Differential Revision: http://llvm-reviews.chandlerc.com/D723
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@181426 91177308-0d34-0410-b5e6-96231b3b80d8
control the visibility of a type for the purposes of RTTI
and template argument restrictions independently of how
visibility propagates to its non-type member declarations.
Also fix r175326 to not ignore template argument visibility
on a template explicit instantiation when a member has
an explicit attribute but the instantiation does not.
The type_visibility work is rdar://11880378
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@175587 91177308-0d34-0410-b5e6-96231b3b80d8
The testcase in pr14929 shows that this is extremely hard to do. If we choose
to apply the attribute, that causes the visibility of some decls to change and
that can happen really late (during codegen).
Current gcc warns and ignores the attribute in this testcase with a warning.
This suggest that the correct solution is to find a point in the compilation
where we can compute the visibility and
* assert it was never computed before
* reject any attempts to compute it again in the future (with warnings).
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@172305 91177308-0d34-0410-b5e6-96231b3b80d8
the body of a functions. The problem was that hasBody looks at the entire chain
and causes problems to -fvisibility-inlines-hidden if the cache was not
invalidated.
Original message:
Cache visibility of decls.
This unifies the linkage and visibility caching. I first implemented this when
working on pr13844, but the previous fixes removed the performance advantage of
this one.
This is still a step in the right direction for making linkage and visibility
cheap to use.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@171053 91177308-0d34-0410-b5e6-96231b3b80d8
This unifies the linkage and visibility caching. I first implemented this when
working on pr13844, but the previous fixes removed the performance advantage of
this one.
This is still a step in the right direction for making linkage and visibility
cheap to use.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@171048 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@169237 91177308-0d34-0410-b5e6-96231b3b80d8
The member variable is always "LangOpts" and the member function is always "getLangOpts".
Reviewed by Chris Lattner
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@152536 91177308-0d34-0410-b5e6-96231b3b80d8
CoreFoundation object-transfer properties audited, and add a #pragma
to cause them to be automatically applied to functions in a particular
span of code. This has to be implemented largely in the preprocessor
because of the requirement that the region be entirely contained in
a single file; that's hard to impose from the parser without registering
for a ton of callbacks.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@140846 91177308-0d34-0410-b5e6-96231b3b80d8
platform implies default visibility. To achieve these, refactor our
lookup of explicit visibility so that we search for both an explicit
VisibilityAttr and an appropriate AvailabilityAttr, favoring the
VisibilityAttr if it is present.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@128336 91177308-0d34-0410-b5e6-96231b3b80d8
This allows us to cache a "#pragma unused" that occurs inside an inline C++ member function.
Fixes rdar://8829590&8770988.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@123666 91177308-0d34-0410-b5e6-96231b3b80d8
visibility. Fixes PR8713.
I've disabled a test which was testing that you can #pragma pop visibility
to get out of a namespace's visibility attribute. We should probably just
diagnose that as an error unless it's instrumental to someone's system
headers.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@121459 91177308-0d34-0410-b5e6-96231b3b80d8
One who seeks the Tao unlearns something new every day.
Less and less remains until you arrive at non-action.
When you arrive at non-action,
nothing will be left undone.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@112244 91177308-0d34-0410-b5e6-96231b3b80d8
Peter Collingbourne