Re: Optimization techniques and undefined behavior

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


>> (** This is the above program auto-translated from C to one of my
>> languages, which is sort of interesting, this being a compiler group.
>>
>
> Sure, your language is absolutely on-topic here.


Don't forget this a compiler newsgroup not a C one, so examples of my
language are just as relevant as C.


'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.


    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.


> 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.




>> 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. My version is exactly the same
program, and is not buggy because this language doesn't make unsigned
overflow undefined behaviour.

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