This was asked a few years ago and i could find a definitive answer.

http://forum.dlang.org/thread/jo2c0a$31hh$1@digitalmars.com

On Saturday, 5 May 2012 at 04:57:48 UTC, Alex Rønne Petersen wrote:
> I don't think the language really makes it clear whether overflows and underflows are well-defined. Do we guarantee that for any integral type T, T.max + 1 == T.min and T.min - 1 == T.max?

What is the current situation of integer overflow and underflow?

On 7/16/2014 2:26 PM, Gary Willoughby wrote:
> What is the current situation of integer overflow and underflow?

https://github.com/D-Programming-Language/druntime/pull/839

On 07/17/2014 12:18 AM, Walter Bright wrote:
> On 7/16/2014 2:26 PM, Gary Willoughby wrote:
>> What is the current situation of integer overflow and underflow?
>
> https://github.com/D-Programming-Language/druntime/pull/839

(His question was whether there is wrap-around behaviour for signed types, which I think does not have a good answer at the moment.)

On Wednesday, 16 July 2014 at 21:26:41 UTC, Gary Willoughby wrote:
> This was asked a few years ago and i could find a definitive answer.
>
> http://forum.dlang.org/thread/jo2c0a$31hh$1@digitalmars.com
>
> On Saturday, 5 May 2012 at 04:57:48 UTC, Alex Rønne Petersen wrote:
>> I don't think the language really makes it clear whether overflows and underflows are well-defined. Do we guarantee that for any integral type T, T.max + 1 == T.min and T.min - 1 == T.max?
>
> What is the current situation of integer overflow and underflow?

My understanding:

Every machine D will feasibly support will do T.max + 1 == T.min and T.min - 1 == T.max for native integral operations, signed or unsigned.

BUT:

We are using C(++) backends, which may assumed an undefined result for signed over/underflow. Optimisers could cause us pain here.

BUT:

It's probably not taken advantage of due to the amount of C code that assumes the expected semantics. Also, there may be ways of telling backends that it is defined and we may be using those ways, I don't know.

On Thursday, 17 July 2014 at 08:50:12 UTC, John Colvin wrote:
> Every machine D will feasibly support will do T.max + 1 == T.min and T.min - 1 == T.max for native integral operations, signed or unsigned.

In fact, the spec mandates this (see AddExpression): "If both operands are of integral types and an overflow or underflow occurs in the computation, wrapping will happen."

> It's probably not taken advantage of due to the amount of C code that assumes the expected semantics. Also, there may be ways of telling backends that it is defined and we may be using those ways, I don't know.

Oh dear, you'd be in for a very nasty surprise if you relied on this. ;)

Compiling the following code as C++ using Clang
---
bool foo(int a) {
  return a > (a + 1);
}
---
yields
---
; Function Attrs: nounwind readnone uwtable
define zeroext i1 @_Z3fooi(i32 %a) #0 {
  ret i1 false
}
---
That is, the optimizer completely gets rid of the check, as the overflow would be undefined behavior and thus cannot happen!

On the other hand, compiling it using LDC yields
---
; Function Attrs: nounwind readnone uwtable
define i1 @_D4test3fooFiZb(i32 inreg %a_arg) #0 {
  %tmp3 = icmp eq i32 %a_arg, 2147483647
  ret i1 %tmp3
}
---
just as it should. In other words, your suspicion that LLVM might offer a way to toggle whether overflow is defined is true, and LDC uses the correct variant of the arithmetic instructions.

GDC seems to be broken in that regard, though: http://bugzilla.gdcproject.org/show_bug.cgi?id=141

Cheers,
David

On Thursday, 17 July 2014 at 08:50:12 UTC, John Colvin wrote:
> there may be ways of telling backends that it is defined and we may be using those ways, I don't know.

For GDC, it's the '-fwrapv' switch, but it's not enabled by default for D.

artur

Artur Skawina:

> For GDC, it's the '-fwrapv' switch, but it's not enabled by default for D.

I think it has to be enabled by default, plus you can add a switch to disable that standard D semantics.

Bye,
bearophile

On 7/17/2014 4:56 AM, David Nadlinger wrote:
> Oh dear, you'd be in for a very nasty surprise if you relied on this. ;)

When I wrote that part of the spec, it was long before these sorts of optimizations appeared, and it never occurred to me that they would be.

On Friday, 18 July 2014 at 08:49:43 UTC, Walter Bright wrote:
> On 7/17/2014 4:56 AM, David Nadlinger wrote:
>> Oh dear, you'd be in for a very nasty surprise if you relied on this. ;)
>
> When I wrote that part of the spec, it was long before these sorts of optimizations appeared, and it never occurred to me that they would be.

Does the dmd backend do any such optimisations? I assume not.

On 7/18/2014 1:59 AM, John Colvin wrote:
> On Friday, 18 July 2014 at 08:49:43 UTC, Walter Bright wrote:
>> On 7/17/2014 4:56 AM, David Nadlinger wrote:
>>> Oh dear, you'd be in for a very nasty surprise if you relied on this. ;)
>>
>> When I wrote that part of the spec, it was long before these sorts of
>> optimizations appeared, and it never occurred to me that they would be.
>
> Does the dmd backend do any such optimisations? I assume not.

No, it doesn't, and I don't intend to add them. I believe they cause more trouble than they're worth. That applies to some other optimizations I've also refused to implement, because while legal, they mess up code that most users believe is correct.