why GCC does implicit promotion to unsigned char?

[David Brown]

On 27/01/2012 10:02, Richard Guenther wrote:
> On Thu, Jan 26, 2012 at 4:58 PM, David Brown<david@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