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

[Junio C Hamano <gitster@pobox.com>]

Torsten Bögershausen <tboegi@web.de> writes:

> On 2016-02-26 19.29, Junio C Hamano wrote:
>> Torsten Bögershausen <tboegi@web.de> writes:
>> 
>>> CC combine-diff.o
>>> combine-diff.c: In function ‘diff_tree_combined’:
>>> combine-diff.c:1391: internal compiler error: Segmentation fault
>>> Please submit a full bug report,
>>> with preprocessed source if appropriate.
>>> See <URL:http://developer.apple.com/bugreporter> for instructions.
>>> make: *** [combine-diff.o] Error 1
>>>
>>> Revert "use st_add and st_mult for allocation size computation" didn't fix it.
>>> I haven't digged deeper yet.
>> 
>> Hmph, I am not quite sure what you meant by "I haven't digged
>> deeper"; I do not think you should be debugging Apple's compiler
>> (unless you have the source to it and that is your job to do so,
>> that is).
>> 
>> In any case, merging the topic to 'master', and reverting that
>> commit will leave this only this change between 'master' and the
>> result.  I do not immediately spot anything trickier in the
>> postimage compared to the preimage that may trickle a compiler bug,
>> but what would I know without the source ;-)
>> 
> 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.



>
>     This reverts commit 5b442c4f2723211ce0d862571e88ee206bfd51bf.
>
> Test suite passes,
> ( except t9115, the 2 new test cases "svn.pathnameencoding=cp932".
>   More info about that later)