BCC64X

From RAD Studio
Jump to: navigation, search

Go Up to Clang-enhanced C++ Compilers


BCC64X is a RAD Studio C++ compiler for 64-bit Windows (Modern).

BCC64X is based on Clang. For more information about what the BCC64X compiler has in common with other Clang-enhanced C++ compilers, see Clang-enhanced C++ Compilers.

Note: For 32-bit Windows, use BCC32C (Clang-enhanced compiler) or BCC32 (previous-generation compiler).

General Information

Field Value
Clang Version 15.0
LLVM Version 15.0
Calling Conventions Microsoft x64
Name Mangling Itanium
Standard Library LLVM libc++
C++ Runtime Custom based on MinGW-LLVM
C Runtime UCRT

Output Files

File Type File Extension File Format
Executable .exe PE64 (PE32+)
Shared Library .dll PE64 (PE32+)
Static Library .lib library of object files
Compiled Object .o COFF64
Debug Information .pdb PDB
Note: The new clang supports linking packages statically and dynamically. You can link these files to your EXE or DLLs.

Writing C++ Code for BCC64X

To write C++ code specifically for BCC64X, use: 

#if defined(__BORLANDC__) && defined(_WIN64) && defined(__MINGW64__)

To focus on a specific release, add a check as follows:

#if __clang_major__ == 15
  #pragma message("Using version 15 of Clang")
#endif


For more information, see Clang-enhanced C++ Compilers, Predefined Macros.

Toolchain

The Windows 64-bit Modern C++ toolchain (bcc64x) is an entirely new implementation of the Clang extensions and C++Builder features with new platform-standard technology. With the LLD linker, new RTL, and more, the new Clang toolchain is our recommended C++ toolchain.

It uses the LLVM libc++ STL, a custom C++ RTL, the Windows UCRT for the C runtime, and emits object files in COFF64 format with PDB debug info.

To add this toolchain to your existing C++ project, perform the following steps:

  1. Right-click the Target Platforms node in the Projects treeview.
  2. Select Add Platform.
  3. Choose Windows 64-bit (Modern).
Note: You can toggle between the old and new Win64 platforms easily because both are installed and can be added to a project side by side, allowing easy upgrading.

How to test for the new BCC64X compiler

RAD Studio has a recommended way for developers to write code that detects if the new toolchain is being used:

  • Recommended: Use a macro test for _CODEGEARC_ and _clang_major_ >= 15 for this and newer versions. RAD Studio recommends this because the Clang version will change over time, and this code will be true for this toolchain's current and future versions. This is almost certainly the check you want to add to your code.
  • Use a macro test _CODEGEARC_ and _clang_major_ == 15 for this specific version. Only use this to test the initial version of the toolchain specifically. This test will fail to detect future versions of the same toolchain, which is why the previous test is recommended.
Note: Learn more on how to detect LLVM and its version here.
  • Use the _has_feature and _has_builtin macros to test for specific C++ or compiler/LLVM features and builtins, which are not C++Builder specific but apply to multiple Clang-based toolchains. Learn more about feature-checking macros here.


The code sample below demonstrates our recommended test for the new toolchain. Use this to wrap toolchain-specific code, such as including specific headers. 

#include <iostream>
#include <tchar.h>

int _tmain(int argc, _TCHAR* argv[])
{
      #if defined(__CODEGEARC__) && (__clang_major__ >= 15)
           std::cout << "C++Builder Modern Compiler, 12.1 or newer";
      #else
           std::cout << "A different compiler";
      #endif
}

To migrate your existing codebase forward, including specific code for the new toolchain inside such a macro is useful.

Note: See a complete list of macros in our Predefined Macros page.

Adjusting Paths

To ensure the compiler finds the correct paths, make sure to add the $(CC_SUFFIX) variable to the library path.

For example: 

$(BDSLIB)\$(PLATFORM)$(CC_SUFFIX)\debug;..\..\..\..\..\Public\Documents\Embarcadero\Studio\15.0\Samples\CPP\Mobile Samples\User Interface\KeyboardToolbar\

The $CC_SUFFIX variable is used to handle the difference in the two Win64 toolchains. The new one, bcc64x, has an X on the end, meaning the correct platform location for files it links to is ‘win64x’. The $CC_SUFFIX evaluates to X when using this platform.

Testing for Windows vs. Testing for a Specific Toolchain

When using third-party C++ source code, you may see headers, method definitions, etc., that are Windows-specific and incorrectly wrapped in a macro testing the toolchain (usually MSVC.) To solve this, replace those macros with a platform test, not a toolchain test.

