From tinderbox at freebsd.org  Sun Nov  1 21:23:01 2009
From: tinderbox at freebsd.org (FreeBSD Tinderbox)
Date: Sun Nov  1 21:23:07 2009
Subject: [releng_8 tinderbox] failure on ia64/ia64
Message-ID: <200911012220.nA1MKiFl089533@freebsd-current.sentex.ca>

TB --- 2009-11-01 22:09:44 - tinderbox 2.6 running on freebsd-current.sentex.ca
TB --- 2009-11-01 22:09:44 - starting RELENG_8 tinderbox run for ia64/ia64
TB --- 2009-11-01 22:09:44 - cleaning the object tree
TB --- 2009-11-01 22:10:01 - cvsupping the source tree
TB --- 2009-11-01 22:10:01 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/RELENG_8/ia64/ia64/supfile
TB --- 2009-11-01 22:10:35 - building world
TB --- 2009-11-01 22:10:35 - MAKEOBJDIRPREFIX=/obj
TB --- 2009-11-01 22:10:35 - PATH=/usr/bin:/usr/sbin:/bin:/sbin
TB --- 2009-11-01 22:10:35 - TARGET=ia64
TB --- 2009-11-01 22:10:35 - TARGET_ARCH=ia64
TB --- 2009-11-01 22:10:35 - TZ=UTC
TB --- 2009-11-01 22:10:35 - __MAKE_CONF=/dev/null
TB --- 2009-11-01 22:10:35 - cd /src
TB --- 2009-11-01 22:10:35 - /usr/bin/make -B buildworld
>>> World build started on Sun Nov  1 22:10:36 UTC 2009
>>> Rebuilding the temporary build tree
>>> stage 1.1: legacy release compatibility shims
>>> stage 1.2: bootstrap tools
>>> stage 2.1: cleaning up the object tree
>>> stage 2.2: rebuilding the object tree
>>> stage 2.3: build tools
>>> stage 3: cross tools
>>> stage 4.1: building includes
>>> stage 4.2: building libraries
[...]
cc -O2 -pipe  -I/src/lib/libc/include -I/src/lib/libc/../../include -I/src/lib/libc/ia64 -DNLS -D__DBINTERFACE_PRIVATE -I/src/lib/libc/../../contrib/gdtoa -DINET6 -I/obj/ia64/src/lib/libc -I/src/lib/libc/resolv -D_ACL_PRIVATE -DPOSIX_MISTAKE -I/src/lib/libc/locale -DBROKEN_DES -DPORTMAP -DDES_BUILTIN -I/src/lib/libc/rpc -DYP -DNS_CACHING -DSYMBOL_VERSIONING -std=gnu99 -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /src/lib/libc/string/wmemmove.c
cc -O2 -pipe  -I/src/lib/libc/include -I/src/lib/libc/../../include -I/src/lib/libc/ia64 -DNLS -D__DBINTERFACE_PRIVATE -I/src/lib/libc/../../contrib/gdtoa -DINET6 -I/obj/ia64/src/lib/libc -I/src/lib/libc/resolv -D_ACL_PRIVATE -DPOSIX_MISTAKE -I/src/lib/libc/locale -DBROKEN_DES -DPORTMAP -DDES_BUILTIN -I/src/lib/libc/rpc -DYP -DNS_CACHING -DSYMBOL_VERSIONING -std=gnu99 -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /src/lib/libc/string/wmemset.c
building static c library
ranlib libc.a
cat /src/lib/libc/ia64/Symbol.map /src/lib/libc/db/Symbol.map /src/lib/libc/compat-43/Symbol.map /src/lib/libc/gdtoa/Symbol.map /src/lib/libc/gen/Symbol.map /src/lib/libc/gmon/Symbol.map /src/lib/libc/inet/Symbol.map /src/lib/libc/locale/Symbol.map /src/lib/libc/nameser/Symbol.map /src/lib/libc/net/Symbol.map /src/lib/libc/nls/Symbol.map /src/lib/libc/posix1e/Symbol.map /src/lib/libc/regex/Symbol.map /src/lib/libc/resolv/Symbol.map /src/lib/libc/stdio/Symbol.map /src/lib/libc/stdlib/Symbol.map /src/lib/libc/stdtime/Symbol.map /src/lib/libc/string/Symbol.map /src/lib/libc/sys/Symbol.map /src/lib/libc/rpc/Symbol.map /src/lib/libc/uuid/Symbol.map /src/lib/libc/xdr/Symbol.map /src/lib/libc/yp/Symbol.map | cpp - -  | awk -v vfile=/src/lib/libc/Versions.def -f /src/share/mk/version_gen.awk > Version.map
File <stdin>, line 515: Undefined library version `FBSD_1.2'.
File <stdin>, line 516: Symbol `getpagesizes' outside version scope.
2 error(s) total.
*** Error code 1

Stop in /src/lib/libc.
*** Error code 1

Stop in /src.
*** Error code 1

Stop in /src.
*** Error code 1

Stop in /src.
*** Error code 1

Stop in /src.
TB --- 2009-11-01 22:20:44 - WARNING: /usr/bin/make returned exit code  1 
TB --- 2009-11-01 22:20:44 - ERROR: failed to build world
TB --- 2009-11-01 22:20:44 - 470.88 user 88.46 system 660.02 real


http://tinderbox.freebsd.org/tinderbox-releng_8-RELENG_8-ia64-ia64.full
From tinderbox at freebsd.org  Mon Nov  2 02:13:47 2009
From: tinderbox at freebsd.org (FreeBSD Tinderbox)
Date: Mon Nov  2 02:13:53 2009
Subject: [releng_8_0 tinderbox] failure on ia64/ia64
Message-ID: <200911020310.nA23A3M0042159@freebsd-current.sentex.ca>

TB --- 2009-11-02 03:08:34 - tinderbox 2.6 running on freebsd-current.sentex.ca
TB --- 2009-11-02 03:08:34 - starting RELENG_8_0 tinderbox run for ia64/ia64
TB --- 2009-11-02 03:08:34 - cleaning the object tree
TB --- 2009-11-02 03:08:59 - cvsupping the source tree
TB --- 2009-11-02 03:08:59 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/RELENG_8_0/ia64/ia64/supfile
TB --- 2009-11-02 03:09:11 - building world
TB --- 2009-11-02 03:09:11 - MAKEOBJDIRPREFIX=/obj
TB --- 2009-11-02 03:09:11 - PATH=/usr/bin:/usr/sbin:/bin:/sbin
TB --- 2009-11-02 03:09:11 - TARGET=ia64
TB --- 2009-11-02 03:09:11 - TARGET_ARCH=ia64
TB --- 2009-11-02 03:09:11 - TZ=UTC
TB --- 2009-11-02 03:09:11 - __MAKE_CONF=/dev/null
TB --- 2009-11-02 03:09:11 - cd /src
TB --- 2009-11-02 03:09:11 - /usr/bin/make -B buildworld
>>> World build started on Mon Nov  2 03:09:12 UTC 2009
>>> Rebuilding the temporary build tree
>>> stage 1.1: legacy release compatibility shims
>>> stage 1.2: bootstrap tools
>>> stage 2.1: cleaning up the object tree
[...]
===> share/doc/usd/title (cleandir)
rm -f Title.ascii Title.ascii.gz  Title.ps Title.ps.gz  Title.html Title-*.html _stamp.extra
===> share/doc/usd/contents (cleandir)
rm -f contents.ascii contents.ascii.gz  contents.ps contents.ps.gz  contents.html contents-*.html _stamp.extra
===> share/doc/usd/04.csh (cleandir)
rm -f paper.ascii paper.ascii.gz  paper.ps paper.ps.gz  paper.html paper-*.html _stamp.extra
===> share/doc/usd/07.mail (cleandir)
/usr/bin/make: Permission denied
*** Error code 126

Stop in /src/share/doc/usd.
*** Error code 1

Stop in /src/share/doc.
*** Error code 1

Stop in /src/share.
*** Error code 1

Stop in /src.
*** Error code 1

Stop in /src.
*** Error code 1

Stop in /src.
TB --- 2009-11-02 03:10:03 - WARNING: /usr/bin/make returned exit code  1 
TB --- 2009-11-02 03:10:03 - ERROR: failed to build world
TB --- 2009-11-02 03:10:03 - 29.73 user 20.99 system 89.52 real


http://tinderbox.freebsd.org/tinderbox-releng_8-RELENG_8_0-ia64-ia64.full
From bugmaster at FreeBSD.org  Mon Nov  2 11:06:57 2009
From: bugmaster at FreeBSD.org (FreeBSD bugmaster)
Date: Mon Nov  2 11:08:31 2009
Subject: Current problem reports assigned to freebsd-ia64@FreeBSD.org
Message-ID: <200911021106.nA2B6u1l033627@freefall.freebsd.org>

Note: to view an individual PR, use:
  http://www.freebsd.org/cgi/query-pr.cgi?pr=(number).

The following is a listing of current problems submitted by FreeBSD users.
These represent problem reports covering all versions including
experimental development code and obsolete releases.


S Tracker      Resp.      Description
--------------------------------------------------------------------------------
o ia64/120315  ia64       Backing store switch in exception_save_restart leaves 
o ia64/113102  ia64       [MCA] Multiple records can have the same sequence numb
o ia64/86218   ia64       Mozilla / Firefox: regxpcom or regchrome broken on ia6

3 problems total.

From tinderbox at freebsd.org  Fri Nov  6 09:57:21 2009
From: tinderbox at freebsd.org (FreeBSD Tinderbox)
Date: Fri Nov  6 09:57:38 2009
Subject: [head tinderbox] failure on ia64/ia64
Message-ID: <200911060928.nA69SiY3092243@freebsd-current.sentex.ca>

TB --- 2009-11-06 07:38:14 - tinderbox 2.6 running on freebsd-current.sentex.ca
TB --- 2009-11-06 07:38:14 - starting HEAD tinderbox run for ia64/ia64
TB --- 2009-11-06 07:38:14 - cleaning the object tree
TB --- 2009-11-06 07:38:30 - cvsupping the source tree
TB --- 2009-11-06 07:38:30 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/ia64/ia64/supfile
TB --- 2009-11-06 07:39:17 - building world
TB --- 2009-11-06 07:39:17 - MAKEOBJDIRPREFIX=/obj
TB --- 2009-11-06 07:39:17 - PATH=/usr/bin:/usr/sbin:/bin:/sbin
TB --- 2009-11-06 07:39:17 - TARGET=ia64
TB --- 2009-11-06 07:39:17 - TARGET_ARCH=ia64
TB --- 2009-11-06 07:39:17 - TZ=UTC
TB --- 2009-11-06 07:39:17 - __MAKE_CONF=/dev/null
TB --- 2009-11-06 07:39:17 - cd /src
TB --- 2009-11-06 07:39:17 - /usr/bin/make -B buildworld
>>> World build started on Fri Nov  6 07:39:18 UTC 2009
>>> Rebuilding the temporary build tree
>>> stage 1.1: legacy release compatibility shims
>>> stage 1.2: bootstrap tools
>>> stage 2.1: cleaning up the object tree
>>> stage 2.2: rebuilding the object tree
>>> stage 2.3: build tools
>>> stage 3: cross tools
>>> stage 4.1: building includes
>>> stage 4.2: building libraries
>>> stage 4.3: make dependencies
>>> stage 4.4: building everything
>>> World build completed on Fri Nov  6 08:55:46 UTC 2009
TB --- 2009-11-06 08:55:46 - generating LINT kernel config
TB --- 2009-11-06 08:55:46 - cd /src/sys/ia64/conf
TB --- 2009-11-06 08:55:46 - /usr/bin/make -B LINT
TB --- 2009-11-06 08:55:46 - building LINT kernel
TB --- 2009-11-06 08:55:46 - MAKEOBJDIRPREFIX=/obj
TB --- 2009-11-06 08:55:46 - PATH=/usr/bin:/usr/sbin:/bin:/sbin
TB --- 2009-11-06 08:55:46 - TARGET=ia64
TB --- 2009-11-06 08:55:46 - TARGET_ARCH=ia64
TB --- 2009-11-06 08:55:46 - TZ=UTC
TB --- 2009-11-06 08:55:46 - __MAKE_CONF=/dev/null
TB --- 2009-11-06 08:55:46 - cd /src
TB --- 2009-11-06 08:55:46 - /usr/bin/make -B buildkernel KERNCONF=LINT
>>> Kernel build for LINT started on Fri Nov  6 08:55:46 UTC 2009
>>> stage 1: configuring the kernel
>>> stage 2.1: cleaning up the object tree
>>> stage 2.2: rebuilding the object tree
>>> stage 2.3: build tools
>>> stage 3.1: making dependencies
>>> stage 3.2: building everything
>>> Kernel build for LINT completed on Fri Nov  6 09:22:11 UTC 2009
TB --- 2009-11-06 09:22:11 - building GENERIC kernel
TB --- 2009-11-06 09:22:11 - MAKEOBJDIRPREFIX=/obj
TB --- 2009-11-06 09:22:11 - PATH=/usr/bin:/usr/sbin:/bin:/sbin
TB --- 2009-11-06 09:22:11 - TARGET=ia64
TB --- 2009-11-06 09:22:11 - TARGET_ARCH=ia64
TB --- 2009-11-06 09:22:11 - TZ=UTC
TB --- 2009-11-06 09:22:11 - __MAKE_CONF=/dev/null
TB --- 2009-11-06 09:22:11 - cd /src
TB --- 2009-11-06 09:22:11 - /usr/bin/make -B buildkernel KERNCONF=GENERIC
>>> Kernel build for GENERIC started on Fri Nov  6 09:22:12 UTC 2009
>>> stage 1: configuring the kernel
>>> stage 2.1: cleaning up the object tree
>>> stage 2.2: rebuilding the object tree
>>> stage 2.3: build tools
>>> stage 3.1: making dependencies
>>> stage 3.2: building everything
[...]
vga_pci.o(.text+0x1ad2): In function `vga_pci_resume':
/src/sys/dev/pci/vga_pci.c:189: undefined reference to `vidsw'
vga_pci.o(.text+0x1ae0):/src/sys/dev/pci/vga_pci.c:189: undefined reference to `vidsw'
vga_pci.o(.text+0x1bc2):/src/sys/dev/pci/vga_pci.c:195: undefined reference to `vidsw'
vga_pci.o(.text+0x1bd0):/src/sys/dev/pci/vga_pci.c:195: undefined reference to `vidsw'
vga_pci.o(.text+0x1de2): In function `vga_pci_suspend':
/src/sys/dev/pci/vga_pci.c:140: undefined reference to `vidsw'
vga_pci.o(.text+0x1df0):/src/sys/dev/pci/vga_pci.c:140: more undefined references to `vidsw' follow
*** Error code 1

