GL_SHADER_BINARY_FORMAT_SPIR_V is not added to the list of GL_SHADER_BINARY_FORMATS even if GL_ARB_gl_spirv is supported.
Actual Bug
I noticed that GL_SHADER_BINARY_FORMAT_SPIR_V did not appear in the list of GL_SHADER_BINARY_FORMATS of a user with an Intel IVB iGPU (GL 4.2) with the i965 driver, while said ICD does support GL_ARB_gl_spirv.
I was told that the issue also exists with radeonsi and that both are using the same code for handling this.
My understanding of the revelant OpenGL specs and extension implies that GL_SHADER_BINARY_FORMAT_SPIR_V needs to be added to the list of GL_SHADER_BINARY_FORMATS in case glShaderBinary accepts said format.
Apart from the requirement based on the spec, this should really be there.
Argument about the spec
Core 4.2 spec (what the user has) and 4.5 the gl_spirv spec is written against both state:
An INVALID_ENUM error is generated if binaryformat is not a supported format returned in SHADER_BINARY_FORMATS.
Section 7.2 deals with ShaderBinary in the 4.5 spec (different section in 4.2 spec). GL_ARB_gl_spirv writes about that section
Additions to Section 7.2, "Shader Binaries":
[...]
Replace the error condition for ShaderBinary which states:
"An INVALID_OPERATION error is generated if more than one of the
handles in shaders refers to the same type of shader object."
with the following:
"An INVALID_OPERATION error is generated if <binaryformat> is not
SHADER_BINARY_FORMAT_SPIR_V_ARB and more than one of the
handles in shaders refers to the same type of shader object."
So, the extention does not change or remove the INVALID_ENUM condition requirement above. So in case ShaderBinary accepts SHADER_BINARY_FORMAT_SPIR_V, it also needs to be listed in GL_SHADER_BINARY_FORMATS.
I don't really want to go down the road of trying to check whether the actual bug is that ShaderBinary does not generate INVALID_ENUM for SHADER_BINARY_FORMAT_SPIR_V as thats certainly what nobody wants.
Last
I really appreciate that this old Intel IVB hardware got SPIR-V support. Thats amazing :)