C/C++ Programmer's Guide (G06.27+, H06.08+, J06.03+)

boundaries, optimization level 1 is useful when you are developing and debugging your
program.
◦ Optimization level 2 provides both intrastatement and interstatement optimizations.
Interstatement optimizations can affect statement boundaries, which, in turn, can make
debugging a program more difficult. Consequently, you should use optimization level 2
only after your program is thoroughly debugged and tested.
• The OPTIMIZE pragma affects native C and C++ programs:
Optimization level 0 disables all optimizations and therefore yields code with relatively
poor performance. Optimization level 0 is useful when you are developing and debugging
◦
your program and is recommended for serious debugging. Statements are well-defined
when debugging; breakpoints and stepping occurs in a manner that the user would expect
when viewing the related source.
◦ Optimization level 1 generates optimized code sequences. Object code compiled at
optimization level 1 can be symbolically debugged; statement boundaries, however,
might be blurred. The Inspect, Native Inspect, and Visual Inspect debuggers choose a
sensible location when a user requests a breakpoint on a source statement, but their
definition of statement boundaries does not always coincide directly with source statements.
The debugger emits a warning when a process is held at a statement for which the code
associated with a previous source statement has not yet executed.
◦ Optimization level 2 generates the most optimized code sequences. Object code compiled
at optimization level 2 cannot be symbolically debugged with a symbolic debugger.
Machine-level debugging might be necessary.
For information on setting TNS/R code optimization levels, see the TNS/R Native Application
Migration Guide. For information on setting TNS/E code optimization levels, see the H-Series
Application Migration Guide. See also OPTFILE (page 224).
OVERFLOW_TRAPS
The OVERFLOW_TRAPS pragma determines whether the native C and C++ compilers generate
code with arithmetic overflow traps. The compiler generates code that traps (issues a signal) on
arithmetic overflow if OVERFLOW_TRAPS is set. The compiler does not generate code that traps
on arithmetic overflow if NOOVERFLOW_TRAPS is set.
[ NO ]OVERFLOW_TRAPS
Usage Guidelines
• The OVERFLOW_TRAPS pragma can be entered on the compiler RUN command line or in the
source text. It can also be specified with the -Woverflow_traps flag of the c89 or the c99
utility.
• Multiple pragmas can be placed in the source code to turn on and off the generation of code
that traps on arithmetic overflow.
• The OVERFLOW_TRAPS pragma in C mimics the overflow trapping code in pTAL and the
trapping behavior of the TNS C compiler. Code that traps on integer overflow is generated
only for signed arithmetic operations. Unsigned arithmetic operations always truncate.
Therefore, if your code uses only unsigned arithmetic operations, the code does not trap on
integer overflow.
• For more details on arithmetic overflow and signals, see the Guardian Programmer’s Guide
226 Compiler Pragmas