Stop in /obj/ia64/src/sys/GENERIC.
*** Error code 1

Stop in /src.
*** Error code 1

Stop in /src.
TB --- 2009-11-06 09:28:44 - WARNING: /usr/bin/make returned exit code  1 
TB --- 2009-11-06 09:28:44 - ERROR: failed to build GENERIC kernel
TB --- 2009-11-06 09:28:44 - 5290.95 user 780.90 system 6630.45 real


http://tinderbox.freebsd.org/tinderbox-head-HEAD-ia64-ia64.full
From xcllnt at mac.com  Fri Nov  6 18:52:31 2009
From: xcllnt at mac.com (Marcel Moolenaar)
Date: Fri Nov  6 18:52:37 2009
Subject: 2009 Update
Message-ID: <595329F2-46F2-4393-B8E3-0923694D250D@mac.com>

All,

Anton Shterenlikht reported various problems when he tried ia64
and I'm pleased to announce some updates:

1.  The kernel panic relating to inconsistent high FP registers
     has been fixed. This also means that the following message
     will not appear on the console anymore:
	XXX: bogusly disabled high FP regs

     Versions fixed: 9-CURRENT
     Fix will be merged to 8-STABLE after 8.0-RELEASE

2.  The failures in perl when threading has been enabled have
     been identified as a compiler bug relating to the use of
     statements in expressions. In other words, the expressions
     of the form:
	({ ... })

     All test failures were eliminated when these were recoded
     as proper inline functions. The perl port has not been
     fixed at this time. A definite confidence booster for the
     threading support on ia64 and yet another nail in GCC's
     coffin.

3.  I'm working on getting KDE 4 to build again. It's currently
     failing in optional packages. The base KDE 4 infrastructure
     is up and running and Konqueror (the web browser) seems to
     work quite well, though tends to dump core after a while.
     It would be looked into.

4.  GNOME built and ran fine before, but it's possible that
     things have changed. I'll keep playing with it.

Future work:

1.  I got a VNC server for ia64 building and running, but I can't
     reproduce it at this time, so no fixes for the ports yet. With
     a VNC server, a whole set of new programs can be ported and
     tested better.

2.  I'm planning to change PAGE_SIZE to 16K instead of 8K. It be
     good for performance. More on this later.

3.  More compiler and debugger work. GCC is really not good for
     ia64. I'm planning on refocusing some of my attention towards
     compiler work. Related to this is the debugger. GDB is not
     lacking severely on ia64. Note that I don't plan to fix GDB.
     Neither will I fix GCC. I'll be looking elsewhere.

Overall good news. However, the state of GCC and GDB for ia64 is
still a big problem in my opinion.

FYI,

-- 
Marcel Moolenaar
xcllnt@mac.com



From tinderbox at freebsd.org  Fri Nov  6 20:09:26 2009
From: tinderbox at freebsd.org (FreeBSD Tinderbox)
Date: Fri Nov  6 20:09:43 2009
Subject: [head tinderbox] failure on ia64/ia64
Message-ID: <200911061937.nA6JbkgE058846@freebsd-current.sentex.ca>

TB --- 2009-11-06 17:48:19 - tinderbox 2.6 running on freebsd-current.sentex.ca
TB --- 2009-11-06 17:48:19 - starting HEAD tinderbox run for ia64/ia64
TB --- 2009-11-06 17:48:19 - cleaning the object tree
TB --- 2009-11-06 17:48:33 - cvsupping the source tree
TB --- 2009-11-06 17:48:33 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/ia64/ia64/supfile
TB --- 2009-11-06 17:49:04 - building world
TB --- 2009-11-06 17:49:04 - MAKEOBJDIRPREFIX=/obj
TB --- 2009-11-06 17:49:04 - PATH=/usr/bin:/usr/sbin:/bin:/sbin
TB --- 2009-11-06 17:49:04 - TARGET=ia64
TB --- 2009-11-06 17:49:04 - TARGET_ARCH=ia64
TB --- 2009-11-06 17:49:04 - TZ=UTC
TB --- 2009-11-06 17:49:04 - __MAKE_CONF=/dev/null
TB --- 2009-11-06 17:49:04 - cd /src
TB --- 2009-11-06 17:49:04 - /usr/bin/make -B buildworld
>>> World build started on Fri Nov  6 17:49:04 UTC 2009
>>> Rebuilding the temporary build tree
>>> stage 1.1: legacy release compatibility shims
>>> stage 1.2: bootstrap tools
>>> stage 2.1: cleaning up the object tree
>>> stage 2.2: rebuilding the object tree
>>> stage 2.3: build tools
>>> stage 3: cross tools
>>> stage 4.1: building includes
>>> stage 4.2: building libraries
>>> stage 4.3: make dependencies
>>> stage 4.4: building everything
>>> World build completed on Fri Nov  6 19:04:54 UTC 2009
TB --- 2009-11-06 19:04:54 - generating LINT kernel config
TB --- 2009-11-06 19:04:54 - cd /src/sys/ia64/conf
TB --- 2009-11-06 19:04:54 - /usr/bin/make -B LINT
TB --- 2009-11-06 19:04:54 - building LINT kernel
TB --- 2009-11-06 19:04:54 - MAKEOBJDIRPREFIX=/obj
TB --- 2009-11-06 19:04:54 - PATH=/usr/bin:/usr/sbin:/bin:/sbin
TB --- 2009-11-06 19:04:54 - TARGET=ia64
TB --- 2009-11-06 19:04:54 - TARGET_ARCH=ia64
TB --- 2009-11-06 19:04:54 - TZ=UTC
TB --- 2009-11-06 19:04:54 - __MAKE_CONF=/dev/null
TB --- 2009-11-06 19:04:54 - cd /src
TB --- 2009-11-06 19:04:54 - /usr/bin/make -B buildkernel KERNCONF=LINT
>>> Kernel build for LINT started on Fri Nov  6 19:04:54 UTC 2009
>>> stage 1: configuring the kernel
>>> stage 2.1: cleaning up the object tree
>>> stage 2.2: rebuilding the object tree
>>> stage 2.3: build tools
>>> stage 3.1: making dependencies
>>> stage 3.2: building everything
>>> Kernel build for LINT completed on Fri Nov  6 19:31:25 UTC 2009
TB --- 2009-11-06 19:31:25 - building GENERIC kernel
TB --- 2009-11-06 19:31:25 - MAKEOBJDIRPREFIX=/obj
TB --- 2009-11-06 19:31:25 - PATH=/usr/bin:/usr/sbin:/bin:/sbin
TB --- 2009-11-06 19:31:25 - TARGET=ia64
TB --- 2009-11-06 19:31:25 - TARGET_ARCH=ia64
TB --- 2009-11-06 19:31:25 - TZ=UTC
TB --- 2009-11-06 19:31:25 - __MAKE_CONF=/dev/null
TB --- 2009-11-06 19:31:25 - cd /src
TB --- 2009-11-06 19:31:25 - /usr/bin/make -B buildkernel KERNCONF=GENERIC
>>> Kernel build for GENERIC started on Fri Nov  6 19:31:25 UTC 2009
>>> stage 1: configuring the kernel
>>> stage 2.1: cleaning up the object tree
>>> stage 2.2: rebuilding the object tree
>>> stage 2.3: build tools
>>> stage 3.1: making dependencies
>>> stage 3.2: building everything
[...]
vga_pci.o(.text+0x1ad2): In function `vga_pci_resume':
/src/sys/dev/pci/vga_pci.c:189: undefined reference to `vidsw'
vga_pci.o(.text+0x1ae0):/src/sys/dev/pci/vga_pci.c:189: undefined reference to `vidsw'
vga_pci.o(.text+0x1bc2):/src/sys/dev/pci/vga_pci.c:195: undefined reference to `vidsw'
vga_pci.o(.text+0x1bd0):/src/sys/dev/pci/vga_pci.c:195: undefined reference to `vidsw'
vga_pci.o(.text+0x1de2): In function `vga_pci_suspend':
/src/sys/dev/pci/vga_pci.c:140: undefined reference to `vidsw'
vga_pci.o(.text+0x1df0):/src/sys/dev/pci/vga_pci.c:140: more undefined references to `vidsw' follow
*** Error code 1

Stop in /obj/ia64/src/sys/GENERIC.
*** Error code 1

Stop in /src.
*** Error code 1

Stop in /src.
TB --- 2009-11-06 19:37:46 - WARNING: /usr/bin/make returned exit code  1 
TB --- 2009-11-06 19:37:46 - ERROR: failed to build GENERIC kernel
TB --- 2009-11-06 19:37:46 - 5286.66 user 776.19 system 6567.26 real


http://tinderbox.freebsd.org/tinderbox-head-HEAD-ia64-ia64.full
From toyorunner at gmail.com  Fri Nov  6 21:32:45 2009
From: toyorunner at gmail.com (ToyoRunner)
Date: Fri Nov  6 21:32:57 2009
Subject: 2009 Update
In-Reply-To: <595329F2-46F2-4393-B8E3-0923694D250D@mac.com>
References: <595329F2-46F2-4393-B8E3-0923694D250D@mac.com>
Message-ID: <b5ef8d5c0911061306h6cd79d7bk33b34854eb09b69b@mail.gmail.com>

Marcel,

Glad to hear that your efforts are paying off. Thanks for all your hard work.

On Fri, Nov 6, 2009 at 10:52 AM, Marcel Moolenaar <xcllnt@mac.com> wrote:
> All,
>
> Anton Shterenlikht reported various problems when he tried ia64
> and I'm pleased to announce some updates:
>
> 1. ?The kernel panic relating to inconsistent high FP registers
> ? ?has been fixed. This also means that the following message
> ? ?will not appear on the console anymore:
> ? ? ? ?XXX: bogusly disabled high FP regs
>
> ? ?Versions fixed: 9-CURRENT
> ? ?Fix will be merged to 8-STABLE after 8.0-RELEASE
>
> 2. ?The failures in perl when threading has been enabled have
> ? ?been identified as a compiler bug relating to the use of
> ? ?statements in expressions. In other words, the expressions
> ? ?of the form:
> ? ? ? ?({ ... })
>
> ? ?All test failures were eliminated when these were recoded
> ? ?as proper inline functions. The perl port has not been
> ? ?fixed at this time. A definite confidence booster for the
> ? ?threading support on ia64 and yet another nail in GCC's
> ? ?coffin.
>
> 3. ?I'm working on getting KDE 4 to build again. It's currently
> ? ?failing in optional packages. The base KDE 4 infrastructure
> ? ?is up and running and Konqueror (the web browser) seems to
> ? ?work quite well, though tends to dump core after a while.
> ? ?It would be looked into.
>
> 4. ?GNOME built and ran fine before, but it's possible that
> ? ?things have changed. I'll keep playing with it.
>
> Future work:
>
> 1. ?I got a VNC server for ia64 building and running, but I can't
> ? ?reproduce it at this time, so no fixes for the ports yet. With
> ? ?a VNC server, a whole set of new programs can be ported and
> ? ?tested better.
>
> 2. ?I'm planning to change PAGE_SIZE to 16K instead of 8K. It be
> ? ?good for performance. More on this later.
>
> 3. ?More compiler and debugger work. GCC is really not good for
> ? ?ia64. I'm planning on refocusing some of my attention towards
> ? ?compiler work. Related to this is the debugger. GDB is not
> ? ?lacking severely on ia64. Note that I don't plan to fix GDB.
> ? ?Neither will I fix GCC. I'll be looking elsewhere.
>
> Overall good news. However, the state of GCC and GDB for ia64 is
> still a big problem in my opinion.
>
> FYI,
>
> --
> Marcel Moolenaar
> xcllnt@mac.com
>
>
>
> _______________________________________________
> freebsd-ia64@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-ia64
> To unsubscribe, send any mail to "freebsd-ia64-unsubscribe@freebsd.org"
>
From mexas at bristol.ac.uk  Sat Nov  7 21:40:41 2009
From: mexas at bristol.ac.uk (Anton Shterenlikht)
Date: Sat Nov  7 21:40:48 2009
Subject: 2009 Update
In-Reply-To: <595329F2-46F2-4393-B8E3-0923694D250D@mac.com>
References: <595329F2-46F2-4393-B8E3-0923694D250D@mac.com>
Message-ID: <20091107214031.GB78634@mech-cluster241.men.bris.ac.uk>

On Fri, Nov 06, 2009 at 09:52:25AM -0800, Marcel Moolenaar wrote:
> 
> 3.  More compiler and debugger work. GCC is really not good for
>      ia64. I'm planning on refocusing some of my attention towards
>      compiler work. Related to this is the debugger. GDB is not
>      lacking severely on ia64. Note that I don't plan to fix GDB.
>      Neither will I fix GCC. I'll be looking elsewhere.

This seems a major undertaking. Also, what will happen to
a miriad of GCC-dependent ports?

many thanks
anton

-- 
Anton Shterenlikht
Room 2.6, Queen's Building
Mech Eng Dept
Bristol University
University Walk, Bristol BS8 1TR, UK
Tel: +44 (0)117 331 5944
Fax: +44 (0)117 929 4423
From codestr0m at osunix.org  Sat Nov  7 22:45:36 2009
From: codestr0m at osunix.org (=?UTF-8?B?IkMuIEJlcmdzdHLDtm0i?=)
Date: Sat Nov  7 22:45:43 2009
Subject: 2009 Update
In-Reply-To: <20091107214031.GB78634@mech-cluster241.men.bris.ac.uk>
References: <595329F2-46F2-4393-B8E3-0923694D250D@mac.com>
	<20091107214031.GB78634@mech-cluster241.men.bris.ac.uk>
Message-ID: <4AF5F413.7010302@osunix.org>

Anton Shterenlikht wrote:
> On Fri, Nov 06, 2009 at 09:52:25AM -0800, Marcel Moolenaar wrote:
>   
>> 3.  More compiler and debugger work. GCC is really not good for
>>      ia64. I'm planning on refocusing some of my attention towards
>>      compiler work. Related to this is the debugger. GDB is not
>>      lacking severely on ia64. Note that I don't plan to fix GDB.
>>      Neither will I fix GCC. I'll be looking elsewhere.
>>     
>
> This seems a major undertaking. Also, what will happen to
> a miriad of GCC-dependent ports?
>   
I'm willing to make PathScale's PathDB CDDL or possibly BSD licensed.  
I've been planning this for months, it has the green light and I'm the 
bottleneck.  If there's interest it could serve a dual purpose of 
building a providing a more liberal licensed debugger for the BSD 
community/open source and share the workload beyond the ia64 community.  
I've not reviewed the code to know the quality, but I'm happy to give 
anyone access to the source.  Once the headers are updated and there's a 
plan going forward we can make it publicly available.

