diff --git a/modules/geom/src/vec3.hh b/modules/geom/src/vec3.hh
index 47137476eb9aa8c2a9d6286de9da7954a97f269b..6ce79ff3d4365ea4084d31bef23e6d6a7d6f4a94 100644
--- a/modules/geom/src/vec3.hh
+++ b/modules/geom/src/vec3.hh
@@ -73,6 +73,23 @@ public:
   //! explicit initialization with an array of floats
   explicit Vec3(const float v[3]): x(v[0]), y(v[1]), z(v[2]) { }
 
+  /* The "=" operator for Vec3 gives the "maybe-uninitialize" warning in
+     combination with GenericPropValue with GCC when optimisation is turned on.
+     GenericPropValue is implemented via boost::variant which may confuse GCC
+     tracking variables through the compilation process. As boost::variant is
+     able to search for a "=" operator of different type if no direct match is
+     provided, maybe GCC mixes the Real and Vec3 operators where Real used for
+     Vec3 would indeed lack the y and z component. According to the GCC manual,
+     the "maybe-uninitialize" warnings are prone to produce false positives.
+     There is actually an initiative to get rid of them.
+
+     We ignore them for this particular case by saving the current diagnostic
+     settings (push), disabling the warning in the diagnostics
+     (ignored "-Wmaybe-uninitialized") and afterwards restoring the old
+     diagnostics context (pop).
+   */
+  #pragma GCC diagnostic push
+  #pragma GCC diagnostic ignored "-Wmaybe-uninitialized"
   //! assignement op
   Vec3& operator=(const Vec3& v)
   {
@@ -81,7 +98,8 @@ public:
     z=v.z;
     return *this;
   }
-
+  #pragma GCC diagnostic pop
+  
   //! comparable
   bool operator==(const Vec3& rhs) const
   {