On 07/23/14 09:16, Don via Digitalmars-d wrote:
On Monday, 21 July 2014 at 21:10:43 UTC, Artur Skawina via Digitalmars-d
wrote:
Actually, C/C++ could get away with treating overflow during constant
folding as an error (or at least emitting a warning) because of the
lack of CTFE (and no
On Tuesday, 22 July 2014 at 21:06:09 UTC, Artur Skawina via
Digitalmars-d wrote:
D is defined as it is, with wrapping two's complement integer
arithmetic
and defined integer sizes.
Integer promotion is locked to 32 bits. That is a mistake. Why
wrap everything below 32bit at 32 on a 64 bit
On Monday, 21 July 2014 at 21:10:43 UTC, Artur Skawina via
Digitalmars-d wrote:
On 07/21/14 21:53, via Digitalmars-d wrote:
On Monday, 21 July 2014 at 19:33:32 UTC, Artur Skawina via
Digitalmars-d wrote:
Disallowing integer overflow just at CT is not (sanely)
possible
in a language with D's
On 7/21/2014 11:15 PM, Iain Buclaw via Digitalmars-d wrote:
CTFE is allowed to do things at an arbitrary precision in mid-flight when
evaluating an expression.
For floating point, yes. Not for integral arithmetic.
On 7/21/2014 2:10 PM, Artur Skawina via Digitalmars-d wrote:
Actually, C/C++ could get away with treating overflow during constant
folding as an error (or at least emitting a warning) because of the
lack of CTFE (and no templates in C's case). The code will either
compile or it won't.
For D that
On Tuesday, 22 July 2014 at 15:31:22 UTC, Ola Fosheim Grøstad
wrote:
On Tuesday, 22 July 2014 at 11:40:08 UTC, Artur Skawina via
Digitalmars-d wrote:
obey the exact same rules as RT. Would you really like to use
a language
in which 'enum x = (a+b)/2;' and 'immutable x = (a+b)/2;'
results in
On Tuesday, 22 July 2014 at 15:31:22 UTC, Ola Fosheim Grøstad
wrote:
A system level language should encourage using the fastest
opcode, so you shouldn't enforce 32 bit masking when the
fastest register size is 64 bit etc.
This is what int_fast32_t is for, but unfortunately it's not
On 7/23/2014 12:49 AM, Don wrote:
On Tuesday, 22 July 2014 at 15:31:22 UTC, Ola Fosheim Grøstad wrote:
D claims to focus generic programming. So it should also encourage pure
functions that can be specified for floats, ints and other numeric types that
are subtypes of (true) reals in the same
On Wednesday, 23 July 2014 at 07:49:28 UTC, Don wrote:
I think it's a complete fantasy to think you can write generic
code that will work for both floats and ints. The algorithms
are completely different.
Not really a valid line of reasoning.
Bool uints ints fixed point floats interval
On 21 Jul 2014 22:10, Artur Skawina via Digitalmars-d
digitalmars-d@puremagic.com wrote:
On 07/21/14 21:53, via Digitalmars-d wrote:
On Monday, 21 July 2014 at 19:33:32 UTC, Artur Skawina via
Digitalmars-d wrote:
Disallowing integer overflow just at CT is not (sanely) possible
in a
On 07/22/14 05:12, via Digitalmars-d wrote:
On Monday, 21 July 2014 at 21:10:43 UTC, Artur Skawina via Digitalmars-d
wrote:
For D that is not possible -- if an expression is valid at run-time
then it should be valid at compile-time (and obviously yield the same
value). Making this aspect
On 07/22/14 08:15, Iain Buclaw via Digitalmars-d wrote:
On 21 Jul 2014 22:10, Artur Skawina via Digitalmars-d
digitalmars-d@puremagic.com mailto:digitalmars-d@puremagic.com wrote:
For D that is not possible -- if an expression is valid at run-time
then it should be valid at compile-time (and
On Tuesday, 22 July 2014 at 11:40:08 UTC, Artur Skawina via
Digitalmars-d wrote:
obey the exact same rules as RT. Would you really like to use a
language
in which 'enum x = (a+b)/2;' and 'immutable x = (a+b)/2;'
results in
different values?...
With the exception of hash-functions the result
On 22 July 2014 12:40, Artur Skawina via Digitalmars-d
digitalmars-d@puremagic.com wrote:
On 07/22/14 08:15, Iain Buclaw via Digitalmars-d wrote:
On 21 Jul 2014 22:10, Artur Skawina via Digitalmars-d
digitalmars-d@puremagic.com mailto:digitalmars-d@puremagic.com wrote:
For D that is not
On 07/22/14 17:31, via Digitalmars-d wrote:
On Tuesday, 22 July 2014 at 11:40:08 UTC, Artur Skawina via Digitalmars-d
wrote:
obey the exact same rules as RT. Would you really like to use a language
in which 'enum x = (a+b)/2;' and 'immutable x = (a+b)/2;' results in
different values?...
On 07/22/14 18:39, Iain Buclaw via Digitalmars-d wrote:
On 22 July 2014 12:40, Artur Skawina via Digitalmars-d
digitalmars-d@puremagic.com wrote:
On 07/22/14 08:15, Iain Buclaw via Digitalmars-d wrote:
On 21 Jul 2014 22:10, Artur Skawina via Digitalmars-d
digitalmars-d@puremagic.com
On Sunday, 20 July 2014 at 11:09:45 UTC, Tobias Müller wrote:
Marc Schütz schue...@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
Marc Schütz schue...@gmx.net wrote:
On Sunday, 20 July 2014 at 11:09:45 UTC, Tobias Müller wrote:
Marc Schütz schue...@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
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
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
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
On Monday, 21 July 2014 at 19:33:32 UTC, Artur Skawina via
Digitalmars-d wrote:
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)
I'd like to see compile
On 07/21/14 21:53, via Digitalmars-d wrote:
On Monday, 21 July 2014 at 19:33:32 UTC, Artur Skawina via Digitalmars-d
wrote:
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
On Monday, 21 July 2014 at 14:32:38 UTC, bearophile wrote:
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
On Monday, 21 July 2014 at 21:10:43 UTC, Artur Skawina via
Digitalmars-d wrote:
For D that is not possible -- if an expression is valid at
run-time
then it should be valid at compile-time (and obviously yield
the same
value). Making this aspect of CT evaluation special would make
CTFE
much
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
Marc Schütz schue...@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
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
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:
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
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
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
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
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
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
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
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,
On Friday, 18 May 2012 at 20:01:15 UTC, Paul D. Anderson wrote:
On Friday, 18 May 2012 at 19:59:01 UTC, Paul D. Anderson wrote:
On Sunday, 6 May 2012 at 16:27:34 UTC, Alex Rønne Petersen
wrote:
On 05-05-2012 06:57, Alex Rønne Petersen wrote:
Hi,
I don't think the language really makes it
Bumping this as we still need to make a decision about this. As
recently as yesterday, someone on the GCC mailing list posted a
complaint about an optimization pass that assumed undefined
semantics for overflow. We need to have a stance about this,
since GDC is going into mainline GCC soon.
On 18-05-2012 15:26, akaz wrote:
Bumping this as we still need to make a decision about this. As
recently as yesterday, someone on the GCC mailing list posted a
complaint about an optimization pass that assumed undefined semantics
for overflow. We need to have a stance about this, since GDC is
I agree that throwing an exception could be a good feature to
have, but it should *not* be the default. I want my systems
code to run at full speed when I know what I'm doing.
In the release version, yes. In the release version, array bound
checking is disabled, too.
But in the debug
On 18-05-2012 19:28, akaz wrote:
I agree that throwing an exception could be a good feature to have,
but it should *not* be the default. I want my systems code to run at
full speed when I know what I'm doing.
In the release version, yes. In the release version, array bound
checking is
On Fri, May 18, 2012 at 6:26 AM, akaz n...@utopia.com wrote:
Bumping this as we still need to make a decision about this. As recently
as yesterday, someone on the GCC mailing list posted a complaint about an
optimization pass that assumed undefined semantics for overflow. We need to
have a
On Friday, 18 May 2012 at 19:59:01 UTC, Paul D. Anderson wrote:
On Sunday, 6 May 2012 at 16:27:34 UTC, Alex Rønne Petersen
wrote:
On 05-05-2012 06:57, Alex Rønne Petersen wrote:
Hi,
I don't think the language really makes it clear whether
overflows and
underflows are well-defined. Do we
On Sunday, 6 May 2012 at 16:27:34 UTC, Alex Rønne Petersen wrote:
On 05-05-2012 06:57, Alex Rønne Petersen wrote:
Hi,
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
On 05-05-2012 06:57, Alex Rønne Petersen wrote:
Hi,
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?
This is relevant in particular for GDC and LDC since
On 05/05/12 06:57, Alex Rønne Petersen wrote:
Hi,
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?
This is relevant in particular for GDC and LDC since
On 07-05-2012 10:05, Don Clugston wrote:
On 05/05/12 06:57, Alex Rønne Petersen wrote:
Hi,
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?
This is
On 05-05-2012 06:57, Alex Rønne Petersen wrote:
Hi,
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?
This is relevant in particular for GDC and LDC since
On Saturday, 5 May 2012 at 05:32:14 UTC, Era Scarecrow wrote:
Any systems that implement a carry flag likely works exactly
like that.
Yes, but that misses the actual problem!
The problem isn't the _system_, it's the _compiler_.
If the language says overflow or underflow are undefined
On Sunday, 6 May 2012 at 16:39:02 UTC, Mehrdad wrote:
Yes, but that misses the actual problem!
The problem isn't the _system_, it's the _compiler_.
If the language says overflow or underflow are undefined
behavior, then what the system does _doesn't matter one bit_,
because the compiler can
On 05-05-2012 07:32, Era Scarecrow wrote:
On Saturday, 5 May 2012 at 04:57:48 UTC, Alex Rønne Petersen wrote:
Hi,
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
On Saturday, 5 May 2012 at 07:10:28 UTC, Alex Rønne Petersen
wrote:
Right, but the question was whether the language guarantees
what I described. C and C++ don't, and IMO, we should strive to
fix that.
I can't see why it wouldn't, unless the compiler adds in checks
and changes it's
On 05-05-2012 10:23, Era Scarecrow wrote:
On Saturday, 5 May 2012 at 07:10:28 UTC, Alex Rønne Petersen wrote:
Right, but the question was whether the language guarantees what I
described. C and C++ don't, and IMO, we should strive to fix that.
I can't see why it wouldn't, unless the compiler
On 5 May 2012 11:42, Alex Rønne Petersen xtzgzo...@gmail.com wrote:
On 05-05-2012 10:23, Era Scarecrow wrote:
On Saturday, 5 May 2012 at 07:10:28 UTC, Alex Rønne Petersen wrote:
Right, but the question was whether the language guarantees what I
described. C and C++ don't, and IMO, we
On 05-05-2012 12:25, Manu wrote:
On 5 May 2012 11:42, Alex Rønne Petersen xtzgzo...@gmail.com
mailto:xtzgzo...@gmail.com wrote:
On 05-05-2012 10 tel:05-05-2012%2010:23, Era Scarecrow wrote:
On Saturday, 5 May 2012 at 07:10:28 UTC, Alex Rønne Petersen wrote:
Right, but
Alex Rønne Petersen:
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?
This is relevant in particular for GDC and LDC since they
target a lot of weird
On 05-05-2012 13:06, bearophile wrote:
Alex Rønne Petersen:
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?
This is relevant in particular for GDC and
Hi,
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?
This is relevant in particular for GDC and LDC since they target a lot
of weird architectures.
On Saturday, 5 May 2012 at 04:57:48 UTC, Alex Rønne Petersen
wrote:
Hi,
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?
This is relevant in
63 matches
Mail list logo
