aboutsummaryrefslogtreecommitdiff
path: root/include/string.h
diff options
context:
space:
mode:
authorJoseph Myers <joseph@codesourcery.com>2016-11-11 21:05:51 +0000
committerJoseph Myers <joseph@codesourcery.com>2016-11-11 21:05:51 +0000
commit84c426b85db7cc595f8c5d3ec549009490ca6299 (patch)
tree4146d1dca9a07de4913cff8af602c15ed78e8b20 /include/string.h
parent8129bf7732decf4472caf8b1c339e4abd072f0ab (diff)
downloadglibc-84c426b85db7cc595f8c5d3ec549009490ca6299.zip
glibc-84c426b85db7cc595f8c5d3ec549009490ca6299.tar.gz
glibc-84c426b85db7cc595f8c5d3ec549009490ca6299.tar.bz2
Ignore -Wmaybe-uninitialized in stdlib/bug-getcontext.c.
Doing all-ABIs compile testing produces a compiler warning in stdlib/bug-getcontext.c on nios2 and tilepro (with GCC 5 branch): bug-getcontext.c: In function 'do_test': bug-getcontext.c:53:6: error: 'except_mask' may be used uninitialized in this function [-Werror=maybe-uninitialized] if (mask != except_mask) ^ This warning appears nonsensical; except_mask is initialized where it's declared. I think what must be happening here is that the compiler is confused by the returns-twice nature of getcontext: if there were a call to setcontext, local variables could indeed have lost their values on the second return from getcontext. This patch duly uses the DIAG_* macros to disable the warning here. Tested for nios2 and tilepro (compilation only; after this patch all the tests compile, though there are other failures) and x86_64 (full testsuite run). * stdlib/bug-getcontext.c: Include <libc-internal.h>. (do_test): Disable -Wmaybe-uninitialized around uses of except_mask.
Diffstat (limited to 'include/string.h')
0 files changed, 0 insertions, 0 deletions