GNU bug report logs - #12754
factor.c selects 64 bit code from longlong.h on 32-bit hppa systems

Previous Next

Full log

View this message in rfc822 format

From: Torbjorn Granlund <tg <at> gmplib.org>
To: Pádraig Brady <P <at> draigBrady.com>
Cc: 12754 <at> debbugs.gnu.org, John David Anglin <dave <at> hiauly1.hia.nrc.ca>, John David Anglin <dave.anglin <at> bell.net>
Subject: bug#12754: factor.c selects 64 bit code from longlong.h on 32-bit hppa systems
Date: Mon, 29 Oct 2012 14:27:26 +0100

Pádraig Brady <P <at> draigBrady.com> writes:

  Sure, but from the message linked above it seems that
  the size of uintmax_t is significant here rather than the "word" size.
  
  Torbjorn should W_TYPE_SIZE match the "word" size or uintmax_t ?
  
We're setting things up for arithmetic on uintmax_t (one or two of
these).

W_TYPE_SIZE is then used to ask longlong.h to define a couple of macros
(documented in the beginning of that file) which provide arithmetic
based on that size.  Then longlong.h will do it in assembly or in C.

W_TYPE_SIZE must thus be the size of uintmax_t.

The problems we've seen are related to this slightly backward use of
longlong in factor.c.  In GMP (the main home of longlong.h) we figure
out the real word size, and then define W_TYPE_SIZE to that.

The trick around this is to find better API specific predefs to test in
longlong.h, juist like Pádraig did for sparc.  If no such predefs exist,
we can either set something up via configure to define some cpp symbol,
or we need to disable the problematic assembly.  This will hurt
performance, but will not affect program behaviour.

-- 
Torbjörn

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.