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 http://clang.llvm.org/ and http://www.llvm.org/ 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