GCC Undefined Behavior Sanitizer

Fri Oct 17 08:17:00 PDT 2014

On Fri, 17 Oct 2014 14:38:29 +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
i was writing about 'if_carry_set'. yes, i really-really-really want
either "propagating carry" if 'if_carry_flag_set', or a way to tell the
compiler "do overflow check on this expression and throw exception on
overflow".

> 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.
it's good. but this not justifies the decision to make 2's complement
overflow undefined.

> >> 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.
i want a way to check integer overflows. i don't even want to think
about dirty C code to do that ('cause, eh, our compilers are very smart
and they, eh, know that there must be no overflows on ints, and they,
eh, just removing some checks 'cause that checks is no-ops when there
are no overflows, and now we, eh, have to cheat the compiler to...
screw it, i'm going home!)

> 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?
yes. what's wrong with using long/ulong when you need 64 bits? i don't
care about work CPU must perform to execute my code, CPU was created to
help me, not vice versa. yet i really care about 'int' being the same
size on different architectures (size_t, you sux! i want you to go
away!).

> That's not portable, that is "portable".
it's portable. and "portable" is when i should making life of some
silicon crap easier instead of silicon crap making my life easier.

> Nah, it is saying: if your code is wrong then you will get wrong 
> results unless you turn on runtime checks.
...and have a nice day, sucker!

> 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).
perfect!

> 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.
if you want such checks, you have a choice. you either can do such
checks manually or use something like CheckedInt. this way when i see
CheckedInt variable i know programmer's intentions from the start. and
if programmer using simple 'int' i know that compiler will not
"optimize away" some checking code.

> The overhead for doing 64bit calculations is marginal. Locking 
> yourself to 32bit is a bad idea.
did you noticed long/ulong types in D specs? and reserved 'cent' type
for that matter?

> 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…
that's why you don't use assembler to write your code now, aren't you?
i was trying to use C for Z80, and that wasn't a huge success that
days. why do you want to make my life harder by targeting D2 to some
imaginary "future hardware" instead of targetting to current one? by
the days when "future hardware" will become "current hardware" we will
have D5 or so. nobody using K&R C now, right?

> The most work on a codebase is done after it ships.
porting to another arch, for example. where... ah, FSCK, int is 29 bits
there! shit! or 16 bits... "portable by rewriting", yeah.

> 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.
(looking at 'date' output) ok, it's 2014 now. and i see no such HW
around. let's talk about this when we'll have widespreaded HW with this
feature.

> - AMD is interested in CPU/GPU intergration/convergence
and me not. but i'm glad for AMD.

> - Intel has a many core "co-processor"
and?..

> - SIMD registers are getting wider and wider… 512 bits is a lot!
and i must spend time to make some silicon crap happy, again? teach
compilers to transparently rewrite my code, i don't want to be a slave
to CPUs.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: not available
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20141017/8c038e8e/attachment-0001.sig>