January 23, 2013
On 2013-01-23 08:50, Walter Bright wrote:

> If your program has undefined behavior in it, the -O flag can definitely
> cause that behavior to change.

Yes, I guess that is to be expected. I'm mostly talking about correct code here.

-- 
/Jacob Carlborg
January 23, 2013
On 1/23/2013 8:06 AM, Jacob Carlborg wrote:
> On 2013-01-23 08:50, Walter Bright wrote:
>
>> If your program has undefined behavior in it, the -O flag can definitely
>> cause that behavior to change.
>
> Yes, I guess that is to be expected. I'm mostly talking about correct code here.

-O can especially expose code bugs like referencing an out-of-scope stack frame.

January 23, 2013
On Wednesday, 23 January 2013 at 20:03:03 UTC, Walter Bright wrote:
> On 1/23/2013 8:06 AM, Jacob Carlborg wrote:
>> On 2013-01-23 08:50, Walter Bright wrote:
>>
>>> If your program has undefined behavior in it, the -O flag can definitely
>>> cause that behavior to change.
>>
>> Yes, I guess that is to be expected. I'm mostly talking about correct code here.
>
> -O can especially expose code bugs like referencing an out-of-scope stack frame.

This is a very good point, and I do think that there might be some mistake like that in my code, but it's definitely not obvious to me where. I did use delegates at some point, but in order to narrow down the causes, I changed that delegate to a functor, and the segfault still occurred.

What would be the prototypic short program that simulates referencing an out of scope stack frame? It would be great to see an example that produces a deterministic segfault.

Thanks, Stephan

January 24, 2013
On 1/23/2013 2:15 PM, Stephan wrote:
> What would be the prototypic short program that simulates referencing an out of
> scope stack frame? It would be great to see an example that produces a
> deterministic segfault.


Just return a pointer to a local (first passing it through another function in order to hide what you're doing from the compiler).

btw, bug 8832 is an example of one.
January 24, 2013
On Thursday, 24 January 2013 at 00:01:26 UTC, Walter Bright wrote:
> On 1/23/2013 2:15 PM, Stephan wrote:
>> What would be the prototypic short program that simulates referencing an out of
>> scope stack frame? It would be great to see an example that produces a
>> deterministic segfault.
>
>
> Just return a pointer to a local (first passing it through another function in order to hide what you're doing from the compiler).
>
> btw, bug 8832 is an example of one.

OK, I spent quite a while to narrow it down, and I definitely can say that there is a compiler bug related to the optimization switch.
I filed an issue: (9387).

I could not anymore reproduce a seg-fault, but even worse: The optimization switch changes the behavior of the program!, I declared it as "major", since it is not clear whether this bug is even detectable if it doesn't cause a seg-fault. It just changes the behavior, so it seems to me very dangerous!

The program I attached in the bug-report is an implementation of a minimization routine from Numerical Recipes, 3rd edition. This bug is possibly caused by having a large number of local variables, which are somehow written out into memory before moved into registers or something. I looked at the assembly with a colleague but we couldn't find something conclusive.

I hope that you guys can reproduce the bug (simply run "rdmd -O brent_test.d" and compare it with "rdmd brent_test.d") on dmd 2.061. There is nothing exotic in the source-code, only assignments. No pointers, no references, no structs. It must be a compiler bug.

Stephan

January 24, 2013
On Thursday, 24 January 2013 at 00:01:26 UTC, Walter Bright wrote:
> On 1/23/2013 2:15 PM, Stephan wrote:
>> What would be the prototypic short program that simulates referencing an out of
>> scope stack frame? It would be great to see an example that produces a
>> deterministic segfault.
>
>
> Just return a pointer to a local (first passing it through another function in order to hide what you're doing from the compiler).
>
> btw, bug 8832 is an example of one.

OK. This bug was introduced in 2.061!
With 2.060, the optimization switch does not corrupt the program. I put this in the bug report as well.

Stephan
1 2
Next ›   Last »