From 222e2a7620e6520ffaf4fc4e69d79c18da31542e Mon Sep 17 00:00:00 2001 From: "Zancanaro; Carlo" Date: Mon, 24 Sep 2012 09:58:17 +1000 Subject: Add the clang library to the repo (with some of my changes, too). --- clang/docs/UsersManual.html | 1147 +++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 1147 insertions(+) create mode 100644 clang/docs/UsersManual.html (limited to 'clang/docs/UsersManual.html') diff --git a/clang/docs/UsersManual.html b/clang/docs/UsersManual.html new file mode 100644 index 0000000..b33ed61 --- /dev/null +++ b/clang/docs/UsersManual.html @@ -0,0 +1,1147 @@ + + + +Clang Compiler User's Manual + + + + + + + + +
+ +

Clang Compiler User's Manual

+ + + + + +

Introduction

+ + +

The Clang Compiler is an open-source compiler for the C family of programming +languages, aiming to be the best in class implementation of these languages. +Clang builds on the LLVM optimizer and code generator, allowing it to provide +high-quality optimization and code generation support for many targets. For +more general information, please see the Clang +Web Site or the LLVM Web Site.

+ +

This document describes important notes about using Clang as a compiler for +an end-user, documenting the supported features, command line options, etc. If +you are interested in using Clang to build a tool that processes code, please +see the Clang Internals Manual. If you are +interested in the Clang +Static Analyzer, please see its web page.

+ +

Clang is designed to support the C family of programming languages, which +includes C, Objective-C, C++, and Objective-C++ as well as many +dialects of those. For language-specific information, please see the +corresponding language specific section:

+ + + +

In addition to these base languages and their dialects, Clang supports a +broad variety of language extensions, which are documented in the corresponding +language section. These extensions are provided to be compatible with the GCC, +Microsoft, and other popular compilers as well as to improve functionality +through Clang-specific features. The Clang driver and language features are +intentionally designed to be as compatible with the GNU GCC compiler as +reasonably possible, easing migration from GCC to Clang. In most cases, code +"just works".

+ +

In addition to language specific features, Clang has a variety of features +that depend on what CPU architecture or operating system is being compiled for. +Please see the Target-Specific Features and +Limitations section for more details.

+ +

The rest of the introduction introduces some basic compiler terminology that is used throughout this manual +and contains a basic introduction to using Clang +as a command line compiler.

+ + +

Terminology

+ + +

Front end, parser, backend, preprocessor, undefined behavior, diagnostic, + optimizer

+ + +

Basic Usage

+ + +

Intro to how to use a C compiler for newbies.

+

+compile + link + +compile then link + +debug info + +enabling optimizations + +picking a language to use, defaults to C99 by default. Autosenses based on +extension. + +using a makefile +

+ + + +

Command Line Options

+ + +

+This section is generally an index into other sections. It does not go into +depth on the ones that are covered by other sections. However, the first part +introduces the language selection and other high level options like -c, -g, etc. +

+ + + +

Options to Control Error and Warning Messages

+ + +

-Werror: Turn warnings into errors.

+

-Werror=foo: Turn warning "foo" into an error.

+

-Wno-error=foo: Turn warning "foo" into an warning even if -Werror is + specified.

+

-Wfoo: Enable warning foo

+

-Wno-foo: Disable warning foo

+

-w: Disable all warnings.

+

-pedantic: Warn on language extensions.

+

-pedantic-errors: Error on language extensions.

+

-Wsystem-headers: Enable warnings from system headers.

+ +

-ferror-limit=123: Stop emitting diagnostics after 123 errors have + been produced. The default is 20, and the error limit can be disabled with + -ferror-limit=0.

+ +

-ftemplate-backtrace-limit=123: Only emit up to 123 template instantiation notes within the template instantiation backtrace for a single warning or error. The default is 10, and the limit can be disabled with -ftemplate-backtrace-limit=0.

+ + +

Formatting of Diagnostics

+ + +

