sage-5.0.beta14 : Error building GMP-ECM

[Rajeev Singh]

Hi,

I got the following error while compiling sage-5.0.beta14. I had got
the same error with sage-5.0.beta13 which I reported earlier.


libtool: compile: gcc -DHAVE_CONFIG_H -I. -I./x86_64
-I/home/rajeev/bin/sage-5.0.beta14/local/include
-I/home/rajeev/bin/sage-5.0.beta14/local/include -march=native -g -O3
-fPIC -MT libecm_la-mul_fft.lo -MD -MP -MF .deps/libecm_la-mul_fft.Tpo
-c mul_fft.c -o libecm_la-mul_fft.o
: Assembler messages:
:16797: Error: no such instruction: `pmulld %xmm2,%xmm0'
:1023: Error: no such instruction: `pmulld %xmm2,%xmm0'
:608: Error: no such instruction: `pmulld %xmm2,%xmm0'
make[4]: *** [libecm_la-mul_fft.lo] Error 1


Some relevant information -

SUSE Linux Enterprise Server 10 (x86_64)
VERSION = 10
PATCHLEVEL = 2

gcc version 4.1.2 20070115 (SUSE Linux)

I have a working copy of sage-4.8 on this machine.

Rajeev

[Volker Braun]

Can you try this version:

http://trac.sagemath.org/sage_trac/ticket/12830

[Rajeev Singh]

Hi,

I get the same error. I used the following commands -

$ pwd
/home/rajeev/bin/sage-5.0.beta14
$ ./sage -f http://boxen.math.washington.edu/home/leif/Sage/spkgs/ecm-6.3.p7.spkg

Rajeev

> --
> To post to this group, send an email to sage-...@googlegroups.com
> To unsubscribe from this group, send an email to
> sage-devel+...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/sage-devel
> URL: http://www.sagemath.org

[Volker Braun]

Seems like you have outdated binutils, the assembler doesn't understand the gcc output. What is the output of "as --version"?

> sage-devel+unsubscribe@googlegroups.com

[Rajeev Singh]

Hi,

Here's the assembler's info -

$ as --version
GNU assembler 2.16.91.0.5 20051219 (SUSE Linux)
Copyright 2005 Free Software Foundation, Inc.
This program is free software; you may redistribute it under the terms of
the GNU General Public License. This program has absolutely no warranty.
This assembler was configured for a target of `x86_64-suse-linux'.

Rajeev

>> > sage-devel+...@googlegroups.com

>> > For more options, visit this group at
>> > http://groups.google.com/group/sage-devel
>> > URL: http://www.sagemath.org
>

> --
> To post to this group, send an email to sage-...@googlegroups.com
> To unsubscribe from this group, send an email to

> sage-devel+...@googlegroups.com

[Volker Braun]

Its pretty clear that this version does not support SSE4.

>> > sage-devel+unsubscribe@googlegroups.com

>> > For more options, visit this group at
>> > http://groups.google.com/group/sage-devel
>> > URL: http://www.sagemath.org
>
> --
> To post to this group, send an email to sage-...@googlegroups.com
> To unsubscribe from this group, send an email to

> sage-devel+unsubscribe@googlegroups.com

[Jeroen Demeyer]

On 2012-04-29 18:41, Rajeev Singh wrote:
> Hi,
>
> I got the following error while compiling sage-5.0.beta14.

Could you please post the contents of
spkg/logs/mpir-2.1.3.p9.log

[Volker Braun]

Did your compilation build the bundled gcc or did it use the system gcc? For example, is there a $SAGE_LOCAL/bin/gcc in your incomplete compile? If you can, post the whole log e.g. to pastebin.

>> > sage-devel+unsubscribe@googlegroups.com

>> > For more options, visit this group at
>> > http://groups.google.com/group/sage-devel
>> > URL: http://www.sagemath.org
>
> --
> To post to this group, send an email to sage-...@googlegroups.com
> To unsubscribe from this group, send an email to

> sage-devel+unsubscribe@googlegroups.com

[leif]

On Apr 29, 9:23 pm, Volker Braun <vbraun.n...@gmail.com> wrote:
> Its pretty clear that this version does not support SSE4.

... and, frankly speaking, one shouldn't be surprised that Sage
doesn't support ancient Linux distros, at least not out-of-the-box.

There are a couple of ways to fix / work around this, e.g.:

- Update 'gas' (the GNU assembler), or your whole binutils.

- Build Sage [5.x] with SAGE_INSTALL_GCC=no.

- Use your system compiler to build the spkg:
$ env CC=/usr/bin/gcc ./sage -i ...

- Set CFLAGS such that the GCC shipped with Sage will produce code
for a more generic architecture / CPU family (whose instruction set
your assembler knows):
$ env CFLAGS="-march=... ..." ./sage -i ...


-leif

> On Sunday, April 29, 2012 2:07:53 PM UTC-4, Rajeev wrote:
>
> > Hi,
>
> > Here's the assembler's info -
>
> > $ as --version
> > GNU assembler 2.16.91.0.5 20051219 (SUSE Linux)
> > Copyright 2005 Free Software Foundation, Inc.
> > This program is free software; you may redistribute it under the terms of
> > the GNU General Public License.  This program has absolutely no warranty.
> > This assembler was configured for a target of `x86_64-suse-linux'.
>
> > Rajeev
>

> > On Sun, Apr 29, 2012 at 11:12 PM, Volker Braun <vbraun.n...@gmail.com>

> > wrote:
> > > Seems like you have outdated binutils, the assembler doesn't understand
> > the
> > > gcc output. What is the output of "as --version"?
>
> > > On Sunday, April 29, 2012 12:58:48 PM UTC-4, Rajeev wrote:
>
> > >> Hi,
>
> > >> I get the same error. I used the following commands -
>
> > >> $ pwd
> > >> /home/rajeev/bin/sage-5.0.beta14
> > >> $ ./sage -f
> > >>http://boxen.math.washington.edu/home/leif/Sage/spkgs/ecm-6.3.p7.spkg
>
> > >> Rajeev
>

> > >> On Sun, Apr 29, 2012 at 10:22 PM, Volker Braun <vbraun.n...@gmail.com>

[Rajeev Singh]

Hi,

gcc was installed by Sage. You can find the install log here -

http://www.imsc.res.in/~rajeev/install.log

Rajeev

>> >> > sage-devel+...@googlegroups.com

>> >> > For more options, visit this group at
>> >> > http://groups.google.com/group/sage-devel
>> >> > URL: http://www.sagemath.org
>> >
>> > --
>> > To post to this group, send an email to sage-...@googlegroups.com
>> > To unsubscribe from this group, send an email to

>> > sage-devel+...@googlegroups.com

>> > For more options, visit this group at
>> > http://groups.google.com/group/sage-devel
>> > URL: http://www.sagemath.org
>
> --
> To post to this group, send an email to sage-...@googlegroups.com
> To unsubscribe from this group, send an email to

> sage-devel+...@googlegroups.com

[Volker Braun]

Given that compiler optimizations are likely to use new additions to the ISA, I propose that our strategy for deciding whether or not to build gcc should be:

1) use OS provided gcc if it works fine (of course)

2) build our own gcc on OSX (very popular and hopelessly broken, but at least we know the binutils version)

3) build with reduced optimization if the OS gcc is broken but works with less optimization (say, -O2 -march=generic)

4) build our own gcc if the OS gcc is hopelessly broken

Automatically reducing optimization levels and switching between different gcc installs could be done by the compilerwrapper.

PS: We should ship sage-5.0 first! 

[Jeroen Demeyer]

On 2012-04-30 16:36, Volker Braun wrote:
> Given that compiler optimizations are likely to use new additions to the
> ISA, I propose that our strategy for deciding whether or not to build
> gcc should be:
>
> 1) use OS provided gcc if it works fine (of course)
>
> 2) build our own gcc on OSX (very popular and hopelessly broken, but at
> least we know the binutils version)
>
> 3) build with reduced optimization if the OS gcc is broken but works
> with less optimization (say, -O2 -march=generic)
>
> 4) build our own gcc if the OS gcc is hopelessly broken

Nice idea, but how are you going to distinguish between the various cases?

[Volker Braun]

Essentially by maintaining a list of gcc versions / architectures that work well enough with reduced optimizations, and that are hopelessly broken. This can just be some shell script that shitlists specific compilers...

[Dr. David Kirkby]

On 04/30/12 03:45 AM, leif wrote:
> On Apr 29, 9:23 pm, Volker Braun<vbraun.n...@gmail.com> wrote:
>> Its pretty clear that this version does not support SSE4.
>
> ... and, frankly speaking, one shouldn't be surprised that Sage
> doesn't support ancient Linux distros, at least not out-of-the-box.
>
> There are a couple of ways to fix / work around this, e.g.:
>
> - Update 'gas' (the GNU assembler), or your whole binutils.
>
> - Build Sage [5.x] with SAGE_INSTALL_GCC=no.
>
> - Use your system compiler to build the spkg:
> $ env CC=/usr/bin/gcc ./sage -i ...

Actually, it depends on the CPU the person has. I'm building the latest Sage
source with an even older assembler, on a CentOS 4.7 system, which I had to fake
to report it was Redhat, in order to install some software.

[drkirkby@blackcap ~]$ cat /etc/redhat-release
Red Hat Enterprise Linux AS release 4 (Nahant Update 7)
#CentOS release 4.7 (Final)


[drkirkby@blackcap ~]$ as --version
GNU assembler 2.15.92.0.2 20040927
Copyright 2002 Free Software Foundation, Inc.

This program is free software; you may redistribute it under the terms of
the GNU General Public License. This program has absolutely no warranty.

This assembler was configured for a target of `x86_64-redhat-linux'.
[drkirkby@blackcap ~]$

The difference is, my 3.16 GHz Intel X5460 Xeon processors don't have the SSE4
instructions.

I'm guessing, if you prevented the compiler from using late instructions, the
assembler would not complain. But updating the assembler seems a better idea.
But perhaps an option to use a more generic set of instructions would be nice.
It would mean its possible to distribute the binaries to a wider range of people.


[drkirkby@blackcap ~]$ cat /proc/cpuinfo
processor : 0
vendor_id : GenuineIntel
cpu family : 6
model : 23
model name : Intel(R) Xeon(R) CPU X5460 @ 3.16GHz
stepping : 10
cpu MHz : 1992.000
cache size : 6144 KB
physical id : 0
siblings : 4
core id : 0
cpu cores : 4
fpu : yes
fpu_exception : yes
cpuid level : 13
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36
clflush dts acpi mmx fxsr sse sse2 ss ht tm syscall lm pni monitor ds_cpl est
tm2 cx16 xtpr lahf_lm
bogomips : 6321.69
clflush size : 64
cache_alignment : 64
address sizes : 38 bits physical, 48 bits virtual
power management:

processor : 1
vendor_id : GenuineIntel
cpu family : 6
model : 23
model name : Intel(R) Xeon(R) CPU X5460 @ 3.16GHz
stepping : 10
cpu MHz : 1992.000
cache size : 6144 KB
physical id : 0
siblings : 4
core id : 1
cpu cores : 4
fpu : yes
fpu_exception : yes
cpuid level : 13
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36
clflush dts acpi mmx fxsr sse sse2 ss ht tm syscall lm pni monitor ds_cpl est
tm2 cx16 xtpr lahf_lm
bogomips : 6317.46
clflush size : 64
cache_alignment : 64
address sizes : 38 bits physical, 48 bits virtual
power management:

processor : 2
vendor_id : GenuineIntel
cpu family : 6
model : 23
model name : Intel(R) Xeon(R) CPU X5460 @ 3.16GHz
stepping : 10
cpu MHz : 1992.000
cache size : 6144 KB
physical id : 0
siblings : 4
core id : 2
cpu cores : 4
fpu : yes
fpu_exception : yes
cpuid level : 13
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36
clflush dts acpi mmx fxsr sse sse2 ss ht tm syscall lm pni monitor ds_cpl est
tm2 cx16 xtpr lahf_lm
bogomips : 6317.49
clflush size : 64
cache_alignment : 64
address sizes : 38 bits physical, 48 bits virtual
power management:

processor : 3
vendor_id : GenuineIntel
cpu family : 6
model : 23
model name : Intel(R) Xeon(R) CPU X5460 @ 3.16GHz
stepping : 10
cpu MHz : 1992.000
cache size : 6144 KB
physical id : 0
siblings : 4
core id : 3
cpu cores : 4
fpu : yes
fpu_exception : yes
cpuid level : 13
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36
clflush dts acpi mmx fxsr sse sse2 ss ht tm syscall lm pni monitor ds_cpl est
tm2 cx16 xtpr lahf_lm
bogomips : 6317.51
clflush size : 64
cache_alignment : 64
address sizes : 38 bits physical, 48 bits virtual
power management:

processor : 4
vendor_id : GenuineIntel
cpu family : 6
model : 23
model name : Intel(R) Xeon(R) CPU X5460 @ 3.16GHz
stepping : 10
cpu MHz : 2324.000
cache size : 6144 KB
physical id : 1
siblings : 4
core id : 4
cpu cores : 4
fpu : yes
fpu_exception : yes
cpuid level : 13
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36
clflush dts acpi mmx fxsr sse sse2 ss ht tm syscall lm pni monitor ds_cpl est
tm2 cx16 xtpr lahf_lm
bogomips : 6317.54
clflush size : 64
cache_alignment : 64
address sizes : 38 bits physical, 48 bits virtual
power management:

processor : 5
vendor_id : GenuineIntel
cpu family : 6
model : 23
model name : Intel(R) Xeon(R) CPU X5460 @ 3.16GHz
stepping : 10
cpu MHz : 2324.000
cache size : 6144 KB
physical id : 1
siblings : 4
core id : 5
cpu cores : 4
fpu : yes
fpu_exception : yes
cpuid level : 13
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36
clflush dts acpi mmx fxsr sse sse2 ss ht tm syscall lm pni monitor ds_cpl est
tm2 cx16 xtpr lahf_lm
bogomips : 6317.54
clflush size : 64
cache_alignment : 64
address sizes : 38 bits physical, 48 bits virtual
power management:

processor : 6
vendor_id : GenuineIntel
cpu family : 6
model : 23
model name : Intel(R) Xeon(R) CPU X5460 @ 3.16GHz
stepping : 10
cpu MHz : 2324.000
cache size : 6144 KB
physical id : 1
siblings : 4
core id : 6
cpu cores : 4
fpu : yes
fpu_exception : yes
cpuid level : 13
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36
clflush dts acpi mmx fxsr sse sse2 ss ht tm syscall lm pni monitor ds_cpl est
tm2 cx16 xtpr lahf_lm
bogomips : 6317.53
clflush size : 64
cache_alignment : 64
address sizes : 38 bits physical, 48 bits virtual
power management:

processor : 7
vendor_id : GenuineIntel
cpu family : 6
model : 23
model name : Intel(R) Xeon(R) CPU X5460 @ 3.16GHz
stepping : 10
cpu MHz : 2324.000
cache size : 6144 KB
physical id : 1
siblings : 4
core id : 7
cpu cores : 4
fpu : yes
fpu_exception : yes
cpuid level : 13
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36
clflush dts acpi mmx fxsr sse sse2 ss ht tm syscall lm pni monitor ds_cpl est
tm2 cx16 xtpr lahf_lm
bogomips : 6317.53
clflush size : 64
cache_alignment : 64
address sizes : 38 bits physical, 48 bits virtual
power management:

--
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?

[Jeroen Demeyer]

On 2012-04-30 22:39, Dr. David Kirkby wrote:
> But perhaps an option to use a more
> generic set of instructions would be nice.

To me, it just shows we really need to implement good default CFLAGS
instead of stupidly using -march=native as in the ECM spkg.

> It would mean its possible to
> distribute the binaries to a wider range of people.

That's already possible by setting SAGE_FAT_BINARY=yes

[David Kirkby]

On 30 April 2012 16:23, Volker Braun <vbrau...@gmail.com> wrote:
> Essentially by maintaining a list of gcc versions / architectures that work
> well enough with reduced optimizations, and that are hopelessly broken. This
> can just be some shell script that shitlists specific compilers...

A problem with that approach is that a compiler can be broken on one
platform, or verions of linux, but ok on another. A better approach is
probaby the one taken by autoconf - test the compiler. If you know a
compiler computes 1+1=3, then write a test for that. Autoconf is good
for this.

Dave

[Volker Braun]

Autoconf-style tests would be nice but I think it'll be painful to write tests for obscure asm issues (like, do binutils support SSE4?). Or compliler releases that die in an ICE after compiling pari for a while. Maybe we should have a combination of both, first autoconf tests and then supplement them with a list of specific (distribution, gcc version) pairs that don't work.

[Jeroen Demeyer]

On 2012-05-01 00:08, Volker Braun wrote:
> (like, do binutils support SSE4?)
MPIR does this.