Nabble - freebsd-ia64

Re: open64 fbsd port?

2009-11-20T11:14:01Z

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@...

_______________________________________________
freebsd-ia64@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ia64
To unsubscribe, send any mail to "freebsd-ia64-unsubscribe@..."

Re: open64 fbsd port?

2009-11-20T11:07:51Z

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@...

_______________________________________________
freebsd-ia64@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ia64
To unsubscribe, send any mail to "freebsd-ia64-unsubscribe@..."

Re: [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.]

2009-11-20T10:56:22Z

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@...> -----
>
>
> ------- 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@...

_______________________________________________
freebsd-ia64@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ia64
To unsubscribe, send any mail to "freebsd-ia64-unsubscribe@..."

[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.]

2009-11-20T09:03:57Z

Marcel, does the follwing make sense:

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

------- 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
_______________________________________________
freebsd-ia64@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ia64
To unsubscribe, send any mail to "freebsd-ia64-unsubscribe@..."

Re: open64 fbsd port?

2009-11-20T09:01:32Z

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
_______________________________________________
freebsd-ia64@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ia64
To unsubscribe, send any mail to "freebsd-ia64-unsubscribe@..."

open64 fbsd port?

2009-11-20T08:47:41Z

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
_______________________________________________
freebsd-ia64@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ia64
To unsubscribe, send any mail to "freebsd-ia64-unsubscribe@..."

[head tinderbox] failure on ia64/ia64

2009-11-19T22:41:42Z

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
_______________________________________________
freebsd-ia64@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ia64
To unsubscribe, send any mail to "freebsd-ia64-unsubscribe@..."

Re: hyperthreading ?

2009-11-17T10:30:15Z

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@...

_______________________________________________
freebsd-ia64@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ia64
To unsubscribe, send any mail to "freebsd-ia64-unsubscribe@..."

Re: port security/nss fails to build on ia64 - assembler trouble

2009-11-17T07:06:34Z

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
_______________________________________________
freebsd-ia64@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ia64
To unsubscribe, send any mail to "freebsd-ia64-unsubscribe@..."

hyperthreading ?

2009-11-17T03:31:19Z

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
_______________________________________________
freebsd-ia64@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ia64
To unsubscribe, send any mail to "freebsd-ia64-unsubscribe@..."

Re: port security/nss fails to build on ia64 - assembler trouble

2009-11-16T10:36:50Z

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@...

_______________________________________________
freebsd-ia64@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ia64
To unsubscribe, send any mail to "freebsd-ia64-unsubscribe@..."

port security/nss fails to build on ia64 - assembler trouble

2009-11-16T09:06:54Z

