On Friday, 18 July 2014 at 19:02:48 UTC, Walter Bright wrote:
> 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.

But if the compiler can prove that the computation stays within the bounds or throws then there is no reason to not allow it. Since such optimizations can effect generics performance it would be nice to think about ways to help the compiler to establish the proof.

Even simple means such as annotating an int type with @assume_nowrap or @expect_wrapping etc.

On Thursday, 17 July 2014 at 11:56:24 UTC, David Nadlinger wrote:
> ---
> ; Function Attrs: nounwind readnone uwtable
> define i1 @_D4test3fooFiZb(i32 inreg %a_arg) #0 {
>   %tmp3 = icmp eq i32 %a_arg, 2147483647
>   ret i1 %tmp3
> }
> ---

Can't it simply generate code as is? Seems wasteful to spend compilation time on this.

On Saturday, 19 July 2014 at 08:34:39 UTC, Kagamin wrote:
> Can't it simply generate code as is? Seems wasteful to spend compilation time on this.

Not if you want fast code, consider a template with:

if (a.length+M < b.length+N) {}

then you alias b = a in the template instantiation:

if(a.length+M < a.length+N){}

you want this reduced to:

if (M<N){
}

which can be resolved at compile time.

On Saturday, 19 July 2014 at 19:49:24 UTC, Ola Fosheim Grøstad wrote:
> On Saturday, 19 July 2014 at 08:34:39 UTC, Kagamin wrote:
>> Can't it simply generate code as is? Seems wasteful to spend compilation time on this.
>
> Not if you want fast code, consider a template with:
>
> if (a.length+M < b.length+N) {}
>
> then you alias b = a in the template instantiation:
>
> if(a.length+M < a.length+N){}
>
> you want this reduced to:
>
> if (M<N){
> }
>
> which can be resolved at compile time.

Yes, but that is the optimizer's job. The front-end doesn't need to spend time on it, if the back-end then anyway does the same optimization again.

"Marc Schütz" <schuetzm@gmx.net> wrote:
> On Saturday, 19 July 2014 at 19:49:24 UTC, Ola Fosheim Grøstad wrote:
>> On Saturday, 19 July 2014 at 08:34:39 UTC, Kagamin wrote:
>>> Can't it simply generate code as is? Seems wasteful to spend >> compilation time on this.
>> 
>> Not if you want fast code, consider a template with:
>> 
>> if (a.length+M < b.length+N) {}
>> 
>> then you alias b = a in the template instantiation:
>> 
>> if(a.length+M < a.length+N){}
>> 
>> you want this reduced to:
>> 
>> if (M<N){
>> }
>> 
>> which can be resolved at compile time.
> 
> Yes, but that is the optimizer's job. The front-end doesn't need to spend time on it, if the back-end then anyway does the same optimization again.

I don't think anyone has said that the frontend does that.
But the language semantics forbid such optimizations if overflow is defined
as wrapping.
If the optimizer respects that is a different chapter, as the experiment
with GDC shows.

Tobi

On Sunday, 20 July 2014 at 11:09:45 UTC, Tobias Müller wrote:
> "Marc Schütz" <schuetzm@gmx.net> wrote:
>> On Saturday, 19 July 2014 at 19:49:24 UTC, Ola Fosheim Grøstad wrote:
>>> On Saturday, 19 July 2014 at 08:34:39 UTC, Kagamin wrote:
>>>> Can't it simply generate code as is? Seems wasteful to spend
>>>> >> compilation time on this.
>>> 
>>> Not if you want fast code, consider a template with:
>>> 
>>> if (a.length+M < b.length+N) {}
>>> 
>>> then you alias b = a in the template instantiation:
>>> 
>>> if(a.length+M < a.length+N){}
>>> 
>>> you want this reduced to:
>>> 
>>> if (M<N){
>>> }
>>> 
>>> which can be resolved at compile time.
>> 
>> Yes, but that is the optimizer's job. The front-end doesn't need to spend
>> time on it, if the back-end then anyway does the same optimization again.
>
> I don't think anyone has said that the frontend does that.

I do ;-) This is how I interpret Kagamin's post.

"Marc Schütz" <schuetzm@gmx.net> wrote:
> On Sunday, 20 July 2014 at 11:09:45 UTC, Tobias Müller wrote:
>> "Marc Schütz" <schuetzm@gmx.net> wrote:
>>> On Saturday, 19 July 2014 at 19:49:24 UTC, Ola Fosheim Grøstad >> wrote:
>>>> On Saturday, 19 July 2014 at 08:34:39 UTC, Kagamin wrote:
>>>>> Can't it simply generate code as is? Seems wasteful to spend
>>>>>>> compilation time on this.
>>>>>>> Not if you want fast code, consider a template with:
>>>>>>> if (a.length+M < b.length+N) {}
>>>>>>> then you alias b = a in the template instantiation:
>>>>>>> if(a.length+M < a.length+N){}
>>>>>>> you want this reduced to:
>>>>>>> if (M<N){
>>>> }
>>>>>>> which can be resolved at compile time.
>>>>> Yes, but that is the optimizer's job. The front-end doesn't >> need to spend
>>> time on it, if the back-end then anyway does the same >> optimization again.
>> 
>> I don't think anyone has said that the frontend does that.
> 
> I do ;-) This is how I interpret Kagamin's post.

Hm I interpreted it the other way round, it's wasteful to spend time for
such optimizations, just.
But my english is probably not as good as yours.

Tobi

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?

If you still feel ok today then dont read this:
-----------------
module meh;

import std.stdio;

//https://stackoverflow.com/questions/24676375/why-does-int-i-1024-1024-1024-1024-compile-without-error

static shared immutable int o = 1024 * 1024 * 1024 * 1024;

void main(string args[])
{
    writeln(o);
}
-------------------------------------------------------------

Basile Burg:

> If you still feel ok today then dont read this:
> -----------------
> module meh;
>
> import std.stdio;
>
> //https://stackoverflow.com/questions/24676375/why-does-int-i-1024-1024-1024-1024-compile-without-error
>
> static shared immutable int o = 1024 * 1024 * 1024 * 1024;
>
> void main(string args[])
> {
>     writeln(o);
> }
> -------------------------------------------------------------

See:
https://issues.dlang.org/show_bug.cgi?id=4835
https://github.com/D-Programming-Language/dmd/pull/1803

Bye,
bearophile

On 07/21/14 16:32, bearophile via Digitalmars-d wrote:
> https://github.com/D-Programming-Language/dmd/pull/1803

Disallowing integer overflow just at CT is not (sanely) possible
in a language with D's CTFE capabilities. (Would result in code
that compiles and works at runtime, but is not ctfe-able)

artur