[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CALCETrXP+Rz8wi_N2G7WLwnGuFMC8zeo5o+jgGmvpZkndrM+2Q@mail.gmail.com>
Date: Fri, 18 Jul 2014 13:08:51 -0700
From: Andy Lutomirski <luto@...capital.net>
To: "H. Peter Anvin" <hpa@...or.com>
Cc: Stephen Rothwell <sfr@...b.auug.org.au>,
Thomas Gleixner <tglx@...utronix.de>,
Ingo Molnar <mingo@...e.hu>,
Peter Zijlstra <peterz@...radead.org>,
"linux-next@...r.kernel.org" <linux-next@...r.kernel.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
Linus Torvalds <torvalds@...ux-foundation.org>
Subject: Re: linux-next: build warning after merge of the tip tree
On Fri, Jul 18, 2014 at 1:05 PM, H. Peter Anvin <hpa@...or.com> wrote:
> On 07/18/2014 12:57 PM, Andy Lutomirski wrote:
>>
>> This particular warning is IMO in a particularly dumb category: GCC
>> optimizes some code and then warns about a construct that wasn't there
>> in the original code. In this case, I think it unrolled a loop and
>> discovered that one iteration contained a test that was always true.
>> Big deal.
>>
>> (OTOH, the code in question was buggy, but not all for the reason that
>> GCC thought it was.)
>>
>
> if (syms[sym_vvar_start] > syms[i] + 4096)
> fail("%s underruns begin_vvar\n",
> required_syms[i].name);
>
> if i == sym_vvar_start then this is at least a valid warning. It could
> easily be quieted by chaning syms[] to an unsigned array.
Hah -- fooled you, too :)
i isn't an index in to the syms array at all. This code is completely
wrong. See the patch I sent in reply to Stephen's original email.
But, to your earlier point, presumably this could warn:
for (int i = 0; i < 10; i++)
if (array[i] > array[5] + 1)
fail();
I think that's absurd. There's nothing wrong with that code. A given
test should have to be always true or always false on *all* loop
iterations to be flagged, I think.
--Andy
>
> -hpa
>
--
Andy Lutomirski
AMA Capital Management, LLC
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists