GCC 14 warning when reading json

[20162026]

gcc throws maybe-uninitialized warning when read_jmespath is used.

issue only occures when:

• gcc 14 or up is used
• optimisation is set to O2
• glz::opts are set to .error_on_unknown_keys = 0
• glz::opts are set to .error_on_missing_keys = 1 null_terminated=0
• struct has two or more members that start from the same letter (renaming struct member variables fixes the issue????)

In function 'constexpr void glz::visit(auto:42&&, size_t) [with long unsigned int N = 3; auto:42 = detail::parse_and_invoke<glz::opts{10, '\000', '\000', '\000', '\001', '\001', '\000', '\000', ' ', 3, '\001', '\000', '\000', '\001', '\000', '\000', '\000', '\000', 0, glz::float_precision::full, '\000', '\000', '\000', '\000', '\000', '\000', '\001', '\000', '\001', '\001', 0}, test_t, hash_info<test_t>, test_t&, glz::context&, const char*&, const char*&>(test_t&, glz::context&, const char*&, const char*&)::<lambda()>]',
    inlined from 'constexpr void glz::detail::parse_and_invoke(Value&&, auto:506&&, auto:507&&, auto:508&&, SelectedIndex&& ...) [with glz::opts Opts = glz::opts{10, '\000', '\000', '\000', '\001', '\001', '\000', '\000', ' ', 3, '\001', '\000', '\000', '\001', '\000', '\000', '\000', '\000', 0, glz::float_precision::full, '\000', '\000', '\000', '\000', '\000', '\000', '\001', '\000', '\001', '\001', 0}; T = test_t; auto& HashInfo = hash_info<test_t>; Value = test_t&; SelectedIndex = {}; auto:506 = glz::context&; auto:507 = const char*&; auto:508 = const char*&]' at /opt/compiler-explorer/libs/glaze/trunk/include/glaze/json/read.hpp:277:24:
/opt/compiler-explorer/libs/glaze/trunk/include/glaze/util/for_each.hpp:63:35: error: '<anonymous>' may be used uninitialized [-Werror=maybe-uninitialized]
   63 |          (lambda.*mem_ptrs[index])();
      |          ~~~~~~~~~~~~~~~~~~~~~~~~~^~

https://godbolt.org/z/zacecnY71

from the first glance it looks like a false positive but i'm struggling to understand why this is even happening...

[stephenberry]

Thanks for bringing this up and sharing the compiler explorer example. I'm looking into it now.
...REMOVED MISTAKEN COMMENT to not confuse others

[stephenberry]

I added a test case for this in #1562. However, this is passing GCC14, which is confusing to me because it uses -Wall, -Wextra, and -Werror. I would have expected it to fail.

I can understand why GCC might think this line of code is not safe: (lambda.*mem_ptrs[index])();. The index could be out of bounds. But, we always check that the index is less than N, which is the count of function pointers in the array. So, it isn't possible to read out of bounds. And, the '<anonymous>' may be used uninitialized error doesn't make any sense, because the std::array creating function pointers from the <anonymous> lambdas is always instantiated up to N. So, it feels like a GCC bug.

[20162026]

I did not quite understand your remarks regarding the example. You have added test_wrapper_t but didn't use it anywhere and if the structure was wrapped I would not need the read_jmespath in the first place. Or was it only about the ec as return code?

regarding the pipeline, correct me if im wrong but it looks like Werror is only set for Clang and there is no O2 optimization

glaze/tests/CMakeLists.txt

Line 27 in 8c2eb57

target_compile_options(glz_test_common INTERFACE -Wall -Wextra -pedantic $<$<CONFIG:Debug>:-Werror>)

[stephenberry]

regarding the pipeline, correct me if im wrong but it looks like Werror is only set for Clang and there is no O2 optimization

Ah, thanks for pointing that out. I'll add those flags to test GCC.

I did not quite understand your remarks regarding the example...

My bad again. You're right the test_wrapper_t is not needed. I rushed my response. Thanks for the correction.

[stephenberry]

The fact that this bug doesn't exist with O0, O1 or O3, but occurs with O2 makes it seem very much like a compiler issue. I can keep this alive to report it to GCC, but I'm going to be out of pocket for a few weeks before I'm able to do so.

[20162026]

yeah it is most likely gcc bug. I did tinker around with debuger (although not x86) and it makes no sense

[20162026]

it also appears with Os and Oz

[20162026]

https://godbolt.org/z/6TG8YzqTv
warning is also thrown with regular json read of wrapped structure.