Build failures with 0.9.9.3 on non-SIMD architectures

[gsliepen]

On non-SIMD architectures, GLM_CONSTEXPR is defined to constexpr. However, this causes a problem in some cases, such as these overloaded declarations of operator[] in glm/detail/type_vec2.hpp:

GLM_FUNC_DECL GLM_CONSTEXPR T& operator[](length_type i);
GLM_FUNC_DECL GLM_CONSTEXPR T const& operator[](length_type i) const;

The issue is that functions declared constexpr are also implicitly const, so the above two declarations become identical. For example, on a 32 bit ARM platform without NEON instructions, gcc 8.2.0 gives these errors:

In file included from /usr/include/glm/ext/vector_bool2.hpp:5,
             from /usr/include/glm/vec2.hpp:5,
             from /usr/include/glm/glm.hpp:116,
             from IOGfxDisplayGL2.cpp:29:
/usr/include/glm/detail/type_vec2.hpp:90:40: error: 'constexpr const T& glm::vec<2, T, Q>::operator[](glm::vec<2, T, Q>::length_type) const' cannot be overloaded with 'constexpr T& glm::vec<2, T, Q>::operator[](glm::vec<2, T, Q>::length_type) const'
   GLM_FUNC_DECL GLM_CONSTEXPR T const& operator[](length_type i) const;
                                        ^~~~~~~~
/usr/include/glm/detail/type_vec2.hpp:89:34: note: previous declaration 'constexpr T& glm::vec<2, T, Q>::operator[](glm::vec<2, T, Q>::length_type) const'
   GLM_FUNC_DECL GLM_CONSTEXPR T& operator[](length_type i);
                                  ^~~~~~~~

Either GLM_CONSTEXPR should not be used, or one of the declarations (and the corresponding implementation) should be put inside #if GLM_HAS_CONSTEXPR.

The issue was found by the Debian autobuilders failing to build packages depending on GLM on all architectures except amd64 and arm64. See for example: https://buildd.debian.org/status/fetch.php?pkg=freedink&arch=armel&ver=109.4-3&stamp=1548775669&raw=0

[gsliepen]

After thinking about this some more, I think you should never make constexpr conditional: either the application can trust that a function is constexpr and can use it in its own constexpr expressions, or it cannot. There is no change in performance anyway: if there is a const version and the compiler inlines it, it can optimize the whole thing away just the same. constexpr is just a promise that something is guaranteed to be evaluable at compile time.

So, I suggest to remove GLM_CONSTEXPR entirely, or at least make it depend on the selected C++ standard version only. Functions that cannot be guaranteed to be constexpr because of SIMD variables should not use GLM_CONSTEXPR.

[Groovounet]

This issue should be fixed in master branch for GLM 0.9.9.4 release.

Thanks!

[gsliepen]

Ok, the issue is not fixed, at least not when you compile with std=c++11. It seems overloading the way is done in the lines:

GLM_FUNC_DECL GLM_CONSTEXPR T& operator[](length_type i);
GLM_FUNC_DECL GLM_CONSTEXPR T const& operator[](length_type i) const;

Is invalid in C++11, but valid in C++14. It doesn't matter which compiler you use, it's a language issue. Here's a link to the compiler explorer that shows the issue: https://godbolt.org/z/d9GCdy