Clang aims to produce beautiful diagnostics by default, particularly for new +users that first come to Clang. However, different people have different +preferences, and sometimes Clang is driven by another program that wants to +parse simple and consistent output, not a person. For these cases, Clang +provides a wide range of options to control the exact output format of the +diagnostics that it generates.

+ +
+ + +
-f[no-]show-column: Print column number in +diagnostic.
+
This option, which defaults to on, controls whether or not Clang prints the +column number of a diagnostic. For example, when this is enabled, Clang will +print something like: + +
+  test.c:28:8: warning: extra tokens at end of #endif directive [-Wextra-tokens]
+  #endif bad
+         ^
+         //
+
+ +

When this is disabled, Clang will print "test.c:28: warning..." with no +column number.

+
+ + +
-f[no-]show-source-location: Print +source file/line/column information in diagnostic.
+
This option, which defaults to on, controls whether or not Clang prints the +filename, line number and column number of a diagnostic. For example, +when this is enabled, Clang will print something like: + +
+  test.c:28:8: warning: extra tokens at end of #endif directive [-Wextra-tokens]
+  #endif bad
+         ^
+         //
+
+ +

When this is disabled, Clang will not print the "test.c:28:8: " part.

+
+ + +
-f[no-]caret-diagnostics: Print source +line and ranges from source code in diagnostic.
+
This option, which defaults to on, controls whether or not Clang prints the +source line, source ranges, and caret when emitting a diagnostic. For example, +when this is enabled, Clang will print something like: + +
+  test.c:28:8: warning: extra tokens at end of #endif directive [-Wextra-tokens]
+  #endif bad
+         ^
+         //
+
+
+ +
-f[no-]color-diagnostics:
+
This option, which defaults to on when a color-capable terminal is + detected, controls whether or not Clang prints diagnostics in color. + When this option is enabled, Clang will use colors to highlight + specific parts of the diagnostic, e.g., + 
+  test.c:28:8: warning: extra tokens at end of #endif directive [-Wextra-tokens]
+  #endif bad
+         ^
+         //
+
+ +

When this is disabled, Clang will just print:

+ +
+  test.c:2:8: warning: extra tokens at end of #endif directive [-Wextra-tokens]
+  #endif bad
+         ^
+         //
+
+
+ +
-fdiagnostics-format=clang/msvc/vi: +Changes diagnostic output format to better match IDEs and command line tools.
+
This option controls the output format of the filename, line number, and column printed in diagnostic messages. The options, and their affect on formatting a simple conversion diagnostic, follow: + +
+
clang (default)
+
+ 
t.c:3:11: warning: conversion specifies type 'char *' but the argument has type 'int'
+
+ +
msvc
+
+ 
t.c(3,11) : warning: conversion specifies type 'char *' but the argument has type 'int'
+
+ +
vi
+
+ 
t.c +3:11: warning: conversion specifies type 'char *' but the argument has type 'int'
+
+
+
+ + +
-f[no-]diagnostics-show-name: +Enable the display of the diagnostic name.
+
This option, which defaults to off, controls whether or not +Clang prints the associated name.

+ +
-f[no-]diagnostics-show-option: +Enable [-Woption] information in diagnostic line.
+
This option, which defaults to on, +controls whether or not Clang prints the associated warning group option name when outputting +a warning diagnostic. For example, in this output: + +
+  test.c:28:8: warning: extra tokens at end of #endif directive [-Wextra-tokens]
+  #endif bad
+         ^
+         //
+
+ +

Passing -fno-diagnostics-show-option will prevent Clang from printing +the [-Wextra-tokens] information in the +diagnostic. This information tells you the flag needed to enable or disable the +diagnostic, either from the command line or through #pragma GCC diagnostic.

