[prev in list] [next in list] [prev in thread] [next in thread] 

List:       gmp-bugs
Subject:    [arm64] Negative immediates and lack of default Neon support
From:       tg () gmplib ! org (=?utf-8?Q?Torbj=C3=B6rn?= Granlund)
Date:       2014-10-03 9:41:52
Message-ID: 86tx3lcwwv.fsf () shell ! gmplib ! org
[Download RAW message or body]

Marc Glisse <marc.glisse at inria.fr> writes:

  Strange, I thought I had tested 3.4, but apparently not. I get the
  same failure as you. And if I use -no-integrated-as, it passes lshift,
  but the compiler goes into an infinite loop for divrem_2.c and fails
  on another .c file with:
  
  /tmp/mod_1_4-96baa4.s: Assembler messages:
  /tmp/mod_1_4-96baa4.s:263: Error: unknown pseudo-op: `.data_region'
  /tmp/mod_1_4-96baa4.s:273: Error: unknown pseudo-op: `.end_data_region'
  
  It also crashes in many files: div_qr_2n_pi1.c, dcpi1_div_qr.c,
  hgcd2.c, gcd.c, jacobi_2.c, dcpi1_divappr_q.c, div_qr_2u_pi1.c,
  hgcd2_jacobi.c...
  
  Most of those seem related to inline asm, --disable-assembly works
  around many of them, but not an issue in get_str.
  
  Working around all that may be possible, but it is going to be quite a
  bit of work, and I don't think it is worth the trouble for a platform
  that almost noone has access to yet.

Wow!  "Released" software isn't what it used to be, that's for sure.

Thanks for this analysis!

(I found a workaround for the negative-offset-problem.  This is another
case of strictness in the clang assembler; ldr doesn't really allow
negative offsets, ldur is needed for that.  With your analysis above in
mind, I might not bother changing our assembly code to use ldur.)

-- 
Torbj?rn
Please encrypt, key id 0xC8601622

[prev in list] [next in list] [prev in thread] [next in thread]