Bugzilla Bug 143484

I tried to emerge ntl-5.4. It compiled OK, then started
make check
several checks succeeded, but then one check seems to take an infinite amount
of time, using 100% of cpu (I interrupted after about 6 hours) The last thing I
see is

making subset
make[1]: Entering directory `/var/tmp/portage/ntl-5.4-r1/work/ntl-5.4/src'
g++ -I../include -I.  -O2 -march=pentium3 -Wno-deprecated  -o subset subset.c
ntl.a   -lgmp -lm
make[1]: Leaving directory `/var/tmp/portage/ntl-5.4-r1/work/ntl-5.4/src'
subset 40 40 20 10 999999 f
n: b: size: prune: seed: alg [fqQxr]: +

Here's my emerge --info

Portage 2.1-r1 (default-linux/x86/2005.1, gcc-3.4.6, glibc-2.3.6-r4,
2.6.16-suspend2-r8 i686)
=================================================================
System uname: 2.6.16-suspend2-r8 i686 Intel(R) Pentium(R) M processor 1400MHz
Gentoo Base System version 1.6.15
app-admin/eselect-compiler: [Not Present]
dev-lang/python:     2.4.3-r1
dev-python/pycrypto: 2.0.1-r5
dev-util/ccache:     [Not Present]
dev-util/confcache:  [Not Present]
sys-apps/sandbox:    1.2.17
sys-devel/autoconf:  2.13, 2.59-r7
sys-devel/automake:  1.4_p6, 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.6-r2
sys-devel/binutils:  2.16.1-r3
sys-devel/gcc-config: 1.3.13-r3
sys-devel/libtool:   1.5.22
virtual/os-headers:  2.6.11-r2
ACCEPT_KEYWORDS="x86"
AUTOCLEAN="yes"
CBUILD="i686-pc-linux-gnu"
CFLAGS="-O2 -march=pentium3"
CHOST="i686-pc-linux-gnu"
CONFIG_PROTECT="/etc /usr/kde/3.5/env /usr/kde/3.5/share/config
/usr/kde/3.5/shutdown /usr/share/X11/xkb /usr/share/config"
CONFIG_PROTECT_MASK="/etc/env.d /etc/gconf /etc/revdep-rebuild /etc/terminfo
/etc/texmf/web2c"
CXXFLAGS="-O2 -march=pentium3"
DISTDIR="/usr/portage/distfiles"
FEATURES="autoconfig collision-protect distlocks metadata-transfer
parallel-fetch sandbox sfperms strict"
GENTOO_MIRRORS="ftp://sunsite.informatik.rwth-aachen.de/pub/Linux/gentoo
ftp://linux.rz.ruhr-uni-bochum.de/gentoo-mirror/
ftp://ftp.uni-erlangen.de/pub/mirrors/gentoo
ftp://ftp.join.uni-muenster.de/pub/linux/distributions/gentoo
ftp://ftp.wh2.tu-dresden.de/pub/mirrors/gentoo
ftp://ftp-stud.fht-esslingen.de/pub/Mirrors/gentoo/
ftp://ftp.rz.tu-bs.de/pub/mirror/ftp.gentoo.org/gentoo-distfiles/"
LINGUAS="ru"
PKGDIR="/usr/portage/packages"
PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress
--force --whole-file --delete --delete-after --stats --timeout=180
--exclude='/distfiles' --exclude='/local' --exclude='/packages'"
PORTAGE_TMPDIR="/var/tmp"
PORTDIR="/usr/portage"
PORTDIR_OVERLAY="/usr/local/portage /usr/local/sci"
SYNC="rsync://rsync.gentoo.org/gentoo-portage"
USE="x86 X acpi alsa arts avi bash-completion berkdb bitmap-fonts blas
browserplugin cdr cli crypt cups dlloader doc dri dvd eds emacs emboss encode
ffmpeg firefox foomaticdb fortran gdbm gif gmp gnome gpm gstreamer gtk gtk2
imlib isdnlog jpeg kde lapack leim libg++ libwww mad mikmod motif mozilla mp3
mpeg mule ncurses nls nptl nsplugin offensive ogg oggvorbis opengl oss pam pcre
pdflib perl png pppd python qt qt3 qt4 quicktime readline reflection sdl
session speex spell spl ssl tcltk tcpd tetex truetype truetype-fonts
type1-fonts vorbis win32codecs xine xml2 xmms xorg xv zlib elibc_glibc
input_devices_keyboard input_devices_mouse kernel_linux linguas_ru userland_GNU
video_cards_i810 video_cards_vesa video_cards_fbdev"
Unset:  CTARGET, EMERGE_DEFAULT_OPTS, INSTALL_MASK, LANG, LC_ALL, LDFLAGS,
MAKEOPTS, PORTAGE_RSYNC_EXTRA_OPTS

Same here ... I just joined the NTL mailing list -- this could be upstream.

Looks like it's upstream ... stay tuned.

I was able to reproduce it from source, so I posted a question about it on the
NTL mailing list. Meanwhile, has anyone tried using less than "-O2"
optimization or other versions of GCC (I have 3.4.6). This kind of looks like a
miscompile or misoptimize; I'm assuming the "make check" step must have worked
on *some* platform. By the way, both the 5.3 and 5.4 ebuilds fail this way.

I've upgraded gcc to 4.1.1. Nothing changed - it loops at the same point.

(In reply to comment #3)
> I was able to reproduce it from source, so I posted a question about it on the
> NTL mailing list.

Any reply? It's unusable, killed the compile after one hour when it got stuck
on one of the tests. Should be p.masked.

(In reply to comment #5)
> (In reply to comment #3)
> > I was able to reproduce it from source, so I posted a question about it on the
> > NTL mailing list.
> 
> Any reply? It's unusable, killed the compile after one hour when it got stuck
> on one of the tests. Should be p.masked.
> 

I haven't seen one. I'm off to RubyConf today, but I'll pulse the list again
when I get on line tonight. I just saw a message from the list today, so I know
someone is reading and writing to it other than myself. :)

Actually, I think if you don't do "make check" in the ebuild, the package will
be usable. I'd still leave it as "testing", though -- definitely not stable if
"make check" doesn't terminate.

(In reply to comment #7)
> Actually, I think if you don't do "make check" in the ebuild, the package will
> be usable. I'd still leave it as "testing", though -- definitely not stable if
> "make check" doesn't terminate.
> 

This is actually not a bug. The developers are just so used to having
mainframes with more than 100 CPUs. To them, make check will finish in an hour
or so, not bad. Change the TestScript will fix the problem.

Created an attachment (id=100191) [edit]
Entire directory containing new ebuild ntl-5.3-r1

This fixes the infinite loop problem.

dev-cpp, is it possible to give the patch provided here a look?  Some more bugs
rely on fixing this.

Christian: Sure :-) But this ebuild has more than one problem, that I can tell
(explicitly setting compiler & tools, ignoring CXXFLAGS, wrong CFLAGS, make
check in src_compile, library install dir wrong for 64bit, etc.).

Finally fixed :-)