workaround gcc compiler bug
There is a regression in gcc since version 12.0 to at least 12.2.1 that
causes gcc to emit incorrect machine code.
Code like
std::optional<int> o1;
try {
o1 = foo(); // foo can throw
} catch(...) {
process(o1);
}
std::optional<double> o2{o1};
bar(o2);
may trigger -Wmaybe-uninitialized with -O2 optimization and the call
process(o1) results in the store for variable o1 removed which makes
the valgrind report uninitialized values (see [1]).
Interestingly, we can work around the bug by setting both std::optional
to contain the same type. I prefer altering our code a bit so our code
is compiled correctly by even by gcc versions that contain this
unfortunate regression.
Thanks Petr Gotthard for discovering the possible crash in our code.
[1] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109434
Bug: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109434
Change-Id: I29d73533b8a8550aeb7f6f0b92b5287021a4f193
Signed-off-by: Jan Kundrát <jan.kundrat@cesnet.cz>
diff --git a/src/yang_schema.cpp b/src/yang_schema.cpp
index 1dc05db..6370d3b 100644
--- a/src/yang_schema.cpp
+++ b/src/yang_schema.cpp
@@ -253,7 +253,8 @@
" is not supported: " +
std::to_string(std::underlying_type_t<libyang::LeafBaseType>(leaf->valueType().base())));
}
- std::optional<std::string_view> typeDesc;
+ // note https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109434
+ std::optional<std::string> typeDesc;
try {
typeDesc = type.description();
@@ -261,7 +262,7 @@
// libyang context doesn't have the parsed info.
}
- return yang::TypeInfo(resType, std::optional<std::string>{leafUnits}, std::optional<std::string>{typeDesc});
+ return yang::TypeInfo(resType, std::optional<std::string>{leafUnits}, typeDesc);
};
return resolveType(leaf->valueType());
}