In file included from src/secp256k1.c:12:
In file included from ./src/scalar_impl.h:20:
./src/scalar_4x64_impl.h:379:19: error: value '4624529908474429119' out of
range for constraint 'n'
: "S"(l), "n"(SECP256K1_N_C_0), "n"(SECP256K1_N_C_1)
^~~~~~~~~~~~~~~
./src/scalar_4x64_impl.h:17:25: note: expanded from macro 'SECP256K1_N_C_0'
#define SECP256K1_N_C_0 (~SECP256K1_N_0 + 1)
^~~~~~~~~~~~~~~~~~~~
./src/scalar_4x64_impl.h:458:74: error: value '4624529908474429119' out of
range for constraint 'n'
: "g"(m0), "g"(m1), "g"(m2), "g"(m3), "g"(m4), "g"(m5), "g"(m6),
"n"(SECP256K1_N_C_0), "n"(SECP256K1_N_C_1)
^~~~~~~~~~~~~~~
./src/scalar_4x64_impl.h:17:25: note: expanded from macro 'SECP256K1_N_C_0'
#define SECP256K1_N_C_0 (~SECP256K1_N_0 + 1)
^~~~~~~~~~~~~~~~~~~~
./src/scalar_4x64_impl.h:504:64: error: value '4624529908474429119' out of
range for constraint 'n'
: "g"(p0), "g"(p1), "g"(p2), "g"(p3), "g"(p4), "D"(r),
"n"(SECP256K1_N_C_0), "n"(SECP256K1_N_C_1)
^~~~~~~~~~~~~~~
./src/scalar_4x64_impl.h:17:25: note: expanded from macro 'SECP256K1_N_C_0'
#define SECP256K1_N_C_0 (~SECP256K1_N_0 + 1)
^~~~~~~~~~~~~~~~~~~~
-
alexdupre commented at 8:45 AM on March 4, 2019: none
-
gmaxwell commented at 9:43 AM on March 4, 2019: contributor
Is there anything special about how you're building it? You're not trying to build a 32bit binary?
This looks like clang is broken: SECP256K1_N_C_0 is a 63 bit number and should be fine for "n" on x86_64. SECP256K1_N_C_1 has a similar magnitude (it's larger, in fact) and your output is not complaining about that.
-
alexdupre commented at 1:06 PM on March 4, 2019: none
Nothing special, here you can see the full build log: http://package18.nyi.freebsd.org/data/headamd64PR236062-default/2019-03-01_06h42m53s/logs/errors/secp256k1-0.1.20190204.log
I guess it doesn't complain about SECP256K1_N_C_1 just because it breaks before on SECP256K1_N_C_0.
-
sipa commented at 11:30 PM on March 4, 2019: contributor
Maybe we should just get rid of this mechanism of passing constants into the asm code, and instead inline them directly? I can't even find any documentation anymore about this "n" constraint; I suspect it isn't very standard (to the extent that GCC's extended asm syntax can be considered standard in the first place).
-
MarcoFalke commented at 7:46 PM on March 6, 2019: none
I can reproduce this on debian sid with
$ clang-8 --version clang version 8.0.0-+rc3-1~exp1 (tags/RELEASE_800/rc3) Target: x86_64-pc-linux-gnu Thread model: posix InstalledDir: /usr/bin $ ./autogen.sh && ./configure CC=clang-8 && make ... Build Options: with endomorphism = no with ecmult precomp = yes with jni = no with benchmarks = yes with coverage = no module ecdh = no module recovery = no asm = x86_64 bignum = no field = 64bit scalar = 64bit CC = clang-8 CFLAGS = -g -O2 -W -std=c89 -pedantic -Wall -Wextra -Wcast-align -Wnested-externs -Wshadow -Wstrict-prototypes -Wno-unused-function -Wno-long-long -Wno-overlength-strings -fvisibility=hidden -O3 CPPFLAGS = LDFLAGS = CC src/bench_verify.o gcc -I. -g -O2 -Wall -Wextra -Wno-unused-function -c src/gen_context.c -o gen_context.o gcc -g -O2 -Wall -Wextra -Wno-unused-function gen_context.o -o gen_context ./gen_context CC src/libsecp256k1_la-secp256k1.lo In file included from src/secp256k1.c:12: In file included from ./src/scalar_impl.h:20: ./src/scalar_4x64_impl.h:379:19: error: value '4624529908474429119' out of range for constraint 'n' : "S"(l), "n"(SECP256K1_N_C_0), "n"(SECP256K1_N_C_1) ^~~~~~~~~~~~~~~ ./src/scalar_4x64_impl.h:17:25: note: expanded from macro 'SECP256K1_N_C_0' #define SECP256K1_N_C_0 (~SECP256K1_N_0 + 1) ^~~~~~~~~~~~~~~~~~~~ ./src/scalar_4x64_impl.h:458:74: error: value '4624529908474429119' out of range for constraint 'n' : "g"(m0), "g"(m1), "g"(m2), "g"(m3), "g"(m4), "g"(m5), "g"(m6), "n"(SECP256K1_N_C_0), "n"(SECP256K1_N_C_1) ^~~~~~~~~~~~~~~ ./src/scalar_4x64_impl.h:17:25: note: expanded from macro 'SECP256K1_N_C_0' #define SECP256K1_N_C_0 (~SECP256K1_N_0 + 1) ^~~~~~~~~~~~~~~~~~~~ ./src/scalar_4x64_impl.h:504:64: error: value '4624529908474429119' out of range for constraint 'n' : "g"(p0), "g"(p1), "g"(p2), "g"(p3), "g"(p4), "D"(r), "n"(SECP256K1_N_C_0), "n"(SECP256K1_N_C_1) ^~~~~~~~~~~~~~~ ./src/scalar_4x64_impl.h:17:25: note: expanded from macro 'SECP256K1_N_C_0' #define SECP256K1_N_C_0 (~SECP256K1_N_0 + 1) ^~~~~~~~~~~~~~~~~~~~ 3 errors generated. make: *** [Makefile:1047: src/libsecp256k1_la-secp256k1.lo] Error 1 - MarcoFalke cross-referenced this on Mar 6, 2019 from issue Error compiling on debian sid with clang-8 by MarcoFalke
-
real-or-random commented at 11:32 PM on March 6, 2019: contributor
I can't even find any documentation anymore about this "n" constraint; I suspect it isn't very standard (to the extent that GCC's extended asm syntax can be considered standard in the first place).
see https://gcc.gnu.org/onlinedocs/gcc/Simple-Constraints.html#Simple-Constraints
-
sipa commented at 11:54 PM on March 6, 2019: contributor
@real-or-random Right, that's it. It's not listed in the machine specific ones for x86 though. @alexdupre @MarcoFalke Could you try replacing all instances of
"n"with"i"in src/scalar_4x64_impl.h? (both work for me in GCC 8.2). -
gmaxwell commented at 6:46 AM on March 7, 2019: contributor
Even if using i fixes it, we might want to open a bug for clang.
-
alexdupre commented at 8:01 AM on March 7, 2019: none
-
alexdupre commented at 9:44 AM on March 7, 2019: none
I confirm that replacing
"n"with"i"fixes the compilation and./testsrun successfully -
real-or-random commented at 3:29 PM on March 7, 2019: contributor
Looks like this issue will be fixed upstream before the official release of clang 8, so it's probably not worth working around here.
-
alexdupre commented at 6:50 AM on March 8, 2019: none
I agree.
- alexdupre closed this on Mar 8, 2019
- gmaxwell cross-referenced this on Mar 10, 2019 from issue Switch x86_64 asm to use "i" instead of "n" for immediate values. by gmaxwell
-
MarcoFalke commented at 4:21 PM on March 11, 2019: none
Compiles in clang-8-rc4
- gmaxwell referenced this in commit ee99f12f3d on Mar 11, 2019