From owner-pro64-support@oss.sgi.com Thu Feb 1 10:55:06 2001 Received: by oss.sgi.com id ; Thu, 1 Feb 2001 10:54:56 -0800 Received: from selene.cps.intel.com ([192.198.165.10]:23048 "EHLO selene.cps.intel.com") by oss.sgi.com with ESMTP id ; Thu, 1 Feb 2001 10:54:44 -0800 Received: from SMTP (fmsmsxvs04-1.fm.intel.com [132.233.42.204]) by selene.cps.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.33 2000/11/21 19:27:27 smothers Exp $) with SMTP id KAA26798 for ; Thu, 1 Feb 2001 10:54:34 -0800 (PST) Received: from fmsmsx26.fm.intel.com ([132.233.48.26]) by 132.233.48.204 (Norton AntiVirus for Internet Email Gateways 1.0) ; Thu, 01 Feb 2001 18:54:34 0000 (GMT) Received: by fmsmsx26.fm.intel.com with Internet Mail Service (5.5.2650.21) id ; Thu, 1 Feb 2001 10:54:33 -0800 Message-ID: From: "Kakulavarapu, Prasad" To: pro64-support@oss.sgi.com Subject: Stack trace Utility for Liniux64 Date: Thu, 1 Feb 2001 10:54:23 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Sender: owner-pro64-support@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;pro64-support-outgoing Hello, Is there a Stacktrace utility for Linux64? We need this to unwind the stack frames to get the function call hierarchy. Needed for debugging after an exception. Any info on such utility for Linux32 also would be helpful; we can port it to Linux64. I learnt that a library function called tracebk() with same functionality was available on Cray. Appreciate any info. Thanks, Prasad From owner-pro64-support@oss.sgi.com Fri Feb 2 18:54:35 2001 Received: by oss.sgi.com id ; Fri, 2 Feb 2001 18:54:25 -0800 Received: from [38.170.141.29] ([38.170.141.29]:27379 "EHLO mail-in.hq.tensilica.com") by oss.sgi.com with ESMTP id ; Fri, 2 Feb 2001 18:54:08 -0800 Received: from tensilica.com (IDENT:jonhsu@leo-home.hq.tensilica.com [192.168.10.103]) by mail-in.hq.tensilica.com (8.9.3/8.9.3) with ESMTP id SAA07866 for ; Fri, 2 Feb 2001 18:54:08 -0800 Message-ID: <3A7B72A8.936CACCB@tensilica.com> Date: Fri, 02 Feb 2001 18:53:28 -0800 From: John Hsu X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.16-3 i686) X-Accept-Language: en MIME-Version: 1.0 To: pro64-support@oss.sgi.com Subject: Front-end bug Content-Type: multipart/mixed; boundary="------------8F25474720705EB9A59BB8CC" Sender: owner-pro64-support@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;pro64-support-outgoing This is a multi-part message in MIME format. --------------8F25474720705EB9A59BB8CC Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit I have encountered another front end bug while trying to compile libstdc++-v3. I've attached a simple test case. > sgiCC -c localename.i ### Assertion failure at line 1117 of ../../g++fe/wfe_decl.cxx: ### Compiler Error during Writing WHIRL file phase: ### unexpected tree code ptrmem_cst sgiCC INTERNAL ERROR: /usr/lib/gcc-lib/ia64-sgi-linux/sgicc-1.0/gfecc returned non-zero status 1 --------------8F25474720705EB9A59BB8CC Content-Type: text/plain; charset=us-ascii; name="localename.i" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="localename.i" namespace std { class locale { public: class _Impl; }; class locale::_Impl { public: _Impl(); void _M_construct_collate(const char*); void _M_construct_ctype(const char*); void _M_construct_monetary(const char*); void _M_construct_numeric(const char*); void _M_construct_time(const char*); void _M_construct_messages(const char*); }; } namespace std { locale::_Impl:: _Impl() { static void(_Impl::* ctors[]) (const char*) = { &locale::_Impl::_M_construct_collate, &locale::_Impl::_M_construct_ctype, &locale::_Impl::_M_construct_monetary, &locale::_Impl::_M_construct_numeric, &locale::_Impl::_M_construct_time, &locale::_Impl::_M_construct_messages, 0 }; } } --------------8F25474720705EB9A59BB8CC-- From owner-pro64-support@oss.sgi.com Mon Feb 5 02:57:24 2001 Received: by oss.sgi.com id ; Mon, 5 Feb 2001 02:57:04 -0800 Received: from sgi.SGI.COM ([192.48.153.1]:42529 "EHLO sgi.com") by oss.sgi.com with ESMTP id ; Mon, 5 Feb 2001 02:56:33 -0800 Received: from sguk.reading.sgi.com ([144.253.64.2]) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id CAA07704 for ; Mon, 5 Feb 2001 02:56:31 -0800 (PST) mail_from (mfoster@sgi.com) Received: from nt-reading1.reading.sgi.com (nt-reading1.reading.sgi.com [144.253.64.202]) by sguk.reading.sgi.com (980427.SGI.8.8.8/980728.SGI.AUTOCF.hoststrip-1.1) via ESMTP id KAA52996 for ; Mon, 5 Feb 2001 10:55:14 GMT Received: by nt-reading1.reading.sgi.com with Internet Mail Service (5.5.2650.21) id ; Mon, 5 Feb 2001 10:54:45 -0000 Message-ID: From: Martyn Foster To: pro64-support@oss.sgi.com Subject: link flags? Date: Mon, 5 Feb 2001 10:54:43 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Sender: owner-pro64-support@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;pro64-support-outgoing bash-2.04$ rm bt.A.9 bash-2.04$ sgif90 -O3 -Wl,-dont_warn_unused -o bt.A.9 bt.o make_set.o initialize.o exact_solution.o exact_rhs.o set_constants.o adi.o define.o copy_faces.o rhs.o lhsx.o lhsy.o lhsz.o x_solve.o y_solve.o z_solve.o add.o error.o verify.o setup_mpi.o print_results.o timers.o -lmpi ls bt*/usr/lib/gcc-lib/ia64-cygnus-linux/2.96-ia64-000717/../../../libfortran.a (open.o):../../libf/fio/open.c:905: the use of `tempnam' is dangerous, better use `mkstemp' bash-2.04$ ls bt* bt.f bt.o bash-2.04$ rm bt.A.9 rm: cannot remove `bt.A.9': No such file or directory bash-2.04$ sgif90 -O3 -o bt.A.9 bt.o make_set.o initialize.o exact_solution.o exact_rhs.o set_constants.o adi.o define.o copy_faces.o rhs.o lhsx.o lhsy.o lhsz.o x_solve.o y_solve.o z_solve.o add.o error.o verify.o setup_mpi.o print_results.o timers.o -lmpi ls bt* /usr/lib/gcc-lib/ia64-cygnus-linux/2.96-ia64-000717/../../../libfortran.a(op en.o):../../libf/fio/open.c:905: the use of `tempnam' is dangerous, better use `mkstemp' bash-2.04$ ls bt* bt.A.9 bt.f bt.o Is the linker behaving appropriately here? Should I get a message? Cheers, Martyn From owner-pro64-support@oss.sgi.com Mon Feb 5 08:04:14 2001 Received: by oss.sgi.com id ; Mon, 5 Feb 2001 08:03:54 -0800 Received: from deliverator.sgi.com ([204.94.214.10]:16675 "EHLO deliverator.sgi.com") by oss.sgi.com with ESMTP id ; Mon, 5 Feb 2001 08:03:37 -0800 Received: from gaea.engr.sgi.com (gaea.engr.sgi.com [130.62.180.97]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id IAA29229 for ; Mon, 5 Feb 2001 08:02:36 -0800 (PST) mail_from (murthy@sgi.com) Received: from sgi.com (localhost [127.0.0.1]) by gaea.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) via ESMTP id IAA27264; Mon, 5 Feb 2001 08:03:26 -0800 (PST) Message-ID: <3A7ECECD.22DFD9F6@sgi.com> Date: Mon, 05 Feb 2001 08:03:25 -0800 From: Chandrasekhar Murthy X-Mailer: Mozilla 4.51C-SGI [en] (X11; I; IRIX 6.5 IP32) X-Accept-Language: en MIME-Version: 1.0 To: John Hsu CC: pro64-support@oss.sgi.com Subject: Re: Front-end bug References: <3A7B72A8.936CACCB@tensilica.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-pro64-support@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;pro64-support-outgoing I will open a bug report for this. Thaks for reporting the problem. From owner-pro64-support@oss.sgi.com Mon Feb 5 08:38:14 2001 Received: by oss.sgi.com id ; Mon, 5 Feb 2001 08:37:55 -0800 Received: from mailgate.rz.uni-karlsruhe.de ([129.13.64.97]:43790 "EHLO mailgate.rz.uni-karlsruhe.de") by oss.sgi.com with ESMTP id ; Mon, 5 Feb 2001 08:37:49 -0800 Received: from wbkpc107 (wbkpc107.mach.uni-karlsruhe.de [129.13.175.107]) by mailgate.rz.uni-karlsruhe.de with smtp (Exim 3.16 #1) id 14PoeB-0001Pu-00; Mon, 05 Feb 2001 17:37:47 +0100 Received: by localhost with Microsoft MAPI; Mon, 5 Feb 2001 17:35:23 +0100 Message-ID: <0FE3AC51A09E584DB0D40763A659269E0D3494@wbkex.wbk.uni-karlsruhe.de> From: Dambacher Reply-To: "ulf.dambacher@mach.uni-karlsruhe.de" To: "'pro64-support@oss.sgi.com'" Subject: native linuxia64 compile possible Date: Mon, 5 Feb 2001 17:38:12 +0100 Organization: wbk X-Mailer: Microsoft Internet E-Mail/MAPI - 8.0.0.4211 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: owner-pro64-support@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;pro64-support-outgoing Hi at pro64-support Is it possible to compile the sgicc suite native on a ia64 linux system? The README.src only tells about 32bit cross-compile... Thanks and bye Ulf Dambacher ----- Dipl.-Ing Ulf Dambacher Institut fur Werkzeugmaschinen und Betriebstechnik - Universitat Karlsruhe Tel.: +49 721 608 6022 Fax: +49 721 69 91 53 ulf.dambacher@mach.uni-karlsruhe.de http://www-wbk.mach.uni-karlsruhe.de From owner-pro64-support@oss.sgi.com Mon Feb 5 10:06:05 2001 Received: by oss.sgi.com id ; Mon, 5 Feb 2001 10:05:56 -0800 Received: from sgi.SGI.COM ([192.48.153.1]:35907 "EHLO sgi.com") by oss.sgi.com with ESMTP id ; Mon, 5 Feb 2001 10:05:33 -0800 Received: from sgihud.hudson.sgi.com ([169.238.41.4]) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id KAA08737 for ; Mon, 5 Feb 2001 10:04:01 -0800 (PST) mail_from (lesniak@sgihud.hudson.sgi.com) Received: (from lesniak@localhost) by sgihud.hudson.sgi.com (980427.SGI.8.8.8/980728.SGI.AUTOCF) id NAA60798; Mon, 5 Feb 2001 13:02:20 -0500 (EST) Date: Mon, 5 Feb 2001 13:02:20 -0500 (EST) From: lesniak@sgihud.hudson.sgi.com (Ken Lesniak) Message-Id: <200102051802.NAA60798@sgihud.hudson.sgi.com> To: "'pro64-support@oss.sgi.com'" , "ulf.dambacher@mach.uni-karlsruhe.de" Subject: Re: native linuxia64 compile possible Reply-To: lesniak@sgihud.hudson.sgi.com Sender: owner-pro64-support@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;pro64-support-outgoing >Hi at pro64-support > >Is it possible to compile the sgicc suite native on a ia64 linux system? >The README.src only tells about 32bit cross-compile... > >Thanks and bye > Ulf Dambacher Not yet. There are still some issues we are working on. Stay tuned... Ken From owner-pro64-support@oss.sgi.com Mon Feb 5 10:13:15 2001 Received: by oss.sgi.com id ; Mon, 5 Feb 2001 10:13:05 -0800 Received: from deliverator.sgi.com ([204.94.214.10]:15450 "EHLO deliverator.sgi.com") by oss.sgi.com with ESMTP id ; Mon, 5 Feb 2001 10:12:48 -0800 Received: from cchkms.engr.sgi.com (cchkms.engr.sgi.com [130.62.180.48]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id KAA23591 for ; Mon, 5 Feb 2001 10:11:48 -0800 (PST) mail_from (rat@cchkms.engr.sgi.com) Received: (from rat@localhost) by cchkms.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) id KAA49061; Mon, 5 Feb 2001 10:12:49 -0800 (PST) From: "Ross A. Towle" Message-Id: <10102051012.ZM49049@cchkms.engr.sgi.com> Date: Mon, 5 Feb 2001 10:12:48 -0800 In-Reply-To: Dambacher "native linuxia64 compile possible" (Feb 5, 5:38pm) References: <0FE3AC51A09E584DB0D40763A659269E0D3494@wbkex.wbk.uni-karlsruhe.de> X-Mailer: Z-Mail (3.2.3 08feb96 MediaMail) To: "ulf.dambacher@mach.uni-karlsruhe.de " , "'pro64-support@oss.sgi.com '" Subject: Re: native linuxia64 compile possible Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-pro64-support@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;pro64-support-outgoing At this time building a working native Linux/IA64 Pro64 is not possible. We are working on this right now. The current gdb situation is causing us to use print statements to debug which is slowing down having a native compiler. -Ross From owner-pro64-support@oss.sgi.com Mon Feb 5 10:18:45 2001 Received: by oss.sgi.com id ; Mon, 5 Feb 2001 10:18:36 -0800 Received: from pneumatic-tube.sgi.com ([204.94.214.22]:34908 "EHLO pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP id ; Mon, 5 Feb 2001 10:18:22 -0800 Received: from cchkms.engr.sgi.com (cchkms.engr.sgi.com [130.62.180.48]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id KAA05674 for ; Mon, 5 Feb 2001 10:27:34 -0800 (PST) mail_from (rat@cchkms.engr.sgi.com) Received: (from rat@localhost) by cchkms.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) id KAA48869; Mon, 5 Feb 2001 10:18:22 -0800 (PST) From: "Ross A. Towle" Message-Id: <10102051018.ZM47645@cchkms.engr.sgi.com> Date: Mon, 5 Feb 2001 10:18:22 -0800 In-Reply-To: Martyn Foster "link flags?" (Feb 5, 10:54am) References: X-Mailer: Z-Mail (3.2.3 08feb96 MediaMail) To: Martyn Foster , pro64-support@oss.sgi.com Subject: Re: link flags? Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-pro64-support@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;pro64-support-outgoing The following message happens and, for now, can be ignored: > bt*/usr/lib/gcc-lib/ia64-cygnus-linux/2.96-ia64-000717/../../../libfortran.a > (open.o):../../libf/fio/open.c:905: the use of `tempnam' is dangerous, > better use `mkstemp' This is due to the switch from glibc2.1 to glibc2.2. With the next release of Pro64 (ie 0.13) the runtime libraries will be fully converted to glibc2.2 and the message will not be seen. -Ross From owner-pro64-support@oss.sgi.com Mon Feb 5 11:14:27 2001 Received: by oss.sgi.com id ; Mon, 5 Feb 2001 11:14:07 -0800 Received: from thalia.fm.intel.com ([132.233.247.11]:47378 "EHLO thalia.fm.intel.com") by oss.sgi.com with ESMTP id ; Mon, 5 Feb 2001 11:14:02 -0800 Received: from SMTP (fmsmsxvs02-1.fm.intel.com [132.233.42.202]) by thalia.fm.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.33 2000/11/21 19:27:27 smothers Exp $) with SMTP id TAA08261; Mon, 5 Feb 2001 19:15:10 GMT Received: from fmsmsx29.FM.INTEL.COM ([132.233.48.29]) by 132.233.48.202 (Norton AntiVirus for Internet Email Gateways 1.0) ; Mon, 05 Feb 2001 19:13:45 0000 (GMT) Received: by fmsmsx29.fm.intel.com with Internet Mail Service (5.5.2650.21) id ; Mon, 5 Feb 2001 11:13:44 -0800 Message-ID: <9287DC1579B0D411AA2F009027F44C3F042DF7A6@FMSMSX41> From: "Chan, Sun C" To: "'ulf.dambacher@mach.uni-karlsruhe.de'" , "'pro64-support@oss.sgi.com'" Subject: RE: native linuxia64 compile possible Date: Mon, 5 Feb 2001 11:13:41 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-pro64-support@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;pro64-support-outgoing In theory, that's possible. Remember IA64 architecture guarantees an IA32 binary works. I've seen other compilers (IA32 binary) runs on an Itanium box. Sun > -----Original Message----- > From: Dambacher [mailto:ulf.dambacher@mach.uni-karlsruhe.de] > Sent: Monday, February 05, 2001 8:38 AM > To: 'pro64-support@oss.sgi.com' > Subject: native linuxia64 compile possible > > > Hi at pro64-support > > Is it possible to compile the sgicc suite native on a ia64 > linux system? > The README.src only tells about 32bit cross-compile... > > Thanks and bye > Ulf Dambacher > > > ----- > > Dipl.-Ing Ulf Dambacher > Institut fur Werkzeugmaschinen und Betriebstechnik - > Universitat Karlsruhe > Tel.: +49 721 608 6022 > Fax: +49 721 69 91 53 > ulf.dambacher@mach.uni-karlsruhe.de > http://www-wbk.mach.uni-karlsruhe.de > > > > From owner-pro64-support@oss.sgi.com Mon Feb 5 11:21:57 2001 Received: by oss.sgi.com id ; Mon, 5 Feb 2001 11:21:37 -0800 Received: from probity.mcc.ac.uk ([130.88.200.94]:5647 "EHLO probity.mcc.ac.uk") by oss.sgi.com with ESMTP id ; Mon, 5 Feb 2001 11:21:24 -0800 Received: from wallace.mvc.mcc.ac.uk ([130.88.1.130] helo=man.ac.uk) by probity.mcc.ac.uk with esmtp (Exim 2.05 #4) id 14PrCU-0003iL-00; Mon, 5 Feb 2001 19:21:22 +0000 Message-ID: <3A7EFD31.20E82F6B@man.ac.uk> Date: Mon, 05 Feb 2001 19:21:21 +0000 From: Dan Kidger Organization: Manchester Computing X-Mailer: Mozilla 4.76 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: "Chan, Sun C" CC: "'ulf.dambacher@mach.uni-karlsruhe.de'" , "'pro64-support@oss.sgi.com'" Subject: Re: native linuxia64 compile possible References: <9287DC1579B0D411AA2F009027F44C3F042DF7A6@FMSMSX41> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-pro64-support@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;pro64-support-outgoing "Chan, Sun C" wrote: > > -----Original Message----- > > Is it possible to compile the sgicc suite native on a ia64 > > linux system? > > The README.src only tells about 32bit cross-compile... > In theory, that's possible. Remember IA64 architecture guarantees > an IA32 binary works. I've seen other compilers (IA32 binary) runs > on an Itanium box. > Sun We use the 32bit sgif90 compiler on our IA-64 R+D machines all the time. It of course works. But you pay a large penalty for running in 'Pentium Emulation' mode, making large project compilations painfully slow. A native 64-bit EPIC binary would hopefully speed up compilation by an order of magnitude. Daniel ----------------------------------------------------------------------- Dr. Daniel Kidger | E: d.kidger@man.ac.uk High Performance Computing Group | W: www.csar.cfs.ac.uk Manchester Computing, University of Manchester, | T: +44 161 275 7038 Oxford Road, Manchester, M13 9PL, UK | F: +44 161 275 6800 --------------------Q: what's up ? A: X cross Z --------------------- From owner-pro64-support@oss.sgi.com Mon Feb 5 11:23:57 2001 Received: by oss.sgi.com id ; Mon, 5 Feb 2001 11:23:37 -0800 Received: from sgi.SGI.COM ([192.48.153.1]:15463 "EHLO sgi.com") by oss.sgi.com with ESMTP id ; Mon, 5 Feb 2001 11:23:27 -0800 Received: from cchkms.engr.sgi.com ([130.62.180.48]) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id LAA08923 for ; Mon, 5 Feb 2001 11:23:09 -0800 (PST) mail_from (rat@cchkms.engr.sgi.com) Received: (from rat@localhost) by cchkms.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) id LAA46540; Mon, 5 Feb 2001 11:23:10 -0800 (PST) From: "Ross A. Towle" Message-Id: <10102051123.ZM48941@cchkms.engr.sgi.com> Date: Mon, 5 Feb 2001 11:23:09 -0800 In-Reply-To: "Chan, Sun C" "RE: native linuxia64 compile possible" (Feb 5, 11:13am) References: <9287DC1579B0D411AA2F009027F44C3F042DF7A6@FMSMSX41> X-Mailer: Z-Mail (3.2.3 08feb96 MediaMail) To: "Chan, Sun C" , "'ulf.dambacher@mach.uni-karlsruhe.de '" , "'pro64-support@oss.sgi.com '" Subject: Re: native linuxia64 compile possible Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-pro64-support@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;pro64-support-outgoing Sun is quite correct. If you take a look at the Pro64 webpages you can install the rpms in two situations: 1. as a cross compiler within the HP NUE environment (that gets you include files, libs, ld, as, ...) or 2. on the actual Itanium hardware. This is what we do at SGI and run using the IA-32 compatability feature of Itanium. When I answered your question originally, I assumed you meant the compiler as an IA-64 executable. Using the IA32 compatibility feature of Itanium has been quite useful. For example, we have gotten around problems with perl by using an IA-32 version of perl. -Ross From owner-pro64-support@oss.sgi.com Mon Feb 5 11:59:37 2001 Received: by oss.sgi.com id ; Mon, 5 Feb 2001 11:59:27 -0800 Received: from scapa.cs.ualberta.ca ([129.128.4.44]:20751 "EHLO scapa.cs.ualberta.ca") by oss.sgi.com with ESMTP id ; Mon, 5 Feb 2001 11:59:12 -0800 Received: (from localhost user: 'pengzhao' uid#483 fake: STDIN (pengzhao@peers)) by scapa.cs.ualberta.ca id ; Mon, 5 Feb 2001 12:58:40 -0700 Date: Mon, 5 Feb 2001 12:58:38 -0700 (MST) From: Peng Zhao To: pro64-support@oss.sgi.com Subject: help in compilation of pro64 Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-pro64-support@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;pro64-support-outgoing Hi, I encountered an error when I manually compile the pro64 1. I enter the directory ~/osprey1.0/targia32_ia64_nodebug 2. run make 3. after some time, it responds with following error messages " g++ -D_SGI_SOURCE -D_LANGUAGE_C_PLUS_PLUS -funsigned-char -D__GNU_BUG_WORKAROUND -D_NOTHREADS -c -D_LEGO_CLONER -DBACK_END -Dlonglong -DSTD_MONGOOSE_LOC='"/usr/lib32/cmplrs"' -DMONGOOSE_BE -D_LONGLONG -D_SVR4_SOURCE -D_NEW_SYMTAB -D__MIPS_AND_IA64_ELF_H -I../../be/com -I../../be/com/ia64 -I../../be/region -I../../be/vho -I../../be/lno -I../../common/com -I../../common/com/ia64 -I../../common/targ_info/access -I../../common/util -I../../common/util/ia64 -I../../be/be -I../../be/be/ia64 -I../../common/instrument -I../../common/targ_info/access -I../targ_info -I../../common/util -I. -I../../be -I../../be/com/ia64 -I../../be/cg -I../../be/opt -I../../be/lno -I../../be/region -I../../be/whirl2c -I../../be/whirl2f -I../../be/purple2 -I../../be/prompf_anl -I../../be/vho -I../../ipa/local -I../../ipa/main/analyze -I../../ipa/common -I../../common/instrument -I../include/libelf -fwritable-strings -fPIC -DTARG_IA64 -I../include -O0 -D_MIPSEL -D_LONGLONG -D_MIPS_SZINT=32 -D_MIPS_SZPTR=32 -D_MIPS_SZLONG=32 -MD ../../be/be/driver.cxx -o driver.o In file included from ../../common/com/symtab.h:70, from ../../common/com/wn_core.h:40, from ../../common/com/wn.h:49, from ../../be/com/be_util.h:62, from ../../be/be/driver.cxx:66: ../../common/com/strtab.h:156: warning: ANSI C++ forbids typedef which does not specify a type ../../common/com/strtab.h:156: cannot declare member `hash_map,equal_to,mempool_allocator > >::allocator_type' within `STR_IDX_MAP' ../../common/com/strtab.h:156: parse error before `;' ../../common/com/strtab.h:161: type specifier omitted for parameter ../../common/com/strtab.h:161: parse error before `=' ../../common/com/strtab.h:163: missing ';' before right brace ../../common/com/strtab.h:152: warning: declaration of identifier `rep' as `class hash_map,equal_to,mempool_allocator > > rep' /usr/include/g++-2/stl_hash_map.h:54: warning: conflicts with other use in class as `class hashtable,unsigned int,hash,select1st >,equal_to,mempool_allocator > > hash_map,equal_to,mempool_allocator > >::rep' ../../common/com/strtab.h:165: destructor `STR_IDX_MAP' must match class name `hash_map' ../../common/com/strtab.h:165: template-id `hash_map<>' for `hash_map,equal_to,mempool_allocator > >::~hash_map<>()' does not match any template declaration ../../common/com/strtab.h:165: syntax error before `&' ../../common/com/strtab.h:166: non-member function `operator [](STR_IDX)' cannot have `const' method qualifier ../../common/com/strtab.h:166: `operator [](STR_IDX)' must be a nonstatic member function ../../common/com/strtab.h:166: `operator [](STR_IDX)' must take exactly two arguments ../../common/com/strtab.h: In function `STR_IDX operator [](STR_IDX)': ../../common/com/strtab.h:167: `rep_type' undeclared (first use this function) ../../common/com/strtab.h:167: (Each undeclared identifier is reported only once ../../common/com/strtab.h:167: for each function it appears in.) ../../common/com/strtab.h:167: parse error before `::' ../../common/com/strtab.h:168: `i' undeclared (first use this function) ../../common/com/strtab.h:168: `rep' undeclared (first use this function) ../../common/com/strtab.h:168: confused by earlier errors, bailing out make[1]: *** [driver.o] Error 1 make[1]: Leaving directory `/compsci/brule9/grad/pengzhao/osprey1.0/targia32_ia64_nodebug/be_driver' " can you give me some idea? thanks Peng -- Peng Zhao pengzhao@cs.ualberta.ca Office Hours: http://www.cs.ualberta.ca/~pengzhao Edmonton (CA): 17:00-19:00 TEL (Office): (780)492-5919 Beijing (CH): 08:00-10:00 Office: CAB 430 From owner-pro64-support@oss.sgi.com Tue Feb 6 08:27:17 2001 Received: by oss.sgi.com id ; Tue, 6 Feb 2001 08:26:57 -0800 Received: from beta.dmz-eu.st.com ([164.129.1.35]:61098 "HELO beta.dmz-eu.st.com") by oss.sgi.com with SMTP id ; Tue, 6 Feb 2001 08:26:39 -0800 Received: from zeta.dmz-eu.st.com (zeta.dmz-eu.st.com [164.129.230.9]) by beta.dmz-eu.st.com (STMicroelectronics) with SMTP id 535C648F0 for ; Tue, 6 Feb 2001 16:26:31 +0000 (GMT) Received: by zeta.dmz-eu.st.com (STMicroelectronics, from userid 0) id CCE294B27; Tue, 6 Feb 2001 16:26:33 +0000 (GMT) Received: from thistle.bri.st.com (localhost [127.0.0.1]) by zeta.dmz-eu.st.com (STMicroelectronics) with ESMTP id 59C771845 for ; Tue, 6 Feb 2001 16:26:33 +0000 (GMT) Received: from [138.198.34.73] (helo=HARPO) by thistle.bristol.st.com with smtp (Exim 3.03 #5) id 14QAwn-0007EX-00 for pro64-support@oss.sgi.com; Tue, 06 Feb 2001 16:26:29 +0000 Message-ID: <00c901c0905a$29a01fb0$4922c68a@HARPO> From: "Benedict R. Gaster" To: Subject: Problems with building Pro64 on Linux x86 with GCC 2.95.2... Date: Tue, 6 Feb 2001 16:30:48 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-pro64-support@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;pro64-support-outgoing Hello! Over the last couple of days I have been trying to build the Pro64 sources on the following configuration: Redhat Linux 6.2 Intel PIII GCC 2.95.2 After a few teathing problems I have the remaining outstadning problems and quires that I was hoping people on the list might be able to help me out with. 1) Building the component: /export/home/spymaster/benedict/Pro64/osprey1.0/targia32_ia64_nodebug/g++fe I get the following error: ../../g++fe/wfe_expr.cxx:2675: attempt to take address of bit-field structure member `tree_decl::built_in_class' which I've tracked down tot the following line of code: if (DECL_BUILT_IN (func)) { Replacing this with the following code seems to resolve the problem: if (func->decl.built_in_class) { but I am less than completely sure that this is semantically correct. Have other people come accross this problem? 2) Building the component: /export/home/spymaster/benedict/Pro64/osprey1.0/targia32_ia64_nodebug/crayf9 0 gets to the following like (outputed by gmake) and then fails with the following lines: gmake[2]: Leaving directory `/export/home/spymaster/benedict/Pro64/osprey1.0/targia32_ia64_nodebug/libci f' NLSPATH=/usr/ia64-sgi-linux/lib/gcc-lib/ia64-sgi-linux/sgicc-1.0/%N.cat \ /usr/ia32-sgi-linux/bin/f90 -c -MD ../../../crayf90/fe90/fold.f sh: /usr/ia32-sgi-linux/bin/f90: No such file or directory gmake[1]: *** [fold.o] Error 126 gmake[1]: Leaving directory `/export/home/spymaster/benedict/Pro64/osprey1.0/targia32_ia64_nodebug/crayf 90/fe90' gmake: *** [first] Error 2 Maybe the problem is due to requiring HP's NUE, etc. My main goal for this work is to get the Pro64 generating both IA-64 and MIPS assembler, and whirl IL output (this is my main direction) and have no requirment to build IA-64 libraries or executables. For the moment, at least. 3) What version of the GCC compiler should I be using? I initially tried using 2.97.x but this failed with problems like no headers, etc. Thanks in advance for any help people can provide to shed any light on this problems. Ben. From owner-pro64-support@oss.sgi.com Wed Feb 7 01:55:32 2001 Received: by oss.sgi.com id ; Wed, 7 Feb 2001 01:55:13 -0800 Received: from beta.dmz-eu.st.com ([164.129.1.35]:6817 "HELO beta.dmz-eu.st.com") by oss.sgi.com with SMTP id ; Wed, 7 Feb 2001 01:55:03 -0800 Received: from zeta.dmz-eu.st.com (zeta.dmz-eu.st.com [164.129.230.9]) by beta.dmz-eu.st.com (STMicroelectronics) with SMTP id 2F04749A8 for ; Wed, 7 Feb 2001 09:54:55 +0000 (GMT) Received: by zeta.dmz-eu.st.com (STMicroelectronics, from userid 0) id CCF8C4A22; Wed, 7 Feb 2001 09:54:57 +0000 (GMT) Received: from thistle.bri.st.com (localhost [127.0.0.1]) by zeta.dmz-eu.st.com (STMicroelectronics) with ESMTP id 5D0801849 for ; Wed, 7 Feb 2001 09:54:57 +0000 (GMT) Received: from [138.198.34.73] (helo=HARPO) by thistle.bristol.st.com with smtp (Exim 3.03 #5) id 14QRJN-0002QS-00 for pro64-support@oss.sgi.com; Wed, 07 Feb 2001 09:54:53 +0000 Message-ID: <042b01c090ec$9f536c20$4922c68a@HARPO> From: "Benedict R. Gaster" To: Subject: MIPS backend for Pro64? Date: Wed, 7 Feb 2001 09:59:12 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-pro64-support@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;pro64-support-outgoing hello! I have got the Pro64 compiler to compile and work under 2.95 and is working fine generating IA-64 assembler code, as expected. However, my goal is to have a version that is generating MIPS code and I have been lead to believe that there is a backend for the Pro64, but I cannot find it! Is it the case that a MIPS backend has been generated for the Pro64? If so can be it down loaded? thanks, ben. ps. i'm sure that the above question has been asked on the list before and so I was wondering if there is an archive of all discussion on the mailing lists concerned with Pro64? From owner-pro64-support@oss.sgi.com Wed Feb 7 09:52:14 2001 Received: by oss.sgi.com id ; Wed, 7 Feb 2001 09:51:55 -0800 Received: from pneumatic-tube.sgi.com ([204.94.214.22]:358 "EHLO pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP id ; Wed, 7 Feb 2001 09:51:32 -0800 Received: from cchkms.engr.sgi.com (cchkms.engr.sgi.com [130.62.180.48]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id KAA00839 for ; Wed, 7 Feb 2001 10:00:46 -0800 (PST) mail_from (rat@cchkms.engr.sgi.com) Received: (from rat@localhost) by cchkms.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) id JAA62696; Wed, 7 Feb 2001 09:49:51 -0800 (PST) From: "Ross A. Towle" Message-Id: <10102070949.ZM62253@cchkms.engr.sgi.com> Date: Wed, 7 Feb 2001 09:49:50 -0800 In-Reply-To: "Benedict R. Gaster" "MIPS backend for Pro64?" (Feb 7, 9:59am) References: <042b01c090ec$9f536c20$4922c68a@HARPO> X-Mailer: Z-Mail (3.2.3 08feb96 MediaMail) To: "Benedict R. Gaster" , Subject: Re: MIPS backend for Pro64? Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-pro64-support@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;pro64-support-outgoing A MIPS backend for Pro64 is being developed at the University of Delaware under Professor Gao. I would contact him (ggao@capsl.udel.edu). -Ross From owner-pro64-support@oss.sgi.com Wed Feb 7 13:55:08 2001 Received: by oss.sgi.com id ; Wed, 7 Feb 2001 13:54:57 -0800 Received: from scapa.cs.ualberta.ca ([129.128.4.44]:23314 "EHLO scapa.cs.ualberta.ca") by oss.sgi.com with ESMTP id ; Wed, 7 Feb 2001 13:54:50 -0800 Received: (from localhost user: 'cbarton' uid#359 fake: STDIN (cbarton@tees.cs.ualberta.ca)) by scapa.cs.ualberta.ca id ; Wed, 7 Feb 2001 14:54:22 -0700 Date: Wed, 7 Feb 2001 14:54:22 -0700 (MST) From: Kit Barton To: pro64-support@oss.sgi.com Subject: Mailing List Archive Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-pro64-support@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;pro64-support-outgoing Hello, I am working with a group of students at the University of Alberta on a compiler project involving the Pro64. We are having problems compiling the Pro64 compiler. I was wondering if there is an archive of this mailing list that I could look through to see if the problems we are having have already been covered. Thanks, Kit From owner-pro64-support@oss.sgi.com Wed Feb 7 14:09:58 2001 Received: by oss.sgi.com id ; Wed, 7 Feb 2001 14:09:38 -0800 Received: from [38.170.141.29] ([38.170.141.29]:40434 "EHLO mail-in.hq.tensilica.com") by oss.sgi.com with ESMTP id ; Wed, 7 Feb 2001 14:09:25 -0800 Received: from tensilica.com (IDENT:jonhsu@leo-home.hq.tensilica.com [192.168.10.103]) by mail-in.hq.tensilica.com (8.9.3/8.9.3) with ESMTP id OAA25449 for ; Wed, 7 Feb 2001 14:09:24 -0800 Message-ID: <3A81C761.17A3960E@tensilica.com> Date: Wed, 07 Feb 2001 14:08:33 -0800 From: John Hsu X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.16-3 i686) X-Accept-Language: en MIME-Version: 1.0 To: pro64-support@oss.sgi.com Subject: extern "C" problem Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-pro64-support@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;pro64-support-outgoing Hi, I'm having a problem where the Pro64 front end is rejecting the following test case. I believe the extern "C" qualifier can be applied to a single declaration without the use of braces, so this should be a legal C++ file. extern "C" struct mutex_t { int sem; }; > sgiCC -c test.cc test.cc:4: storage class specified for field `sem' From owner-pro64-support@oss.sgi.com Wed Feb 7 15:23:58 2001 Received: by oss.sgi.com id ; Wed, 7 Feb 2001 15:23:48 -0800 Received: from pneumatic-tube.sgi.com ([204.94.214.22]:62757 "EHLO pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP id ; Wed, 7 Feb 2001 15:23:29 -0800 Received: from gaea.engr.sgi.com (gaea.engr.sgi.com [130.62.180.97]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id PAA06873 for ; Wed, 7 Feb 2001 15:32:43 -0800 (PST) mail_from (murthy@sgi.com) Received: from sgi.com (localhost [127.0.0.1]) by gaea.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) via ESMTP id PAA92482; Wed, 7 Feb 2001 15:21:57 -0800 (PST) Message-ID: <3A81D895.BC1342AC@sgi.com> Date: Wed, 07 Feb 2001 15:21:57 -0800 From: Chandrasekhar Murthy X-Mailer: Mozilla 4.51C-SGI [en] (X11; I; IRIX 6.5 IP32) X-Accept-Language: en MIME-Version: 1.0 To: John Hsu CC: pro64-support@oss.sgi.com Subject: Re: extern "C" problem References: <3A81C761.17A3960E@tensilica.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-pro64-support@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;pro64-support-outgoing John Hsu wrote: > > Hi, > > I'm having a problem where the Pro64 front end is rejecting the > following test case. I believe the extern "C" qualifier can be applied > to a single declaration without the use of braces, so this should be a > legal C++ file. > > extern "C" > struct mutex_t > { > int sem; > }; > > > sgiCC -c test.cc > test.cc:4: storage class specified for field `sem' This appears to be a problem with g++. You might want to report it to http://gcc.gnu.org/bugs.html Murthy From owner-pro64-support@oss.sgi.com Fri Feb 9 13:29:48 2001 Received: by oss.sgi.com id ; Fri, 9 Feb 2001 13:29:37 -0800 Received: from [38.170.141.29] ([38.170.141.29]:765 "EHLO mail-in.hq.tensilica.com") by oss.sgi.com with ESMTP id ; Fri, 9 Feb 2001 13:29:23 -0800 Received: from tensilica.com (IDENT:jonhsu@leo-home.hq.tensilica.com [192.168.10.103]) by mail-in.hq.tensilica.com (8.9.3/8.9.3) with ESMTP id NAA11661 for ; Fri, 9 Feb 2001 13:29:22 -0800 Message-ID: <3A8460FB.F2B9B0E6@tensilica.com> Date: Fri, 09 Feb 2001 13:28:27 -0800 From: John Hsu X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.16-3 i686) X-Accept-Language: en MIME-Version: 1.0 To: pro64-support@oss.sgi.com Subject: debugging problem Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-pro64-support@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;pro64-support-outgoing The following test case fails, I think because the front end tries to emit debug information for a structure that isn't defined within the file. > sgicc test.c -ansi -g -S Signal: Segmentation fault in Writing WHIRL file phase. Error: Signal Segmentation fault in phase Writing WHIRL file -- processing aborted sgicc ERROR: /usr/lib/gcc-lib/ia64-sgi-linux/sgicc-1.0/gfec died due to signal 4 sgicc ERROR: core dumped test.c: ----- int net_sysctl(p) struct proc *p; { return (42 ); } From owner-pro64-support@oss.sgi.com Sun Feb 11 15:38:16 2001 Received: by oss.sgi.com id ; Sun, 11 Feb 2001 15:38:06 -0800 Received: from pneumatic-tube.sgi.com ([204.94.214.22]:14119 "EHLO pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP id ; Sun, 11 Feb 2001 15:37:48 -0800 Received: from relay1.corp.sgi.com (spindle.corp.sgi.com [198.29.75.13]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id PAA00973 for ; Sun, 11 Feb 2001 15:47:07 -0800 (PST) mail_from (waynev@sgi.com) Received: from ted (sshgate.corp.sgi.com [169.238.216.146]) by relay1.corp.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) via SMTP id PAA80511 for ; Sun, 11 Feb 2001 15:37:17 -0800 (PST) From: "Wayne Vieira" To: Subject: Problems with -Ofast Date: Sun, 11 Feb 2001 15:47:03 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <200102082259.OAA03243@k2.llnl.gov> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-pro64-support@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;pro64-support-outgoing I don't understand how to use the -Ofast optimization level with sgif90. Given a simple program to compile and load, if I use -Ofast on the compile but not on the load, then I get: [wv@t44 temp]$ sgif90 -Ofast main.f -c [wv@t44 temp]$ sgif90 main.o main.o: could not read symbols: Bad value collect2: ld returned 1 exit status If I use -Ofast on both compile and load, then: [wv@t44 temp]$ sgif90 -Ofast main.f -c [wv@t44 temp]$ sgif90 -Ofast main.o /usr/lib/gcc-lib/ia64-cygnus-linux/2.96-ia64-000717/../../..//libfortran.a(o pen.o):../../libf/fio/open.c:905: the use of `tempnam' is dangerous, better use `mkstemp' /usr/lib/libc_nonshared.a: could not read symbols: Bad value sgif90 INTERNAL ERROR: /usr/lib/gcc-lib/ia64-sgi-linux/sgicc-1.0/ipa_link returned non-zero status 1 So, I just pushed the problem off to mixed optimization levels between my code and the libraries. Is there some other option that is supposed to be used along with -Ofast to get things to load? I haven't been able to find anything in the man pages, but I may just be looking the wrong place. Thanks, Wayne ** Wayne Vieira, Systems Engineer, Linux/IRIX, RHCE ** SGI Federal http://www.sgi.com/linux ** e-mail: waynev@sgi.com From owner-pro64-support@oss.sgi.com Sun Feb 11 15:55:16 2001 Received: by oss.sgi.com id ; Sun, 11 Feb 2001 15:55:06 -0800 Received: from pneumatic-tube.sgi.com ([204.94.214.22]:58663 "EHLO pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP id ; Sun, 11 Feb 2001 15:54:40 -0800 Received: from rohi.engr.sgi.com (rohi.engr.sgi.com [130.62.180.74]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id QAA05244 for ; Sun, 11 Feb 2001 16:03:59 -0800 (PST) mail_from (mpm@rohi.engr.sgi.com) Received: (from mpm@localhost) by rohi.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) id PAA06864; Sun, 11 Feb 2001 15:53:05 -0800 (PST) Date: Sun, 11 Feb 2001 15:53:05 -0800 (PST) From: mpm@rohi.engr.sgi.com (Michael Murphy) Message-Id: <200102112353.PAA06864@rohi.engr.sgi.com> To: , "Wayne Vieira" Subject: Re: Problems with -Ofast Sender: owner-pro64-support@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;pro64-support-outgoing -Ofast is not supported yet. It uses ipa, which has not been released yet (but will be soon). Use -O3 for now. -- Mike Murphy -- mpm@sgi.com -- quote of the day: -- "God, grant me the serenity to accept the things I cannot change, -- the courage to change the things I can, -- and the wisdom to know the difference." From owner-pro64-support@oss.sgi.com Sun Feb 11 22:11:01 2001 Received: by oss.sgi.com id ; Sun, 11 Feb 2001 22:10:42 -0800 Received: from pneumatic-tube.sgi.com ([204.94.214.22]:24882 "EHLO pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP id ; Sun, 11 Feb 2001 22:10:18 -0800 Received: from cchkms.engr.sgi.com (cchkms.engr.sgi.com [130.62.180.48]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id WAA00499 for ; Sun, 11 Feb 2001 22:19:37 -0800 (PST) mail_from (rat@cchkms.engr.sgi.com) Received: (from rat@localhost) by cchkms.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) id VAA06579; Sun, 11 Feb 2001 21:34:37 -0800 (PST) Date: Sun, 11 Feb 2001 21:34:37 -0800 (PST) From: rat@cchkms.engr.sgi.com (Ross A. Towle) Message-Id: <200102120534.VAA06579@cchkms.engr.sgi.com> To: , "Wayne Vieira" Subject: Re: Problems with -Ofast Sender: owner-pro64-support@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;pro64-support-outgoing -Ofast turns on IPA. IPA requires the use of a modified linker which is called ipa_link. This has not been part of the Pro64 releases. We have been trying for over 9 months to get the changes included in the GNU linker. Due to the lack of success we will be including the sources for ipa_link with the upcoming release 0.13 of Pro64. In the meantime, compile at -O3. =Ross From owner-pro64-support@oss.sgi.com Mon Feb 12 02:21:02 2001 Received: by oss.sgi.com id ; Mon, 12 Feb 2001 02:20:52 -0800 Received: from ns.suse.de ([213.95.15.193]:61707 "HELO Cantor.suse.de") by oss.sgi.com with SMTP id ; Mon, 12 Feb 2001 02:20:31 -0800 Received: from Hermes.suse.de (Hermes.suse.de [213.95.15.136]) by Cantor.suse.de (Postfix) with ESMTP id 93E2D1E0AC; Mon, 12 Feb 2001 11:20:29 +0100 (MET) Date: Mon, 12 Feb 2001 11:19:45 +0100 From: Andi Kleen To: "Ross A. Towle" Cc: pro64-support@oss.sgi.com, Wayne Vieira Subject: Re: Problems with -Ofast Message-ID: <20010212111945.B21435@gruyere.muc.suse.de> References: <200102120534.VAA06579@cchkms.engr.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200102120534.VAA06579@cchkms.engr.sgi.com>; from rat@cchkms.engr.sgi.com on Sun, Feb 11, 2001 at 09:34:37PM -0800 Sender: owner-pro64-support@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;pro64-support-outgoing On Sun, Feb 11, 2001 at 09:34:37PM -0800, Ross A. Towle wrote: > -Ofast turns on IPA. IPA requires the use of a modified linker > which is called ipa_link. This has not been part of the Pro64 > releases. We have been trying for over 9 months to get the changes > included in the GNU linker. Due to the lack of success we will > be including the sources for ipa_link with the upcoming release > 0.13 of Pro64. I'm curious: what were the main problems in porting to BFD/GNU ld? -Andi From owner-pro64-support@oss.sgi.com Mon Feb 12 08:19:45 2001 Received: by oss.sgi.com id ; Mon, 12 Feb 2001 08:19:35 -0800 Received: from beta.dmz-eu.st.com ([164.129.1.35]:12935 "HELO beta.dmz-eu.st.com") by oss.sgi.com with SMTP id ; Mon, 12 Feb 2001 08:19:22 -0800 Received: from zeta.dmz-eu.st.com (zeta.dmz-eu.st.com [164.129.230.9]) by beta.dmz-eu.st.com (STMicroelectronics) with SMTP id 445B14996 for ; Mon, 12 Feb 2001 16:19:09 +0000 (GMT) Received: by zeta.dmz-eu.st.com (STMicroelectronics, from userid 0) id 746D54AE4; Mon, 12 Feb 2001 16:16:32 +0000 (GMT) Received: from eux100.sgp.st.com (localhost [127.0.0.1]) by zeta.dmz-eu.st.com (STMicroelectronics) with ESMTP id 35E661849 for ; Mon, 12 Feb 2001 16:16:32 +0000 (GMT) Received: from st.com (lod30.gnb.st.com [164.129.117.127]) by eux100.sgp.st.com (8.8.6 (PHNE_17190)/8.8.6) with ESMTP id RAA25141; Mon, 12 Feb 2001 17:16:27 +0100 (MET) Message-ID: <3A880C5B.E9FEEE6B@st.com> Date: Mon, 12 Feb 2001 17:16:27 +0100 From: Arthur Stoutchinin Reply-To: Arthur.Stoutchinin@st.com Organization: STMicroelectronics X-Mailer: Mozilla 4.7 [en] (X11; I; SunOS 5.5.1 sun4u) X-Accept-Language: ru, en MIME-Version: 1.0 To: pro64-support@oss.sgi.com, Arthur.Stoutchinin@st.com Subject: ia64.md Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-pro64-support@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;pro64-support-outgoing Good day, We're trying to retarget the Pro64 for another processor than IA64. We noticed that the WHIRL tree is built in parallel to the rtl representation of GCC. We do not really need the rtl but in order to build the compiler one needs to provide the gnu/config/TARG/TARG.md file based on which some rtl structures are generated. Question: what are the informations in the gnu/config/ia64/ia64.md usefull for the Pro64 WHIRL generation (if any). Would it create a problem if we used the ia64.md in hope that the rtl is entirely dummy here ? thank you, Arthur Stoutchinin From owner-pro64-support@oss.sgi.com Mon Feb 12 10:34:26 2001 Received: by oss.sgi.com id ; Mon, 12 Feb 2001 10:34:06 -0800 Received: from pneumatic-tube.sgi.com ([204.94.214.22]:109 "EHLO pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP id ; Mon, 12 Feb 2001 10:33:58 -0800 Received: from cchkms.engr.sgi.com (cchkms.engr.sgi.com [130.62.180.48]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id KAA00482 for ; Mon, 12 Feb 2001 10:43:18 -0800 (PST) mail_from (rat@cchkms.engr.sgi.com) Received: (from rat@localhost) by cchkms.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) id JAA07943; Mon, 12 Feb 2001 09:56:32 -0800 (PST) From: "Ross A. Towle" Message-Id: <10102120956.ZM7957@cchkms.engr.sgi.com> Date: Mon, 12 Feb 2001 09:56:31 -0800 In-Reply-To: Andi Kleen "Re: Problems with -Ofast" (Feb 12, 11:19am) References: <200102120534.VAA06579@cchkms.engr.sgi.com> <20010212111945.B21435@gruyere.muc.suse.de> X-Mailer: Z-Mail (3.2.3 08feb96 MediaMail) To: Andi Kleen Subject: Re: Problems with -Ofast Cc: pro64-support@oss.sgi.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-pro64-support@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;pro64-support-outgoing The development of ipa-link as a modification to gnu ld is very easy. There are are small number of changes. There were no engineering problems. Just getting the changes into the GNU source tree is the sticking point. -Ross From owner-pro64-support@oss.sgi.com Mon Feb 12 10:44:56 2001 Received: by oss.sgi.com id ; Mon, 12 Feb 2001 10:44:37 -0800 Received: from [208.155.65.221] ([208.155.65.221]:14867 "EHLO www.cgsoftware.com") by oss.sgi.com with ESMTP id ; Mon, 12 Feb 2001 10:44:10 -0800 Received: from localhost (dan@localhost) by www.cgsoftware.com (8.11.1/8.11.1) with ESMTP id f1CIhK329165; Mon, 12 Feb 2001 13:43:31 -0500 X-Authentication-Warning: www.cgsoftware.com: dan owned process doing -bs Date: Mon, 12 Feb 2001 13:43:20 -0500 (EST) From: Daniel Berlin X-X-Sender: To: "Ross A. Towle" cc: Andi Kleen , Subject: Re: Problems with -Ofast In-Reply-To: <10102120956.ZM7957@cchkms.engr.sgi.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-pro64-support@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;pro64-support-outgoing On Mon, 12 Feb 2001, Ross A. Towle wrote: > The development of ipa-link as a modification to gnu ld is very > easy. There are are small number of changes. There were no > engineering problems. Just getting the changes into the GNU > source tree is the sticking point. Well, I searched the binutils mailing list for "ipa", "ipa-link", "ipa_link", and got no hits. Did you ever actually submit the changes to the binutils mailing list? > > -Ross > From owner-pro64-support@oss.sgi.com Mon Feb 12 12:14:17 2001 Received: by oss.sgi.com id ; Mon, 12 Feb 2001 12:14:07 -0800 Received: from sgi.SGI.COM ([192.48.153.1]:24878 "EHLO sgi.com") by oss.sgi.com with ESMTP id ; Mon, 12 Feb 2001 12:13:46 -0800 Received: from harpoon.engr.sgi.com ([130.62.37.31]) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id MAA07785 for ; Mon, 12 Feb 2001 12:13:45 -0800 (PST) mail_from (jkingdon@cthulhu.engr.sgi.com) Received: from engr.sgi.com (kingdon.engr.sgi.com [130.62.180.80]) by harpoon.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) via ESMTP id MAA68352; Mon, 12 Feb 2001 12:12:09 -0800 (PST) Message-ID: <3A884384.3FAFF9ED@engr.sgi.com> Date: Mon, 12 Feb 2001 12:11:48 -0800 From: James Kingdon X-Mailer: Mozilla 4.7C-SGI [en] (X11; I; IRIX 6.5 IP32) X-Accept-Language: en MIME-Version: 1.0 To: Arthur.Stoutchinin@st.com CC: pro64-support@oss.sgi.com Subject: Re: ia64.md References: <3A880C5B.E9FEEE6B@st.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-pro64-support@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;pro64-support-outgoing Arthur Stoutchinin wrote: > Question: what are the informations in the gnu/config/ia64/ia64.md > useful > for the Pro64 WHIRL generation (if any). Would it create a problem if we > used the ia64.md in hope that the rtl is entirely dummy here ? As far as I know it is entirely dummy (along with the whole GCC backend which is linked into gfecc and gfec). I suspect this was done as a way of minimizing the number of changes that we needed to make to toplev.c (the ones in #ifdef SGI_MONGOOSE). From owner-pro64-support@oss.sgi.com Mon Feb 12 12:29:17 2001 Received: by oss.sgi.com id ; Mon, 12 Feb 2001 12:28:57 -0800 Received: from pneumatic-tube.sgi.com ([204.94.214.22]:58116 "EHLO pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP id ; Mon, 12 Feb 2001 12:28:52 -0800 Received: from rohi.engr.sgi.com (rohi.engr.sgi.com [130.62.180.74]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id MAA09193 for ; Mon, 12 Feb 2001 12:38:11 -0800 (PST) mail_from (mpm@rohi.engr.sgi.com) Received: (from mpm@localhost) by rohi.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) id MAA10956; Mon, 12 Feb 2001 12:26:46 -0800 (PST) Date: Mon, 12 Feb 2001 12:26:46 -0800 (PST) From: mpm@rohi.engr.sgi.com (Michael Murphy) Message-Id: <200102122026.MAA10956@rohi.engr.sgi.com> To: pro64-support@oss.sgi.com, Arthur.Stoutchinin@st.com Subject: Re: ia64.md Sender: owner-pro64-support@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;pro64-support-outgoing From: Arthur Stoutchinin Good day, We're trying to retarget the Pro64 for another processor than IA64. We noticed that the WHIRL tree is built in parallel to the rtl representation of GCC. We do not really need the rtl but in order to build the compiler one needs to provide the gnu/config/TARG/TARG.md file based on which some rtl structures are generated. Question: what are the informations in the gnu/config/ia64/ia64.md usefull for the Pro64 WHIRL generation (if any). Would it create a problem if we used the ia64.md in hope that the rtl is entirely dummy here ? thank you, Arthur Stoutchinin In general, this is just dummy code that is created as part of the gcc processing, but we do our translation from the parse trees, not the rtl. So I think you could use the ia64 rtl definition (but I haven't tried doing such a thing, so there might be problems). There are other people on this list doing what you want to do, so they should know what is involved. The one place where it might be important to have your own rtl is if you wanted to support asm statements for your processor. -- Mike Murphy -- mpm@sgi.com -- quote of the day: -- "Nearly all men can stand adversity, but if you want to test a -- man's character, give him power." (Abraham Lincoln) From owner-pro64-support@oss.sgi.com Thu Feb 15 20:26:45 2001 Received: by oss.sgi.com id ; Thu, 15 Feb 2001 20:26:35 -0800 Received: from kankou.cs.uec.ac.jp ([130.153.200.1]:25615 "EHLO kankou.cs.uec.ac.jp") by oss.sgi.com with ESMTP id ; Thu, 15 Feb 2001 20:26:08 -0800 Received: from ikura.watalab.cs.uec.ac.jp (xlpark@ikura.cs.uec.ac.jp [130.153.200.42]) by kankou.cs.uec.ac.jp (8.9.3/3.7W-00071121) with ESMTP id NAA03333 for ; Fri, 16 Feb 2001 13:26:01 +0900 (JST) Date: Fri, 16 Feb 2001 13:25:42 +0900 Message-ID: From: Xiaolin Park To: pro64-support@oss.sgi.com Subject: Symbol Table Interfaces User-Agent: Wanderlust/2.4.0 (Rio) EMY/1.13.9 (Art is long, life is short) FLIM/1.14.2 (Yagi-Nishiguchi) APEL/10.3 Emacs/20.7 (i386-debian-linux-gnu) MULE/4.1 (AOI) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Sender: owner-pro64-support@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;pro64-support-outgoing Hi, everyone: In symtab.pdf, there is a symbol table interfaces section 2.20 Symbol Table Interfaces The symbol table interfaces are described in a separate document. An online version can be found in http://sahara.mti.sgi.com/Projects/Symtab/porting.html But this website is down. So, Could anyone tell where can I find the Symbol Table Interfaces documents? From owner-pro64-support@oss.sgi.com Fri Feb 16 11:57:30 2001 Received: by oss.sgi.com id ; Fri, 16 Feb 2001 11:57:21 -0800 Received: from deliverator.sgi.com ([204.94.214.10]:1562 "EHLO deliverator.sgi.com") by oss.sgi.com with ESMTP id ; Fri, 16 Feb 2001 11:56:59 -0800 Received: from harpoon.engr.sgi.com (harpoon.engr.sgi.com [130.62.41.49]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id LAA26032 for ; Fri, 16 Feb 2001 11:55:55 -0800 (PST) mail_from (jkingdon@cthulhu.engr.sgi.com) Received: from engr.sgi.com (kingdon.engr.sgi.com [130.62.180.80]) by harpoon.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) via ESMTP id LAA97002; Fri, 16 Feb 2001 11:55:20 -0800 (PST) Message-ID: <3A8D8591.DBA7D815@engr.sgi.com> Date: Fri, 16 Feb 2001 11:54:57 -0800 From: Jim Kingdon X-Mailer: Mozilla 4.7C-SGI [en] (X11; I; IRIX 6.5 IP32) X-Accept-Language: en MIME-Version: 1.0 To: Xiaolin Park CC: pro64-support@oss.sgi.com Subject: Re: Symbol Table Interfaces References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-pro64-support@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;pro64-support-outgoing Xiaolin Park wrote: > http://sahara.mti.sgi.com/Projects/Symtab/porting.html > But this website is down. > So, Could anyone tell where can I find the Symbol Table Interfaces documents? Hmm, I've included some excerpts at the end of this message. I've omitted the parts which are about the difference between the 7.2 and 7.3 compilers on the theory that they would just be confusing. You probably want to use this as a starting point and treat the source code (for example, the .h files mentioned below) as the authoritative source. I don't really know how up to date porting.html is. The last edit is shown as 1997. --------- begin excerpts from porting.html Scope Array Section 2.2 of the symtab spec. describes the concept of the Scope array, which replaces the SYMTAB entries. For all phases except IPA and the inliner, a single global Scope array Scope_tab is defined. Through Scope_tab all symbol table information visible to a PU can be obtained. There are two predefined indices to Scope_tab: GLOBAL_SYMTAB for the global symbol table and CURRENT_SYMTAB for the local symbol table. Here are some examples: // check if an ST_IDX refers to the global symtab if (ST_IDX_level (WN_st_idx (wn)) == GLOBAL_SYMTAB) ... // in a nested PU, check if an ST_IDX refers to a local // variable in the parent PU ST_IDX st_idx = WN_st_idx (wn); if (st_idx != GLOBAL_SYMTAB && st_idx < CURRENT_SYMTAB) { ... } Accessing The Symbol Tables The following table describes how each symbol table structure can be referenced: Class Name Index Type Table Name Entry Access Access Cost ST ST_IDX St_Table ST_IDX idx; ST& st = St_Table[idx]; high PU PU_IDX Pu_Table PU_IDX idx; PU& pu = Pu_Table[idx]; low TY TY_IDX Ty_Table TY_IDX idx; TY& ty = Ty_Table[idx]; ~low FLD FLD_IDX Fld_Table FLD_IDX idx; FLD& fld = Fld_Table[idx]; low ARB ARB_IDX Arb_Table ARB_IDX idx; ARB& arb = Arb_Table[idx]; low TYLIST TYLIST_IDX Tylist_Table TYLIST_IDX idx; TYLIST& tylist = Tylist_Table[idx]; low TCON TCON_IDX Tcon_Table TCON_IDX idx; TCON& tcon = Tcon_Table[idx]; low INITO INITO_IDX Inito_Table INITO_IDX idx; INITO& inito = Inito_Table[idx]; high INITV INITV_IDX Initv_Table INITV_IDX idx; INITV& initv = Initv_Table[idx]; low LABEL LABEL_IDX Label_Table LABEL_IDX idx; LABEL& label = Label_Table[idx]; medium PREG PREG_IDX Preg_Table PREG_IDX idx; PREG& preg = Preg_Table[idx]; medium STR_IDX Str_Table STR_IDX idx; char *str = &Str_Table[idx]; very low The XX_IDX should always be used to identify an entry of a table, especially when being passed as parameter. On the other hand, it is safe to store away the address of an entry for faster access to multiple fields within it. For example: void foo (TY_IDX ty_idx) { const TY& ty = Ty_Table[ty_idx]; if (TY_kind(ty) == KIND_STRUCT && TY_is_union (ty) && TY_no_ansi_alias(ty)) { ... } } The only exception is ST. Due to the high cost to access an ST entry via the ST_IDX, it has been accepted as a convention that ST entries are identified by "ST*" and this is the preferred way to pass an ST entry as function parameter. The ST_IDX of an ST entry is stored in the entry itself and can be accessed via the ST_st_idx() function. For example: // check if the given ST entry is based on another block // pass in ST* instead of ST_IDX inline BOOL Has_Base_Block (const ST* s) { // check if the base index is the same as itself return ST_base_idx (s) != ST_st_idx (s); } Note that the Whirl nodes now hold an ST_IDX instead of ST*, and the access functions have been redefined as follow: #define WN_st_idx(x) ((x)->u1u2.uu.ub.st) inline ST* WN_st (const WN *wn) { return &St_Table[WN_st_idx (wn)]; } Typical uses: if (ST_sclass (WN_st (wn)) == SCLASS_AUTO) ... WN_st_idx (wn) = ST_st_idx (st); In other cases where you need to convert an ST_IDX to ST*, you can use &St_Table[st_idx]. Access Functions for Data Members For each symbol table class, a set of access functions is derived from the data member. In general: XX_yyy(const XX& xx) returns the value of data member yyy of class XX, specified by xx. Set_XX_yyy (XX& xx, type_of_yyy val) set the value of yyy to val. Flag names of a class are always upper-case, prefixed by the name of the class. For example, if XX_FLAG1 is a flag of class XX: XX_flag1 (const XX& xx) returns TRUE if XX_FLAG1 is set. Set_XX_flag1 (XX& xx) sets XX_FLAG1 to TRUE. Clear_XX_flag1 (XX& xx) sets XX_FLAG1 to FALSE. Note that the access functions take a reference type (XX&) as parameter, except: For ST's, overloaded versions that takes ST* are also defined. Some of the commonly used access functions for TY also accept TY_IDX as parameter. These functions are more expensive and if multiple fields of a TY are accessed, it is better to convert the TY_IDX to TY& first and use that instead. The access functions are defined in symtab_access.h. Creating a Symbol Table Entry For each class XX, the functions New_XX() and XX_Init() are defined. For example: TY_IDX ty_idx; // New_TY returns an uninitialized TY entry, // and set the index in the reference parameter ty_idx TY& ty = New_TY (ty_idx); // The init routine takes values of most commonly used fields, and // zero out the remaining fields. // Always initialize the entry right after calling New. TY_Init (ty, 4 KIND_SCALAR, MTYPE_I4, Save_Str ("foo")); // Other attributes must be set after calling TY_Init Set_TY_align (ty_idx, 4); // Should always return TY_IDX instead of TY& return ty_idx; Organization of the Symbol Table Headers The following table should give you a rough idea where to look for the functions that you need. File name Description symtab.h This is the only symtab header to be #include'd. It also contains overloaded access functions and other trivial inlined utility functions. symtab_defs.h Class definitions of ST, FLD, ARB, LABEL, PREG, TY, PU, BLK, SCOPE, and FILE_INFO. Declarations of all the Xx_Table's. symtab_idx.h Definitions of all XX_IDX's. symtab_access.h Definitions of all access functions that are mechanically derived from the classes. symtab_utils.h Declarations of non-trivial utility functions. symtab_verify.h Declarations of symbol table verifier functions. symtab_compatible.h Definitions of inlined functions for compatibility with old symbol table. These functions are defined only to make the transition to new symbol format easier, and they will be removed after the transition period. irbdata_defs.h Class definitions of INITO and INITV. irbdata.h Access functions and utilities functions for INITO and INITV. strtab.h String table utilities. Iterators For each class XX, a forward iterator XX_ITER is defined. You can create an iterator pointing to a specified entry using the Make_xx_iter function. For example: FLD_IDX fld_idx = TY_fld (ty); // Create an iterator pointing to the entry given by fld_idx FLD_ITER fld_iter = Make_fld_iter (fld_idx); do { // operator* dereference the iterator FLD& fld = *fld_iter; ... } while (!FLD_last_field (*fld_iter++)); The pre/post increment operator ++ increment the iterator to the next entry. You can also compare iterators using the == and != operators. The total number of entries in a table can be obtained by the XX_Table_Size function. Fast Iteration Through All Entries The above iterator is good for iterating a small number of entries. If you need to go through the entire table, you should use the more efficient iterator function For_all. For example, suppose we want to go through all the PUs and clear the PU_NO_SIDE_EFFECTS bit: // Function object that defines the operation struct clear_no_se { // First argument is the array index of the current entry, ignored in this case // Second argument is the pointer to the current entry void operator() (UINT32, const PU* pu) const { Clear_PU_no_side_effects (*pu); } }; void Clear_all_pu_side_effect () { // Pass in an anonymous function object For_all (Pu_Table, clear_no_se()); } You can replace the function object by a function pointer, but the function object is much more efficient because it is a direct function call instead of an indirect call via a function pointer. Note that these functions always iterate from the 2nd entry of the table till the last one. The first entry of each table, by definition, is reserved and zero'ed. Fast iteration with early exit If you want to exit from the loop before reaching the end, you can use the For_all_until function. Just define the function object to return TRUE when the termination condition is satisfied. If the termination condition is never satisfied, it will return 0: struct find_ty_by_name { const char* name; find_ty_by_name (const char* str) : name (str) {} // return TRUE when the name strings match BOOL operator() (UINT32, const TY* ty) const { return strcmp (TY_name (*ty), name) == 0; } }; TY_IDX Find_ty (const char* name) { TY_IDX idx = For_all_until (Ty_Table, find_ty_by_name (name)); // If entry is not found, idx will be 0 return idx; } Symbol Table Verifier We have implemented a symbol table verifier that examines every field in each symbol table data structure against the specification. It is called at the end of each compiler phase. Additionally, the following interfaces are provided so you can invoke the verifier explicitly. The only assumption is that the symbol table needs to be in a consistent state when you invoke the verifier (i.e., not partially updated). extern void Verify_LOCAL_SYMTAB (const SCOPE&, SYMTAB_IDX); extern void Verify_GLOBAL_SYMTAB (); inline void Verify_SYMTAB (SYMTAB_IDX level) { if (level > GLOBAL_SYMTAB) Verify_LOCAL_SYMTAB (Scope_tab[level], level); else Verify_GLOBAL_SYMTAB (); } To verify the entire symbol table: for (SYMTAB_IDX i = GLOBAL_SYMTAB; i <= CURRENT_SYMTAB; ++i) Verify_SYMTAB (i); From owner-pro64-support@oss.sgi.com Tue Feb 20 10:48:36 2001 Received: by oss.sgi.com id ; Tue, 20 Feb 2001 10:48:26 -0800 Received: from goliath.cnchost.com ([207.155.252.47]:22972 "EHLO goliath.cnchost.com") by oss.sgi.com with ESMTP id ; Tue, 20 Feb 2001 10:48:13 -0800 Received: from adaptivesilicon.com ([216.112.13.250]) by goliath.cnchost.com id NAA29687; Tue, 20 Feb 2001 13:48:10 -0500 (EST) [ConcentricHost SMTP Relay 1.10] Message-ID: <3A92BC02.61F94C3E@adaptivesilicon.com> Date: Tue, 20 Feb 2001 10:48:34 -0800 From: Ernst Mayer X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.14-5.0smp i686) X-Accept-Language: en MIME-Version: 1.0 To: pro64-support@oss.sgi.com CC: "Ernst W. Mayer" Subject: problems with extended-precision floats in sgif90 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-pro64-support@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;pro64-support-outgoing Dear SGI compile folks: I wrote and maintain the major RISC/Unix client, Mlucas, for the Great Internet Mersenne Prime Search. Mlucas is a much-improved version of lucas, an early prototype version of the code which is now part of the SPEC2000FP suite. While Mlucas is much bigger and better than lucas, it was designed (based on my experience with SPEC2000) to be similarly portable. I've successfully compiled it on all the major RISC platforms that have a decent f90 compiler: Alpha (TruUnix and various flavors of Linux), MIPS/Irix, Sparc and IBM Power1,2,3/AIX. I recently tried it out on a Linux Itanium system avaialable via the compaq TestDrive program. Here are the platform specifics: spe190.testdrive.compaq.com> uname -a Linux spe190.testdrive.compaq.com 2.4.0-test9 #25 SMP Fri Oct 20 09:14:53 PDT 2000 ia64 unknown spe190.testdrive.compaq.com> sgif90 -version SGIcc Compilers: Version 0.01.0-12 The source code I was compiling is described and linked at ftp://209.133.33.182/pub/mayer/README2.html The code basically performs a bunch of large-integer multiplies using an efficient FFT implementation I wrote. For Mersenne testing, high accuracy is very important, so one of the tricks the code uses to try to minimize roundoff error is to query the compiler on the platform where it is built for an extended-precision floating-point data type (via the f90 selected_real_kind function), and to do initializations of small FFT sincos data tables using the highest-precision supported floating data type. All subsequent computations are done in strictly 64-bit real. I do the high-prec. inits simply as integer, parameter :: r8 =selected_real_kind(15,30) !* This gives the default 8-byte floating data type. integer, parameter :: r16=max(r8,selected_real_kind(18,50)) !* If r16 >= 0, an extended-precision (i.e. > 8-byte) float is available. i.e. if an ext.-prec. floating type is not available, everything reverts to real*8. The above is from the Mdata.f90 module of the source code - simply attempting to compile this small module will show you what error messages were generated. Here is the complete module: !******************** ! !...Module for stashing global parameters used by various Mlucas routines. ! MODULE Mdata implicit none integer, parameter :: r8 =selected_real_kind(15,30) !* This gives the default 8-byte floating data type. integer, parameter :: r16=max(r8,selected_real_kind(18,50)) !* If r16 >= 0, an extended-precision (i.e. > 8-byte) float is available. !...Quasi-generic cache-and-bank-conflict-avoiding array padding parameters are here. These MUST be a power of two to be ! compatible with the simple padded-index calculation scheme we use. ! Unctuous TV announcer: "Are you suffering from cache flow problems? Bank foreclosures? Then try my new array padding!" integer, parameter :: dat_bits = 10 !* Number of 8-byte array data in each contiguous-data block = 2^dat_bits. !* This should be chosen so a complete data block, along with a roughly equal !* number of FFT sincos or DWT weights data, fits in the L1 cache. 512 8-byte !* floats seems a good choice for an 8KB L1 cache. !* NOTES: - the blocklength must divide the (unpadded) vector length. !* - dat_bits must be at least 5 to be compatible with radix16_wrapper_square. !* - dat_bits must be at least 6 to be compatible with radix32_wrapper_square. !* - dat_bits must be at least 7 to be compatible with radix64_wrapper_square. integer, parameter :: pad_bits = 1 !* Number of 8-byte padding slots in each contiguous-data block = 2^pad_bits. real*8 , parameter :: rnd_const = .75d0*2d0**53 !* Constant used to effect speedy NINT(x) = (x+rnd_const)-rnd_const. !* General form is .75*2^{number of mantissa bits in FP representation}, !* e.g. on the x86 family with its 80-bit register float we'd use .75*2d0**64. !* For this NINT to work, must prevent overaggressive compiler optimizations !* which eliminate sequences like (x+y)-y, e.g. under DEC Unix !* we specify <-assume accuracy_sensitive>. !...Parameters used frequently in the complex floating-point transform... real(kind=r16), parameter :: one=1,two=2,twopi=6.28318530717958647692528676655900559_r16 real*8, parameter :: isrt2=0.7071067811865476_r8 !* 1/sqrt(2) real*8, save :: one_half(0:2)=(/1d0,.5d0,.25d0/) !* Needed for small-weights-tables scheme end MODULE Mdata Anyway, the above should compile OK even if there is only real*8 support, but sgif90 doesn't agree. Interestingly, when I modified the code so it only defined r16 (but didn't use it in a (kind=) statement or as an _r16 literal extension), it generated a value of 16, which should mean that such a data type is available, but apparently it isn't. So that's probably a simple compiler bug for you to look into. An additional question: when will the sgif90 compiler support extended-precision floats? And, will it support both the x86 real*10 type and an emulated real*16 type? It would be nice to have both available, since there is actual hardware support for real*10, hence such operations should run only about 2x as slow as real*8 (the factor of 2 comes from the load/store penalty for moving 80-bit-wide operands between floating registers and memory). If people actually need even more precision, they could then resort to real*16, but of course that typically involves a 10x performance penalty, and for many applications (e.g. the aforementioned high-precision floating data tables inits), simply having a few bits or bytes more than real*8 is sufficient. -Ernst Mayer p.s.: Before writing this I looked for the Pro64 support mail archive mentioned on your website, but found no link to it - only a way to subscribe to the mailing list. Would subscribing allow me to access the list archive? From owner-pro64-support@oss.sgi.com Tue Feb 20 11:53:36 2001 Received: by oss.sgi.com id ; Tue, 20 Feb 2001 11:53:27 -0800 Received: (from localhost user: 'qarce', uid#10141) by oss.sgi.com with ESMTP id ; Tue, 20 Feb 2001 11:53:12 -0800 Date: Tue, 20 Feb 2001 11:53:12 -0800 (PST) From: Quentin Arce To: Pro64-support Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-pro64-support@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;pro64-support-outgoing Runnining another check -------------------- Quentin Arce qarce@engr.sgi.com Linux Scalability Pager:(925) 472-2007 Admin. oss.sgi.com Office:(650) 933-3771 From owner-pro64-support@oss.sgi.com Wed Feb 21 09:52:16 2001 Received: by oss.sgi.com id ; Wed, 21 Feb 2001 09:52:06 -0800 Received: from roura.ac.upc.es ([147.83.33.10]:19449 "EHLO roura.ac.upc.es") by oss.sgi.com with ESMTP id ; Wed, 21 Feb 2001 09:51:50 -0800 Received: from ac.upc.es (pons.ac.upc.es [147.83.32.9]) by roura.ac.upc.es (8.11.0/8.11.0) with ESMTP id f1LHpOa02049 for ; Wed, 21 Feb 2001 18:51:24 +0100 (MET) Message-ID: <3A94001C.E693D8BB@ac.upc.es> Date: Wed, 21 Feb 2001 18:51:24 +0100 From: Eduard Santamaria Organization: DAC-UPC X-Mailer: Mozilla 4.7 [en] (X11; U; OSF1 V4.0 alpha) X-Accept-Language: en MIME-Version: 1.0 To: pro64-support@oss.sgi.com Subject: bus error when running gfec and gfecc Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-pro64-support@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;pro64-support-outgoing Hi, As a first step to port the Pro64 to an IRIX/MIPS platform I'm trying to build the Pro64 on that platform. I've already compiled and executed the driver and the preprocessor, but a problem arises when it comes to the c and C++ front-ends. None of them executes properly and the operating system yields a bus error. I've tried to do some debugging finding that the error arises at the execv call (when the driver tries to load and execute the front-end image), so I think it might be the loader who causes the error (perhaps due to defective objects). sources from osprey1.0/gccfe/gnu have been compiled with gcc (gcc version 2.8.1). sources from osprey1.0/gccfe have been compiled with SGI cc and CC (MIPSpro Compilers: Version 7.30). Could linking together objects from both compilers lead to bus error problem? It seems not easy to compile all the sources with a single compiler. I've discarded doing so with the SGI compiler because a huge amount of errors appear. When trying the GNU compiler I find this "`operator new' takes type `size_t' as first parameter" error which I don't know how to deal with. uname -a IRIX64 karnak 6.5 04191312 IP27 Does anyone have any idea of the possible cause and solution to this problem? Another question: I'm not quite sure of the meaning of the BUILD_TARGET variable defined at every Makefile file. Does it refer to the platform where the Pro64 is to be executed or the platform for which the Pro64 is going to generate code? If it's the former I'm afraid I lack some files, am I wrong? Best regards, Eduard. ________________________________________________________________________ o o o Eduard Santamaria Barnadas o o o Department of Computer Architecture o o o Universitat Politecnica de Catalunya Phone: +34 93 401 1649 C/ Jordi Girona, 1-3 Campus Nord, Modul C6 - S103 U P C 08034 - BARCELONA (SPAIN) mailto:esantama@ac.upc.es ________________________________________________________________________ From owner-pro64-support@oss.sgi.com Wed Feb 21 15:18:38 2001 Received: by oss.sgi.com id ; Wed, 21 Feb 2001 15:18:17 -0800 Received: from deliverator.sgi.com ([204.94.214.10]:42095 "EHLO deliverator.sgi.com") by oss.sgi.com with ESMTP id ; Wed, 21 Feb 2001 15:17:50 -0800 Received: from cchkms.engr.sgi.com (cchkms.engr.sgi.com [130.62.180.48]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id PAA15048 for ; Wed, 21 Feb 2001 15:16:46 -0800 (PST) mail_from (rat@cchkms.engr.sgi.com) Received: (from rat@localhost) by cchkms.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) id PAA16312 for pro64-support@oss.sgi.com; Wed, 21 Feb 2001 15:14:26 -0800 (PST) From: "Ross A. Towle" Message-Id: <10102211514.ZM16317@cchkms.engr.sgi.com> Date: Wed, 21 Feb 2001 15:14:24 -0800 In-Reply-To: Eduard Santamaria "bus error when running gfec and gfecc" (Feb 21, 6:51pm) References: <3A94001C.E693D8BB@ac.upc.es> X-Mailer: Z-Mail (3.2.3 08feb96 MediaMail) To: pro64-support@oss.sgi.com Subject: Re: bus error when running gfec and gfecc Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-pro64-support@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;pro64-support-outgoing Let me answer the 2nd part first. We make a distinction between HOST and TARGET. The BUILD_HOST is used to indicate the ISA (instruction set architecture) of the system where the build is taking place. The BUILD_TARGET is the ISA of the library/ phase/whatever that you are building. Right now the ISA of the compiler phases is IA-32 (which run in IA-32 compatability mode on IA-64) so for them we set BUILD_TARGET=IA32. For the runtime libraries the ISA is IA-64 so we set the BUILD_TARGET=IA64 for them. This will be changing sometime after the Pro64 0.13 release. At that point the compiler phases will have BUILD_TARGET=IA64. Now for the first part. No idea of the cause of your problems. I would suggest that you do "file" on the front end executables to see what it says. Double check to make sure you are using the IRIX ld and ar when building the frondend. Remember you are hosting the compiler on IRIX. -Ross From owner-pro64-support@oss.sgi.com Thu Feb 22 11:52:10 2001 Received: by oss.sgi.com id ; Thu, 22 Feb 2001 11:52:00 -0800 Received: from paco.llnl.gov ([134.9.17.119]:47379 "EHLO paco.llnl.gov") by oss.sgi.com with ESMTP id ; Thu, 22 Feb 2001 11:51:45 -0800 Received: from paco.llnl.gov (IDENT:waynev@localhost [127.0.0.1]) by paco.llnl.gov (SGI-8.9.3/8.9.3) with ESMTP id LAA12329 for ; Thu, 22 Feb 2001 11:51:17 -0800 (PST) Message-ID: <3A956DB5.CC3E90E4@paco.llnl.gov> Date: Thu, 22 Feb 2001 11:51:17 -0800 From: Wayne Vieira Reply-To: waynev@sgi.com Organization: SGI X-Mailer: Mozilla 4.75C-SGI [en] (X11; U; IRIX64 6.5 IP30) X-Accept-Language: en MIME-Version: 1.0 To: pro64-support@oss.sgi.com Subject: Default include directory for sgif90 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-pro64-support@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;pro64-support-outgoing Isn't sgif90 supposed to use /usr/include for searching for includes? I ran the following example test case program test INCLUDE "mpif.h" c USE MPI #This works, as expected INTEGER*8 error CALL MPI_INIT(error) write(6,*)'hello penguins' call MPI_Finalize(error) stop end If I have the full path or -I/usr/include it works without error, but not by default. What are the default search directories for include files? Wayne From owner-pro64-support@oss.sgi.com Thu Feb 22 15:22:53 2001 Received: by oss.sgi.com id ; Thu, 22 Feb 2001 15:22:43 -0800 Received: from deliverator.sgi.com ([204.94.214.10]:12114 "EHLO deliverator.sgi.com") by oss.sgi.com with ESMTP id ; Thu, 22 Feb 2001 15:22:34 -0800 Received: from rohi.engr.sgi.com (rohi.engr.sgi.com [130.62.180.74]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id PAA08444 for ; Thu, 22 Feb 2001 15:21:23 -0800 (PST) mail_from (mpm@rohi.engr.sgi.com) Received: (from mpm@localhost) by rohi.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) id PAA52858; Thu, 22 Feb 2001 15:20:54 -0800 (PST) Date: Thu, 22 Feb 2001 15:20:54 -0800 (PST) From: mpm@rohi.engr.sgi.com (Michael Murphy) Message-Id: <200102222320.PAA52858@rohi.engr.sgi.com> To: pro64-support@oss.sgi.com, "Ross A. Towle" Subject: Re: bus error when running gfec and gfecc References: <3A94001C.E693D8BB@ac.upc.es> Sender: owner-pro64-support@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;pro64-support-outgoing From: "Ross A. Towle" We make a distinction between HOST and TARGET. The BUILD_HOST is used to indicate the ISA (instruction set architecture) of the system where the build is taking place. The BUILD_TARGET is the ISA of the library/ phase/whatever that you are building. Right now the ISA of the compiler phases is IA-32 (which run in IA-32 compatability mode on IA-64) so for them we set BUILD_TARGET=IA32. For the runtime libraries the ISA is IA-64 so we set the BUILD_TARGET=IA64 for them. This will be changing sometime after the Pro64 0.13 release. At that point the compiler phases will have BUILD_TARGET=IA64. Close, but not quite right. The BUILD_TARGET is the target architecture that our compiler will generate code for. So when we build a compiler that will generate IA64 code, we set BUILD_TARGET=IA64, even if it is a cross compiler. It is BUILD_ARCH and BUILD_ABI that specify the host info, so the currently released compiler phases which run in IA-32 compatibility mode are built with: BUILD_ABI = I32BIT BUILD_ARCH = IA32 Look in Makefile.gsetup for a description of these BUILD variables. -- Mike Murphy -- mpm@sgi.com -- quote of the day: -- "Give thanks in all circumstances, for this is God's will" -- (I Thessalonians 5:18, The Bible) From owner-pro64-support@oss.sgi.com Thu Feb 22 16:32:23 2001 Received: by oss.sgi.com id ; Thu, 22 Feb 2001 16:32:12 -0800 Received: from pneumatic-tube.sgi.com ([204.94.214.22]:21304 "EHLO pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP id ; Thu, 22 Feb 2001 16:32:02 -0800 Received: from rohi.engr.sgi.com (rohi.engr.sgi.com [130.62.180.74]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id QAA07907 for ; Thu, 22 Feb 2001 16:40:51 -0800 (PST) mail_from (mpm@rohi.engr.sgi.com) Received: (from mpm@localhost) by rohi.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) id QAA53700; Thu, 22 Feb 2001 16:29:32 -0800 (PST) Date: Thu, 22 Feb 2001 16:29:32 -0800 (PST) From: mpm@rohi.engr.sgi.com (Michael Murphy) Message-Id: <200102230029.QAA53700@rohi.engr.sgi.com> To: "Ross A. Towle" , pro64-support@oss.sgi.com, mpm@rohi.engr.sgi.com (Michael Murphy) Subject: Re: bus error when running gfec and gfecc References: <3A94001C.E693D8BB@ac.upc.es> Sender: owner-pro64-support@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;pro64-support-outgoing After talking to Ross, I think I was also close but not quite exact. There are actually two kinds of "hosts": the build host that we build the compiler on, and the run host that we run the compiler on. Then there is the target, which is what the compiler targets when it is run. BUILD_HOST is for the build host, BUILD_ARCH is for the run host, BUILD_TARGET is for the run target. I'm going to update Makefile.gsetup with a better description of this. -- Mike Murphy -- mpm@sgi.com -- quote of the day: -- "Give thanks in all circumstances, for this is God's will" -- (I Thessalonians 5:18, The Bible) From owner-pro64-support@oss.sgi.com Thu Feb 22 17:45:22 2001 Received: by oss.sgi.com id ; Thu, 22 Feb 2001 17:45:13 -0800 Received: from [38.170.141.29] ([38.170.141.29]:49655 "EHLO heart.hq.tensilica.com") by oss.sgi.com with ESMTP id ; Thu, 22 Feb 2001 17:45:06 -0800 Received: (from goodwin@localhost) by heart.hq.tensilica.com (8.9.3/8.9.3) id RAA07239; Thu, 22 Feb 2001 17:45:06 -0800 X-Authentication-Warning: heart.hq.tensilica.com: goodwin set sender to goodwin@tensilica.com using -f From: David Goodwin MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14997.49313.943861.677839@heart.hq.tensilica.com> Date: Thu, 22 Feb 2001 17:45:05 -0800 (PST) To: pro64-support@oss.sgi.com Subject: unnecessary symbol definitions in C++ X-Mailer: VM 6.75 under Emacs 20.5.1 Reply-to: goodwin@tensilica.com Sender: owner-pro64-support@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;pro64-support-outgoing I've looked at this some, but I'm not having any luck fixing it. sgiCC generates unnecessary definitions of __FUNCTION__ and __PRETTY_FUNCTION__. An example that shows this behavior is attached. WFE_Initialize_Decl claims it ignores unnecessary declarations by checking DECL_IGNORED_P, but that doesn't seem to work. > cat hello.cc #include int main () { printf("Hello World\n"); } > sgiCC -v SGIcc Compilers: Version 0.01.0-12 > sgiCC -O2 hello.cc -S > cat hello.s // /usr/lib/gcc-lib/ia64-sgi-linux/sgicc-1.0/be::0.01.0-12 //----------------------------------------------------------- // Compiling hello.cc (/tmp/ccI.XOud7p) //----------------------------------------------------------- //----------------------------------------------------------- // Options: //----------------------------------------------------------- // Target:Itanium, ISA:ISA_1, Pointer Size:64 // -O2 (Optimization level) // -g0 (Debug level) // -m1 (Report warnings) //----------------------------------------------------------- .section .text, "ax", "progbits" .align 16 .section .rodata, "a", "progbits" .align 8 .section .sbss, "wa", "nobits" .align 1 .section .bss, "wa", "nobits" .align 1 .section .sbss .org 0x0 .align 0 .type __func___82, @object .size __func___82, 1 __func___82: // 0x0 .skip 1 .org 0x1 .align 0 .type __FUNCTION___84, @object .size __FUNCTION___84, 1 __FUNCTION___84: // 0x1 .skip 1 .section .bss .org 0x0 .align 0 .type __PRETTY_FUNCTION___83, @object .size __PRETTY_FUNCTION___83, 10 __PRETTY_FUNCTION___83: // 0x0 .skip 10 .section .text // Program Unit: main .proc main# .global main# main#: // 0x0 .file 1 "/usr/local/home/goodwin/hello.cc" .loc 1 5 0 // 1 #include // 2 // 3 int // 4 main () // 5 { .BB1_main: // 0x0 // ... From owner-pro64-support@oss.sgi.com Thu Feb 22 17:54:42 2001 Received: by oss.sgi.com id ; Thu, 22 Feb 2001 17:54:33 -0800 Received: from sgi.SGI.COM ([192.48.153.1]:51830 "EHLO sgi.com") by oss.sgi.com with ESMTP id ; Thu, 22 Feb 2001 17:54:26 -0800 Received: from gaea.engr.sgi.com ([130.62.180.97]) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id RAA01819 for ; Thu, 22 Feb 2001 17:53:39 -0800 (PST) mail_from (murthy@gaea.engr.sgi.com) Received: (from murthy@localhost) by gaea.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) id RAA84582; Thu, 22 Feb 2001 17:49:56 -0800 (PST) Date: Thu, 22 Feb 2001 17:49:56 -0800 (PST) From: murthy@gaea.engr.sgi.com (Chandrasekhar Murthy) Message-Id: <200102230149.RAA84582@gaea.engr.sgi.com> To: pro64-support@oss.sgi.com, goodwin@tensilica.com Subject: Re: unnecessary symbol definitions in C++ Sender: owner-pro64-support@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;pro64-support-outgoing I will take a look. Murthy From owner-pro64-support@oss.sgi.com Fri Feb 23 11:15:38 2001 Received: by oss.sgi.com id ; Fri, 23 Feb 2001 11:15:28 -0800 Received: from deliverator.sgi.com ([204.94.214.10]:44612 "EHLO deliverator.sgi.com") by oss.sgi.com with ESMTP id ; Fri, 23 Feb 2001 11:15:20 -0800 Received: from harpoon.engr.sgi.com (harpoon.engr.sgi.com [130.62.41.49]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id LAA23351 for ; Fri, 23 Feb 2001 11:14:15 -0800 (PST) mail_from (jkingdon@cthulhu.engr.sgi.com) Received: from engr.sgi.com (kingdon.engr.sgi.com [130.62.180.80]) by harpoon.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) via ESMTP id LAA32921; Fri, 23 Feb 2001 11:14:03 -0800 (PST) Message-ID: <3A96B65E.1744D814@engr.sgi.com> Date: Fri, 23 Feb 2001 11:13:35 -0800 From: Jim Kingdon X-Mailer: Mozilla 4.7C-SGI [en] (X11; I; IRIX 6.5 IP32) X-Accept-Language: en MIME-Version: 1.0 To: pro64-support@oss.sgi.com Subject: IPA changes to ld Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-pro64-support@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;pro64-support-outgoing Due to popular demand, I've submitted the changes to the GNU linker to implement IPA (interprocedural analysis) at: http://sources.redhat.com/ml/binutils/2001-02/msg00553.html This is used by -Ofast for example. To actually make use of IPA will require the next release of Pro64 (which is out Real Soon Now last I heard), but interested parties can take a look right now. There are also opportunities to contribute: let the binutils mailing list know if you would actually use this feature or if you can offer to help work on it that's even better. Hard to say what the binutils maintainers reactions will be (if any) - we haven't gotten a reaction yet but we've only asked a few times. We also expect to release the patched linker at http://oss.sgi.com/projects/Pro64/ and keep doing so until/unless it gets merged into GNU ld. Thanks go to Ross Towle, Jack Carter, and Lilian Leung for helping bring me up to speed on this. From owner-pro64-support@oss.sgi.com Fri Feb 23 12:19:19 2001 Received: by oss.sgi.com id ; Fri, 23 Feb 2001 12:18:59 -0800 Received: from olsen.capsl.udel.edu ([128.4.10.3]:61133 "EHLO olsen.capsl.udel.edu") by oss.sgi.com with ESMTP id ; Fri, 23 Feb 2001 12:18:42 -0800 Received: from hum.capsl.udel.edu (hum.capsl.udel.edu [128.4.10.4]) by olsen.capsl.udel.edu (8.9.1/8.9.1) with ESMTP id PAA18466 for ; Fri, 23 Feb 2001 15:18:19 -0500 (EST) Received: from etinternational.com (localhost [127.0.0.1]) by hum.capsl.udel.edu (8.9.1/8.9.0) with ESMTP id PAA21790 for ; Fri, 23 Feb 2001 15:18:18 -0500 (EST) X-Authentication-Warning: hum.capsl.udel.edu: mmdf owned process doing -bs Message-ID: <3A96C58A.6EF2CF5@etinternational.com> Date: Fri, 23 Feb 2001 15:18:18 -0500 From: Robert Kim Yates Organization: University of Delaware, Newark X-Mailer: Mozilla 4.75 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: pro64-support Subject: F95 for Pro64? Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-pro64-support@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;pro64-support-outgoing Can you give me more information on if/when there will be a F95 front end for the Pro64? -- Robert Yates Chief Technology Officer, ET International (302) 983-3317 http://www.etinternational.com From owner-pro64-support@oss.sgi.com Fri Feb 23 12:56:18 2001 Received: by oss.sgi.com id ; Fri, 23 Feb 2001 12:56:08 -0800 Received: from deliverator.sgi.com ([204.94.214.10]:10866 "EHLO deliverator.sgi.com") by oss.sgi.com with ESMTP id ; Fri, 23 Feb 2001 12:55:48 -0800 Received: from cchkms.engr.sgi.com (cchkms.engr.sgi.com [130.62.180.48]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id MAA15443 for ; Fri, 23 Feb 2001 12:54:43 -0800 (PST) mail_from (rat@cchkms.engr.sgi.com) Received: (from rat@localhost) by cchkms.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) id MAA28717 for pro64-support@oss.sgi.com; Fri, 23 Feb 2001 12:52:24 -0800 (PST) From: "Ross A. Towle" Message-Id: <10102231252.ZM28406@cchkms.engr.sgi.com> Date: Fri, 23 Feb 2001 12:52:22 -0800 In-Reply-To: Robert Kim Yates "F95 for Pro64?" (Feb 23, 3:18pm) References: <3A96C58A.6EF2CF5@etinternational.com> X-Mailer: Z-Mail (3.2.3 08feb96 MediaMail) To: pro64-support Subject: Re: F95 for Pro64? Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-pro64-support@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;pro64-support-outgoing The sgif90 in Pro64 0.12 supports Fortran95. -Ross From owner-pro64-support@oss.sgi.com Fri Feb 23 14:55:20 2001 Received: by oss.sgi.com id ; Fri, 23 Feb 2001 14:55:11 -0800 Received: from scapa.cs.ualberta.ca ([129.128.4.44]:22277 "EHLO scapa.cs.ualberta.ca") by oss.sgi.com with ESMTP id ; Fri, 23 Feb 2001 14:54:53 -0800 Received: (from localhost user: 'pengzhao' uid#483 fake: STDIN (pengzhao@peers)) by scapa.cs.ualberta.ca id ; Fri, 23 Feb 2001 15:54:33 -0700 Date: Fri, 23 Feb 2001 15:54:33 -0700 (MST) From: Peng Zhao To: pro64-support@oss.sgi.com Subject: Assembler messages in cross-compilation of pro64 Message-ID: MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="-2138965737-748718235-982968873=:7809" Sender: owner-pro64-support@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;pro64-support-outgoing This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. Send mail to mime@docserver.cac.washington.edu for more info. ---2138965737-748718235-982968873=:7809 Content-Type: TEXT/PLAIN; charset=US-ASCII HI, When I run gmake in ~/pro64/osprey1.0/targia32_ia64_nodebug/ipa, I ran into some error messages, I need some help. Thank you. Enclosed file is the messages produced by gmake. Thank you very much. Peng ---2138965737-748718235-982968873=:7809 Content-Type: TEXT/PLAIN; charset=US-ASCII; name=nn Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: Content-Disposition: attachment; filename=nn Z21ha2U6IEVudGVyaW5nIGRpcmVjdG9yeSBgL2NvbXBzY2kvYnJ1bGU5L2dy YWQvcGVuZ3poYW8vcHJvNjQvb3NwcmV5MS4wL3RhcmdpYTMyX2lhNjRfbm9k ZWJ1Zy9pcGEnDQpjZCAuLi9iZSAmJiBnbWFrZQ0KZ21ha2VbMV06IEVudGVy aW5nIGRpcmVjdG9yeSBgL2NvbXBzY2kvYnJ1bGU5L2dyYWQvcGVuZ3poYW8v cHJvNjQvb3NwcmV5MS4wL3RhcmdpYTMyX2lhNjRfbm9kZWJ1Zy9iZScNCmNk IC4uL2luY2x1ZGUgJiYgZ21ha2UNCmdtYWtlWzJdOiBFbnRlcmluZyBkaXJl Y3RvcnkgYC9jb21wc2NpL2JydWxlOS9ncmFkL3Blbmd6aGFvL3BybzY0L29z cHJleTEuMC90YXJnaWEzMl9pYTY0X25vZGVidWcvaW5jbHVkZScNCmdtYWtl WzJdOiBMZWF2aW5nIGRpcmVjdG9yeSBgL2NvbXBzY2kvYnJ1bGU5L2dyYWQv cGVuZ3poYW8vcHJvNjQvb3NwcmV5MS4wL3RhcmdpYTMyX2lhNjRfbm9kZWJ1 Zy9pbmNsdWRlJw0KaWYgISB0ZXN0IC1hIGl0YW5pdW0uc287IHRoZW4gbG4g LXNmIC4uL3RhcmdfaW5mby9pdGFuaXVtLnNvIC47IGZpDQpjZCAuLi90YXJn X2luZm8gJiYgZ21ha2UNCmdtYWtlWzJdOiBFbnRlcmluZyBkaXJlY3Rvcnkg YC9jb21wc2NpL2JydWxlOS9ncmFkL3Blbmd6aGFvL3BybzY0L29zcHJleTEu MC90YXJnaWEzMl9pYTY0X25vZGVidWcvdGFyZ19pbmZvJw0KY2QgLi4vaW5j bHVkZSAmJiBnbWFrZQ0KZ21ha2VbM106IEVudGVyaW5nIGRpcmVjdG9yeSBg L2NvbXBzY2kvYnJ1bGU5L2dyYWQvcGVuZ3poYW8vcHJvNjQvb3NwcmV5MS4w L3RhcmdpYTMyX2lhNjRfbm9kZWJ1Zy9pbmNsdWRlJw0KZ21ha2VbM106IExl YXZpbmcgZGlyZWN0b3J5IGAvY29tcHNjaS9icnVsZTkvZ3JhZC9wZW5nemhh by9wcm82NC9vc3ByZXkxLjAvdGFyZ2lhMzJfaWE2NF9ub2RlYnVnL2luY2x1 ZGUnDQpnbWFrZVsyXTogTGVhdmluZyBkaXJlY3RvcnkgYC9jb21wc2NpL2Jy dWxlOS9ncmFkL3Blbmd6aGFvL3BybzY0L29zcHJleTEuMC90YXJnaWEzMl9p YTY0X25vZGVidWcvdGFyZ19pbmZvJw0KZ21ha2VbMV06IExlYXZpbmcgZGly ZWN0b3J5IGAvY29tcHNjaS9icnVsZTkvZ3JhZC9wZW5nemhhby9wcm82NC9v c3ByZXkxLjAvdGFyZ2lhMzJfaWE2NF9ub2RlYnVnL2JlJw0KY2QgLi4vaXBs ICYmIGdtYWtlDQpnbWFrZVsxXTogRW50ZXJpbmcgZGlyZWN0b3J5IGAvY29t cHNjaS9icnVsZTkvZ3JhZC9wZW5nemhhby9wcm82NC9vc3ByZXkxLjAvdGFy Z2lhMzJfaWE2NF9ub2RlYnVnL2lwbCcNCmlmICEgdGVzdCAtYSBiZS5zbzsg dGhlbiBsbiAtc2YgLi4vYmUvYmUuc28gLjsgZmkNCmNkIC4uL3dvcHQgJiYg Z21ha2UNCmdtYWtlWzJdOiBFbnRlcmluZyBkaXJlY3RvcnkgYC9jb21wc2Np L2JydWxlOS9ncmFkL3Blbmd6aGFvL3BybzY0L29zcHJleTEuMC90YXJnaWEz Ml9pYTY0X25vZGVidWcvd29wdCcNCmNkIC4uL2JlICYmIGdtYWtlDQpnbWFr ZVszXTogRW50ZXJpbmcgZGlyZWN0b3J5IGAvY29tcHNjaS9icnVsZTkvZ3Jh ZC9wZW5nemhhby9wcm82NC9vc3ByZXkxLjAvdGFyZ2lhMzJfaWE2NF9ub2Rl YnVnL2JlJw0KY2QgLi4vaW5jbHVkZSAmJiBnbWFrZQ0KZ21ha2VbNF06IEVu dGVyaW5nIGRpcmVjdG9yeSBgL2NvbXBzY2kvYnJ1bGU5L2dyYWQvcGVuZ3po YW8vcHJvNjQvb3NwcmV5MS4wL3RhcmdpYTMyX2lhNjRfbm9kZWJ1Zy9pbmNs dWRlJw0KZ21ha2VbNF06IExlYXZpbmcgZGlyZWN0b3J5IGAvY29tcHNjaS9i cnVsZTkvZ3JhZC9wZW5nemhhby9wcm82NC9vc3ByZXkxLjAvdGFyZ2lhMzJf aWE2NF9ub2RlYnVnL2luY2x1ZGUnDQppZiAhIHRlc3QgLWEgaXRhbml1bS5z bzsgdGhlbiBsbiAtc2YgLi4vdGFyZ19pbmZvL2l0YW5pdW0uc28gLjsgZmkN CmNkIC4uL3RhcmdfaW5mbyAmJiBnbWFrZQ0KZ21ha2VbNF06IEVudGVyaW5n IGRpcmVjdG9yeSBgL2NvbXBzY2kvYnJ1bGU5L2dyYWQvcGVuZ3poYW8vcHJv NjQvb3NwcmV5MS4wL3RhcmdpYTMyX2lhNjRfbm9kZWJ1Zy90YXJnX2luZm8n DQpjZCAuLi9pbmNsdWRlICYmIGdtYWtlDQpnbWFrZVs1XTogRW50ZXJpbmcg ZGlyZWN0b3J5IGAvY29tcHNjaS9icnVsZTkvZ3JhZC9wZW5nemhhby9wcm82 NC9vc3ByZXkxLjAvdGFyZ2lhMzJfaWE2NF9ub2RlYnVnL2luY2x1ZGUnDQpn bWFrZVs1XTogTGVhdmluZyBkaXJlY3RvcnkgYC9jb21wc2NpL2JydWxlOS9n cmFkL3Blbmd6aGFvL3BybzY0L29zcHJleTEuMC90YXJnaWEzMl9pYTY0X25v ZGVidWcvaW5jbHVkZScNCmdtYWtlWzRdOiBMZWF2aW5nIGRpcmVjdG9yeSBg L2NvbXBzY2kvYnJ1bGU5L2dyYWQvcGVuZ3poYW8vcHJvNjQvb3NwcmV5MS4w L3RhcmdpYTMyX2lhNjRfbm9kZWJ1Zy90YXJnX2luZm8nDQpnbWFrZVszXTog TGVhdmluZyBkaXJlY3RvcnkgYC9jb21wc2NpL2JydWxlOS9ncmFkL3Blbmd6 aGFvL3BybzY0L29zcHJleTEuMC90YXJnaWEzMl9pYTY0X25vZGVidWcvYmUn DQppZiAhIHRlc3QgLWEgYmUuc287IHRoZW4gbG4gLXNmIC4uL2JlL2JlLnNv IC47IGZpDQpnbWFrZVsyXTogTGVhdmluZyBkaXJlY3RvcnkgYC9jb21wc2Np L2JydWxlOS9ncmFkL3Blbmd6aGFvL3BybzY0L29zcHJleTEuMC90YXJnaWEz Ml9pYTY0X25vZGVidWcvd29wdCcNCmdtYWtlWzFdOiBMZWF2aW5nIGRpcmVj dG9yeSBgL2NvbXBzY2kvYnJ1bGU5L2dyYWQvcGVuZ3poYW8vcHJvNjQvb3Nw cmV5MS4wL3RhcmdpYTMyX2lhNjRfbm9kZWJ1Zy9pcGwnDQpnKysgLURfU0dJ X1NPVVJDRSAtRF9MQU5HVUFHRV9DX1BMVVNfUExVUyAtZnVuc2lnbmVkLWNo YXIgLURfX0dOVV9CVUdfV09SS0FST1VORCAtRF9OT1RIUkVBRFMgLWMgICAg ICAgICAgICAtRF9fTUlQU19BTkRfSUE2NF9FTEZfSCAtRFRBUkdfSUE2NCAt RF9ORVdfU1lNVEFCIC1EX01FUkdFX1NVTU1BUllfU1RfSURYXz0xIC1EQkFD S19FTkQgLURTVERfTU9OR09PU0VfTE9DPSciL3Vzci9saWIzMi9jbXBscnMi JyAtRF9TVVBQT1JUX0lQQSAtRF9NVUxUSUdPVCAtRF9ORVdfU1lNVEFCIC1E X01FUkdFX1NVTU1BUllfU1RfSURYXz0xIC1EQkFDS19FTkQgLURTVERfTU9O R09PU0VfTE9DPSciL3Vzci9saWIzMi9jbXBscnMiJyAtRF9TVVBQT1JUX0lQ QSAtRE1PTkdPT1NFX0JFIC1JLi4vLi4vaXBhL2NvbW1vbiAtSS4uLy4uL2lw YS9sb2NhbCAtSS4uLy4uL2lwYS9tYWluL29wdGltaXplIC1JLi4vLi4vaXBh L21haW4vYW5hbHl6ZSAtSS4uLy4uL2JlL2xubyAtSS4uLy4uL2JlL2NvbSAt SS4uLy4uL2NvbW1vbi9jb20gLUkuLi8uLi9iZS9yZWdpb24gLUkuLi8uLi9i ZS9vcHQgLUkuLi8uLi9jb21tb24vY29tL2lhNjQgLUkuLi8uLi9jb21tb24v dXRpbCAtSS4uLy4uL2Zha2VfbGQvY29tbW9uIC1JLi4vLi4vZmFrZV9sZCAt SS4uL2JlIC1JLi4vaW5jbHVkZS9saWJlbGYgICAtSS4uL2luY2x1ZGUgIC1P MCAtRF9NSVBTRUwgLURfTE9OR0xPTkcgLURfTUlQU19TWklOVD0zMiAtRF9N SVBTX1NaUFRSPTMyIC1EX01JUFNfU1pMT05HPTMyIC1NRCAuLi8uLi9pcGEv Y29tbW9uL2lwY19kc3RfbWVyZ2UuY3h4IC1vIGlwY19kc3RfbWVyZ2Uubw0K SW4gZmlsZSBpbmNsdWRlZCBmcm9tIC4uLy4uL2JlL2NvbS9mYl93aGlybC5o OjY3LA0KICAgICAgICAgICAgICAgICBmcm9tIC4uLy4uL2lwYS9sb2NhbC9p cGxfc3VtbWFyeS5oOjc2LA0KICAgICAgICAgICAgICAgICBmcm9tIC4uLy4u L2lwYS9tYWluL2FuYWx5emUvaXBhX2NnLmg6NjUsDQogICAgICAgICAgICAg ICAgIGZyb20gLi4vLi4vaXBhL2NvbW1vbi9pcGNfZHN0X21lcmdlLmN4eDo1 MToNCi4uLy4uL2NvbW1vbi9jb20vZmJfaW5mby5oOjE0MjoyOiB3YXJuaW5n OiBtdWx0aS1saW5lIGNvbW1lbnQNCi4uLy4uL2NvbW1vbi9jb20vZmJfaW5m by5oOjE0NToyOiB3YXJuaW5nOiBtdWx0aS1saW5lIGNvbW1lbnQNCi90bXAv Y2NqOG1Ya2ouczogQXNzZW1ibGVyIG1lc3NhZ2VzOg0KL3RtcC9jY2o4bVhr ai5zOjE2MzogRXJyb3I6IGludmFsaWQgY2hhcmFjdGVyICc9JyBpbiBvcGVy YW5kIDENCi90bXAvY2NqOG1Ya2ouczo0NDY6IEVycm9yOiBpbnZhbGlkIGNo YXJhY3RlciAnPScgaW4gb3BlcmFuZCAxDQovdG1wL2NjajhtWGtqLnM6NTIw OiBFcnJvcjogaW52YWxpZCBjaGFyYWN0ZXIgJz0nIGluIG9wZXJhbmQgMQ0K L3RtcC9jY2o4bVhrai5zOjc5OTogRXJyb3I6IGludmFsaWQgY2hhcmFjdGVy ICc9JyBpbiBvcGVyYW5kIDENCi90bXAvY2NqOG1Ya2ouczo4NjM6IEVycm9y OiBpbnZhbGlkIGNoYXJhY3RlciAnPScgaW4gb3BlcmFuZCAxDQovdG1wL2Nj ajhtWGtqLnM6MTE3NTogRXJyb3I6IGludmFsaWQgY2hhcmFjdGVyICc9JyBp biBvcGVyYW5kIDENCi90bXAvY2NqOG1Ya2ouczoxMjUwOiBFcnJvcjogaW52 YWxpZCBjaGFyYWN0ZXIgJz0nIGluIG9wZXJhbmQgMQ0KL3RtcC9jY2o4bVhr ai5zOjEzMzc6IEVycm9yOiBpbnZhbGlkIGNoYXJhY3RlciAnPScgaW4gb3Bl cmFuZCAxDQovdG1wL2NjajhtWGtqLnM6MTEyODg6IEVycm9yOiBSZXN0IG9m IGxpbmUgaWdub3JlZC4gRmlyc3QgaWdub3JlZCBjaGFyYWN0ZXIgaXMgYCEn Lg0KL3RtcC9jY2o4bVhrai5zOjExMjg5OiBFcnJvcjogaWdub3JpbmcgdW5y ZWNvZ25pemVkIHN5bWJvbCB0eXBlICIiDQovdG1wL2NjajhtWGtqLnM6MTEy ODk6IEVycm9yOiBSZXN0IG9mIGxpbmUgaWdub3JlZC4gRmlyc3QgaWdub3Jl ZCBjaGFyYWN0ZXIgaXMgYCEnLg0KL3RtcC9jY2o4bVhrai5zOjExMjkwOiBF cnJvcjogaW52YWxpZCBjaGFyYWN0ZXIgJyEnIGluIG1uZW1vbmljDQovdG1w L2NjajhtWGtqLnM6MTEzMTk6IEVycm9yOiBleHBlY3RlZCBjb21tYSBhZnRl ciBuYW1lIGBvcGVyYXRvcicgaW4gLnNpemUgZGlyZWN0aXZlDQovdG1wL2Nj ajhtWGtqLnM6MTEzMTk6IEVycm9yOiBSZXN0IG9mIGxpbmUgaWdub3JlZC4g Rmlyc3QgaWdub3JlZCBjaGFyYWN0ZXIgaXMgYCEnLg0KL3RtcC9jY2o4bVhr ai5zOjExNzY4OiBXYXJuaW5nOiBtaXNzaW5nIG9wZXJhbmQ7IHplcm8gYXNz dW1lZA0KL3RtcC9jY2o4bVhrai5zOjEyMjI3OiBFcnJvcjogUmVzdCBvZiBs aW5lIGlnbm9yZWQuIEZpcnN0IGlnbm9yZWQgY2hhcmFjdGVyIGlzIGA8Jy4N Ci90bXAvY2NqOG1Ya2ouczoxMjIyODogRXJyb3I6IGlnbm9yaW5nIHVucmVj b2duaXplZCBzeW1ib2wgdHlwZSAiIg0KL3RtcC9jY2o4bVhrai5zOjEyMjI4 OiBFcnJvcjogUmVzdCBvZiBsaW5lIGlnbm9yZWQuIEZpcnN0IGlnbm9yZWQg Y2hhcmFjdGVyIGlzIGA8Jy4NCi90bXAvY2NqOG1Ya2ouczoxMjIyOTogRXJy b3I6IGludmFsaWQgY2hhcmFjdGVyICc8JyBpbiBtbmVtb25pYw0KL3RtcC9j Y2o4bVhrai5zOjEyMjYzOiBFcnJvcjogZXhwZWN0ZWQgY29tbWEgYWZ0ZXIg bmFtZSBgb3BlcmF0b3InIGluIC5zaXplIGRpcmVjdGl2ZQ0KL3RtcC9jY2o4 bVhrai5zOjEyMjYzOiBFcnJvcjogUmVzdCBvZiBsaW5lIGlnbm9yZWQuIEZp cnN0IGlnbm9yZWQgY2hhcmFjdGVyIGlzIGA8Jy4NCmdtYWtlOiAqKiogW2lw Y19kc3RfbWVyZ2Uub10gRXJyb3IgMQ0KZ21ha2U6IExlYXZpbmcgZGlyZWN0 b3J5IGAvY29tcHNjaS9icnVsZTkvZ3JhZC9wZW5nemhhby9wcm82NC9vc3By ZXkxLjAvdGFyZ2lhMzJfaWE2NF9ub2RlYnVnL2lwYScNCg== ---2138965737-748718235-982968873=:7809-- From owner-pro64-support@oss.sgi.com Fri Feb 23 15:05:10 2001 Received: by oss.sgi.com id ; Fri, 23 Feb 2001 15:05:01 -0800 Received: from pneumatic-tube.sgi.com ([204.94.214.22]:38194 "EHLO pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP id ; Fri, 23 Feb 2001 15:04:50 -0800 Received: from gaea.engr.sgi.com (gaea.engr.sgi.com [130.62.180.97]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id PAA05907 for ; Fri, 23 Feb 2001 15:14:21 -0800 (PST) mail_from (murthy@sgi.com) Received: from sgi.com (localhost [127.0.0.1]) by gaea.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) via ESMTP id PAA99932; Fri, 23 Feb 2001 15:01:29 -0800 (PST) Message-ID: <3A96EBC9.14A2C31@sgi.com> Date: Fri, 23 Feb 2001 15:01:29 -0800 From: Chandrasekhar Murthy X-Mailer: Mozilla 4.51C-SGI [en] (X11; I; IRIX 6.5 IP32) X-Accept-Language: en MIME-Version: 1.0 To: Peng Zhao CC: pro64-support@oss.sgi.com Subject: Re: Assembler messages in cross-compilation of pro64 References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-pro64-support@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;pro64-support-outgoing It is a bug in g++. It was reported by Jacques-Olivier Haenni on Jan 22. I had suggested the following workaround then. Modify the g++ commandline emitted by make to generate the assembly language file ipc_dst_merge.s Edit the assembly file replacing operator!= by __ne operator< by __lt and then generate the object file as follows as -x -o ipc_dst_merge.o ipc_dst_merge.s Murthy From owner-pro64-support@oss.sgi.com Fri Feb 23 15:07:21 2001 Received: by oss.sgi.com id ; Fri, 23 Feb 2001 15:07:11 -0800 Received: from scapa.cs.ualberta.ca ([129.128.4.44]:32262 "EHLO scapa.cs.ualberta.ca") by oss.sgi.com with ESMTP id ; Fri, 23 Feb 2001 15:06:53 -0800 Received: (from localhost user: 'pengzhao' uid#483 fake: STDIN (pengzhao@peers)) by scapa.cs.ualberta.ca id ; Fri, 23 Feb 2001 16:06:31 -0700 Date: Fri, 23 Feb 2001 16:06:31 -0700 (MST) From: Peng Zhao To: Chandrasekhar Murthy cc: pro64-support@oss.sgi.com Subject: Re: Assembler messages in cross-compilation of pro64 In-Reply-To: <3A96EBC9.14A2C31@sgi.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-pro64-support@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;pro64-support-outgoing Thank you very much for you prompt response. But I cann't found the assembly file. From the error msg, it seems that it is in the /tmp directory. But nothing there. thank you again. Regards Peng On Fri, 23 Feb 2001, Chandrasekhar Murthy wrote: > It is a bug in g++. > It was reported by Jacques-Olivier Haenni > > on Jan 22. > > I had suggested the following workaround then. > > Modify the g++ commandline emitted by make to generate the > assembly language file ipc_dst_merge.s > > Edit the assembly file replacing > > operator!= by __ne > operator< by __lt > > and then generate the object file as follows > > as -x -o ipc_dst_merge.o ipc_dst_merge.s > > Murthy > Peng -- Peng Zhao pengzhao@cs.ualberta.ca http://www.cs.ualberta.ca/~pengzhao TEL (Lab): (780)492-3725 Lab: CSC251 From owner-pro64-support@oss.sgi.com Fri Feb 23 15:24:30 2001 Received: by oss.sgi.com id ; Fri, 23 Feb 2001 15:24:20 -0800 Received: from pneumatic-tube.sgi.com ([204.94.214.22]:54323 "EHLO pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP id ; Fri, 23 Feb 2001 15:24:07 -0800 Received: from gaea.engr.sgi.com (gaea.engr.sgi.com [130.62.180.97]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id PAA02061 for ; Fri, 23 Feb 2001 15:33:38 -0800 (PST) mail_from (murthy@gaea.engr.sgi.com) Received: (from murthy@localhost) by gaea.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) id PAA07022; Fri, 23 Feb 2001 15:20:46 -0800 (PST) Date: Fri, 23 Feb 2001 15:20:46 -0800 (PST) From: murthy@gaea.engr.sgi.com (Chandrasekhar Murthy) Message-Id: <200102232320.PAA07022@gaea.engr.sgi.com> To: Chandrasekhar Murthy , Peng Zhao Subject: Re: Assembler messages in cross-compilation of pro64 Cc: pro64-support@oss.sgi.com Sender: owner-pro64-support@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;pro64-support-outgoing The -S option in g++ man page can be used to generate an assembly language file. Murthy From owner-pro64-support@oss.sgi.com Fri Feb 23 15:24:40 2001 Received: by oss.sgi.com id ; Fri, 23 Feb 2001 15:24:31 -0800 Received: from deliverator.sgi.com ([204.94.214.10]:58149 "EHLO deliverator.sgi.com") by oss.sgi.com with ESMTP id ; Fri, 23 Feb 2001 15:24:17 -0800 Received: from rohi.engr.sgi.com (rohi.engr.sgi.com [130.62.180.74]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id PAA07833 for ; Fri, 23 Feb 2001 15:23:13 -0800 (PST) mail_from (mpm@rohi.engr.sgi.com) Received: (from mpm@localhost) by rohi.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) id PAA55376; Fri, 23 Feb 2001 15:22:47 -0800 (PST) Date: Fri, 23 Feb 2001 15:22:47 -0800 (PST) From: mpm@rohi.engr.sgi.com (Michael Murphy) Message-Id: <200102232322.PAA55376@rohi.engr.sgi.com> To: Chandrasekhar Murthy , Peng Zhao Subject: Re: Assembler messages in cross-compilation of pro64 Cc: pro64-support@oss.sgi.com Sender: owner-pro64-support@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;pro64-support-outgoing add -S to the command line to keep the .s file, or -keep to keep all intermediate files. -- Mike Murphy -- mpm@sgi.com -- quote of the day: -- "When people are serving, life is no longer meaningless" (John Gardner) From owner-pro64-support@oss.sgi.com Fri Feb 23 15:28:30 2001 Received: by oss.sgi.com id ; Fri, 23 Feb 2001 15:28:11 -0800 Received: from deliverator.sgi.com ([204.94.214.10]:60454 "EHLO deliverator.sgi.com") by oss.sgi.com with ESMTP id ; Fri, 23 Feb 2001 15:27:59 -0800 Received: from rohi.engr.sgi.com (rohi.engr.sgi.com [130.62.180.74]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id PAA08363 for ; Fri, 23 Feb 2001 15:26:54 -0800 (PST) mail_from (mpm@rohi.engr.sgi.com) Received: (from mpm@localhost) by rohi.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) id PAA58951; Fri, 23 Feb 2001 15:26:29 -0800 (PST) Date: Fri, 23 Feb 2001 15:26:29 -0800 (PST) From: mpm@rohi.engr.sgi.com (Michael Murphy) Message-Id: <200102232326.PAA58951@rohi.engr.sgi.com> To: Peng Zhao , Chandrasekhar Murthy , mpm@rohi.engr.sgi.com (Michael Murphy) Subject: Re: Assembler messages in cross-compilation of pro64 Cc: pro64-support@oss.sgi.com Sender: owner-pro64-support@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;pro64-support-outgoing > or -keep to keep all intermediate files. Oops, I was thinking of sgi++. Use -save-temps in g++. -- Mike Murphy -- mpm@sgi.com -- quote of the day: -- "When people are serving, life is no longer meaningless" (John Gardner) From owner-pro64-support@oss.sgi.com Fri Feb 23 16:35:31 2001 Received: by oss.sgi.com id ; Fri, 23 Feb 2001 16:35:22 -0800 Received: from munch-it.turbolinux.com ([38.170.88.129]:36850 "EHLO mail.us.tlan") by oss.sgi.com with ESMTP id ; Fri, 23 Feb 2001 16:35:07 -0800 Received: (from nobody@localhost) by mail.us.tlan (8.9.3/8.9.3) id QAA03606 for ; Fri, 23 Feb 2001 16:35:04 -0800 Received: from drevil.us.tlan(172.16.13.106), claiming to be "drevil.dev.us.tlan" via SMTP by mail.us.tlan, id smtpdIjH6Ee; Fri Feb 23 16:35:00 2001 Received: (from mmadore@localhost) by drevil.dev.us.tlan (8.9.3/8.9.3) id QAA16957 for pro64-support@oss.sgi.com; Fri, 23 Feb 2001 16:35:13 -0800 Date: Fri, 23 Feb 2001 16:35:13 -0800 From: Michael Madore To: pro64-support@oss.sgi.com Subject: Link error building emacs Message-ID: <20010223163513.A16425@drevil.no> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-pro64-support@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;pro64-support-outgoing Hi, I was attempting to build emacs using the Pro64 compiler instead of gcc. I am running into the following linking problem: cd lib-src; make all \ CC='/usr/bin/sgicc' CFLAGS='-g -O' CPPFLAGS='-D_BSD_SOURCE -D_XOPEN_SOURCE ' \ LDFLAGS='' MAKE='make' make[1]: Entering directory `/usr/src/turbo/BUILD/emacs-20.7/lib-src' make[1]: Nothing to be done for `all'. make[1]: Leaving directory `/usr/src/turbo/BUILD/emacs-20.7/lib-src' cd src; make all \ CC='/usr/bin/sgicc' CFLAGS='-g -O' CPPFLAGS='-D_BSD_SOURCE -D_XOPEN_SOURCE ' \ LDFLAGS='' MAKE='make' make[1]: Entering directory `/usr/src/turbo/BUILD/emacs-20.7/src' /usr/bin/sgicc -nostdlib `./prefix-args -Xlinker ` -o temacs pre-crt0.o /usr/lib/crt1.o /usr/lib/crti.o dispnew.o frame.o scroll.o xdisp.o xmenu.o window.o charset.o coding.o category.o ccl.o cm.o term.o xfaces.o emacs.o keyboard.o macros.o keymap.o sysdep.o buffer.o filelock.o insdel.o marker.o intervals.o textprop.o minibuf.o fileio.o dired.o filemode.o cmds.o casetab.o casefiddle.o indent.o search.o regex.o undo.o alloc.o data.o doc.o editfns.o callint.o eval.o floatfns.o fns.o print.o lread.o abbrev.o syntax.o unexelf.o mocklisp.o bytecode.o process.o callproc.o region-cache.o doprnt.o strftime.o getloadavg.o terminfo.o lastfile.o vm-limit.o -lncurses -lm -lc -lgcc /usr/lib/crtn.o /usr/lib/crt1.o: In function `_start': /usr/lib/crt1.o(.text+0x0): multiple definition of `_start' /usr/lib/gcc-lib/ia64-cygnus-linux/2.96-ia64-000717/../../../crt1.o(.text+0x0): first defined here /usr/lib/crt1.o(.sdata+0x0): multiple definition of `_IO_stdin_used' /usr/lib/gcc-lib/ia64-cygnus-linux/2.96-ia64-000717/../../../crt1.o(.sdata+0x0): first defined here /usr/lib/crti.o: In function `_init': /usr/lib/crti.o(.init+0x0): multiple definition of `_init' /usr/lib/gcc-lib/ia64-cygnus-linux/2.96-ia64-000717/../../../crti.o(.init+0x0): first defined here /usr/lib/crti.o: In function `_fini': /usr/lib/crti.o(.fini+0x0): multiple definition of `_fini' /usr/lib/gcc-lib/ia64-cygnus-linux/2.96-ia64-000717/../../../crti.o(.fini+0x0): first defined here callproc.o: In function `Fcall_process_region': callproc.o(.text+0x2e32): the use of `mktemp' is dangerous, better use `mkstemp' collect2: ld returned 1 exit status make[1]: *** [temacs] Error 2 make[1]: Leaving directory `/usr/src/turbo/BUILD/emacs-20.7/src' make: *** [src] Error 2 It looks like it's linking in both the gcc and sgi c-runtimes. Do I need to specify additional environment variables other than CC=/usr/bin/sgicc? -- Mike Madore Software Engineer TurboLinux, Inc. From owner-pro64-support@oss.sgi.com Fri Feb 23 16:44:01 2001 Received: by oss.sgi.com id ; Fri, 23 Feb 2001 16:43:42 -0800 Received: from fmfdns02.fm.intel.com ([132.233.247.11]:15062 "EHLO thalia.fm.intel.com") by oss.sgi.com with ESMTP id ; Fri, 23 Feb 2001 16:43:36 -0800 Received: from SMTP (fmsmsxvs03-1.fm.intel.com [132.233.42.203]) by thalia.fm.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.35 2001/02/12 09:03:45 smothers Exp $) with SMTP id AAA25871; Sat, 24 Feb 2001 00:43:18 GMT Received: from fmsmsx19.fm.intel.com ([132.233.48.19]) by 132.233.48.203 (Norton AntiVirus for Internet Email Gateways 1.0) ; Sat, 24 Feb 2001 00:43:18 0000 (GMT) Received: by fmsmsx19.fm.intel.com with Internet Mail Service (5.5.2650.21) id ; Fri, 23 Feb 2001 16:43:17 -0800 Message-ID: <9287DC1579B0D411AA2F009027F44C3F042DF8B3@FMSMSX41> From: "Chan, Sun C" To: "'Michael Madore'" , pro64-support@oss.sgi.com Subject: RE: Link error building emacs Date: Fri, 23 Feb 2001 16:43:16 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-pro64-support@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;pro64-support-outgoing your sgicc line has /usr/lib/cr1.o and /usr/lib/crti.o, hence the duplicate symbol -----Original Message----- From: Michael Madore [mailto:mmadore@turbolinux.com] Sent: Friday, February 23, 2001 4:35 PM To: pro64-support@oss.sgi.com Subject: Link error building emacs Hi, I was attempting to build emacs using the Pro64 compiler instead of gcc. I am running into the following linking problem: cd lib-src; make all \ CC='/usr/bin/sgicc' CFLAGS='-g -O' CPPFLAGS='-D_BSD_SOURCE -D_XOPEN_SOURCE ' \ LDFLAGS='' MAKE='make' make[1]: Entering directory `/usr/src/turbo/BUILD/emacs-20.7/lib-src' make[1]: Nothing to be done for `all'. make[1]: Leaving directory `/usr/src/turbo/BUILD/emacs-20.7/lib-src' cd src; make all \ CC='/usr/bin/sgicc' CFLAGS='-g -O' CPPFLAGS='-D_BSD_SOURCE -D_XOPEN_SOURCE ' \ LDFLAGS='' MAKE='make' make[1]: Entering directory `/usr/src/turbo/BUILD/emacs-20.7/src' /usr/bin/sgicc -nostdlib `./prefix-args -Xlinker ` -o temacs pre-crt0.o /usr/lib/crt1.o /usr/lib/crti.o dispnew.o frame.o scroll.o xdisp.o xmenu.o window.o charset.o coding.o category.o ccl.o cm.o term.o xfaces.o emacs.o keyboard.o macros.o keymap.o sysdep.o buffer.o filelock.o insdel.o marker.o intervals.o textprop.o minibuf.o fileio.o dired.o filemode.o cmds.o casetab.o casefiddle.o indent.o search.o regex.o undo.o alloc.o data.o doc.o editfns.o callint.o eval.o floatfns.o fns.o print.o lread.o abbrev.o syntax.o unexelf.o mocklisp.o bytecode.o process.o callproc.o region-cache.o doprnt.o strftime.o getloadavg.o terminfo.o lastfile.o vm-limit.o -lncurses -lm -lc -lgcc /usr/lib/crtn.o /usr/lib/crt1.o: In function `_start': /usr/lib/crt1.o(.text+0x0): multiple definition of `_start' /usr/lib/gcc-lib/ia64-cygnus-linux/2.96-ia64-000717/../../../crt1.o(.text+0x 0): first defined here /usr/lib/crt1.o(.sdata+0x0): multiple definition of `_IO_stdin_used' /usr/lib/gcc-lib/ia64-cygnus-linux/2.96-ia64-000717/../../../crt1.o(.sdata+0 x0): first defined here /usr/lib/crti.o: In function `_init': /usr/lib/crti.o(.init+0x0): multiple definition of `_init' /usr/lib/gcc-lib/ia64-cygnus-linux/2.96-ia64-000717/../../../crti.o(.init+0x 0): first defined here /usr/lib/crti.o: In function `_fini': /usr/lib/crti.o(.fini+0x0): multiple definition of `_fini' /usr/lib/gcc-lib/ia64-cygnus-linux/2.96-ia64-000717/../../../crti.o(.fini+0x 0): first defined here callproc.o: In function `Fcall_process_region': callproc.o(.text+0x2e32): the use of `mktemp' is dangerous, better use `mkstemp' collect2: ld returned 1 exit status make[1]: *** [temacs] Error 2 make[1]: Leaving directory `/usr/src/turbo/BUILD/emacs-20.7/src' make: *** [src] Error 2 It looks like it's linking in both the gcc and sgi c-runtimes. Do I need to specify additional environment variables other than CC=/usr/bin/sgicc? -- Mike Madore Software Engineer TurboLinux, Inc. From owner-pro64-support@oss.sgi.com Fri Feb 23 18:10:51 2001 Received: by oss.sgi.com id ; Fri, 23 Feb 2001 18:10:41 -0800 Received: from scapa.cs.ualberta.ca ([129.128.4.44]:2835 "EHLO scapa.cs.ualberta.ca") by oss.sgi.com with ESMTP id ; Fri, 23 Feb 2001 18:10:31 -0800 Received: (from localhost user: 'pengzhao' uid#483 fake: STDIN (pengzhao@peers)) by scapa.cs.ualberta.ca id ; Fri, 23 Feb 2001 19:10:22 -0700 Date: Fri, 23 Feb 2001 19:10:22 -0700 (MST) From: Peng Zhao To: pro64-support@oss.sgi.com Subject: Internal compiler error in In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-pro64-support@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;pro64-support-outgoing Hi, Although this seems that something wrong with g++, I's like to see whether somebody else has solved it. In ~/pro64/osprey1.0/targia32_ia64_nodebug/cg, I run "gmake", later I got a error message about "Internal compiler error". enclosed file is the error message. following are my system infomation: >gcc -v Reading specs from /usr/lib/gcc-lib/i386-redhat-linux/2.96/specs gcc version 2.96 20000731 (Red Hat Linux 7.0) Thanks Peng -- Peng Zhao pengzhao@cs.ualberta.ca http://www.cs.ualberta.ca/~pengzhao TEL (Lab): (780)492-3725 Lab: CSC251 From owner-pro64-support@oss.sgi.com Fri Feb 23 18:14:51 2001 Received: by oss.sgi.com id ; Fri, 23 Feb 2001 18:14:32 -0800 Received: from scapa.cs.ualberta.ca ([129.128.4.44]:14099 "EHLO scapa.cs.ualberta.ca") by oss.sgi.com with ESMTP id ; Fri, 23 Feb 2001 18:14:21 -0800 Received: (from localhost user: 'pengzhao' uid#483 fake: STDIN (pengzhao@peers)) by scapa.cs.ualberta.ca id ; Fri, 23 Feb 2001 19:13:58 -0700 Date: Fri, 23 Feb 2001 19:13:57 -0700 (MST) From: Peng Zhao To: pro64-support@oss.sgi.com Subject: Internal compiler error in(file enclosed) In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="-2138965737-929463465-982980837=:8443" Sender: owner-pro64-support@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;pro64-support-outgoing This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. Send mail to mime@docserver.cac.washington.edu for more info. ---2138965737-929463465-982980837=:8443 Content-Type: TEXT/PLAIN; charset=US-ASCII Sorry. On Fri, 23 Feb 2001, Peng Zhao wrote: > > Hi, > Although this seems that something wrong with g++, I's like to see > whether somebody else has solved it. > > In ~/pro64/osprey1.0/targia32_ia64_nodebug/cg, I run "gmake", > later I got a error message about "Internal compiler error". > > enclosed file is the error message. > > following are my system infomation: > > >gcc -v > Reading specs from /usr/lib/gcc-lib/i386-redhat-linux/2.96/specs > gcc version 2.96 20000731 (Red Hat Linux 7.0) > > Thanks > > Peng > -- > Peng Zhao pengzhao@cs.ualberta.ca > http://www.cs.ualberta.ca/~pengzhao > TEL (Lab): (780)492-3725 Lab: CSC251 > > > Peng -- Peng Zhao pengzhao@cs.ualberta.ca http://www.cs.ualberta.ca/~pengzhao TEL (Lab): (780)492-3725 Lab: CSC251 ---2138965737-929463465-982980837=:8443 Content-Type: TEXT/PLAIN; charset=US-ASCII; name=nn Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: Content-Disposition: attachment; filename=nn Z21ha2U6IEVudGVyaW5nIGRpcmVjdG9yeSBgL2NvbXBzY2kvYnJ1bGU5L2dy YWQvcGVuZ3poYW8vcHJvNjQvb3NwcmV5MS4wL3RhcmdpYTMyX2lhNjRfbm9k ZWJ1Zy9jZycNCmNkIC4uL2xpYmVsZiAmJiBnbWFrZQ0KZ21ha2VbMV06IEVu dGVyaW5nIGRpcmVjdG9yeSBgL2NvbXBzY2kvYnJ1bGU5L2dyYWQvcGVuZ3po YW8vcHJvNjQvb3NwcmV5MS4wL3RhcmdpYTMyX2lhNjRfbm9kZWJ1Zy9saWJl bGYnDQpjZCAuLi9pbmNsdWRlICYmIGdtYWtlDQpnbWFrZVsyXTogRW50ZXJp bmcgZGlyZWN0b3J5IGAvY29tcHNjaS9icnVsZTkvZ3JhZC9wZW5nemhhby9w cm82NC9vc3ByZXkxLjAvdGFyZ2lhMzJfaWE2NF9ub2RlYnVnL2luY2x1ZGUn DQpnbWFrZVsyXTogTGVhdmluZyBkaXJlY3RvcnkgYC9jb21wc2NpL2JydWxl OS9ncmFkL3Blbmd6aGFvL3BybzY0L29zcHJleTEuMC90YXJnaWEzMl9pYTY0 X25vZGVidWcvaW5jbHVkZScNCmdtYWtlWzFdOiBMZWF2aW5nIGRpcmVjdG9y eSBgL2NvbXBzY2kvYnJ1bGU5L2dyYWQvcGVuZ3poYW8vcHJvNjQvb3NwcmV5 MS4wL3RhcmdpYTMyX2lhNjRfbm9kZWJ1Zy9saWJlbGYnDQpjZCAuLi9saWJl bGZ1dGlsICYmIGdtYWtlDQpnbWFrZVsxXTogRW50ZXJpbmcgZGlyZWN0b3J5 IGAvY29tcHNjaS9icnVsZTkvZ3JhZC9wZW5nemhhby9wcm82NC9vc3ByZXkx LjAvdGFyZ2lhMzJfaWE2NF9ub2RlYnVnL2xpYmVsZnV0aWwnDQpjZCAuLi9p bmNsdWRlICYmIGdtYWtlDQpnbWFrZVsyXTogRW50ZXJpbmcgZGlyZWN0b3J5 IGAvY29tcHNjaS9icnVsZTkvZ3JhZC9wZW5nemhhby9wcm82NC9vc3ByZXkx LjAvdGFyZ2lhMzJfaWE2NF9ub2RlYnVnL2luY2x1ZGUnDQpnbWFrZVsyXTog TGVhdmluZyBkaXJlY3RvcnkgYC9jb21wc2NpL2JydWxlOS9ncmFkL3Blbmd6 aGFvL3BybzY0L29zcHJleTEuMC90YXJnaWEzMl9pYTY0X25vZGVidWcvaW5j bHVkZScNCmdtYWtlWzFdOiBMZWF2aW5nIGRpcmVjdG9yeSBgL2NvbXBzY2kv YnJ1bGU5L2dyYWQvcGVuZ3poYW8vcHJvNjQvb3NwcmV5MS4wL3RhcmdpYTMy X2lhNjRfbm9kZWJ1Zy9saWJlbGZ1dGlsJw0KY2QgLi4vbGliZHdhcmYgJiYg Z21ha2UNCmdtYWtlWzFdOiBFbnRlcmluZyBkaXJlY3RvcnkgYC9jb21wc2Np L2JydWxlOS9ncmFkL3Blbmd6aGFvL3BybzY0L29zcHJleTEuMC90YXJnaWEz Ml9pYTY0X25vZGVidWcvbGliZHdhcmYnDQpjZCAuLi9pbmNsdWRlICYmIGdt YWtlDQpnbWFrZVsyXTogRW50ZXJpbmcgZGlyZWN0b3J5IGAvY29tcHNjaS9i cnVsZTkvZ3JhZC9wZW5nemhhby9wcm82NC9vc3ByZXkxLjAvdGFyZ2lhMzJf aWE2NF9ub2RlYnVnL2luY2x1ZGUnDQpnbWFrZVsyXTogTGVhdmluZyBkaXJl Y3RvcnkgYC9jb21wc2NpL2JydWxlOS9ncmFkL3Blbmd6aGFvL3BybzY0L29z cHJleTEuMC90YXJnaWEzMl9pYTY0X25vZGVidWcvaW5jbHVkZScNCmdtYWtl WzFdOiBMZWF2aW5nIGRpcmVjdG9yeSBgL2NvbXBzY2kvYnJ1bGU5L2dyYWQv cGVuZ3poYW8vcHJvNjQvb3NwcmV5MS4wL3RhcmdpYTMyX2lhNjRfbm9kZWJ1 Zy9saWJkd2FyZicNCmNkIC4uL2xpYnVud2luZFAgJiYgZ21ha2UNCmdtYWtl WzFdOiBFbnRlcmluZyBkaXJlY3RvcnkgYC9jb21wc2NpL2JydWxlOS9ncmFk L3Blbmd6aGFvL3BybzY0L29zcHJleTEuMC90YXJnaWEzMl9pYTY0X25vZGVi dWcvbGlidW53aW5kUCcNCmNkIC4uL2luY2x1ZGUgJiYgZ21ha2UNCmdtYWtl WzJdOiBFbnRlcmluZyBkaXJlY3RvcnkgYC9jb21wc2NpL2JydWxlOS9ncmFk L3Blbmd6aGFvL3BybzY0L29zcHJleTEuMC90YXJnaWEzMl9pYTY0X25vZGVi dWcvaW5jbHVkZScNCmdtYWtlWzJdOiBMZWF2aW5nIGRpcmVjdG9yeSBgL2Nv bXBzY2kvYnJ1bGU5L2dyYWQvcGVuZ3poYW8vcHJvNjQvb3NwcmV5MS4wL3Rh cmdpYTMyX2lhNjRfbm9kZWJ1Zy9pbmNsdWRlJw0KY2QgLi4vdGFyZ19pbmZv ICYmIGdtYWtlDQpnbWFrZVsyXTogRW50ZXJpbmcgZGlyZWN0b3J5IGAvY29t cHNjaS9icnVsZTkvZ3JhZC9wZW5nemhhby9wcm82NC9vc3ByZXkxLjAvdGFy Z2lhMzJfaWE2NF9ub2RlYnVnL3RhcmdfaW5mbycNCmNkIC4uL2luY2x1ZGUg JiYgZ21ha2UNCmdtYWtlWzNdOiBFbnRlcmluZyBkaXJlY3RvcnkgYC9jb21w c2NpL2JydWxlOS9ncmFkL3Blbmd6aGFvL3BybzY0L29zcHJleTEuMC90YXJn aWEzMl9pYTY0X25vZGVidWcvaW5jbHVkZScNCmdtYWtlWzNdOiBMZWF2aW5n IGRpcmVjdG9yeSBgL2NvbXBzY2kvYnJ1bGU5L2dyYWQvcGVuZ3poYW8vcHJv NjQvb3NwcmV5MS4wL3RhcmdpYTMyX2lhNjRfbm9kZWJ1Zy9pbmNsdWRlJw0K Z21ha2VbMl06IExlYXZpbmcgZGlyZWN0b3J5IGAvY29tcHNjaS9icnVsZTkv Z3JhZC9wZW5nemhhby9wcm82NC9vc3ByZXkxLjAvdGFyZ2lhMzJfaWE2NF9u b2RlYnVnL3RhcmdfaW5mbycNCmdtYWtlWzFdOiBMZWF2aW5nIGRpcmVjdG9y eSBgL2NvbXBzY2kvYnJ1bGU5L2dyYWQvcGVuZ3poYW8vcHJvNjQvb3NwcmV5 MS4wL3RhcmdpYTMyX2lhNjRfbm9kZWJ1Zy9saWJ1bndpbmRQJw0KY2QgLi4v YmUgJiYgZ21ha2UNCmdtYWtlWzFdOiBFbnRlcmluZyBkaXJlY3RvcnkgYC9j b21wc2NpL2JydWxlOS9ncmFkL3Blbmd6aGFvL3BybzY0L29zcHJleTEuMC90 YXJnaWEzMl9pYTY0X25vZGVidWcvYmUnDQpjZCAuLi9pbmNsdWRlICYmIGdt YWtlDQpnbWFrZVsyXTogRW50ZXJpbmcgZGlyZWN0b3J5IGAvY29tcHNjaS9i cnVsZTkvZ3JhZC9wZW5nemhhby9wcm82NC9vc3ByZXkxLjAvdGFyZ2lhMzJf aWE2NF9ub2RlYnVnL2luY2x1ZGUnDQpnbWFrZVsyXTogTGVhdmluZyBkaXJl Y3RvcnkgYC9jb21wc2NpL2JydWxlOS9ncmFkL3Blbmd6aGFvL3BybzY0L29z cHJleTEuMC90YXJnaWEzMl9pYTY0X25vZGVidWcvaW5jbHVkZScNCmlmICEg dGVzdCAtYSBpdGFuaXVtLnNvOyB0aGVuIGxuIC1zZiAuLi90YXJnX2luZm8v aXRhbml1bS5zbyAuOyBmaQ0KY2QgLi4vdGFyZ19pbmZvICYmIGdtYWtlDQpn bWFrZVsyXTogRW50ZXJpbmcgZGlyZWN0b3J5IGAvY29tcHNjaS9icnVsZTkv Z3JhZC9wZW5nemhhby9wcm82NC9vc3ByZXkxLjAvdGFyZ2lhMzJfaWE2NF9u b2RlYnVnL3RhcmdfaW5mbycNCmNkIC4uL2luY2x1ZGUgJiYgZ21ha2UNCmdt YWtlWzNdOiBFbnRlcmluZyBkaXJlY3RvcnkgYC9jb21wc2NpL2JydWxlOS9n cmFkL3Blbmd6aGFvL3BybzY0L29zcHJleTEuMC90YXJnaWEzMl9pYTY0X25v ZGVidWcvaW5jbHVkZScNCmdtYWtlWzNdOiBMZWF2aW5nIGRpcmVjdG9yeSBg L2NvbXBzY2kvYnJ1bGU5L2dyYWQvcGVuZ3poYW8vcHJvNjQvb3NwcmV5MS4w L3RhcmdpYTMyX2lhNjRfbm9kZWJ1Zy9pbmNsdWRlJw0KZ21ha2VbMl06IExl YXZpbmcgZGlyZWN0b3J5IGAvY29tcHNjaS9icnVsZTkvZ3JhZC9wZW5nemhh by9wcm82NC9vc3ByZXkxLjAvdGFyZ2lhMzJfaWE2NF9ub2RlYnVnL3Rhcmdf aW5mbycNCmdtYWtlWzFdOiBMZWF2aW5nIGRpcmVjdG9yeSBgL2NvbXBzY2kv YnJ1bGU5L2dyYWQvcGVuZ3poYW8vcHJvNjQvb3NwcmV5MS4wL3RhcmdpYTMy X2lhNjRfbm9kZWJ1Zy9iZScNCmlmICEgdGVzdCAtYSBiZS5zbzsgdGhlbiBs biAtc2YgLi4vYmUvYmUuc28gLjsgZmkNCmlmICEgdGVzdCAtYSBpdGFuaXVt LnNvOyB0aGVuIGxuIC1zZiAuLi90YXJnX2luZm8vaXRhbml1bS5zbyAuOyBm aQ0KZysrIC1EX1NHSV9TT1VSQ0UgLURfTEFOR1VBR0VfQ19QTFVTX1BMVVMg LWZ1bnNpZ25lZC1jaGFyIC1EX19HTlVfQlVHX1dPUktBUk9VTkQgLURfTk9U SFJFQURTIC1jICAgICAgICAgICAgLURzZ2kgLURCQUNLX0VORCAtRE1PTkdP T1NFX0JFIC1EbG9uZ2xvbmcgLURfTE9OR0xPTkcgLURfU1ZSNF9TT1VSQ0Ug LUxBTkc6cGFja2VkPW9uIC1EX19NSVBTX0FORF9JQTY0X0VMRl9IIC1JLiAt SS4uLy4uL2JlL2NnIC1JLi4vLi4vYmUvY2cvZ3JhX21vbiAtSS4uLy4uL2Jl L2NnL2lhNjQgLUkuLi8uLi9jb21tb24vY29tIC1JLi4vLi4vY29tbW9uL2Nv bS9pYTY0IC1JLi4vLi4vY29tbW9uL3V0aWwgLUkuLi8uLi9jb21tb24vc3Rs IC1JLi4vLi4vYmUvY29tIC1JLi4vLi4vYmUvcmVnaW9uIC1JLi4vLi4vYmUv cHJvbXBmX2FubCAtSS4uLy4uL2JlL29wdCAtSS4uLy4uL2NvbW1vbi90YXJn X2luZm8vYWNjZXNzIC1JLi4vdGFyZ19pbmZvIC1JLi4vYmUgLUkuLi9pbmNs dWRlL2xpYmVsZiAtZlBJQyAtRFRBUkdfSUE2NCAgLWZ3cml0YWJsZS1zdHJp bmdzICAtSS4uL2luY2x1ZGUgIC1PMCAtRF9NSVBTRUwgLURfTE9OR0xPTkcg LURfTUlQU19TWklOVD0zMiAtRF9NSVBTX1NaUFRSPTMyIC1EX01JUFNfU1pM T05HPTMyIC1NRCAuLi8uLi9iZS9jZy9scmEuY3h4IC1vIGxyYS5vDQouLi8u Li9iZS9jZy9scmEuY3h4OiBJbiBmdW5jdGlvbiBgdm9pZCBQcmludF9BdmFp bF9TZXQgKEJCICopJzoNCi4uLy4uL2JlL2NnL2xyYS5jeHg6NDYwOiBJbnRl cm5hbCBjb21waWxlciBlcnJvciBpbiANCnByaW50X29wZXJhbmRfYWRkcmVz cywgYXQgY29uZmlnL2kzODYvaTM4Ni5jOjM0MDQNClBsZWFzZSBzdWJtaXQg YSBmdWxsIGJ1ZyByZXBvcnQuDQpTZWUgPFVSTDpodHRwOi8vd3d3LmdudS5v cmcvc29mdHdhcmUvZ2NjL2J1Z3MuaHRtbD4gZm9yIGluc3RydWN0aW9ucy4N CmdtYWtlOiAqKiogW2xyYS5vXSBFcnJvciAxDQpnbWFrZTogTGVhdmluZyBk aXJlY3RvcnkgYC9jb21wc2NpL2JydWxlOS9ncmFkL3Blbmd6aGFvL3BybzY0 L29zcHJleTEuMC90YXJnaWEzMl9pYTY0X25vZGVidWcvY2cnDQo= ---2138965737-929463465-982980837=:8443-- From owner-pro64-support@oss.sgi.com Sat Feb 24 04:33:06 2001 Received: by oss.sgi.com id ; Sat, 24 Feb 2001 04:32:46 -0800 Received: from lslsun.epfl.ch ([128.178.150.20]:44524 "EHLO lslsun.epfl.ch") by oss.sgi.com with ESMTP id ; Sat, 24 Feb 2001 04:32:24 -0800 Received: from epfl.ch (johaenni@lslsun8 [128.178.150.31]) by lslsun.epfl.ch (8.8.X/EPFL-8.1a) with ESMTP id NAA14238; Sat, 24 Feb 2001 13:32:15 +0100 (MET) Message-ID: <3A97A9CE.FF34BAEF@epfl.ch> Date: Sat, 24 Feb 2001 13:32:14 +0100 From: Jacques-Olivier Haenni Organization: Swiss Federal Institute of Technology, Lausanne (EPFL) X-Mailer: Mozilla 4.75 [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en, fr-CH, fr MIME-Version: 1.0 CC: Peng Zhao , pro64-support@oss.sgi.com Subject: Re: Assembler messages in cross-compilation of pro64 References: <3A96EBC9.14A2C31@sgi.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: unlisted-recipients:; (no To-header on input) Sender: owner-pro64-support@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;pro64-support-outgoing Hi, Chandrasekhar Murthy wrote: > > It is a bug in g++. > It was reported by Jacques-Olivier Haenni > > on Jan 22. For more details, look at : http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=24685 When I faced this ipa compilation problem a few weeks ago, I have also been told the following : > I am not sure why you are trying to build ipa. > All components necessary for using ipa have not yet > been released. You should maybe reconsider the pertinence of rebuilding ipa yourself. Jacques-Olivier Haenni -- Jacques-Olivier Haenni http://lslwww.epfl.ch/~johaenni/ Jacques-Olivier.Haenni@epfl.ch Logic Systems Laboratory Swiss Federal Institute of Technology (EPFL) | Tel: (+41 21) 693 66 30 1015 Lausanne - Switzerland | Fax: (+41 21) 693 37 05 From owner-pro64-support@oss.sgi.com Sun Feb 25 16:05:02 2001 Received: by oss.sgi.com id ; Sun, 25 Feb 2001 16:04:42 -0800 Received: from pneumatic-tube.sgi.com ([204.94.214.22]:30993 "EHLO pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP id ; Sun, 25 Feb 2001 16:04:27 -0800 Received: from gaea.engr.sgi.com (gaea.engr.sgi.com [130.62.180.97]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id QAA09752 for ; Sun, 25 Feb 2001 16:14:00 -0800 (PST) mail_from (murthy@sgi.com) Received: from sgi.com (localhost [127.0.0.1]) by gaea.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) via ESMTP id QAA15596; Sun, 25 Feb 2001 16:00:08 -0800 (PST) Message-ID: <3A999C86.FC626628@sgi.com> Date: Sun, 25 Feb 2001 16:00:06 -0800 From: Chandrasekhar Murthy X-Mailer: Mozilla 4.51C-SGI [en] (X11; I; IRIX 6.5 IP32) X-Accept-Language: en MIME-Version: 1.0 To: Jacques-Olivier Haenni CC: Peng Zhao , pro64-support@oss.sgi.com Subject: Re: Assembler messages in cross-compilation of pro64 References: <3A96EBC9.14A2C31@sgi.com> <3A97A9CE.FF34BAEF@epfl.ch> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-pro64-support@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;pro64-support-outgoing Jacques-Olivier Haenni wrote: > > Hi, > > Chandrasekhar Murthy wrote: > > > > It is a bug in g++. > > It was reported by Jacques-Olivier Haenni > > > > on Jan 22. > > For more details, look at : > http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=24685 > > When I faced this ipa compilation problem a few weeks ago, I have also been > told the following : > > > I am not sure why you are trying to build ipa. > > All components necessary for using ipa have not yet > > been released. > > You should maybe reconsider the pertinence of rebuilding ipa yourself. > We do a clean build of all compiler modules (except assembler and ld/ipa_link) on a nightly basis, and I don't remember getting this error with the building of the cross compiler. I will check with the build group. Murthy From owner-pro64-support@oss.sgi.com Mon Feb 26 15:02:52 2001 Received: by oss.sgi.com id ; Mon, 26 Feb 2001 15:02:45 -0800 Received: from sirius.astro.uiuc.edu ([128.174.51.24]:16106 "EHLO sirius.astro.uiuc.edu") by oss.sgi.com with ESMTP id ; Mon, 26 Feb 2001 15:02:30 -0800 Received: from astro.uiuc.edu (crutch.astro.uiuc.edu [128.174.51.23]) by sirius.astro.uiuc.edu (8.11.0/8.11.0) with ESMTP id f1QN2Th22043 for ; Mon, 26 Feb 2001 17:02:29 -0600 (CST) Message-ID: <3A9AE1AD.D5DB06BE@astro.uiuc.edu> Date: Mon, 26 Feb 2001 15:07:25 -0800 From: Paulo Cortes X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: "pro64-support@oss.sgi.com" Subject: internal compiler error Content-Type: multipart/mixed; boundary="------------329DCF3D0695CEA971828AC4" Sender: owner-pro64-support@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;pro64-support-outgoing This is a multi-part message in MIME format. --------------329DCF3D0695CEA971828AC4 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi guys I am getting and internal compiler error using the pro-64. Not a clue yet why. An additional question. Is there a list of known bugs? I couldnt find it at the sgi site. [aips2mgr@titan161 /proc]$ uname -a Linux titan161.ncsa.uiuc.edu 2.4.0test10-001115-57smp #1 SMP Tue Dec 5 18:04:33 PST 2000 ia64 unknown [aips2mgr@titan161 /proc]$ sgicc -version SGIcc Compilers: Version 0.01.0-12 Many thanks in advance Paulo -- ------------------------------------------------------------ "There is no Heaven without a Hell" Paulo Cortes Ingeniero Civil en Computacion Graduate student Astronomy Department University of Illinois RA National Center For Supercomputing Applications cortes@astro.uiuc.edu (217) 3337957 --------------329DCF3D0695CEA971828AC4 Content-Type: application/x-unknown-content-type-txtfile; name="gmake.log" Content-Transfer-Encoding: base64 Content-Disposition: inline; filename="gmake.log" Z21ha2U6ICoqKiBXYXJuaW5nOiBGaWxlIGAvaG9tZS9haXBzMm1nci9kYWlseS9jb2RlL2Fp cHMvaW1wbGVtZW50L0lucHV0cycgaGFzIG1vZGlmaWNhdGlvbiB0aW1lIGluIHRoZSBmdXR1 cmUgKDIwMDEtMDItMjAgMTE6MDY6MDMgPiAyMDAxLTAyLTIwIDExOjA1OjQ5KQoKZ21ha2Vb MF06IGdtYWtlIC1DIHRlc3QgYWxsc3lzCmdtYWtlWzFdOiBOb3RoaW5nIHRvIGJlIGRvbmUg Zm9yIGBhbGxzeXMnLgoKQmVnaW4gbGlicmFyeSByZWJ1aWxkClR1ZSAyMDAxLzAyLzIwIDEx OjA1OjQ5IENTVAoKT3B0aW1pemVkIGNvbXBpbGUgY29tbWFuZCBpczoKc2dpQ0MgLURfX2Nw bHVzcGx1cyAgIC13IC1EQUlQU19MSU5VWCAtREFJUFNfTElUVExFX0VORElBTiAtRE5BVElW RV9FWENQIC1JL2hvbWUvYWlwczJtZ3IvZGFpbHkvY29kZS9pbmNsdWRlIC1JLiAtTzIgLWZQ SUMgIC1EU0dJNjQgLURBSVBTX1VTRV9PTERfQ09NUExFWCAtREFJUFNfTk9fTEVBX01BTExP QyAtREFJUFNfSUE2NCAtcGlwZSAtV3JldHVybi10eXBlIC1XaW1wbGljaXQgLWMgPz8/LmNj OwoKSW5wdXQgKG9wdCkKL2hvbWUvYWlwczJtZ3IvZGFpbHkvY29kZS9haXBzL2ltcGxlbWVu dC9JbnB1dHMvSW5wdXQuY2M6NTAwOiBJbnRlcm5hbCBjb21waWxlciBlcnJvci4KL2hvbWUv YWlwczJtZ3IvZGFpbHkvY29kZS9haXBzL2ltcGxlbWVudC9JbnB1dHMvSW5wdXQuY2M6NTAw OiBQbGVhc2Ugc3VibWl0IGEgZnVsbCBidWcgcmVwb3J0LgovaG9tZS9haXBzMm1nci9kYWls eS9jb2RlL2FpcHMvaW1wbGVtZW50L0lucHV0cy9JbnB1dC5jYzo1MDA6IFNlZQo8VVJMOmh0 dHA6Ly93d3cuZ251Lm9yZy9zb2Z0d2FyZS9nY2MvYnVncy5odG1sPiBmb3IgaW5zdHJ1Y3Rp b25zLgpnbWFrZTogWy9ob21lL2FpcHMybWdyL2RhaWx5L2xpbnV4NjRfc2dpL3RtcC9haXBz L29wdC9JbnB1dC5sb2NrXSBFcnJvciAyIChpZ25vcmVkKQpUdWUgMjAwMS8wMi8yMCAxMTow NTo1OSBDU1QKCmdtYWtlOiB3YXJuaW5nOiAgQ2xvY2sgc2tldyBkZXRlY3RlZC4gIFlvdXIg YnVpbGQgbWF5IGJlIGluY29tcGxldGUuCg== --------------329DCF3D0695CEA971828AC4 Content-Type: text/plain; charset=us-ascii; name="Input.cc" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="Input.cc" //# Input.cc: A linked list of user input parameters //# Copyright (C) 1993,1994,1995,1996,1999,2000,2001 //# Associated Universities, Inc. Washington DC, USA. //# //# This library is free software; you can redistribute it and/or modify it //# under the terms of the GNU Library General Public License as published by //# the Free Software Foundation; either version 2 of the License, or (at your //# option) any later version. //# //# This library is distributed in the hope that it will be useful, but WITHOUT //# ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or //# FITNESS FOR A PARTICULAR PURPOSE. See the GNU Library General Public //# License for more details. //# //# You should have received a copy of the GNU Library General Public License //# along with this library; if not, write to the Free Software Foundation, //# Inc., 675 Massachusetts Ave, Cambridge, MA 02139, USA. //# //# Correspondence concerning AIPS++ should be addressed as follows: //# Internet email: aips2-request@nrao.edu. //# Postal address: AIPS++ Project Office //# National Radio Astronomy Observatory //# 520 Edgemont Road //# Charlottesville, VA 22903-2475 USA //# //# $Id: Input.cc,v 15.3 2001/02/07 02:36:05 wbrouw Exp $ // Class Input: the user interface #include #include #include #include #include #if defined(TESTBED) #define DEBUG 1 #endif // // The constructor does nothing more but read the users environment // and add appropriate things to the linked list of Param`s // This can be turned off by overriding the default `init' argument. // Input::Input (Int createEnv) : version_id("1999/07/30 BEG/TPPR/PJT/GvD"), is_closed(False), do_prompt(False), debug_level(0), p_count(0) { if (createEnv){ envCreate ("DEBUG", "debug", "0"); envCreate ("HELP" , "help", "0"); debug_level = getInt("debug"); if (debug(5)) { cout << "Input::Input: (debug=" << debug_level << ")\n"; } } else { create ("debug","0","Debug Level"); create ("help","0"); } } // Destructor Input::~Input() { if (debug(5)) { cout << "INPUT> Destructing " << count() << " parameters\n"; } } void Input::create (const String& key) { createPar (0, key, "", "", "", "", ""); } void Input::create (const String& key, const String& value) { createPar(0, key, value, "", "", "", ""); } void Input::create (const String& key, const String& value, const String& help) { createPar(0, key, value, help, "", "", ""); } void Input::create (const String& key, const String& value, const String& help, const String& type) { createPar(0, key, value, help, type, "", ""); } void Input::create (const String& key, const String& value, const String& help, const String& type, const String& range) { createPar(0, key, value, help, type, range, ""); } void Input::create (const String& key, const String& value, const String& help, const String& type, const String& range, const String& unit) { createPar(0, key, value, help, type, range, unit); } // CreatePar() is the workhorse function, it is a private member function void Input::createPar (Int system, const String& key, const String& value, const String& help, const String& type, const String& range, const String& unit) { if (is_closed) { String msg = "Input::createPar: " + key + ": Cannot create any more Parameters"; throw(AipsError(msg)); return; } int i = getParam(key); if (i!=0) { String msg = "Input:cCreatePar: " + key + ": Parameters already exists."; throw (AipsError(msg)); } if (key=="help") { if (value=="prompt") { do_prompt = True; } help_mode = value; } if (debug(5)) { cout << "Input::CreatePar: Creating new keyword " << key << "=" << value << "\n" << flush; } Param tmp(key,value,help,type,range,unit); if (system) { tmp.setSystem(True); } else { tmp.setIndex(++p_count); } ListIter parlist(parList_p); parlist.toStart(); while (!parlist.atEnd()) { ++parlist; } parlist.addRight(tmp); } void Input::close() { if (is_closed) { String msg = "Input::Close: parameter creation is already closed."; throw(AipsError(msg)); } else { is_closed = True; } if (debug(1)) { // Display Param as: 'key=val: help' cout << "INPUT> Closing parameter creation: \n"; cout << "INPUT> ----------------------------------------------------\n"; ListIter parlist(parList_p); parlist.toStart(); Int n=count(); for (Int i=0; i " << x.keyVal() << ": " << x.getHelp() << "\n"; } cout << "INPUT>-----------------------------------------------------\n" << flush; } } // Query functions Double Input::getDouble (const String& key) { Int i = getParam(key); if (i==0) { String msg ="Input::GetDouble: Parameter " + key + " is unknown."; throw (AipsError(msg)); } ListIter parlist(parList_p); parlist.toStart(); parlist.step(i-1); Param& x = parlist.getRight(); if (do_prompt && !x.isSystem()) { prompt(x); } return x.getDouble(); } Block Input::getDoubleArray (const String& key) { Int i = getParam(key); if (i==0) { String msg ="Input::GetDoubleArray: Parameter " + key + " is unknown."; throw (AipsError(msg)); } ListIter parlist(parList_p); parlist.toStart(); parlist.step(i-1); Param& x = parlist.getRight(); if (do_prompt && !x.isSystem()) { prompt(x); } return x.getDoubleArray(); } int Input::getInt (const String& key) { Int i = getParam(key); if (i==0) { String msg ="Input::GetInt: Parameter " + key + " is unknown."; throw (AipsError(msg)); } ListIter parlist(parList_p); parlist.toStart(); parlist.step(i-1); Param& x = parlist.getRight(); if (do_prompt && !x.isSystem()) { prompt(x); } return x.getInt(); } Block Input::getIntArray (const String& key) { Int i = getParam(key); if (i==0) { String msg ="Input::GetIntArray: Parameter " + key + " is unknown."; throw (AipsError(msg)); } ListIter parlist(parList_p); parlist.toStart(); parlist.step(i-1); Param& x = parlist.getRight(); if (do_prompt && !x.isSystem()) { prompt(x); } return x.getIntArray(); } String Input::getString (const String& key) { Int i = getParam(key); if (i==0) { String msg ="Input::GetString: Parameter " + key + " is unknown."; throw (AipsError(msg)); } ListIter parlist(parList_p); parlist.toStart(); parlist.step(i-1); Param& x = parlist.getRight(); if (do_prompt && !x.isSystem()) { prompt(x); } return x.getString(); } Bool Input::getBool (const String& key) { Int i = getParam(key); if (i==0) { String msg ="Input::GetBool: Parameter " + key + " is unknown."; throw (AipsError(msg)); } ListIter parlist(parList_p); parlist.toStart(); parlist.step(i-1); Param& x = parlist.getRight(); if (do_prompt && !x.isSystem()) { prompt(x); } return x.getBool(); } // Modifiers Bool Input::put (const String& key, const String& value) { String akey, avalue; if (debug(5)) { cout << "PUT> " << key << "=" << value << "\n"; } Int i = getParam(key); if (i==0) { String msg = "Input::Put: parameter " + key + " is unknown."; throw (AipsError(msg)); } ListIter parlist(parList_p); parlist.toStart(); parlist.step(i-1); Param& x = parlist.getRight(); x.put(value); return True; } Bool Input::put (const String& key) { String k = key; // Need non-const string if (!key.index("=")) { String msg = "Input::Put: " + key + " is not a valid parameter."; throw (AipsError(msg)); } return put (k.before("="), k.after("=")); } Int Input::count() const { ConstListIter parlist(parList_p); return parlist.len(); } void Input::version (const String& a_version) { version_id = a_version; } void Input::announce() { if (debug(5)) { cout << getString("argv0") << " "; ConstListIter parlist(parList_p); parlist.toStart(); Int n=count(); for (Int i=0; i 0) { cout << x << " "; } } cout << "\n"; } if (help_mode.contains("prompt")) { do_prompt = True; } if (help_mode.contains("pane")) { pane(); exit(0); } if (help_mode.contains("keys")) { keys(); } if (help_mode.contains("exit")) { exit(0); } if (version_id.length() > 0) { // Always announce ??? cout << getString("argv0") << ": Version " << version_id << "\n"; } } // Some private member functions we need // // Move to the current named Parameter; return 0 if none found // A value >= 1 is the index (not used in K_ stuff) // Int Input::getParam (const String& name) const { Int n = count(); if (n <= 0) { return n; } ConstListIter parlist(parList_p); parlist.toStart(); for (Int i=0; i parlist(parList_p); parlist.toStart(); for (Int i=0; i parlist(parList_p); parlist.toStart(); for (Int i=0; i " << p_count << " program parameters\n"; } close(); // close creation // Show version on screen if -v or --version is given. if (av[1] && (String(av[1]) == "-v" || String(av[1]) == "--version")) { cerr << av[0] << " version " << version_id << endl; exit (1); } // Show parameters on screen if -h or --help given. if (av[1] && (String(av[1]) == "-h" || String(av[1]) == "--help")) { cerr << av[0] << " version " << version_id << endl; ConstListIter parlist(parList_p); for (parlist.toStart(); ! parlist.atEnd(); parlist++) { const Param& x = parlist.getRight(); if (x.getIndex() > 0) { cerr << x.getKey() << ", " << x.getType() << ", "; if (String(x.get()) != "") { cerr << '(' << x.get() << ')'; } cerr << endl; if (String(x.getHelp()) != "") { cerr << " " << x.getHelp() << endl; } } } exit (1); } // Turn khoros style command inputs into keyword=value inputs // ' -channels 64' becomes 'channels=64' String thisarg; String keyandval; // Pass through keyword=value and turn -keyword value into keyword=value for (i=1; i= ac - 1) { throw(AipsError("Input::ReadArguments:" "-keyword not followed by value")); } i++; // Advance keyandval = thisarg.after("-") + "=" + av[i]; } else { keyandval = thisarg; } // cout << "putting " << keyandval << endl; put (keyandval); // Insert command line parameters if (keyandval.before("=") == "debug") { debug_level = atoi(keyandval.after("=").chars()); } else if (keyandval.before("=")=="help") { help_mode = keyandval.after("="); } } announce(); // Announce and possibly die here } Vector Input::makeMaskFromRanges(const String& ranges, uInt length, Bool oneRelative) { Regex single("^[ \t]*[0-9]+[ \t]*$", 1); Regex range("^[ \t]*[0-9]+[ \t]*-[ \t]*[0-9]+[ \t]*$", 1); Vector mask(length); mask = False; // Step through the string, comma separated expression by comma separated // expression. Int numberOfCommas = ranges.freq(","); Block expressions(numberOfCommas + 1); split (ranges, expressions.storage(), numberOfCommas + 1, ","); for (uInt i=0; i < expressions.nelements(); i++) { // Validate if (expressions[i].contains(single) == False && expressions[i].contains(range) == False) { throw (AipsError(String("Input::makeMaskFromRanges - " "invalid range:") + expressions[i])); } Int left, right; if (expressions[i].contains("-")) { left = atoi(expressions[i].before("-").chars()); right = atoi(expressions[i].after("-").chars()); } else { left = right = atoi(expressions[i].chars()); } if (oneRelative) { left -= 1; right -= 1; } if (left + 1 > Int(mask.nelements()) || right + 1 > Int(mask.nelements()) || left > right) { throw (AipsError(String("Input::makeMaskFromRanges - " "out of range or end; Mon, 26 Feb 2001 15:58:33 -0800 Received: from sirius.astro.uiuc.edu ([128.174.51.24]:21492 "EHLO sirius.astro.uiuc.edu") by oss.sgi.com with ESMTP id ; Mon, 26 Feb 2001 15:58:26 -0800 Received: from astro.uiuc.edu (crutch.astro.uiuc.edu [128.174.51.23]) by sirius.astro.uiuc.edu (8.11.0/8.11.0) with ESMTP id f1QNwPh23379 for ; Mon, 26 Feb 2001 17:58:25 -0600 (CST) Message-ID: <3A9AEEC9.A001E9A5@astro.uiuc.edu> Date: Mon, 26 Feb 2001 16:03:21 -0800 From: Paulo Cortes X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: "pro64-support@oss.sgi.com" Subject: internal compiler error Content-Type: multipart/mixed; boundary="------------A85C4F769D93434A17992473" Sender: owner-pro64-support@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;pro64-support-outgoing This is a multi-part message in MIME format. --------------A85C4F769D93434A17992473 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sorry I missed some info. Paulo -- ------------------------------------------------------------ "Al final del juego el peon y el rey vuelven a la misma caja" Paulo Cortes Ingeniero Civil en Computacion Graduate student Astronomy Department University of Illinois RA National Center For Supercomputing Applications cortes@astro.uiuc.edu (217) 3337957 --------------A85C4F769D93434A17992473 Content-Type: application/x-unknown-content-type-txtfile; name="gmake.log" Content-Transfer-Encoding: base64 Content-Disposition: inline; filename="gmake.log" Z21ha2U6ICoqKiBXYXJuaW5nOiBGaWxlIGAvaG9tZS9haXBzMm1nci9kYWlseS9jb2RlL2Fp cHMvaW1wbGVtZW50L0lucHV0cy9JbnB1dC5oJyBoYXMgbW9kaWZpY2F0aW9uIHRpbWUgaW4g dGhlIGZ1dHVyZSAoMjAwMS0wMi0yNiAxNzo1Mzo0OSA+IDIwMDEtMDItMjYgMTc6NTM6MzMp DQoNCk1vbiAyMDAxLzAyLzI2IDE3OjUzOjM0IENTVA0KZGVwZW5kOiBHZW5lcmF0aW5nIGRl cGVuZGVuY2llcyBmb3IgYWlwcy1JbnB1dHMuLi4NCiAgICAgICAgSW5wdXQuY2MNCnNnaUND IEVSUk9SOiAgY2Fubm90IGV4ZWMgL3Vzci9saWIvZ2NjLWxpYi9pYTY0LXNnaS1saW51eC9z Z2ljYy0xLjAvY3BwDQpVcGRhdGluZyB0aGUgZGVwZW5kZW5jeSBsaXN0IChhaXBzMm1nckB0 aXRhbjE2MToyNTE5MikuLi4NCkRlcGVuZGVuY3kgbGlzdCB1cGRhdGVkIChhaXBzMm1nckB0 aXRhbjE2MToyNTE5MikuDQpNb24gMjAwMS8wMi8yNiAxNzo1MzozNCBDU1QNCmdtYWtlOiAq KiogV2FybmluZzogRmlsZSBgL2hvbWUvYWlwczJtZ3IvZGFpbHkvbGludXg2NF9zZ2kvYXV4 L2FpcHMtSW5wdXRzLmxpc3QnIGhhcyBtb2RpZmljYXRpb24gdGltZSBpbiB0aGUgZnV0dXJl ICgyMDAxLTAyLTI2IDE3OjU0OjA1ID4gMjAwMS0wMi0yNiAxNzo1MzozNSkNCg0KZ21ha2Vb MF06IGdtYWtlIC1DIHRlc3QgYWxsc3lzDQpnbWFrZVsxXTogTm90aGluZyB0byBiZSBkb25l IGZvciBgYWxsc3lzJy4NCg0KQmVnaW4gbGlicmFyeSByZWJ1aWxkDQpNb24gMjAwMS8wMi8y NiAxNzo1MzozNSBDU1QNCg0KT3B0aW1pemVkIGNvbXBpbGUgY29tbWFuZCBpczoNCnNnaUND IC1EX19jcGx1c3BsdXMgICAtdyAtREFJUFNfTElOVVggLURBSVBTX0xJVFRMRV9FTkRJQU4g LUROQVRJVkVfRVhDUCAtSS9ob21lL2FpcHMybWdyL2RhaWx5L2NvZGUvaW5jbHVkZSAtSS4g LU8yIC1mUElDICAtRFNHSTY0IC1EQUlQU19VU0VfT0xEX0NPTVBMRVggLURBSVBTX05PX0xF QV9NQUxMT0MgLURBSVBTX0lBNjQgLXBpcGUgLVdyZXR1cm4tdHlwZSAtV2ltcGxpY2l0IC1j ID8/Py5jYzsNCg0KSW5wdXQgKG9wdCkNCi9ob21lL2FpcHMybWdyL2RhaWx5L2NvZGUvYWlw cy9pbXBsZW1lbnQvSW5wdXRzL0lucHV0LmNjOjUwMzogSW50ZXJuYWwgY29tcGlsZXIgZXJy b3IuDQovaG9tZS9haXBzMm1nci9kYWlseS9jb2RlL2FpcHMvaW1wbGVtZW50L0lucHV0cy9J bnB1dC5jYzo1MDM6IFBsZWFzZSBzdWJtaXQgYSBmdWxsIGJ1ZyByZXBvcnQuDQovaG9tZS9h aXBzMm1nci9kYWlseS9jb2RlL2FpcHMvaW1wbGVtZW50L0lucHV0cy9JbnB1dC5jYzo1MDM6 IFNlZQ0KPFVSTDpodHRwOi8vd3d3LmdudS5vcmcvc29mdHdhcmUvZ2NjL2J1Z3MuaHRtbD4g Zm9yIGluc3RydWN0aW9ucy4NCmdtYWtlOiBbL2hvbWUvYWlwczJtZ3IvZGFpbHkvbGludXg2 NF9zZ2kvdG1wL2FpcHMvb3B0L0lucHV0LmxvY2tdIEVycm9yIDIgKGlnbm9yZWQpDQpNb24g MjAwMS8wMi8yNiAxNzo1Mzo0NSBDU1Q= --------------A85C4F769D93434A17992473-- From owner-pro64-support@oss.sgi.com Mon Feb 26 18:46:54 2001 Received: by oss.sgi.com id ; Mon, 26 Feb 2001 18:46:45 -0800 Received: from hypnos.cps.intel.com ([192.198.165.17]:51914 "EHLO hypnos.cps.intel.com") by oss.sgi.com with ESMTP id ; Mon, 26 Feb 2001 18:46:25 -0800 Received: from SMTP (fmsmsxvs04-1.fm.intel.com [132.233.42.204]) by hypnos.cps.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.35 2001/02/12 09:03:45 smothers Exp $) with SMTP id XAA13389; Mon, 26 Feb 2001 23:18:26 GMT Received: from fmsmsx27.FM.INTEL.COM ([132.233.48.27]) by 132.233.48.204 (Norton AntiVirus for Internet Email Gateways 1.0) ; Mon, 26 Feb 2001 23:18:25 0000 (GMT) Received: by fmsmsx27.fm.intel.com with Internet Mail Service (5.5.2650.21) id <17DP2WV1>; Mon, 26 Feb 2001 15:18:24 -0800 Message-ID: <9287DC1579B0D411AA2F009027F44C3F042DF8C3@FMSMSX41> From: "Chan, Sun C" To: "'Paulo Cortes'" , pro64-support@oss.sgi.com Subject: RE: internal compiler error Date: Mon, 26 Feb 2001 15:18:20 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-pro64-support@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;pro64-support-outgoing I suggest you preprocess your input file. It has as include files. Then try to minimize the input file while keeping the problem reproducible. The "internal compiler error" message will not get anyone very far to help you. Also, try to compile it using vanilla gcc, this will tell you whether its a Pro64 problem or gcc problem. Sun -----Original Message----- From: Paulo Cortes [mailto:cortes@astro.uiuc.edu] Sent: Monday, February 26, 2001 3:07 PM To: pro64-support@oss.sgi.com Subject: internal compiler error Hi guys I am getting and internal compiler error using the pro-64. Not a clue yet why. An additional question. Is there a list of known bugs? I couldnt find it at the sgi site. [aips2mgr@titan161 /proc]$ uname -a Linux titan161.ncsa.uiuc.edu 2.4.0test10-001115-57smp #1 SMP Tue Dec 5 18:04:33 PST 2000 ia64 unknown [aips2mgr@titan161 /proc]$ sgicc -version SGIcc Compilers: Version 0.01.0-12 Many thanks in advance Paulo -- ------------------------------------------------------------ "There is no Heaven without a Hell" Paulo Cortes Ingeniero Civil en Computacion Graduate student Astronomy Department University of Illinois RA National Center For Supercomputing Applications cortes@astro.uiuc.edu (217) 3337957 From owner-pro64-support@oss.sgi.com Tue Feb 27 09:38:41 2001 Received: by oss.sgi.com id ; Tue, 27 Feb 2001 09:38:31 -0800 Received: from lslsun.epfl.ch ([128.178.150.20]:4300 "EHLO lslsun.epfl.ch") by oss.sgi.com with ESMTP id ; Tue, 27 Feb 2001 09:38:14 -0800 Received: from epfl.ch (johaenni@lslsun8 [128.178.150.31]) by lslsun.epfl.ch (8.8.X/EPFL-8.1a) with ESMTP id SAA10273; Tue, 27 Feb 2001 18:38:01 +0100 (MET) Message-ID: <3A9BE5F7.C982AF58@epfl.ch> Date: Tue, 27 Feb 2001 18:37:59 +0100 From: Jacques-Olivier Haenni Organization: Swiss Federal Institute of Technology, Lausanne (EPFL) X-Mailer: Mozilla 4.75 [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en, fr-CH, fr MIME-Version: 1.0 To: pro64-contrib@oss.sgi.com, pro64-support@oss.sgi.com Subject: Adding support for multimedia (SIMD) instructions Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-pro64-support@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;pro64-support-outgoing Hi ! I would like to add support for Itanium multimedia instructions into SGI Pro64 compiler. My aim would be the compiler to be able to generate multimedia instructions for inner loop without any help from the programmer. In order to evaluate the feasibility and the complexity of this work, I would like to ask you some questions. First of all, is somebody already working on this ? Here are some reflections you may comment about: - The "conversion" of scalar to multimedia operations should be performed before the conversion of WHIRL code to OPs (Convert_WHIRL_To_OPs). During this conversion, the sizes of the operands (8-, 16-, 32- or 64-bit) are lost; this information seems me primordial for finding candidate loops for parallelization. - The backend already knows multimedia instructions; one "just" has to generate such instructions while WHIRL to OPs conversion. This mainly involves inner loop detection, dependence analysis, memory reference disambiguation. Does anybody have any ideas about the complexity of this task ? Do you know where I could find documentation about whirl to ops conversion and loop manipulation in Pro64 (I already have the file 'whirl.pdf' from the Web) ? Any hint, any clue or any idea about this topic are very welcome. Thanks in advance for your reactions, Jacques-Olivier -- Jacques-Olivier Haenni http://lslwww.epfl.ch/~johaenni/ Jacques-Olivier.Haenni@epfl.ch Logic Systems Laboratory Swiss Federal Institute of Technology (EPFL) | Tel: (+41 21) 693 66 30 1015 Lausanne - Switzerland | Fax: (+41 21) 693 37 05 From owner-pro64-support@oss.sgi.com Tue Feb 27 12:25:44 2001 Received: by oss.sgi.com id ; Tue, 27 Feb 2001 12:25:34 -0800 Received: from [38.170.141.29] ([38.170.141.29]:31477 "EHLO mail-in.hq.tensilica.com") by oss.sgi.com with ESMTP id ; Tue, 27 Feb 2001 12:25:29 -0800 Received: from sonata.hq.tensilica.com (IDENT:root@sonata.hq.tensilica.com [192.168.10.17]) by mail-in.hq.tensilica.com (8.9.3/8.9.3) with ESMTP id MAA06491; Tue, 27 Feb 2001 12:25:28 -0800 Received: from gobi-pc ([192.168.11.121]) by sonata.hq.tensilica.com (8.8.7/8.8.7) with SMTP id MAA10075; Tue, 27 Feb 2001 12:25:28 -0800 Message-ID: <008301c0a0fa$dfed4170$790ba8c0@gobi-pc.hq.tensilica.com> From: "Peng Tu" To: "Jacques-Olivier Haenni" , , Subject: Re: Adding support for multimedia (SIMD) instructions Date: Tue, 27 Feb 2001 12:21:32 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.3110.5 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 Sender: owner-pro64-support@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;pro64-support-outgoing The loop optimizations in Pro64 is under 'be/lno' directory. The LNO is on under -O3. The LNO performs loop detection, dependence analysis etc. The IR for LNO is WHIRL. You may want to do all your analysis in LNO and generate multimedia instructions by: (1) Either expand the WHIRL to include the multimedia instructions, or expand the build-in data types to support multimedia data types so you can reuse the same WHIRL nodes/operators. (2) Expand convert WHIRL to OPs to generate the multimedia instructions. Depending on how good a job you want to do, it can take from 3 months to 3 years I guess :-) Peng. -----Original Message----- From: Jacques-Olivier Haenni To: pro64-contrib@oss.sgi.com ; pro64-support@oss.sgi.com Date: Tuesday, February 27, 2001 9:39 AM Subject: Adding support for multimedia (SIMD) instructions >Hi ! > >I would like to add support for Itanium multimedia instructions into SGI Pro64 >compiler. My aim would be the compiler to be able to generate multimedia >instructions for inner loop without any help from the programmer. > >In order to evaluate the feasibility and the complexity of this work, I would >like to ask you some questions. > >First of all, is somebody already working on this ? > >Here are some reflections you may comment about: > >- The "conversion" of scalar to multimedia operations should be performed >before the conversion of WHIRL code to OPs (Convert_WHIRL_To_OPs). During this >conversion, the sizes of the operands (8-, 16-, 32- or 64-bit) are lost; this >information seems me primordial for finding candidate loops for >parallelization. > >- The backend already knows multimedia instructions; one "just" has to generate >such instructions while WHIRL to OPs conversion. This mainly involves inner >loop detection, dependence analysis, memory reference disambiguation. > >Does anybody have any ideas about the complexity of this task ? > >Do you know where I could find documentation about whirl to ops conversion and >loop manipulation in Pro64 (I already have the file 'whirl.pdf' from the Web) ? > >Any hint, any clue or any idea about this topic are very welcome. > >Thanks in advance for your reactions, > >Jacques-Olivier > >-- > Jacques-Olivier Haenni http://lslwww.epfl.ch/~johaenni/ > Jacques-Olivier.Haenni@epfl.ch >Logic Systems Laboratory >Swiss Federal Institute of Technology (EPFL) | Tel: (+41 21) 693 66 30 >1015 Lausanne - Switzerland | Fax: (+41 21) 693 37 05 From owner-pro64-support@oss.sgi.com Tue Feb 27 13:02:14 2001 Received: by oss.sgi.com id ; Tue, 27 Feb 2001 13:01:55 -0800 Received: from deliverator.sgi.com ([204.94.214.10]:66 "EHLO deliverator.sgi.com") by oss.sgi.com with ESMTP id ; Tue, 27 Feb 2001 13:01:52 -0800 Received: from gaea.engr.sgi.com (gaea.engr.sgi.com [130.62.180.97]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id NAA00416; Tue, 27 Feb 2001 13:00:46 -0800 (PST) mail_from (murthy@sgi.com) Received: from sgi.com (localhost [127.0.0.1]) by gaea.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) via ESMTP id MAA45390; Tue, 27 Feb 2001 12:53:45 -0800 (PST) Message-ID: <3A9C13D9.E4C13E77@sgi.com> Date: Tue, 27 Feb 2001 12:53:45 -0800 From: Chandrasekhar Murthy X-Mailer: Mozilla 4.51C-SGI [en] (X11; I; IRIX 6.5 IP32) X-Accept-Language: en MIME-Version: 1.0 To: Peng Tu CC: Jacques-Olivier Haenni , pro64-contrib@oss.sgi.com, pro64-support@oss.sgi.com Subject: Re: Adding support for multimedia (SIMD) instructions References: <008301c0a0fa$dfed4170$790ba8c0@gobi-pc.hq.tensilica.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-pro64-support@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;pro64-support-outgoing Peng Tu wrote: > > The loop optimizations in Pro64 is under 'be/lno' directory. The LNO is on > under > -O3. The LNO performs loop detection, dependence analysis etc. The IR for > LNO > is WHIRL. You may want to do all your analysis in LNO and generate > multimedia > instructions by: > > (1) Either expand the WHIRL to include the multimedia instructions, or > expand the > build-in data types to support multimedia data types so you can reuse the > same > WHIRL nodes/operators. > (2) Expand convert WHIRL to OPs to generate the multimedia instructions. > > Depending on how good a job you want to do, it can take from 3 months to 3 > years > I guess :-) > > Peng. > > -----Original Message----- > From: Jacques-Olivier Haenni > To: pro64-contrib@oss.sgi.com ; > pro64-support@oss.sgi.com > Date: Tuesday, February 27, 2001 9:39 AM > Subject: Adding support for multimedia (SIMD) instructions > > >Hi ! > > > >I would like to add support for Itanium multimedia instructions into SGI > Pro64 > >compiler. My aim would be the compiler to be able to generate multimedia > >instructions for inner loop without any help from the programmer. > > > >In order to evaluate the feasibility and the complexity of this work, I > would > >like to ask you some questions. > > > >First of all, is somebody already working on this ? > > > >Here are some reflections you may comment about: > > > >- The "conversion" of scalar to multimedia operations should be performed > >before the conversion of WHIRL code to OPs (Convert_WHIRL_To_OPs). During > this > >conversion, the sizes of the operands (8-, 16-, 32- or 64-bit) are lost; > this > >information seems me primordial for finding candidate loops for > >parallelization. > > > >- The backend already knows multimedia instructions; one "just" has to > generate > >such instructions while WHIRL to OPs conversion. This mainly involves > inner > >loop detection, dependence analysis, memory reference disambiguation. > > > >Does anybody have any ideas about the complexity of this task ? > > > >Do you know where I could find documentation about whirl to ops conversion > and > >loop manipulation in Pro64 (I already have the file 'whirl.pdf' from the > Web) ? > > > >Any hint, any clue or any idea about this topic are very welcome. > > > >Thanks in advance for your reactions, > > > >Jacques-Olivier > > > >-- > > Jacques-Olivier Haenni http://lslwww.epfl.ch/~johaenni/ > > Jacques-Olivier.Haenni@epfl.ch > >Logic Systems Laboratory > >Swiss Federal Institute of Technology (EPFL) | Tel: (+41 21) 693 66 30 > >1015 Lausanne - Switzerland | Fax: (+41 21) 693 37 05 To minimize the impact on the rest of the compiler, you might consider treating the multimedia instructions as intrinsic ops rather than WHIRL ops. Murthy From owner-pro64-support@oss.sgi.com Tue Feb 27 23:29:58 2001 Received: by oss.sgi.com id ; Tue, 27 Feb 2001 23:29:38 -0800 Received: from hitpro.hitachi.co.jp ([133.145.224.7]:33997 "EHLO hitpro.hitachi.co.jp") by oss.sgi.com with ESMTP id ; Tue, 27 Feb 2001 23:29:18 -0800 Received: from newton.ebina.hitachi.co.jp by hitpro.hitachi.co.jp (8.9.3/3.7W-hitpro) id QAA08557; Wed, 28 Feb 2001 16:29:15 +0900 (JST) Received: from pcd0.ebina.hitachi.co.jp (root@pcd0.ebina.hitachi.co.jp [158.214.169.211]) by newton.ebina.hitachi.co.jp (8.9.0/3.7W-EBINA) with ESMTP id QAA01445 for ; Wed, 28 Feb 2001 16:29:14 +0900 (JST) Received: from one6117 ([172.16.81.8]) by pcd0.ebina.hitachi.co.jp (8.9.3/3.7W-EBINA-local) with SMTP id QAA05521; Wed, 28 Feb 2001 16:29:13 +0900 (JST) Message-Id: <4.0.1-J.20010228162228.00e6c7b0@pop-pcd0.ebina.hitachi.co.jp> X-Sender: mikiko@ebina.hitachi.co.jp X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0.1-J Date: Wed, 28 Feb 2001 16:26:43 +0900 To: pro64-support@oss.sgi.com From: Mikiko Sato Subject: error message Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-pro64-support@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;pro64-support-outgoing When I use sgif90, error message occured but created a.out. (1) Please instruct us how to search your support mail archive. (2) Our error message is following. May I ignore? /usr/lib/gcc-lib/ia64-cygnus-linux/2.96-ia64-000717/../../../libfortran.a(op en.o):../../libf/fio/open.c:905: the use of `tempnam' is dangerous, better u se `mkstemp' (3) Our platform are following - Lion 1P B1 stepping, BIOS 1063B - Linux asc-sdv09 2.4.0-010109-61smp #1 SMP Fri Jan 12 16:23:38 PST 2001 ia6 4 unknown - SGIcc Compilers: Version 0.01.0-12 Best regards, Mikiko Sato -------- Mikiko Sato (mikiko@ebina.hitachi.co.jp) Hitachi,Ltd, Hitachi ASC(Application Solution Center) 810 Shimoimaizumi Ebina-shi, Kanagawa-ken, 243-0435 Japan Tel:+81-46-235-7506 From owner-pro64-support@oss.sgi.com Wed Feb 28 07:10:40 2001 Received: by oss.sgi.com id ; Wed, 28 Feb 2001 07:10:30 -0800 Received: from pneumatic-tube.sgi.com ([204.94.214.22]:64071 "EHLO pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP id ; Wed, 28 Feb 2001 07:10:14 -0800 Received: from gaea.engr.sgi.com (gaea.engr.sgi.com [130.62.180.97]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id HAA03084 for ; Wed, 28 Feb 2001 07:19:50 -0800 (PST) mail_from (murthy@gaea.engr.sgi.com) Received: (from murthy@localhost) by gaea.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) id HAA74723; Wed, 28 Feb 2001 07:03:02 -0800 (PST) Date: Wed, 28 Feb 2001 07:03:02 -0800 (PST) From: murthy@gaea.engr.sgi.com (Chandrasekhar Murthy) Message-Id: <200102281503.HAA74723@gaea.engr.sgi.com> To: pro64-support@oss.sgi.com, Mikiko Sato Subject: Re: error message Sender: owner-pro64-support@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;pro64-support-outgoing > (2) Our error message is following. May I ignore? Yes. Murthy From owner-pro64-support@oss.sgi.com Wed Feb 28 15:01:33 2001 Received: by oss.sgi.com id ; Wed, 28 Feb 2001 15:01:13 -0800 Received: from [38.170.141.29] ([38.170.141.29]:10485 "EHLO mail-in.hq.tensilica.com") by oss.sgi.com with ESMTP id ; Wed, 28 Feb 2001 15:00:57 -0800 Received: from tensilica.com (IDENT:jonhsu@leo-home.hq.tensilica.com [192.168.10.103]) by mail-in.hq.tensilica.com (8.9.3/8.9.3) with ESMTP id PAA29221 for ; Wed, 28 Feb 2001 15:00:56 -0800 Message-ID: <3A9D8327.D21132E1@tensilica.com> Date: Wed, 28 Feb 2001 15:00:55 -0800 From: John Hsu X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.16-3 i686) X-Accept-Language: en MIME-Version: 1.0 To: pro64-support@oss.sgi.com Subject: min bug Content-Type: multipart/mixed; boundary="------------8CB61E3B2A78B96FF75C247C" Sender: owner-pro64-support@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;pro64-support-outgoing This is a multi-part message in MIME format. --------------8CB61E3B2A78B96FF75C247C Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit I'm having problems with a test case that's been simplified from code that uses the min() template function in the algorithm header: > sgiCC -O2 min.cpp > a.out 456048 <-- should be 4 We suspect that the front end is generating incorrect code, which causes the optimizer to delete stores that it thinks are unnecessary because they only affect local variables. --------------8CB61E3B2A78B96FF75C247C Content-Type: text/plain; charset=us-ascii; name="min.cpp" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="min.cpp" #include const int& min(const int& __a, const int& __b) { return __b < __a ? __b : __a; } int j=4, k=7; void main() { int i = min(j,k); cout << i << endl; } --------------8CB61E3B2A78B96FF75C247C-- From owner-pro64-support@oss.sgi.com Wed Feb 28 15:36:13 2001 Received: by oss.sgi.com id ; Wed, 28 Feb 2001 15:36:03 -0800 Received: from pneumatic-tube.sgi.com ([204.94.214.22]:45323 "EHLO pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP id ; Wed, 28 Feb 2001 15:35:47 -0800 Received: from gaea.engr.sgi.com (gaea.engr.sgi.com [130.62.180.97]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id PAA00888 for ; Wed, 28 Feb 2001 15:45:23 -0800 (PST) mail_from (murthy@gaea.engr.sgi.com) Received: (from murthy@localhost) by gaea.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) id PAA85520; Wed, 28 Feb 2001 15:28:28 -0800 (PST) Date: Wed, 28 Feb 2001 15:28:28 -0800 (PST) From: murthy@gaea.engr.sgi.com (Chandrasekhar Murthy) Message-Id: <200102282328.PAA85520@gaea.engr.sgi.com> To: pro64-support@oss.sgi.com, John Hsu Subject: Re: min bug Sender: owner-pro64-support@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;pro64-support-outgoing > We suspect that the front end is generating incorrect code. It appears to be a frontend problem. I will take a look. Murthy