9.5.2. Configuring the compilers

This section describes how to configure compiler options that are common to each of the ARM compilers:

Note

Many of the configuration settings described here are optional. However, you should review at least the Target options, ATPCS options, and Debug table generation options to ensure that they are suitable for your project.

Each compiler has its own configuration panel consisting of a number of tabbed panes. The panels are listed in the Target Settings Panels list (see Figure 9.20 for an example) when you select the ARM linker or the ARM librarian as the linker in the Target Settings panel. See Configuring target settings for more information on selecting the linker in the Target Settings panel.

The configuration options are described in:

These sections give general descriptions of the available compiler options. Where applicable, you are referred to more detailed descriptions in the C and C++ Compiler chapters of the ADS Compilers and Libraries Guide.

Configuring the target and source

To configure the target processor and architecture for the ARM compilers:

  1. Display the Target Settings window for the build target you want to configure (see Displaying Target Settings panels).

  2. Depending on the compiler you are using, click the appropriate entry in the Target Settings Panels list and click the Target and Source tab to display the configuration panel (Figure 9.20).

    Figure 9.20. ARM compiler Target and Source panel

    ARM compiler Target and Source panel
  3. Select values for the following options:

    Architecture or Processor

    Select an architecture or processor for your target hardware from the drop-down list. The drop-down list contains menu items for all current product names and architectures. If you select:

    • an architecture, for example 4T, your code is compiled to run on any processor that implements that architecture

    • a processor, the compiler compiles code that is optimized for that processor.

    Some processor selections imply a floating-point selection. For example, with the ARM compilers ARM10200E implies VFPv2 format and instruction. The implied option is overridden if you specify an explicit floating point option. If no processor or floating-point options are specified, Pure-endian softfp is used.

    Floating Point

    Select the floating-point system you are using. Valid values are:

    FPA format and instructions

    Select this option if you are targeting a system with a hardware Floating Point Architecture unit. This option is not available for the Thumb compilers.

    VFPv1 format and instructions

    Select this option to target hardware vector floating-point unit conforming to architecture VFPv1, such as the ARM10200™ rev 0. This option is not available for the Thumb compilers.

    VFPv2 format and instructions

    Select this option to target hardware vector floating-point unit conforming to architecture VFPv2, such as the ARM10200E. This option is not available for the Thumb compilers.

    Old-style mixed-endian softfp

    Select this option to use the software floating-point library and your source code uses FPA-format double-precision floating-point representations.

    Pure-endian softfp

    Select this option to use the software floating-point library with pure-endian doubles. This option specifies that your code uses VFP format double-precision floating-point representations, but does not use any floating-point coprocessor instructions. This is the default.

    VFP with softvfp calling standard

    Selects software floating-point library with pure-endian doubles, software floating-point linkage, and requiring a VFP unit. Select this option if you are interworking Thumb code with ARM code on a system that implements a VFP unit.

    If you select this option the compiler behaves exactly as for Pure-endian softfp except that it links with VFP-optimized floating-point libraries.

    Note

    If this option is specified for both armcc and tcc, it ensures that your interworking floating-point code is compiled to use software floating-point linkage. If you select VFPv1 format and instructions, or VFPv2 format and instructions for armcc you must use the __softfp keyword to ensure that your interworking ARM code is compiled to use software floating-point linkage. See the description of __softfp in the ADS Compilers and Libraries Guide for more information.

    No floating point

    Select this option if you are neither targeting a hardware floating-point unit, nor the software floating-point library.

    Byte Order

    Select the byte order used by your target hardware.

    Source Language

    Select the source language you require from the drop-down list. See the compiler chapters of the ADS Compilers and Libraries Guide for detailed information on C and C++ standards conformance and implementation details. Valid options for both C and C++ compilers are:

    ANSI/ISO Standard C

    Select this option to compile fairly strict ANSI standard C, with some characteristics removed, and some minor extensions, such as accepting C++ style comments (//), and accepting $ characters in identifiers.

    Strict ANSI/ISO Standard C

    Select this option to enforce stricter adherence to the ANSI standard.

    The ARM C++ compilers provide the following additional options:

    ISO/IEC Standard C++

    Select this option to compile standard ISO/IEC C++ with minor extensions.

    Strict ISO/IEC Standard C++

    Select this option to enforce stricter adherence to the ISO/IEC standard. For example, the following code gives an error when this option is selected, and a warning when compiled with the standard ISO/IEC option:

    static struct T {int i;};
    

    The static declaration is spurious because no object is declared. In strict C++ it is illegal.

    Embedded C++

    Select this option to compile C++ that closely conforms to the industry standard for embedded C++. Embedded C++ is a subset of standard C++ that is designed to encourage efficient code for use in embedded systems. The Embedded C++ standard is evolving. The proposed definition can be found on the web at http://www.caravan.net/ec2plus.

  4. Click Apply to apply your changes.

Configuring compiler ATPCS options

Selecting ATPCS options instructs the compiler to generate code that conforms to the appropriate ATPCS variant. In general, you must ensure that you use compatible calling standard options when you are compiling objects or libraries that you expect to link together.

Note

Routines that are entered from exception vectors do not necessarily need the same settings as the rest of your project code. For example, software stack checking should be avoided in FIQ handlers in order to maximize the speed of the handler.

In addition, if you are calling routines written in ARM assembly language you must ensure that your assembly language code conforms to the appropriate ATPCS variant, and that the assembler is configured with the appropriate ATPCS options. See Configuring assembler ATPCS options for details. See also the ATPCS chapter in the ADS Developer Guide for more information.

To configure the ARM and Thumb procedure call standard options for the ARM compilers:

  1. Display the Target Settings window for the build target you want to configure (see Displaying Target Settings panels).

  2. Depending on the compiler you are using, click the appropriate entry in the Target Settings Panels list and click the ATPCS tab to display the configuration panel (Figure 9.21).

    Figure 9.21. ARM compiler ATPCS panel

    ARM compiler ATPCS panel
  3. Select the ATPCS variant options that you require:

    ARM/Thumb interworking

    Select this option if you are writing ARM code that you want to interwork with Thumb code, or Thumb code that you want to interwork with ARM code. Only functions called from the other state need to be compiled for interworking. The linker generates suitable interworking veneers when the compiler output is linked. See the description of Interworking in the ADS Developer Guide for more information.

    Software stack check

    Select this option if you are writing code that performs stack checking in software. This option slows down performance, but can be useful in identifying errors that are hard to find. See the section on the callgraph option in Configuring linker options for information on calculating static stack size.

    Read-only position independent

    Select this option if you are compiling code that you want to be position-independent. If this option is selected, the compiler:

    • addresses read-only entities (code and data) pc-relative

    • sets the PI attribute on read-only output sections.

    Note

    The ARM tools cannot determine if the final output image will be Read-Only Position-Independent until the linker finishes processing input sections. This means that the linker might emit ROPI error messages, even though you have selected this option.

    Read-write position independent

    Select this option to ensure that output data sections in your compiled code are addressed position-independently. If this option is selected, the compiler:

    • Addresses writable data using offsets from the static base (sb). This means that:

      • data addresses can be fixed at run time

      • data can be multiply instanced

      • data can be, but does not have to be, position-independent.

    • Sets the PI attribute on read-write output sections.

    Note

    The compiler does not force your writable data to be position-independent. This means that the linker might emit RWPI messages, even though you have selected this option.

  4. Click Apply to apply your changes.

Configuring warnings

The compiler issues warning messages to warn about portability problems or other potential problems in your code. You can use the Warnings tab to configure the C and C++ compilers to suppress or enable specific warnings.

To configure warnings given by the ARM compilers:

  1. Display the Target Settings window for the build target you want to configure (see Displaying Target Settings panels).

  2. Depending on the compiler you are using, click the appropriate entry in the Target Settings Panels list and click the Warnings tab to display the configuration panel (Figure 9.22).

    Figure 9.22. ARM compiler Warnings panel

    ARM compiler Warnings panel
  3. Select warning options that apply to both C and C++, as required:

    No warnings

    Select this option to turn off all warnings.

    Warn for all conditions

    Select this option to turn on all warnings, including those that are disabled by default.

    Assignment in condition

    Select this option to enable the warning:

    C2961W: use of “=” in condition context

    This warning is issued when the compiler finds a statement such as:

    if (a = b) {...
    

    where it is possible that one of the following is intended:

    if ((a = b) != 0) {... 
    
    if (a == b) {...
    
    ANSI C extensions

    Select this option to enable warning messages that are issued when extensions to the ANSI standard are used implicitly. Examples include:

    • using an unwidened type in an ANSI C assignment

    • specifying bitfields with a type of char, short, long, or long long

    • specifying char, short, float, or enum, arguments to variadic functions such as va_start().

    Header file not guarded

    Select this option to enable the warning given when an unguarded header file is #included. An unguarded header file is one that is not wrapped in a declaration such as:

    #ifndef foo_h
    #define foo_h
    /* body of include file */
    #endif
    
    Unused declaration

    Select this option to enable not used warnings such as:


    C2870W: variable 'y' declared but not used.

    Warning are given for:

    • local (within a function) declarations of variables, typedefs, and functions

    • labels (always within a function)

    • top-level static functions and static variables.

    Non-ANSI header

    Select this option to enable the warning message:

    C2812W: Non-ANSI #include <…>

    The ANSI C standard requires that you use #include <…> for ANSI C headers only. However, it is useful to disable this warning when compiling code that does not conform to this aspect of the standard. These warnings are suppressed by default unless you have selected a strict source language option in the Target and Source panel (see Configuring the target and source).

    Padding inserted in struct

    Select this option to enable warnings given when the compiler inserts padding in a struct.

    For example:


    C2221W: padding inserted in struct 's'

    C to C++ incompatibility

    For C code, select this option to enable warnings about future compatibility with C++. Warnings are suppressed by default. For example:

    int *new(void *p) {  return p; }
    

    results in the following warnings:


    C2204W: C++ keyword used as identifier: 'new'
    C2920W: implicit cast from (void *), C++ forbids

    Lower precision in wider context

    Select this option to enable the warning message:

    Lower precision in wider context

    that is given when code like the following is found:

    long x; int y, z; x = y*z
    

    where the multiplication yields an int result that is then widened to long. This warning indicates a potential problem when either the destination is long long, or when the target system defines 16-bit integers or 64-bit longs.

    Implicit narrowing

    Select this option to enable the Implicit narrowing cast warning message.

    This warning is issued when the compiler detects the implicit narrowing of a long expression in an int or char context, or the implicit narrowing of a floating-point expression in an integer or narrower floating-point context.

    Implicit narrowing casts such as these almost always cause problems when you move code that has been developed on a fully 32-bit system to a system in which integers occupy 16 bits and longs occupy 32 bits.

    Double to float

    Select this option to disable the warning:


    C2621W: double constant automatically converted to float

    This warning is given when the default type of unqualified floating-point constants is changed by the Narrow double constants to float constants option. This warning is switched on by default.

  4. Select warning options specific to C++, if required:

    Member and base inits out of order

    Select this option to enable warnings given when base and member initializations are out of order. For example:

    struct T { T(int); int i, j; };T::T(int x) : j(x), i(j*3) { }
    

    The base and member initializations are done in declaration order (virtual bases are done first) no matter what the order specified in the definition of the constructor. In this case i is initialized before j and so j*3 gives an undefined value.

    Unused this in non-static member function

    Select this option to enable the unused this warning. This warning is issued when the implicit this argument is not used in a non-static member function. It is applicable to C++ only. The warning can also be avoided by making the member function a static member function. The default is off. For example:

    struct T {
            int f() { return 42; }
    };
    

    results in the following warning:


    C2924W: 'this' unused in non-static member function

    To avoid the warning, use static int f() ...

    Implicit virtual

    Select this option to enable the implicit virtual warning that is given when a non-virtual member function of a derived class hides a virtual member of a parent class. For example:

    struct Base { virtual void f(); };
    struct Derived : Base { void f(); };	
    					// warning 'implicit virtual'
    


    C2997W: 'Derived::f()' inherits implicit virtual from 'Base::f()'

    Adding the virtual keyword in the derived class prevents the warning.

    Implicit constructor

    Select this option to enable the implicit constructor warning that is given when the code requires a constructor to be invoked implicitly. For example:

    struct X { X(int); };
    X x = 10;				// actually means, X x = X(10);
    				// See the Annotated C++ 
    				// Reference Manual p.272
    
  5. Click Apply to apply your changes.

Configuring errors

The compiler issues error messages to indicate serious problems in the code it is attempting to compile.

The options described below enable you to:

  • turn specific recoverable errors off

  • downgrade specific errors to warnings.

Caution

These options force the compiler to accept C and C++ source that normally produces errors. If you use any of these options to ignore error messages, it means that your source code does not conform to the appropriate C or C++ standard.

These options might be useful when importing code from other environments. However, they might allow the compiler to produce code that does not function correctly. It is generally better to correct the code than to use options to switch off error messages.

To configure error messages issued by the ARM compilers:

  1. Display the Target Settings window for the build target you want to configure (see Displaying Target Settings panels).

  2. Depending on the compiler you are using, click the appropriate entry in the Target Settings Panels list and click the Errors tab to display the configuration panel (Figure 9.23).

    Figure 9.23. ARM compiler Errors panel

    ARM compiler Errors panel
  3. Select error options that apply to both C and C++, if required:

    Note

    By default, all the following options are selected. Deselect an option to instruct the compiler to suppress or downgrade the error message.

    Implicit pointer casts

    Deselect this option to suppress all implicit cast error messages, such as the error message generated by casting a nonzero int to pointer. No warning message is given.

    Other dubious casts

    Deselect this option to downgrade error messages for illegal casts, such as those generated by casting pointer to short, to warnings.

    Junk at end of #endif/#else/#undef

    Deselect this option to suppress error messages generated as the result of extra characters at the end of a preprocessor line. No warning message is given.

    Zero-length arrays

    Deselect this option to suppress error messages arising from zero-length arrays. No warning message is given.

    Linkage conflicts

    Deselect this option to suppress error messages about linkage disagreements where functions are implicitly declared as extern and then later redefined as static. No warning message is given.

  4. Select error options that apply only to C++, as required:

    Access control violations

    Deselect this option to downgrade access control errors to warnings. For example:

    class A { void f() {}; };							// private member
    A a;
    void g() { a.f(); } 							// erroneous access
    
    Implicit ‘int’ types

    Deselect this option to downgrade error messages produced by constructs such as:

    const i;
    //missing type specification for 'i' - 'int' assumed
    

    to warnings.

  5. Click Apply to apply your changes.

Configuring debug and optimization

Use the Debug/Opt panel to set debug controls, and optimization levels and criteria for the compiler. The optimization selections you make affect the quality of the debug view of your code.

To configure optimization and debug options for the compilers:

  1. Display the Target Settings window for the build target you want to configure (see Displaying Target Settings panels).

  2. Depending on the compiler you are using, click the appropriate entry in the Target Settings Panels list and click the Debug/Opt tab to display the configuration panel (Figure 9.24).

    Figure 9.24. ARM compiler Debug and optimization panel

    ARM compiler Debug and optimization panel
  3. Select Debug control options:

    Enable debug table generation

    Select this option to instruct the compiler to generate DWARF2 debug tables. This option enables you to debug your output images at the source level. If this option is not selected, only limited debugging is available.

    Include preprocessor symbols

    Select this option to include preprocessor symbols in the compiler output.

    Enable debug of inline functions

    Select this option to instruct the compiler to compile inline qualified functions out of line so that they can be debugged at source more easily.

  4. Select the level of optimization you want:

    Minimum

    Select this option to disable all compiler optimizations. Use this option in combination with enabled debug table generation to generate the best possible debug view of your output image.

    Most

    Select this option to disable compiler optimizations that impact seriously on the debug view. Use this option in combination with enabled debug table generation to generate code that provides a good compromise between optimization and debug.

    All

    Select this option to enable all compiler optimizations. This option results in a poor debug view of your output image due to code movement and register re-use. You can use this option with debug table generation turned off, or by linking with debug data discarded, to generate the most efficient code possible, after you have finished debugging.

  5. Select the optimization criterion:

    For space

    Select this option to favor small code size over execution speed. This is the default.

    For time

    Select this option to favor execution speed over code size.

  6. Click Apply to apply your changes.

Configuring the preprocessor

Use the Preprocessor panel to configure preprocessor macros, and to set search path options. To add, replace, or delete a preprocessor macro for the ARM compilers:

  1. Display the Target Settings window for the build target you want to configure (see Displaying Target Settings panels).

  2. Depending on the compiler you are using, click the appropriate entry in the Target Settings Panels list and click the Preprocessor tab to display the configuration panel (Figure 9.25). The panel displays a list of all predefined macros.

    Figure 9.25. ARM compiler Preprocessor panel

    ARM compiler Preprocessor panel
  3. Double-click on a preprocessor macro definition in the List of #DEFINEs field to modify the definition. If you want to add a new definition, double-click on any existing definition. The name of the macro is displayed in the text field below the list.

  4. Edit the value of the macro definition as appropriate. If you want to create a new macro, type over the existing macro name. Specify the value of the macro with an equals sign. For example:

    EXAMPLE_DEFINE=2
    

    If you do not enter a value, the value defaults to 1.

  5. Click Add to add a new macro definition, or click Replace to edit the value of an existing macro definition.

    Caution

    Do not replace the macro definitions predefined by ARM.

  6. Click Apply to apply your changes.

Configuring code generation

To configure code generation options for the ARM compilers:

  1. Display the Target Settings window for the build target you want to configure (see Displaying Target Settings panels).

  2. Depending on the compiler you are using, click the appropriate entry in the Target Settings Panels list and click the Code Gen tab to display the configuration panel (Figure 9.26).

    Figure 9.26. ARM Compiler Code Gen panel

    ARM Compiler Code Gen panel
  3. Select Code Generation options:

    Enum container always int

    Select this option to force all enumerations to be stored in integers. By default, the compiler uses the smallest data type that can hold all values in an enum.

    Note

    This option is not recommended for general use and is not required for ANSI-compatible source. If used incorrectly, this option can cause errors in the resulting image.

    Plain char is signed

    Select this option to make the char type signed. It is normally unsigned in C++ and ANSI C modes.

    Note

    This option is not recommended for general use and is not required for ANSI-compatible source. If used incorrectly, this option can cause errors in the resulting image.

    Split load and store multiple

    Select this option to instruct the compiler to split LDM and STM instructions into two or more LDM or STM instructions, where required, to reduce the maximum number of registers transferred to:

    • five, for all STMs, and for LDMs that do not load the PC

    • four, for LDMs that load the PC.

    This option can reduce interrupt latency on ARM systems that:

    • do not have a cache or a write buffer (for example, a cacheless ARM7TDMI)

    • use zero-wait-state, 32-bit memory.

    Note

    Using this option increases code size and decreases performance slightly.

    This option does not split ARM inline assembly LDM or STM instructions, or VFP FLDM or FSTM instructions, but does split Thumb LDM and STM inline assembly instructions where possible.

    This option has no significant benefit for cached systems, or for processors with a write buffer.

    This option also has no benefit for systems with non-zero-wait-state memory, or for systems with slow peripheral devices. Interrupt latency in such systems is determined by the number of cycles required for the slowest memory or peripheral access. This is typically much greater than the latency introduced by multiple register transfers.

    Narrow double constants to float constants

    Select this option to change the type of unsuffixed floating-point constants from double (as specified by the ANSI/ISO C and C++ standards) to unspecified. In this context, unspecified means that uncast double constants and double constant expressions are treated as float when used in expressions with values other than double. This can sometimes improve the execution speed of a program.

    Compile-time evaluation of constant expressions that contain such constants is unchanged. The compiler uses double-precision calculations, but the unspecified type is preserved. For example:

    (1.0 + 1.0) // evaluates to the floating-point 
                // constant 2.0 of double precision and
                // unspecified type.
    

    In a binary expression that must be evaluated at run-time (including expressions that use the ?: operator), a constant of unspecified type is converted to float, instead of double. The compiler issues the following warning:


    C2621W: double constant automatically converted to float

    You can avoid this warning by explicitly suffixing floating-point constants that you want to be treated as float. You can turn this warning off with the -Wk compiler option.

    Note

    This behavior is not in accordance with the ANSI C standard.

    If the other operand in the expression has type double, a constant of unspecified type is converted to double. A cast of a constant of unspecified type to type T produces a constant of type T.

    For example:


    float f1(float x) { return x + 1.0; }         // Uses float add and is treated the same
                                                  // as f2() below, a warning is issued.
    float f2(float x) { return x + 1.0f;}         // Uses float add with no warning, with or
                                                  // without -auto_float_constants.
    float f3(double x) { return x + 1.0; }        // Uses double add, no special treatment.
    float f4(float x) { return x + (double)1.0;}  // Uses double add, no special treatment.

    One ELF section per function

    Select this option to generate one ELF section for each function in a source file. This option enables the linker to remove unused functions. This option increases code size slightly for some functions, but when creating code for a library, it can prevent unused functions being included at the link stage. This can result in the reduction of the final image size.

  4. Click Apply to apply your changes.

Note

If you want to configure the compiler to generate assembler files instead of object files, add -S to the equivalent command line box. The CodeWarrior IDE creates a .s file when the project is compiled, invokes armasm, and attempts to assemble the .s file. With -S alone, this assemble step succeeds, because the output from -S is a source file that can be assembled. However, with -S -fs, the link step fails, because a .txt file is created. It is recommended that you use the new compiler option, -asm -fs, as an alternative to -S -fs.

Reading compiler options from a file

A via file is a text file that contains additional command-line arguments to the compiler. Via files are read when the compiler is invoked. The via file options are processed after the options specified in the configuration panels, and override them if there is a conflict. You can use via files to ensure that the same compiler settings are used by different build targets and projects. See the ADS Compilers and Libraries Guide for a description of via file syntax.

To specify a via file:

  1. Display the Target Settings window for the build target you want to configure (see Displaying Target Settings panels).

  2. Depending on the compiler you are using, click the appropriate entry in the Target Settings Panels list and click the Extras tab to display the configuration panel (Figure 9.27).

    Figure 9.27. ARM Compiler Extras panel

    ARM Compiler Extras panel
  3. Enter the path name of the via file you want to use, or click Choose… and select the via file from the standard file dialog box.

  4. Click Apply to apply your changes.

Copyright © 1999-2001 ARM Limited. All rights reserved.ARM DUI 0065D
Non-Confidential