http://hg.pathscale.com
Just let me know your username and I'll give you access.


It may also be possible for PathScale's compiler to be getting a major 
improvement in the near future that would benefit IA64 and other 
targets.  It's still uncertain, but I'd love to see it happen.  Parts of 
our fully open source compiler project are being held up by some legal 
issues beyond my control.  The parts that are pending wouldn't inhibit 
finishing our BSD port and or get in the way of anything ia64 related.

Between now and after SC09 (SuperComputing) I apologize if I'm slow to 
respond to emails.  irc is best for quick questions or to say hi..


Christopher

CTO PathScale
#pathscale irc.freenode.net

(Sent from my open source email)
From mexas at bristol.ac.uk  Sat Nov  7 23:23:03 2009
From: mexas at bristol.ac.uk (Anton Shterenlikht)
Date: Sat Nov  7 23:23:09 2009
Subject: 2009 Update
In-Reply-To: <4AF5F413.7010302@osunix.org>
References: <595329F2-46F2-4393-B8E3-0923694D250D@mac.com>
	<20091107214031.GB78634@mech-cluster241.men.bris.ac.uk>
	<4AF5F413.7010302@osunix.org>
Message-ID: <20091107232251.GA33482@mech-cluster241.men.bris.ac.uk>

On Sat, Nov 07, 2009 at 05:26:27PM -0500, "C. Bergstr?m" wrote:
> Anton Shterenlikht wrote:
> > On Fri, Nov 06, 2009 at 09:52:25AM -0800, Marcel Moolenaar wrote:
> >   
> >> 3.  More compiler and debugger work. GCC is really not good for
> >>      ia64. I'm planning on refocusing some of my attention towards
> >>      compiler work. Related to this is the debugger. GDB is not
> >>      lacking severely on ia64. Note that I don't plan to fix GDB.
> >>      Neither will I fix GCC. I'll be looking elsewhere.
> >>     
> >
> > This seems a major undertaking. Also, what will happen to
> > a miriad of GCC-dependent ports?
> >   
> I'm willing to make PathScale's PathDB CDDL or possibly BSD licensed.  
> I've been planning this for months, it has the green light and I'm the 
> bottleneck.  If there's interest it could serve a dual purpose of 
> building a providing a more liberal licensed debugger for the BSD 
> community/open source and share the workload beyond the ia64 community.  
> I've not reviewed the code to know the quality, but I'm happy to give 
> anyone access to the source.  Once the headers are updated and there's a 
> plan going forward we can make it publicly available.
> 
> http://hg.pathscale.com
> Just let me know your username and I'll give you access.
> 
> 
> It may also be possible for PathScale's compiler to be getting a major 
> improvement in the near future that would benefit IA64 and other 
> targets.  It's still uncertain, but I'd love to see it happen.  Parts of 
> our fully open source compiler project are being held up by some legal 
> issues beyond my control.  The parts that are pending wouldn't inhibit 
> finishing our BSD port and or get in the way of anything ia64 related.
> 
> Between now and after SC09 (SuperComputing) I apologize if I'm slow to 
> respond to emails.  irc is best for quick questions or to say hi..

There are 6 ia64 systems on top500 list (details below). All
run linux, of course. But these organisations must use
very good compilers, and, at least for nuclear codes (systems 71
and 96), these will be f90-f95 or even f2003 (I don't know of
any f2008) compilers. Perhaps they do use PathScale and
forget about GCC..

anton

################

Rank	Site	System	Cores	Rmax	Rpeak
58	NASA/Ames Research Center/NAS
United States	SGI Altix 1.5/1.6/1.66 GHz, Voltaire Infiniband
SGI	13824	66.57	82.94

66	Leibniz Rechenzentrum
Germany	Altix 4700 1.6 GHz
SGI	9728	56.52	62.26

71	Commissariat a l'Energie Atomique (CEA)
France	NovaScale 5160, Itanium2 1.6 GHz, Quadrics
Bull SA	9968	52.84	63.8

75	Wright-Patterson Air Force Base/DoD ASC
United States	Altix 4700 1.6 GHz
SGI	9216	51.44	58.98

96	Commissariat a l'Energie Atomique (CEA)
France	Novascale 3045, Itanium2 1.6 GHz, Infiniband
Bull SA	7680	42.13	49.15

325	Government Classified
United States	Cluster Platform 6000 rx1620, Itanium2 1.6 GHz, Quadrics
Hewlett-Packard	4096	20.45	26.21te

-- 
Anton Shterenlikht
Room 2.6, Queen's Building
Mech Eng Dept
Bristol University
University Walk, Bristol BS8 1TR, UK
Tel: +44 (0)117 331 5944
Fax: +44 (0)117 929 4423
From peterc at gelato.unsw.edu.au  Sun Nov  8 01:42:47 2009
From: peterc at gelato.unsw.edu.au (Peter Chubb)
Date: Sun Nov  8 01:42:54 2009
Subject: 2009 Update
In-Reply-To: <20091107232251.GA33482@mech-cluster241.men.bris.ac.uk>
References: <595329F2-46F2-4393-B8E3-0923694D250D@mac.com>
	<20091107214031.GB78634@mech-cluster241.men.bris.ac.uk>
	<4AF5F413.7010302@osunix.org>
	<20091107232251.GA33482@mech-cluster241.men.bris.ac.uk>
Message-ID: <87hbt5yg9i.wl%peter@chubb.wattle.id.au>

>>>>> "Anton" == Anton Shterenlikht <mexas@bristol.ac.uk> writes:

Anton> On Sat, Nov 07, 2009 at 05:26:27PM -0500, "C. Bergstr?m" wrote:

Anton> There are 6 ia64 systems on top500 list (details below). All
Anton> run linux, of course. But these organisations must use very
Anton> good compilers, and, at least for nuclear codes (systems 71 and
Anton> 96), these will be f90-f95 or even f2003 (I don't know of any
Anton> f2008) compilers. Perhaps they do use PathScale and forget
Anton> about GCC..

Most use the Intel compiler, and heavy hand-optimization of inner
loops using tools like vTune.

Gelato put a lot of effort into imprving gcc for IA64 -- gcc 4.x is
miles better than gcc 3.x -- but there's still a lot that could be done
with low-level instruction scheduling.

Peter C

--
Dr Peter Chubb		www.nicta.com.au    peter DOT chubb AT nicta.com.au
http://www.ertos.nicta.com.au           ERTOS within National ICT Australia
From codestr0m at osunix.org  Sun Nov  8 05:13:45 2009
From: codestr0m at osunix.org (=?ISO-8859-1?Q?=22C=2E_Bergstr=F6m=22?=)
Date: Sun Nov  8 05:13:51 2009
Subject: 2009 Update
In-Reply-To: <87hbt5yg9i.wl%peter@chubb.wattle.id.au>
References: <595329F2-46F2-4393-B8E3-0923694D250D@mac.com>	<20091107214031.GB78634@mech-cluster241.men.bris.ac.uk>	<4AF5F413.7010302@osunix.org>	<20091107232251.GA33482@mech-cluster241.men.bris.ac.uk>
	<87hbt5yg9i.wl%peter@chubb.wattle.id.au>
Message-ID: <4AF65423.8040108@osunix.org>

Peter Chubb wrote:
>>>>>> "Anton" == Anton Shterenlikht <mexas@bristol.ac.uk> writes:
>>>>>>             
>
> Anton> On Sat, Nov 07, 2009 at 05:26:27PM -0500, "C. Bergstr?m" wrote:
>
> Anton> There are 6 ia64 systems on top500 list (details below). All
> Anton> run linux, of course. But these organisations must use very
> Anton> good compilers, and, at least for nuclear codes (systems 71 and
> Anton> 96), these will be f90-f95 or even f2003 (I don't know of any
> Anton> f2008) compilers. Perhaps they do use PathScale and forget
> Anton> about GCC..
>
> Most use the Intel compiler, and heavy hand-optimization of inner
> loops using tools like vTune.
>
> Gelato put a lot of effort into imprving gcc for IA64 -- gcc 4.x is
> miles better than gcc 3.x -- but there's still a lot that could be done
> with low-level instruction scheduling.
>
>   
I do not normally discourage people to work on other compilers, but 
working on GCC for IA64 is a complete waste of time.  With that I do 
agree the current situation for IA64 is less than ideal.. I'm happy to 
hear complaints and do what is within my resources and capability to fix..

Small notes..
    a) PathScale doesn't currently support IA64
    b) I would like to merge in some code that would give us a near 
optimal CG for IA64.  That in combination with a couple other things 
would hopefully bring us in the same ballpark as the Intel IA64 
compiler.  (Pure speculation as I don't know this target very well or 
current state of Intel compiler)
    c) We're happy to help test and verify changes for IA64 with the 
PathScale QA harness, but need to acquire hardware.  This is something I 
may personally have money for and can put in our datacenter, but there 
is currently no company budget.


./C

From peterc at gelato.unsw.edu.au  Sun Nov  8 06:44:06 2009
From: peterc at gelato.unsw.edu.au (Peter Chubb)
Date: Sun Nov  8 06:44:13 2009
Subject: 2009 Update
In-Reply-To: <4AF65423.8040108@osunix.org>
References: <595329F2-46F2-4393-B8E3-0923694D250D@mac.com>
	<20091107214031.GB78634@mech-cluster241.men.bris.ac.uk>
	<4AF5F413.7010302@osunix.org>
	<20091107232251.GA33482@mech-cluster241.men.bris.ac.uk>
	<87hbt5yg9i.wl%peter@chubb.wattle.id.au>
	<4AF65423.8040108@osunix.org>
Message-ID: <87eio9y0ri.wl%peter@chubb.wattle.id.au>

>>>>> "C" == C Bergstr?m <codestr0m@osunix.org> writes:

C> Peter Chubb wrote:
>>>>>>> "Anton" == Anton Shterenlikht <mexas@bristol.ac.uk> writes:
>>>>>>> 
>>
Anton> On Sat, Nov 07, 2009 at 05:26:27PM -0500, "C. Bergstr?m" wrote:
>>
Anton> There are 6 ia64 systems on top500 list (details below). All
Anton> run linux, of course. But these organisations must use very
Anton> good compilers, and, at least for nuclear codes (systems 71 and
Anton> 96), these will be f90-f95 or even f2003 (I don't know of any
Anton> f2008) compilers. Perhaps they do use PathScale and forget
Anton> about GCC..
>> Most use the Intel compiler, and heavy hand-optimization of inner
>> loops using tools like vTune.
>> 
>> Gelato put a lot of effort into imprving gcc for IA64 -- gcc 4.x is
>> miles better than gcc 3.x -- but there's still a lot that could be
>> done with low-level instruction scheduling.
>> 
>> 
C> I do not normally discourage people to work on other compilers, but
C> working on GCC for IA64 is a complete waste of time.  With that I
C> do agree the current situation for IA64 is less than ideal.. I'm
C> happy to hear complaints and do what is within my resources and
C> capability to fix..


The reason we put so much effort into attempting to improve things is
that most people will just try to run their code with the compiler(s)
they already know.  And the code generated by gcc was appalling, so
Itanium appeared to suck badly.  Fixing GCC meant that users could
continue to use the toolchains they already knew, and maybe they'd get
halfway decent results.    The stuff we did is documented at
http://gcc.gelato.org/



People can still do better, by using the Intel compiler, but even it
was non-optimal for system code (although I haven't tried it recently:
it may have improved), and needed (again, I haven't looked recently,
this may be out of date) careful tuning to get good performance for
enterprise workloads.

--
Dr Peter Chubb		www.nicta.com.au    peter DOT chubb AT nicta.com.au
http://www.ertos.nicta.com.au           ERTOS within National ICT Australia
From codestr0m at osunix.org  Sun Nov  8 06:54:03 2009
From: codestr0m at osunix.org (=?ISO-8859-1?Q?=22C=2E_Bergstr=F6m=22?=)
Date: Sun Nov  8 06:54:10 2009
Subject: 2009 Update
In-Reply-To: <87eio9y0ri.wl%peter@chubb.wattle.id.au>
References: <595329F2-46F2-4393-B8E3-0923694D250D@mac.com>	<20091107214031.GB78634@mech-cluster241.men.bris.ac.uk>	<4AF5F413.7010302@osunix.org>	<20091107232251.GA33482@mech-cluster241.men.bris.ac.uk>	<87hbt5yg9i.wl%peter@chubb.wattle.id.au>	<4AF65423.8040108@osunix.org>
	<87eio9y0ri.wl%peter@chubb.wattle.id.au>
Message-ID: <4AF66BA7.8010302@osunix.org>

Peter Chubb wrote:
> ...
> The reason we put so much effort into attempting to improve things is
> that most people will just try to run their code with the compiler(s)
> they already know.
We have a GCC front-end to make the learning curve much easier for 
exactly the reason you stated above.  I'm happy to work with the gelato 
community if there's interest and I can help in some way.
From bugmaster at FreeBSD.org  Mon Nov  9 11:06:55 2009
From: bugmaster at FreeBSD.org (FreeBSD bugmaster)
Date: Mon Nov  9 11:08:24 2009
Subject: Current problem reports assigned to freebsd-ia64@FreeBSD.org
Message-ID: <200911091106.nA9B6spf079021@freefall.freebsd.org>

Note: to view an individual PR, use:
  http://www.freebsd.org/cgi/query-pr.cgi?pr=(number).

The following is a listing of current problems submitted by FreeBSD users.
These represent problem reports covering all versions including
experimental development code and obsolete releases.


S Tracker      Resp.      Description
--------------------------------------------------------------------------------
o ia64/120315  ia64       Backing store switch in exception_save_restart leaves 
o ia64/113102  ia64       [MCA] Multiple records can have the same sequence numb
o ia64/86218   ia64       Mozilla / Firefox: regxpcom or regchrome broken on ia6

3 problems total.

From mexas at bristol.ac.uk  Mon Nov  9 13:21:19 2009
From: mexas at bristol.ac.uk (Anton Shterenlikht)
Date: Mon Nov  9 13:21:27 2009
Subject: QMutex: mutex destroy failure: Device busy -> Seg fault in
 ports/x11/kdebase4-workspace
Message-ID: <20091109132113.GA71911@mech-cluster241.men.bris.ac.uk>

