Why does stackalloc initialization have inconsistent behavior?

The following code initializes two stackalloc arrays with non-zero values. While array A is properly initialized, array B remains filled with zeroes, contrary to what is expected.

By disassembling the compiled executable, one can see that no initialization code is generated for array B. Why is that?

using System;

namespace ConsoleApp1

 class Program
 
 static unsafe void Main(string args)
 
 double a1 = 1;
 double* A = stackalloc double a1, 0, 0, a1, a1 ; // results in 1 0 0 1 1
 double* B = stackalloc double a1, 0, 0, 0, 0; // results in 0 0 0 0 0 

 for (int i = 0; i < 5; i++) Console.Write($"A[i] ");
 Console.WriteLine();
 for (int i = 0; i < 5; i++) Console.Write($"B[i] ");

Expected results:

1 0 0 1 1
1 0 0 0 0

Actual results:

1 0 0 1 1
0 0 0 0 0

edited Dec 31 '18 at 6:54

marc_s

572k12811061253

asked Dec 30 '18 at 22:23

Igor Gribanov

763

1

@ChrisF why would you expect replacing i with j would make a difference? (it doesn't, but curious)

– Kirk Woll
Dec 30 '18 at 22:33

1

This seems really peculiar to me. (i.e. I'm ready to learn something ;) ) but replacing a1 with the literal 1 in the second one produces entirely different results (it works).

– Kirk Woll
Dec 30 '18 at 22:34

2

@KirkWoll - I wasn't really expecting anything, but wanted to rule out any possible strangeness with reusing the variable. I've had cases where despite scoping indicating otherwise, variables and their values have persisted outside loops. In this case I wanted to check that the code was actually writing out each element of B and not just ,e.g., B[4]

– ChrisF♦
Dec 30 '18 at 22:36

2

Looks like a bug in the compiler. As far as I can see, it triggered if you have 3 or more zero constant expressions, and no non-zero constant expressions.

– PetSerAl
Dec 30 '18 at 22:42

2

I've attempted a 🦇 signal to @jaredpar. We'll see if he's ready to come to our aid. ;)

– Kirk Woll
Dec 30 '18 at 22:45

|
show 6 more comments

The following code initializes two stackalloc arrays with non-zero values. While array A is properly initialized, array B remains filled with zeroes, contrary to what is expected.

By disassembling the compiled executable, one can see that no initialization code is generated for array B. Why is that?

using System;

namespace ConsoleApp1

 class Program
 
 static unsafe void Main(string args)
 
 double a1 = 1;
 double* A = stackalloc double a1, 0, 0, a1, a1 ; // results in 1 0 0 1 1
 double* B = stackalloc double a1, 0, 0, 0, 0; // results in 0 0 0 0 0 

 for (int i = 0; i < 5; i++) Console.Write($"A[i] ");
 Console.WriteLine();
 for (int i = 0; i < 5; i++) Console.Write($"B[i] ");

Expected results:

1 0 0 1 1
1 0 0 0 0

Actual results:

1 0 0 1 1
0 0 0 0 0

edited Dec 31 '18 at 6:54

marc_s

572k12811061253

asked Dec 30 '18 at 22:23

Igor Gribanov

763

1

@ChrisF why would you expect replacing i with j would make a difference? (it doesn't, but curious)

– Kirk Woll
Dec 30 '18 at 22:33

1

This seems really peculiar to me. (i.e. I'm ready to learn something ;) ) but replacing a1 with the literal 1 in the second one produces entirely different results (it works).

– Kirk Woll
Dec 30 '18 at 22:34

2

@KirkWoll - I wasn't really expecting anything, but wanted to rule out any possible strangeness with reusing the variable. I've had cases where despite scoping indicating otherwise, variables and their values have persisted outside loops. In this case I wanted to check that the code was actually writing out each element of B and not just ,e.g., B[4]

– ChrisF♦
Dec 30 '18 at 22:36

2

Looks like a bug in the compiler. As far as I can see, it triggered if you have 3 or more zero constant expressions, and no non-zero constant expressions.

– PetSerAl
Dec 30 '18 at 22:42

2

I've attempted a 🦇 signal to @jaredpar. We'll see if he's ready to come to our aid. ;)

– Kirk Woll
Dec 30 '18 at 22:45

|
show 6 more comments

The following code initializes two stackalloc arrays with non-zero values. While array A is properly initialized, array B remains filled with zeroes, contrary to what is expected.

By disassembling the compiled executable, one can see that no initialization code is generated for array B. Why is that?

using System;

namespace ConsoleApp1

 class Program
 
 static unsafe void Main(string args)
 
 double a1 = 1;
 double* A = stackalloc double a1, 0, 0, a1, a1 ; // results in 1 0 0 1 1
 double* B = stackalloc double a1, 0, 0, 0, 0; // results in 0 0 0 0 0 

 for (int i = 0; i < 5; i++) Console.Write($"A[i] ");
 Console.WriteLine();
 for (int i = 0; i < 5; i++) Console.Write($"B[i] ");

Expected results:

1 0 0 1 1
1 0 0 0 0

Actual results:

1 0 0 1 1
0 0 0 0 0

edited Dec 31 '18 at 6:54

marc_s

572k12811061253

asked Dec 30 '18 at 22:23

Igor Gribanov

763

The following code initializes two stackalloc arrays with non-zero values. While array A is properly initialized, array B remains filled with zeroes, contrary to what is expected.

By disassembling the compiled executable, one can see that no initialization code is generated for array B. Why is that?

using System;

namespace ConsoleApp1

 class Program
 
 static unsafe void Main(string args)
 
 double a1 = 1;
 double* A = stackalloc double a1, 0, 0, a1, a1 ; // results in 1 0 0 1 1
 double* B = stackalloc double a1, 0, 0, 0, 0; // results in 0 0 0 0 0 

 for (int i = 0; i < 5; i++) Console.Write($"A[i] ");
 Console.WriteLine();
 for (int i = 0; i < 5; i++) Console.Write($"B[i] ");

Expected results:

1 0 0 1 1
1 0 0 0 0

Actual results:

1 0 0 1 1
0 0 0 0 0

edited Dec 31 '18 at 6:54

marc_s

572k12811061253

asked Dec 30 '18 at 22:23

Igor Gribanov

763

edited Dec 31 '18 at 6:54

marc_s

572k12811061253

asked Dec 30 '18 at 22:23

Igor Gribanov

763

edited Dec 31 '18 at 6:54

marc_s

572k12811061253

edited Dec 31 '18 at 6:54

marc_s

572k12811061253

edited Dec 31 '18 at 6:54

marc_s

572k12811061253

asked Dec 30 '18 at 22:23

Igor Gribanov

763

asked Dec 30 '18 at 22:23

Igor Gribanov

763

asked Dec 30 '18 at 22:23

Igor Gribanov

763

1

@ChrisF why would you expect replacing i with j would make a difference? (it doesn't, but curious)

– Kirk Woll
Dec 30 '18 at 22:33

1

This seems really peculiar to me. (i.e. I'm ready to learn something ;) ) but replacing a1 with the literal 1 in the second one produces entirely different results (it works).

– Kirk Woll
Dec 30 '18 at 22:34

2

@KirkWoll - I wasn't really expecting anything, but wanted to rule out any possible strangeness with reusing the variable. I've had cases where despite scoping indicating otherwise, variables and their values have persisted outside loops. In this case I wanted to check that the code was actually writing out each element of B and not just ,e.g., B[4]

– ChrisF♦
Dec 30 '18 at 22:36

2

Looks like a bug in the compiler. As far as I can see, it triggered if you have 3 or more zero constant expressions, and no non-zero constant expressions.

– PetSerAl
Dec 30 '18 at 22:42

2

I've attempted a 🦇 signal to @jaredpar. We'll see if he's ready to come to our aid. ;)

– Kirk Woll
Dec 30 '18 at 22:45

|
show 6 more comments

1

@ChrisF why would you expect replacing i with j would make a difference? (it doesn't, but curious)

– Kirk Woll
Dec 30 '18 at 22:33

1

This seems really peculiar to me. (i.e. I'm ready to learn something ;) ) but replacing a1 with the literal 1 in the second one produces entirely different results (it works).

– Kirk Woll
Dec 30 '18 at 22:34

2

@KirkWoll - I wasn't really expecting anything, but wanted to rule out any possible strangeness with reusing the variable. I've had cases where despite scoping indicating otherwise, variables and their values have persisted outside loops. In this case I wanted to check that the code was actually writing out each element of B and not just ,e.g., B[4]

– ChrisF♦
Dec 30 '18 at 22:36

2

Looks like a bug in the compiler. As far as I can see, it triggered if you have 3 or more zero constant expressions, and no non-zero constant expressions.

– PetSerAl
Dec 30 '18 at 22:42

2

I've attempted a 🦇 signal to @jaredpar. We'll see if he's ready to come to our aid. ;)

– Kirk Woll
Dec 30 '18 at 22:45

@ChrisF why would you expect replacing i with j would make a difference? (it doesn't, but curious)

– Kirk Woll
Dec 30 '18 at 22:33

This seems really peculiar to me. (i.e. I'm ready to learn something ;) ) but replacing a1 with the literal 1 in the second one produces entirely different results (it works).

– Kirk Woll
Dec 30 '18 at 22:34

@KirkWoll - I wasn't really expecting anything, but wanted to rule out any possible strangeness with reusing the variable. I've had cases where despite scoping indicating otherwise, variables and their values have persisted outside loops. In this case I wanted to check that the code was actually writing out each element of B and not just ,e.g., B[4]

– ChrisF♦
Dec 30 '18 at 22:36

Looks like a bug in the compiler. As far as I can see, it triggered if you have 3 or more zero constant expressions, and no non-zero constant expressions.

– PetSerAl
Dec 30 '18 at 22:42

I've attempted a 🦇 signal to @jaredpar. We'll see if he's ready to come to our aid. ;)

– Kirk Woll
Dec 30 '18 at 22:45

|
show 6 more comments

2 Answers
2

active

oldest

votes

Thanks for writing up a nice repro here! This appears to be a duplicate of issue 29092. The repro is a bit different but at a quick glance it's hitting the same problem and should also be fixed. The fix for this will be included in Dev16.

answered Dec 30 '18 at 22:57

JaredPar

570k11810581342

Stupid question: if you fixed it in September, why was it not shipped with all versions of Roslyn since?

– Ian Kemp
Dec 30 '18 at 23:10

1

The fix has been shipped then. The reason you didn't see a fix in the 15.9 build, which shipped in November, is that there is a delay between when VS stops taking fixes from us and when a version of VS ships. We essentially shut down 15.9 work in early September hence this didn't make it. The fix should appear in 16.0 builds though. If it doesn't then that means it's not a dupe.

– JaredPar
Jan 2 at 23:25

add a comment |

As it is stated by @JaredPar, It is a bug that is needed to be fixed.

As a workarround, I found two ways to avoid this problem.

one is to use const varible

const double a1 = 1;
double* A = stackalloc double[5] a1, 0, 0, 0, a1 ; // output 1 0 0 0 1

double a1 = 1;
double a0 = 0;
double* A = stackalloc double[5] a1, a0, a0, a0, a1 ; // output 1 0 0 0 1

answered Dec 30 '18 at 23:03

Simonare

7,18611435

add a comment |

Your Answer

StackExchange.ifUsing("editor", function ()
StackExchange.using("externalEditor", function ()
StackExchange.using("snippets", function ()
StackExchange.snippets.init();
);
);
, "code-snippets");

StackExchange.ready(function()
var channelOptions =
tags: "".split(" "),
id: "1"
;
initTagRenderer("".split(" "), "".split(" "), channelOptions);

StackExchange.using("externalEditor", function()
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled)
StackExchange.using("snippets", function()
createEditor();
);

else
createEditor();

);

function createEditor()
StackExchange.prepareEditor(
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader:
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
,
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
);

);

draft saved

draft discarded

StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53981915%2fwhy-does-stackalloc-initialization-have-inconsistent-behavior%23new-answer', 'question_page');

);

Post as a guest

Name

Required, but never shown

2 Answers
2

active

oldest

votes

2 Answers
2

active

oldest

votes

answered Dec 30 '18 at 22:57

JaredPar

570k11810581342

Stupid question: if you fixed it in September, why was it not shipped with all versions of Roslyn since?

– Ian Kemp
Dec 30 '18 at 23:10

1

The fix has been shipped then. The reason you didn't see a fix in the 15.9 build, which shipped in November, is that there is a delay between when VS stops taking fixes from us and when a version of VS ships. We essentially shut down 15.9 work in early September hence this didn't make it. The fix should appear in 16.0 builds though. If it doesn't then that means it's not a dupe.

– JaredPar
Jan 2 at 23:25

add a comment |

answered Dec 30 '18 at 22:57

JaredPar

570k11810581342

Stupid question: if you fixed it in September, why was it not shipped with all versions of Roslyn since?

– Ian Kemp
Dec 30 '18 at 23:10

1

The fix has been shipped then. The reason you didn't see a fix in the 15.9 build, which shipped in November, is that there is a delay between when VS stops taking fixes from us and when a version of VS ships. We essentially shut down 15.9 work in early September hence this didn't make it. The fix should appear in 16.0 builds though. If it doesn't then that means it's not a dupe.

– JaredPar
Jan 2 at 23:25

add a comment |

answered Dec 30 '18 at 22:57

JaredPar

570k11810581342

answered Dec 30 '18 at 22:57

JaredPar

570k11810581342

answered Dec 30 '18 at 22:57

JaredPar

570k11810581342

answered Dec 30 '18 at 22:57

JaredPar

570k11810581342

answered Dec 30 '18 at 22:57

JaredPar

570k11810581342

Stupid question: if you fixed it in September, why was it not shipped with all versions of Roslyn since?

– Ian Kemp
Dec 30 '18 at 23:10

1

The fix has been shipped then. The reason you didn't see a fix in the 15.9 build, which shipped in November, is that there is a delay between when VS stops taking fixes from us and when a version of VS ships. We essentially shut down 15.9 work in early September hence this didn't make it. The fix should appear in 16.0 builds though. If it doesn't then that means it's not a dupe.

– JaredPar
Jan 2 at 23:25

add a comment |

Stupid question: if you fixed it in September, why was it not shipped with all versions of Roslyn since?

– Ian Kemp
Dec 30 '18 at 23:10

1

The fix has been shipped then. The reason you didn't see a fix in the 15.9 build, which shipped in November, is that there is a delay between when VS stops taking fixes from us and when a version of VS ships. We essentially shut down 15.9 work in early September hence this didn't make it. The fix should appear in 16.0 builds though. If it doesn't then that means it's not a dupe.

– JaredPar
Jan 2 at 23:25

Stupid question: if you fixed it in September, why was it not shipped with all versions of Roslyn since?

– Ian Kemp
Dec 30 '18 at 23:10

The fix has been shipped then. The reason you didn't see a fix in the 15.9 build, which shipped in November, is that there is a delay between when VS stops taking fixes from us and when a version of VS ships. We essentially shut down 15.9 work in early September hence this didn't make it. The fix should appear in 16.0 builds though. If it doesn't then that means it's not a dupe.

– JaredPar
Jan 2 at 23:25

add a comment |

As it is stated by @JaredPar, It is a bug that is needed to be fixed.

As a workarround, I found two ways to avoid this problem.

one is to use const varible

const double a1 = 1;
double* A = stackalloc double[5] a1, 0, 0, 0, a1 ; // output 1 0 0 0 1

double a1 = 1;
double a0 = 0;
double* A = stackalloc double[5] a1, a0, a0, a0, a1 ; // output 1 0 0 0 1

answered Dec 30 '18 at 23:03

Simonare

7,18611435

add a comment |

As it is stated by @JaredPar, It is a bug that is needed to be fixed.

As a workarround, I found two ways to avoid this problem.

one is to use const varible

const double a1 = 1;
double* A = stackalloc double[5] a1, 0, 0, 0, a1 ; // output 1 0 0 0 1

double a1 = 1;
double a0 = 0;
double* A = stackalloc double[5] a1, a0, a0, a0, a1 ; // output 1 0 0 0 1

answered Dec 30 '18 at 23:03

Simonare

7,18611435

add a comment |

As it is stated by @JaredPar, It is a bug that is needed to be fixed.

As a workarround, I found two ways to avoid this problem.

one is to use const varible

const double a1 = 1;
double* A = stackalloc double[5] a1, 0, 0, 0, a1 ; // output 1 0 0 0 1

double a1 = 1;
double a0 = 0;
double* A = stackalloc double[5] a1, a0, a0, a0, a1 ; // output 1 0 0 0 1

answered Dec 30 '18 at 23:03

Simonare

7,18611435

As it is stated by @JaredPar, It is a bug that is needed to be fixed.

As a workarround, I found two ways to avoid this problem.

one is to use const varible

const double a1 = 1;
double* A = stackalloc double[5] a1, 0, 0, 0, a1 ; // output 1 0 0 0 1

double a1 = 1;
double a0 = 0;
double* A = stackalloc double[5] a1, a0, a0, a0, a1 ; // output 1 0 0 0 1

answered Dec 30 '18 at 23:03

Simonare

7,18611435

answered Dec 30 '18 at 23:03

Simonare

7,18611435

answered Dec 30 '18 at 23:03

Simonare

7,18611435

answered Dec 30 '18 at 23:03

Simonare

7,18611435

add a comment |

draft saved

draft discarded

Thanks for contributing an answer to Stack Overflow!

Please be sure to answer the question. Provide details and share your research!

But avoid …

Asking for help, clarification, or responding to other answers.

Making statements based on opinion; back them up with references or personal experience.

To learn more, see our tips on writing great answers.

draft saved

draft discarded

Post as a guest

Name

Required, but never shown

Name

Required, but never shown

Name

Required, but never shown

搜尋此網誌

mjhjmtu