The changes in 745224e0 don't seem to build here with gcc-4.9 on
linux x64_64. Any idea what's wrong?
CC credential-store.o
In file included from /usr/lib/.../xmmintrin.h:31:0,
from /usr/lib/.../emmintrin.h:31,
from git-compat-util.h:708,
from cache.h:4,
from credential-store.c:1:
/usr/lib/.../mmintrin.h: In function '_mm_cvtsi32_si64':
/usr/lib/.../mmintrin.h:64:3: error: can't convert between vector
values of different size
return (__m64) __builtin_ia32_vec_init_v2si (__i, 0);
^
/usr/lib/.../mmintrin.h: In function '_mm_cvtsi64_si32':
/usr/lib/.../mmintrin.h:107:10: error: incompatible type for argument
1 of '__builtin_ia32_vec_ext_v2si'
return __builtin_ia32_vec_ext_v2si ((__v2si)__i, 0);
^
[...]
In file included from /usr/lib/.../emmintrin.h:31:0,
from git-compat-util.h:708,
from cache.h:4,
from credential-store.c:1:
/usr/lib/.../xmmintrin.h: In function '_mm_add_ss':
/usr/lib/.../xmmintrin.h:127:19: error: incompatible type for argument
1 of '__builtin_ia32_addss'
return (__m128) __builtin_ia32_addss ((__v4sf)__A, (__v4sf)__B);
^
/usr/lib/.../xmmintrin.h:127:3: note: expected '__vector(4) float' but
argument is of type '__m128'
return (__m128) __builtin_ia32_addss ((__v4sf)__A, (__v4sf)__B);
^
/usr/lib/.../xmmintrin.h:127:19: error: incompatible type for argument
2 of '__builtin_ia32_addss'
return (__m128) __builtin_ia32_addss ((__v4sf)__A, (__v4sf)__B);
^
[...]
/usr/lib/.../emmintrin.h:1455:3: error: incompatible type for argument
2 of '__builtin_ia32_movntpd'
__builtin_ia32_movntpd (__A, (__v2df)__B);
^
/usr/lib/.../emmintrin.h:1455:3: note: expected '__vector(2) double'
but argument is of type '__m128d'
Makefile:1983: recipe for target 'credential-store.o' failed
make: *** [credential-store.o] Error 1
On Thu, Jul 10, 2014 at 9:59 PM, Tuncer Ayaz wrote:
The changes in 745224e0 don't seem to build here with gcc-4.9 on
linux x64_64. Any idea what's wrong?
s/x64_64/x86_64/
Should have written amd64 to avoid the typo :).
CC credential-store.o
In file included from /usr/lib/.../xmmintrin.h:31:0,
from /usr/lib/.../emmintrin.h:31,
from git-compat-util.h:708,
from cache.h:4,
from credential-store.c:1:
/usr/lib/.../mmintrin.h: In function '_mm_cvtsi32_si64':
/usr/lib/.../mmintrin.h:64:3: error: can't convert between vector
values of different size
return (__m64) __builtin_ia32_vec_init_v2si (__i, 0);
^
/usr/lib/.../mmintrin.h: In function '_mm_cvtsi64_si32':
/usr/lib/.../mmintrin.h:107:10: error: incompatible type for argument
1 of '__builtin_ia32_vec_ext_v2si'
return __builtin_ia32_vec_ext_v2si ((__v2si)__i, 0);
^
[...]
In file included from /usr/lib/.../emmintrin.h:31:0,
from git-compat-util.h:708,
from cache.h:4,
from credential-store.c:1:
/usr/lib/.../xmmintrin.h: In function '_mm_add_ss':
/usr/lib/.../xmmintrin.h:127:19: error: incompatible type for argument
1 of '__builtin_ia32_addss'
return (__m128) __builtin_ia32_addss ((__v4sf)__A, (__v4sf)__B);
^
/usr/lib/.../xmmintrin.h:127:3: note: expected '__vector(4) float' but
argument is of type '__m128'
return (__m128) __builtin_ia32_addss ((__v4sf)__A, (__v4sf)__B);
^
/usr/lib/.../xmmintrin.h:127:19: error: incompatible type for argument
2 of '__builtin_ia32_addss'
return (__m128) __builtin_ia32_addss ((__v4sf)__A, (__v4sf)__B);
^
[...]
/usr/lib/.../emmintrin.h:1455:3: error: incompatible type for argument
2 of '__builtin_ia32_movntpd'
__builtin_ia32_movntpd (__A, (__v2df)__B);
^
/usr/lib/.../emmintrin.h:1455:3: note: expected '__vector(2) double'
but argument is of type '__m128d'
Makefile:1983: recipe for target 'credential-store.o' failed
make: *** [credential-store.o] Error 1
From: David Turner <hidden> Date: 2016-06-15 23:01:52
On Thu, 2014-07-10 at 21:59 +0200, Tuncer Ayaz wrote:
The changes in 745224e0 don't seem to build here with gcc-4.9 on
linux x64_64. Any idea what's wrong?
CC credential-store.o
In file included from /usr/lib/.../xmmintrin.h:31:0,
What's in the ...?
Because if you're using headers from a different version of gcc, that
might explain it.
On Thu, Jul 10, 2014 at 10:23 PM, Jeff King wrote:
On Thu, Jul 10, 2014 at 09:59:37PM +0200, Tuncer Ayaz wrote:
quoted
The changes in 745224e0 don't seem to build here with gcc-4.9 on
linux x64_64. Any idea what's wrong?
Weird. It compiles fine on my x86_64 box (Debian unstable, gcc
4.9.0-10). Can you tell us more about your environment?
gcc version 4.9.0 20140604 (prerelease)
I normally use a custom config.mak, but I get the error without
it too, so it has no direct effect.
Let me know if there's anything to try out for finding the difference.
On Thu, Jul 10, 2014 at 10:33 PM, David Turner wrote:
On Thu, 2014-07-10 at 21:59 +0200, Tuncer Ayaz wrote:
quoted
The changes in 745224e0 don't seem to build here with gcc-4.9 on
linux x64_64. Any idea what's wrong?
CC credential-store.o
In file included from /usr/lib/.../xmmintrin.h:31:0,
What's in the ...?
Because if you're using headers from a different version of gcc, that
might explain it.
From: David Turner <hidden> Date: 2016-06-15 23:01:52
On Thu, 2014-07-10 at 22:44 +0200, Tuncer Ayaz wrote:
On Thu, Jul 10, 2014 at 10:33 PM, David Turner wrote:
quoted
On Thu, 2014-07-10 at 21:59 +0200, Tuncer Ayaz wrote:
quoted
The changes in 745224e0 don't seem to build here with gcc-4.9 on
linux x64_64. Any idea what's wrong?
CC credential-store.o
In file included from /usr/lib/.../xmmintrin.h:31:0,
What's in the ...?
Because if you're using headers from a different version of gcc, that
might explain it.
That seems fine to me.
It looks like the error messages are coming from inside the system's
header files (but this is sometimes misleading). If you just try to
compile
#include <emmintrin.h>
int main() { }
with whatever options you use for git, does that work? If not, I would
say that you have a compiler setup problem.
On Thu, Jul 10, 2014 at 10:53 PM, David Turner wrote:
On Thu, 2014-07-10 at 22:44 +0200, Tuncer Ayaz wrote:
quoted
On Thu, Jul 10, 2014 at 10:33 PM, David Turner wrote:
quoted
On Thu, 2014-07-10 at 21:59 +0200, Tuncer Ayaz wrote:
quoted
The changes in 745224e0 don't seem to build here with gcc-4.9 on
linux x64_64. Any idea what's wrong?
CC credential-store.o
In file included from /usr/lib/.../xmmintrin.h:31:0,
What's in the ...?
Because if you're using headers from a different version of gcc, that
might explain it.
That seems fine to me.
It looks like the error messages are coming from inside the system's
header files (but this is sometimes misleading). If you just try to
compile
#include <emmintrin.h>
int main() { }
with whatever options you use for git, does that work? If not, I would
say that you have a compiler setup problem.
The above test works on the same machine, so I'll
investigate what's going on when building git. Thanks.
Sorry, didn't test properly when I tried with/without config.mak, and
PROFILE=BUILD was the problem. I had that in config.mak based on
information gathered from INSTALL and Makefile. To be clear, is
PROFILE=BUILD (still) supported?
From: David Turner <hidden> Date: 2016-06-15 23:01:52
On Fri, 2014-07-11 at 00:12 +0200, Tuncer Ayaz wrote:
Sorry, didn't test properly when I tried with/without config.mak, and
PROFILE=BUILD was the problem. I had that in config.mak based on
information gathered from INSTALL and Makefile. To be clear, is
PROFILE=BUILD (still) supported?
For what it's worth, the problem seems to depend on the combination of
-DNO_NOTRETURN=1 and -fprofile-use. So I can trigger the same breakage
with this:
---
#define NO_NORETURN 1
#include "git-compat-util.h"
int main() {}
---
gcc -I. -c -fprofile-use=/tmp foo.c -o foo.o
Do we still need NO_NORETURN? Git seems to build without it under GCC
4.6.3 (Ubuntu's version).
From: Jeff King <hidden> Date: 2016-06-15 23:01:54
On Fri, Jul 11, 2014 at 12:12:55AM +0200, Tuncer Ayaz wrote:
Sorry, didn't test properly when I tried with/without config.mak, and
PROFILE=BUILD was the problem. I had that in config.mak based on
information gathered from INSTALL and Makefile. To be clear, is
PROFILE=BUILD (still) supported?
I think none of the regular devs uses PROFILE, and it bit-rotted
somewhat. Andi Kleen recently posted a series to fix it[1]. I can
reproduce your problem without that series, but compiling with
ak/profile-feedback-build merged in seems to work OK.
[1] http://thread.gmane.org/gmane.comp.version-control.git/253005
On Fri, Jul 11, 2014 at 12:12:55AM +0200, Tuncer Ayaz wrote:
quoted
Sorry, didn't test properly when I tried with/without config.mak,
and PROFILE=BUILD was the problem. I had that in config.mak based
on information gathered from INSTALL and Makefile. To be clear, is
PROFILE=BUILD (still) supported?
I think none of the regular devs uses PROFILE, and it bit-rotted
somewhat. Andi Kleen recently posted a series to fix it[1]. I can
reproduce your problem without that series, but compiling with
ak/profile-feedback-build merged in seems to work OK.
[1] http://thread.gmane.org/gmane.comp.version-control.git/253005
Yes, Andi's patch works.
Any idea when ak/profile-feedback-build will land in master?
I think none of the regular devs uses PROFILE, and it bit-rotted
By the way, is there no build (CI) server for git.git to regularly
test branches on different platforms or at least different build
configs on the same platform?
From: Jeff King <hidden> Date: 2016-06-15 23:01:54
On Sat, Jul 12, 2014 at 10:47:03AM +0200, Tuncer Ayaz wrote:
Yes, Andi's patch works.
Any idea when ak/profile-feedback-build will land in master?
Junio posts updates in his "What's Cooking" messages (usually about
twice a week). Last Tuesday's listed it as "will merge to next". Unless
anybody finds problems with it, I'd expect it in master within a week or
two, and probably part of v2.1 when it releases.
-Peff
From: Jeff King <hidden> Date: 2016-06-15 23:01:54
On Sat, Jul 12, 2014 at 10:53:47AM +0200, Tuncer Ayaz wrote:
On Sat, Jul 12, 2014 at 6:56 AM, Jeff King wrote:
quoted
I think none of the regular devs uses PROFILE, and it bit-rotted
By the way, is there no build (CI) server for git.git to regularly
test branches on different platforms or at least different build
configs on the same platform?
Junio tests master and next on a few different platforms before pushing
out the results of topic integration. Other than that, we rely on people
to report problems (and people testing master or even next on their
platforms is very much appreciated, as it means we can fix problems
before they are cemented in a release).
-Peff