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

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	PE+/PE32+

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:

• Project Options Supported by BCC64
• Options Not Supported by BCC64

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

   bcc64 -c  test.cpp

or:

  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:

• BCC64 Errors and Warnings
• Stricter C++ Compiler (BCC64)

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>
OPTIONS:
 -###                    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
 -arcmt-migrate-emit-errors
                         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
 -fcatch-undefined-behavior
                         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
 -objcmt-migrate-literals
                         Enable migration to modern ObjC literals
 -objcmt-migrate-subscripting
                         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>

C:\>

See Also

• BCC64 Errors and Warnings
• What's New in C++Builder 64-Bit Windows
• C++Builder 64-bit Windows Application Development
  • C++Builder 64-bit Windows Differences
  • Stricter C++ Compiler (BCC64)
  • Upgrading Existing C++ Projects to 64-bit Windows
  • Debugging C++Builder 64-Bit Windows Applications
• C++11 Features (BCC64)
• Project Options Supported by BCC64
• Options Not Supported by BCC64
• Using Precompiled Headers in 64-bit Windows C++ Applications
• Precompiled Headers Command Line Options for BCC64
• Linking a C++ 64-bit Windows Hello World Application
• CPP64, the Preprocessor for 64-bit Windows
• 64-bit Windows "Hello World" Cross-Platform Application (Delphi and C++)
• MKEXP.EXE, the 64-bit Windows Import Library Tool for C++
• BCCOSX.EXE, the C++ Cross Compiler for OS X
• BCC32.EXE, the C++ 32-bit Command-Line Compiler
• http://clang.llvm.org/
  • http://llvm.org/demo/
  • http://channel9.msdn.com/Events/GoingNative/GoingNative-2012/Clang-Defending-C-from-Murphy-s-Million-Monkeys
  • http://devimages.apple.com/llvm/videos/ExtendingClang.m4v
  • http://llvm.org/devmtg/2011-11/Gregor_ExtendingClang.pdf
  • http://llvm.org/docs/Passes.html)