Thread (6 messages) flat view 6 messages, 4 authors, 2016-06-15

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

From: Jeff King <hidden>
Date: 2016-06-15 23:08:30

Possibly related (same subject, not in this thread)

On Fri, Feb 26, 2016 at 03:35:10PM -0800, Junio C Hamano wrote:
quoted
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
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help