We see some surprising warnings on tilegx with gcc 4.8.2:
In file included from regex.c:66:0:
regcomp.c: In function ‘parse_expression’:
regcomp.c:2849:15: error: ‘end_elem’ may be used uninitialized in this
function [-Werror=maybe-uninitialized]
else if (br_elem->type == COLL_SYM)
^
regcomp.c:3109:34: note: ‘end_elem’ was declared here
bracket_elem_t start_elem, end_elem;
^
regcomp.c:3109:22: error: ‘start_elem’ may be used uninitialized in
this function [-Werror=maybe-uninitialized]
bracket_elem_t start_elem, end_elem;
^
These warnings are not seen on x86, and in fact if I compile the
preprocessed tile sources with the x86 gcc 4.8.2, I don't see the
warnings. I do see eqiuvalent warnings if I compile the
x86-preprocessed source code with tilegx gcc 4.8.2.
The fix here is to initialize the union type field appropriately in
a couple of places where we pass a union pointer to a subroutine that
"knows" what type the union is. Setting the type explicitly seems like
a more robust way to manage such a data structure in any case.
+2015-01-07 Chris Metcalf <cmetcalf@ezchip.com>
+
+ * posix/regcomp.c (parse_bracket_exp): Initialize type to
+ COLL_SYM in a couple of places to avoid uninitialized variable
+ wanings on tilegx gcc 4.8.2.
+
2015-01-07 Richard Earnshaw <rearnsha@arm.com>
* sysdeps/aarch64/strcpy.S: New file.
re_token_t token2;
start_elem.opr.name = start_name_buf;
+ start_elem.type = COLL_SYM;
ret = parse_bracket_element (&start_elem, regexp, token, token_len, dfa,
syntax, first_round);
if (BE (ret != REG_NOERROR, 0))
if (is_range_exp == 1)
{
end_elem.opr.name = end_name_buf;
+ end_elem.type = COLL_SYM;
ret = parse_bracket_element (&end_elem, regexp, &token2, token_len2,
dfa, syntax, 1);
if (BE (ret != REG_NOERROR, 0))