Re: Optimization techniques and undefined behavior

On 02/05/2019 19:59, Bart wrote:
> On 02/05/2019 16:27, David Brown wrote:
>> On 01/05/2019 13:40, Bart wrote:


> 'Of interest' was a source-to-source translator that removes unnecessary
> macros, typedefs, #ifs and #includes from C source code.
>
>> But if you want to translate your language to C, you need to translate
>> it to C - not to what you think C ought to be.
>
> Read again - the translation goes the other way.
>


OK, I got that wrong. When you are translating /from/ C, you can assume
any behaviour you like for things that are undefined behaviour.


I can't understand how you would see the removal of typedefs, macros,
etc., to be an advantage - it would make most C code harder to
understand. But if you find your tool useful, great.


>   Given that you want your
>> own language to have wrapping semantics on integer overflow (hey, it's
>> your language - you define it in a crazy way if you want),
>
> You mean, like most processors, most languages and even most C
> compilers? Then yeah it's crazy.
>


Yes, crazy for a language. I think it is hard to define "most
languages", but a great many either throw a run-time error or use
expanded range numbers - both of which are appropriate (though there is
a cost). Several, not just C, assume that overflow doesn't happen as it
is undefined behaviour. There are some languages that define it as
two's complement wrapping, and that's crazy.


I've explained before why /processors/ use two's complement wrapping -
it is not because it gives a useful answer.


>> What does not make sense, of course, is to run tests in C with undefined
>> behaviour and expect consistent or testable results.  That is just daft.
>
> That was sort of the point of my post - it's daft is for C to declare
> such code undefined behaviour, when the general consensus (see above) is
> that it can be perfectly well defined.
>


Proof by repeated assertion is not valid.


>
>>> The results match those of the non-gcc/non-clang C compilers (apart from
>>> speed which is poor).)
>>
>> Who cares?  The C code is buggy, so the results don't matter.
>
> The C is only buggy because C says so.


The C standards define the c language - if they say the C code is buggy,
the C code is buggy. I can't believe you need this explained.


> My version is exactly the same
> program, and is not buggy because this language doesn't make unsigned
> overflow undefined behaviour.


(I assume you meant "signed" here.)


You are welcome to have an extended C language that defines the
behaviour of signed overflow - and the code is not buggy in that
language. Some C compilers specifically give that guarantee too (such
as gcc with "-fwrapv"), and the code is not buggy for them. For other C
compilers that mostly do two's complement wrapping but don't document
it, and might behave differently when optimising some types of code,
it's a game of chance - that means the code is buggy.

Return to the comp.compilers page.
Search the comp.compilers archives again.