I added clang 3.5 and clang 3.6 testing to a Breadwell system.
We got one new build failure, and a handful new check failures.
I suspect the "steamroller" failures are a real hardware compatibility
problem.
I suspect the build failure is due to plain (Intel NUC) hardware without
ECC, or Linux bu
On Mon, 25 May 2015, Marc Glisse wrote:
On Mon, 25 May 2015, Torbjörn Granlund wrote:
Marc Glisse writes:
Now I've found it (and reported
https://llvm.org/bugs/show_bug.cgi?id=23646 ). Note that the same (?)
instruction is spelled differently in the same file:
bc+ 12, 28, L(9
Marc Glisse writes:
> bc+ 12, 28, L(9)
> vs.
> blt+cr7, L(24)
>
> Note that the former form works with clang 3.5 installs. A 3.6
> regression?
Indeed...
One may debate what is a valid instruction form. I suppose one needs to
read the specs for what IBM calls
On Mon, 25 May 2015, Torbjörn Granlund wrote:
Marc Glisse writes:
Now I've found it (and reported
https://llvm.org/bugs/show_bug.cgi?id=23646 ). Note that the same (?)
instruction is spelled differently in the same file:
bc+ 12, 28, L(9)
vs.
blt+cr7, L(24)
Note th
Marc Glisse writes:
Now I've found it (and reported
https://llvm.org/bugs/show_bug.cgi?id=23646 ). Note that the same (?)
instruction is spelled differently in the same file:
bc+ 12, 28, L(9)
vs.
blt+cr7, L(24)
Note that the former form works with clang 3.5
t...@gmplib.org (Torbjörn Granlund) writes:
> We could use a short clang whitelist instead of a clang blacklist? Here
> is a beginning: "" :-)
For s start, I think it would make some sense to blacklist all clang
versions until today (but future versions should be assumed working
until proven bug
ni...@lysator.liu.se (Niels Möller) writes:
> Harsh against whom? The point is not to make a statement, but to make
> it more likely that GMP works correctly for our users.
It's going to look very much like you're making a statement, whether or
not that's your intention.
Please don'
t...@gmplib.org (Torbjörn Granlund) writes:
> ni...@lysator.liu.se (Niels Möller) writes:
>
> I think that requiring an --enable-clang to be able to build with any
> version of clang on any platform whatsoever is a bit harsh.
>
> Harsh against whom? The point is not to make a statement, but t
Marc Glisse writes:
> On powerpc-linux-gnu, clang complains about the bc+ instruction, and
> indeed I can't find that in IBM's documentation.
https://www-01.ibm.com/support/knowledgecenter/ssw_aix_71/com.ibm.aix.alangref/idalangref_bcbr_inst.htm
(The + sign manipulates the static branch p
Marc Glisse writes:
Now I've found it (and reported
https://llvm.org/bugs/show_bug.cgi?id=23646 ). Note that the same (?)
instruction is spelled differently in the same file:
bc+ 12, 28, L(9)
vs.
blt+cr7, L(24)
(there is also a mix of using "7" vs "cr7")
On Thu, 21 May 2015, Marc Glisse wrote:
On powerpc-linux-gnu, clang complains about the bc+ instruction, and
indeed I can't find that in IBM's documentation. After removing
divrem_2.asm, it compiles fine and passes the testsuite.
Now I've found it (and reported
https://llvm.org/bugs/show_bug
ni...@lysator.liu.se (Niels Möller) writes:
I think that requiring an --enable-clang to be able to build with any
version of clang on any platform whatsoever is a bit harsh.
Harsh against whom? The point is not to make a statement, but to make
it more likely that GMP works correctly for our
t...@gmplib.org (Torbjörn Granlund) writes:
> The clang on FreeBSD 10 miscompiles GMP on for some x86 CPU subtypes.
> Apparently Intel Haswell is one of these; this is currently not
> exercised by our tests setup.
But the bugs are likely to be exposed if a user runs make check on an
affected plat
ni...@lysator.liu.se (Niels Möller) writes:
> GMP triggers bugs in clang on every platform where we tried this
> compiler.
It looks like it almost works on x86, except for failures with the
(obscure?) x32 ABI.
The clang on FreeBSD 10 miscompiles GMP on for some x86 CPU subtypes.
Appa
14 matches
Mail list logo
