Keil Logo

Selecting source language options

3.3 Selecting source language options

armclang provides different levels of support for different source language standards. Arm® Compiler infers the source language, for example C or C++, from the filename extension. You can use the -x and -std options to force Arm Compiler to compile for a specific source language and source language standard.

Note:

This topic includes descriptions of [ALPHA] and [COMMUNITY] features. See Support level definitions.

Source language

By default Arm Compiler treats files with .c extension as C source files. If you want to compile a .c file, for example file.c, as a C++ source file, use the -xc++ option:

armclang --target=aarch64-arm-none-eabi -march=armv8-a -xc++ file.c

By default Arm Compiler treats files with .cpp extension as C++ source files. If you want to compile a .cpp file, for example file.cpp, as a C source file, use the -xc option:

armclang --target=aarch64-arm-none-eabi -march=armv8-a -xc file.cpp

The -x option only applies to input files that follow it on the command line.

Source language standard

Arm Compiler supports Standard and GNU variants of source languages as shown in the following table.

Table 3-6 Source language variants

Standard C GNU C Standard C++ GNU C++
c90 gnu90 c++98 gnu++98
c99 gnu99 c++03 gnu++03
c11 [COMMUNITY] gnu11 [COMMUNITY] c++11 gnu++11
- - c++14 gnu++14
- - c++17 [COMMUNITY] gnu++17 [COMMUNITY]

The default language standard for C code is gnu11 [COMMUNITY]. The default language standard for C++ code is gnu++14. To specify a different source language standard, use the -std=name option.

Note:

Arm does not guarantee the compatibility of C++ compilation units compiled with different major or minor versions of Arm Compiler and linked into a single image. Therefore, Arm recommends that you always build your C++ code from source with a single version of the toolchain.

You can mix C++ with C code or C libraries.

Arm Compiler supports various language extensions, including GCC extensions, which you can use in your source code. The GCC extensions are only available when you specify one of the GCC C or C++ language variants. For more information on language extensions, see the Arm® C Language Extensions in Arm Compiler.

Because Arm Compiler uses the available language extensions by default, it does not adhere to the strict ISO standard. To compile to strict ISO standard for the source language, use the -Wpedantic option. This option generates warnings where the source code violates the ISO standard. Arm Compiler does not support strict adherence to C++98 or C++03.

If you do not use -Wpedantic, Arm Compiler uses the available language extensions without warning. However, where language variants produce different behavior, the behavior is that of the language variant that -std specifies.

Note:

Certain compiler optimizations can violate strict adherence to the ISO standard for the language. To identify when these violations happen, use the -Wpedantic option.

The following example shows the use of a variable length array, which is a C99 feature. In this example, the function declares an array i, with variable length n.

#include <stdlib.h>

void function(int n) {
    int i[n];
}

Arm Compiler does not warn when compiling the example for C99 with -Wpedantic:

armclang --target=aarch64-arm-none-eabi -march=armv8-a -c -std=c99 -Wpedantic file.c

Arm Compiler does warn about variable length arrays when compiling the example for C90 with -Wpedantic:

armclang --target=aarch64-arm-none-eabi -march=armv8-a -c -std=c90 -Wpedantic file.c

In this case, armclang gives the following warning:

file.c:4:8: warning: variable length arrays are a C99 feature [-Wvla-extension]
int i[n];
^
1 warning generated.

Exceptions to language standard support

Arm Compiler 6 with libc++ provides varying levels of support for different source language standards. The following table lists the exceptions to the support Arm Compiler provides for each language standard:

Table 3-7 Exceptions to the support for the language standards

Language standard Exceptions to the support for the language standard
All supported standard versions

For all supported standards, the libc++ library deviates from the standard library as follows:

  • For std::vector<bool>::const_reference, the standards require the const_reference type to be bool. However, in libc++ the const_reference type is an IMPLEMENTATION DEFINED, read-only bit reference class.
  • For std::bitset<N>, the standards require bool operator[](size_t pos) const; to return bool. However, in libc++ bool operator[](size_t pos) const; returns an IMPLEMENTATION DEFINED, read-only bit reference object.
