Validator does not consider type aliasing with structs in interface blocks about spirv-tools HOT 6 CLOSED

The validation might be correct due to this wording

Pointer is the pointer to store through. Its type must be an OpTypePointer whose Type operand is the same as the
type of Object.

but I'm not sure how this would interact with everything else.

from spirv-tools.

Not a bug -- this is the spec's intent. %11 and %8 are different types, despite having the same structure.

Note that type IDs must be unique for non-structure types.

from spirv-tools.

I am not sure how storing structs to SSBO would be possible in this case though. Or perhaps that is defined to not be possible ... At any rate, I have opened a glslang ticket about this instead.

from spirv-tools.

I agree this is a glslang bug -- it should simply reuse a single struct type for foo* and bar. I can't think of a reason why it couldn't. That would generate valid SPIR-V functionally equivalent to the GLSL above.

from spirv-tools.

I agree this is a glslang bug -- it should simply reuse a single struct type for foo* and bar. I can't think of a reason why it couldn't.

In this case it might be okay, but in the general case, the struct has two different layouts, one for each block it is in.

So, it is the same type at the GLSL level, but not at the SPIR-V level, which means a full implementation of GLSL->SPIR-V needs to copy member-by-member, not as a whole object.

from spirv-tools.

Ah, good point -- thanks, @johnkslang.

from spirv-tools.