Age | Commit message (Collapse) | Author |
|
in general (such an atomic has boolean representation) and
specifically for IR generation of __c11_atomic_init. The latter also
means actually using initialization semantics for this initialization,
rather than just creating a store.
On a related note, make sure we actually put in non-atomic-to-atomic
conversions when performing an implicit conversion sequence. IR
generation is far too kind here, but we still want the ASTs to make
sense.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@154612 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
This is not quite sufficient for libstdc++'s <atomic>: we still need
__atomic_test_and_set and __atomic_clear, and may need a more complete
__atomic_is_lock_free implementation.
We are also missing an implementation of __atomic_always_lock_free,
__atomic_nand_fetch, and __atomic_fetch_nand, but those aren't needed
for libstdc++.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@154579 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
FunctionDecl::Create calls as well.
rdar://11079003
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@154578 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
The mangler doesn't like non-prototyped functions so only use a mangled
name for prototyped functions.
rdar://11079003
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@154570 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
so.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@154569 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
<stdatomic.h> header.
In passing, fix LanguageExtensions to note that C11 and C++11 are no longer
"upcoming standards" but are now actually standardized.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@154513 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
types.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@154507 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
an explicit instance variable.
rdar://10590352
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@154481 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
and emit a relatively empty block for a plain break statement. This
enables us to track where we went through a switch.
PR9796 & rdar://11215207
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@154420 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
rational number, eg as 2.5 rather than 5, 2. OK'd by Peter Collingbourne.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@154388 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@154384 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@154383 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@154327 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
for hooking in code flow visualisation applications.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@154321 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
case as we don't currently have any way of dumping target options or
otherwise observing this. Another small step toward fixing PR12380. With
this we generate TLS accesses using the static model instead of the
dynamic model, but we're still generating suboptimal code under the
mistaken assumption that the TLS offset might be greater than 2^32, and
therefor not viable as an immediate offset of a segment register.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@154298 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
First, this patch cleans up the parsing of the PIC and PIE family of
options in the driver. The existing logic failed to claim arguments all
over the place resulting in kludges that marked the options as unused.
Instead actually walk all of the arguments and claim them properly.
We now treat -f{,no-}{pic,PIC,pie,PIE} as a single set, accepting the
last one on the commandline. Previously there were lots of ordering bugs
that could creep in due to the nature of the parsing. Let me know if
folks would like weird things such as "-fPIE -fno-pic" to turn on PIE,
but disable full PIC. This doesn't make any sense to me, but we could in
theory support it.
Options that seem to have intentional "trump" status (-static, -mkernel,
etc) continue to do so and are commented as such.
Next, a -pie-level flag is threaded into the frontend, rigged to
a language option, and handled preprocessor, setting up the appropriate
defines. We'll now have the correct defines when compiling with -fpie.
The one place outside of the preprocessor that was inspecting the PIC
level (as opposed to the relocation model, which is set and handled
separately, yay!) is in the GNU ObjC runtime. I changed it to exactly
preserve existing behavior. If folks want to change its behavior in the
face of PIE, they can do that in a separate patch.
Essentially the only functionality changed here is the preprocessor
defines and bug-fixes to the argument management.
Tests have been updated and extended to test all of this a bit more
thoroughly.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@154291 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
global destructor entry. For some reason this isn't enabled for
apple-kexts; it'd be good to have documentation for that.
Based on a patch by Nakamura Takumi!
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@154191 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@154190 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@154175 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
synthesized ones. Reasonable debug info size reduction for objc.
rdar://11179756
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@154129 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
as a vector actually usable. Patch by David Neto. PR12465.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@154128 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@154052 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
non-const copy constructor.
This was caused by the code deciding the number of fields in the byref structure using a different test to the part of the code creating the GEPs into said structure.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@154013 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
patch by Timur Iskhodzhanov.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@153990 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@153986 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
property file/line rather than the @synthesize file/line. Avoids
some nasty confusing-ness with conflating the file from the scope
and the line from the original declaration. Use the current scope
location as a separate parameter so that we can match it up
better in the line table with the beginning of the scope.
Update a couple of testcases accordingly since I had to change
that we actually use the passed in location in EmitFunctionStart
and for the new metadata parameter and add a new testcase to
make sure we've got the right line numbers for synthesized
properties.
Part of rdar://11026482
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@153917 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
in the fragile and non-fragile Mac ObjC runtimes. No useful test
case. Fixes rdar://problem/11072576.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@153778 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@153776 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@153768 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
other things which might mess with the variable's type.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@153733 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
pre-c++11-compatible.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@153728 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
is causing the gdb test failures on the bots.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@153727 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@153723 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
inheritance.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@153722 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@153721 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
in general. Found by inspection.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@153720 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
property file/line rather than the @synthesize file/line. Avoids
some nasty confusing-ness with conflating the file from the scope
and the line from the original declaration.
Update a couple of testcases accordingly since I had to change
that we actually use the passed in location in EmitFunctionStart.
Fixes rdar://11026482
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@153714 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
section. A 'normal' string will go into the __TEXT,__const section, but this
isn't good for UTF16 strings. The __ustring section allows for coalescing, among
other niceties (such as allowing the linker to easily split up strings).
Instead of outputting the UTF16 string as a series of bytes, output it as a
series of shorts. The back-end will then nicely place the UTF16 string into the
correct section, because it's a mensch.
<rdar://problem/10655949>
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@153710 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@153698 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
LLVM intrinsics for.
I have an implementation of these functions, which wants to go in a libgcc_s
equivalent in compiler-rt. It's currently here:
http://people.freebsd.org/~theraven/atomic.c
It will be committed to compiler-rt as soon as I work out where would be a
sensible place to put it...
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@153666 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
testers.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@153660 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
in the property debug info. Any more isn't necessary after all.
rdar://11144023
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@153659 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@153658 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
http://llvm.org/docs/SourceLevelDebugging.html#objcproperty
including type and DECL. Expand the getter and setter names
into the fully qualified names.
rdar://11144023
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@153640 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
a complete object, the memcpy needs to use the data size of
the structure instead of its sizeof() value. Fixes PR12204.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@153613 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@153578 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
flag as GCC uses: -fstrict-enums). There is a *lot* of code making
unwarranted assumptions about the underlying type of enums, and it
doesn't seem entirely reasonable to eagerly break all of it.
Much more importantly, the current state of affairs is *very* good at
optimizing based upon this information, which causes failures that are
very distant from the actual enum. Before we push for enabling this by
default, I think we need to implement -fcatch-undefined-behavior support
for instrumenting and trapping whenever we store or load a value outside
of the range. That way we can track down the misbehaving code very
quickly.
I discussed this with Rafael, and currently the only important cases he
is aware of are the bool range-based optimizations which are staying
hard enabled. We've not seen any issue with those either, and they are
much more important for performance.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@153550 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@153447 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@153389 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
Thanks to NAKAMURA Takumi for finding it!
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@153383 91177308-0d34-0410-b5e6-96231b3b80d8
|