Re: Configure fails on 32-bit platform

[Niels Möller]

Vincent Lefevre  writes:

> So, in case of 32-bit x86 mode in the compiler, shouldn't $host be
> seen as matching X86_PATTERN instead of X86_64_PATTERN?

Interestingly, it seems config.guess checks $CC (but not $CFLAGS):

  $ ./config.guess 
  haswell-pc-linux-gnu
  $ CC='gcc -m32' ./config.guess 
  x86_64-pc-linux-gnu

If it had produced

  i386-pc-linux-gnu

in the latter case, ABI=64 would probably have been excluded.

GMP configure might like to know both that the compiler is only capable
of 32-bit code, and that the chip is a haswell to be used in 32-bit
mode, not any random x86.

But the thing with GMP configure is that it wants 64-bit code if
possible, so given a compiler which defaults to 32-bit code but is
capable of 64-bit, it wants to use ABI=64 and add -m64 or similar to
CFLAGS. Which gives better performance, but sometimes a bit surprising
to the user. I think it would be better to not automatically add -m64 in
this case, but just display a loud message suggesting a reconfigure with
CC='gcc -m64'.

Regards,
/Niels

-- 
Niels Möller. PGP-encrypted email is preferred. Keyid 368C6677.
Internet email is subject to wholesale government surveillance.
___
gmp-bugs mailing list
gmp-bugs@gmplib.org
https://gmplib.org/mailman/listinfo/gmp-bugs

Re: Configure fails on 32-bit platform

[Vincent Lefevre]

On 2018-02-12 12:52:49 +0100, Torbjorn Granlund wrote:
> It is less common that people set CC/CFLAGS to bad values (or at least
> we don't hear about that very often).  I don't think we should try to
> accomodate that since it would result in lots of fragile complexity.
> (If you don't agree, please see the logic for "ABI" -> (CFLAGS,mpn_path)
> selection.)

The problem here may be somewhere else. On an x86_64 machine, with
just "gcc", the processor is regarded as an x86_64: the __x86_64
macro is defined. But if one uses -m32, then the processor is
regarded as a 32-bit x86: __x86_64 is no longer defined; __i386 and
__i686 are defined instead.

The selection of the ABI seems to be based on $host in configure.ac:

case $host in
  [...]
  X86_PATTERN | X86_64_PATTERN)
abilist="32"
[...]
case $host in
  X86_64_PATTERN)
cclist_64="gcc cc"
[...]
abilist="64 x32 32"
[...]

So, in case of 32-bit x86 mode in the compiler, shouldn't $host be
seen as matching X86_PATTERN instead of X86_64_PATTERN?

Otherwise, since abilist="64 x32 32", for X86_64_PATTERN, shouldn't 32
be tried if 64 and x32 do not work (i.e. as if the user set ABI=32)?
There's a "for abi in $abilist; do" loop. So I'm wondering whether it
does all the necessary tests it could do. Here, it appears to decide
too early that ABI=64 is working.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)
___
gmp-bugs mailing list
gmp-bugs@gmplib.org
https://gmplib.org/mailman/listinfo/gmp-bugs

Re: Configure fails on 32-bit platform

[Niels Möller]

t...@gmplib.org (Torbjörn Granlund) writes:

> It is not easy to find anything better than what we have today.
>
> The current strategy was chosen to work best for most users, and work
> best here means to give optimal GMP performance.  If the optimal "ABI"
> does not work, the next best "ABI" is tried, and so on.

In the case that the user explicitly selects a "compiler-ABI" (somewhat
unclear exactly what that means, for the moment, lets say it's
equivalent to explicitly setting CFLAGS). Then it would make sense to
try to detect which ABI that is, and only consider choices of
gmp-ABI which are consistent with the user's compiler-ABI.

It's a bit unclear to me in which cases there are multiple gmp-ABI
consistent with the same compiler-ABI.

Regards,
/Niels

-- 
Niels Möller. PGP-encrypted email is preferred. Keyid 368C6677.
Internet email is subject to wholesale government surveillance.
___
gmp-bugs mailing list
gmp-bugs@gmplib.org
https://gmplib.org/mailman/listinfo/gmp-bugs

Re: Configure fails on 32-bit platform

[Torbjörn Granlund]

Vincent Lefevre  writes:

  So, if I understand correctly, this means that if the user chooses
  to set -m32 in CFLAGS, he might have to try different ABI values
  before finding one that works (because -m32 does not necessarily
  imply 32-bit limbs). This is not nice.

It is not easy to find anything better than what we have today.

The current strategy was chosen to work best for most users, and work
best here means to give optimal GMP performance.  If the optimal "ABI"
does not work, the next best "ABI" is tried, and so on.

The optimal "ABI" can easily be 5 times faster then the 2nd best "ABI".

Clearly this has some drawbacks.  E.g., some 64-bit systems default to
generating 32-bit code, and this code might not link to the newly built
GMP.  

It is less common that people set CC/CFLAGS to bad values (or at least
we don't hear about that very often).  I don't think we should try to
accomodate that since it would result in lots of fragile complexity.
(If you don't agree, please see the logic for "ABI" -> (CFLAGS,mpn_path)
selection.)

-- 
Torbjörn
Please encrypt, key id 0xC8601622
___
gmp-bugs mailing list
gmp-bugs@gmplib.org
https://gmplib.org/mailman/listinfo/gmp-bugs

Re: Configure fails on 32-bit platform

[Vincent Lefevre]

On 2018-02-12 10:31:23 +0100, Torbjorn Granlund wrote:
> Vincent Lefevre  writes:
> 
>   As written above, this is for C compilers. But GMP also has assembler
>   code. So, you need to provide an option that will affect the assembler
>   code. This is what ABI is for.
>   
>   That said, perhaps GMP might be improved to detect the ABI by a
>   simple parsing of $CFLAGS when provided by the user (in case values
>   like -m32 or -m64 are standard). The reason is that the user could
>   have a generic CFLAGS for various software, while AFAIK, ABI is
>   specific to GMP.
> 
> That would be nice but unfortunately is not going to work.
> 
> We use "ABI" in a somewhat non-standard way.  It mainly refers to the
> limb size.  The same exact compiler flags might be correct for several
> choices of "ABI".

So, if I understand correctly, this means that if the user chooses
to set -m32 in CFLAGS, he might have to try different ABI values
before finding one that works (because -m32 does not necessarily
imply 32-bit limbs). This is not nice.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)
___
gmp-bugs mailing list
gmp-bugs@gmplib.org
https://gmplib.org/mailman/listinfo/gmp-bugs

Re: Configure fails on 32-bit platform

[Niels Möller]

Vincent Lefevre  writes:

> That said, perhaps GMP might be improved to detect the ABI by a
> simple parsing of $CFLAGS when provided by the user (in case values
> like -m32 or -m64 are standard).

In Nettle, I try to detect the ABI used by the configured C compiler,
with a configure test like

  case "$host_cpu" in
[x86_64 | amd64])
  AC_TRY_COMPILE([
  #if defined(__x86_64__) || defined(__arch64__)
  #error 64-bit x86
  #endif
  ], [], [
ABI=32
  ], [
ABI=64
  ])
  ;;
  ...

(and the above misses x32). That's a bit verbose, but I think it's less
brittle than trying to parse compiler flags. For one, how would we know
which ABI the compiler uses by default?

The result is used when selecting assembly code.

But then the way I recommend to configure ABI is still not to set
CFLAGS, but to set CC. E.g.,

  ./configure CC='gcc -m32' CXX='g++ -m32'

Regards,
/Niels

-- 
Niels Möller. PGP-encrypted email is preferred. Keyid 368C6677.
Internet email is subject to wholesale government surveillance.
___
gmp-bugs mailing list
gmp-bugs@gmplib.org
https://gmplib.org/mailman/listinfo/gmp-bugs

Re: Configure fails on 32-bit platform

[Torbjörn Granlund]

Vincent Lefevre  writes:

  As written above, this is for C compilers. But GMP also has assembler
  code. So, you need to provide an option that will affect the assembler
  code. This is what ABI is for.
  
  That said, perhaps GMP might be improved to detect the ABI by a
  simple parsing of $CFLAGS when provided by the user (in case values
  like -m32 or -m64 are standard). The reason is that the user could
  have a generic CFLAGS for various software, while AFAIK, ABI is
  specific to GMP.

That would be nice but unfortunately is not going to work.

We use "ABI" in a somewhat non-standard way.  It mainly refers to the
limb size.  The same exact compiler flags might be correct for several
choices of "ABI".

-- 
Torbjörn
Please encrypt, key id 0xC8601622
___
gmp-bugs mailing list
gmp-bugs@gmplib.org
https://gmplib.org/mailman/listinfo/gmp-bugs

Re: Configure fails on 32-bit platform

[Vincent Lefevre]

On 2018-02-11 19:21:33 -0500, Jeffrey Walton wrote:
> That's not true. In fact, Stallman specifically tells the project to
> adds the flags it needs. Below is from Section 7.2.3 of
> https://www.gnu.org/prep/standards/standards.html. This would fix the
> ARM compile problem, too:
> 
> 
> 
> If there are C compiler options that must be used for proper
> compilation of certain files, do not include them in CFLAGS. Users
> expect to be able to specify CFLAGS freely themselves. Instead,
> arrange to pass the necessary options to the C compiler independently
> of CFLAGS, by writing them explicitly in the compilation commands or
> by defining an implicit rule, like this:
[...]

As written above, this is for C compilers. But GMP also has assembler
code. So, you need to provide an option that will affect the assembler
code. This is what ABI is for.

That said, perhaps GMP might be improved to detect the ABI by a
simple parsing of $CFLAGS when provided by the user (in case values
like -m32 or -m64 are standard). The reason is that the user could
have a generic CFLAGS for various software, while AFAIK, ABI is
specific to GMP.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)
___
gmp-bugs mailing list
gmp-bugs@gmplib.org
https://gmplib.org/mailman/listinfo/gmp-bugs

Re: Configure fails on 32-bit platform

[Jeffrey Walton]

On Sun, Feb 11, 2018 at 4:40 PM, Niels Möller  wrote:
> Jeffrey Walton  writes:
>
>> But please see -m32 -march=native, which was provided to configure to
>> configure with.
>
> Setting CFLAGS simply specifies what flags to be passed to the C
> compiler, totally overriding configure's automatic selection of compiler
> flags. But CFLAGS is *not* interpreted by configure in any way.
>
> Please use the documented mechanism to get the configuration you want.

That's not true. In fact, Stallman specifically tells the project to
adds the flags it needs. Below is from Section 7.2.3 of
https://www.gnu.org/prep/standards/standards.html. This would fix the
ARM compile problem, too:



If there are C compiler options that must be used for proper
compilation of certain files, do not include them in CFLAGS. Users
expect to be able to specify CFLAGS freely themselves. Instead,
arrange to pass the necessary options to the C compiler independently
of CFLAGS, by writing them explicitly in the compilation commands or
by defining an implicit rule, like this:

CFLAGS = -g
ALL_CFLAGS = -I. $(CFLAGS)
.c.o:
$(CC) -c $(CPPFLAGS) $(ALL_CFLAGS) $<

Do include the ‘-g’ option in CFLAGS, because that is not required for
proper compilation. You can consider it a default that is only
recommended. If the package is set up so that it is compiled with GCC
by default, then you might as well include ‘-O’ in the default value
of CFLAGS as well.



Jeff
___
gmp-bugs mailing list
gmp-bugs@gmplib.org
https://gmplib.org/mailman/listinfo/gmp-bugs

Re: Configure fails on 32-bit platform

[Niels Möller]

Jeffrey Walton  writes:

> But please see -m32 -march=native, which was provided to configure to
> configure with.

Setting CFLAGS simply specifies what flags to be passed to the C
compiler, totally overriding configure's automatic selection of compiler
flags. But CFLAGS is *not* interpreted by configure in any way.

Please use the documented mechanism to get the configuration you want.

Regards,
/Niels

-- 
Niels Möller. PGP-encrypted email is preferred. Keyid 368C6677.
Internet email is subject to wholesale government surveillance.
___
gmp-bugs mailing list
gmp-bugs@gmplib.org
https://gmplib.org/mailman/listinfo/gmp-bugs