Re: What's cooking in git.git (Feb 2016, #07; Thu, 25)

From: Jeff King <peff@peff.net>
Date: Feb 27, 2016, 03:29 UTC
Message-ID: <20160227032907.GB10313@sigill.intra.peff.net>
In-Reply-To: <xmqqtwkvhwpd.fsf@gitster.mtv.corp.google.com>

On Fri, Feb 26, 2016 at 03:35:10PM -0800, Junio C Hamano wrote:

Show 15 quoted lines

> > Digging means:
> > run git bisect and report the commit.
> > And this makes the compiler happy:
> >   Revert "tree-diff: catch integer overflow in combine_diff_path allocation"
> 
> So?
> 
> Identifying two versions of the same C file, for one of which the
> Apple compiler does not give you "internal compiler error" and for
> the other it does, may help Apple engineers to debug their compiler.
> 
> But we cannot and will not revert any of our code only because some
> vendor compiler is broken.  It would be a different story if we were
> throwing an invalid C at compilers and relying on a bug in GCC that
> accepts an invalid code, but I do not think that is the case here.

I think knowing the commit that causes the problem is interesting for us, because it lets us see whether we are throwing invalid C at the compiler or not (the compiler should never segfault, obviously, but I can believe that it is more likely to if you throw garbage at it).

But that commit is one of the tamest, I think; it just seems like a boring compiler bug. I'd be curious to reduce it to a minimal change that causes the bug, just to be sure.

Torsten, what is the compiler version (I don't have Apple compilers, but it seems plausible that older clang might have the same problem).

-Peff