GCC Undefined Behavior Sanitizer

[via Digitalmars-d]

On Friday, 17 October 2014 at 13:44:24 UTC, ketmar via 
Digitalmars-d wrote:
> On Fri, 17 Oct 2014 09:46:48 +0000
> via Digitalmars-d <digitalmars-d at puremagic.com> wrote:
>
>> It is just plain wrong to let integers wrap by default in an 
>> accessible result. That is not integer behaviour.
> do you know any widespread hardware with doesn't work this way?

Yes, the carry flag is set if you add with carry. It means you 
SHOULD add to another hi-word with carry.  :P

You can also add with clamp with SSE, so you clamp to max/min. 
Too bad languages don't support it. I've always thought it be 
nice to have clamp operators, so you can say x(+)y and have the 
result clamped to the max/min values. Useful for stuff like DSP 
on integers.

>> if (x < ((x+1)&0xffffffff)){…}
> perfect. nice and straightforward way to do overflow checks.

Uh, so you want slow? If you want this you should also check the 
overflow flag so that you can catch overflows and throw an 
exception.

But then you have a high level language. All high level languages 
should do this.

>> In D it is even worse since you are forced to use a fixed size 
>> modulo even for int, so you cannot do 32 bit arithmetic in a 
>> 64 bit register without getting extra modulo operations.
> why should i, as programmer, care? what i *really* care about is
> portable code. having size of base types not strictly defined 
> is not
> helping at all.

So you want to have lots of masking on your shiny new 64-bit 
register only CPU, because D is stuck on promoting to 32-bits by 
spec?

That's not portable, that is "portable".

>> So, "undefined behaviour" is not so bad
> yes, it's not bad, it's terrible. having "undefined behavior" in
> language is like saying "hey, we don't know what to do with 
> this, and

Nah, it is saying: if your code is wrong then you will get wrong 
results unless you turn on runtime checks.

What D is saying is: nothing is wrong even if you get something 
you never wanted to express, because we specify all operations to 
be boundless (circular) so that nothing can be wrong by 
definition (but your code will still crash and burn).

That also means that you cannot turn on runtime checks, since it 
is by definition valid. No way for the compiler to figure out if 
it is intentional or not.

>> D has locked itself to Pentium-style x86 behaviour.
> oops. 2's complement integer arithmetic is "pentium-style x86" 
> now... i
> bet x86_64 does everything in ternary, right? oh, and how about
> pre-pentium era?

The overhead for doing 64bit calculations is marginal. Locking 
yourself to 32bit is a bad idea.

> it is very easy. take current hardware, evaluate it's 
> popularity, do
> what most popular hardware does. that's it. i, for myself, 
> don't need
> a language for "future hardware", i need to work with what i 
> have now.

My first computer had no division or multiply and 8 bit registers 
and was insanely popular. It was inconceivable that I would 
afford anything more advanced in the next decade. In the next 5 
years I had two 16 bit computers, one with 16x RAM and GPU… and 
at a much lower price…

> if we'll have some drastic changes in the future... well, we 
> always can
> emulate old HW to work with old code, and rewrite that old code 
> for new
> HW.

The most work on a codebase is done after it ships.

Interesting things may happen on the hardware side in the next 
few years:

- You'll find info on the net where Intel has planned buffered 
transactional memory for around 2017.

- AMD is interested in CPU/GPU intergration/convergence

- Intel has a many core "co-processor"

- SIMD registers are getting wider and wider… 512 bits is a lot!

etc...