From: Junio C Hamano <hidden> Date: 2016-06-15 23:08:30
Torsten Bögershausen [off-list ref] writes:
On 2016-02-26 19.29, Junio C Hamano wrote:
quoted
Torsten Bögershausen [off-list ref] writes:
quoted
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)
From: Jeff King <hidden> Date: 2016-06-15 23:08:30
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
On Fri, Feb 26, 2016 at 03:35:10PM -0800, Junio C Hamano wrote:
quoted
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
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
How about something like this as a workaround ?
(I can send a proper patch, if this is the way forward)
commit dcd7d5551d6931e47829c7febbee0877340eb17f
Author: Torsten Bögershausen [off-list ref]
Date: Sat Feb 27 15:18:28 2016 +0100
config.mak.uname: Darwin: Use clang for Mac OS X 10.6
Commit
"tree-diff: catch integer overflow in combine_diff_path allocation"
make gcc under Mac OX 10.6 crash like this:
CC combine-diff.o
combine-diff.c: In function ‘diff_tree_combined’:
combine-diff.c:1391: internal compiler error: Segmentation fault
Xcode for Mac OS X 10.6 has both gcc and clang.
Later versions of Mac OSX/Xcode only provide clang, and gcc is a wrapper
to it.
Make Git compile under Mac OS X 10.6 by using clang instead of gcc
From: Jeff King <hidden> Date: 2016-06-15 23:08:32
On Sat, Feb 27, 2016 at 08:12:22AM +0100, Torsten Bögershausen wrote:
quoted
Torsten, what is the compiler version (I don't have Apple compilers, but
it seems plausible that older clang might have the same problem).
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.
Thanks. Out of curiosity, I tried to reproduce by with a build of gcc
4.2.1, to see if I could bisect. But it seems the toolchain is quite
complex. After much munging, I managed to build a broken compiler (which
I think is due to a much too-new version of bison, but I stopped
digging).
Your suggestion elsewhere in the thread to just use clang instead sounds
good to me. :)
-Peff
From: Eric Sunshine <hidden> Date: 2016-06-15 23:08:32
On Mon, Feb 29, 2016 at 5:18 AM, Jeff King [off-list ref] wrote:
On Sat, Feb 27, 2016 at 08:12:22AM +0100, Torsten Bögershausen wrote:
quoted
quoted
Torsten, what is the compiler version (I don't have Apple compilers, but
it seems plausible that older clang might have the same problem).
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.
Thanks. Out of curiosity, I tried to reproduce by with a build of gcc
4.2.1, to see if I could bisect. But it seems the toolchain is quite
complex. After much munging, I managed to build a broken compiler (which
I think is due to a much too-new version of bison, but I stopped
digging).
Your suggestion elsewhere in the thread to just use clang instead sounds
good to me. :)
If possible, for the moment, I'd prefer to hold off on that
sledge-hammer approach of unconditionally making the build use clang.
It would be nice to have a more detailed understanding of what exactly
is triggering the Apple compiler bug, and I've been trying to find
time to check it out on my old Mac.