runtime: Debugger does not correctly handle bytes without a backing field.

Had another user hit this and ping me on Twitter.

@tommcdon, Given this issue has been present for over 4 years, has had a plethora of duplicate issues, and gets at least a couple new hits/asks per release, can we please look at reprioritizing it?

Thanks for the feedback @tannergooding . We will evaluate this request for .NET 8

Please fix this, I just spent a significant amount of time convinced that I did not really understand how to create a Vector<long> from a Span<long> because of this bug.

@tommcdon, is this something that you could point me to the sources for and I could take a look at getting a small fix in for?

The more general fix is likely more complex, but handling Vector<T> itself could likely just be a simple special-case.

@tannergooding thanks! I have changed the milestone from Future to 5.0, so this item is on our 5.0 backlog.

Tested on .NET 8 locally and it looks to also be resolved for fixed sized buffers.

I just re-tested this and my conclusion is that it reproduces if you target .NET 6.0, but it does NOT reproduce if you target .NET 7.0.

So perhaps something changed in .NET 7.0 that fixed this?

For the record, my repro for this was the following:

namespace Test
{
    using System;
    using System.Diagnostics;
    using System.Numerics;
    using System.Runtime.InteropServices;

    class TestProgram
    {
        static void Main(string[] args)
        {
            var data = new Memory<byte>(new byte[64]);
            var val = 5L;

            for (int i = 0; i < 64; i += 8)
            {
                MemoryMarshal.Write<long>(data.Span.Slice(i, 8), ref val);
            }

            var longValues = MemoryMarshal.Cast<byte, long>(data.Span.Slice(0, 64));

            var count = Vector<long>.Count;
            var sliceA = longValues.Slice(0, count);
            var vecA = new Vector<long>(sliceA);
            Debug.WriteLine(vecA);
        }
    }
}

On VS 2022 17.5.0, I am seeing the correct values

Just ran into this (2nd time may be) and trying to think what is happening until @tannergooding pointed me to this issue.

@rickbrew Thank you for the feedback. We apologize for the long wait implementing a fix for this issue. Ideally we would like to fix every issue and implement every idea people submit. Realistically, we cannot address every item.  We will continue to re-evaluate this issue against our other priorities and update it once it is committed for the release.

I have just encountered this while debugging some code that uses Vector<T>.

This is quite a visible problem for those of us writing code using Vector<T> on a CPU with 256 bit vector registers (i.e. pretty much all modern CPUs). Any chance this could be moved back to the 5.0 milestone? It’s already been kicked down the road several times - for at least three years (see #7626)

That said, it seems to me that this a a Visual Studio bug, not a dotnet core/sdk bug - is that so? and if so can the bug be fixed in a VS update? So perhaps it doesn’t have to be tied to a dotnet milestone?

For the record, here’s my demo program for recreating the problem on a machine with 256bit SIMD registers:

    static void Main(string[] args)
    {
        // Some array we want to perform maths on using Vector<float>.
        float[] x = new float[16];
        for(int i=0; i < x.Length; i++) {
            x[i] = i;
        }

        // Determine number of floats that will fit into one vector on the current hardware.
        // E.g. 256 bit vector register = 8 * 32bit floats.
        int width = Vector<float>.Count;

        // Get a 'width' sized slice from x.
        Span<float> span = x.AsSpan();
        Span<float> slice = span.Slice(0, width);

        // Load the slice into a Vector.
        var vec = new Vector<float>(slice);

        // Print the elements of the vector.
        for(int i=0; i < width; i++)
        {
            Console.WriteLine($"[{i}] = {vec[i]}");
        }
        
        // Again, using ToString().
        Console.WriteLine(vec.ToString());
    }

The output of the program is correct, but the debugger shows zeros in the last 4 elements of vec, which is certainly confusing!

@davmason, @tommcdon.

Has there been any progress or prioritization here. There seems to have been at least 4 total issues on CoreFX and at least 3 total internal issues filed on this so far (there may be more but tracking them all is a bit difficult).

@tmat and I just went through and closed several as dupes against this; it seems fairly prevalent; especially as more people are writing vectorized code.