On 10/03/2018 11:52 PM, Iago Toral wrote: > On Wed, 2018-10-03 at 16:24 +0300, Vadim Shovkoplias wrote: >> Hi Iago, >> >> I also think that compiler is the best place for the fix. But from my >> understanding compiler fix will be limited to distinct shader objects >> (not the shader stage). >> In GLSL spec mentioned: "A program will fail to compile or link if any >> *shader or stage* contains two or more functions with the same name if >> the name is >> associated with a subroutine type". >> So if I understand the spec correctly such restriction for the shader >> stage can be fixed only in linker. E.g. consider the use case when >> fragment shader is linked from >> two fragment shader objects. One object contains function foo() which >> is associated with subroutine type and second shader object has some >> regular foo() function >> with the same name. I suppose compiler fix won't be able to detect this. > > Yes, that is correct, good point. > >> IMHO the best way to fix this is to implement 2 patches: >> 1) One patch for linker to implement restriction for the shader stages >> (already done in this patch) >> 2) Another one for compiler to check the restriction for distinct >> shader objects. >> >> What do you think ? > > Since we need to keep the link-time check, any compile-time checks we > add would be redundant with that, so I think we should just go with the > link-time check only (your original patch)
The spec quotation is pretty clear: "A program will fail to compile ... if any shader ... contains two or more functions with the same name if the name is associated with a subroutine type." To be strictly correct, both checks are necessary. Before doing that extra work, someone should check that glslang has the compile-time check. _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
