Original Redmine Comment
Author Name: Todd Strader (@toddstrader)
Original Date: 2015-09-24T22:13:46Z

Actually, after looking a little bit further, I'm noticing that replaceWithSimulation() wants to replace the node with a V3Number. I'm guessing that's the problem here and that the solution would be to have this method replace the node with a value of any data type. Not sure what this node type is or how to do this yet, I'll keep digging.

Original Redmine Comment
Author Name: Wilson Snyder (@wsnyder)
Original Date: 2015-09-25T01:20:06Z

I think you're right it's like #�. If you run this

make && test_regress/t/t_static_elab_struct.pl --debug --debugi-V3Simulate 9

you'll see it doesn't replace "result" because it's a struct (the Clear optimizable debug message). Can you attempt a patch?

Original Redmine Comment
Author Name: Todd Strader (@toddstrader)
Original Date: 2015-09-25T02:38:10Z

Yeah, sure thing. Thanks for the pointer.

Original Redmine Comment
Author Name: Todd Strader (@toddstrader)
Original Date: 2015-09-29T11:53:03Z

I posted a fix to GitHub, but I'm not entirely clear on the ramifications. There were two issues I had to address. The first was an extension of #�. I just had to tell the simulator that it could "squash structs too":toddstrader/verilator-static-elab@033818c#diff-7e9b42736a22eade7ad7b9a534f5983bL264.

After I did that, I could compile my test but it failed because the logic member of the struct was being initialized with X's. My first attempt was to add logic to the list of zero-able types in AstBasicDTypeKwd::isZeroInit(). However, this broke a couple tests which check for this very behavior. Instead I "modified the ASSIGN visitor":toddstrader/verilator-static-elab@033818c#diff-7e9b42736a22eade7ad7b9a534f5983bL473 so that it would accept logics as zero-able as well. This makes my test and all others pass.

My concern is that this weakens the property of poisoning uninitialized values. If I had a function that returned a struct like this and forgot to assign a field, I would prefer X's in the field as opposed to 0's.

I was somewhat surprised that my logic member was being infected by X's since I explicitly assign it in the function. I traced this down to V3Number::setBit() which doesn't clear out the X/Z state even when setting the bit to 0/1. I'm sure I'm missing something here, but this seems wrong. I understand that if I perform logical operations on X/Z, I may get a result of X/Z. But I would think that whatever value I'm setting a bit to should just stick.

Thoughts? Does my V3Simulate change work? Should I make a more forceful version of V3Number::setBit() to avoid X poisoning?

Original Redmine Comment
Author Name: Wilson Snyder (@wsnyder)
Original Date: 2015-09-29T12:09:10Z

I suspect the V3Number non-clearing is a bug, please try a separate patch fixing that and if all the tests work I'll commit it.

Original Redmine Comment
Author Name: Todd Strader (@toddstrader)
Original Date: 2015-09-29T12:15:59Z

OK, sounds good. It seemed pretty intentional, so I was scared to touch it. But we'll see what the tests say.

Original Redmine Comment
Author Name: Todd Strader (@toddstrader)
Original Date: 2015-09-29T21:56:51Z

All of the tests seem to be happy with the setBit() change. I've cleaned up the GitHub repo. Please take a look when you get a chance. It should be ready to go.

Original Redmine Comment
Author Name: Wilson Snyder (@wsnyder)
Original Date: 2015-09-30T01:03:52Z

Good stuff. Slightly changed the V3Number code to clean it up (my original code was bizarre.)

Fixed in git towards 3.877.

Original Redmine Comment
Author Name: Todd Strader (@toddstrader)
Original Date: 2015-09-30T10:09:24Z

Unfortunately, I think setBit() has another bug now. I'll open another issue.

Original Redmine Comment
Author Name: Wilson Snyder (@wsnyder)
Original Date: 2015-11-01T13:22:55Z

In 3.878.