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

From: Torsten Bögershausen <tboegi@web.de>
Date: Feb 27, 2016, 07:12 UTC
Message-ID: <56D14C56.6070306@web.de>
In-Reply-To: <20160227032907.GB10313@sigill.intra.peff.net>

On 27.02.16 04:29, Jeff King wrote:

Show 29 quoted lines

> On Fri, Feb 26, 2016 at 03:35:10PM -0800, Junio C Hamano wrote:
>
>>> 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

That's machine is running Mac OS X 10.6, which is no longer supported with updates.

 gcc --version
i686-apple-darwin10-gcc-4.2.1 (GCC) 4.2.1 (Apple Inc. build 5666) (dot 3)
Copyright (C) 2007 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

There seems to be a clang as well:
clang --version
Apple clang version 1.7 (tags/Apple/clang-77) (based on LLVM 2.9svn)
Target: x86_64-apple-darwin10
Thread model: posix

If that information is helpful:
On later versions of Mac OS X (and/or Xcode) gcc is a wrapper to clang,
and this is what I see under Mac OS 10.9:
gcc --version
Configured with: --prefix=/Library/Developer/CommandLineTools/usr --with-gxx-include-dir=/usr/include/c++/4.2.1
Apple LLVM version 6.0 (clang-600.0.57) (based on LLVM 3.5svn)
Target: x86_64-apple-darwin13.4.0
Thread model: posix