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.

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.

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?

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. :)

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

"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).