To test for Windows, whether MSVC, C++Builder, or another toolchain, test for _WIN32 or _WIN64 being defined. Both C++Builder and MSVC define these macros. This is recommended when your code is Windows-specific.

Code mixing platform (Windows) tests with toolchain tests seem to be decreasing on Windows due to the growing use of other toolchains such as RAD Studio's and mingw-llvm. However, it's still a common issue when pulling in third-party C++ source code or libraries.

Creating DLL Import Libraries

RAD Studio now allows you to link a .dll directly, eliminating the need for an import library. This new implementation is only for Win64x platforms.

However, the import library is commonly used to import a .dll file because the linker will look for libraries first, in opposition to .dll files that are searched last.

The toolchain supports any existing COFF library; however, you can create your own.

To create your own import library (.lib) file, follow the steps below:

  1. Get the definition (.def) file for the DLL.
    Note: You can generate the .def file from a .dll file by using our tdump tool.
  2. With the tdump tool, run the following command to create the .def file:
    tdump -def mydll.dll mydll.def
    Note: A .def file is plain text, open the file and ensure it contains LIBRARY <dllname>.dll with the correct <dllname>.
  3. Use the new LLD linker to generate the import library by running the following command in the RAD Studio Command Prompt:
    ld.lld.exe -m i386pep --out-implib file.lib file.def

The IDE automatically creates your DLL import library when building, but you can also do this manually by running any of the following codes in the command line: 

bcc64x -tD -Xlinker --out-implib=dll.lib dll.cpp

or 

bcc64x -tD dll.cpp -Wl,--out-implib,dll.lib

--jobs

RAD Studio has a new implementation for--jobswhich allows compilation to speed up the build process.

This leads to a faster building with bcc64x using--jobscompared to building with:

  • --jobs using the old bcc64 (old Win64 toolchain).
  • CMake & Ninja, using both the old and new bcc64/x.
  • Visual C++, both with CMake and Ninja and the /MP command line switch.

Understanding --jobs, compiler output, and CPU utilization

Below you can find some information that will help you understand how--jobsworks, so you can fine-tune your build environments to achieve faster, more efficient compilation while balancing resource utilization.

Compiler output

Compiler messages are not interleaved. Although they run in parallel, an entire file’s output messages will be printed at once, after it completes.

If there is a compile error, all compiling will be terminated. After the error, you might get successful compile messages because the other compiles will continue until completion.

Build systems

--jobsis implemented using the CC1 options. It is not available from the driver options. This means it can be used from the IDE and command-line MSBuild but not directly via the command-line ‘bcc64x’. So, to take advantage of this, you need to build via a .cbproj in some form. Note that you can absolutely use this for CI, builds servers, and more, when you build via a command-line MSBuild command.

What is CC1 vs driver options?

Roughly speaking, bcc64x is the compiler driver, a frontend that provides what was originally intended for the Clang project, which was to be gcc-like command line options. Clang has its own internal representation of compiler options, CC1.

When the IDE and MSBuild invoke the compiler, they do so via CC1 options, which are different from those you see on the command line.

For more information on this topic please review the following pages:

CPU Saturation

In the {{Project Options > Project Properties > General}} tab look for the Number of subprocesses setting, the default is ‘0’. This means using all cores available. It runs twice as many threads as there are cores.

If you want the build system to take almost but not quite all resources available, set it to -1. This uses one core less than the default, ‘0’. Only use this if you want to do something while compiling and find that other processes slow down.

You can also set it to any positive integer. Depending on how many are available, it will use up to this number of cores.

Our recommended value is 0 (the default.) This saturates the CPU and builds as fast as possible.

Known Issues

Components from packages created for WIN64X using DPROJ cannot be placed in VCL form while in “Modern Win64” mode. Also, components must be enabled for the platform first. To enable components for the Windows 64-bit (Modern) platform, follow the steps below:

  1. Open the Delphi .dproj project in the IDE.
  2. Ensure the Windows 64-bit (Modern) platform is activated for the project.
  3. Delete the project’s .res file.
  4. Rebuild the 32-bit package and reinstall it in the IDE.
Note: The issue only happens for existing projects. Newly created projects are not affected.

For more information, see ComponentPlatformsAttribute.

See Also

Retrieved from "https://docwiki.embarcadero.com/RADStudio/Athens/e/index.php?title=BCC64X&oldid=277596"