René Scharfe writes:
> Am 24.03.2013 05:55, schrieb Junio C Hamano:
>> So I like your change for readability, but for GCC 4.4.5 we still
>> need the unnecessary initialization.
>
> Hrm, perhaps we can make it even simpler for the compiler.
And the result is even simpler for human readers, I'd ha
Am 24.03.2013 05:55, schrieb Junio C Hamano:
> However, the same compiler still thinks {elem,path,mode}1 can be
> used uninitialized (but not {elem,path,mode}2). The craziness I
> reported in the previous message is also the same. With this patch
> on top to swap the side we inspect first, the co
On Sat, Mar 23, 2013 at 09:55:53PM -0700, Junio C Hamano wrote:
> René Scharfe writes:
>
> > Hmm, let's see if we can help the compiler follow the code without
> > making it harder for people to understand. The patch looks a bit
> > jumbled, but the resulting code is OK in my biased opinion.
>
René Scharfe writes:
> Hmm, let's see if we can help the compiler follow the code without
> making it harder for people to understand. The patch looks a bit
> jumbled, but the resulting code is OK in my biased opinion.
I actually think the result is much better than a mere "OK"; the
duplicated
Am 22.03.2013 17:21, schrieb Jeff King:
> Of the 8 patches, this is the one I find the least satisfying, if only
> because I do not think gcc's failure is because of complicated control
> flow, and rearranging the code would only hurt readability.
Hmm, let's see if we can help the compiler follow
On Fri, Mar 22, 2013 at 02:33:16PM -0700, Junio C Hamano wrote:
> Junio C Hamano writes:
>
> > These three are all updated by the same tree_entry_extract() call,
> > and whenever we use mode[12] we use path[12], so if it decides path1
> > is used or assigned, it should be able to tell mode1 is,
Junio C Hamano writes:
> These three are all updated by the same tree_entry_extract() call,
> and whenever we use mode[12] we use path[12], so if it decides path1
> is used or assigned, it should be able to tell mode1 is, too.
>
> Unsatisfactory, it surely is...
And immediately after I wrote the
Jeff King writes:
> Of the 8 patches, this is the one I find the least satisfying, if only
> because I do not think gcc's failure is because of complicated control
> flow, and rearranging the code would only hurt readability. And I'm
> quite curious why it complains about "mode", but not about th
These nonsense assignments are meant to squelch gcc warnings
that the variables might be used uninitialized. However, gcc
gets it mostly right, realizing that we will either
extract tree entries from both sides, or we will hit a
"continue" statement and go to the top of the loop.
However, while ge
9 matches
Mail list logo
