Show: Delphi C++
Display Preferences

BCC64.EXE, the C++ 64-bit Windows Compiler

From RAD Studio XE3
Jump to: navigation, search

Go Up to Command Line Utilities Index

The C++ 64-bit Windows compiler (BCC64) is based on the open-source Clang compiler, which is the front end for the LLVM compiler, described at and respectively.

BCC64 is an entirely new code base, so there are significant differences between BCC64 and BCC32.

BCC64 Feature Description

Calling convention

MS x64 ABI

Name mangling

Itanium C++ 64-bit ABI (with some extensions)

See Intel® Itanium™ Process-specific Application Binary Interface (ABI)

Compiled object file

ELF64 format

Executable file



Project Options for BCC64 in the IDE

A subset of the features of Clang have been integrated into RAD Studio, and some of these are available on the C++ Compiler Project Options pages.

Differences between BCC64 (Clang-based) and BCC32

Here are some of the notable differences between BCC64 and BCC32:

  • BCC64 is also a preprocessor, when run with the -E switch. There is also a separate CPP64.EXE preprocessor.
  • BCC64 enforces template two-phase lookup. That is, names that are not tied to a dependent type are looked-up in the first phase (before instantiation) and might lead to errors that BCC32 did not report.
  • BCC64 allows a default argument only in a function declaration. BCC32 allowed default arguments in a function pointer or closure declaration as well.
  • BCC64 does not allow the use of sizeof in a preprocessor directive, such as #if sizeof(ATypeName) > 20.
  • BCC64 is stricter about conversions. For example, converting string constants to char* generates a warning (conversion from string literal to char * is deprecated). On the other hand, initializing a char* with an unsigned char* results in a plain error (Cannot initialize a variable of type 'char *' with an rvalue of type BYTE *, also known as unsigned char *).
  • BCC64 does not allow you to mix __try with catch: this is because catch must be used with try; and __try must be used with __except and/or __finally.
  • Unicode identifiers are not supported by BCC64.
  • CPP32 supports the -Hp option and prints header guard information that is used by the PCH Wizard.
  • CPP32's default is not Unix style #line, and so forth.
  • The final (C++), deprecated and noreturn C++0x attributes are not supported by the 64-bit Windows C++ compiler. See Workaround for C++0x attributes for a workaround in BCC64.
  • Many BCC32 options are not supported by BCC64, and vice versa; see Options Not Supported by BCC64

For more information, see C++Builder 64-bit Windows Differences.

Clang compiler options

clang: -fcommon     Do not put uninitialized globals in the common section
clang: -fverbose-asm
clang: -fvisibility=hidden     (does not affect "extern"s)
clang: -combine     Pass multiple source files to compiler at once
clang: -fdata-sections     Place data items into their own section
ld: --warn-common     Warn about duplicate common symbols
ld: --warn-unresolved-symbols     Report unresolved symbols as warnings
ld: --error-unresolved-symbols     Report unresolved symbols as errors

Note: Using BCC64 on the command line can have unexpected results. However, the BCC64 compiler options that are available in the IDE have been tested during implementation. For more information, see:

For anyone who calls BCC64 at the command line, we recommend going through the driver, as follows:

   bcc64 -c  test.cpp


  bcc64 -tWCV myVCLConsoleApp.cpp

In this case, BCC64 runs with -fborland-extensions enabled by default.

If you are an experienced user of Clang and you want to use BCC64 without going through the driver, you should pass -cc1 as the first option, telling BCC64 that you are taking matters in your hands and want to have total/strict control on all options. In this case, no option is automatically injected for you, and you would need to specify -fborland-extensions.

How BCC32 options translate to BCC64 options

See Project Options Supported by BCC64.

Common Issues when Compiling a BCC32 Project in BCC64

You are likely to encounter new errors due to the ANSI-compliant strictness of BCC64.

For more information, see:

Support for Precompiled Headers

BCC64 supports the use of one precompiled header, named by default <project><n>PCH.h.

For further information, see Using Precompiled Headers in 64-bit Windows C++ Applications.

To illustrate one basic difference between BCC32 and BCC64, here are two MAKE-like snippets:

# BCC32 Build
source1.obj: source1.cpp source1.h
  BCC32 -c -H projectPCH.pch source1.cpp
source2.obj: source2.cpp source2.h
  BCC32 -c -H projectPCH.pch source2.cpp
# BCC64 Build
projectPCH.pch: projectPCH.h
  BCC64 -emit-pch -o projectPCH.pch projectPCH.h
source1.obj: projectPCH.pch source1.cpp source1.h
  BCC64 -emit-obj -include-pch projectPCH.pch source1.cpp
source2.obj: projectPCH.pch source2.cpp source2.h
  BCC64 -emit-obj -include-pch projectPCH.pch source2.cpp

The key idea is that there is a specific target for building the project's precompiled header.

Command-Line Help for BCC64

To display command-line help, append the --help option:

C:> bcc64 --help

The following help is displayed:

OVERVIEW: bcc64 driver
USAGE: bcc64 [options] <inputs>
 -###                    Print the commands to run for this compilation
 --analyze               Run the static analyzer
 --help                  Display available options
 --migrate               Run the migrator
 --relocatable-pch       Build a relocatable precompiled header
 --serialize-diagnostics <value>
                         Serialize compiler diagnostics to a file
 -E                      Only run the preprocessor
 -ObjC++                 Treat source input files as Objective-C++ inputs
 -ObjC                   Treat source input files as Objective-C inputs
 -Qunused-arguments      Don't emit warning for unused driver arguments
 -S                      Only run preprocess and compilation steps
 -Wa,<arg>               Pass the comma separated arguments in <arg> to the assembler
 -Wl,<arg>               Pass the comma separated arguments in <arg> to the linker
 -Wp,<arg>               Pass the comma separated arguments in <arg> to the preprocessor
 -Xanalyzer <arg>        Pass <arg> to the static analyzer
 -Xassembler <arg>       Pass <arg> to the assembler
 -Xclang <arg>           Pass <arg> to the clang compiler
 -Xlinker <arg>          Pass <arg> to the linker
 -Xpreprocessor <arg>    Pass <arg> to the preprocessor
                         Emit ARC errors even if the migrator can fix them
 -arcmt-migrate-report-output <value>
                         Output path for the plist report
 -c                      Only run preprocess, compile, and assemble steps
 -emit-ast               Emit Clang AST files for source inputs
 -emit-llvm              Use the LLVM representation for assembler and object files
                         Generate runtime checks for undefined behavior.
 -flimit-debug-info      Limit debug information produced to reduce size of debug binary
 -fno-limit-debug-info   Do not limit debug information produced to reduce size of debug binary
 -ftrap-function=<value> Issue call to specified function rather than a trap instruction
 -gcc-toolchain <value>  Use the gcc toolchain at the given directory
 -n <directory>          Specify the output directory for intermediate files
                         Enable migration to modern ObjC literals
                         Enable migration to modern ObjC subscripting
 -o <file>               Write output to <file>
 -pipe                   Use pipes between commands, when possible
 -print-file-name=<file> Print the full library path of <file>
 -print-libgcc-file-name Print the library path for "libgcc.a"
 -print-prog-name=<name> Print the full program path of <name>
 -print-search-dirs      Print the paths used for finding libraries and programs
 -rewrite-legacy-objc    Rewrite Legacy Objective-C source to C++
 -rewrite-objc           Rewrite Objective-C source to C++
 -save-temps             Save intermediate compilation results
 -target <value>         Generate code for the given target
 -time                   Time individual commands
 -t<value>               Specify Borland target executable
 -verify                 Verify output using a verifier.
 -v                      Show commands to run and use verbose output
 -working-directory <value>
                         Resolve file paths relative to the specified directory
 -x <language>           Treat subsequent input files as having type <language>


See Also

Personal tools
Previous Versions
In other languages