[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
_______________________________________________
freebsd-ia64@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ia64
To unsubscribe, send any mail to "freebsd-ia64-unsubscribe@..."

kde4

2009-11-16T09:03:22Z

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
_______________________________________________
freebsd-ia64@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ia64
To unsubscribe, send any mail to "freebsd-ia64-unsubscribe@..."

Current problem reports assigned to freebsd-ia64@FreeBSD.org

2009-11-16T03:06:54Z

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.

_______________________________________________
freebsd-ia64@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ia64
To unsubscribe, send any mail to "freebsd-ia64-unsubscribe@..."

Re: compiler discussion

2009-11-13T06:55:23Z

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
_______________________________________________
freebsd-ia64@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ia64
To unsubscribe, send any mail to "freebsd-ia64-unsubscribe@..."

Re: compiler discussion

2009-11-13T00:00:33Z

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/
_______________________________________________
freebsd-ia64@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ia64
To unsubscribe, send any mail to "freebsd-ia64-unsubscribe@..."

Re: konqueror causes panic on ia64 current

2009-11-12T11:38:30Z

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@...

_______________________________________________
freebsd-ia64@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ia64
To unsubscribe, send any mail to "freebsd-ia64-unsubscribe@..."

konqueror causes panic on ia64 current

2009-11-12T09:02:22Z

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
_______________________________________________
freebsd-ia64@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ia64
To unsubscribe, send any mail to "freebsd-ia64-unsubscribe@..."

Re: compiler discussion

2009-11-12T08:52:08Z

On Thu, Nov 12, 2009 at 07:34:07AM -0800, Steve Kargl wrote:

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
_______________________________________________
freebsd-ia64@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ia64
To unsubscribe, send any mail to "freebsd-ia64-unsubscribe@..."

Re: compiler discussion

2009-11-12T07:34:07Z

On Thu, Nov 12, 2009 at 02:15:19PM +0000, Anton Shterenlikht wrote:

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
_______________________________________________
freebsd-ia64@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ia64
To unsubscribe, send any mail to "freebsd-ia64-unsubscribe@..."

Re: compiler discussion

2009-11-12T06:32:39Z

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.
_______________________________________________
freebsd-ia64@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ia64
To unsubscribe, send any mail to "freebsd-ia64-unsubscribe@..."

compiler discussion

2009-11-12T06:15:19Z

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
_______________________________________________
freebsd-ia64@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ia64
To unsubscribe, send any mail to "freebsd-ia64-unsubscribe@..."

[head tinderbox] failure on ia64/ia64

2009-11-11T06:02:30Z

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
_______________________________________________
freebsd-ia64@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ia64
To unsubscribe, send any mail to "freebsd-ia64-unsubscribe@..."

Re: 2009 Update

2009-11-10T13:19:16Z

[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@...

_______________________________________________
freebsd-ia64@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ia64
To unsubscribe, send any mail to "freebsd-ia64-unsubscribe@..."

Re: QMutex: mutex destroy failure: Device busy -> Seg fault in ports/x11/kdebase4-workspace

2009-11-09T23:33:23Z

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@...

_______________________________________________
freebsd-ia64@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ia64
To unsubscribe, send any mail to "freebsd-ia64-unsubscribe@..."

firefox3.diff (2K) Download Attachment

Re: QMutex: mutex destroy failure: Device busy -> Seg fault in ports/x11/kdebase4-workspace

2009-11-09T12:48:04Z

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@...

_______________________________________________
freebsd-ia64@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ia64
To unsubscribe, send any mail to "freebsd-ia64-unsubscribe@..."

ports.diff (3K) Download Attachment

QMutex: mutex destroy failure: Device busy -> Seg fault in ports/x11/kdebase4-workspace

2009-11-09T05:21:13Z

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
_______________________________________________
freebsd-ia64@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ia64
To unsubscribe, send any mail to "freebsd-ia64-unsubscribe@..."

Current problem reports assigned to freebsd-ia64@FreeBSD.org

2009-11-09T03:06:54Z

Re: 2009 Update

2009-11-07T22:54:15Z

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.
_______________________________________________
freebsd-ia64@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ia64
To unsubscribe, send any mail to "freebsd-ia64-unsubscribe@..."

Re: 2009 Update

2009-11-07T22:43:45Z

>>>>> "C" == C Bergström <codestr0m@...> writes:

C> Peter Chubb wrote:
>>>>>>> "Anton" == Anton Shterenlikht <mexas@...> 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
_______________________________________________
freebsd-ia64@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ia64
To unsubscribe, send any mail to "freebsd-ia64-unsubscribe@..."

Re: 2009 Update

2009-11-07T21:14:01Z

Peter Chubb wrote:

>>>>>> "Anton" == Anton Shterenlikht <mexas@...> 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

_______________________________________________
freebsd-ia64@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ia64
To unsubscribe, send any mail to "freebsd-ia64-unsubscribe@..."

Re: 2009 Update

2009-11-07T17:08:57Z

>>>>> "Anton" == Anton Shterenlikht <mexas@...> 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
_______________________________________________
freebsd-ia64@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ia64
To unsubscribe, send any mail to "freebsd-ia64-unsubscribe@..."

Re: 2009 Update

2009-11-07T15:22:51Z

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
_______________________________________________
freebsd-ia64@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ia64
To unsubscribe, send any mail to "freebsd-ia64-unsubscribe@..."

Re: 2009 Update

2009-11-07T14:26:27Z

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)
_______________________________________________
freebsd-ia64@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ia64
To unsubscribe, send any mail to "freebsd-ia64-unsubscribe@..."

Re: 2009 Update

2009-11-07T13:40:31Z

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
_______________________________________________
freebsd-ia64@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ia64
To unsubscribe, send any mail to "freebsd-ia64-unsubscribe@..."