BUG && SPEC VIOLATION: CheckNamedFramebufferStatus returns GL_FRAMEBUFFER_INCOMPLETE_DIMENSIONS_EXT under GL 4.5 core

We have discovered a bug which goes against the Core 3.3+ spec, by attaching two different sized textures (also same happens with renderbuffers) to a Frame Buffer Object.

By the spec, if attachments are different size, then the renderable area will be the intersection of all attachment sizes (largest rectangle to fit in all).

Also the GL_FRAMEBUFFER_INCOMPLETE_DIMENSIONS_EXT enum is part of the EXT_framebuffer_object extension, which we are definitely not using or loading function pointers to.

We use OpenGL 4.5 with DSA, and were able to reproduce the bug both on 64bit Linux (driver 387.34) and 64bit Windows (driver 391.01).

Here’s a repository directory with an apitrace file and the screenshot of the relevant trace, and a Linux binary
[url]https://github.com/devshgraphicsprogramming/BugTraces/tree/master/NVIDIA[/url]

And a full source code of the binary in my engine repository; no visual studio solution for the example yet, but will come soon (also requires building the engine as a dependency, with openssl)
[url]https://github.com/buildaworldnet/IrrlichtBAW/tree/master/examples_tests/18.DifferentSizeFBOAttachments[/url]

After some investigations we’ve found that the Direct State Access path is causing framebuffer to be incomplete, despite using a core profile 4.5 context where ARB_direct_state_access was integrated into core.

Now we have had to re-code DSA workarounds (use bind-to-modify again) for framebuffer attaching, setting read/draw buffers, validation and clearing because the behaviour mandated by both ARB_direct_state_access and The OpenGL 4.5 spec is violated.