• Koz Ross (21/21) Sep 18 2014 I don't know if this is the right place to ask, but I figured it
• deadalnix (2/2) Sep 18 2014 You should try dustmite to reduce the problem further:
• Vladimir Panteleev (11/18) Sep 18 2014 I can't reproduce this. It's probably related to GDC. Can you try
• Koz Ross (11/29) Sep 18 2014 Hi Vladimir,
• Koz Ross (5/23) Sep 18 2014 Following up on this, under DMD, I get the enforcement failure on
• ketmar via Digitalmars-d (6/9) Sep 18 2014 On Fri, 19 Sep 2014 04:55:32 +0000
• ketmar via Digitalmars-d (5/8) Sep 18 2014 no failuers for me. Slackware GNU/Linux, x86, gcc 4.9.1 and
• Koz Ross (6/16) Sep 18 2014 Yeah, I'm still confused as to why this is happening to me. So
• ketmar via Digitalmars-d (4/8) Sep 18 2014 yes, alot of lines (201 ;-) with pairs of numbers, no errors at all.
• Koz Ross (4/13) Sep 18 2014 I'll try and test it on a 32-bit machine (or in fact, another
• Dan Olson (4/17) Sep 19 2014 I assume by overflow you mean buffer overflow?
• Iain Buclaw via Digitalmars-d (26/31) Sep 18 2014 worth a try. Basically, I'm getting totally bizarre behaviour from my co...
• Koz Ross (9/63) Sep 18 2014 Hi Iain,
• Koz Ross (5/5) Sep 18 2014 An update:
• Iain Buclaw via Digitalmars-d (4/8) Sep 19 2014 If there's overflow occurring, and overflow is *expected* in the code,
• Kagamin (2/2) Sep 19 2014 You can add more verification that numbers read from file are

"Koz Ross" <rasheevkostya hotmail.com> writes:

I don't know if this is the right place to ask, but I figured it 
was worth a try. Basically, I'm getting totally bizarre behaviour 
from my code, which I have put in a repo at 
https://gitorious.org/tournament-tree/tournament-tree/source/545460fb9d760b6bfa5bc74deb7b69d79ec70541:

To replicate the error, simply run 'make profile' from the 
project directory. It should fail (claiming an enforcement error 
on node.d, line 50). Then, go to tournament.d, and uncomment line 
33. Then, try 'make profile' again, and it won't have the same 
issue. I've been working all day to try and isolate the source of 
the problem, across multiple machines, and I've had no luck. This 
is the most isolation I've managed.

I would really appreciate any and all help, as this is something 
that totally baffles me. I know this is a lot of code, and it's 
probably quite hideous, but it would help me a lot if someone 
could at least suggest as to where the source of the problem lies.

I already am aware that the failure is caused by an overflow, but 
its source is completely unclear, and I never get overflows when 
that one writeln statement in tournament.d is executed (hence my 
confusion).

I'm running Manjaro GNU/Linux, and my gdc version is 4.9.1. I 
have a 64-bit OS.

"deadalnix" <deadalnix gmail.com> writes:

You should try dustmite to reduce the problem further: 
https://github.com/CyberShadow/DustMite

"Vladimir Panteleev" <vladimir thecybershadow.net> writes:

On Friday, 19 September 2014 at 04:46:56 UTC, Koz Ross wrote:
 I don't know if this is the right place to ask, but I figured 
 it was worth a try. Basically, I'm getting totally bizarre 
 behaviour from my code, which I have put in a repo at 
 https://gitorious.org/tournament-tree/tournament-tree/source/545460fb9d760b6bfa5bc74deb7b69d79ec70541:

I can't reproduce this. It's probably related to GDC. Can you try 
a different D compiler?

If you can't reproduce the problem with DMD, you should post in 
the GDC group:
http://forum.dlang.org/group/D.gnu

Have you heard of DustMite? It can automate the process of 
reducing your code to a minimal test case:

https://github.com/CyberShadow/DustMite/

 To replicate the error, simply run 'make profile' from the 
 project directory. It should fail (claiming an enforcement 
 error on node.d, line 50).

There is no enforce call on node.d line 50. Is the uploaded 
source code correct, or is this part of the problem?

"Koz Ross" <rasheevkostya hotmail.com> writes:

On Friday, 19 September 2014 at 04:55:34 UTC, Vladimir Panteleev 
wrote:
 On Friday, 19 September 2014 at 04:46:56 UTC, Koz Ross wrote:
 I don't know if this is the right place to ask, but I figured 
 it was worth a try. Basically, I'm getting totally bizarre 
 behaviour from my code, which I have put in a repo at 
 https://gitorious.org/tournament-tree/tournament-tree/source/545460fb9d760b6bfa5bc74deb7b69d79ec70541:

 I can't reproduce this. It's probably related to GDC. Can you 
 try a different D compiler?

 If you can't reproduce the problem with DMD, you should post in 
 the GDC group:
 http://forum.dlang.org/group/D.gnu

 Have you heard of DustMite? It can automate the process of 
 reducing your code to a minimal test case:

 https://github.com/CyberShadow/DustMite/

 To replicate the error, simply run 'make profile' from the 
 project directory. It should fail (claiming an enforcement 
 error on node.d, line 50).

 There is no enforce call on node.d line 50. Is the uploaded 
 source code correct, or is this part of the problem?

Hi Vladimir,

First of all, thanks for the prompt response. The enforce call in 
question is actually on line 55, and looks like this:

enforce(value > 0)

I added a few clarifying comments to the file, and I guess it 
changed the line number from what it was originally.

I will try and compile this under dmd and see if I have the same 
problem. I haven't heard of DustMite, but I'll also look into 
that. Thanks!

"Koz Ross" <rasheevkostya hotmail.com> writes:

On Friday, 19 September 2014 at 04:55:34 UTC, Vladimir Panteleev 
wrote:
 On Friday, 19 September 2014 at 04:46:56 UTC, Koz Ross wrote:
 I don't know if this is the right place to ask, but I figured 
 it was worth a try. Basically, I'm getting totally bizarre 
 behaviour from my code, which I have put in a repo at 
 https://gitorious.org/tournament-tree/tournament-tree/source/545460fb9d760b6bfa5bc74deb7b69d79ec70541:

 I can't reproduce this. It's probably related to GDC. Can you 
 try a different D compiler?

 If you can't reproduce the problem with DMD, you should post in 
 the GDC group:
 http://forum.dlang.org/group/D.gnu

 Have you heard of DustMite? It can automate the process of 
 reducing your code to a minimal test case:

 https://github.com/CyberShadow/DustMite/

 To replicate the error, simply run 'make profile' from the 
 project directory. It should fail (claiming an enforcement 
 error on node.d, line 50).

 There is no enforce call on node.d line 50. Is the uploaded 
 source code correct, or is this part of the problem?

Following up on this, under DMD, I get the enforcement failure on 
line 55 with and without the print statement. Now I'm even more 
confused.

ketmar via Digitalmars-d <digitalmars-d puremagic.com> writes:

On Fri, 19 Sep 2014 04:55:32 +0000
Vladimir Panteleev via Digitalmars-d <digitalmars-d puremagic.com>
wrote:

 Have you heard of DustMite? It can automate the process of=20
 reducing your code to a minimal test case:
 https://github.com/CyberShadow/DustMite/

i think that we must have DustMite on the main D page. it's a great
tool, yet most people can find it only by accident or by reading posts
of other people who mention it.

ketmar via Digitalmars-d <digitalmars-d puremagic.com> writes:

On Fri, 19 Sep 2014 04:46:55 +0000
Koz Ross via Digitalmars-d <digitalmars-d puremagic.com> wrote:

 To replicate the error, simply run 'make profile' from the=20
 project directory. It should fail (claiming an enforcement error=20
 on node.d, line 50).

