Print this page
Implement -fstrict-calling-conventions
Stock GCC is overly willing to violate the ABI when calling local functions,
such that it passes arguments in registers on i386.  This hampers debugging
with anything other than a fully-aware DWARF debugger, and is generally not
something we desire.
Implement a flag which disables this behaviour, enabled by default.  The flag is
global, though only effective on i386, to more easily allow its globalization
later which, given the odds, is likely to be necessary.


6569   int* ip;
6570   t.d = 3.0;
6571   ip = &t.i;
6572   return *ip;
6573 @}
6574 @end smallexample
6575 
6576 Similarly, access by taking the address, casting the resulting pointer
6577 and dereferencing the result has undefined behavior, even if the cast
6578 uses a union type, e.g.:
6579 @smallexample
6580 int f() @{
6581   double d = 3.0;
6582   return ((union a_union *) &d)->i;
6583 @}
6584 @end smallexample
6585 
6586 The @option{-fstrict-aliasing} option is enabled at levels
6587 @option{-O2}, @option{-O3}, @option{-Os}.
6588 






6589 @item -fstrict-overflow
6590 @opindex fstrict-overflow
6591 Allow the compiler to assume strict signed overflow rules, depending
6592 on the language being compiled.  For C (and C++) this means that
6593 overflow when doing arithmetic with signed numbers is undefined, which
6594 means that the compiler may assume that it will not happen.  This
6595 permits various optimizations.  For example, the compiler will assume
6596 that an expression like @code{i + 10 > i} will always be true for
6597 signed @code{i}.  This assumption is only valid if signed overflow is
6598 undefined, as the expression is false if @code{i + 10} overflows when
6599 using twos complement arithmetic.  When this option is in effect any
6600 attempt to determine whether an operation on signed numbers will
6601 overflow must be written carefully to not actually involve overflow.
6602 
6603 This option also allows the compiler to assume strict pointer
6604 semantics: given a pointer to an object, if adding an offset to that
6605 pointer does not produce a pointer to the same object, the addition is
6606 undefined.  This permits the compiler to conclude that @code{p + u >
6607 p} is always true for a pointer @code{p} and unsigned integer
6608 @code{u}.  This assumption is only valid because pointer wraparound is




6569   int* ip;
6570   t.d = 3.0;
6571   ip = &t.i;
6572   return *ip;
6573 @}
6574 @end smallexample
6575 
6576 Similarly, access by taking the address, casting the resulting pointer
6577 and dereferencing the result has undefined behavior, even if the cast
6578 uses a union type, e.g.:
6579 @smallexample
6580 int f() @{
6581   double d = 3.0;
6582   return ((union a_union *) &d)->i;
6583 @}
6584 @end smallexample
6585 
6586 The @option{-fstrict-aliasing} option is enabled at levels
6587 @option{-O2}, @option{-O3}, @option{-Os}.
6588 
6589 @item -fstrict-calling-conventions
6590 @opindex mstrict-calling-conventions
6591 Use strict ABI calling conventions even with local functions.
6592 This disable certain optimizations that may cause GCC to call local
6593 functions in a manner other than that described by the ABI.
6594 
6595 @item -fstrict-overflow
6596 @opindex fstrict-overflow
6597 Allow the compiler to assume strict signed overflow rules, depending
6598 on the language being compiled.  For C (and C++) this means that
6599 overflow when doing arithmetic with signed numbers is undefined, which
6600 means that the compiler may assume that it will not happen.  This
6601 permits various optimizations.  For example, the compiler will assume
6602 that an expression like @code{i + 10 > i} will always be true for
6603 signed @code{i}.  This assumption is only valid if signed overflow is
6604 undefined, as the expression is false if @code{i + 10} overflows when
6605 using twos complement arithmetic.  When this option is in effect any
6606 attempt to determine whether an operation on signed numbers will
6607 overflow must be written carefully to not actually involve overflow.
6608 
6609 This option also allows the compiler to assume strict pointer
6610 semantics: given a pointer to an object, if adding an offset to that
6611 pointer does not produce a pointer to the same object, the addition is
6612 undefined.  This permits the compiler to conclude that @code{p + u >
6613 p} is always true for a pointer @code{p} and unsigned integer
6614 @code{u}.  This assumption is only valid because pointer wraparound is