From patchwork Fri Oct 28 04:46:52 2016 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Carlos O'Donell X-Patchwork-Id: 16883 Received: (qmail 55582 invoked by alias); 28 Oct 2016 04:48:55 -0000 Mailing-List: contact libc-alpha-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Unsubscribe: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: libc-alpha-owner@sourceware.org Delivered-To: mailing list libc-alpha@sourceware.org Received: (qmail 53795 invoked by uid 89); 28 Oct 2016 04:47:05 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=0.6 required=5.0 tests=AWL, BAYES_00, KAM_LAZY_DOMAIN_SECURITY, RCVD_IN_DNSWL_LOW, RCVD_IN_SORBS_SPAM, UNSUBSCRIBE_BODY autolearn=no version=3.3.2 spammy=indicator, 9307, nameserver X-HELO: mail-qk0-f179.google.com X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:to:from:subject:organization:message-id:date :user-agent:mime-version:content-transfer-encoding; bh=+Hjrs2mexBKKdlFoq2NkYNldHA8JUXL9ju0Et8P1ydM=; b=ZOr2X/jCa1mJHvKAqdDQ5Z5syBga0us14lCLiSxauoQzO7u02PCKzAc72ASusMInJj Jm/+jOkS4Uxbnf+lZkNwvW//nPQjF7RUWT+MGT0wbEZJKNZw3PyM0iSaFXFSLRb5xm45 n8K4vtVI3Yjrv8Y7TF6NP9I+90MaJW3w/68b8/nISFaHDiwput2Ujn4OSNCcLOWCQBv0 PgYx+LWq/LbfTm2N+DugtiQhKC1yzleXZEfNdSC+Xn3tpE/hlP6C9UwzxlK7X1W5Xt0o LLzQ+arVFr2YojWHRZg6LopmpYsymIOuGLyxrvUehK6bplW3hDN6vEJxsSpDVr4XNxoL iZvw== X-Gm-Message-State: ABUngvec84WWVEhOERwpqZ0p7gbOOnd1jEtvCxwvsxkUgtEPdt32X89fTirXnv7hMkpQKArj X-Received: by 10.55.209.90 with SMTP id s87mr8180073qki.99.1477630014394; Thu, 27 Oct 2016 21:46:54 -0700 (PDT) To: GNU C Library , Florian Weimer From: Carlos O'Donell Subject: [PATCH] Fix -Os related -Werror failures. Message-ID: <6eac682f-26fa-6a47-9497-357206266ba1@redhat.com> Date: Fri, 28 Oct 2016 00:46:52 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 While investigating bug 20729 I decided to fix up the -Wmaybe-uninitialized errors caused by building with -Os rather than build with -Wno-error. The comments provide all the details. No regressions on x86_64 and x86 (building with -O2). There are _tons_ of failures building with -Os, but nothing that is novel, lots of linkspace failures because of lack of inlining, and lots of extra PLT references that should not be in the dynamic loader, all things that would need fixing. Is there value in checking in these fixes then to let others work out the -Os failures? 2016-10-27 Carlos O'Donell * iso-2022-cn-ext.c: Include libc-internal.h and ignore -Wmaybe-uninitialized for BODY macro. * locale/weight.h (findix): Ignore -Wmaybe-uninitialized error for seq2.back_us and seq1.back_us. * locale/weightwc.h (findix): Likewise. * nptl_db/thread_dbP.h: Ignore -Wmaybe-uninitialized error for DB_GET_FIELD_ADDRESS. * resolv/res_send (reopen): Ignore -Wmaybe-uninitialized error for slen. * string/strcoll_l.c (get_next_seq): Ignore -Wmaybe-uninitialized for seq2.save_idx and seq1.save_idx. diff --git a/iconvdata/iso-2022-cn-ext.c b/iconvdata/iso-2022-cn-ext.c index df5b5df..6c9fc97 100644 --- a/iconvdata/iso-2022-cn-ext.c +++ b/iconvdata/iso-2022-cn-ext.c @@ -27,6 +27,7 @@ #include "cns11643.h" #include "cns11643l1.h" #include "cns11643l2.h" +#include #include @@ -394,6 +395,16 @@ enum #define MIN_NEEDED_OUTPUT TO_LOOP_MIN_NEEDED_TO #define MAX_NEEDED_OUTPUT TO_LOOP_MAX_NEEDED_TO #define LOOPFCT TO_LOOP +/* With GCC 5.3 when compiling with -Os the compiler emits a warning + that buf[0] and buf[1] may be used uninitialized. This can only + happen in the case where tmpbuf[3] is used, and in that case the + write to the tmpbuf[1] and tmpbuf[2] was assured because + ucs4_to_cns11643 would have filled in those entries. The difficulty + is in getting the compiler to see this logic because tmpbuf[0] is + involved in determining the code page and is the indicator that + tmpbuf[2] is initialized. */ +DIAG_PUSH_NEEDS_COMMENT; +DIAG_IGNORE_NEEDS_COMMENT (5.3, "-Wmaybe-uninitialized"); #define BODY \ { \ uint32_t ch; \ @@ -645,6 +656,7 @@ enum /* Now that we wrote the output increment the input pointer. */ \ inptr += 4; \ } +DIAG_POP_NEEDS_COMMENT; #define EXTRA_LOOP_DECLS , int *setp #define INIT_PARAMS int set = (*setp >> 3) & CURRENT_MASK; \ int ann = (*setp >> 3) & ~CURRENT_MASK diff --git a/locale/weight.h b/locale/weight.h index c99730c..4c35313 100644 --- a/locale/weight.h +++ b/locale/weight.h @@ -61,9 +61,17 @@ findidx (const int32_t *table, already. */ size_t cnt; + /* With GCC 5.3 when compiling with -Os the compiler warns + that seq2.back_us, which becomes usrc, might be used + uninitialized. This can't be true because we pass a length + of -1 for len at the same time which means that this loop + never executes. */ + DIAG_PUSH_NEEDS_COMMENT; + DIAG_IGNORE_NEEDS_COMMENT (5.3, "-Wmaybe-uninitialized"); for (cnt = 0; cnt < nhere && cnt < len; ++cnt) if (cp[cnt] != usrc[cnt]) break; + DIAG_POP_NEEDS_COMMENT; if (cnt == nhere) { diff --git a/locale/weightwc.h b/locale/weightwc.h index ab26482..5dcfb2e 100644 --- a/locale/weightwc.h +++ b/locale/weightwc.h @@ -59,9 +59,17 @@ findidx (const int32_t *table, already. */ size_t cnt; + /* With GCC 5.3 when compiling with -Os the compiler warns + that seq2.back_us, which becomes usrc, might be used + uninitialized. This can't be true because we pass a length + of -1 for len at the same time which means that this loop + never executes. */ + DIAG_PUSH_NEEDS_COMMENT; + DIAG_IGNORE_NEEDS_COMMENT (5.3, "-Wmaybe-uninitialized"); for (cnt = 0; cnt < nhere && cnt < len; ++cnt) if (cp[cnt] != usrc[cnt]) break; + DIAG_POP_NEEDS_COMMENT; if (cnt == nhere) { diff --git a/nptl_db/thread_dbP.h b/nptl_db/thread_dbP.h index 39c3061..116a546 100644 --- a/nptl_db/thread_dbP.h +++ b/nptl_db/thread_dbP.h @@ -160,10 +160,19 @@ extern ps_err_e td_mod_lookup (struct ps_prochandle *ps, const char *modname, SYM_##type##_FIELD_##field, \ (psaddr_t) 0 + (idx), (ptr), &(var)) +/* With GCC 5.3 when compiling with -Os the compiler emits a warning + that slot may be used uninitialized. This is never the case since + the dynamic loader initializes the slotinfo list and + dtv_slotinfo_list will point slot at the first entry. Therefore + when DB_GET_FIELD_ADDRESS is called with a slot for ptr, the slot is + always initialized. */ +DIAG_PUSH_NEEDS_COMMENT; +DIAG_IGNORE_NEEDS_COMMENT (5.3, "-Wmaybe-uninitialized"); #define DB_GET_FIELD_ADDRESS(var, ta, ptr, type, field, idx) \ ((var) = (ptr), _td_locate_field ((ta), (ta)->ta_field_##type##_##field, \ SYM_##type##_FIELD_##field, \ (psaddr_t) 0 + (idx), &(var))) +DIAG_POP_NEEDS_COMMENT; extern td_err_e _td_locate_field (td_thragent_t *ta, db_desc_t desc, int descriptor_name, diff --git a/resolv/res_send.c b/resolv/res_send.c index 6d46bb2..19a4c1f 100644 --- a/resolv/res_send.c +++ b/resolv/res_send.c @@ -930,7 +930,16 @@ reopen (res_state statp, int *terrno, int ns) * error message is received. We can thus detect * the absence of a nameserver without timing out. */ + /* With GCC 5.3 when compiling with -Os the compiler + emits a warning that slen may be used uninitialized, + but that is never true. Both slen and + EXT(statp).nssocks[ns] are initialized together or the + function return -1 before control flow reaches the + call to connect with slen. */ + DIAG_PUSH_NEEDS_COMMENT; + DIAG_IGNORE_NEEDS_COMMENT (5.3, "-Wmaybe-uninitialized"); if (connect(EXT(statp).nssocks[ns], nsap, slen) < 0) { + DIAG_POP_NEEDS_COMMENT; Aerror(statp, stderr, "connect(dg)", errno, nsap); __res_iclose(statp, false); return (0); diff --git a/string/strcoll_l.c b/string/strcoll_l.c index 4d1e3ab..8e689ba 100644 --- a/string/strcoll_l.c +++ b/string/strcoll_l.c @@ -24,6 +24,7 @@ #include #include #include +#include #ifndef STRING_TYPE # define STRING_TYPE char @@ -170,7 +171,19 @@ get_next_seq (coll_seq *seq, int nrules, const unsigned char *rulesets, } } + /* With GCC 5.3 when compiling with -Os the compiler complains + that idx, taken from seq->idx (seq1 or seq2 from STRCOLL) may + be used uninitialized. In general this can't possibly be true + since seq1.idx and seq2.idx are initialized to zero in the + outer function. Only one case where seq->idx is restored from + seq->save_idx might result in an uninitialized idx value, but + it is guarded by a sequence of checks against backw_stop which + ensures that seq->save_idx was saved to first and contains a + valid value. */ + DIAG_PUSH_NEEDS_COMMENT; + DIAG_IGNORE_NEEDS_COMMENT (5.3, "-Wmaybe-uninitialized"); len = weights[idx++]; + DIAG_POP_NEEDS_COMMENT; /* Skip over indices of previous levels. */ for (int i = 0; i < pass; i++) {