no failuers for me. Slackware GNU/Linux, x86, gcc 4.9.1 and
gdc-4.9-head (yet with some fixes backported from master, but they
shouldn't make any difference). it also works perfectly with dmd-head.

"Koz Ross" <rasheevkostya hotmail.com> writes:

On Friday, 19 September 2014 at 05:18:20 UTC, ketmar via 
Digitalmars-d wrote:
 On Fri, 19 Sep 2014 04:46:55 +0000
 Koz Ross via Digitalmars-d <digitalmars-d puremagic.com> wrote:

 To replicate the error, simply run 'make profile' from the 
 project directory. It should fail (claiming an enforcement 
 error on node.d, line 50).

 no failuers for me. Slackware GNU/Linux, x86, gcc 4.9.1 and
 gdc-4.9-head (yet with some fixes backported from master, but 
 they
 shouldn't make any difference). it also works perfectly with 
 dmd-head.

Yeah, I'm still confused as to why this is happening to me. So 
does it run correctly and output a bunch of numbers, separated by 
spaces, two per line, or does it just not throw an enforcement 
error?

ketmar via Digitalmars-d <digitalmars-d puremagic.com> writes:

On Fri, 19 Sep 2014 06:11:32 +0000
Koz Ross via Digitalmars-d <digitalmars-d puremagic.com> wrote:

 Yeah, I'm still confused as to why this is happening to me. So=20
 does it run correctly and output a bunch of numbers, separated by=20
 spaces, two per line, or does it just not throw an enforcement=20
 error?

yes, alot of lines (201 ;-) with pairs of numbers, no errors at all.
maybe it's due to my 32-bit system.

"Koz Ross" <rasheevkostya hotmail.com> writes:

On Friday, 19 September 2014 at 06:21:31 UTC, ketmar via 
Digitalmars-d wrote:
 On Fri, 19 Sep 2014 06:11:32 +0000
 Koz Ross via Digitalmars-d <digitalmars-d puremagic.com> wrote:

 Yeah, I'm still confused as to why this is happening to me. So 
 does it run correctly and output a bunch of numbers, separated 
 by spaces, two per line, or does it just not throw an 
 enforcement error?

 yes, alot of lines (201 ;-) with pairs of numbers, no errors at 
 all.
 maybe it's due to my 32-bit system.

I'll try and test it on a 32-bit machine (or in fact, another 
machine) and see if I get the same error.

Dan Olson <zans.is.for.cans yahoo.com> writes:

"Koz Ross" <rasheevkostya hotmail.com> writes:

 On Friday, 19 September 2014 at 06:21:31 UTC, ketmar via Digitalmars-d
 wrote:
 On Fri, 19 Sep 2014 06:11:32 +0000
 Koz Ross via Digitalmars-d <digitalmars-d puremagic.com> wrote:

 Yeah, I'm still confused as to why this is happening to me. So does
 it run correctly and output a bunch of numbers, separated by
 spaces, two per line, or does it just not throw an enforcement
 error?

 yes, alot of lines (201 ;-) with pairs of numbers, no errors at all.
 maybe it's due to my 32-bit system.

 I'll try and test it on a 32-bit machine (or in fact, another machine)
 and see if I get the same error.

I assume by overflow you mean buffer overflow?

I also ran your code successfully (no enforce error) on OSX 64-bit
with  dmd 2.066 and ldc 0.14.0 (2.065).

Iain Buclaw via Digitalmars-d <digitalmars-d puremagic.com> writes:

On 19 Sep 2014 05:50, "Koz Ross via Digitalmars-d" <
digitalmars-d puremagic.com> wrote:
 I don't know if this is the right place to ask, but I figured it was

worth a try. Basically, I'm getting totally bizarre behaviour from my code,
which I have put in a repo at
https://gitorious.org/tournament-tree/tournament-tree/source/545460fb9d760b6bfa5bc74deb7b69d79ec70541
:
 To replicate the error, simply run 'make profile' from the project

directory. It should fail (claiming an enforcement error on node.d, line
50). Then, go to tournament.d, and uncomment line 33. Then, try 'make
profile' again, and it won't have the same issue. I've been working all day
to try and isolate the source of the problem, across multiple machines, and
I've had no luck. This is the most isolation I've managed.
 I would really appreciate any and all help, as this is something that

totally baffles me. I know this is a lot of code, and it's probably quite
hideous, but it would help me a lot if someone could at least suggest as to
where the source of the problem lies.
 I already am aware that the failure is caused by an overflow, but its

source is completely unclear, and I never get overflows when that one
writeln statement in tournament.d is executed (hence my confusion).
 I'm running Manjaro GNU/Linux, and my gdc version is 4.9.1. I have a

64-bit OS.

What flags are you using to build?  And is this a package you installed
from your distribution?

Recently in upstream, I've turned on -fwrapv by default so that the backend
handles overflow as precisely defined, rather than optimising aggressively
by pretending it never happens.

http://bugzilla.gdcproject.org/show_bug.cgi?id=141

It may be a good idea to add this flag to your build script if you are
using an earlier version of gdc.

Iain.

"Koz Ross" <rasheevkostya hotmail.com> writes:

On Friday, 19 September 2014 at 06:35:32 UTC, Iain Buclaw via 
Digitalmars-d wrote:
 On 19 Sep 2014 05:50, "Koz Ross via Digitalmars-d" <
 digitalmars-d puremagic.com> wrote:
 I don't know if this is the right place to ask, but I figured 
 it was

 worth a try. Basically, I'm getting totally bizarre behaviour 
 from my code,
 which I have put in a repo at
 https://gitorious.org/tournament-tree/tournament-tree/source/545460fb9d760b6bfa5bc74deb7b69d79ec70541
 :
 To replicate the error, simply run 'make profile' from the 
 project

 directory. It should fail (claiming an enforcement error on 
 node.d, line
 50). Then, go to tournament.d, and uncomment line 33. Then, try 
 'make
 profile' again, and it won't have the same issue. I've been 
 working all day
 to try and isolate the source of the problem, across multiple 
 machines, and
 I've had no luck. This is the most isolation I've managed.
 I would really appreciate any and all help, as this is 
 something that

 totally baffles me. I know this is a lot of code, and it's 
 probably quite
 hideous, but it would help me a lot if someone could at least 
 suggest as to
 where the source of the problem lies.
 I already am aware that the failure is caused by an overflow, 
 but its

 source is completely unclear, and I never get overflows when 
 that one
 writeln statement in tournament.d is executed (hence my 
 confusion).
 I'm running Manjaro GNU/Linux, and my gdc version is 4.9.1. I 
 have a

 64-bit OS.

 What flags are you using to build?  And is this a package you 
 installed
 from your distribution?

 Recently in upstream, I've turned on -fwrapv by default so that 
 the backend
 handles overflow as precisely defined, rather than optimising 
 aggressively
 by pretending it never happens.

 http://bugzilla.gdcproject.org/show_bug.cgi?id=141

 It may be a good idea to add this flag to your build script if 
 you are
 using an earlier version of gdc.

 Iain.

Hi Iain,

I'm using the flags as described in the makefile - my compile 
command is always

gdc -O3 -funittest -Wall -Werror -Wdeprecated -Wunknown-pragmas -g

The package I'm using is the gdc package from AUR (as Manjaro is 
an Arch).

I'll try -fwrapv and see if it does anything.

"Koz Ross" <rasheevkostya hotmail.com> writes:

An update:

If I don't use -O3 (in fact, if I don't use the -O flag at all), 
the code compiles and runs exactly as expected. I'm a little 
surprised (as even -O1 causes this same strange behaviour). Could 
this be a bug?

Iain Buclaw via Digitalmars-d <digitalmars-d puremagic.com> writes:

On 19 September 2014 07:41, Koz Ross via Digitalmars-d
<digitalmars-d puremagic.com> wrote:
 An update:

 If I don't use -O3 (in fact, if I don't use the -O flag at all), the code
 compiles and runs exactly as expected. I'm a little surprised (as even -O1
 causes this same strange behaviour). Could this be a bug?

If there's overflow occurring, and overflow is *expected* in the code,
then you are at the mercy of the optimiser working against you. :)

"Kagamin" <spam here.lot> writes:

You can add more verification that numbers read from file are 
positive.