I was concerned that only setting the Immutable property would not capture the fact that the tag itself could change. But it seems the tag of lazy values is never read directly, always through the caml_obj_tag primitive (in Lazy.from_val/is_val, or in the code generated by matching.ml), and thus flambda cannot be "too clever" and illegally simplify away the tag extraction.

What about generating a call to the opaque identity around the creation of the forward block? This should be a bit safer than the current solution (Immutable) for future optimizations (e.g. shortcutting the call to caml_obj_tag when the tag seems to be known), no?

(I was also concerned that there might be other cases of blocks whose tag change, but this does not seem to be the case for now: Obj.set_tag is also called in camlinternalMod, but this should be covered -- perhaps adding the opaque identity there could be cleaner, though.)

I was going to say the same thing as @alainfrisch, Popaque is the only way to prevent the tag information from being used.

Also we might not want to hide the setfield argument inside an opaque to be able to see other potential missing cases

I confirm that the patch avoids the segfault in our failing tests.

@alainfrisch You mean setting the Mutable property, not Immutable, right? Anyway, yes, maybe it is in fact better to generate Popaque around this (and aim to have a new primitive in the future, as per the comment).

@chambart Maybe in fact that is a better idea, at least for the moment. I'll revert that part.

You mean setting the Mutable property, not Immutable, right?

Yes, sorry.

I'm not sure what should be the semantics of such a lazy makeblock to fit well with the Pforce code. Maybe that suggest that Plazyforce lowering should apply later in native code to handle that well.

@alainfrisch @chambart Can one of you please approve this if you are certain of the fix?

Yes, I'm rather confident this patch addresses the root cause of the problem. (Don't forget to add an entry to Changes!)