On 27/01/2012 10:02, Richard Guenther wrote:
On Thu, Jan 26, 2012 at 4:58 PM, David Brown<da...@westcontrol.com> wrote:
On 26/01/2012 12:53, Konstantin Vladimirov wrote:
Hi,
If I know what I am doing, and my code itself guarantees, that there
will be no overflows and UB here, can I switch off this signed char to
unsigned char expansion in favor of signed char to signed int
expansion?
The big question here is why you are using an unqualified "char" for
arithmetic in the first place. The signedness of plain "char" varies by
target (some default to signed, some to unsigned) and by compiler flags. If
you want to write code that uses signed chars, use "signed char". Or even
better, use<stdint.h> type "int8_t".
However, as has been pointed out, the problem is that signed arithmetic
doesn't wrap - it must be turned into unsigned arithmetic to make it safe.
An alternative is to tell gcc that signed arithmetic is 2's compliment and
wraps, by using the "-fwrapv" flag or "int8_t char sum_A_B(void)
__attribute__((optimize("wrapv")));" on the specific function.
Note that semantic changing optimize attributes do not work reliably.
Richard.
Is there any more information about that somewhere? Certainly I expect
there to be issues when trying to turn on and off options like
"-fshort-enums" or "-freg-struct-return" - just as you can expect
problems linking modules that have been compiled with different flags
like that. But others like "-fwrapv", "-fargument-alias", or
"-finstrument-functions" can logically be applied to a single function.
If there are problems with changing these (with attributes or
pragmas), then perhaps they should be disabled, or the potential
problems documented in the manual?
mvh.,
David
