From: Torbjorn Granlund t...@gmplib.org
Date: Tue, 16 Apr 2013 14:43:58 +0200
If we cannot make an configure test, we need to know if there is a
release where the assembler can be trusted.
After some discussions with my Oracle contact, I think a configure
test will actually be easy, the
David Miller da...@davemloft.net writes:
From: Torbjorn Granlund t...@gmplib.org
Date: Tue, 16 Apr 2013 14:43:58 +0200
If we cannot make an configure test, we need to know if there is a
release where the assembler can be trusted.
After some discussions with my Oracle contact, I
From: Torbjorn Granlund t...@gmplib.org
Date: Wed, 17 Apr 2013 00:00:37 +0200
But if a real feature/bug test is too hard, or hard to make reliable,
version detection is what we have to do.
My plan is to shoot for a full functionality+bug test, and if
that's too hard then if the assembler
Where to go from here? If we want to clean up some old SPARC code,
then we have learnt that we to test the result on several key platforms.
We also don't want to create slower code, unless the old code is clearly
broken (in more than a hypothetical way).
For the 64bit case, it is safe to assume
From: Torbjorn Granlund t...@gmplib.org
Date: Mon, 15 Apr 2013 17:13:34 +0200
Where to go from here?
Please run make -k in that tarball I posted for you last night, it's
very important.
None of what's happening makes any sense, and we can't make wise decisions
about how to proceed until we
From: ni...@lysator.liu.se (Niels Möller)
Date: Mon, 15 Apr 2013 18:57:53 +0200
Torbjorn Granlund t...@gmplib.org writes:
We may well put data in the text segment rather than rodata to allow for
plainer code.
At least in theory, there should be little difference. PC-relative
offsets
swift gmake -k
gcc -m64 -fPIC -c -o test1_shared.o test1.S
/usr/ccs/bin/as: /var/tmp//ccqorjdc.s: , approx line 18: internal error:
pic_relocs(): hh reltype?
gmake: *** [test1_shared.o] Error 1
gcc -m64 -c -o test1_static.o test1.S
gcc -m64 -fPIC -c -o test2_shared.o test2.S
/usr/ccs/bin/as:
David Miller da...@davemloft.net writes:
BTW, you traded one failure for another, now PIC is broke
for ultrasparct3 builds, because now in invert_limb.asm we're
back to:
diff -r bd92f35223f8 mpn/sparc64/ultrasparct3/invert_limb.asm
--- a/mpn/sparc64/ultrasparct3/invert_limb.asm Sun
From: Torbjorn Granlund t...@gmplib.org
Date: Sun, 14 Apr 2013 19:21:36 +0200
I tried some timing of call to a pc loading thunk versus an rdpc
instruction. Approximate cycle counts:
rdpcthunk
US2 5 2
US3 6 6
T1 6 10
I assume US1=US2,
From: Torbjorn Granlund t...@gmplib.org
Date: Sun, 14 Apr 2013 19:21:36 +0200
T3 and T4 are of course quite relevant, so we should take these into
account. If they run rdpc no slower than the thunk call, then we should
use rdpc unconditionally.
I used this test program:
Ok, on T4, %pc
David Miller da...@davemloft.net writes:
Since using rdpc avoids the whole issue of corrupting the return
address stack, it seems pretty desirable to move over to it.
Let's do it.
Well see a slight slowdown for T3, but probably its general slowness
will make this new slowdown almost
From: Torbjorn Granlund t...@gmplib.org
Date: Sun, 14 Apr 2013 23:26:31 +0200
David Miller da...@davemloft.net writes:
Sure, let's revert v9/sqr_diagonal.asm and sparc64/gcd_1.asm back to
their previous state for now, and try to work from that. Here's a
patch.
2013-04-14
Torbjorn Granlund t...@gmplib.org writes:
Torbjorn Granlund t...@gmplib.org writes:
ld: fatal: relocation error: R_SPARC_GOTDATA_OP_LOX10: file
mpn/.libs/gcd_1.o: symbol ctz_table: relocation illegal for TLS symbol
ld: fatal: relocation error: R_SPARC_GOTDATA_OP: file
From: Torbjorn Granlund t...@gmplib.org
Date: Sat, 13 Apr 2013 15:40:38 +0200
I spotted a comment in gcc,
;; Even on V9 we use this call sequence with a stub, instead of rd %pc, ...
;; because the RDPC instruction is extremely expensive and incurs a complete
;; instruction pipeline flush.
From: Torbjorn Granlund t...@gmplib.org
Date: Sat, 13 Apr 2013 12:10:33 +0200
David Miller da...@davemloft.net writes:
* mpn/sparc32/sparc-defs.m4 (LEA): Remove unused local label.
(LEA_LEAF): Likewise.
This patch helped the get past the Slowlaris assembler, which
can only
From: Torbjorn Granlund t...@gmplib.org
Date: Sat, 13 Apr 2013 21:10:35 +0200
ld: fatal: relocation error: R_SPARC_GOTDATA_OP_LOX10: file
mpn/.libs/gcd_1.o: symbol ctz_table: relocation illegal for TLS symbol
ld: fatal: relocation error: R_SPARC_GOTDATA_OP: file mpn/.libs/gcd_1.o:
David Miller da...@davemloft.net writes:
ld: fatal: relocation error: R_SPARC_GOTDATA_OP_LOX10: file
mpn/.libs/gcd_1.o: symbol ctz_table: relocation illegal for TLS symbol
ld: fatal: relocation error: R_SPARC_GOTDATA_OP: file
mpn/.libs/gcd_1.o: symbol ctz_table: relocation illegal
From: Torbjorn Granlund t...@gmplib.org
Date: Sat, 13 Apr 2013 21:52:40 +0200
Really? What does our case have to do with TLS? The example error
message uses a TLS reloc, we don't.
Implicit section at the beginning of assembly?
Here, try these two things:
1) Build:
static const
From: David Miller da...@davemloft.net
Date: Sat, 13 Apr 2013 15:58:44 -0400 (EDT)
From: Torbjorn Granlund t...@gmplib.org
Date: Sat, 13 Apr 2013 21:52:40 +0200
Really? What does our case have to do with TLS? The example error
message uses a TLS reloc, we don't.
Implicit section at the
From: David Miller da...@davemloft.net
Date: Sat, 13 Apr 2013 15:59:49 -0400 (EDT)
From: David Miller da...@davemloft.net
Date: Sat, 13 Apr 2013 15:58:44 -0400 (EDT)
From: Torbjorn Granlund t...@gmplib.org
Date: Sat, 13 Apr 2013 21:52:40 +0200
Really? What does our case have to do with
There are syntax errors for swift.nada.kth.se, a Solaris system. See
http://gmplib.org/devel/tm-date.html.
The offending lines:
swift (ABI=64)
99: sethi %gdop_hix22(ctz_table), %i5
swift-32 (ABI=32)
99: sethi %gdop_hix22(.Lnoll), %l0
We need things to work on Solaris, *BSD.
--
I've done some more research into this.
I first made sure that we are using the same test that GCC uses to
enable the use of gotdata relocations.
Then I read over the new m4 LEA macros a few times, the only thing
I found was that I left around a local label that was only necessary
for an
This patch aims to:
1) Consolidate all of the address loading details of PIC
vs. non-PIC into one place, via helper macros.
2) Add support for GOTDATA relocations when the tools
support it.
3) When supported by the tools, use comdat et al. in order to have
shared PIC thunks. All PIC
Please use LEA* instead of LOAD_SYMBOL*, since that's what we use
elsewhere. (OK, LEA might be a misnomer, but a well-established one in
and outside of GMP.)
I assume your broad testing covers every modified file. Do you have an
idea of whether that is true.
Whn testing shared libs, I have
From: Torbjorn Granlund t...@gmplib.org
Date: Wed, 10 Apr 2013 14:35:13 +0200
Please use LEA* instead of LOAD_SYMBOL*, since that's what we use
elsewhere. (OK, LEA might be a misnomer, but a well-established one in
and outside of GMP.)
Ok.
I assume your broad testing covers every modified
I assume your broad testing covers every modified file. Do you have an
idea of whether that is true.
I rechecked everything and the one case I missed was supersparc-*
Even the current tree has a build problem of the supersparc target
with current tools due to combination of a
From: Torbjorn Granlund t...@gmplib.org
Date: Wed, 10 Apr 2013 20:07:52 +0200
I'll get those bugs sorted out, but at least gcc-4.6 and gcc-4.7 have
this problem, and have had them for some time, so I think we should
work around it. A workaround that works is to pass -mcpu=v8
27 matches
Mail list logo