+ + +
-fdiagnostics-show-category=none/id/name: +Enable printing category information in diagnostic line.
+
This option, which defaults to "none", +controls whether or not Clang prints the category associated with a diagnostic +when emitting it. Each diagnostic may or many not have an associated category, +if it has one, it is listed in the diagnostic categorization field of the +diagnostic line (in the []'s). + +

For example, a format string warning will produce these three renditions +based on the setting of this option:

+ +
+  t.c:3:11: warning: conversion specifies type 'char *' but the argument has type 'int' [-Wformat]
+  t.c:3:11: warning: conversion specifies type 'char *' but the argument has type 'int' [-Wformat,1]
+  t.c:3:11: warning: conversion specifies type 'char *' but the argument has type 'int' [-Wformat,Format String]
+
+ +

This category can be used by clients that want to group diagnostics by +category, so it should be a high level category. We want dozens of these, not +hundreds or thousands of them.

+
+ + + + +
-f[no-]diagnostics-fixit-info: +Enable "FixIt" information in the diagnostics output.
+
This option, which defaults to on, controls whether or not Clang prints the +information on how to fix a specific diagnostic underneath it when it knows. +For example, in this output: + +
+  test.c:28:8: warning: extra tokens at end of #endif directive [-Wextra-tokens]
+  #endif bad
+         ^
+         //
+
+ +

Passing -fno-diagnostics-fixit-info will prevent Clang from printing +the "//" line at the end of the message. This information is useful for users +who may not understand what is wrong, but can be confusing for machine +parsing.

+
+ + +
+-f[no-]diagnostics-print-source-range-info: +Print machine parsable information about source ranges.
+
This option, which defaults to off, controls whether or not Clang prints +information about source ranges in a machine parsable format after the +file/line/column number information. The information is a simple sequence of +brace enclosed ranges, where each range lists the start and end line/column +locations. For example, in this output: + +
+exprs.c:47:15:{47:8-47:14}{47:17-47:24}: error: invalid operands to binary expression ('int *' and '_Complex float')
+   P = (P-42) + Gamma*4;
+       ~~~~~~ ^ ~~~~~~~
+
+ +

The {}'s are generated by -fdiagnostics-print-source-range-info.

+
+ + +
+-fdiagnostics-parseable-fixits: +Print Fix-Its in a machine parseable form.
+

This option makes Clang print available Fix-Its in a machine parseable format at the end of diagnostics. The following example illustrates the format:

+ +
+ fix-it:"t.cpp":{7:25-7:29}:"Gamma"
+
+ +

The range printed is a half-open range, so in this example the characters at +column 25 up to but not including column 29 on line 7 in t.cpp should be +replaced with the string "Gamma". Either the range or the replacement +string may be empty (representing strict insertions and strict erasures, +respectively). Both the file name and the insertion string escape backslash (as +"\\"), tabs (as "\t"), newlines (as "\n"), double +quotes(as "\"") and non-printable characters (as octal +"\xxx").

+
+ +
+ + + + +

Individual Warning Groups

+ + +

TODO: Generate this from tblgen. Define one anchor per warning group.

+ + +
+ + + +
-Wextra-tokens: Warn about excess tokens at + the end of a preprocessor directive.
+
This option, which defaults to on, enables warnings about extra tokens at +the end of preprocessor directives. For example: + +
+  test.c:28:8: warning: extra tokens at end of #endif directive [-Wextra-tokens]
+  #endif bad
+         ^
+
+ +

These extra tokens are not strictly conforming, and are usually best handled +by commenting them out.

+ +

This option is also enabled by -Wfoo, -Wbar, + and -Wbaz.

+
+ + +
-Wambiguous-member-template: +Warn about unqualified uses of a member template whose name resolves +to another template at the location of the use.
+
This option, which defaults to on, enables a warning in the +following code: + +
+template<typename T> struct set{};
+template<typename T> struct trait { typedef const T& type; };
+struct Value {
+  template<typename T> void set(typename trait<T>::type value) {}
+};
+void foo() {
+  Value v;
+  v.set<double>(3.2);
+}
+
+ +

C++ [basic.lookup.classref] requires this to be an error, but, +because it's hard to work around, Clang downgrades it to a warning as +an extension.

+
+ + +
-Wbind-to-temporary-copy: Warn about +an unusable copy constructor when binding a reference to a temporary.
+
This option, which defaults to on, enables warnings about binding a +reference to a temporary when the temporary doesn't have a usable copy +constructor. For example: + +
+  struct NonCopyable {
+    NonCopyable();
+  private:
+    NonCopyable(const NonCopyable&);
+  };
+  void foo(const NonCopyable&);
+  void bar() {
+    foo(NonCopyable());  // Disallowed in C++98; allowed in C++11.
+  }
+
+
+  struct NonCopyable2 {
+    NonCopyable2();
+    NonCopyable2(NonCopyable2&);
+  };
+  void foo(const NonCopyable2&);
+  void bar() {
+    foo(NonCopyable2());  // Disallowed in C++98; allowed in C++11.
+  }
+
+ +

Note that if NonCopyable2::NonCopyable2() has a default +argument whose instantiation produces a compile error, that error will +still be a hard error in C++98 mode even if this warning is turned +off.

+ +
+ +
+ + +

Options to Control Clang Crash Diagnostics

+ + +

As unbelievable as it may sound, Clang does crash from time to time. +Generally, this only occurs to those living on the +bleeding edge. Clang +goes to great lengths to assist you in filing a bug report. Specifically, Clang +generates preprocessed source file(s) and associated run script(s) upon a +crash. These files should be attached to a bug report to ease reproducibility +of the failure. Below are the command line options to control the crash +diagnostics. +

+ +

-fno-crash-diagnostics: Disable auto-generation of preprocessed +source files during a clang crash.

+ +

The -fno-crash-diagnostics flag can be helpful for speeding the process of +generating a delta reduced test case.

+ + + +

Language and Target-Independent Features

+ + + + +

Controlling Errors and Warnings

+ + +

Clang provides a number of ways to control which code constructs cause it to +emit errors and warning messages, and how they are displayed to the console.

+ +

Controlling How Clang Displays Diagnostics

+ +

When Clang emits a diagnostic, it includes rich information in the output, +and gives you fine-grain control over which information is printed. Clang has +the ability to print this information, and these are the options that control +it:

+ +
    +
  1. A file/line/column indicator that shows exactly where the diagnostic occurs + in your code [-fshow-column, -fshow-source-location].
    2. +
  2. A categorization of the diagnostic as a note, warning, error, or fatal + error.
    3. +
  3. A text string that describes what the problem is.
    4. +
  4. An option that indicates how to control the diagnostic (for diagnostics that + support it) [-fdiagnostics-show-option].
    5. +
  5. A high-level category for the + diagnostic for clients that want to group diagnostics by class (for + diagnostics that support it) [-fdiagnostics-show-category].
    6. +
  6. The line of source code that the issue occurs on, along with a caret and + ranges that indicate the important locations [-fcaret-diagnostics].
    7. +
  7. "FixIt" information, which is a concise explanation of how to fix the + problem (when Clang is certain it knows) [-fdiagnostics-fixit-info].
    8. +
  8. A machine-parsable representation of the ranges involved (off by + default) [-fdiagnostics-print-source-range-info].
    9. +
+ +

For more information please see Formatting of +Diagnostics.

+ + +

Diagnostic Mappings

+ +

All diagnostics are mapped into one of these 5 classes:

+ + + +

Diagnostic Categories

+ +

Though not shown by default, diagnostics may each be associated with a + high-level category. This category is intended to make it possible to triage + builds that produce a large number of errors or warnings in a grouped way. +

+ +

Categories are not shown by default, but they can be turned on with the +-fdiagnostics-show-category option. +When set to "name", the category is printed textually in the diagnostic +output. When it is set to "id", a category number is printed. The +mapping of category names to category id's can be obtained by running 'clang + --print-diagnostic-categories'. +

+ +

Controlling Diagnostics via Command Line + Flags

+ +

-W flags, -pedantic, etc

+ +

Controlling Diagnostics via Pragmas

+ +

Clang can also control what diagnostics are enabled through the use of +pragmas in the source code. This is useful for turning off specific warnings +in a section of source code. Clang supports GCC's pragma for compatibility +with existing source code, as well as several extensions.

+ +

The pragma may control any warning that can be used from the command line. +Warnings may be set to ignored, warning, error, or fatal. The following +example code will tell Clang or GCC to ignore the -Wall warnings:

+ +
+#pragma GCC diagnostic ignored "-Wall"
+
+ +

In addition to all of the functionality provided by GCC's pragma, Clang +also allows you to push and pop the current warning state. This is particularly +useful when writing a header file that will be compiled by other people, because +you don't know what warning flags they build with.

+ +

In the below example +-Wmultichar is ignored for only a single line of code, after which the +diagnostics return to whatever state had previously existed.

+ +
+#pragma clang diagnostic push
+#pragma clang diagnostic ignored "-Wmultichar"
+
+char b = 'df'; // no warning.
+
+#pragma clang diagnostic pop
+
+ +

The push and pop pragmas will save and restore the full diagnostic state of +the compiler, regardless of how it was set. That means that it is possible to +use push and pop around GCC compatible diagnostics and Clang will push and pop +them appropriately, while GCC will ignore the pushes and pops as unknown +pragmas. It should be noted that while Clang supports the GCC pragma, Clang and +GCC do not support the exact same set of warnings, so even when using GCC +compatible #pragmas there is no guarantee that they will have identical behaviour +on both compilers.

+ +

Enabling All Warnings

+ +

In addition to the traditional -W flags, one can enable all + warnings by passing -Weverything. + This works as expected with -Werror, + and also includes the warnings from -pedantic.

+ +

Note that when combined with -w (which disables all warnings), that + flag wins.

+ +

Controlling Static Analyzer Diagnostics

+ +

While not strictly part of the compiler, the diagnostics from Clang's static analyzer can also be influenced +by the user via changes to the source code. This can be done in two ways: + +

+ + +

Precompiled Headers

+ + +

Precompiled +headers are a general approach employed by many compilers to reduce +compilation time. The underlying motivation of the approach is that it is +common for the same (and often large) header files to be included by +multiple source files. Consequently, compile times can often be greatly improved +by caching some of the (redundant) work done by a compiler to process headers. +Precompiled header files, which represent one of many ways to implement +this optimization, are literally files that represent an on-disk cache that +contains the vital information necessary to reduce some of the work +needed to process a corresponding header file. While details of precompiled +headers vary between compilers, precompiled headers have been shown to be +highly effective at speeding up program compilation on systems with very large +system headers (e.g., Mac OS/X).

+ +

Generating a PCH File

+ +

To generate a PCH file using Clang, one invokes Clang with +the -x <language>-header option. This mirrors the +interface in GCC for generating PCH files:

+ +
+  $ gcc -x c-header test.h -o test.h.gch
+  $ clang -x c-header test.h -o test.h.pch
+
+ +

Using a PCH File

+ +

A PCH file can then be used as a prefix header when a +-include option is passed to clang:

+ +
+  $ clang -include test.h test.c -o test
+
+ +

The clang driver will first check if a PCH file for test.h +is available; if so, the contents of test.h (and the files it includes) +will be processed from the PCH file. Otherwise, Clang falls back to +directly processing the content of test.h. This mirrors the behavior of +GCC.

+ +

NOTE: Clang does not automatically use PCH files +for headers that are directly included within a source file. For example:

+ +
+  $ clang -x c-header test.h -o test.h.pch
+  $ cat test.c
+  #include "test.h"
+  $ clang test.c -o test
+
+ +

In this example, clang will not automatically use the PCH file for +test.h since test.h was included directly in the source file +and not specified on the command line using -include.

+ +

Relocatable PCH Files

+

It is sometimes necessary to build a precompiled header from headers that +are not yet in their final, installed locations. For example, one might build a +precompiled header within the build tree that is then meant to be installed +alongside the headers. Clang permits the creation of "relocatable" precompiled +headers, which are built with a given path (into the build directory) and can +later be used from an installed location.

+ +

To build a relocatable precompiled header, place your headers into a +subdirectory whose structure mimics the installed location. For example, if you +want to build a precompiled header for the header mylib.h that +will be installed into /usr/include, create a subdirectory +build/usr/include and place the header mylib.h into +that subdirectory. If mylib.h depends on other headers, then +they can be stored within build/usr/include in a way that mimics +the installed location.

+ +

Building a relocatable precompiled header requires two additional arguments. +First, pass the --relocatable-pch flag to indicate that the +resulting PCH file should be relocatable. Second, pass +-isysroot /path/to/build, which makes all includes for your +library relative to the build directory. For example:

+ +
+  # clang -x c-header --relocatable-pch -isysroot /path/to/build /path/to/build/mylib.h mylib.h.pch
+
+ +

When loading the relocatable PCH file, the various headers used in the PCH +file are found from the system header root. For example, mylib.h +can be found in /usr/include/mylib.h. If the headers are installed +in some other system root, the -isysroot option can be used provide +a different system root from which the headers will be based. For example, +-isysroot /Developer/SDKs/MacOSX10.4u.sdk will look for +mylib.h in +/Developer/SDKs/MacOSX10.4u.sdk/usr/include/mylib.h.

+ +

Relocatable precompiled headers are intended to be used in a limited number +of cases where the compilation environment is tightly controlled and the +precompiled header cannot be generated after headers have been installed. +Relocatable precompiled headers also have some performance impact, because +the difference in location between the header locations at PCH build time vs. +at the time of PCH use requires one of the PCH optimizations, +stat() caching, to be disabled. However, this change is only +likely to affect PCH files that reference a large number of headers.

+ + +

Controlling Code Generation

+ + +

Clang provides a number of ways to control code generation. The options are listed below.

+ + +
+
-fcatch-undefined-behavior: Turn +on runtime code generation to check for undefined behavior.
+ +
This option, which defaults to off, controls whether or not Clang +adds runtime checks for undefined runtime behavior. If a check fails, +__builtin_trap() is used to indicate failure. +The checks are: +
    +
  • Subscripting where the static type of one operand is a variable + which is decayed from an array type and the other operand is + greater than the size of the array or less than zero.
    • +
  • Shift operators where the amount shifted is greater or equal to the + promoted bit-width of the left-hand-side or less than zero.
    • +
  • If control flow reaches __builtin_unreachable. +
  • When llvm implements more __builtin_object_size support, reads and + writes for objects that __builtin_object_size indicates we aren't + accessing valid memory. Bit-fields and vectors are not yet checked. +
+
+ +
-f[no-]address-sanitizer: +Turn on AddressSanitizer, +a memory error detector. + +
-f[no-]thread-sanitizer: +Turn on ThreadSanitizer, an experimental data race detector. +Not ready for widespread use. + +
-fno-assume-sane-operator-new: +Don't assume that the C++'s new operator is sane.
+
This option tells the compiler to do not assume that C++'s global new +operator will always return a pointer that does not +alias any other pointer when the function returns.
+ +
-ftrap-function=[name]: Instruct code +generator to emit a function call to the specified function name for +__builtin_trap().
+ +
LLVM code generator translates __builtin_trap() to a trap +instruction if it is supported by the target ISA. Otherwise, the builtin is +translated into a call to abort. If this option is set, then the code +generator will always lower the builtin to a call to the specified function +regardless of whether the target ISA has a trap instruction. This option is +useful for environments (e.g. deeply embedded) where a trap cannot be properly +handled, or when some custom behavior is desired.
+
+ + +

C Language Features

+ + +

The support for standard C in clang is feature-complete except for the C99 +floating-point pragmas.

+ + +

Extensions supported by clang

+ + +

See clang language extensions.

+ + +

Differences between various standard modes

+ + +

clang supports the -std option, which changes what language mode clang uses. +The supported modes for C are c89, gnu89, c94, c99, gnu99 and various aliases +for those modes. If no -std option is specified, clang defaults to gnu99 mode. +

+ +

Differences between all c* and gnu* modes:

+ + +

Differences between *89 and *99 modes:

+ + +

c94 mode is identical to c89 mode except that digraphs are enabled in +c94 mode (FIXME: And __STDC_VERSION__ should be defined!).

+ + +

GCC extensions not implemented yet

+ + +

clang tries to be compatible with gcc as much as possible, but some gcc +extensions are not implemented yet:

+ + + +

This is not a complete list; if you find an unsupported extension +missing from this list, please send an e-mail to cfe-dev. This list +currently excludes C++; see C++ Language Features. +Also, this list does not include bugs in mostly-implemented features; please +see the +bug tracker for known existing bugs (FIXME: Is there a section for +bug-reporting guidelines somewhere?).

+ + +

Intentionally unsupported GCC extensions

+ + + + + +

Microsoft extensions

+ + +

clang has some experimental support for extensions from +Microsoft Visual C++; to enable it, use the -fms-extensions command-line +option. This is the default for Windows targets. Note that the +support is incomplete; enabling Microsoft extensions will silently drop +certain constructs (including __declspec and Microsoft-style asm statements). +

+ + + + +

C++ Language Features

+ + +

clang fully implements all of standard C++98 except for exported templates +(which were removed in C++11), and +many C++11 features are also +implemented.

+ + +

Controlling implementation limits

+ + +

-fconstexpr-depth=N: Sets the limit for recursive constexpr function +invocations to N. The default is 512.

+ +

-ftemplate-depth=N: Sets the limit for recursively nested template +instantiations to N. The default is 1024.

+ + +

Target-Specific Features and Limitations

+ + + + +

CPU Architectures Features and Limitations

+ + + +

X86

+ + +

The support for X86 (both 32-bit and 64-bit) is considered stable on Darwin +(Mac OS/X), Linux, FreeBSD, and Dragonfly BSD: it has been tested to correctly +compile many large C, C++, Objective-C, and Objective-C++ codebases.

+ +

On x86_64-mingw32, passing i128(by value) is incompatible to Microsoft x64 +calling conversion. You might need to tweak WinX86_64ABIInfo::classify() +in lib/CodeGen/TargetInfo.cpp.

+ + +

ARM

+ + +

The support for ARM (specifically ARMv6 and ARMv7) is considered stable on +Darwin (iOS): it has been tested to correctly compile many large C, C++, +Objective-C, and Objective-C++ codebases. Clang only supports a limited number +of ARM architectures. It does not yet fully support ARMv5, for example.

+ + +

Other platforms

+ +clang currently contains some support for PPC and Sparc; however, significant +pieces of code generation are still missing, and they haven't undergone +significant testing. + +

clang contains limited support for the MSP430 embedded processor, but both +the clang support and the LLVM backend support are highly experimental. + +

Other platforms are completely unsupported at the moment. Adding the +minimal support needed for parsing and semantic analysis on a new platform +is quite easy; see lib/Basic/Targets.cpp in the clang source tree. This level +of support is also sufficient for conversion to LLVM IR for simple programs. +Proper support for conversion to LLVM IR requires adding code to +lib/CodeGen/CGCall.cpp at the moment; this is likely to change soon, though. +Generating assembly requires a suitable LLVM backend. + + +

Operating System Features and Limitations

+ + + +

Darwin (Mac OS/X)

+ + +

No __thread support, 64-bit ObjC support requires SL tools.

+ + +

Windows

+ + +

Experimental supports are on Cygming.

+ +
Cygwin
+ +

Clang works on Cygwin-1.7.

+ +
MinGW32
+ +

Clang works on some mingw32 distributions. +Clang assumes directories as below;

+ + + +

On MSYS, a few tests might fail.

+ +
MinGW-w64
+ +

For 32-bit (i686-w64-mingw32), and 64-bit (x86_64-w64-mingw32), Clang assumes as below;

+ +

+ +

This directory layout is standard for any toolchain you will find on the official MinGW-w64 website. + +

Clang expects the GCC executable "gcc.exe" compiled for i686-w64-mingw32 (or x86_64-w64-mingw32) to be present on PATH.

+ +

Some tests might fail +on x86_64-w64-mingw32.

+ +
+ + -- cgit v1.2.3