C90 None. C90 is fully supported.
C99 Complex numbers are not supported.

C11 [COMMUNITY]

The base Clang component provides C11 language functionality. However, Arm has performed no independent testing of these features and therefore these features are [COMMUNITY] features. Use of C11 library features is unsupported.

C11 is the default language standard for C code. However, use of the new C11 language features is a community feature. Use the -std option to restrict the language standard if necessary. Use the -Wc11-extensions option to warn about any use of C11-specific features.

C++98
  • The C++98 standard is supported except:

    • Where the C++11 standard deviates from the C++98 standard. For example, where std::deque<T>::insert() returns an iterator, as required by the C++11 standard, but the C++98 standard requires it to return void. Information about how the C++11 standard deviates from the C++98 standard is available in Annex "C Compatibility" of the C++11 standard definition.
    • Where the libc++ library deviates from the C++98 standard library:

      • For std::raw_storage_iterator, the C++98 standard requires the raw_storage_iterator class template to be inherited from std::iterator<std::output_iterator_tag,void,void,void,void>. However, in libc++ the raw_storage_iterator class template is inherited from an instantiation of std::iterator with a different list of template arguments.
  • Support for -fno-exceptions is limited.
C++03
  • The C++03 standard is supported except:

    • Where the C++11 standard deviates from the C++03 standard. For example, where std::deque<T>::insert() returns an iterator, as required by the C++11 standard, but the C++03 standard requires it to return void. Information about how the C++11 standard deviates from the C++03 standard is available in Annex "C Compatibility" of the C++11 standard definition.
    • Where the libc++ library deviates from the C++03 standard library:

      • For std::raw_storage_iterator, the C++03 standard requires the raw_storage_iterator class template to be inherited from std::iterator<std::output_iterator_tag,void,void,void,void>. However, in libc++ the raw_storage_iterator class template is inherited from an instantiation of std::iterator with a different list of template arguments.
  • Support for -fno-exceptions is limited.
C++11
  • Concurrency constructs or other constructs that are enabled through the following standard library headers are [ALPHA] supported:

    • <thread>
    • <mutex>
    • <shared_mutex>
    • <condition_variable>
    • <future>
    • <chrono>
    • <atomic>
    • For more details, contact the Arm Support team.

  • The thread_local keyword is not supported.
C++14
  • Concurrency constructs or other constructs that are enabled through the following standard library headers are [ALPHA] supported:

    • <thread>
    • <mutex>
    • <shared_mutex>
    • <condition_variable>
    • <future>
    • <chrono>
    • <atomic>
    • For more details, contact the Arm Support team.

  • The thread_local keyword is not supported.

Note:

gnu++14 is the default language standard for C++ code.

C++17 [COMMUNITY]

The base Clang and libc++ components provide C++17 language functionality. However, Arm has performed no independent testing of these features and therefore these features are [COMMUNITY] features.

Additional information

See the Arm® Compiler Reference Guide for information about Arm-specific language extensions.

For more information about libc++ support, see Standard C++ library implementation definition, in the Arm® C and C++ Libraries and Floating-Point Support User Guide.

The Clang documentation provides additional information about language compatibility:

Arm® Compiler and undefined behavior

The C and C++ standards consider any code that uses non-portable, erroneous program or data constructs as undefined behavior. Arm provides no information or guarantees about the behavior of Arm Compiler when presented with a program that exhibits undefined behavior. That includes whether the compiler attempts to diagnose the undefined behavior.

Note:

The -fsanitize=undefined command-line option is a [COMMUNITY] feature.
Non-ConfidentialPDF file icon PDF version100748_0616_01_en
Copyright © 2016–2021 Arm Limited or its affiliates. All rights reserved. 
  Arm logo
Important information

This site uses cookies to store information on your computer. By continuing to use our site, you consent to our cookies.

Change Settings

Privacy Policy Update

Arm’s Privacy Policy has been updated. By continuing to use our site, you consent to Arm’s Privacy Policy. Please review our Privacy Policy to learn more about our collection, use and transfers
of your data.