[v4] Fix -Os related build and test failures.
Commit Message
On 10/29/2016 01:35 PM, Joseph Myers wrote:
> On Sat, 29 Oct 2016, Carlos O'Donell wrote:
>
>> +#if __OPTIMIZE_SIZE__
>> +#define DIAG_IGNORE_Os_NEEDS_COMMENT(version, option) \
>> + _Pragma (_DIAG_STR (GCC diagnostic ignored option))
>> +#else
>> +#define DIAG_IGNORE_Os_NEEDS_COMMENT(version, option)
>> +#endif
>
> That should have "# define" preprocessor indentation inside #if.
Fixed.
I've committed the following after testing on i486 -Os and
x86_64 -O2.
v4
- Correct preprocessor indentation.
2016-10-28 Carlos O'Donell <carlos@redhat.com>
[BZ #20729]
* include/libc-internal.h (DIAG_IGNORE_Os_NEEDS_COMMENT):
Define.
* iso-2022-cn-ext.c: Include libc-internal.h and ignore
-Wmaybe-uninitialized for BODY macro only for -Os compiles.
* locale/weight.h (findix): Ignore -Wmaybe-uninitialized error
for seq2.back_us and seq1.back_us only for -Os compiles.
* locale/weightwc.h (findix): Likewise.
* nptl_db/thread_dbP.h: Ignore -Wmaybe-uninitialized error for
DB_GET_FIELD_ADDRESS only for -Os compiles.
* resolv/res_send (reopen): Ignore -Wmaybe-uninitialized error
for slen only for -Os compiles.
* string/strcoll_l.c (get_next_seq): Ignore
-Wmaybe-uninitialized for seq2.save_idx and seq1.save_idx only
for -Os compiles.
---
Comments
https://build.opensuse.org/project/monitor/home:Andreas_Schwab:glibc
In file included from strxfrm_l.c:48:0:
../locale/weight.h: In function ‘findidx’:
../locale/weight.h:69:4: error: ‘DIAG_PUSH_NEEDS_COMMENT’ undeclared (first use in this function)
DIAG_PUSH_NEEDS_COMMENT;
^~~~~~~~~~~~~~~~~~~~~~~
../locale/weight.h:69:4: note: each undeclared identifier is reported only once for each function it appears in
../locale/weight.h:70:4: error: implicit declaration of function ‘DIAG_IGNORE_Os_NEEDS_COMMENT’ [-Werror=implicit-function-declaration]
DIAG_IGNORE_Os_NEEDS_COMMENT (5, "-Wmaybe-uninitialized");
^~~~~~~~~~~~~~~~~~~~~~~~~~~~
../locale/weight.h:74:4: error: ‘DIAG_POP_NEEDS_COMMENT’ undeclared (first use in this function)
DIAG_POP_NEEDS_COMMENT;
^~~~~~~~~~~~~~~~~~~~~~
Andreas.
On 10/31/2016 04:33 AM, Andreas Schwab wrote:
> https://build.opensuse.org/project/monitor/home:Andreas_Schwab:glibc
>
> In file included from strxfrm_l.c:48:0:
> ../locale/weight.h: In function ‘findidx’:
> ../locale/weight.h:69:4: error: ‘DIAG_PUSH_NEEDS_COMMENT’ undeclared (first use in this function)
> DIAG_PUSH_NEEDS_COMMENT;
> ^~~~~~~~~~~~~~~~~~~~~~~
> ../locale/weight.h:69:4: note: each undeclared identifier is reported only once for each function it appears in
> ../locale/weight.h:70:4: error: implicit declaration of function ‘DIAG_IGNORE_Os_NEEDS_COMMENT’ [-Werror=implicit-function-declaration]
> DIAG_IGNORE_Os_NEEDS_COMMENT (5, "-Wmaybe-uninitialized");
> ^~~~~~~~~~~~~~~~~~~~~~~~~~~~
> ../locale/weight.h:74:4: error: ‘DIAG_POP_NEEDS_COMMENT’ undeclared (first use in this function)
> DIAG_POP_NEEDS_COMMENT;
> ^~~~~~~~~~~~~~~~~~~~~~
I'm fixing this. I don't know why this didn't fail on my x86_64 build.
I'm moving the #include <libc-internal.h> into the weight header fragments.
Cheers,
Carlos.
On 10/31/2016 10:16 AM, Carlos O'Donell wrote:
> I'm fixing this. I don't know why this didn't fail on my x86_64 build.
x86_64 includes <libc-internal.h> by default because the
platform-specific headers need the cast_to_integer macro.
Florian
From: Carlos O'Donell <carlos@redhat.com>
Date: Mon, 31 Oct 2016 05:16:29 -0400
> On 10/31/2016 04:33 AM, Andreas Schwab wrote:
>> https://build.opensuse.org/project/monitor/home:Andreas_Schwab:glibc
>>
>> In file included from strxfrm_l.c:48:0:
>> ../locale/weight.h: In function ‘findidx’:
>> ../locale/weight.h:69:4: error: ‘DIAG_PUSH_NEEDS_COMMENT’ undeclared (first use in this function)
>> DIAG_PUSH_NEEDS_COMMENT;
>> ^~~~~~~~~~~~~~~~~~~~~~~
>> ../locale/weight.h:69:4: note: each undeclared identifier is reported only once for each function it appears in
>> ../locale/weight.h:70:4: error: implicit declaration of function ‘DIAG_IGNORE_Os_NEEDS_COMMENT’ [-Werror=implicit-function-declaration]
>> DIAG_IGNORE_Os_NEEDS_COMMENT (5, "-Wmaybe-uninitialized");
>> ^~~~~~~~~~~~~~~~~~~~~~~~~~~~
>> ../locale/weight.h:74:4: error: ‘DIAG_POP_NEEDS_COMMENT’ undeclared (first use in this function)
>> DIAG_POP_NEEDS_COMMENT;
>> ^~~~~~~~~~~~~~~~~~~~~~
>
> I'm fixing this. I don't know why this didn't fail on my x86_64 build.
>
> I'm moving the #include <libc-internal.h> into the weight header fragments.
The thread debugging header nptl_db/thread_dbP.h needs it too.
On 10/31/2016 08:55 AM, David Miller wrote:
> From: Carlos O'Donell <carlos@redhat.com>
> Date: Mon, 31 Oct 2016 05:16:29 -0400
>
>> On 10/31/2016 04:33 AM, Andreas Schwab wrote:
>>> https://build.opensuse.org/project/monitor/home:Andreas_Schwab:glibc
>>>
>>> In file included from strxfrm_l.c:48:0:
>>> ../locale/weight.h: In function ‘findidx’:
>>> ../locale/weight.h:69:4: error: ‘DIAG_PUSH_NEEDS_COMMENT’ undeclared (first use in this function)
>>> DIAG_PUSH_NEEDS_COMMENT;
>>> ^~~~~~~~~~~~~~~~~~~~~~~
>>> ../locale/weight.h:69:4: note: each undeclared identifier is reported only once for each function it appears in
>>> ../locale/weight.h:70:4: error: implicit declaration of function ‘DIAG_IGNORE_Os_NEEDS_COMMENT’ [-Werror=implicit-function-declaration]
>>> DIAG_IGNORE_Os_NEEDS_COMMENT (5, "-Wmaybe-uninitialized");
>>> ^~~~~~~~~~~~~~~~~~~~~~~~~~~~
>>> ../locale/weight.h:74:4: error: ‘DIAG_POP_NEEDS_COMMENT’ undeclared (first use in this function)
>>> DIAG_POP_NEEDS_COMMENT;
>>> ^~~~~~~~~~~~~~~~~~~~~~
>>
>> I'm fixing this. I don't know why this didn't fail on my x86_64 build.
>>
>> I'm moving the #include <libc-internal.h> into the weight header fragments.
>
> The thread debugging header nptl_db/thread_dbP.h needs it too.
Yes. I'm fixing any file to include the header as required.
I was too clever in thinking I could elide it for header
fragments included in other source files, I should have just
followed the rules we had in place "if it needs it it should
include it" since that fixed the messes we previously had.
I'm going to setup a non-x86_64 cross-build to test this.
I think I can do it easily enough on Fedora so I can keep
it up to date for upstream builds.
Cheers,
Carlos.
On Okt 30 2016, Carlos O'Donell <carlos@redhat.com> wrote:
> diff --git a/resolv/res_send.c b/resolv/res_send.c
> index 6d46bb2..4ec8c1a 100644
> --- a/resolv/res_send.c
> +++ b/resolv/res_send.c
> @@ -664,7 +664,7 @@ send_vc(res_state statp,
> a false-positive.
> */
> DIAG_PUSH_NEEDS_COMMENT;
> - DIAG_IGNORE_NEEDS_COMMENT (5, "-Wmaybe-uninitialized");
> + DIAG_IGNORE_Os_NEEDS_COMMENT (5, "-Wmaybe-uninitialized");
> int resplen;
> DIAG_POP_NEEDS_COMMENT;
> struct iovec iov[4];
That breaks powerpc and s390.
res_send.c: In function 'send_vc':
res_send.c:668:6: error: 'resplen' may be used uninitialized in this function [-Werror=maybe-uninitialized]
int resplen;
^~~~~~~
Andreas.
On Tue, 1 Nov 2016, Andreas Schwab wrote:
> On Okt 30 2016, Carlos O'Donell <carlos@redhat.com> wrote:
>
> > diff --git a/resolv/res_send.c b/resolv/res_send.c
> > index 6d46bb2..4ec8c1a 100644
> > --- a/resolv/res_send.c
> > +++ b/resolv/res_send.c
> > @@ -664,7 +664,7 @@ send_vc(res_state statp,
> > a false-positive.
> > */
> > DIAG_PUSH_NEEDS_COMMENT;
> > - DIAG_IGNORE_NEEDS_COMMENT (5, "-Wmaybe-uninitialized");
> > + DIAG_IGNORE_Os_NEEDS_COMMENT (5, "-Wmaybe-uninitialized");
> > int resplen;
> > DIAG_POP_NEEDS_COMMENT;
> > struct iovec iov[4];
>
> That breaks powerpc and s390.
>
> res_send.c: In function 'send_vc':
> res_send.c:668:6: error: 'resplen' may be used uninitialized in this function [-Werror=maybe-uninitialized]
> int resplen;
> ^~~~~~~
And the other change to the same file introduces a new use of
DIAG_IGNORE_NEEDS_COMMENT with a comment that only mentions -Os. Was the
intent to edit the latter use to be DIAG_IGNORE_Os_NEEDS_COMMENT, with the
former one edited by mistake instead?
This also breaks ARM and AArch64,
Would it be worth reverting the commit until this is fixed?
It's currently blocking trunk builds.
Kind Regards,
Tamar
> -----Original Message-----
> From: libc-alpha-owner@sourceware.org [mailto:libc-alpha-
> owner@sourceware.org] On Behalf Of Joseph Myers
> Sent: 01 November 2016 11:13
> To: Andreas Schwab
> Cc: Carlos O'Donell; Florian Weimer; GNU C Library
> Subject: Re: [PATCH v4] Fix -Os related build and test failures.
>
> On Tue, 1 Nov 2016, Andreas Schwab wrote:
>
> > On Okt 30 2016, Carlos O'Donell <carlos@redhat.com> wrote:
> >
> > > diff --git a/resolv/res_send.c b/resolv/res_send.c index
> > > 6d46bb2..4ec8c1a 100644
> > > --- a/resolv/res_send.c
> > > +++ b/resolv/res_send.c
> > > @@ -664,7 +664,7 @@ send_vc(res_state statp,
> > > a false-positive.
> > > */
> > > DIAG_PUSH_NEEDS_COMMENT;
> > > - DIAG_IGNORE_NEEDS_COMMENT (5, "-Wmaybe-uninitialized");
> > > + DIAG_IGNORE_Os_NEEDS_COMMENT (5, "-Wmaybe-uninitialized");
> > > int resplen;
> > > DIAG_POP_NEEDS_COMMENT;
> > > struct iovec iov[4];
> >
> > That breaks powerpc and s390.
> >
> > res_send.c: In function 'send_vc':
> > res_send.c:668:6: error: 'resplen' may be used uninitialized in this function
> [-Werror=maybe-uninitialized]
> > int resplen;
> > ^~~~~~~
>
> And the other change to the same file introduces a new use of
> DIAG_IGNORE_NEEDS_COMMENT with a comment that only mentions -Os.
> Was the intent to edit the latter use to be
> DIAG_IGNORE_Os_NEEDS_COMMENT, with the former one edited by
> mistake instead?
>
> --
> Joseph S. Myers
> joseph@codesourcery.com
From: Tamar Christina <Tamar.Christina@arm.com>
Date: Tue, 1 Nov 2016 15:58:20 +0000
> This also breaks ARM and AArch64,
>
> Would it be worth reverting the commit until this is fixed?
> It's currently blocking trunk builds.
Mainline has been fixed already.
Ah, OK. Hadn't noticed.
Thanks!
> -----Original Message-----
> From: David Miller [mailto:davem@davemloft.net]
> Sent: 01 November 2016 16:06
> To: Tamar Christina
> Cc: joseph@codesourcery.com; schwab@linux-m68k.org;
> carlos@redhat.com; fweimer@redhat.com; libc-alpha@sourceware.org; nd;
> Bin Cheng
> Subject: Re: [PATCH v4] Fix -Os related build and test failures.
>
> From: Tamar Christina <Tamar.Christina@arm.com>
> Date: Tue, 1 Nov 2016 15:58:20 +0000
>
> > This also breaks ARM and AArch64,
> >
> > Would it be worth reverting the commit until this is fixed?
> > It's currently blocking trunk builds.
>
> Mainline has been fixed already.
On Mon, 31 Oct 2016, Carlos O'Donell wrote:
> I'm going to setup a non-x86_64 cross-build to test this.
> I think I can do it easily enough on Fedora so I can keep
> it up to date for upstream builds.
FYI: I'm writing a script to run glibc builds (and the part of the tests
that don't involve running host code), including building the cross
compilers, for lots of configurations (a rough sort of equivalent to GCC's
contrib/config-list.mk). I think such a script would be useful to have in
glibc, though it would take to long to use for testing most patches (it
should aim to cover all ABI variants in
<https://sourceware.org/glibc/wiki/ABIList> and enough other variants e.g.
for CPUs using different sysdeps directories to test building each piece
of code in glibc at least once) - but it might be useful to have a bot
running it continuously and watching for regressions.
On 11/01/2016 12:06 PM, David Miller wrote:
> From: Tamar Christina <Tamar.Christina@arm.com>
> Date: Tue, 1 Nov 2016 15:58:20 +0000
>
>> This also breaks ARM and AArch64,
>>
>> Would it be worth reverting the commit until this is fixed?
>> It's currently blocking trunk builds.
>
> Mainline has been fixed already.
No, there is one more issue left. My automated cleanup script
turned one of the DIAG's into an -Os diag by error. Joseph
noticed this and I'll fix it right now.
I'm going to push out a Fedora Rawhide build to verify this
for: arm, aarch64, ppc64le, ppc64, s390, s390x, x86, and
x86_64.
Cheers,
Carlos.
On 11/01/2016 06:58 PM, Joseph Myers wrote:
> On Mon, 31 Oct 2016, Carlos O'Donell wrote:
>
>> I'm going to setup a non-x86_64 cross-build to test this.
>> I think I can do it easily enough on Fedora so I can keep
>> it up to date for upstream builds.
>
> FYI: I'm writing a script to run glibc builds (and the part of the tests
> that don't involve running host code), including building the cross
> compilers, for lots of configurations (a rough sort of equivalent to GCC's
> contrib/config-list.mk). I think such a script would be useful to have in
> glibc, though it would take to long to use for testing most patches (it
> should aim to cover all ABI variants in
> <https://sourceware.org/glibc/wiki/ABIList> and enough other variants e.g.
> for CPUs using different sysdeps directories to test building each piece
> of code in glibc at least once) - but it might be useful to have a bot
> running it continuously and watching for regressions.
That would be excellent. Please publish the script so that others can use it.
I have a similar script, but not yet setup for cross-compiles.
Cheers,
Carlos.
On 11/01/2016 07:12 AM, Joseph Myers wrote:
> On Tue, 1 Nov 2016, Andreas Schwab wrote:
>
>> On Okt 30 2016, Carlos O'Donell <carlos@redhat.com> wrote:
>>
>>> diff --git a/resolv/res_send.c b/resolv/res_send.c
>>> index 6d46bb2..4ec8c1a 100644
>>> --- a/resolv/res_send.c
>>> +++ b/resolv/res_send.c
>>> @@ -664,7 +664,7 @@ send_vc(res_state statp,
>>> a false-positive.
>>> */
>>> DIAG_PUSH_NEEDS_COMMENT;
>>> - DIAG_IGNORE_NEEDS_COMMENT (5, "-Wmaybe-uninitialized");
>>> + DIAG_IGNORE_Os_NEEDS_COMMENT (5, "-Wmaybe-uninitialized");
>>> int resplen;
>>> DIAG_POP_NEEDS_COMMENT;
>>> struct iovec iov[4];
>>
>> That breaks powerpc and s390.
>>
>> res_send.c: In function 'send_vc':
>> res_send.c:668:6: error: 'resplen' may be used uninitialized in this function [-Werror=maybe-uninitialized]
>> int resplen;
>> ^~~~~~~
>
> And the other change to the same file introduces a new use of
> DIAG_IGNORE_NEEDS_COMMENT with a comment that only mentions -Os. Was the
> intent to edit the latter use to be DIAG_IGNORE_Os_NEEDS_COMMENT, with the
> former one edited by mistake instead?
It was indeed a mistake. I used a script to find and fix the uses I'd added,
but here I made a mistake.
I'm running a rawhide build check here to verify the fix fixes things for
x86, x86_64, aarch64, arm, ppc64, ppc64le, and s390.
Cheers,
Carlos.
@@ -27,6 +27,7 @@
#include "cns11643.h"
#include "cns11643l1.h"
#include "cns11643l2.h"
+#include <libc-internal.h>
#include <assert.h>
@@ -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_Os_NEEDS_COMMENT (5, "-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
@@ -111,4 +111,19 @@ extern __typeof (__profile_frequency) __profile_frequency attribute_hidden;
#define DIAG_IGNORE_NEEDS_COMMENT(version, option) \
_Pragma (_DIAG_STR (GCC diagnostic ignored option))
+/* Similar to DIAG_IGNORE_NEEDS_COMMENT the following macro ignores the
+ diagnostic OPTION but only if optimizations for size are enabled.
+ This is required because different warnings may be generated for
+ different optimization levels. For example a key piece of code may
+ only generate a warning when compiled at -Os, but at -O2 you could
+ still want the warning to be enabled to catch errors. In this case
+ you would use DIAG_IGNORE_Os_NEEDS_COMMENT to disable the warning
+ only for -Os. */
+#ifdef __OPTIMIZE_SIZE__
+# define DIAG_IGNORE_Os_NEEDS_COMMENT(version, option) \
+ _Pragma (_DIAG_STR (GCC diagnostic ignored option))
+#else
+# define DIAG_IGNORE_Os_NEEDS_COMMENT(version, option)
+#endif
+
#endif /* _LIBC_INTERNAL */
@@ -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_Os_NEEDS_COMMENT (5, "-Wmaybe-uninitialized");
for (cnt = 0; cnt < nhere && cnt < len; ++cnt)
if (cp[cnt] != usrc[cnt])
break;
+ DIAG_POP_NEEDS_COMMENT;
if (cnt == nhere)
{
@@ -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_Os_NEEDS_COMMENT (5, "-Wmaybe-uninitialized");
for (cnt = 0; cnt < nhere && cnt < len; ++cnt)
if (cp[cnt] != usrc[cnt])
break;
+ DIAG_POP_NEEDS_COMMENT;
if (cnt == nhere)
{
@@ -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_Os_NEEDS_COMMENT (5, "-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,
@@ -664,7 +664,7 @@ send_vc(res_state statp,
a false-positive.
*/
DIAG_PUSH_NEEDS_COMMENT;
- DIAG_IGNORE_NEEDS_COMMENT (5, "-Wmaybe-uninitialized");
+ DIAG_IGNORE_Os_NEEDS_COMMENT (5, "-Wmaybe-uninitialized");
int resplen;
DIAG_POP_NEEDS_COMMENT;
struct iovec iov[4];
@@ -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, "-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);
@@ -24,6 +24,7 @@
#include <stdint.h>
#include <string.h>
#include <sys/param.h>
+#include <libc-internal.h>
#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_Os_NEEDS_COMMENT (5, "-Wmaybe-uninitialized");
len = weights[idx++];
+ DIAG_POP_NEEDS_COMMENT;
/* Skip over indices of previous levels. */
for (int i = 0; i < pass; i++)
{