It is indeed weird that this code compiles.

But I'm not sure we can turn it into an error. For one thing, it could break existing content.

It also really depends on whether this is supposed to be allowed by the GLSL spec. I don't know off-hand.

Per the GLSL ES spec, section 10.29, it appears to be well-defined that a missing return path will return an undefined value, though I'm not sure if this is true also of GLSL.

https://www.khronos.org/files/opengles_shading_language.pdf

yeah, I read elsewhere that determining whether a final return was really necessary would be equivalent to the NP problem of program halting. 

In the spirit of secure languages like ADA one could force the user to always put a return at the end, but conservative constraints is not in the spirit of C-family languages which GLSL inherit.

Still, this indetermination seems to give consistently different values in OpenGL vs Angle, but there's probably not much we can do here.

Thanks for studying the spec and clarifying GLSL ES behavior.

This is similar to uninitialized variables. I think we could just simply append an extra "return 0" in the end of a function to get rid of undefined values.

very good idea for at least if would be cross-compatible.
But do you know easily how to generate the zero for any type ?

We already have the code to initialize un-initialized variables, so assume generating zero for any type is already implemented in ANGLE shader translator?

Yes, we have the code to generate zero for any type already. We can't just naively add return 0 to everything though - issues might arise if ANGLE would append return 0 in cases where the extra return is detected by the native compiler and it starts complaining about it.

We can still probably do pretty well without solving the halting problem, but it is a fair amount of effort - I don't think I'll take this on right now.