Program runs fine in Debug but crashes in Release

[ThatGuyMike7]

This program runs fine in Debug mode, but crashes in Release mode with optimizations on. The relevant portion is the 3 nested for-loops that loop over the bitmap and samples. For each pixel, multiple rays are cast and then the result is averaged (anti-aliasing). As you can see, I add the colors up and then divide to get the average. Finally, in the ColorF structure, the components are converted from a [0f - 1f] range to a [0 - 255] range. The exception thrown in Release mode is because the green component is > 1.1f, expected result is <= 1.0f. The code looks fine to me, so I thought this could be a compiler bug, as the program runs fine with optimizations disabled.

Repro steps

1. Copy code from https://pastebin.com/B38VwWKB
2. Compile the code (with Visual Studio 2019, FSharp.Core (6.0.1) and System.Drawing.Common (5.0.2))

Project zip file if needed: raytracer.zip

Expected behavior
Output a "output.jpeg" image in Release mode.

Actual behavior
Exception thrown in Release mode.

• Operating system: Windows 10
• .NET Runtime kind (.NET Core, .NET Framework, Mono): I am not sure honestly but you can check the zip file. I think it's .Net Framework 5.0
• Editing Tools (e.g. Visual Studio Version, Visual Studio): Visual Studio Community 2019

[dsyme]

Thank you for this bug report. I've confirmed the behaviour is the same in all of

• .NET SDK 3.1414
• .NET SDK 5.0.402
• .NET SDK 6.0.100-rc.2.21505.57

So at least it's not a regression.

thanks

[dsyme]

The code looks fine to me, so I thought this could be a compiler bug, as the program runs fine with optimizations disabled.

So my understanding is that .NET floating point code can differ between Release and Debug - my understanding is that floating point values can stay in registers longer in Release mode and precisions can be different. (32 bit --> 80 bit internally in Intel preocessors). I assume that's what's doing on here.

If we can narrow this down to a repro much smaller we may be able to clarify.

[dsyme]

I've confirmed this is a codegen bug, thank you

[dsyme]

Labelling as a regression - it's strictly speaking not but it's important to fix

[gsomix]

I've found minimal repro.

[<Struct>]
type ColorF =
    val r: float32
    val g: float32
    val b: float32

    new (r, g, b) = {
        ColorF.r = r
        ColorF.g = g
        ColorF.b = b
    }

    static member (+) (first: ColorF, second: ColorF) =
        ColorF(first.r + second.r, first.g + second.g, first.b + second.b)

let Issue12333 () =
    for x = 0 to 1 do
        printfn "iter %d" x
        let mutable color: ColorF = ColorF()
        printfn "init color %g %g %g" color.r color.g color.b
        for s = 0 to 1 do
            let temp = ColorF(0.1f, 0.1f, 0.1f)
            color <- color + temp
            printfn "color %g %g %g" color.r color.g color.b

[<EntryPoint>]
let main (argv: string[]): int =
    Issue12333()
    0 

Debug output:

iter 0
init color 0 0 0
color 0.1 0.1 0.1
color 0.2 0.2 0.2
iter 1
init color 0 0 0
color 0.1 0.1 0.1
color 0.2 0.2 0.2

Release output:

iter 0
init color 0 0 0
color 0.1 0.1 0.1
color 0.2 0.2 0.2
iter 1
init color 0.1 0.1 0.1 // wrong initial value!!!
color 0.2 0.2 0.2
color 0.3 0.3 0.3

Environment:

> dotnet --version
6.0.100-rc.2.21505.57

[dsyme]

Yes, it's a zero-initialization bug related to backward branching. We had one of these before.

[dsyme]

Fix is in #12337

[dsyme]

Fix is in.