On ia64 HEAD while building x11/kdebase4-workspace
I get lots of messages similar to:

	QWaitCondition: mutex destroy failure: Device busy
	QMutex: mutex destroy failure: Device busy

culminating in this error:


[skip]


Linking CXX shared module ../../lib/kgreet_generic.so
[ 10%] Built target kgreet_generic
[ 10%] Generating org.kde.Kephal.Screens.xml
QMutex: mutex destroy failure: Device busy
[ 10%] Generating org.kde.Kephal.Outputs.xml
[ 10%] Generating org.kde.Kephal.Configurations.xml
Segmentation fault (core dumped)
*** Error code 139
1 error
*** Error code 2
Linking CXX shared module ../../lib/kgreet_winbind.so
[ 10%] Built target kgreet_winbind
1 error
*** Error code 2
1 error
*** Error code 1

Stop in /usr/ports/x11/kdebase4-workspace.
*** Error code 1


Please advise
anton

PS. I don't really need KDE at all. But Marcel reports that
konqueror seems to be working. So I just want to build this.
At present there's no
secure graphical web browser for ia64. Until recently
kazehakase was working. But now it doesn't, because security/nss
doesn't build. And firefox doesn't build because of broken xpcom..

-- 
Anton Shterenlikht
Room 2.6, Queen's Building
Mech Eng Dept
Bristol University
University Walk, Bristol BS8 1TR, UK
Tel: +44 (0)117 331 5944
Fax: +44 (0)117 929 4423
From xcllnt at mac.com  Mon Nov  9 20:48:28 2009
From: xcllnt at mac.com (Marcel Moolenaar)
Date: Mon Nov  9 20:48:40 2009
Subject: QMutex: mutex destroy failure: Device busy -> Seg fault in
 ports/x11/kdebase4-workspace
In-Reply-To: <20091109132113.GA71911@mech-cluster241.men.bris.ac.uk>
References: <20091109132113.GA71911@mech-cluster241.men.bris.ac.uk>
Message-ID: <3A2818E0-70DE-4837-9E47-08FFDF74072D@mac.com>


On Nov 9, 2009, at 5:21 AM, Anton Shterenlikht wrote:

> On ia64 HEAD while building x11/kdebase4-workspace
> I get lots of messages similar to:
>
> 	QWaitCondition: mutex destroy failure: Device busy
> 	QMutex: mutex destroy failure: Device busy
>
> culminating in this error:
>
>
> [skip]
>
>
> Linking CXX shared module ../../lib/kgreet_generic.so
> [ 10%] Built target kgreet_generic
> [ 10%] Generating org.kde.Kephal.Screens.xml
> QMutex: mutex destroy failure: Device busy
> [ 10%] Generating org.kde.Kephal.Outputs.xml
> [ 10%] Generating org.kde.Kephal.Configurations.xml
> Segmentation fault (core dumped)
> *** Error code 139
> 1 error
> *** Error code 2
> Linking CXX shared module ../../lib/kgreet_winbind.so
> [ 10%] Built target kgreet_winbind
> 1 error
> *** Error code 2
> 1 error
> *** Error code 1
>
> Stop in /usr/ports/x11/kdebase4-workspace.
> *** Error code 1
>
>
> Please advise
> anton

This is most likely a compiler bug. Just restart the build.
I noticed some instability as well, but when restarting it
would always move past the original problem.

Please do not override compiler options. Just keep the default
for now.

> PS. I don't really need KDE at all. But Marcel reports that
> konqueror seems to be working. So I just want to build this.

I have some outstanding patches, you may want to apply.
See attached.

> At present there's no
> secure graphical web browser for ia64. Until recently
> kazehakase was working. But now it doesn't, because security/nss
> doesn't build. And firefox doesn't build because of broken xpcom..

Firefox used to build. I'll see up with that...

-- 
Marcel Moolenaar
xcllnt@mac.com


-------------- next part --------------
A non-text attachment was scrubbed...
Name: ports.diff
Type: application/octet-stream
Size: 3626 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-ia64/attachments/20091109/4360c939/ports.obj
From xcllnt at mac.com  Tue Nov 10 07:34:04 2009
From: xcllnt at mac.com (Marcel Moolenaar)
Date: Tue Nov 10 07:34:16 2009
Subject: QMutex: mutex destroy failure: Device busy -> Seg fault in
 ports/x11/kdebase4-workspace
In-Reply-To: <3A2818E0-70DE-4837-9E47-08FFDF74072D@mac.com>
References: <20091109132113.GA71911@mech-cluster241.men.bris.ac.uk>
	<3A2818E0-70DE-4837-9E47-08FFDF74072D@mac.com>
Message-ID: <BE5313BE-3EA9-48C2-9A56-5AFCB58292D7@mac.com>


On Nov 9, 2009, at 12:48 PM, Marcel Moolenaar wrote:
> 
>> At present there's no
>> secure graphical web browser for ia64. Until recently
>> kazehakase was working. But now it doesn't, because security/nss
>> doesn't build. And firefox doesn't build because of broken xpcom..
> 
> Firefox used to build. I'll see up with that...

Apply the attached patch to /usr/ports/www/firefox3.
I'm testing the same patch against firefox35 as I type
this.

FYI,

-- 
Marcel Moolenaar
xcllnt@mac.com


-------------- next part --------------
A non-text attachment was scrubbed...
Name: firefox3.diff
Type: application/octet-stream
Size: 2693 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-ia64/attachments/20091110/bc94c839/firefox3.obj
From xcllnt at mac.com  Tue Nov 10 21:19:20 2009
From: xcllnt at mac.com (Marcel Moolenaar)
Date: Tue Nov 10 21:19:51 2009
Subject: 2009 Update
In-Reply-To: <87hbt5yg9i.wl%peter@chubb.wattle.id.au>
References: <595329F2-46F2-4393-B8E3-0923694D250D@mac.com>
	<20091107214031.GB78634@mech-cluster241.men.bris.ac.uk>
	<4AF5F413.7010302@osunix.org>
	<20091107232251.GA33482@mech-cluster241.men.bris.ac.uk>
	<87hbt5yg9i.wl%peter@chubb.wattle.id.au>
Message-ID: <53C58109-BD6C-4314-B498-D628023CF553@mac.com>

[combined response]

On Nov 7, 2009, at 5:08 PM, Peter Chubb wrote:

> Gelato put a lot of effort into imprving gcc for IA64 -- gcc 4.x is
> miles better than gcc 3.x -- but there's still a lot that could be done
> with low-level instruction scheduling.

My immediate concern is correctness. Improving SPECcpu20xx looks good
academically, but means nothing to me in the context of FreeBSD if it
means spending a lot time finding work-arounds for correctness bugs.

At this time we can't compile the kernel correctly when all debugging
options are removed and I think we actually have a more optimal OS
with a compiler that generates less-optimal, but correct code than
what we now have with GCC 4.2.1. I find that bizarre..

I would probably stick with GCC much more longer if it would at least
generate correct code. Nonetheless, any future improvements that people
may make, may not be usable by FreeBSD due to licensing anyway, so to
me it's not as simple as "just fix what's broken"...


On Nov 7, 2009, at 9:16 PM, C. Bergstr?m wrote:

> Small notes..
>   a) PathScale doesn't currently support IA64

Another aspect, again specifically in the context of FreeBSD, is that
architecture support in PathScale (or Open64) is limited. As such,
it won't easily be the next system compiler. At this time LLVM has
the best chance of replacing GCC, if GCC is ever being replaced.
Alas, the LLVM project recently removed the ia64 backend due to lack
of support. Just my luck :-)

While PathScale (and Open64) are great compilers for in the ports
collection and I would be very happy to see that happen, I do need
to keep an eye out for any developments involving the system compiler
and I may be forced to work on that just to keep FreeBSD on ia64
viable without forking off...

>   b) I would like to merge in some code that would give us a near optimal CG for IA64.  That in combination with a couple other things would hopefully bring us in the same ballpark as the Intel IA64 compiler.  (Pure speculation as I don't know this target very well or current state of Intel compiler)

Speculation is the correct word: the Intel compiler utilizes data
and control speculation and achieves good results in certain cases
because of it. The use of explicit prefetch operations also helps
to prime the cache with good results.

The CG for Itanium in PathScale should utilize this as well to be
in the same ballpark as the Intel compiler. At least, that's what
I assume it should do. If the code comes from Open64, then I think
you'll be in the same ballpark. People (including Intel as part of
the ORC project) have done a great job.


On Nov 7, 2009, at 10:43 PM, Peter Chubb wrote:

> The reason we put so much effort into attempting to improve things is
> that most people will just try to run their code with the compiler(s)
> they already know.

I can see that. Then again, I also fail to see it. With autoconf
and libtool, compiler differences should be non-issues and the
only thing developers should do is actually write portable code.

I believe that there's an even deeper and darker consequence to
the statement that people just try with the compiler they already
know and that is that the assumptions embedded in the code about
the architecture are not expected to cause problems.

Itanium did cause a lot of code churn while porting code from
i386 to ia64 and it wasn't just for being 64-bit. Still a lot
of code uses 'int' for variables that are never negative when
'unsigned int' yields more optimal code simply because it avoids
an unnecessary sign-extension.

What I'm trying to say is that assumptions about the compiler are
just a part of the problem and it's probably a smaller problem
than assumptions embedded in the code that cause unique problems
on Itanium. Assumptions about the architecture may have a bigger
impact on the resulting performance than assumptions about the
compiler will have.

It's good to keep as much the same if so many things change, so
Gelato's work has been good and beneficial. I was more in touch
when I worked @HP then I am now, so I don't know all the good
Gelato has done.

-- 
Marcel Moolenaar
xcllnt@mac.com



From xcllnt at mac.com  Tue Nov 10 23:34:56 2009
From: xcllnt at mac.com (Marcel Moolenaar)
Date: Tue Nov 10 23:35:03 2009
Subject: QMutex: mutex destroy failure: Device busy -> Seg fault in
 ports/x11/kdebase4-workspace
In-Reply-To: <20091109132113.GA71911@mech-cluster241.men.bris.ac.uk>
References: <20091109132113.GA71911@mech-cluster241.men.bris.ac.uk>
Message-ID: <3A2818E0-70DE-4837-9E47-08FFDF74072D@mac.com>


On Nov 9, 2009, at 5:21 AM, Anton Shterenlikht wrote:

> On ia64 HEAD while building x11/kdebase4-workspace
> I get lots of messages similar to:
>
> 	QWaitCondition: mutex destroy failure: Device busy
> 	QMutex: mutex destroy failure: Device busy
>
> culminating in this error:
>
>
> [skip]
>
>
> Linking CXX shared module ../../lib/kgreet_generic.so
> [ 10%] Built target kgreet_generic
> [ 10%] Generating org.kde.Kephal.Screens.xml
> QMutex: mutex destroy failure: Device busy
> [ 10%] Generating org.kde.Kephal.Outputs.xml
> [ 10%] Generating org.kde.Kephal.Configurations.xml
> Segmentation fault (core dumped)
> *** Error code 139
> 1 error
> *** Error code 2
> Linking CXX shared module ../../lib/kgreet_winbind.so
> [ 10%] Built target kgreet_winbind
> 1 error
> *** Error code 2
> 1 error
> *** Error code 1
>
> Stop in /usr/ports/x11/kdebase4-workspace.
> *** Error code 1
>
>
> Please advise
> anton

This is most likely a compiler bug. Just restart the build.
I noticed some instability as well, but when restarting it
would always move past the original problem.

Please do not override compiler options. Just keep the default
for now.

> PS. I don't really need KDE at all. But Marcel reports that
> konqueror seems to be working. So I just want to build this.

I have some outstanding patches, you may want to apply.
See attached.

> At present there's no
> secure graphical web browser for ia64. Until recently
> kazehakase was working. But now it doesn't, because security/nss
> doesn't build. And firefox doesn't build because of broken xpcom..

Firefox used to build. I'll see up with that...

-- 
Marcel Moolenaar
xcllnt@mac.com


-------------- next part --------------
A non-text attachment was scrubbed...
Name: ports.diff
Type: application/octet-stream
Size: 3626 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-ia64/attachments/20091110/4360c939/ports.obj
-------------- next part --------------
_______________________________________________
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org"
From tinderbox at freebsd.org  Wed Nov 11 15:00:20 2009
From: tinderbox at freebsd.org (FreeBSD Tinderbox)
Date: Wed Nov 11 15:00:27 2009
Subject: [head tinderbox] failure on ia64/ia64
Message-ID: <200911111402.nABE2Uwh052394@freebsd-current.sentex.ca>

TB --- 2009-11-11 12:43:26 - tinderbox 2.6 running on freebsd-current.sentex.ca
TB --- 2009-11-11 12:43:26 - starting HEAD tinderbox run for ia64/ia64
TB --- 2009-11-11 12:43:26 - cleaning the object tree
TB --- 2009-11-11 12:43:42 - cvsupping the source tree
TB --- 2009-11-11 12:43:42 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/ia64/ia64/supfile
TB --- 2009-11-11 12:44:09 - building world
TB --- 2009-11-11 12:44:09 - MAKEOBJDIRPREFIX=/obj
TB --- 2009-11-11 12:44:09 - PATH=/usr/bin:/usr/sbin:/bin:/sbin
TB --- 2009-11-11 12:44:09 - TARGET=ia64
TB --- 2009-11-11 12:44:09 - TARGET_ARCH=ia64
TB --- 2009-11-11 12:44:09 - TZ=UTC
TB --- 2009-11-11 12:44:09 - __MAKE_CONF=/dev/null
TB --- 2009-11-11 12:44:09 - cd /src
TB --- 2009-11-11 12:44:09 - /usr/bin/make -B buildworld
>>> World build started on Wed Nov 11 12:44:09 UTC 2009
>>> Rebuilding the temporary build tree
>>> stage 1.1: legacy release compatibility shims
>>> stage 1.2: bootstrap tools
>>> stage 2.1: cleaning up the object tree
>>> stage 2.2: rebuilding the object tree
>>> stage 2.3: build tools
>>> stage 3: cross tools
>>> stage 4.1: building includes
>>> stage 4.2: building libraries
>>> stage 4.3: make dependencies
>>> stage 4.4: building everything
>>> World build completed on Wed Nov 11 13:59:55 UTC 2009
TB --- 2009-11-11 13:59:55 - generating LINT kernel config
TB --- 2009-11-11 13:59:55 - cd /src/sys/ia64/conf
TB --- 2009-11-11 13:59:55 - /usr/bin/make -B LINT
TB --- 2009-11-11 13:59:55 - building LINT kernel
TB --- 2009-11-11 13:59:55 - MAKEOBJDIRPREFIX=/obj
TB --- 2009-11-11 13:59:55 - PATH=/usr/bin:/usr/sbin:/bin:/sbin
TB --- 2009-11-11 13:59:55 - TARGET=ia64
TB --- 2009-11-11 13:59:55 - TARGET_ARCH=ia64
TB --- 2009-11-11 13:59:55 - TZ=UTC
TB --- 2009-11-11 13:59:55 - __MAKE_CONF=/dev/null
TB --- 2009-11-11 13:59:55 - cd /src
TB --- 2009-11-11 13:59:55 - /usr/bin/make -B buildkernel KERNCONF=LINT
>>> Kernel build for LINT started on Wed Nov 11 13:59:55 UTC 2009
>>> stage 1: configuring the kernel
>>> stage 2.1: cleaning up the object tree
>>> stage 2.2: rebuilding the object tree
>>> stage 2.3: build tools
>>> stage 3.1: making dependencies
>>> stage 3.2: building everything
[...]
cc -c -O2 -pipe -fno-strict-aliasing  -std=c99  -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes  -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual  -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc  -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/ia64/libuwx/src -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mconstant-gp -ffixed-r13 -mfixed-range=f32-f127 -fpic -ffreestanding -Werror  /src/sys/cam/cam_sim.c
cc -c -O2 -pipe -fno-strict-aliasing  -std=c99  -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes  -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual  -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc  -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/ia64/libuwx/src -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mconstant-gp -ffixed-r13 -mfixed-range=f32-f127 -fpic -ffreestanding -Werror  /src/sys/cam/cam_xpt.c
/src/sys/cam/cam_xpt.c:288: error: static declaration of 'xpt_start_tags' follows non-static declaration
/src/sys/cam/cam_xpt_internal.h:179: error: previous declaration of 'xpt_start_tags' was here
cc1: warnings being treated as errors
/src/sys/cam/cam_xpt.c: In function 'xpt_action_default':
/src/sys/cam/cam_xpt.c:2525: warning: implicit declaration of function 'xpt_schedule_dev_sendq'
/src/sys/cam/cam_xpt.c:2525: warning: nested extern declaration of 'xpt_schedule_dev_sendq'
*** Error code 1

Stop in /obj/ia64/src/sys/LINT.
*** Error code 1

Stop in /src.
*** Error code 1

Stop in /src.
TB --- 2009-11-11 14:02:30 - WARNING: /usr/bin/make returned exit code  1 
TB --- 2009-11-11 14:02:30 - ERROR: failed to build lint kernel
TB --- 2009-11-11 14:02:30 - 3726.84 user 627.39 system 4744.55 real


http://tinderbox.freebsd.org/tinderbox-head-HEAD-ia64-ia64.full
From mexas at bristol.ac.uk  Thu Nov 12 14:15:31 2009
From: mexas at bristol.ac.uk (Anton Shterenlikht)
Date: Thu Nov 12 14:15:42 2009
Subject: compiler discussion
Message-ID: <20091112141519.GA66229@mech-cluster241.men.bris.ac.uk>

Following from the discussion on the system compiler for ia64,
I tried to list few major ports which I'd love to have on ia64,
but can't, because of GCC problems:

- math/blas, lapack, lapack95, arpack, scalapack, atlas, etc.
- science/hdf5-18 (fortran APIs can't be built)
- french/aster (industial quality FEA code)
- cad/calculix (another good FEA code)

All these depend on lang/gcc44, which doesn't build.

The only fortran compiler I know to build and work
successfully on ia64 is (correct me if I'm wrong) g95.

I wonder if it's possible/desirable/easy to use lang/g95 for
the above and other fortran-dependent ports? 

In principal, lang/g95 looks very good, and it's got
some features not available in gfortran, e.g. limited
support for 2003 standard.

Any comments?

Also, any comments on the usability (particularly for fortran)
of llvm and lang/llvm-gcc4 on ia64?

many thanks
anton

-- 
Anton Shterenlikht
Room 2.6, Queen's Building
Mech Eng Dept
Bristol University
University Walk, Bristol BS8 1TR, UK
Tel: +44 (0)117 331 5944
Fax: +44 (0)117 929 4423
From codestr0m at osunix.org  Thu Nov 12 14:32:09 2009
From: codestr0m at osunix.org (=?ISO-8859-1?Q?=22C=2E_Bergstr=F6m=22?=)
Date: Thu Nov 12 14:32:19 2009
Subject: compiler discussion
In-Reply-To: <20091112141519.GA66229@mech-cluster241.men.bris.ac.uk>
References: <20091112141519.GA66229@mech-cluster241.men.bris.ac.uk>
Message-ID: <4AFC1D0F.1020805@osunix.org>

Anton Shterenlikht wrote:
> Following from the discussion on the system compiler for ia64,
> I tried to list few major ports which I'd love to have on ia64,
> but can't, because of GCC problems:
>
> - math/blas, lapack, lapack95, arpack, scalapack, atlas, etc.
> - science/hdf5-18 (fortran APIs can't be built)
> - french/aster (industial quality FEA code)
> - cad/calculix (another good FEA code)
>
> All these depend on lang/gcc44, which doesn't build.
>
> The only fortran compiler I know to build and work
> successfully on ia64 is (correct me if I'm wrong) g95.
>
> I wonder if it's possible/desirable/easy to use lang/g95 for
> the above and other fortran-dependent ports? 
>
> In principal, lang/g95 looks very good, and it's got
> some features not available in gfortran, e.g. limited
> support for 2003 standard.
>
> Any comments?
>
>   
Lots, but the main is that I don't think the g95 developer is still 
active.  Please ping Andy and if you do get a response let me know.
From sgk at troutmask.apl.washington.edu  Thu Nov 12 15:34:14 2009
From: sgk at troutmask.apl.washington.edu (Steve Kargl)
Date: Thu Nov 12 15:34:26 2009
Subject: compiler discussion
In-Reply-To: <20091112141519.GA66229@mech-cluster241.men.bris.ac.uk>
References: <20091112141519.GA66229@mech-cluster241.men.bris.ac.uk>
Message-ID: <20091112153407.GA62396@troutmask.apl.washington.edu>

On Thu, Nov 12, 2009 at 02:15:19PM +0000, Anton Shterenlikht wrote:
> Following from the discussion on the system compiler for ia64,
> I tried to list few major ports which I'd love to have on ia64,
> but can't, because of GCC problems:
> 
> - math/blas, lapack, lapack95, arpack, scalapack, atlas, etc.
> - science/hdf5-18 (fortran APIs can't be built)
> - french/aster (industial quality FEA code)
> - cad/calculix (another good FEA code)
> 
> All these depend on lang/gcc44, which doesn't build.

Doesn't build is not a very good description if you're
looking for help.  Post the build log somewhere.
Have you submitted bug reports to gcc.gnu.org?  Bugs
that are unreported are unlikely to be fixed.

> The only fortran compiler I know to build and work
> successfully on ia64 is (correct me if I'm wrong) g95.
> 
> I wonder if it's possible/desirable/easy to use lang/g95 for
> the above and other fortran-dependent ports? 

Given Polyhedron Benchmarks, it may be preferable to determine
why you can't build gcc44 and fix that problem.*

> In principal, lang/g95 looks very good, and it's got
> some features not available in gfortran, e.g. limited
> support for 2003 standard.
> 
> Any comments?

AFAIK, g95 has TR 15580 implemented and gfortran doesn't.
Other than that feature, gfortran has a fairly long list
of Fortran 2003 features implemented, which you can find
partially enumerated at the gfortran wiki.

> Also, any comments on the usability (particularly for fortran)
> of llvm and lang/llvm-gcc4 on ia64?

Last time I checked, Fortran in llvm was based off a very old
gfortran.  The llvm website mentions gcc 4.2.?.  While the 4.2.?
gfortran isn't too bad, you most certainly would rather use gcc44
if you can.  Literally, hundreds of bugs and several new feature
have been add to gfortran in going from 4.2.? to gcc 4.4.2.

Have you checked the Open64 project?

*disclaimer:  I've contributed a few hundred patches to gfortran,
and I'm listed as a gfortran maintainer.
 
-- 
Steve
From mexas at bristol.ac.uk  Thu Nov 12 16:52:14 2009
From: mexas at bristol.ac.uk (Anton Shterenlikht)
Date: Thu Nov 12 16:52:21 2009
Subject: compiler discussion
In-Reply-To: <20091112153407.GA62396@troutmask.apl.washington.edu>
References: <20091112141519.GA66229@mech-cluster241.men.bris.ac.uk>
	<20091112153407.GA62396@troutmask.apl.washington.edu>
Message-ID: <20091112165208.GC1283@mech-cluster241.men.bris.ac.uk>

On Thu, Nov 12, 2009 at 07:34:07AM -0800, Steve Kargl wrote:
> On Thu, Nov 12, 2009 at 02:15:19PM +0000, Anton Shterenlikht wrote:
> > Following from the discussion on the system compiler for ia64,
> > I tried to list few major ports which I'd love to have on ia64,
> > but can't, because of GCC problems:
> > 
> > - math/blas, lapack, lapack95, arpack, scalapack, atlas, etc.
> > - science/hdf5-18 (fortran APIs can't be built)
> > - french/aster (industial quality FEA code)
> > - cad/calculix (another good FEA code)
> > 
> > All these depend on lang/gcc44, which doesn't build.
> 
> Doesn't build is not a very good description if you're
> looking for help.  Post the build log somewhere.
> Have you submitted bug reports to gcc.gnu.org?  Bugs
> that are unreported are unlikely to be fixed.

sorry, I thought it was a known issue. Here's my bug report:

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40959

I admit, I haven't checked the suggested patch yet..

> Have you checked the Open64 project?

will do

many thanks
anton

-- 
Anton Shterenlikht
Room 2.6, Queen's Building
Mech Eng Dept
Bristol University
University Walk, Bristol BS8 1TR, UK
Tel: +44 (0)117 331 5944
Fax: +44 (0)117 929 4423
From mexas at bristol.ac.uk  Thu Nov 12 17:03:21 2009
From: mexas at bristol.ac.uk (Anton Shterenlikht)
Date: Thu Nov 12 17:03:33 2009
Subject: konqueror causes panic on ia64 current
Message-ID: <20091112170222.GA1426@mech-cluster241.men.bris.ac.uk>

on ia64 current, kern.osrevision: 199506, I've built
kdebase-4.3.1_1. Lanching konqueror caused panic after
about 5 mouse clicks. What I've recovered is below.

I can try to repeat it, and collect a full crash dump
if it's of any use.

anton

#############################

cpu_thread_exit(0xe000000019fcee40, 0xe0000000043b30c0, 0x50e, 0x163) at cpu_thread_exit+0x20
thread_exit(0xe00000000483d1f8, 0xe00000000483be40, 0xe000000011713a58, 0xe000000019fcee40) at threa
d_exit+0x130
thr_exit(0xe0000000117139d0, 0xe000000011713aa8, 0xe00000000483d1d0, 0xe0000000117139b0) at thr_exit
+0x120
syscall(0xa0000000c3b0f400, 0x1af, 0x2000000043aa67f0, 0xe000000019fcee40, 0xe0000000117139b0, 0xe00
00000049396f8, 0x1af, 0xa0000000c3b0f4e8) at syscall+0x3e0
epc_syscall_return() at epc_syscall_return
KDB: enter: panic
[thread pid 72526 tid 100179 ]
Stopped at      kdb_enter+0x92: [I2]    addl r14=0xffffffffffe1f3c8,gp ;;
db>

db> panic
boot(0x104, 0xe00000000483bbd8, 0xe000000004396170, 0x793) at boot+0x70
panic(0xe00000000480eb50) at panic+0x350
db_panic(0xe00000000413d5d0, 0x40c, 0xffffffffffffffff) at db_panic+0x40
db_command(0xe000000004988118, 0x0, 0x1) at db_command+0x750
db_command_loop(0xe000000004988140, 0xe000000004988110, 0xe000000004988118, 0xe00000000480ec00) at d
b_command_loop+0xf0
db_trap(0xb, 0xe0000000043f9e60) at db_trap+0x2b0
kdb_trap(0xb, 0x0, 0xa0000000c3b0f000, 0x1, 0x10080a2010, 0xe0000000047e9640, 0x716, 0xe000000004b69
b80) at kdb_trap+0x200
trap(0xb, 0xa0000000c3b0f000) at trap+0x7c0
ivt_Break_Instruction() at ivt_Break_Instruction+0x40
--- trapframe at 0xa0000000c3b0f000
kdb_enter(0xe00000000483bd90, 0xe00000000483bd90, 0xe000000004396120, 0x793) at kdb_enter+0xa0
panic(0xe000000004874470, 0x0, 0xe000000004874448, 0x5d3) at panic+0x2f0
ia64_highfp_drop(0xe000000019fcee40) at ia64_highfp_drop+0x100
cpu_thread_exit(0xe000000019fcee40, 0xe0000000043b30c0, 0x50e, 0x163) at cpu_thread_exit+0x20
thread_exit(0xe00000000483d1f8, 0xe00000000483be40, 0xe000000011713a58, 0xe000000019fcee40) at threa
d_exit+0x130
thr_exit(0xe0000000117139d0, 0xe000000011713aa8, 0xe00000000483d1d0, 0xe0000000117139b0) at thr_exit
+0x120
syscall(0xa0000000c3b0f400, 0x1af, 0x2000000043aa67f0, 0xe000000019fcee40, 0xe0000000117139b0, 0xe00
00000049396f8, 0x1af, 0xa0000000c3b0f4e8) at syscall+0x3e0
epc_syscall_return() at epc_syscall_return
db>



-- 
Anton Shterenlikht
Room 2.6, Queen's Building
Mech Eng Dept
Bristol University
University Walk, Bristol BS8 1TR, UK
Tel: +44 (0)117 331 5944
Fax: +44 (0)117 929 4423
From xcllnt at mac.com  Thu Nov 12 19:38:40 2009
From: xcllnt at mac.com (Marcel Moolenaar)
Date: Thu Nov 12 19:38:46 2009
Subject: konqueror causes panic on ia64 current
In-Reply-To: <20091112170222.GA1426@mech-cluster241.men.bris.ac.uk>
References: <20091112170222.GA1426@mech-cluster241.men.bris.ac.uk>
Message-ID: <14DDE756-9E12-4EF8-8A17-8883738874A1@mac.com>


On Nov 12, 2009, at 9:02 AM, Anton Shterenlikht wrote:

> on ia64 current, kern.osrevision: 199506, I've built
> kdebase-4.3.1_1. Lanching konqueror caused panic after
> about 5 mouse clicks. What I've recovered is below.

Please update your sources. This problem is fixed.
FYI,

-- 
Marcel Moolenaar
xcllnt@mac.com



From rdivacky at freebsd.org  Fri Nov 13 08:18:04 2009
From: rdivacky at freebsd.org (Roman Divacky)
Date: Fri Nov 13 08:18:11 2009
Subject: compiler discussion
In-Reply-To: <20091112153407.GA62396@troutmask.apl.washington.edu>
References: <20091112141519.GA66229@mech-cluster241.men.bris.ac.uk>
	<20091112153407.GA62396@troutmask.apl.washington.edu>
Message-ID: <20091113080033.GB90272@freebsd.org>

On Thu, Nov 12, 2009 at 07:34:07AM -0800, Steve Kargl wrote:
> On Thu, Nov 12, 2009 at 02:15:19PM +0000, Anton Shterenlikht wrote:
> > Following from the discussion on the system compiler for ia64,
> > I tried to list few major ports which I'd love to have on ia64,
> > but can't, because of GCC problems:
> > 
> > - math/blas, lapack, lapack95, arpack, scalapack, atlas, etc.
> > - science/hdf5-18 (fortran APIs can't be built)
> > - french/aster (industial quality FEA code)
> > - cad/calculix (another good FEA code)
> > 
> > All these depend on lang/gcc44, which doesn't build.
> 
> Doesn't build is not a very good description if you're
> looking for help.  Post the build log somewhere.
> Have you submitted bug reports to gcc.gnu.org?  Bugs
> that are unreported are unlikely to be fixed.
> 
> > The only fortran compiler I know to build and work
> > successfully on ia64 is (correct me if I'm wrong) g95.
> > 
> > I wonder if it's possible/desirable/easy to use lang/g95 for
> > the above and other fortran-dependent ports? 
> 
> Given Polyhedron Benchmarks, it may be preferable to determine
> why you can't build gcc44 and fix that problem.*
> 
> > In principal, lang/g95 looks very good, and it's got
> > some features not available in gfortran, e.g. limited
> > support for 2003 standard.
> > 
> > Any comments?
> 
> AFAIK, g95 has TR 15580 implemented and gfortran doesn't.
> Other than that feature, gfortran has a fairly long list
> of Fortran 2003 features implemented, which you can find
> partially enumerated at the gfortran wiki.
> 
> > Also, any comments on the usability (particularly for fortran)
> > of llvm and lang/llvm-gcc4 on ia64?
> 
> Last time I checked, Fortran in llvm was based off a very old
> gfortran.  The llvm website mentions gcc 4.2.?.  While the 4.2.?
> gfortran isn't too bad, you most certainly would rather use gcc44
> if you can.  Literally, hundreds of bugs and several new feature
> have been add to gfortran in going from 4.2.? to gcc 4.4.2.

you can use dragonegg gcc plugin which uses gcc frontend (for any
language) and uses llvm backed to generate the code:

	http://dragonegg.llvm.org/
From sgk at troutmask.apl.washington.edu  Fri Nov 13 14:56:01 2009
From: sgk at troutmask.apl.washington.edu (Steve Kargl)
Date: Fri Nov 13 14:56:13 2009
Subject: compiler discussion
In-Reply-To: <20091113080033.GB90272@freebsd.org>
References: <20091112141519.GA66229@mech-cluster241.men.bris.ac.uk>
	<20091112153407.GA62396@troutmask.apl.washington.edu>
	<20091113080033.GB90272@freebsd.org>
Message-ID: <20091113145523.GA66476@troutmask.apl.washington.edu>

On Fri, Nov 13, 2009 at 09:00:33AM +0100, Roman Divacky wrote:
> On Thu, Nov 12, 2009 at 07:34:07AM -0800, Steve Kargl wrote:
> > 
> > Last time I checked, Fortran in llvm was based off a very old
> > gfortran.  The llvm website mentions gcc 4.2.?.  While the 4.2.?
> > gfortran isn't too bad, you most certainly would rather use gcc44
> > if you can.  Literally, hundreds of bugs and several new feature
> > have been add to gfortran in going from 4.2.? to gcc 4.4.2.
> 
> you can use dragonegg gcc plugin which uses gcc frontend (for any
> language) and uses llvm backed to generate the code:
> 
> 	http://dragonegg.llvm.org/

OP is interested in ia64.  It appears that dragonegg is ia32
and amd64 only.  Additionally, dragonegg is a gcc plugin.  OP
can't get gcc to build, so the plugin would be of no use.

However, this does look like an interesting project.

-- 
Steve
From bugmaster at FreeBSD.org  Mon Nov 16 11:06:55 2009
From: bugmaster at FreeBSD.org (FreeBSD bugmaster)
Date: Mon Nov 16 11:08:27 2009
Subject: Current problem reports assigned to freebsd-ia64@FreeBSD.org
Message-ID: <200911161106.nAGB6skZ011193@freefall.freebsd.org>

Note: to view an individual PR, use:
  http://www.freebsd.org/cgi/query-pr.cgi?pr=(number).

The following is a listing of current problems submitted by FreeBSD users.
These represent problem reports covering all versions including
experimental development code and obsolete releases.


S Tracker      Resp.      Description
--------------------------------------------------------------------------------
o ia64/120315  ia64       Backing store switch in exception_save_restart leaves 
o ia64/113102  ia64       [MCA] Multiple records can have the same sequence numb
o ia64/86218   ia64       Mozilla / Firefox: regxpcom or regchrome broken on ia6

3 problems total.

From mexas at bristol.ac.uk  Mon Nov 16 17:03:28 2009
From: mexas at bristol.ac.uk (Anton Shterenlikht)
Date: Mon Nov 16 17:03:35 2009
Subject: kde4
Message-ID: <20091116170322.GA82372@mech-cluster241.men.bris.ac.uk>

on ia64 kern.osreldate: 900002 I've successfully built kdebase4.
konqueror seems to be working ok, save for lots of messages like

kdeinit4: preparing to launch /usr/local/kde4/lib/kde4/kio_file.so
kdeinit4: preparing to launch /usr/local/kde4/lib/kde4/kio_file.so
QWaitCondition: mutex destroy failure: Device busy
QWaitCondition: mutex destroy failure: Device busy
QMutex: mutex destroy failure: Device busy
QWaitCondition: mutex destroy failure: Device busy
QMutex: mutex destroy failure: Device busy
QWaitCondition: mutex destroy failure: Device busy
QMutex: mutex destroy failure: Device busy
kdeinit4: preparing to launch /usr/local/kde4/lib/kde4/kio_http.so
kdeinit4: preparing to launch /usr/local/kde4/lib/kde4/kio_http.so
kdeinit4: preparing to launch /usr/local/kde4/lib/kde4/kio_http.so
QMutex: mutex destroy failure: Device busy
QMutex: mutex destroy failure: Device busy
QPainter::begin: Widget painting can only begin as a result of a paintEvent
QPainter::translate: Painter not active
QPainter::setClipRect: Painter not active
QPainter::font: Painter not active
QPainter::setFont: Painter not active
QPainter::setPen: Painter not active
kdeinit4: preparing to launch /usr/local/kde4/lib/kde4/kio_http.so
...


-- 
Anton Shterenlikht
Room 2.6, Queen's Building
Mech Eng Dept
Bristol University
University Walk, Bristol BS8 1TR, UK
Tel: +44 (0)117 331 5944
Fax: +44 (0)117 929 4423
From mexas at bristol.ac.uk  Mon Nov 16 17:07:02 2009
From: mexas at bristol.ac.uk (Anton Shterenlikht)
Date: Mon Nov 16 17:07:08 2009
Subject: port security/nss fails to build on ia64 - assembler trouble
Message-ID: <20091116170654.GA82410@mech-cluster241.men.bris.ac.uk>

[a port build failure report]

on ia64, kern.osreldate: 900002, while trying to build port
security/nss I get:

gmake[2]: Leaving directory `/usr/ports/security/nss/work/nss-3.12.4/mozilla/security/nss/lib/util'
cd freebl; gmake libs
gmake[2]: Entering directory `/usr/ports/security/nss/work/nss-3.12.4/mozilla/security/nss/lib/freebl'
../../../coreconf/nsinstall/FreeBSD9.0_OPT.OBJ/nsinstall -R -m 664 FreeBSD9.0_OPT.OBJ/libfreebl.a ../../../../dist/FreeBSD9.0_OPT.OBJ/lib
gmake FREEBL_CHILD_BUILD=1 \
 OBJDIR=FreeBSD9.0_OPT.OBJ/FreeBSD_SINGLE_SHLIB libs
gmake[3]: Entering directory `/usr/ports/security/nss/work/nss-3.12.4/mozilla/security/nss/lib/freebl'
cc -o FreeBSD9.0_OPT.OBJ/FreeBSD_SINGLE_SHLIB/sha_fast.o -c -O2 -pipe -I/usr/local/include/nspr -L/usr/local/lib -fno-strict-aliasing -O -fPIC -ansi -Wall -Wno-switch -DFREEBSD -DHAVE_STRERROR -DHAVE_BSD_FLOCK -DXP_UNIX -UDEBUG -DNDEBUG -D_THREAD_SAFE -D_REENTRANT -DNSS_ENABLE_ECC -DUSE_UTIL_DIRECTLY -I../../dist/FreeBSD9.0_OPT.OBJ/include -I../../dist/public/ -I../../dist/private/  -O -fPIC -ansi -Wall -Wno-switch -DFREEBSD -DHAVE_STRERROR -DHAVE_BSD_FLOCK -DXP_UNIX -UDEBUG -DNDEBUG -D_THREAD_SAFE -D_REENTRANT -DNSS_ENABLE_ECC -DUSE_UTIL_DIRECTLY -I../../../dist/FreeBSD9.0_OPT.OBJ/include -I../../../dist/public/ -I../../../dist/private/  -O -fPIC -ansi -Wall -Wno-switch -DFREEBSD -DHAVE_STRERROR -DHAVE_BSD_FLOCK -DXP_UNIX -DSHLIB_SUFFIX=\"so.1\" -DSHLIB_PREFIX=\"lib\" -DSHLIB_VERSION=\"3\" -DSOFTOKEN_SHLIB_VERSION=\"3\" -DRIJNDAEL_INCLUDE_TABLES -UDEBUG -DNDEBUG -D_THREAD_SAFE -D_REENTRANT -DNSS_ENABLE_ECC -DUSE_UTIL_DIRECTLY -DNSS_X86_OR_X64 -DNSS_X86 -DMP_API_COMPATIBLE -I../../../../dist/FreeBSD9.0_OPT.OBJ/include -I../../../../dist/public/nss -I../../../../dist/private/nss -Impi -Iecl  -O -fPIC -ansi -Wall -Wno-switch -DFREEBSD -DHAVE_STRERROR -DHAVE_BSD_FLOCK -DXP_UNIX -DSHLIB_SUFFIX=\"so.1\" -DSHLIB_PREFIX=\"lib\" -DSHLIB_VERSION=\"3\" -DSOFTOKEN_SHLIB_VERSION=\"3\" -DRIJNDAEL_INCLUDE_TABLES -UDEBUG -DNDEBUG -D_THREAD_SAFE -D_REENTRANT -DNSS_ENABLE_ECC -DUSE_UTIL_DIRECTLY -DNSS_X86_OR_X64 -DNSS_X86 -DMP_API_COMPATIBLE -I../../../../dist/FreeBSD9.0_OPT.OBJ/include -I../../../../dist/public/nss -I../../../../dist/private/nss -Impi -Iecl  sha_fast.c
{standard input}: Assembler messages:
{standard input}:63: Error: Unknown opcode `bswap r14'
{standard input}:98: Error: Unknown opcode `bswap r14'
{standard input}:135: Error: Unknown opcode `bswap r14'
{standard input}:171: Error: Unknown opcode `bswap r14'
{standard input}:207: Error: Unknown opcode `bswap r14'
{standard input}:243: Error: Unknown opcode `bswap r14'
{standard input}:278: Error: Unknown opcode `bswap r14'
{standard input}:315: Error: Unknown opcode `bswap r14'
{standard input}:351: Error: Unknown opcode `bswap r14'
{standard input}:387: Error: Unknown opcode `bswap r14'
{standard input}:423: Error: Unknown opcode `bswap r14'
{standard input}:459: Error: Unknown opcode `bswap r14'
{standard input}:495: Error: Unknown opcode `bswap r14'
{standard input}:531: Error: Unknown opcode `bswap r14'
{standard input}:567: Error: Unknown opcode `bswap r14'
{standard input}:603: Error: Unknown opcode `bswap r14'
{standard input}:3585: Error: Unknown opcode `bswap r14'
{standard input}:3591: Error: Unknown opcode `bswap r35'
{standard input}:3605: Error: Unknown opcode `bswap r14'
{standard input}:3615: Error: Unknown opcode `bswap r14'
{standard input}:3625: Error: Unknown opcode `bswap r14'
{standard input}:3635: Error: Unknown opcode `bswap r14'
{standard input}:3645: Error: Unknown opcode `bswap r14'
gmake[3]: *** [FreeBSD9.0_OPT.OBJ/FreeBSD_SINGLE_SHLIB/sha_fast.o] Error 1
gmake[3]: Leaving directory `/usr/ports/security/nss/work/nss-3.12.4/mozilla/security/nss/lib/freebl'
gmake[2]: *** [libs] Error 2
gmake[2]: Leaving directory `/usr/ports/security/nss/work/nss-3.12.4/mozilla/security/nss/lib/freebl'
gmake[1]: *** [libs] Error 2
gmake[1]: Leaving directory `/usr/ports/security/nss/work/nss-3.12.4/mozilla/security/nss/lib'
gmake: *** [libs] Error 2
*** Error code 1

Stop in /usr/ports/security/nss.
*** Error code 1


-- 
Anton Shterenlikht
Room 2.6, Queen's Building
Mech Eng Dept
Bristol University
University Walk, Bristol BS8 1TR, UK
Tel: +44 (0)117 331 5944
Fax: +44 (0)117 929 4423
From xcllnt at mac.com  Mon Nov 16 18:37:07 2009
From: xcllnt at mac.com (Marcel Moolenaar)
Date: Mon Nov 16 18:37:14 2009
Subject: port security/nss fails to build on ia64 - assembler trouble
In-Reply-To: <20091116170654.GA82410@mech-cluster241.men.bris.ac.uk>
References: <20091116170654.GA82410@mech-cluster241.men.bris.ac.uk>
Message-ID: <0BBCDA29-8A79-4E78-A619-CD0F38228D61@mac.com>


On Nov 16, 2009, at 9:06 AM, Anton Shterenlikht wrote:


> [a port build failure report]
> 
> on ia64, kern.osreldate: 900002, while trying to build port
> security/nss I get:
> 
> gmake[2]: Leaving directory `/usr/ports/security/nss/work/nss-3.12.4/mozilla/security/nss/lib/util'
> cd freebl; gmake libs
> gmake[2]: Entering directory `/usr/ports/security/nss/work/nss-3.12.4/mozilla/security/nss/lib/freebl'
> ../../../coreconf/nsinstall/FreeBSD9.0_OPT.OBJ/nsinstall -R -m 664 FreeBSD9.0_OPT.OBJ/libfreebl.a ../../../../dist/FreeBSD9.0_OPT.OBJ/lib
> gmake FREEBL_CHILD_BUILD=1 \
> OBJDIR=FreeBSD9.0_OPT.OBJ/FreeBSD_SINGLE_SHLIB libs
> gmake[3]: Entering directory `/usr/ports/security/nss/work/nss-3.12.4/mozilla/security/nss/lib/freebl'
> cc -o FreeBSD9.0_OPT.OBJ/FreeBSD_SINGLE_SHLIB/sha_fast.o -c -O2 -pipe -I/usr/local/include/nspr -L/usr/local/lib -fno-strict-aliasing -O -fPIC -ansi -Wall -Wno-switch -DFREEBSD -DHAVE_STRERROR -DHAVE_BSD_FLOCK -DXP_UNIX -UDEBUG -DNDEBUG -D_THREAD_SAFE -D_REENTRANT -DNSS_ENABLE_ECC -DUSE_UTIL_DIRECTLY -I../../dist/FreeBSD9.0_OPT.OBJ/include -I../../dist/public/ -I../../dist/private/  -O -fPIC -ansi -Wall -Wno-switch -DFREEBSD -DHAVE_STRERROR -DHAVE_BSD_FLOCK -DXP_UNIX -UDEBUG -DNDEBUG -D_THREAD_SAFE -D_REENTRANT -DNSS_ENABLE_ECC -DUSE_UTIL_DIRECTLY -I../../../dist/FreeBSD9.0_OPT.OBJ/include -I../../../dist/public/ -I../../../dist/private/  -O -fPIC -ansi -Wall -Wno-switch -DFREEBSD -DHAVE_STRERROR -DHAVE_BSD_FLOCK -DXP_UNIX -DSHLIB_SUFFIX=\"so.1\" -DSHLIB_PREFIX=\"lib\" -DSHLIB_VERSION=\"3\" -DSOFTOKEN_SHLIB_VERSION=\"3\" -DRIJNDAEL_INCLUDE_TABLES -UDEBUG -DNDEBUG -D_THREAD_SAFE -D_REENTRANT -DNSS_ENABLE_ECC -DUSE_UTIL_DIRECTLY -DNSS_X86_OR_X64 -DNSS_X86 -DMP_API_COMPATIBLE -I../../../../dist/FreeBSD9.0_OPT.OBJ/include -I../../../../dist/public/nss -I../../../../dist/private/nss -Impi -Iecl  -O -fPIC -ansi -Wall -Wno-switch -DFREEBSD -DHAVE_STRERROR -DHAVE_BSD_FLOCK -DXP_UNIX -DSHLIB_SUFFIX=\"so.1\" -DSHLIB_PREFIX=\"lib\" -DSHLIB_VERSION=\"3\" -DSOFTOKEN_SHLIB_VERSION=\"3\" -DRIJNDAEL_INCLUDE_TABLES -UDEBUG -DNDEBUG -D_THREAD_SAFE -D_REENTRANT -DNSS_ENABLE_ECC -DUSE_UTIL_DIRECTLY -DNSS_X86_OR_X64 -DNSS_X86 -DMP_API_COMPATIBLE -I../../../../dist/FreeBSD9.0_OPT.OBJ/include -I../../../../dist/public/nss -I../../../../dist/private/nss -Impi -Iecl  sha_fast.c

I ran into this as well. I thought I fixed this.
Can you update your ports tree and try again. In
the mean time I'll see what happened to my fix.

FYI,

-- 
Marcel Moolenaar
xcllnt@mac.com



From mexas at bristol.ac.uk  Tue Nov 17 11:31:46 2009
From: mexas at bristol.ac.uk (Anton Shterenlikht)
Date: Tue Nov 17 11:31:52 2009
Subject: hyperthreading ?
Message-ID: <20091117113119.GA91601@mech-cluster241.men.bris.ac.uk>

Has anybody tried hyperthreading on ia64 FBSD?

I know that on ia64 VMS effects of hyperthreading
are very application dependent. In some cases
there is a significant speed-up, in others the apps
are running slower.

many thanks
anton

-- 
Anton Shterenlikht
Room 2.6, Queen's Building
Mech Eng Dept
Bristol University
University Walk, Bristol BS8 1TR, UK
Tel: +44 (0)117 331 5944
Fax: +44 (0)117 929 4423
From mexas at bristol.ac.uk  Tue Nov 17 15:06:58 2009
From: mexas at bristol.ac.uk (Anton Shterenlikht)
Date: Tue Nov 17 15:07:05 2009
Subject: port security/nss fails to build on ia64 - assembler trouble
In-Reply-To: <0BBCDA29-8A79-4E78-A619-CD0F38228D61@mac.com>
References: <20091116170654.GA82410@mech-cluster241.men.bris.ac.uk>
	<0BBCDA29-8A79-4E78-A619-CD0F38228D61@mac.com>
Message-ID: <20091117150634.GA3669@mech-cluster241.men.bris.ac.uk>

On Mon, Nov 16, 2009 at 10:36:50AM -0800, Marcel Moolenaar wrote:
> .OBJ/include -I../../../../dist/public/nss -I../../../../dist/private/nss -Impi -Iecl  -O -fPIC -ansi -Wall -Wno-switch -DFREEBSD -DHAVE_STRERROR -DHAVE_BSD_FLOCK -DXP_UNIX -DSHLIB_SUFFIX=\"so.1\" -DSHLIB_PREFIX=\"lib\" -DSHLIB_VERSION=\"3\" -DSOFTOKEN_SHLIB_VERSION=\"3\" -DRIJNDAEL_INCLUDE_TABLES -UDEBUG -DNDEBUG -D_THREAD_SAFE -D_REENTRANT -DNSS_ENABLE_ECC -DUSE_UTIL_DIRECTLY -DNSS_X86_OR_X64 -DNSS_X86 -DMP_API_COMPATIBLE -I../../../../dist/FreeBSD9.0_OPT.OBJ/include -I../../../../dist/public/nss -I../../../../dist/private/nss -Impi -Iecl  sha_fast.c
> 
> I ran into this as well. I thought I fixed this.
> Can you update your ports tree and try again. In
> the mean time I'll see what happened to my fix.

no, still the same:

cc -o FreeBSD9.0_OPT.OBJ/FreeBSD_SINGLE_SHLIB/sha_fast.o -c -O2 -pipe -I/usr/local/include/nspr -L/usr/local/lib -fno-strict-aliasing -O -fPIC -ansi -Wall -Wno-switch -DFREEBSD -DHAVE_STRERROR -DHAVE_BSD_FLOCK -DXP_UNIX -UDEBUG -DNDEBUG -D_THREAD_SAFE -D_REENTRANT -DNSS_ENABLE_ECC -DUSE_UTIL_DIRECTLY -I../../dist/FreeBSD9.0_OPT.OBJ/include -I../../dist/public/ -I../../dist/private/  -O -fPIC -ansi -Wall -Wno-switch -DFREEBSD -DHAVE_STRERROR -DHAVE_BSD_FLOCK -DXP_UNIX -UDEBUG -DNDEBUG -D_THREAD_SAFE -D_REENTRANT -DNSS_ENABLE_ECC -DUSE_UTIL_DIRECTLY -I../../../dist/FreeBSD9.0_OPT.OBJ/include -I../../../dist/public/ -I../../../dist/private/  -O -fPIC -ansi -Wall -Wno-switch -DFREEBSD -DHAVE_STRERROR -DHAVE_BSD_FLOCK -DXP_UNIX -DSHLIB_SUFFIX=\"so.1\" -DSHLIB_PREFIX=\"lib\" -DSHLIB_VERSION=\"3\" -DSOFTOKEN_SHLIB_VERSION=\"3\" -DRIJNDAEL_INCLUDE_TABLES -UDEBUG -DNDEBUG -D_THREAD_SAFE -D_REENTRANT -DNSS_ENABLE_ECC -DUSE_UTIL_DIRECTLY -DNSS_X86_OR_X64 -DNSS_X86 -DMP_API_COMPATIBLE -I../../../../dist/FreeBSD9.0_OPT.OBJ/include -I../../../../dist/public/nss -I../../../../dist/private/nss -Impi -Iecl  -O -fPIC -ansi -Wall -Wno-switch -DFREEBSD -DHAVE_STRERROR -DHAVE_BSD_FLOCK -DXP_UNIX -DSHLIB_SUFFIX=\"so.1\" -DSHLIB_PREFIX=\"lib\" -DSHLIB_VERSION=\"3\" -DSOFTOKEN_SHLIB_VERSION=\"3\" -DRIJNDAEL_INCLUDE_TABLES -UDEBUG -DNDEBUG -D_THREAD_SAFE -D_REENTRANT -DNSS_ENABLE_ECC -DUSE_UTIL_DIRECTLY -DNSS_X86_OR_X64 -DNSS_X86 -DMP_API_COMPATIBLE -I../../../../dist/FreeBSD9.0_OPT.OBJ/include -I../../../../dist/public/nss -I../../../../dist/private/nss -Impi -Iecl  sha_fast.c
{standard input}: Assembler messages:
{standard input}:63: Error: Unknown opcode `bswap r14'
{standard input}:98: Error: Unknown opcode `bswap r14'
{standard input}:135: Error: Unknown opcode `bswap r14'
{standard input}:171: Error: Unknown opcode `bswap r14'
{standard input}:207: Error: Unknown opcode `bswap r14'
{standard input}:243: Error: Unknown opcode `bswap r14'
{standard input}:278: Error: Unknown opcode `bswap r14'
{standard input}:315: Error: Unknown opcode `bswap r14'
{standard input}:351: Error: Unknown opcode `bswap r14'
{standard input}:387: Error: Unknown opcode `bswap r14'
{standard input}:423: Error: Unknown opcode `bswap r14'
{standard input}:459: Error: Unknown opcode `bswap r14'
{standard input}:495: Error: Unknown opcode `bswap r14'
{standard input}:531: Error: Unknown opcode `bswap r14'
{standard input}:567: Error: Unknown opcode `bswap r14'
{standard input}:603: Error: Unknown opcode `bswap r14'
{standard input}:3585: Error: Unknown opcode `bswap r14'
{standard input}:3591: Error: Unknown opcode `bswap r35'
{standard input}:3605: Error: Unknown opcode `bswap r14'
{standard input}:3615: Error: Unknown opcode `bswap r14'
{standard input}:3625: Error: Unknown opcode `bswap r14'
{standard input}:3635: Error: Unknown opcode `bswap r14'
{standard input}:3645: Error: Unknown opcode `bswap r14'
gmake[3]: *** [FreeBSD9.0_OPT.OBJ/FreeBSD_SINGLE_SHLIB/sha_fast.o] Error 1
gmake[3]: Leaving directory `/usr/ports/security/nss/work/nss-3.12.4/mozilla/security/nss/lib/freebl'
gmake[2]: *** [libs] Error 2


-- 
Anton Shterenlikht
Room 2.6, Queen's Building
Mech Eng Dept
Bristol University
University Walk, Bristol BS8 1TR, UK
Tel: +44 (0)117 331 5944
Fax: +44 (0)117 929 4423
From xcllnt at mac.com  Tue Nov 17 18:30:36 2009
From: xcllnt at mac.com (Marcel Moolenaar)
Date: Tue Nov 17 18:30:58 2009
Subject: hyperthreading ?
In-Reply-To: <20091117113119.GA91601@mech-cluster241.men.bris.ac.uk>
References: <20091117113119.GA91601@mech-cluster241.men.bris.ac.uk>
Message-ID: <70A300C5-5B38-4598-A544-893380466DF7@mac.com>


On Nov 17, 2009, at 3:31 AM, Anton Shterenlikht wrote:

> Has anybody tried hyperthreading on ia64 FBSD?

I haven't. I'm not aware of anyone else playing with it.

-- 
Marcel Moolenaar
xcllnt@mac.com



From tinderbox at freebsd.org  Fri Nov 20 06:41:43 2009
From: tinderbox at freebsd.org (FreeBSD Tinderbox)
Date: Fri Nov 20 06:42:00 2009
Subject: [head tinderbox] failure on ia64/ia64
Message-ID: <200911200641.nAK6fgtD060956@freebsd-current.sentex.ca>

TB --- 2009-11-20 05:08:32 - tinderbox 2.6 running on freebsd-current.sentex.ca
TB --- 2009-11-20 05:08:32 - starting HEAD tinderbox run for ia64/ia64
TB --- 2009-11-20 05:08:32 - cleaning the object tree
TB --- 2009-11-20 05:08:53 - cvsupping the source tree
TB --- 2009-11-20 05:08:53 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/ia64/ia64/supfile
TB --- 2009-11-20 05:09:20 - building world
TB --- 2009-11-20 05:09:20 - MAKEOBJDIRPREFIX=/obj
TB --- 2009-11-20 05:09:20 - PATH=/usr/bin:/usr/sbin:/bin:/sbin
TB --- 2009-11-20 05:09:20 - TARGET=ia64
TB --- 2009-11-20 05:09:20 - TARGET_ARCH=ia64
TB --- 2009-11-20 05:09:20 - TZ=UTC
TB --- 2009-11-20 05:09:20 - __MAKE_CONF=/dev/null
TB --- 2009-11-20 05:09:20 - cd /src
TB --- 2009-11-20 05:09:20 - /usr/bin/make -B buildworld
>>> World build started on Fri Nov 20 05:09:20 UTC 2009
>>> Rebuilding the temporary build tree
>>> stage 1.1: legacy release compatibility shims
>>> stage 1.2: bootstrap tools
>>> stage 2.1: cleaning up the object tree
>>> stage 2.2: rebuilding the object tree
>>> stage 2.3: build tools
>>> stage 3: cross tools
>>> stage 4.1: building includes
>>> stage 4.2: building libraries
>>> stage 4.3: make dependencies
>>> stage 4.4: building everything
>>> World build completed on Fri Nov 20 06:25:47 UTC 2009
TB --- 2009-11-20 06:25:47 - generating LINT kernel config
TB --- 2009-11-20 06:25:47 - cd /src/sys/ia64/conf
TB --- 2009-11-20 06:25:47 - /usr/bin/make -B LINT
TB --- 2009-11-20 06:25:47 - building LINT kernel
TB --- 2009-11-20 06:25:47 - MAKEOBJDIRPREFIX=/obj
TB --- 2009-11-20 06:25:47 - PATH=/usr/bin:/usr/sbin:/bin:/sbin
TB --- 2009-11-20 06:25:47 - TARGET=ia64
TB --- 2009-11-20 06:25:47 - TARGET_ARCH=ia64
TB --- 2009-11-20 06:25:47 - TZ=UTC
TB --- 2009-11-20 06:25:47 - __MAKE_CONF=/dev/null
TB --- 2009-11-20 06:25:47 - cd /src
TB --- 2009-11-20 06:25:47 - /usr/bin/make -B buildkernel KERNCONF=LINT
>>> Kernel build for LINT started on Fri Nov 20 06:25:47 UTC 2009
>>> stage 1: configuring the kernel
>>> stage 2.1: cleaning up the object tree
>>> stage 2.2: rebuilding the object tree
>>> stage 2.3: build tools
>>> stage 3.1: making dependencies
>>> stage 3.2: building everything
[...]
cc -c -O2 -pipe -fno-strict-aliasing  -std=c99  -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes  -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual  -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc  -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/ia64/libuwx/src -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mconstant-gp -ffixed-r13 -mfixed-range=f32-f127 -fpic -ffreestanding -Werror  /src/sys/ia64/ia64/efi.c
cc -c -O2 -pipe -fno-strict-aliasing  -std=c99  -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes  -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual  -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc  -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/ia64/libuwx/src -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mconstant-gp -ffixed-r13 -mfixed-range=f32-f127 -fpic -ffreestanding -Werror  /src/sys/ia64/ia64/elf_machdep.c
cc -c -O2 -pipe -fno-strict-aliasing  -std=c99  -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes  -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual  -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc  -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/ia64/libuwx/src -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mconstant-gp -ffixed-r13 -mfixed-range=f32-f127 -fpic -ffreestanding -Werror  /src/sys/ia64/ia64/emulate.c
cc -c -x assembler-with-cpp -Wa,-x -DLOCORE -O2 -pipe -fno-strict-aliasing  -std=c99  -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes  -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual  -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc  -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/ia64/libuwx/src -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mconstant-gp -ffixed-r13 -mfixed-range=f32-f127 -fpic -ffreestanding -Werror /src/sys/ia64/ia64/exception.S
In file included from /src/sys/ia64/ia64/exception.S:35:
./assym.s:13:1: error: "KSTACK_PAGES" redefined
In file included from /src/sys/ia64/ia64/exception.S:31:
./opt_kstack_pages.h:1:1: error: this is the location of the previous definition
*** Error code 1

Stop in /obj/ia64/src/sys/LINT.
*** Error code 1

Stop in /src.
*** Error code 1

Stop in /src.
TB --- 2009-11-20 06:41:41 - WARNING: /usr/bin/make returned exit code  1 
TB --- 2009-11-20 06:41:41 - ERROR: failed to build lint kernel
TB --- 2009-11-20 06:41:42 - 4435.35 user 664.91 system 5589.31 real


http://tinderbox.freebsd.org/tinderbox-head-HEAD-ia64-ia64.full
From mexas at bristol.ac.uk  Fri Nov 20 16:47:47 2009
From: mexas at bristol.ac.uk (Anton Shterenlikht)
Date: Fri Nov 20 16:48:00 2009
Subject: open64 fbsd port?
Message-ID: <20091120164741.GA59827@mech-cluster241.men.bris.ac.uk>

Is there a fbsd port of open64 (http://www.open64.net/),
or any branched project?

In particular there is a mention of ORC (http://ipf-orc.sourceforge.net/)
specifically for ia64, but the pages are very out of date.

And then there's something called Aurora, which seems to be the same
as ORC (http://sourceforge.net/projects/ipf-orc/), but also *very*
out of date.

I'm confused 

many thanks
anton

-- 
Anton Shterenlikht
Room 2.6, Queen's Building
Mech Eng Dept
Bristol University
University Walk, Bristol BS8 1TR, UK
Tel: +44 (0)117 331 5944
Fax: +44 (0)117 929 4423
From mexas at bristol.ac.uk  Fri Nov 20 17:01:42 2009
From: mexas at bristol.ac.uk (Anton Shterenlikht)
Date: Fri Nov 20 17:02:02 2009
Subject: open64 fbsd port?
In-Reply-To: <20091120164741.GA59827@mech-cluster241.men.bris.ac.uk>
References: <20091120164741.GA59827@mech-cluster241.men.bris.ac.uk>
Message-ID: <20091120170132.GA62790@mech-cluster241.men.bris.ac.uk>

On Fri, Nov 20, 2009 at 04:47:41PM +0000, Anton Shterenlikht wrote:
> Is there a fbsd port of open64 (http://www.open64.net/),
> or any branched project?
> 
> In particular there is a mention of ORC (http://ipf-orc.sourceforge.net/)
> specifically for ia64, but the pages are very out of date.
> 
> And then there's something called Aurora, which seems to be the same
> as ORC (http://sourceforge.net/projects/ipf-orc/), but also *very*
> out of date.

And also there is OpenUH, primarilily for ia64, but linux:

OpenUH 	Source code,
	IA-64, Red Hat Enterprise Linux AS release 3 and gcc 3.x
	  	openuh-alpha.src.tar.gz  	90.2 MB

and Path64 (http://www.path64.com/)

I understand no fbsd ports for these compilers exist yet?

-- 
Anton Shterenlikht
Room 2.6, Queen's Building
Mech Eng Dept
Bristol University
University Walk, Bristol BS8 1TR, UK
Tel: +44 (0)117 331 5944
Fax: +44 (0)117 929 4423
From mexas at bristol.ac.uk  Fri Nov 20 17:04:03 2009
From: mexas at bristol.ac.uk (Anton Shterenlikht)
Date: Fri Nov 20 17:04:10 2009
Subject: [gcc-bugzilla@gcc.gnu.org: [Bug target/40959] build fails - No
 rule to make target
 `/usr/ports/lang/gcc43/work/build/ia64-portbld-freebsd8.0/libgcc/crtfastmath.o',
 needed by `T_TARGET'.  Stop.]
Message-ID: <20091120170357.GA62829@mech-cluster241.men.bris.ac.uk>

Marcel, does the follwing make sense:

----- Forwarded message from sje at cup dot hp dot com <gcc-bugzilla@gcc.gnu.org> -----


------- Comment #10 from sje at cup dot hp dot com  2009-11-20 16:59 -------
Does freebsd use glibc?  Does freebsd have a system libunwind?  I am going to
guess yes to the first question and no to the second in which case you need to
edit gcc/config.gcc and modify the 'ia64*-*-freebsd*' entry to include the
t-libunwind-elf and ia64/t-glibc-libunwind makefile fragments to the tm_file
list.  That is what 'ia64*-*-linux* does when 'with_system_libunwind' is set to
no.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40959

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.
You reported the bug, or are watching the reporter.

----- End forwarded message -----

-- 
Anton Shterenlikht
Room 2.6, Queen's Building
Mech Eng Dept
Bristol University
University Walk, Bristol BS8 1TR, UK
Tel: +44 (0)117 331 5944
Fax: +44 (0)117 929 4423
From xcllnt at mac.com  Fri Nov 20 18:56:24 2009
From: xcllnt at mac.com (Marcel Moolenaar)
Date: Fri Nov 20 18:56:52 2009
Subject: [gcc-bugzilla@gcc.gnu.org: [Bug target/40959] build fails - No
 rule to make target
 `/usr/ports/lang/gcc43/work/build/ia64-portbld-freebsd8.0/libgcc/crtfastmath.o',
 needed by `T_TARGET'.  Stop.]
In-Reply-To: <20091120170357.GA62829@mech-cluster241.men.bris.ac.uk>
References: <20091120170357.GA62829@mech-cluster241.men.bris.ac.uk>
Message-ID: <1DC89124-7E3F-4DC4-85CD-39F0970DAB9E@mac.com>


On Nov 20, 2009, at 9:03 AM, Anton Shterenlikht wrote:

> Marcel, does the follwing make sense:
> 
> ----- Forwarded message from sje at cup dot hp dot com <gcc-bugzilla@gcc.gnu.org> -----
> 
> 
> ------- Comment #10 from sje at cup dot hp dot com  2009-11-20 16:59 -------
> Does freebsd use glibc?  Does freebsd have a system libunwind?  I am going to
> guess yes to the first question and no to the second in which case you need to
> edit gcc/config.gcc and modify the 'ia64*-*-freebsd*' entry to include the
> t-libunwind-elf and ia64/t-glibc-libunwind makefile fragments to the tm_file
> list.  That is what 'ia64*-*-linux* does when 'with_system_libunwind' is set to
> no.

FreeBSD does *NOT* use glibc.
FreeBSD/ia64 does *NOT* (yet) have a system libunwind.

FYI,

-- 
Marcel Moolenaar
xcllnt@mac.com



From xcllnt at mac.com  Fri Nov 20 19:07:53 2009
From: xcllnt at mac.com (Marcel Moolenaar)
Date: Fri Nov 20 19:08:00 2009
Subject: open64 fbsd port?
In-Reply-To: <20091120164741.GA59827@mech-cluster241.men.bris.ac.uk>
References: <20091120164741.GA59827@mech-cluster241.men.bris.ac.uk>
Message-ID: <2DCF854B-29FF-4915-A456-E088CF9E3D1B@mac.com>


On Nov 20, 2009, at 8:47 AM, Anton Shterenlikht wrote:

> Is there a fbsd port of open64 (http://www.open64.net/),
> or any branched project?

Not at this time.

> In particular there is a mention of ORC (http://ipf-orc.sourceforge.net/)
> specifically for ia64, but the pages are very out of date.

open64 includes ORC. I believe ORC is EOL.

> And then there's something called Aurora, which seems to be the same
> as ORC (http://sourceforge.net/projects/ipf-orc/), but also *very*
> out of date.

They probably renamed the project. It does look like the same
thing.

FYI,

-- 
Marcel Moolenaar
xcllnt@mac.com



From xcllnt at mac.com  Fri Nov 20 19:14:02 2009
From: xcllnt at mac.com (Marcel Moolenaar)
Date: Fri Nov 20 19:14:14 2009
Subject: open64 fbsd port?
In-Reply-To: <20091120170132.GA62790@mech-cluster241.men.bris.ac.uk>
References: <20091120164741.GA59827@mech-cluster241.men.bris.ac.uk>
	<20091120170132.GA62790@mech-cluster241.men.bris.ac.uk>
Message-ID: <E8B59B1B-F179-4B41-8AE7-9754B46877FC@mac.com>


On Nov 20, 2009, at 9:01 AM, Anton Shterenlikht wrote:

> On Fri, Nov 20, 2009 at 04:47:41PM +0000, Anton Shterenlikht wrote:
>> Is there a fbsd port of open64 (http://www.open64.net/),
>> or any branched project?
>> 
>> In particular there is a mention of ORC (http://ipf-orc.sourceforge.net/)
>> specifically for ia64, but the pages are very out of date.
>> 
>> And then there's something called Aurora, which seems to be the same
>> as ORC (http://sourceforge.net/projects/ipf-orc/), but also *very*
>> out of date.
> 
> And also there is OpenUH, primarilily for ia64, but linux:
> 
> OpenUH 	Source code,
> 	IA-64, Red Hat Enterprise Linux AS release 3 and gcc 3.x
> 	  	openuh-alpha.src.tar.gz  	90.2 MB

Looks like a branch off of Open64.

> 
> and Path64 (http://www.path64.com/)

I don't believe Path64 has an ia64 backend (it's optimized for amd64),
but that may be pulled from Open64. I think Path64 may be a better
investment than Open64 (for FreeBSD), if the project is more open...

> I understand no fbsd ports for these compilers exist yet?

Correct.

-- 
Marcel Moolenaar
xcllnt@mac.com



From bugmaster at FreeBSD.org  Mon Nov 23 11:06:57 2009
From: bugmaster at FreeBSD.org (FreeBSD bugmaster)
Date: Mon Nov 23 11:08:26 2009
Subject: Current problem reports assigned to freebsd-ia64@FreeBSD.org
Message-ID: <200911231106.nANB6uZp070154@freefall.freebsd.org>

Note: to view an individual PR, use:
  http://www.freebsd.org/cgi/query-pr.cgi?pr=(number).

The following is a listing of current problems submitted by FreeBSD users.
These represent problem reports covering all versions including
experimental development code and obsolete releases.


S Tracker      Resp.      Description
--------------------------------------------------------------------------------
o ia64/120315  ia64       Backing store switch in exception_save_restart leaves 
o ia64/113102  ia64       [MCA] Multiple records can have the same sequence numb
o ia64/86218   ia64       Mozilla / Firefox: regxpcom or regchrome broken on ia6

3 problems total.

From mexas at bristol.ac.uk  Mon Nov 23 11:35:12 2009
From: mexas at bristol.ac.uk (Anton Shterenlikht)
Date: Mon Nov 23 11:35:18 2009
Subject: goodbye FreeBSD alpha.. hello FreeBSD ia64
Message-ID: <20091123113507.GB94309@mech-cluster241.men.bris.ac.uk>

It's been about a year now since I moved my last alpha from FreeBSD to VMS.
I'm writing to express my gratitude and admiration to
all those who made FreeBSD alpha port a reality and a success.
I want once again to thank all those who answered my
alpha questions, provided solutions, shared tips and advice.
It's been a very enjoyable experience.

Now it's time to say goodbye..

I moved my alphas to a VMS cluster. That should keep them
useful for several more years.

And I moved all my FreeBSD server needs to ia64. Now, I know
some of you consider it no less alive than alpha, but we shall see.
Being in academia, I'm in a privileged position to take risks.

all the best, and see you again..

-- 
Anton Shterenlikht
Room 2.6, Queen's Building
Mech Eng Dept
Bristol University
University Walk, Bristol BS8 1TR, UK
Tel: +44 (0)117 331 5944
Fax: +44 (0)117 929 4423