This reduces the number of warnings generated by Doxygen by about 100
(roughly 10%). Issues addressed:
(1) Primarily, backslash-escaped "@foo" and "#bah" in Doxygen comments
when they're not supposed to be Doxygen commands or links, and
similarly for "<baz>" when it's not intended as as HTML tag;
(2) Changed some \t commands (which don't exist) to \c ("to refer to a
word of code", as the Doxygen manual says);
(3) \precondition becomes \pre;
(4) When touching comments, deleted a couple of spurious spaces in them;
(5) Changed some \n and \r to \\n and \\r;
(6) Fixed one tiny typo: #pragms -> #pragma.
This patch touches documentation/comments only.
llvm-svn: 158422
__atomic_test_and_set, __atomic_clear, plus a pile of undocumented __GCC_*
predefined macros.
Implement library fallback for __atomic_is_lock_free and
__c11_atomic_is_lock_free, and implement __atomic_always_lock_free.
Contrary to their documentation, GCC's __atomic_fetch_add family don't
multiply the operand by sizeof(T) when operating on a pointer type.
libstdc++ relies on this quirk. Remove this handling for all but the
__c11_atomic_fetch_add and __c11_atomic_fetch_sub builtins.
Contrary to their documentation, __atomic_test_and_set and __atomic_clear
take a first argument of type 'volatile void *', not 'void *' or 'bool *',
and __atomic_is_lock_free and __atomic_always_lock_free have an argument
of type 'const volatile void *', not 'void *'.
With this change, libstdc++4.7's <atomic> passes libc++'s atomic test suite,
except for a couple of libstdc++ bugs and some cases where libc++'s test
suite tests for properties which implementations have latitude to vary.
llvm-svn: 154640
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.
llvm-svn: 154291
- Add atomic-to/from-nonatomic cast types
- Emit atomic operations for arithmetic on atomic types
- Emit non-atomic stores for initialisation of atomic types, but atomic stores and loads for every other store / load
- Add a __atomic_init() intrinsic which does a non-atomic store to an _Atomic() type. This is needed for the corresponding C11 stdatomic.h function.
- Enables the relevant __has_feature() checks. The feature isn't 100% complete yet, but it's done enough that we want people testing it.
Still to do:
- Make the arithmetic operations on atomic types (e.g. Atomic(int) foo = 1; foo++;) use the correct LLVM intrinsic if one exists, not a loop with a cmpxchg.
- Add a signal fence builtin
- Properly set the fenv state in atomic operations on floating point values
- Correctly handle things like _Atomic(_Complex double) which are too large for an atomic cmpxchg on some platforms (this requires working out what 'correctly' means in this context)
- Fix the many remaining corner cases
llvm-svn: 148242
part of HeaderSearch. This function just normalizes filenames for use
inside of a synthetic include directive, but it is used in both the
Frontend and Serialization libraries so it needs a common home.
llvm-svn: 146227
language options. Use that .def file to declare the LangOptions class
and initialize all of its members, eliminating a source of annoying
initialization bugs.
AST serialization changes are next up.
llvm-svn: 139605
structure to hold inferred information, then propagate each invididual
bit down to -cc1. Separate the bits of "supports weak" and "has a native
ARC runtime"; make the latter a CodeGenOption.
The tool chain is still driving this decision, because it's the place that
has the required deployment target information on Darwin, but at least it's
better-factored now.
llvm-svn: 134453
Language-design credit goes to a lot of people, but I particularly want
to single out Blaine Garst and Patrick Beard for their contributions.
Compiler implementation credit goes to Argyrios, Doug, Fariborz, and myself,
in no particular order.
llvm-svn: 133103
matches GCC behavior which libstdc++ uses to limit #warning-based
messages about deprecation.
The machinery involves threading this through a new '-fdeprecated-macro'
flag for CC1. The flag defaults to "on", similarly to -Wdeprecated. We
turn the flag off in the driver when the warning is turned off (modulo
matching some GCC bugs). We record this as a language option, and key
the preprocessor on the option when introducing the define.
A separate flag rather than a '-D' flag allows us to properly represent
the difference between C and C++ builds (only C++ receives the define),
and it allows the specific behavior of following -Wdeprecated without
potentially impacting the set of user-provided macro flags.
llvm-svn: 130055
should report the original file name for contents of files that were overriden by other files,
otherwise it should report the name of the new file. Default is true.
Also add similar field in PreprocessorOptions and pass similar parameter in ASTUnit::LoadFromCommandLine.
llvm-svn: 127289
FileSystemOpts through a ton of apis, simplifying a lot of code.
This also fixes a latent bug in ASTUnit where it would invoke
methods on FileManager without creating one in some code paths
in cindextext.
llvm-svn: 120010
When -working-directory is passed in command line, file paths are resolved relative to the specified directory.
This helps both when using libclang (where we can't require the user to actually change the working directory)
and to help reproduce test cases when the reproduction work comes along.
--FileSystemOptions is introduced which controls how file system operations are performed (currently it just contains
the working directory value if set).
--FileSystemOptions are passed around to various interfaces that perform file operations.
--Opening & reading the content of files should be done only through FileManager. This is useful in general since
file operations will be abstracted in the future for the reproduction mechanism.
FileSystemOptions is independent of FileManager so that we can have multiple translation units sharing the same
FileManager but with different FileSystemOptions.
Addresses rdar://8583824.
llvm-svn: 118203
reparsing an ASTUnit. When saving a preamble, create a buffer larger
than the actual file we're working with but fill everything from the
end of the preamble to the end of the file with spaces (so the lexer
will quickly skip them). When we load the file, create a buffer of the
same size, filling it with the file and then spaces. Then, instruct
the lexer to start lexing after the preamble, therefore continuing the
parse from the spot where the preamble left off.
It's now possible to perform a simple preamble build + parse (+
reparse) with ASTUnit. However, one has to disable a bunch of checking
in the PCH reader to do so. That part isn't committed; it will likely
be handled with some other kind of flag (e.g., -fno-validate-pch).
As part of this, fix some issues with null termination of the memory
buffers created for the preamble; we were trying to explicitly
NULL-terminate them, even though they were also getting implicitly
NULL terminated, leading to excess warnings about NULL characters in
source files.
llvm-svn: 109445
'long'. The practical upshot is so that the uint64_t we define in our stdint.h
ends up being compatible with that defined by gcc (at least on Darwin), which
otherwise could lead to type incompatibilities with other system headers.
llvm-svn: 107255
.S files. "# 123" is passed through as-is, not treated as a line
marker in this mode. No testcase, because it would be nasty and isn't
worth it.
llvm-svn: 102391
copy the source buffers provided rather than referencing them
directly, so that the caller can free those buffers immediately after
calling clang_createTranslationUnitFromSourceFile(). Otherwise, we
risk hitting those buffers later (when building source ranges, forming
diagnostics, etc.).
llvm-svn: 97296
std::vectors.
- MacroBuilder wraps a raw_ostream so it can easily write to any buffer
supported by raw_ostream.
- MacroBuilder's method take Twines for easy string concatenation (this was done
with sprintf and temporary buffers before).
- Targets still use std::vector as they don't have access to the builder.
llvm-svn: 93051
file. This is accomplished by introducing the notion of a "virtual"
file into the file manager, which provides a FileEntry* for a named
file whose size and modification time are known but which may not
exist on disk.
Added a cute little test that remaps both a .c file and a .h file it
includes to alternative files.
llvm-svn: 90329
Ken Dyck!
"This adds definitions for types of 8-bit multiples
from 8 to 64 to stdint.h and rationalizes the selection of types
for the exact-width definitions in InitPreprocessor.cpp."
llvm-svn: 86977
Note that I'm guessing that *BSD and Solaris do the same thing as Linux
here, but it's quite possible I'm wrong; if the following testcase
gives an error on x86-64 with gcc for any of those operating systems, please
tell me:
#include <stdint.h>
int64_t x; long x;
llvm-svn: 74583
function attributes. There are predefined macros that are defined when stack
protectors are used: __SSP__=1 with -fstack-protector and __SSP_ALL__=2 with
-fstack-protector-all.
llvm-svn: 74405
compiled with -fobjc-sender-dependent-dispatch. This is used in AOP, COP, implementing object
planes, and a few other things.
Patch by David Chisnall.
llvm-svn: 72275
buffer. This caused exciting nonsense like this:
$ clang t.c -fsyntax-only -UMACRO
In file included from <built-in>:104:
<command line>:1:14: warning: extra tokens at end of #undef directive [-Wextra-tokens]
#undef MACRO 1
^
//
1 diagnostic generated.
rdar://6891800
llvm-svn: 71860
- If we don't find a file looking relative to the current working
directory, fall back to header search. This is closer to what would
happen if the lookup was starting from right directory in the first
place (except it will find files in the directory of the main
source file, which I *think* should not be found).
- PR3992.
llvm-svn: 69794
by marking the predefines buffer as a system header. The problem
with stdint is that it was getting problems like this:
/Volumes/Projects/cvs/llvm/Debug/lib/clang/1.0/include/stdint.h:43:9: warning: 'long long' is an extension when C99 mode is not enabled
typedef __INT64_TYPE__ int64_t;
^
<built-in>:73:29: note: instantiated from:
#define __INT64_TYPE__ long long
^
We correctly silence warnings in system headers, but only if the
spelling location of the token came from the system header. This is
designed so that if you use a system macro in your code that you don't
get punished for its definition. This is all cool except that the
predefines buffer wasn't considered a system header.
llvm-svn: 69770
Ted Kremenek