Found through Reddit. A nice incomplete list that specifies a "friendly C" that replaces many occurrences of "X has undefined behavior" with "X results in an unspecified value":

http://blog.regehr.org/archives/1180

But I agree with one comment:

>memcpy and memmove ought to remain distinct, but I think that an overlapping memcpy ought to result in unspecified garbage being written rather than undefined behavior.<

Bye,
bearophile

This prohibits diagnostic of integer overflow. The runtime is no longer allowed to throw exception in such case.

Though good as an additional dialect.

On Thursday, 28 August 2014 at 07:36:28 UTC, bearophile wrote:
> Found through Reddit. A nice incomplete list that specifies a "friendly C" that replaces many occurrences of "X has undefined behavior" with "X results in an unspecified value":
>
> http://blog.regehr.org/archives/1180
>
> But I agree with one comment:
>
>>memcpy and memmove ought to remain distinct, but I think that an overlapping memcpy ought to result in unspecified garbage being written rather than undefined behavior.<
>
> Bye,
> bearophile

It forces all the load to potentially have side effects, which, in turn, limit dramatically what the optimizer can do.

On Thu, 28 Aug 2014 09:12:15 +0000
deadalnix via Digitalmars-d <digitalmars-d@puremagic.com> wrote:

> It forces all the load to potentially have side effects, which, in turn, limit dramatically what the optimizer can do.
but there is alot code that doesn't need "super-speed". it's ok to fallback to "standard C" for the parts that need all speed we can have w/o assembly. but most programs are ok with not-so-extensive optimizations, and writing code in "friendly c" is much easier than in "standard c".

i myself compiling all my C code with -fwrapv -fno-strict-aliasing -fno-delete-null-pointer-checks. i believe that compiler was made to make my life easier, not to make it harder. so it's the compiler who should obey my orders, not vice versa. ;-)

On Thu, 28 Aug 2014 09:12:15 +0000
deadalnix via Digitalmars-d <digitalmars-d@puremagic.com> wrote:

p.s. code generated by DMD, for example, at least two times slower than code generated by GDC. but most people are ok with it.

On Friday, 29 August 2014 at 02:10:55 UTC, ketmar via Digitalmars-d wrote:
> On Thu, 28 Aug 2014 09:12:15 +0000
> deadalnix via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
>
>> It forces all the load to potentially have side effects, which, in turn, limit dramatically what the optimizer can do.
> but there is alot code that doesn't need "super-speed". it's ok to
> fallback to "standard C" for the parts that need all speed we can have
> w/o assembly. but most programs are ok with not-so-extensive
> optimizations, and writing code in "friendly c" is much easier than in
> "standard c".
>
> i myself compiling all my C code with -fwrapv -fno-strict-aliasing
> -fno-delete-null-pointer-checks. i believe that compiler was made to
> make my life easier, not to make it harder. so it's the compiler who
> should obey my orders, not vice versa. ;-)

It is not only about null checks.

If the value in unspecified, rather than the behavior undefined, it means that no load or store can be optimized away or reordered, unless the compiler can prove that is won't fault.

I'm talking about doubtful optimization to gain 0.5% here, but that everything single variable except locals must be considered volatile in the C sense.

On Friday, 29 August 2014 at 05:31:02 UTC, deadalnix wrote:
> If the value in unspecified, rather than the behavior undefined, it means that no load or store can be optimized away or reordered, unless the compiler can prove that is won't fault.
>
> I'm talking about doubtful optimization to gain 0.5% here, but that everything single variable except locals must be considered volatile in the C sense.

Why is that? If the value is unspecified then you can assume a random value, so no single store is needed unless explicitly volatile?

Wrapping semantics is also bad for optimization, though. You cannot reduce length < length+N to true in generic code, so you need to establish bounds on x or create multiple execution paths. This is usually silly when using a 64 bit int...

On Fri, 29 Aug 2014 05:31:00 +0000
deadalnix via Digitalmars-d <digitalmars-d@puremagic.com> wrote:

> If the value in unspecified, rather than the behavior undefined, it means that no load or store can be optimized away or reordered, unless the compiler can prove that is won't fault.
will it really hurt most programs? compiler is still be able to remove
unused assignments, dead code and so on. and turning `while (v) {}` to
`while (true) {}` too, btw, so no, not 'volatile'.

and i can't see why it should prevent load reordering too. what it actually forbids is throwing away overflow checks like 'if (a+100 < a)' -- the same effect as '-fwrapv'.

aliasing sux too: only a small fraction of code gains something from optimisations based on aliasing rules, yet that rules pushed down the throat for everyone.

those who need speed will be able to use 'C with UB' (and chase mysterious bugs) and majority of people will get much nicer C language to write their code.

current C is anti-human.

On Thursday, 28 August 2014 at 09:12:17 UTC, deadalnix wrote:
> It forces all the load to potentially have side effects, which, in turn, limit dramatically what the optimizer can do.

Why? I could be true in case of unspecified behavior, but not in case of unspecified value.