On Fri, Jan 27, 2012 at 10:40 AM, David Brown <da...@westcontrol.com> wrote:
> 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?
Well, the implementation is simply a bit naiive in accepting all options
and not all code is prepared to handle functions which differ in optimization
options. For example inlining happily will inline a -fwrapv function into
a -fno-wrapv function and later assume the inlined copy does have -fno-wrapv
semantics. The safe implementation here would have been to disallow
any inlining between functions that have any optimize attribute/pragma,
but that of course would defeat most of its use.
That said, using the attribute for debugging might be of help, but I would
not rely on it in any way.
Richard.
> mvh.,
>
> David
>
>
