From owner-pro64-support@oss.sgi.com Fri Nov  3 02:46:37 2000
Received:  by oss.sgi.com id <S553821AbQKCKq1>;
	Fri, 3 Nov 2000 02:46:27 -0800
Received: from probity.mcc.ac.uk ([130.88.200.94]:27144 "EHLO
        probity.mcc.ac.uk") by oss.sgi.com with ESMTP id <S553811AbQKCKqH>;
	Fri, 3 Nov 2000 02:46:07 -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 13reMH-000Pa5-00
	for pro64-support@oss.sgi.com; Fri, 3 Nov 2000 10:46:05 +0000
Message-ID: <3A0296A8.C885BAB5@man.ac.uk>
Date:   Fri, 03 Nov 2000 10:42:48 +0000
From:   Dan Kidger <d.kidger@man.ac.uk>
Organization: Manchester Computing
X-Mailer: Mozilla 4.6 [en] (Win98; I)
X-Accept-Language: en
MIME-Version: 1.0
To:     pro64-support@oss.sgi.com
Subject: Sgicc compiler crash
Content-Type: multipart/mixed;
 boundary="------------C46AA6A020A2A52FCBA701B9"
Sender: owner-pro64-support@oss.sgi.com
Precedence: bulk
Return-Path: <owner-pro64-support@oss.sgi.com>
X-Orcpt: rfc822;pro64-support-outgoing

This is a multi-part message in MIME format.
--------------C46AA6A020A2A52FCBA701B9
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit


Dear all,

I am having troubling building the ATLAS libraries on the IA64


$ uname -a
Linux fourier1 2.4.0test8-000913-44smp #1 SMP Tue Oct 3 23:29:59 PDT 2000 ia64
unknown
$ sgicc -v
SGIcc Compilers: Version 0.01.0-11


$ cd /lhome/zzcgudk/ATLAS/tune/blas/gemm/SGICC_IA64
$ sgicc -O2 -c dmm.c

Signal: Segmentation fault in Hyberlock Scheduler phase.
Error: Signal Segmentation fault in phase Hyberlock Scheduler -- processing
aborted
sgicc ERROR:  /usr/lib/gcc-lib/ia64-sgi-linux/sgicc-1.0/be died due to signal
4
sgicc ERROR:  core dumped


It works with -O1 or -O0 and also with gcc.

Code is attached. dmm.c (329 lines)

It is a 60x60 matrix multiply that has been unrolled. The source is generated
automatically by the ATLAS install.



Yours,
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
Manchester, M13 9PL, United Kingdom.            | F:   +44 161 275 6800
--------------------Q: what's up ?   A: Z cross X ---------------------
--------------C46AA6A020A2A52FCBA701B9
Content-Type: application/x-unknown-content-type-c_auto_file;
 name="dmm.c"
Content-Transfer-Encoding: base64
Content-Disposition: inline;
 filename="dmm.c"

dm9pZCBBVExfZEpJSzYweDYweDYwVE42MHg2MHgwX2ExX2IxDQogICAoY29uc3QgaW50IE0s
IGNvbnN0IGludCBOLCBjb25zdCBpbnQgSywgY29uc3QgZG91YmxlIGFscGhhLCBjb25zdCBk
b3VibGUgKkEsIGNvbnN0IGludCBsZGEsIGNvbnN0IGRvdWJsZSAqQiwgY29uc3QgaW50IGxk
YiwgY29uc3QgZG91YmxlIGJldGEsIGRvdWJsZSAqQywgY29uc3QgaW50IGxkYykNCi8qDQog
KiBtYXRtdWwgd2l0aCBUQT1ULCBUQj1OLCBNQj02MCwgTkI9NjAsIEtCPTYwLCANCiAqIGxk
YT02MCwgbGRiPTYwLCBsZGM9MCwgbXU9MSwgbnU9MSwga3U9NjANCiAqLw0Kew0KICAgY29u
c3QgZG91YmxlICpzdE0gPSBBICsgMzYwMDsNCiAgIGNvbnN0IGRvdWJsZSAqc3ROID0gQiAr
IDM2MDA7DQogICAjZGVmaW5lIGluY0FrIDYwDQogICBjb25zdCBpbnQgaW5jQW0gPSAwLCBp
bmNBbiA9IC0zNjAwOw0KICAgI2RlZmluZSBpbmNCayA2MA0KICAgY29uc3QgaW50IGluY0Jt
ID0gLTYwLCBpbmNCbiA9IDYwOw0KICAgY29uc3QgaW50IGluY0FrMCA9ICgoaW5jQWspIC8g
NjApLCBpbmNCazAgPSAoKGluY0JrKSAvIDYwKTsNCiAgICNkZWZpbmUgaW5jQ20gMQ0KICAg
Y29uc3QgaW50IGluY0NuID0gKGxkYykgLSA2MDsNCiAgIGRvdWJsZSAqcEMwPUM7DQogICBj
b25zdCBkb3VibGUgKnBBMD1BOw0KICAgY29uc3QgZG91YmxlICpwQjA9QjsNCiAgIHJlZ2lz
dGVyIGludCBrOw0KICAgcmVnaXN0ZXIgZG91YmxlIHJBMDsNCiAgIHJlZ2lzdGVyIGRvdWJs
ZSByQjA7DQogICByZWdpc3RlciBkb3VibGUgbTAsIG0xLCBtMiwgbTMsIG00LCBtNTsNCiAg
IHJlZ2lzdGVyIGRvdWJsZSByQzAwOw0KICAgZG8gLyogTi1sb29wICovDQogICB7DQogICAg
ICBkbyAvKiBNLWxvb3AgKi8NCiAgICAgIHsNCiAgICAgICAgIHJDMDAgPSAqcEMwOw0KLyoN
CiAqICAgICAgIFN0YXJ0IHBpcGVsaW5lDQogKi8NCiAgICAgICAgIHJBMCA9ICpwQTA7DQog
ICAgICAgICByQjAgPSAqcEIwOw0KICAgICAgICAgbTAgPSByQTAgKiByQjA7DQogICAgICAg
ICByQTAgPSBwQTBbMV07DQogICAgICAgICByQjAgPSBwQjBbMV07DQogICAgICAgICBtMSA9
IHJBMCAqIHJCMDsNCiAgICAgICAgIHJBMCA9IHBBMFsyXTsNCiAgICAgICAgIHJCMCA9IHBC
MFsyXTsNCiAgICAgICAgIG0yID0gckEwICogckIwOw0KICAgICAgICAgckEwID0gcEEwWzNd
Ow0KICAgICAgICAgckIwID0gcEIwWzNdOw0KICAgICAgICAgbTMgPSByQTAgKiByQjA7DQog
ICAgICAgICByQTAgPSBwQTBbNF07DQogICAgICAgICByQjAgPSBwQjBbNF07DQogICAgICAg
ICBtNCA9IHJBMCAqIHJCMDsNCiAgICAgICAgIHJBMCA9IHBBMFs1XTsNCiAgICAgICAgIHJC
MCA9IHBCMFs1XTsNCiAgICAgICAgIG01ID0gckEwICogckIwOw0KICAgICAgICAgckEwID0g
cEEwWzZdOw0KICAgICAgICAgckIwID0gcEIwWzZdOw0KDQovKg0KICogICAgICAgQ29tcGxl
dGVseSB1bnJvbGxlZCBLLWxvb3ANCiAqLw0KICAgICAgICAgckMwMCArPSBtMDsNCiAgICAg
ICAgIG0wID0gckEwICogckIwOw0KICAgICAgICAgckEwID0gcEEwWzddOw0KICAgICAgICAg
ckIwID0gcEIwWzddOw0KICAgICAgICAgckMwMCArPSBtMTsNCiAgICAgICAgIG0xID0gckEw
ICogckIwOw0KICAgICAgICAgckEwID0gcEEwWzhdOw0KICAgICAgICAgckIwID0gcEIwWzhd
Ow0KICAgICAgICAgckMwMCArPSBtMjsNCiAgICAgICAgIG0yID0gckEwICogckIwOw0KICAg
ICAgICAgckEwID0gcEEwWzldOw0KICAgICAgICAgckIwID0gcEIwWzldOw0KICAgICAgICAg
ckMwMCArPSBtMzsNCiAgICAgICAgIG0zID0gckEwICogckIwOw0KICAgICAgICAgckEwID0g
cEEwWzEwXTsNCiAgICAgICAgIHJCMCA9IHBCMFsxMF07DQogICAgICAgICByQzAwICs9IG00
Ow0KICAgICAgICAgbTQgPSByQTAgKiByQjA7DQogICAgICAgICByQTAgPSBwQTBbMTFdOw0K
ICAgICAgICAgckIwID0gcEIwWzExXTsNCiAgICAgICAgIHJDMDAgKz0gbTU7DQogICAgICAg
ICBtNSA9IHJBMCAqIHJCMDsNCiAgICAgICAgIHJBMCA9IHBBMFsxMl07DQogICAgICAgICBy
QjAgPSBwQjBbMTJdOw0KICAgICAgICAgckMwMCArPSBtMDsNCiAgICAgICAgIG0wID0gckEw
ICogckIwOw0KICAgICAgICAgckEwID0gcEEwWzEzXTsNCiAgICAgICAgIHJCMCA9IHBCMFsx
M107DQogICAgICAgICByQzAwICs9IG0xOw0KICAgICAgICAgbTEgPSByQTAgKiByQjA7DQog
ICAgICAgICByQTAgPSBwQTBbMTRdOw0KICAgICAgICAgckIwID0gcEIwWzE0XTsNCiAgICAg
ICAgIHJDMDAgKz0gbTI7DQogICAgICAgICBtMiA9IHJBMCAqIHJCMDsNCiAgICAgICAgIHJB
MCA9IHBBMFsxNV07DQogICAgICAgICByQjAgPSBwQjBbMTVdOw0KICAgICAgICAgckMwMCAr
PSBtMzsNCiAgICAgICAgIG0zID0gckEwICogckIwOw0KICAgICAgICAgckEwID0gcEEwWzE2
XTsNCiAgICAgICAgIHJCMCA9IHBCMFsxNl07DQogICAgICAgICByQzAwICs9IG00Ow0KICAg
ICAgICAgbTQgPSByQTAgKiByQjA7DQogICAgICAgICByQTAgPSBwQTBbMTddOw0KICAgICAg
ICAgckIwID0gcEIwWzE3XTsNCiAgICAgICAgIHJDMDAgKz0gbTU7DQogICAgICAgICBtNSA9
IHJBMCAqIHJCMDsNCiAgICAgICAgIHJBMCA9IHBBMFsxOF07DQogICAgICAgICByQjAgPSBw
QjBbMThdOw0KICAgICAgICAgckMwMCArPSBtMDsNCiAgICAgICAgIG0wID0gckEwICogckIw
Ow0KICAgICAgICAgckEwID0gcEEwWzE5XTsNCiAgICAgICAgIHJCMCA9IHBCMFsxOV07DQog
ICAgICAgICByQzAwICs9IG0xOw0KICAgICAgICAgbTEgPSByQTAgKiByQjA7DQogICAgICAg
ICByQTAgPSBwQTBbMjBdOw0KICAgICAgICAgckIwID0gcEIwWzIwXTsNCiAgICAgICAgIHJD
MDAgKz0gbTI7DQogICAgICAgICBtMiA9IHJBMCAqIHJCMDsNCiAgICAgICAgIHJBMCA9IHBB
MFsyMV07DQogICAgICAgICByQjAgPSBwQjBbMjFdOw0KICAgICAgICAgckMwMCArPSBtMzsN
CiAgICAgICAgIG0zID0gckEwICogckIwOw0KICAgICAgICAgckEwID0gcEEwWzIyXTsNCiAg
ICAgICAgIHJCMCA9IHBCMFsyMl07DQogICAgICAgICByQzAwICs9IG00Ow0KICAgICAgICAg
bTQgPSByQTAgKiByQjA7DQogICAgICAgICByQTAgPSBwQTBbMjNdOw0KICAgICAgICAgckIw
ID0gcEIwWzIzXTsNCiAgICAgICAgIHJDMDAgKz0gbTU7DQogICAgICAgICBtNSA9IHJBMCAq
IHJCMDsNCiAgICAgICAgIHJBMCA9IHBBMFsyNF07DQogICAgICAgICByQjAgPSBwQjBbMjRd
Ow0KICAgICAgICAgckMwMCArPSBtMDsNCiAgICAgICAgIG0wID0gckEwICogckIwOw0KICAg
ICAgICAgckEwID0gcEEwWzI1XTsNCiAgICAgICAgIHJCMCA9IHBCMFsyNV07DQogICAgICAg
ICByQzAwICs9IG0xOw0KICAgICAgICAgbTEgPSByQTAgKiByQjA7DQogICAgICAgICByQTAg
PSBwQTBbMjZdOw0KICAgICAgICAgckIwID0gcEIwWzI2XTsNCiAgICAgICAgIHJDMDAgKz0g
bTI7DQogICAgICAgICBtMiA9IHJBMCAqIHJCMDsNCiAgICAgICAgIHJBMCA9IHBBMFsyN107
DQogICAgICAgICByQjAgPSBwQjBbMjddOw0KICAgICAgICAgckMwMCArPSBtMzsNCiAgICAg
ICAgIG0zID0gckEwICogckIwOw0KICAgICAgICAgckEwID0gcEEwWzI4XTsNCiAgICAgICAg
IHJCMCA9IHBCMFsyOF07DQogICAgICAgICByQzAwICs9IG00Ow0KICAgICAgICAgbTQgPSBy
QTAgKiByQjA7DQogICAgICAgICByQTAgPSBwQTBbMjldOw0KICAgICAgICAgckIwID0gcEIw
WzI5XTsNCiAgICAgICAgIHJDMDAgKz0gbTU7DQogICAgICAgICBtNSA9IHJBMCAqIHJCMDsN
CiAgICAgICAgIHJBMCA9IHBBMFszMF07DQogICAgICAgICByQjAgPSBwQjBbMzBdOw0KICAg
ICAgICAgckMwMCArPSBtMDsNCiAgICAgICAgIG0wID0gckEwICogckIwOw0KICAgICAgICAg
ckEwID0gcEEwWzMxXTsNCiAgICAgICAgIHJCMCA9IHBCMFszMV07DQogICAgICAgICByQzAw
ICs9IG0xOw0KICAgICAgICAgbTEgPSByQTAgKiByQjA7DQogICAgICAgICByQTAgPSBwQTBb
MzJdOw0KICAgICAgICAgckIwID0gcEIwWzMyXTsNCiAgICAgICAgIHJDMDAgKz0gbTI7DQog
ICAgICAgICBtMiA9IHJBMCAqIHJCMDsNCiAgICAgICAgIHJBMCA9IHBBMFszM107DQogICAg
ICAgICByQjAgPSBwQjBbMzNdOw0KICAgICAgICAgckMwMCArPSBtMzsNCiAgICAgICAgIG0z
ID0gckEwICogckIwOw0KICAgICAgICAgckEwID0gcEEwWzM0XTsNCiAgICAgICAgIHJCMCA9
IHBCMFszNF07DQogICAgICAgICByQzAwICs9IG00Ow0KICAgICAgICAgbTQgPSByQTAgKiBy
QjA7DQogICAgICAgICByQTAgPSBwQTBbMzVdOw0KICAgICAgICAgckIwID0gcEIwWzM1XTsN
CiAgICAgICAgIHJDMDAgKz0gbTU7DQogICAgICAgICBtNSA9IHJBMCAqIHJCMDsNCiAgICAg
ICAgIHJBMCA9IHBBMFszNl07DQogICAgICAgICByQjAgPSBwQjBbMzZdOw0KICAgICAgICAg
ckMwMCArPSBtMDsNCiAgICAgICAgIG0wID0gckEwICogckIwOw0KICAgICAgICAgckEwID0g
cEEwWzM3XTsNCiAgICAgICAgIHJCMCA9IHBCMFszN107DQogICAgICAgICByQzAwICs9IG0x
Ow0KICAgICAgICAgbTEgPSByQTAgKiByQjA7DQogICAgICAgICByQTAgPSBwQTBbMzhdOw0K
ICAgICAgICAgckIwID0gcEIwWzM4XTsNCiAgICAgICAgIHJDMDAgKz0gbTI7DQogICAgICAg
ICBtMiA9IHJBMCAqIHJCMDsNCiAgICAgICAgIHJBMCA9IHBBMFszOV07DQogICAgICAgICBy
QjAgPSBwQjBbMzldOw0KICAgICAgICAgckMwMCArPSBtMzsNCiAgICAgICAgIG0zID0gckEw
ICogckIwOw0KICAgICAgICAgckEwID0gcEEwWzQwXTsNCiAgICAgICAgIHJCMCA9IHBCMFs0
MF07DQogICAgICAgICByQzAwICs9IG00Ow0KICAgICAgICAgbTQgPSByQTAgKiByQjA7DQog
ICAgICAgICByQTAgPSBwQTBbNDFdOw0KICAgICAgICAgckIwID0gcEIwWzQxXTsNCiAgICAg
ICAgIHJDMDAgKz0gbTU7DQogICAgICAgICBtNSA9IHJBMCAqIHJCMDsNCiAgICAgICAgIHJB
MCA9IHBBMFs0Ml07DQogICAgICAgICByQjAgPSBwQjBbNDJdOw0KICAgICAgICAgckMwMCAr
PSBtMDsNCiAgICAgICAgIG0wID0gckEwICogckIwOw0KICAgICAgICAgckEwID0gcEEwWzQz
XTsNCiAgICAgICAgIHJCMCA9IHBCMFs0M107DQogICAgICAgICByQzAwICs9IG0xOw0KICAg
ICAgICAgbTEgPSByQTAgKiByQjA7DQogICAgICAgICByQTAgPSBwQTBbNDRdOw0KICAgICAg
ICAgckIwID0gcEIwWzQ0XTsNCiAgICAgICAgIHJDMDAgKz0gbTI7DQogICAgICAgICBtMiA9
IHJBMCAqIHJCMDsNCiAgICAgICAgIHJBMCA9IHBBMFs0NV07DQogICAgICAgICByQjAgPSBw
QjBbNDVdOw0KICAgICAgICAgckMwMCArPSBtMzsNCiAgICAgICAgIG0zID0gckEwICogckIw
Ow0KICAgICAgICAgckEwID0gcEEwWzQ2XTsNCiAgICAgICAgIHJCMCA9IHBCMFs0Nl07DQog
ICAgICAgICByQzAwICs9IG00Ow0KICAgICAgICAgbTQgPSByQTAgKiByQjA7DQogICAgICAg
ICByQTAgPSBwQTBbNDddOw0KICAgICAgICAgckIwID0gcEIwWzQ3XTsNCiAgICAgICAgIHJD
MDAgKz0gbTU7DQogICAgICAgICBtNSA9IHJBMCAqIHJCMDsNCiAgICAgICAgIHJBMCA9IHBB
MFs0OF07DQogICAgICAgICByQjAgPSBwQjBbNDhdOw0KICAgICAgICAgckMwMCArPSBtMDsN
CiAgICAgICAgIG0wID0gckEwICogckIwOw0KICAgICAgICAgckEwID0gcEEwWzQ5XTsNCiAg
ICAgICAgIHJCMCA9IHBCMFs0OV07DQogICAgICAgICByQzAwICs9IG0xOw0KICAgICAgICAg
bTEgPSByQTAgKiByQjA7DQogICAgICAgICByQTAgPSBwQTBbNTBdOw0KICAgICAgICAgckIw
ID0gcEIwWzUwXTsNCiAgICAgICAgIHJDMDAgKz0gbTI7DQogICAgICAgICBtMiA9IHJBMCAq
IHJCMDsNCiAgICAgICAgIHJBMCA9IHBBMFs1MV07DQogICAgICAgICByQjAgPSBwQjBbNTFd
Ow0KICAgICAgICAgckMwMCArPSBtMzsNCiAgICAgICAgIG0zID0gckEwICogckIwOw0KICAg
ICAgICAgckEwID0gcEEwWzUyXTsNCiAgICAgICAgIHJCMCA9IHBCMFs1Ml07DQogICAgICAg
ICByQzAwICs9IG00Ow0KICAgICAgICAgbTQgPSByQTAgKiByQjA7DQogICAgICAgICByQTAg
PSBwQTBbNTNdOw0KICAgICAgICAgckIwID0gcEIwWzUzXTsNCiAgICAgICAgIHJDMDAgKz0g
bTU7DQogICAgICAgICBtNSA9IHJBMCAqIHJCMDsNCiAgICAgICAgIHJBMCA9IHBBMFs1NF07
DQogICAgICAgICByQjAgPSBwQjBbNTRdOw0KICAgICAgICAgckMwMCArPSBtMDsNCiAgICAg
ICAgIG0wID0gckEwICogckIwOw0KICAgICAgICAgckEwID0gcEEwWzU1XTsNCiAgICAgICAg
IHJCMCA9IHBCMFs1NV07DQogICAgICAgICByQzAwICs9IG0xOw0KICAgICAgICAgbTEgPSBy
QTAgKiByQjA7DQogICAgICAgICByQTAgPSBwQTBbNTZdOw0KICAgICAgICAgckIwID0gcEIw
WzU2XTsNCiAgICAgICAgIHJDMDAgKz0gbTI7DQogICAgICAgICBtMiA9IHJBMCAqIHJCMDsN
CiAgICAgICAgIHJBMCA9IHBBMFs1N107DQogICAgICAgICByQjAgPSBwQjBbNTddOw0KICAg
ICAgICAgckMwMCArPSBtMzsNCiAgICAgICAgIG0zID0gckEwICogckIwOw0KICAgICAgICAg
ckEwID0gcEEwWzU4XTsNCiAgICAgICAgIHJCMCA9IHBCMFs1OF07DQogICAgICAgICByQzAw
ICs9IG00Ow0KICAgICAgICAgbTQgPSByQTAgKiByQjA7DQogICAgICAgICByQTAgPSBwQTBb
NTldOw0KICAgICAgICAgckIwID0gcEIwWzU5XTsNCi8qDQogKiAgICAgICBEcmFpbiBwaXBl
IG9uIGxhc3QgaXRlcmF0aW9uIG9mIEstbG9vcA0KICovDQogICAgICAgICByQzAwICs9IG01
Ow0KICAgICAgICAgbTUgPSByQTAgKiByQjA7DQogICAgICAgICByQzAwICs9IG0wOw0KICAg
ICAgICAgckMwMCArPSBtMTsNCiAgICAgICAgIHJDMDAgKz0gbTI7DQogICAgICAgICByQzAw
ICs9IG0zOw0KICAgICAgICAgckMwMCArPSBtNDsNCiAgICAgICAgIHJDMDAgKz0gbTU7DQog
ICAgICAgICBwQTAgKz0gaW5jQWs7DQogICAgICAgICBwQjAgKz0gaW5jQms7DQogICAgICAg
ICAqcEMwID0gckMwMDsNCiAgICAgICAgIHBDMCArPSBpbmNDbTsNCiAgICAgICAgIHBBMCAr
PSBpbmNBbTsNCiAgICAgICAgIHBCMCArPSBpbmNCbTsNCiAgICAgIH0NCiAgICAgIHdoaWxl
KHBBMCAhPSBzdE0pOw0KICAgICAgcEMwICs9IGluY0NuOw0KICAgICAgcEEwICs9IGluY0Fu
Ow0KICAgICAgcEIwICs9IGluY0JuOw0KICAgfQ0KICAgd2hpbGUocEIwICE9IHN0Tik7DQp9
DQojaWZkZWYgaW5jQW0NCiAgICN1bmRlZiBpbmNBbQ0KI2VuZGlmDQojaWZkZWYgaW5jQW4N
CiAgICN1bmRlZiBpbmNBbg0KI2VuZGlmDQojaWZkZWYgaW5jQWsNCiAgICN1bmRlZiBpbmNB
aw0KI2VuZGlmDQojaWZkZWYgaW5jQm0NCiAgICN1bmRlZiBpbmNCbQ0KI2VuZGlmDQojaWZk
ZWYgaW5jQm4NCiAgICN1bmRlZiBpbmNCbg0KI2VuZGlmDQojaWZkZWYgaW5jQmsNCiAgICN1
bmRlZiBpbmNCaw0KI2VuZGlmDQojaWZkZWYgaW5jQ20NCiAgICN1bmRlZiBpbmNDbQ0KI2Vu
ZGlmDQojaWZkZWYgaW5jQ24NCiAgICN1bmRlZiBpbmNDbg0KI2VuZGlmDQojaWZkZWYgaW5j
Q2sNCiAgICN1bmRlZiBpbmNDaw0KI2VuZGlmDQojaWZkZWYgTWINCiAgICN1bmRlZiBNYg0K
I2VuZGlmDQojaWZkZWYgTmINCiAgICN1bmRlZiBOYg0KI2VuZGlmDQojaWZkZWYgS2INCiAg
ICN1bmRlZiBLYg0KI2VuZGlmDQo=

--------------C46AA6A020A2A52FCBA701B9--


From owner-pro64-support@oss.sgi.com Fri Nov  3 08:04:00 2000
Received:  by oss.sgi.com id <S553848AbQKCQDt>;
	Fri, 3 Nov 2000 08:03:49 -0800
Received: from web10203.mail.yahoo.com ([216.136.130.67]:6931 "HELO
        web10203.mail.yahoo.com") by oss.sgi.com with SMTP
	id <S553763AbQKCQDf>; Fri, 3 Nov 2000 08:03:35 -0800
Message-ID: <20001103160329.72257.qmail@web10203.mail.yahoo.com>
Received: from [144.216.91.245] by web10203.mail.yahoo.com; Fri, 03 Nov 2000 08:03:29 PST
Date:   Fri, 3 Nov 2000 08:03:29 -0800 (PST)
From:   Rongcai Zhao <rongcaizhao@yahoo.com>
Subject: Help me.
To:     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: <owner-pro64-support@oss.sgi.com>
X-Orcpt: rfc822;pro64-support-outgoing

Dear Sir:

I downloaded the Pro64 and NUE components from sgi
website and installed them. But I faced some problems.
1.The installation of NUE is completely success.But it
was reported that /dev/mtab file doesn't exist during
the installation of pro64 rpm.
2.UNE runs normally.The cc and sgcc run OK. But only
the text about warranty and license was displayed and
no program result when running the a.out.What's the
idea.
I'd like you give me directions.

Rong C.Zhao



__________________________________________________
Do You Yahoo!?
>From homework help to love advice, Yahoo! Experts has your answer.
http://experts.yahoo.com/

From owner-pro64-support@oss.sgi.com Mon Nov  6 00:15:56 2000
Received:  by oss.sgi.com id <S553983AbQKFIPr>;
	Mon, 6 Nov 2000 00:15:47 -0800
Received: from steinberg.umd.edu ([129.2.71.109]:10399 "EHLO steinberg.umd.edu")
	by oss.sgi.com with ESMTP id <S553980AbQKFIPk>;
	Mon, 6 Nov 2000 00:15:40 -0800
Received: from fiber.eng.umd.edu (IDENT:root@fiber.eng.umd.edu [129.2.98.185])
	by steinberg.umd.edu (8.9.3/8.9.3) with ESMTP id DAA27882
	for <pro64-support@oss.sgi.com>; Mon, 6 Nov 2000 03:20:16 -0500 (EST)
Received: from fiber.eng.umd.edu (IDENT:sendmail@localhost [127.0.0.1])
	by fiber.eng.umd.edu (8.9.3/8.9.3) with SMTP id DAA09818
	for <pro64-support@oss.sgi.com>; Mon, 6 Nov 2000 03:15:37 -0500 (EST)
Received: from localhost (tvinod@localhost)
	by fiber.eng.umd.edu (8.9.3/8.9.3) with ESMTP id DAA09814
	for <pro64-support@oss.sgi.com>; Mon, 6 Nov 2000 03:15:37 -0500 (EST)
X-Authentication-Warning: fiber.eng.umd.edu: tvinod owned process doing -bs
Date:   Mon, 6 Nov 2000 03:15:37 -0500 (EST)
From:   T Vinod Kumar Gupta <tvinod@Glue.umd.edu>
X-Sender: tvinod@fiber.eng.umd.edu
To:     pro64-support@oss.sgi.com
Subject: scheduler in haifa_sched.c
Message-ID: <Pine.GSO.4.21.0011060311520.9705-100000@fiber.eng.umd.edu>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-pro64-support@oss.sgi.com
Precedence: bulk
Return-Path: <owner-pro64-support@oss.sgi.com>
X-Orcpt: rfc822;pro64-support-outgoing

Hello All,

	I have a question. I want to look into the code scheduler of
sgicc. I looked into the haifa_sched.c file in the gccfe/gnu
directory. But it seems that functions in those files are not being called
at all. So

1) Are the schedule functions in that file never called?

2) If so, who does the scheduling of the code?

3) Also, the .cxx files in the be/cg directory and elsewhere - are they
being automatically generated or were created?

	
	It would be nice if I could get some quick answers for that.

Thanks in advance,
Vinod

Graduate Student,
Dept. of ECE,
Univ of Maryland, College park,



From owner-pro64-support@oss.sgi.com Mon Nov  6 01:28:38 2000
Received:  by oss.sgi.com id <S553983AbQKFJ22>;
	Mon, 6 Nov 2000 01:28:28 -0800
Received: from Cantor.suse.de ([194.112.123.193]:39953 "HELO Cantor.suse.de")
	by oss.sgi.com with SMTP id <S553980AbQKFJ2R>;
	Mon, 6 Nov 2000 01:28:17 -0800
Received: from Hermes.suse.de (Hermes.suse.de [194.112.123.136])
	by Cantor.suse.de (Postfix) with ESMTP
	id 235951E08F; Mon,  6 Nov 2000 10:28:15 +0100 (MET)
Received: from gruyere.muc.suse.de (unknown [10.23.1.2])
	by Hermes.suse.de (Postfix) with ESMTP
	id A00683E476; Mon,  6 Nov 2000 10:28:14 +0100 (MET)
Received: by gruyere.muc.suse.de (Postfix, from userid 14446)
	id D2BC62F300; Mon,  6 Nov 2000 10:28:13 +0100 (MET)
Date:   Mon, 6 Nov 2000 10:28:13 +0100
From:   Andi Kleen <ak@suse.de>
To:     T Vinod Kumar Gupta <tvinod@Glue.umd.edu>
Cc:     pro64-support@oss.sgi.com
Subject: Re: scheduler in haifa_sched.c
Message-ID: <20001106102813.A11985@gruyere.muc.suse.de>
References: <Pine.GSO.4.21.0011060311520.9705-100000@fiber.eng.umd.edu>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <Pine.GSO.4.21.0011060311520.9705-100000@fiber.eng.umd.edu>; from tvinod@Glue.umd.edu on Mon, Nov 06, 2000 at 03:15:37AM -0500
Sender: owner-pro64-support@oss.sgi.com
Precedence: bulk
Return-Path: <owner-pro64-support@oss.sgi.com>
X-Orcpt: rfc822;pro64-support-outgoing

On Mon, Nov 06, 2000 at 03:15:37AM -0500, T Vinod Kumar Gupta wrote:
> Hello All,
> 
> 	I have a question. I want to look into the code scheduler of
> sgicc. I looked into the haifa_sched.c file in the gccfe/gnu
> directory. But it seems that functions in those files are not being called
> at all. So
> 
> 1) Are the schedule functions in that file never called?

This is gcc's scheduler which is part of gcc's backend. pro64 does not 
use gcc's backend because it has its own.

> 
> 2) If so, who does the scheduling of the code?

Have you checked be/cg/cg_sched_* ?

> 
> 3) Also, the .cxx files in the be/cg directory and elsewhere - are they
> being automatically generated or were created?

They do not look like it, except if SGI has some much better AIs than everybody
else @)


-Andi

From owner-pro64-support@oss.sgi.com Mon Nov  6 20:54:16 2000
Received:  by oss.sgi.com id <S553796AbQKGEyH>;
	Mon, 6 Nov 2000 20:54:07 -0800
Received: from xena.eas.asu.edu ([129.219.38.222]:30213 "EHLO xena.eas.asu.edu")
	by oss.sgi.com with ESMTP id <S553793AbQKGExr>;
	Mon, 6 Nov 2000 20:53:47 -0800
Received: from localhost (andy@localhost)
	by xena.eas.asu.edu (8.9.3/8.9.3) with ESMTP id VAA25181
	for <pro64-support@oss.sgi.com>; Mon, 6 Nov 2000 21:54:54 -0700
Date:   Mon, 6 Nov 2000 21:54:53 -0700 (MST)
From:   Andrew Vaught <andy@xena.eas.asu.edu>
To:     pro64-support@oss.sgi.com
Subject: Bug Report
Message-ID: <Pine.LNX.4.21.0011062150460.25178-100000@xena.eas.asu.edu>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-pro64-support@oss.sgi.com
Precedence: bulk
Return-Path: <owner-pro64-support@oss.sgi.com>
X-Orcpt: rfc822;pro64-support-outgoing

Hi--

  I ran across a problem with your fortran 90 compiler.  The program:

type tt
  integer :: unit
end type

type(tt) :: comm

write(comm%unit)
end

Crashes the compiler with:

andyv@medusa:~ % f90 -c tst.f90

### Assertion failure at line 402 of ../../../crayf90/sgi/cwh_stk.c:
### Compiler Error in file tst.f90 during IR->WHIRL Conversion phase:
### Stack underflow
f90 INTERNAL ERROR:  /usr/lib32/cmplrs/mfef90 returned non-zero status 1
andyv@medusa:~ %
----------------------------------
"uname -a" gives:

IRIX64 medusa 6.4 02121744 IP27

----------------------------------
"f90 -version" gives:
MIPSpro Compilers: Version 7.20

           Andy

-----------------                        XOLD(K,IC,I)=
Andy Vaught               ....        DO ITERS=1, 10  XOLD(K,IC,I)
andy@xena.eas.asu.edu     |  |   /CALLMSOLVE(A,B,X,I,ITERS,TOL)+(RANNYU(0)
Arizona State University  ======|WRITE(6,'(I5,2X,F12.6)')ITERS,TOL -HALF)
Tempe, Arizona USA        OOOOOO \ENDDORETURN PARAMETER(ZERO=1.D0)*TENTH*DELTA


From owner-pro64-support@oss.sgi.com Mon Nov  6 22:09:26 2000
Received:  by oss.sgi.com id <S553806AbQKGGJR>;
	Mon, 6 Nov 2000 22:09:17 -0800
Received: from deliverator.sgi.com ([204.94.214.10]:14649 "EHLO
        deliverator.sgi.com") by oss.sgi.com with ESMTP id <S553800AbQKGGJN>;
	Mon, 6 Nov 2000 22:09:13 -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 WAA10177
	for <pro64-support@oss.sgi.com>; Mon, 6 Nov 2000 22:01: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 WAA44734; Mon, 6 Nov 2000 22:06:00 -0800 (PST)
Date:   Mon, 6 Nov 2000 22:06:00 -0800 (PST)
From:   mpm@rohi.engr.sgi.com (Michael Murphy)
Message-Id: <200011070606.WAA44734@rohi.engr.sgi.com>
To:     pro64-support@oss.sgi.com, Andrew Vaught <andy@xena.eas.asu.edu>
Subject: Re:  Bug Report
Sender: owner-pro64-support@oss.sgi.com
Precedence: bulk
Return-Path: <owner-pro64-support@oss.sgi.com>
X-Orcpt: rfc822;pro64-support-outgoing

	From: Andrew Vaught <andy@xena.eas.asu.edu>
	
	  I ran across a problem with your fortran 90 compiler.  The program:
	
	[ deleted]

	"f90 -version" gives:
	MIPSpro Compilers: Version 7.20
	
This mailing list is for the IA64 open source SGIpro compilers.
You are using the IRIX MIPSpro compilers, which is a different product.
You need to go through customer support for problems in those
compilers.  But I will tell you that you should upgrade to 7.3,
and that will solve your problem.
-- Mike Murphy
-- mpm@sgi.com
-- quote of the day:
--  "Plan to throw one [implementation] away; you will, anyhow." 
--   (Fred Brooks, "The Mythical Man-Month", Chapter 11) 

From owner-pro64-support@oss.sgi.com Tue Nov  7 10:40:10 2000
Received:  by oss.sgi.com id <S553728AbQKGSjv>;
	Tue, 7 Nov 2000 10:39:51 -0800
Received: from deliverator.sgi.com ([204.94.214.10]:13076 "EHLO
        deliverator.sgi.com") by oss.sgi.com with ESMTP id <S553709AbQKGSju>;
	Tue, 7 Nov 2000 10:39: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 KAA18702
	for <pro64-support@oss.sgi.com>; Tue, 7 Nov 2000 10:31:59 -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 KAA23841; Tue, 7 Nov 2000 10:32:56 -0800 (PST)
From:   "Ross A. Towle" <rat@cchkms.engr.sgi.com>
Message-Id: <10011071032.ZM21846@cchkms.engr.sgi.com>
Date:   Tue, 7 Nov 2000 10:32:54 -0800
In-Reply-To: Andrew Vaught <andy@xena.eas.asu.edu>
        "Bug Report" (Nov  6,  9:54pm)
References: <Pine.LNX.4.21.0011062150460.25178-100000@xena.eas.asu.edu>
X-Mailer: Z-Mail (3.2.3 08feb96 MediaMail)
To:     Andrew Vaught <andy@xena.eas.asu.edu>, pro64-support@oss.sgi.com
Subject: Re: Bug Report
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: owner-pro64-support@oss.sgi.com
Precedence: bulk
Return-Path: <owner-pro64-support@oss.sgi.com>
X-Orcpt: rfc822;pro64-support-outgoing

The problem you submitted is with the MIPSpro compilers and not
the Pro64 compilers.  They are not the same products.  Please use this
mail list to submit Pro64 problems.  Problems with the MIPSpro
compilers should be submitted through SGI Customer Service.

For your information it works with MIPSpro7.3.1.2m.

-Ross

From owner-pro64-support@oss.sgi.com Wed Nov  8 15:37:21 2000
Received:  by oss.sgi.com id <S554038AbQKHXhL>;
	Wed, 8 Nov 2000 15:37:11 -0800
Received: from deliverator.sgi.com ([204.94.214.10]:846 "EHLO
        deliverator.sgi.com") by oss.sgi.com with ESMTP id <S553733AbQKHXhG>;
	Wed, 8 Nov 2000 15:37:06 -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 PAA16700; Wed, 8 Nov 2000 15:29:15 -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 PAA27753; Wed, 8 Nov 2000 15:30:13 -0800 (PST)
Date:   Wed, 8 Nov 2000 15:30:13 -0800 (PST)
From:   rat@cchkms.engr.sgi.com (Ross A. Towle)
Message-Id: <200011082330.PAA27753@cchkms.engr.sgi.com>
To:     pro64-support@oss.sgi.com, pro64-announce@oss.sgi.com
Subject: Pro64 release 12 is available for downloading
Sender: owner-pro64-support@oss.sgi.com
Precedence: bulk
Return-Path: <owner-pro64-support@oss.sgi.com>
X-Orcpt: rfc822;pro64-support-outgoing


Another release of Pro64 is available for downloading from 
http://oss.sgi.com/projects/Pro64/download.html.

This release fixes a number of reported problems by Uros Prestor and others.
It also switches from using implicit prefetches to explicit prefetches.
There are other performance tweaks.

Release 12 will probably be the last release that depends upon IA32
compatability mode on Itanium.  The next release will require the compiler
be installed on Itanium.

Continue to send problem reports to pro64-support@oss.sgi.com.

-Ross A. Towle
Director, High Performance Programming Environments
SGI

From owner-pro64-support@oss.sgi.com Sat Nov 11 22:26:06 2000
Received:  by oss.sgi.com id <S553894AbQKLGZ4>;
	Sat, 11 Nov 2000 22:25:56 -0800
Received: from steinberg.umd.edu ([129.2.71.109]:21970 "EHLO steinberg.umd.edu")
	by oss.sgi.com with ESMTP id <S553878AbQKLGZj>;
	Sat, 11 Nov 2000 22:25:39 -0800
Received: from baud.eng.umd.edu (IDENT:root@baud.eng.umd.edu [129.2.98.183])
	by steinberg.umd.edu (8.9.3/8.9.3) with ESMTP id BAA14729
	for <pro64-support@oss.sgi.com>; Sun, 12 Nov 2000 01:25:31 -0500 (EST)
Received: from baud.eng.umd.edu (IDENT:sendmail@localhost [127.0.0.1])
	by baud.eng.umd.edu (8.9.3/8.9.3) with SMTP id BAA06151
	for <pro64-support@oss.sgi.com>; Sun, 12 Nov 2000 01:25:30 -0500 (EST)
Received: from localhost (tvinod@localhost)
	by baud.eng.umd.edu (8.9.3/8.9.3) with ESMTP id BAA06147
	for <pro64-support@oss.sgi.com>; Sun, 12 Nov 2000 01:25:30 -0500 (EST)
X-Authentication-Warning: baud.eng.umd.edu: tvinod owned process doing -bs
Date:   Sun, 12 Nov 2000 01:25:30 -0500 (EST)
From:   T Vinod Kumar Gupta <tvinod@Glue.umd.edu>
X-Sender: tvinod@baud.eng.umd.edu
To:     pro64-support@oss.sgi.com
Subject: Speculation in sgicc
Message-ID: <Pine.GSO.4.21.0011120120060.6115-100000@baud.eng.umd.edu>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-pro64-support@oss.sgi.com
Precedence: bulk
Return-Path: <owner-pro64-support@oss.sgi.com>
X-Orcpt: rfc822;pro64-support-outgoing

Hello,
	I am looking into the (control) speculation abilities of the sgi
compiler. I was looking into the gcm.cxx file in be/cg.
	There is some piece of code to decide to do speculation but it
seems that in actual practice, speculation is never done. I tried it with
one of the spec2000 applications as well. 
Also, I remembered to use the -O3 option.

	Is control speculation properly implemented in the compiler??
	If yes, are there some severe constraints??
	
Thanks in advance,
Vinod

Graduate Student
Dept. of ECE,
University of Maryland, College Park



From owner-pro64-support@oss.sgi.com Sun Nov 12 02:04:47 2000
Received:  by oss.sgi.com id <S553897AbQKLKE0>;
	Sun, 12 Nov 2000 02:04:26 -0800
Received: from narkis.wisdom.weizmann.ac.il ([132.76.80.32]:40465 "EHLO
        narkis.wisdom.weizmann.ac.il") by oss.sgi.com with ESMTP
	id <S553885AbQKLKDy>; Sun, 12 Nov 2000 02:03:54 -0800
Received: from wisdom.weizmann.ac.il (amir8-pc.wisdom.weizmann.ac.il [132.76.81.32])
	by narkis.wisdom.weizmann.ac.il (8.9.1a/8.9.1) with ESMTP id MAA20841
	for <pro64-support@oss.sgi.com>; Sun, 12 Nov 2000 12:04:08 +0200 (IST)
Message-ID: <3A0E6A7A.C3963A73@wisdom.weizmann.ac.il>
Date:   Sun, 12 Nov 2000 12:01:30 +0200
From:   raya <raya@wisdom.weizmann.ac.il>
Organization: Weizmann Institute of Science
X-Mailer: Mozilla 4.75 [en] (WinNT; U)
X-Accept-Language: il,en
MIME-Version: 1.0
To:     pro64 <pro64-support@oss.sgi.com>
Subject: loop-unrolling bug ?
Content-Type: multipart/mixed;
 boundary="------------85F90C9E80A749D387FB569E"
Sender: owner-pro64-support@oss.sgi.com
Precedence: bulk
Return-Path: <owner-pro64-support@oss.sgi.com>
X-Orcpt: rfc822;pro64-support-outgoing

This is a multi-part message in MIME format.
--------------85F90C9E80A749D387FB569E
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Hello,

Enclosed is a c source and the assembly output of a small c loop.
The first instruction of the loop (label: BB6_main) is:
    ls4 r33=[r36].
To my understanding, "r36" is not initialized in the first time the loop
is executed, (no reg rotation was done at this stage). To my
understanding pr17 is set to "1" in the first execution of the loop. Am
I worng?

Thanks,
--
Raya Leviathan
Tel. 972-8-9344208 (office)
Tel. 972-3-6358481 (home)
Email: raya@wisdom.weizmann.ac.il


--------------85F90C9E80A749D387FB569E
Content-Type: application/x-unknown-content-type-c_auto_file;
 name="modulo-scheduling.c"
Content-Disposition: inline;
 filename="modulo-scheduling.c"
Content-Transfer-Encoding: base64

aW50IE07CmludCBhWzEwMF07Cm1haW4oKQp7CiAgaW50IGk7CiAgZm9yKGkgPSAwOyBpIDwg
MTAwIDsgaSArKyl7CiAgICBhW2ldICs9IE07CiAgfQp9Cg==
--------------85F90C9E80A749D387FB569E
Content-Type: application/x-unknown-content-type-S_auto_file;
 name="modulo-scheduling_1.s"
Content-Disposition: inline;
 filename="modulo-scheduling_1.s"
Content-Transfer-Encoding: base64

CS8vICAvdXNyL2xpYi9nY2MtbGliL2lhNjQtc2dpLWxpbnV4L3NnaWNjLTEuMC9iZTo6MC4w
MS4wLTkKCgkvLy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tCgkvLyBDb21waWxpbmcgbW9kdWxvLXNjaGVkdWxpbmcuYyAoL3Rt
cC9jY0IuSUNVbTVVKQoJLy8tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLQoKCS8vLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0KCS8vIE9wdGlvbnM6CgkvLy0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
CgkvLyAgVGFyZ2V0Okl0YW5pdW0sIElTQTpJU0FfMSwgUG9pbnRlciBTaXplOjY0CgkvLyAg
LU8zCShPcHRpbWl6YXRpb24gbGV2ZWwpCgkvLyAgLWczCShEZWJ1ZyBsZXZlbCkKCS8vICAt
bTEJKFJlcG9ydCB3YXJuaW5ncykKCS8vLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0KCgkuY29tbW9uCU0jLCA0LCA0CgkuY29t
bW9uCWEjLCA0MDAsIDQKCgkuc2VjdGlvbiAudGV4dCwgImF4IiwgInByb2diaXRzIgoJLmFs
aWduCTE2Cgkuc2VjdGlvbiAudGV4dAoKCS8vIFByb2dyYW0gVW5pdDogbWFpbgoJLnByb2MJ
bWFpbiMKCS5nbG9iYWwJbWFpbiMKbWFpbiM6CS8vIDB4MAoJLmZpbGUJMCAiL2hvbWUvcmF5
YS9iZW5jaG1hcmtzL21vZHVsby1zY2hlZHVsaW5nL21vZHVsby1zY2hlZHVsaW5nLmMiCgku
bG9jCTAJNAkwCi8vICAgMSAgaW50IE07Ci8vICAgMiAgaW50IGFbMTAwXTsKLy8gICAzICBt
YWluKCkKLy8gICA0ICB7Ci5CQjFfbWFpbjoJLy8gMHgwCi8vPGZyZXE+Ci8vPGZyZXE+IEJC
OjEgZnJlcXVlbmN5ID0gMS4wMDAwMCAoaGV1cmlzdGljKQovLzxmcmVxPgogewkgICAgICAu
bWlpCi8vCS5zYXZlIGFyLnBmcwoJICAgICAgYWxsb2Mgcjg9YXIucGZzLDAsMjQsMCwyNAkv
LyBbMF0gIAoJICAgICAgYWRkbCByMj1AbHRvZmYoTSMpLGdwICAgCS8vIFswXSAgTQoJICAg
ICAgYWRkbCByMTQ9QGx0b2ZmKGEjKSxncCAgCS8vIFswXSAgYQogfTsgewkgICAgICAubWlp
CgkgICAgICBtb3YgcjM9OTkgICAgICAgICAgICAgICAJLy8gWzBdICAKCSAgICAgIG1vdiBy
MTE9cHIgOzsgICAgICAgICAgIAkvLyBbMF0gIAoJICAgICAgbW92LmkgYXIubGM9cjMgICAg
ICAgICAgCS8vIFsxXSAgCiB9OyB7CSAgICAgIC5tbWkKCSAgICAgIGxkOCByMj1bcjJdICAg
ICAgICAgICAgIAkvLyBbMl0gIAoJICAgICAgbGQ4IHIxND1bcjE0XSAgICAgICAgICAgCS8v
IFsyXSAgCgkgICAgICBub3AuaSAwIDs7ICAgICAgICAgICAgICAJLy8gIAogfTsgewkgICAg
ICAubWlpCgkgICAgICBtb3YgcjM1PXIxNCAgICAgICAgICAgICAJLy8gWzRdICAKCSAgICAg
IGFkZHMgcjM0PTEyOCxyMTQgICAgICAgIAkvLyBbNF0gIAoJICAgICAgbm9wLmkgMCAgICAg
ICAgICAgICAgICAgCS8vICAKIH07IHsJICAgICAgLm1paQoJICAgICAgbGQ0IHIyPVtyMl0g
ICAgICAgICAgICAgCS8vIFs1XSAgaWQ6MTQgTSsweDAKCSAgICAgIG5vcC5pIDAgICAgICAg
ICAgICAgICAgIAkvLyAgCgkgICAgICBub3AuaSAwIDs7ICAgICAgICAgICAgICAJLy8gIAog
fTsKLkJCOF9tYWluOgkvLyAweDUwCi8vPGxvb3A+IFVucm9sbGluZyByZW1haW5kZXIgbG9v
cCAoNCBpdGVyYXRpb25zKQovLzxmcmVxPgovLzxmcmVxPiBCQjo4IGZyZXF1ZW5jeSA9IDEu
MDAwMDAgKGhldXJpc3RpYykKLy88ZnJlcT4KIHsJICAgICAgLm1taQoJICAgICAgbW92IHI4
PXIxNCA7OyAgICAgICAgICAgCS8vIFs0XSAgCgkgICAgICBsZDQgcjM9W3I4XSwxNDAgICAg
ICAgICAJLy8gWzBdICBpZDoxNSBhKzB4MAoJICAgICAgbW92IHIzNT1yMTQgICAgICAgICAg
ICAgCS8vIFswXSAgCiB9OyB7CSAgICAgIC5tbWkKCS5sb2MJMAk3CTAKLy8gICA1ICAgIGlu
dCBpOwovLyAgIDYgICAgZm9yKGkgPSAwOyBpIDwgMTAwIDsgaSArKyl7Ci8vICAgNyAgICAg
IGFbaV0gKz0gTTsKCSAgICAgIGFkZHMgcjM0PTE0NCxyMTQgOzsgICAgIAkvLyBbMF0gIAoJ
ICAgICAgbGZldGNoLmV4Y2wgW3I4XSAgICAgICAgCS8vIFsxXSAgTDIKCSAgICAgIGFkZCBy
Mz1yMyxyMiA7OyAgICAgICAgIAkvLyBbMl0gIAogfTsgewkgICAgICAubW1pCgkgICAgICBz
dDQgW3IzNV09cjMsNCA7OyAgICAgICAJLy8gWzNdICBpZDoxNiBhKzB4MAoJICAgICAgbGQ0
IHIzPVtyMzVdICAgICAgICAgICAgCS8vIFs0XSAgaWQ6MTUgYSsweDAKCSAgICAgIG5vcC5p
IDAgOzsgICAgICAgICAgICAgIAkvLyAgCiB9OyB7CSAgICAgIC5tbWkKCSAgICAgIGFkZCBy
Mz1yMyxyMiA7OyAgICAgICAgIAkvLyBbNl0gIAoJICAgICAgc3Q0IFtyMzVdPXIzLDQgICAg
ICAgICAgCS8vIFs3XSAgaWQ6MTYgYSsweDAKCSAgICAgIG5vcC5pIDAgOzsgICAgICAgICAg
ICAgIAkvLyAgCiB9OyB7CSAgICAgIC5tbWkKCSAgICAgIGxkNCByMTA9W3IzNV0gOzsgICAg
ICAgIAkvLyBbOF0gIGlkOjE1IGErMHgwCgkgICAgICBhZGQgcjEwPXIxMCxyMiAgICAgICAg
ICAJLy8gWzEwXSAgCgkgICAgICBub3AuaSAwIDs7ICAgICAgICAgICAgICAJLy8gIAogfTsg
ewkgICAgICAubW1pCgkgICAgICBzdDQgW3IzNV09cjEwLDQgOzsgICAgICAJLy8gWzExXSAg
aWQ6MTYgYSsweDAKCSAgICAgIGxkNCByOT1bcjM1XSAgICAgICAgICAgIAkvLyBbMTJdICBp
ZDoxNSBhKzB4MAoJICAgICAgbW92IHIxMD0xMSA7OyAgICAgICAgICAgCS8vIFsxMl0gIAog
fTsgewkgICAgICAubW1pCgkgICAgICBhZGQgcjk9cjkscjIgOzsgICAgICAgICAJLy8gWzE0
XSAgCgkgICAgICBzdDQgW3IzNV09cjksNCAgICAgICAgICAJLy8gWzE1XSAgaWQ6MTYgYSsw
eDAKCSAgICAgIG5vcC5pIDAgOzsgICAgICAgICAgICAgIAkvLyAgCiB9OwouQkI3X21haW46
CS8vIDB4YzAKLy88ZnJlcT4KLy88ZnJlcT4gQkI6NyBmcmVxdWVuY3kgPSAxLjAwMDAwICho
ZXVyaXN0aWMpCi8vPGZyZXE+CiB7CSAgICAgIC5taWIKCSAgICAgIG1vdiByOT0yICAgICAg
ICAgICAgICAgIAkvLyBbMF0gIAoJICAgICAgbm9wLmkgMCAgICAgICAgICAgICAgICAgCS8v
ICAKCSAgICAgIGNscnJyYi5wciA7OyAgICAgICAgICAgIAkvLyBbMF0gIAogfTsgewkgICAg
ICAubWlpCgkgICAgICBub3AubSAwICAgICAgICAgICAgICAgICAJLy8gIAoJICAgICAgbW92
IHByLnJvdD02NTUzNiAgICAgICAgCS8vIFswXSAgCgkgICAgICBtb3YuaSBhci5sYz1yMTAg
ICAgICAgICAJLy8gWzBdICAKIH07IHsJICAgICAgLm1paQoJICAgICAgbm9wLm0gMCAgICAg
ICAgICAgICAgICAgCS8vICAKCSAgICAgIG1vdi5pIGFyLmVjPXI5ICAgICAgICAgIAkvLyBb
MV0gIAoJICAgICAgbm9wLmkgMCA7OyAgICAgICAgICAgICAgCS8vICAKIH07Ci5CQjZfbWFp
bjoJLy8gMHhmMAovLzxsb29wPiBMb29wIGJvZHkgbGluZSA0LCBuZXN0aW5nIGRlcHRoOiAx
LCBpdGVyYXRpb25zOiAxMgovLzxsb29wPiB1bnJvbGxlZCA4IHRpbWVzCi8vPHN3cHM+IAov
Lzxzd3BzPiAgIDkgY3ljbGVzIHBlciAxIGl0ZXJhdGlvbiBpbiBzdGVhZHkgc3RhdGUKLy88
c3dwcz4gICAyIHBpcGVsaW5lIHN0YWdlcwovLzxzd3BzPiAKLy88c3dwcz4gICAgICBtaW4g
OSBjeWNsZXMgcmVxdWlyZWQgYnkgcmVzb3VyY2VzCi8vPHN3cHM+ICAgICAgbWluIDkgY3lj
bGVzIHJlcXVpcmVkIGJ5IHJlc291cmNlcy9yZWN1cnJlbmNlCi8vPHN3cHM+ICAgICAgbWlu
IDYgY3ljbGVzIChhY3R1YWwgMTAgY3ljbGVzKSByZXF1aXJlZCB0byBzY2hlZHVsZSBvbmUg
aXRlcmF0aW9uCi8vPHN3cHM+ICAgICAgCi8vPHN3cHM+ICAgICAgMzUgaXNzdWUgdW5pdHMg
KCA2NCUgb2YgcGVhayApCi8vPHN3cHM+ICAgICAgMzQgSTAtSTEtTU8tTTEgdW5pdHMgKCA5
NCUgb2YgcGVhayApCi8vPHN3cHM+ICAgICAgMTcgbWVtb3J5IHVuaXRzICggOTQlIG9mIHBl
YWsgKQovLzxzd3BzPiAgICAgIDEgYnJhbmNoIHVuaXRzICggMyUgb2YgcGVhayApCi8vPHN3
cHM+ICAgICAgCi8vPGZyZXE+Ci8vPGZyZXE+IEJCOjYgZnJlcXVlbmN5ID0gMTMuNTAwMDAg
KGhldXJpc3RpYykKLy88ZnJlcT4gQkI6NiA9PiBCQjo2IHByb2JhYmlsaXR5ID0gMC45MTY2
NwovLzxmcmVxPiBCQjo2ID0+IEJCOjUgcHJvYmFiaWxpdHkgPSAwLjA4MzMzCi8vPGZyZXE+
CiB7CSAgICAgIC5taWkKCShwMTcpIGxkNCByMzM9W3IzNl0gICAgICAgICAgIAkvLyBbMSpJ
SSswXSAgaWQ6MTUgYSsweDAKCShwMTcpIGFkZHMgcjM3PTI0LHIzNiAgICAgICAgIAkvLyBb
MSpJSSswXSAgCgkocDE3KSBhZGRzIHIzOD0yMCxyMzYgICAgICAgICAJLy8gWzEqSUkrMF0g
IAogfTsgewkgICAgICAubWZpCgkocDE3KSBsZmV0Y2guZXhjbCBbcjM1XSAgICAgICAJLy8g
WzEqSUkrMF0gIEwyCgkocDE3KSBub3AuZiAwICAgICAgICAgICAgICAgICAJLy8gWzEqSUkr
MF0gIAoJKHAxNykgbm9wLmkgMCA7OyAgICAgICAgICAgICAgCS8vIFsxKklJKzBdICAKIH07
IHsJICAgICAgLm1paQoJKHAxNykgbGQ0IHIzOT1bcjM0XSAgICAgICAgICAgCS8vIFsxKklJ
KzFdICBpZDoxNSBhKzB4MAoJKHAxNykgYWRkcyByNDA9MTYscjM2ICAgICAgICAgCS8vIFsx
KklJKzFdICAKCShwMTcpIGFkZHMgcjQxPTEyLHIzNiA7OyAgICAgIAkvLyBbMSpJSSsxXSAg
CiB9OyB7CSAgICAgIC5taWkKCShwMTcpIGxkNCByNDI9W3IzN10gICAgICAgICAgIAkvLyBb
MSpJSSsyXSAgaWQ6MTUgYSsweDAKCShwMTcpIGFkZHMgcjQzPTgscjM2ICAgICAgICAgIAkv
LyBbMSpJSSsyXSAgCgkocDE3KSBhZGRzIHI0ND00LHIzNiAgICAgICAgICAJLy8gWzEqSUkr
Ml0gIAogfTsgewkgICAgICAubWZpCgkocDE3KSBsZDQgcjQ1PVtyMzhdICAgICAgICAgICAJ
Ly8gWzEqSUkrMl0gIGlkOjE1IGErMHgwCgkocDE3KSBub3AuZiAwICAgICAgICAgICAgICAg
ICAJLy8gWzEqSUkrMl0gIAoJKHAxNykgbm9wLmkgMCA7OyAgICAgICAgICAgICAgCS8vIFsx
KklJKzJdICAKIH07IHsJICAgICAgLm1paQoJKHAxNykgbGQ0IHI0Nj1bcjQwXSAgICAgICAg
ICAgCS8vIFsxKklJKzNdICBpZDoxNSBhKzB4MAoJKHAxNykgYWRkIHI0Nz1yMzkscjIgICAg
ICAgICAgCS8vIFsxKklJKzNdICAKCShwMTcpIGFkZCByMzk9cjMzLHIyICAgICAgICAgIAkv
LyBbMSpJSSszXSAgCiB9OyB7CSAgICAgIC5tZmkKCShwMTcpIGxkNCByMzM9W3I0MV0gICAg
ICAgICAgIAkvLyBbMSpJSSszXSAgaWQ6MTUgYSsweDAKCShwMTcpIG5vcC5mIDAgICAgICAg
ICAgICAgICAgIAkvLyBbMSpJSSszXSAgCgkocDE3KSBub3AuaSAwIDs7ICAgICAgICAgICAg
ICAJLy8gWzEqSUkrM10gIAogfTsgewkgICAgICAubWlpCgkocDE3KSBsZDQgcjQ4PVtyNDNd
ICAgICAgICAgICAJLy8gWzEqSUkrNF0gIGlkOjE1IGErMHgwCgkocDE3KSBhZGQgcjQ5PXI0
MixyMiAgICAgICAgICAJLy8gWzEqSUkrNF0gIAoJKHAxNykgYWRkIHI0Mj1yNDUscjIgICAg
ICAgICAgCS8vIFsxKklJKzRdICAKIH07IHsJICAgICAgLm1maQoJKHAxNykgbGQ0IHI0NT1b
cjQ0XSAgICAgICAgICAgCS8vIFsxKklJKzRdICBpZDoxNSBhKzB4MAoJKHAxNykgbm9wLmYg
MCAgICAgICAgICAgICAgICAgCS8vIFsxKklJKzRdICAKCShwMTcpIG5vcC5pIDAgOzsgICAg
ICAgICAgICAgIAkvLyBbMSpJSSs0XSAgCiB9OyB7CSAgICAgIC5taWkKCShwMTcpIHN0NCBb
cjM0XT1yNDcgICAgICAgICAgIAkvLyBbMSpJSSs1XSAgaWQ6MTYgYSsweDAKCShwMTcpIGFk
ZCByMzQ9cjQ2LHIyICAgICAgICAgIAkvLyBbMSpJSSs1XSAgCgkocDE3KSBhZGQgcjQ2PXIz
MyxyMiAgICAgICAgICAJLy8gWzEqSUkrNV0gIAogfTsgewkgICAgICAubWZpCgkocDE3KSBz
dDQgW3IzN109cjQ5ICAgICAgICAgICAJLy8gWzEqSUkrNV0gIGlkOjE2IGErMHgwCgkocDE3
KSBub3AuZiAwICAgICAgICAgICAgICAgICAJLy8gWzEqSUkrNV0gIAoJKHAxNykgbm9wLmkg
MCA7OyAgICAgICAgICAgICAgCS8vIFsxKklJKzVdICAKIH07IHsJICAgICAgLm1paQoJKHAx
Nykgc3Q0IFtyNDFdPXI0NiAgICAgICAgICAgCS8vIFsxKklJKzZdICBpZDoxNiBhKzB4MAoJ
KHAxNykgYWRkIHIzNz1yNDgscjIgICAgICAgICAgCS8vIFsxKklJKzZdICAKCShwMTcpIGFk
ZCByMzM9cjQ1LHIyICAgICAgICAgIAkvLyBbMSpJSSs2XSAgCiB9OyB7CSAgICAgIC5tZmkK
CShwMTcpIHN0NCBbcjM2XT1yMzkgICAgICAgICAgIAkvLyBbMSpJSSs2XSAgaWQ6MTYgYSsw
eDAKCShwMTcpIG5vcC5mIDAgICAgICAgICAgICAgICAgIAkvLyBbMSpJSSs2XSAgCgkocDE3
KSBub3AuaSAwIDs7ICAgICAgICAgICAgICAJLy8gWzEqSUkrNl0gIAogfTsgewkgICAgICAu
bWlpCgkocDE3KSBzdDQgW3I0MF09cjM0ICAgICAgICAgICAJLy8gWzEqSUkrN10gIGlkOjE2
IGErMHgwCgkocDE3KSBhZGRzIHIzND0zMixyMzUgICAgICAgICAJLy8gWzEqSUkrN10gIAoJ
KHAxNykgYWRkcyByMzU9MzIscjM2ICAgICAgICAgCS8vIFsxKklJKzddICAKIH07IHsJICAg
ICAgLm1maQoJKHAxNykgc3Q0IFtyNDRdPXIzMyAgICAgICAgICAgCS8vIFsxKklJKzddICBp
ZDoxNiBhKzB4MAoJKHAxNykgbm9wLmYgMCAgICAgICAgICAgICAgICAgCS8vIFsxKklJKzdd
ICAKCShwMTcpIG5vcC5pIDAgOzsgICAgICAgICAgICAgIAkvLyBbMSpJSSs3XSAgCiB9OyB7
CSAgICAgIC5taWkKCShwMTcpIHN0NCBbcjM4XT1yNDIgICAgICAgICAgIAkvLyBbMSpJSSs4
XSAgaWQ6MTYgYSsweDAKCShwMTYpIGFkZHMgcjMzPTI4LHIzNSAgICAgICAgIAkvLyBbMCpJ
SSs4XSAgCgkocDE2KSBub3AuaSAwICAgICAgICAgICAgICAgICAJLy8gWzAqSUkrOF0gIAog
fTsgewkgICAgICAubWZiCgkocDE3KSBzdDQgW3I0M109cjM3ICAgICAgICAgICAJLy8gWzEq
SUkrOF0gIGlkOjE2IGErMHgwCgkocDE3KSBub3AuZiAwICAgICAgICAgICAgICAgICAJLy8g
WzEqSUkrOF0gIAoJICAgICAgYnIuY3RvcC5kcHRrLmZldyAuQkI2X21haW4gOzsJLy8gWzEq
SUkrOF0gIAogfTsKLkJCNV9tYWluOgkvLyAweDIwMAovLzxmcmVxPgovLzxmcmVxPiBCQjo1
IGZyZXF1ZW5jeSA9IDEuMDAwMDAgKGhldXJpc3RpYykKLy88ZnJlcT4KIHsJICAgICAgLm1p
YgoJICAgICAgbm9wLm0gMCAgICAgICAgICAgICAgICAgCS8vICAKCSAgICAgIG5vcC5pIDAg
ICAgICAgICAgICAgICAgIAkvLyAgCgkgICAgICBjbHJycmIgOzsgICAgICAgICAgICAgICAJ
Ly8gWzBdICAKIH07Ci5CQjNfbWFpbjoJLy8gMHgyMTAKLy88ZnJlcT4KLy88ZnJlcT4gQkI6
MyBmcmVxdWVuY3kgPSAxLjAwMDAwIChoZXVyaXN0aWMpCi8vPGZyZXE+CiB7CSAgICAgIC5t
aWkKCSAgICAgIG5vcC5tIDAgICAgICAgICAgICAgICAgIAkvLyAgCgkgICAgICBtb3YgcHI9
cjExLC0xICAgICAgICAgICAJLy8gWzBdICAKCSAgICAgIG5vcC5pIDAgOzsgICAgICAgICAg
ICAgIAkvLyAgCiB9OyB7CSAgICAgIC5taWIKCSAgICAgIG5vcC5tIDAgICAgICAgICAgICAg
ICAgIAkvLyAgCgkgICAgICBub3AuaSAwICAgICAgICAgICAgICAgICAJLy8gIAoJICAgICAg
YnIucmV0LnNwdGsubWFueSBiMCA7OyAgCS8vIFswXSAgCiB9OwoJLmVuZHAJbWFpbiMKLy8g
ZW1pdCB1bndpbmQgaW5mbwoJLnNlY3Rpb24gLklBXzY0LnVud2luZF9pbmZvCi5MdW53aW5k
X2luZm9fMDoKCWRhdGE4IDB4MTAwMDAwMDAwMDAwMQoJZGF0YTggMHg4YjEwMGU2Njg2MAoJ
LnNlY3Rpb24gLklBXzY0LnVud2luZAoJZGF0YTggQHNlZ3JlbChtYWluIykKCWRhdGE4IEBz
ZWdyZWwobWFpbiMrMHgyMzApCglkYXRhOCBAc2VncmVsKC5MdW53aW5kX2luZm9fMCkKCS5z
ZWN0aW9uIC50ZXh0CgkuYWxpZ24gMTYKLy8JLmdwdmFsdWUgMAoKCS5zZWN0aW9uIC5kZWJ1
Z19pbmZvLCAiIiwgInByb2diaXRzIgoJLmFsaWduCTAKCWRhdGExCTB4YmQsIDB4MDAsIDB4
MDAsIDB4MDAsIDB4MDIsIDB4MDAKCWRhdGE0LnVhCS5kZWJ1Z19hYmJyZXYKCWRhdGExCTB4
MDgsIDB4MDEsIDB4NmQsIDB4NmYsIDB4NjQsIDB4NzUsIDB4NmMsIDB4NmYKCWRhdGExCTB4
MmQsIDB4NzMsIDB4NjMsIDB4NjgsIDB4NjUsIDB4NjQsIDB4NzUsIDB4NmMKCWRhdGExCTB4
NjksIDB4NmUsIDB4NjcsIDB4MmUsIDB4NjMsIDB4MDAsIDB4NjgsIDB4NjEKCWRhdGExCTB4
NmUsIDB4NjQsIDB4NjUsIDB4NmMsIDB4MmUsIDB4NzcsIDB4NjksIDB4NzMKCWRhdGExCTB4
NjQsIDB4NmYsIDB4NmQsIDB4M2EsIDB4MmYsIDB4NjgsIDB4NmYsIDB4NmQKCWRhdGExCTB4
NjUsIDB4MmYsIDB4NzIsIDB4NjEsIDB4NzksIDB4NjEsIDB4MmYsIDB4NjIKCWRhdGExCTB4
NjUsIDB4NmUsIDB4NjMsIDB4NjgsIDB4NmQsIDB4NjEsIDB4NzIsIDB4NmIKCWRhdGExCTB4
NzMsIDB4MmYsIDB4NmQsIDB4NmYsIDB4NjQsIDB4NzUsIDB4NmMsIDB4NmYKCWRhdGExCTB4
MmQsIDB4NzMsIDB4NjMsIDB4NjgsIDB4NjUsIDB4NjQsIDB4NzUsIDB4NmMKCWRhdGExCTB4
NjksIDB4NmUsIDB4NjcsIDB4MDAsIDB4MmQsIDB4NGYsIDB4MzMsIDB4MjAKCWRhdGExCTB4
MmQsIDB4NjcsIDB4MzMsIDB4MDAsIDB4MDEsIDB4MDAKCWRhdGE0LnVhCS5kZWJ1Z19saW5l
CglkYXRhMQkweDAyLCAweDY5LCAweDZlLCAweDc0LCAweDAwLCAweDA1LCAweDA0LCAweDAz
CglkYXRhMQkweDRkLCAweDAwLCAweDY0LCAweDAwLCAweDAwLCAweDAwLCAweDA5LCAweDAz
CglkYXRhOC51YQlNCglkYXRhMQkweDAxLCAweDA0LCAweDY0LCAweDAwLCAweDAwLCAweDAw
LCAweDkwLCAweDAxCglkYXRhMQkweDAzLCAweDYxLCAweDAwLCAweDdkLCAweDAwLCAweDAw
LCAweDAwLCAweDA5CglkYXRhMQkweDAzCglkYXRhOC51YQlhCglkYXRhMQkweDAxLCAweDA1
LCAweDAxLCAweDA0LCAweDZkLCAweDYxLCAweDY5LCAweDZlCglkYXRhMQkweDAwLCAweDY0
LCAweDAwLCAweDAwLCAweDAwLCAweDAxLCAweDAzLCAweDkyCglkYXRhMQkweDBjLCAweDAw
CglkYXRhOC51YQkuQkIxX21haW4KCWRhdGE4LnVhCS5CQjFfbWFpbiArIDB4MjMwCglkYXRh
MQkweDA2LCAweDY5LCAweDAwLCAweDY0LCAweDAwLCAweDAwLCAweDAwLCAweDAwCglkYXRh
MQkweDAwLCAweDAwCgoJLnNlY3Rpb24gLmRlYnVnX2FyYW5nZXMsICIiLCAicHJvZ2JpdHMi
CgkuYWxpZ24JMAoJZGF0YTEJMHgyYywgMHgwMCwgMHgwMCwgMHgwMCwgMHgwMiwgMHgwMAoJ
ZGF0YTQudWEJLmRlYnVnX2luZm8KCWRhdGExCTB4MDgsIDB4MDAsIDB4MDAsIDB4MDAsIDB4
MDAsIDB4MDAKCWRhdGE4LnVhCS5CQjFfbWFpbgoJZGF0YTgudWEJLkJCMV9tYWluIC0gLkJC
MV9tYWluICsgMHgyMzAKCWRhdGExCTB4MDAsIDB4MDAsIDB4MDAsIDB4MDAsIDB4MDAsIDB4
MDAsIDB4MDAsIDB4MDAKCWRhdGExCTB4MDAsIDB4MDAsIDB4MDAsIDB4MDAsIDB4MDAsIDB4
MDAsIDB4MDAsIDB4MDAKCgkuc2VjdGlvbiAuZGVidWdfcHVibmFtZXMsICIiLCAicHJvZ2Jp
dHMiCgkuYWxpZ24JMAoJZGF0YTEJMHgyMywgMHgwMCwgMHgwMCwgMHgwMCwgMHgwMiwgMHgw
MAoJZGF0YTQudWEJLmRlYnVnX2luZm8KCWRhdGExCTB4MDAsIDB4MDAsIDB4MDAsIDB4MDAs
IDB4NmIsIDB4MDAsIDB4MDAsIDB4MDAKCWRhdGExCTB4NGQsIDB4MDAsIDB4ODQsIDB4MDAs
IDB4MDAsIDB4MDAsIDB4NjEsIDB4MDAKCWRhdGExCTB4OTYsIDB4MDAsIDB4MDAsIDB4MDAs
IDB4NmQsIDB4NjEsIDB4NjksIDB4NmUKCWRhdGExCTB4MDAsIDB4MDAsIDB4MDAsIDB4MDAs
IDB4MDAKCgkuc2VjdGlvbiAuZGVidWdfYWJicmV2LCAiIiwgInByb2diaXRzIgoJLmFsaWdu
CTAKCWRhdGExCTB4MDEsIDB4MTEsIDB4MDEsIDB4MDMsIDB4MDgsIDB4MWIsIDB4MDgsIDB4
MjUKCWRhdGExCTB4MDgsIDB4MTMsIDB4MGIsIDB4NDIsIDB4MGIsIDB4MTAsIDB4MDYsIDB4
MDAKCWRhdGExCTB4MDAsIDB4MDIsIDB4MjQsIDB4MDAsIDB4MDMsIDB4MDgsIDB4M2UsIDB4
MGIKCWRhdGExCTB4MGIsIDB4MGIsIDB4MDAsIDB4MDAsIDB4MDMsIDB4MzQsIDB4MDAsIDB4
MDMKCWRhdGExCTB4MDgsIDB4NDksIDB4MTMsIDB4MDIsIDB4MGEsIDB4M2YsIDB4MGMsIDB4
MDAKCWRhdGExCTB4MDAsIDB4MDQsIDB4MDEsIDB4MDAsIDB4NDksIDB4MTMsIDB4MGIsIDB4
MDUKCWRhdGExCTB4MDAsIDB4MDAsIDB4MDUsIDB4MmUsIDB4MDEsIDB4M2EsIDB4MGIsIDB4
M2IKCWRhdGExCTB4MGIsIDB4MDMsIDB4MDgsIDB4NDksIDB4MTMsIDB4M2YsIDB4MGMsIDB4
NDAKCWRhdGExCTB4MGEsIDB4MTEsIDB4MDEsIDB4MTIsIDB4MDEsIDB4MDAsIDB4MDAsIDB4
MDYKCWRhdGExCTB4MzQsIDB4MDAsIDB4MDMsIDB4MDgsIDB4NDksIDB4MTMsIDB4MDAsIDB4
MDAK
--------------85F90C9E80A749D387FB569E
Content-Type: text/plain; charset=us-ascii;
 name="OUT"
Content-Disposition: inline;
 filename="OUT"
Content-Transfer-Encoding: 7bit

sgicc WARNING:  modulo-scheduling_1.s modulo-scheduling_1.s will overwrite a file that has a source-file suffix
SGIcc Compilers: Version 0.01.0-9
/usr/bin/gcc -D_LANGUAGE_C -D_SGI_COMPILER_VERSION=001 -D__host_ia32 -D__INLINE_INTRINSICS -v -D__OPTIMIZE__ -D_LP64 -D__ia64=1 modulo-scheduling.c -E > /tmp/cci.Uy7Kof 
Reading specs from /usr/lib/gcc-lib/ia64-hp-linux/2.9-ia64-000216/specs
gcc version 2.9-ia64-000216 snap-000324
 /usr/lib/gcc-lib/ia64-hp-linux/2.9-ia64-000216/cpp -lang-c -v -isystem /usr/lib/gcc-lib/ia64-sgi-linux/sgicc-1.0/include -D__GNUC__=2 -D__GNUC_MINOR__=9 -D__ia64 -D__ia64__ -D__linux -D__linux__ -D_LONGLONG -Dlinux -Dunix -D__LP64__ -D__ELF__ -D__ia64 -D__ia64__ -D__linux -D__linux__ -D_LONGLONG -D__linux__ -D__unix__ -D__LP64__ -D__ELF__ -D__linux -D__unix -Asystem(linux) -Acpu(ia64) -Amachine(ia64) -D__LONG_MAX__=9223372036854775807L -D_LANGUAGE_C -D_SGI_COMPILER_VERSION=001 -D__host_ia32 -D__INLINE_INTRINSICS -D__OPTIMIZE__ -D_LP64 -D__ia64=1 modulo-scheduling.c
GNU CPP version 2.9-ia64-000216 snap-000324 (IA-64)
#include "..." search starts here:
#include <...> search starts here:
 /usr/lib/gcc-lib/ia64-sgi-linux/sgicc-1.0/include
 /usr/lib/gcc-lib/ia64-hp-linux/2.9-ia64-000216/include
 /usr/lib/gcc-lib/ia64-hp-linux/2.9-ia64-000216/../../../../ia64-hp-linux/include
End of search list.
The following default directories have been omitted from the search path:
 /usr/lib/gcc-lib/ia64-hp-linux/2.9-ia64-000216/../../../../include/g++-3
 /usr/lib/gcc-lib/ia64-hp-linux/2.9-ia64-000216/../../../../ia64-hp-linux/sys-include
End of omitted list.
/usr/lib/gcc-lib/ia64-sgi-linux/sgicc-1.0/gfec -O3 -g3 -dx -version -quiet -dumpbase modulo-scheduling.c /tmp/cci.Uy7Kof -o /tmp/ccB.qIKHmm 
GNU C version sgicc-1.0 (ia64-linux) compiled by GNU C version 2.95.2 19991024 (release).
/usr/lib/gcc-lib/ia64-sgi-linux/sgicc-1.0/be -PHASE:l:w:c -G8 -TENV:PIC -m1 -INTERNAL:return_val=on -INTERNAL:mldid_mstid=on -INTERNAL:return_info=on -show -O3 -g3 -TARG:abi=i64 -LANG:=ansi_c -fB,/tmp/ccB.qIKHmm -s -fs,modulo-scheduling_1.s modulo-scheduling.c 
Compiling modulo-scheduling.c (/tmp/ccB.qIKHmm) -- Back End
Compiling main(0)


--------------85F90C9E80A749D387FB569E--


From owner-pro64-support@oss.sgi.com Sun Nov 12 02:15:46 2000
Received:  by oss.sgi.com id <S553900AbQKLKPg>;
	Sun, 12 Nov 2000 02:15:36 -0800
Received: from narkis.wisdom.weizmann.ac.il ([132.76.80.32]:49681 "EHLO
        narkis.wisdom.weizmann.ac.il") by oss.sgi.com with ESMTP
	id <S553896AbQKLKPW>; Sun, 12 Nov 2000 02:15:22 -0800
Received: from wisdom.weizmann.ac.il (amir8-pc.wisdom.weizmann.ac.il [132.76.81.32])
	by narkis.wisdom.weizmann.ac.il (8.9.1a/8.9.1) with ESMTP id MAA20943
	for <pro64-support@oss.sgi.com>; Sun, 12 Nov 2000 12:15:36 +0200 (IST)
Message-ID: <3A0E6D2A.68984758@wisdom.weizmann.ac.il>
Date:   Sun, 12 Nov 2000 12:12:58 +0200
From:   raya <raya@wisdom.weizmann.ac.il>
Organization: Weizmann Institute of Science
X-Mailer: Mozilla 4.75 [en] (WinNT; U)
X-Accept-Language: il,en
MIME-Version: 1.0
To:     pro64 <pro64-support@oss.sgi.com>
Subject: loop unrolling bug ? (cont')
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: owner-pro64-support@oss.sgi.com
Precedence: bulk
Return-Path: <owner-pro64-support@oss.sgi.com>
X-Orcpt: rfc822;pro64-support-outgoing

Following  is additional information:

uname -a:
Linux handel 2.2.12-20smp #1 SMP Mon Sep 27 10:34:45 EDT 1999 ia64
unknown
compilation line:
sgicc -v -O3 -g -o modulo-scheduling_1.s -S modulo-scheduling.c
sgicc -version:
SGIcc Compilers: Version 0.01.0-9


--
Raya Leviathan
Tel. 972-8-9344208 (office)
Tel. 972-3-6358481 (home)
Email: raya@wisdom.weizmann.ac.il



From owner-pro64-support@oss.sgi.com Sun Nov 12 18:20:16 2000
Received:  by oss.sgi.com id <S553963AbQKMCT5>;
	Sun, 12 Nov 2000 18:19:57 -0800
Received: from beckmann.eng.umd.edu ([129.2.102.4]:39125 "EHLO
        beckmann.eng.umd.edu") by oss.sgi.com with ESMTP id <S553953AbQKMCTi>;
	Sun, 12 Nov 2000 18:19:38 -0800
Received: from fiber.eng.umd.edu (IDENT:root@fiber.eng.umd.edu [129.2.98.185])
	by beckmann.eng.umd.edu (8.9.3/8.9.3) with ESMTP id VAA11678
	for <pro64-support@oss.sgi.com>; Sun, 12 Nov 2000 21:19:34 -0500 (EST)
Received: from fiber.eng.umd.edu (IDENT:sendmail@localhost [127.0.0.1])
	by fiber.eng.umd.edu (8.9.3/8.9.3) with SMTP id VAA02970
	for <pro64-support@oss.sgi.com>; Sun, 12 Nov 2000 21:19:31 -0500 (EST)
Received: from localhost (tvinod@localhost)
	by fiber.eng.umd.edu (8.9.3/8.9.3) with ESMTP id VAA02966
	for <pro64-support@oss.sgi.com>; Sun, 12 Nov 2000 21:19:31 -0500 (EST)
X-Authentication-Warning: fiber.eng.umd.edu: tvinod owned process doing -bs
Date:   Sun, 12 Nov 2000 21:19:30 -0500 (EST)
From:   T Vinod Kumar Gupta <tvinod@Glue.umd.edu>
X-Sender: tvinod@fiber.eng.umd.edu
To:     pro64-support@oss.sgi.com
Subject: Is this a bug??
Message-ID: <Pine.GSO.4.21.0011122112090.2953-100000@fiber.eng.umd.edu>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-pro64-support@oss.sgi.com
Precedence: bulk
Return-Path: <owner-pro64-support@oss.sgi.com>
X-Orcpt: rfc822;pro64-support-outgoing

Hello All,

	I guess that control speculation is not really  implemented in
the compiler. But before that, it does some checks for the candidate ops
in the OP_To_Move function. At line 2337 of gcm.cxx, there is this line :-

---------
    if (OP_Real_Ops(cur_op) != 1 || OP_Real_Ops(cur_op) != 0)
       continue;
---------

	Now it is clear that this statement will always lead to continue
of the enclosing for statement.
	Is this intentionally done?? 

	I changed the || condition to &&.!!(I guessed it was a typo!) Now
it seems to go into speculation code but the final result is no
speculation.

	Is there something wrong, or it doesn't matter as no control spec
is anyway not being done?

Thanks
Vinod

Graduate Student
Dept. of ECE,
University of Maryland,
College Park.



From owner-pro64-support@oss.sgi.com Mon Nov 13 09:25:31 2000
Received:  by oss.sgi.com id <S553891AbQKMRZW>;
	Mon, 13 Nov 2000 09:25:22 -0800
Received: from atlrel1.hp.com ([156.153.255.210]:19413 "HELO atlrel1.hp.com")
	by oss.sgi.com with SMTP id <S553860AbQKMRZH>;
	Mon, 13 Nov 2000 09:25:07 -0800
Received: from hpfctwc.fc.hp.com (hpfctwc.fc.hp.com [15.6.247.128])
	by atlrel1.hp.com (Postfix) with ESMTP id C7181796
	for <pro64-support@oss.sgi.com>; Mon, 13 Nov 2000 12:25:05 -0500 (EST)
Received: from fc.hp.com (athena.nsr.hp.com [15.116.178.38]) by hpfctwc.fc.hp.com with ESMTP (8.8.6 (PHNE_14041)/8.8.6 SMKit7.02) id KAA20370 for <pro64-support@oss.sgi.com>; Mon, 13 Nov 2000 10:25:14 -0700 (MST)
Message-ID: <3A1023D0.ACDD6ED@fc.hp.com>
Date:   Mon, 13 Nov 2000 10:24:33 -0700
From:   Christopher Worley <cworley@fc.hp.com>
Organization: Hewlett-Packard Laboratories
X-Mailer: Mozilla 4.72 [en] (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To:     pro64 <pro64-support@oss.sgi.com>
Subject: 10 byte long double
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-pro64-support@oss.sgi.com
Precedence: bulk
Return-Path: <owner-pro64-support@oss.sgi.com>
X-Orcpt: rfc822;pro64-support-outgoing

Is there a flag that sets a long double to 10 bytes, or a data type the
represents a double-extended precision value?

--
Christopher Worley
Software Design Engineer
Hewlett-Packard Laboratories

E-Mail: cworley@fc.hp.com
Phone:  (720) 528-9500
Telnet:  (970) 898-0617
FAX:    (720) 528-9499



From owner-pro64-support@oss.sgi.com Mon Nov 13 09:43:32 2000
Received:  by oss.sgi.com id <S553891AbQKMRnM>;
	Mon, 13 Nov 2000 09:43:12 -0800
Received: from deliverator.sgi.com ([204.94.214.10]:14873 "EHLO
        deliverator.sgi.com") by oss.sgi.com with ESMTP id <S553860AbQKMRmp>;
	Mon, 13 Nov 2000 09:42:45 -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 JAA14210
	for <pro64-support@oss.sgi.com>; Mon, 13 Nov 2000 09:34:53 -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 JAA38181; Mon, 13 Nov 2000 09:38:23 -0800 (PST)
From:   "Ross A. Towle" <rat@cchkms.engr.sgi.com>
Message-Id: <10011130938.ZM32538@cchkms.engr.sgi.com>
Date:   Mon, 13 Nov 2000 09:38:21 -0800
In-Reply-To: Christopher Worley <cworley@fc.hp.com>
        "10 byte long double" (Nov 13, 10:24am)
References: <3A1023D0.ACDD6ED@fc.hp.com>
X-Mailer: Z-Mail (3.2.3 08feb96 MediaMail)
To:     Christopher Worley <cworley@fc.hp.com>,
        pro64 <pro64-support@oss.sgi.com>
Subject: Re: 10 byte long double
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: owner-pro64-support@oss.sgi.com
Precedence: bulk
Return-Path: <owner-pro64-support@oss.sgi.com>
X-Orcpt: rfc822;pro64-support-outgoing

Long doubles as extended double precision has not been implemented at
this time.

-Ross

From owner-pro64-support@oss.sgi.com Mon Nov 13 10:28:22 2000
Received:  by oss.sgi.com id <S553934AbQKMS2C>;
	Mon, 13 Nov 2000 10:28:02 -0800
Received: from deliverator.sgi.com ([204.94.214.10]:49963 "EHLO
        deliverator.sgi.com") by oss.sgi.com with ESMTP id <S553897AbQKMS1l>;
	Mon, 13 Nov 2000 10:27:41 -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 KAA23379
	for <pro64-support@oss.sgi.com>; Mon, 13 Nov 2000 10:19:49 -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 KAA38347; Mon, 13 Nov 2000 10:23:17 -0800 (PST)
From:   "Ross A. Towle" <rat@cchkms.engr.sgi.com>
Message-Id: <10011131023.ZM37193@cchkms.engr.sgi.com>
Date:   Mon, 13 Nov 2000 10:23:16 -0800
In-Reply-To: raya <raya@wisdom.weizmann.ac.il>
        "loop-unrolling bug ?" (Nov 12, 12:01pm)
References: <3A0E6A7A.C3963A73@wisdom.weizmann.ac.il>
X-Mailer: Z-Mail (3.2.3 08feb96 MediaMail)
To:     raya <raya@wisdom.weizmann.ac.il>,
        pro64 <pro64-support@oss.sgi.com>
Subject: Re: loop-unrolling bug ?
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: owner-pro64-support@oss.sgi.com
Precedence: bulk
Return-Path: <owner-pro64-support@oss.sgi.com>
X-Orcpt: rfc822;pro64-support-outgoing

On Nov 12, 12:01pm, raya wrote:
> Subject: loop-unrolling bug ?
>
> Hello,
>
> Enclosed is a c source and the assembly output of a small c loop.
> The first instruction of the loop (label: BB6_main) is:
>     ls4 r33=[r36].
> To my understanding, "r36" is not initialized in the first time the loop
> is executed, (no reg rotation was done at this stage). To my
> understanding pr17 is set to "1" in the first execution of the loop. Am
> I worng?

Yes you are mistaken.  This loop is using rotating registers.  On the
initial iteration p16 is true an the others are false. This is done
 outside the loop by mov pr.rot=65536

-Ross


>
> Thanks,
> --
> Raya Leviathan
> Tel. 972-8-9344208 (office)
> Tel. 972-3-6358481 (home)
> Email: raya@wisdom.weizmann.ac.il
>
>
> [ Attachment (application/x-unknown-content-type-c_auto_file):
"modulo-scheduling.c" 121 bytes
>   Encoded with "base64" ]
>
> [ Attachment (application/x-unknown-content-type-S_auto_file):
"modulo-scheduling_1.s" 13947 bytes
>   Encoded with "base64" ]
>
> [ text/plain ] :
>
> sgicc WARNING:  modulo-scheduling_1.s modulo-scheduling_1.s will overwrite a
file that has a source-file suffix
> SGIcc Compilers: Version 0.01.0-9
> /usr/bin/gcc -D_LANGUAGE_C -D_SGI_COMPILER_VERSION=001 -D__host_ia32
-D__INLINE_INTRINSICS -v -D__OPTIMIZE__ -D_LP64 -D__ia64=1 modulo-scheduling.c
-E > /tmp/cci.Uy7Kof
> Reading specs from /usr/lib/gcc-lib/ia64-hp-linux/2.9-ia64-000216/specs
> gcc version 2.9-ia64-000216 snap-000324
>  /usr/lib/gcc-lib/ia64-hp-linux/2.9-ia64-000216/cpp -lang-c -v -isystem
/usr/lib/gcc-lib/ia64-sgi-linux/sgicc-1.0/include -D__GNUC__=2
-D__GNUC_MINOR__=9 -D__ia64 -D__ia64__ -D__linux -D__linux__ -D_LONGLONG
-Dlinux -Dunix -D__LP64__ -D__ELF__ -D__ia64 -D__ia64__ -D__linux -D__linux__
-D_LONGLONG -D__linux__ -D__unix__ -D__LP64__ -D__ELF__ -D__linux -D__unix
-Asystem(linux) -Acpu(ia64) -Amachine(ia64) -D__LONG_MAX__=9223372036854775807L
-D_LANGUAGE_C -D_SGI_COMPILER_VERSION=001 -D__host_ia32 -D__INLINE_INTRINSICS
-D__OPTIMIZE__ -D_LP64 -D__ia64=1 modulo-scheduling.c
> GNU CPP version 2.9-ia64-000216 snap-000324 (IA-64)
> #include "..." search starts here:
> #include <...> search starts here:
>  /usr/lib/gcc-lib/ia64-sgi-linux/sgicc-1.0/include
>  /usr/lib/gcc-lib/ia64-hp-linux/2.9-ia64-000216/include
>  /usr/lib/gcc-lib/ia64-hp-linux/2.9-ia64-000216/../../../../ia64-hp-linux/include
> End of search list.
> The following default directories have been omitted from the search path:
>  /usr/lib/gcc-lib/ia64-hp-linux/2.9-ia64-000216/../../../../include/g++-3
>  /usr/lib/gcc-lib/ia64-hp-linux/2.9-ia64-000216/../../../../ia64-hp-linux/sys-include
> End of omitted list.
> /usr/lib/gcc-lib/ia64-sgi-linux/sgicc-1.0/gfec -O3 -g3 -dx -version -quiet
-dumpbase modulo-scheduling.c /tmp/cci.Uy7Kof -o /tmp/ccB.qIKHmm
> GNU C version sgicc-1.0 (ia64-linux) compiled by GNU C version 2.95.2
19991024 (release).
> /usr/lib/gcc-lib/ia64-sgi-linux/sgicc-1.0/be -PHASE:l:w:c -G8 -TENV:PIC -m1
-INTERNAL:return_val=on -INTERNAL:mldid_mstid=on -INTERNAL:return_info=on -show
-O3 -g3 -TARG:abi=i64 -LANG:=ansi_c -fB,/tmp/ccB.qIKHmm -s
-fs,modulo-scheduling_1.s modulo-scheduling.c
> Compiling modulo-scheduling.c (/tmp/ccB.qIKHmm) -- Back End
> Compiling main(0)
>
>-- End of excerpt from raya



From owner-pro64-support@oss.sgi.com Tue Nov 14 17:06:42 2000
Received:  by oss.sgi.com id <S553865AbQKOBGc>;
	Tue, 14 Nov 2000 17:06:32 -0800
Received: from [159.226.39.1] ([159.226.39.1]:59919 "HELO ns.ict.ac.cn")
	by oss.sgi.com with SMTP id <S553844AbQKOBG2>;
	Tue, 14 Nov 2000 17:06:28 -0800
Received: (qmail 10715 invoked from network); 15 Nov 2000 01:01:23 -0000
Received: from unknown (HELO act200) (159.226.40.246)
  by ns.ict.ac.cn with SMTP; 15 Nov 2000 01:01:23 -0000
Message-ID: <002101c04ea0$39b96880$260379c8@act200>
From:   "Liu Yang" <ly@ict.ac.cn>
To:     "pro64" <pro64-support@oss.sgi.com>
Subject: 
Date:   Wed, 15 Nov 2000 09:06:03 +0800
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_001E_01C04EE3.47C724B0"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2919.6700
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700
Sender: owner-pro64-support@oss.sgi.com
Precedence: bulk
Return-Path: <owner-pro64-support@oss.sgi.com>
X-Orcpt: rfc822;pro64-support-outgoing

This is a multi-part message in MIME format.

------=_NextPart_000_001E_01C04EE3.47C724B0
Content-Type: text/plain;
	charset="gb2312"
Content-Transfer-Encoding: quoted-printable

Hello,Everyone!
Could you find some info about the following problems I meet?
1 When I read the source code of Pro64,the comment said that:
Loop unrolling is performed by: BB *CG_LOOP_Unroll(LOOP_DESCR *loop), =
which
returns a new unrolled body if the loop is unrolled.  It may also create =
a
"remainder loop" in the prolog or epilog.
=20
But I do not found this function in Pro64.And another function
unroll_multi_BB never been called in Pro64.I want to know whether this =
is
true.
=20
2 In Single_BB_Do_Loop_SWP,is unrolling also done?
=20
3 Before unroll,the whole loop converted to a single BB,is that true?
=20
Thanks!
=20
With my best regards,

Liu Yang

Advanced Compiler Lab
Institute of Computing Technology
Chinese Academy of Science
E-Mail :  ly@ict.ac.cn


------=_NextPart_000_001E_01C04EE3.47C724B0
Content-Type: text/html;
	charset="gb2312"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META content=3D"text/html; charset=3Dgb2312" http-equiv=3DContent-Type>
<META content=3D"MSHTML 5.00.2920.0" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3DArial size=3D2>Hello,Everyone!</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>Could you find some info about the =
following=20
problems I meet?<BR>1 When I read the source code of Pro64,the comment =
said=20
that:<BR>Loop unrolling is performed by: BB *CG_LOOP_Unroll(LOOP_DESCR =
*loop),=20
which<BR>returns a new unrolled body if the loop is unrolled.&nbsp; It =
may also=20
create a<BR>"remainder loop" in the prolog or epilog.<BR>&nbsp;<BR>But I =
do not=20
found this function in Pro64.And another function<BR>unroll_multi_BB =
never been=20
called in Pro64.I want to know whether this is<BR>true.<BR>&nbsp;<BR>2 =
In=20
Single_BB_Do_Loop_SWP,is unrolling also done?<BR>&nbsp;<BR>3 Before =
unroll,the=20
whole loop converted to a single BB,is that=20
true?<BR>&nbsp;<BR>Thanks!<BR>&nbsp;<BR>With my best =
regards,<BR></DIV></FONT>
<DIV><FONT face=3DArial size=3D2>Liu Yang</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>Advanced Compiler Lab<BR>Institute of =
Computing=20
Technology<BR>Chinese Academy of Science<BR>E-Mail :&nbsp; <A=20
href=3D"mailto:ly@ict.ac.cn">ly@ict.ac.cn</A><BR></FONT></DIV></BODY></HT=
ML>

------=_NextPart_000_001E_01C04EE3.47C724B0--


From owner-pro64-support@oss.sgi.com Tue Nov 14 17:45:12 2000
Received:  by oss.sgi.com id <S553686AbQKOBpC>;
	Tue, 14 Nov 2000 17:45:02 -0800
Received: from [209.21.47.226] ([209.21.47.226]:12304 "EHLO
        therouter.routefree.com") by oss.sgi.com with ESMTP
	id <S553677AbQKOBpA>; Tue, 14 Nov 2000 17:45:00 -0800
Received: from routefree.com (IDENT:lo@osprey.routefree.com [10.0.0.35])
	by therouter.routefree.com (8.9.3/8.9.3) with ESMTP id RAA07285;
	Tue, 14 Nov 2000 17:44:36 -0800
Message-ID: <3A11F893.392FC5AF@routefree.com>
Date:   Tue, 14 Nov 2000 18:44:35 -0800
From:   Raymond Lo <lo@routefree.com>
Organization: RouteFree Inc.
X-Mailer: Mozilla 4.73 [en] (X11; U; Linux 2.2.14-5.0 i686)
X-Accept-Language: en
MIME-Version: 1.0
To:     Liu Yang <ly@ict.ac.cn>, sun.c.chan@intel.com
CC:     pro64 <pro64-support@oss.sgi.com>
Subject: Re: 
References: <002101c04ea0$39b96880$260379c8@act200>
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-pro64-support@oss.sgi.com
Precedence: bulk
Return-Path: <owner-pro64-support@oss.sgi.com>
X-Orcpt: rfc822;pro64-support-outgoing

<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
<body bgcolor="#FFFFFF">
Liu Yang wrote:
<blockquote TYPE=CITE><style></style>
<font face="Arial"><font size=-1>Hello,Everyone!</font></font><font face="Arial"><font size=-1>Could
you find some info about the following problems I meet?</font></font>
<br><font face="Arial"><font size=-1>1 When I read the source code of Pro64,the
comment said that:</font></font>
<br><font face="Arial"><font size=-1>Loop unrolling is performed by: BB
*CG_LOOP_Unroll(LOOP_DESCR *loop), which</font></font>
<br><font face="Arial"><font size=-1>returns a new unrolled body if the
loop is unrolled.&nbsp; It may also create a</font></font>
<br><font face="Arial"><font size=-1>"remainder loop" in the prolog or
epilog.</font></font>
<p><font face="Arial"><font size=-1>But I do not found this function in
Pro64.And another function</font></font>
<br><font face="Arial"><font size=-1>unroll_multi_BB never been called
in Pro64.I want to know whether this is</font></font>
<br><font face="Arial"><font size=-1>true.</font></font>
<p><font face="Arial"><font size=-1>2 In Single_BB_Do_Loop_SWP,is unrolling
also done?</font></font>
<p><font face="Arial"><font size=-1>3 Before unroll,the whole loop converted
to a single BB,is that true?</font></font>
<p><font face="Arial"><font size=-1>Thanks!</font></font>
<p><font face="Arial"><font size=-1>With my best regards,</font></font><font face="Arial"><font size=-1>Liu
Yang</font></font>&nbsp;<font face="Arial"><font size=-1>Advanced Compiler
Lab</font></font>
<br><font face="Arial"><font size=-1>Institute of Computing Technology</font></font>
<br><font face="Arial"><font size=-1>Chinese Academy of Science</font></font>
<br><font face="Arial"><font size=-1>E-Mail :&nbsp; <a href="mailto:ly@ict.ac.cn">ly@ict.ac.cn</a></font></font></blockquote>

<p><br>CG_LOOP_Unroll has been replaced by CG_LOOP_Optimize.&nbsp; Most
of your questions can be answered by examining CG_LOOP_Otpimize.&nbsp;
It controls the interaction between unrolling and other optimizations.&nbsp;&nbsp;&nbsp;
It invokes Unroll_Do_Loop and Unroll_Dowhile_Loop to do the actual unrolling.&nbsp;&nbsp;
Unrolling of multibb loop has not been supported/finished.&nbsp; Unrolling
of single BB loop (swp, no swp, do-loop, dowhile-loop) are supported.&nbsp;
See Unroll_Do_Loop and Unroll_Dowhile_Loop.&nbsp;&nbsp; Inexpensive if-conversion
is performed before entering CG_LOOP_Optimize.&nbsp;&nbsp; CG_LOOP_Optimize,
before performing unrolling, invokes Force_If_Convert to carry out more
expensive if-conversions if the cost can be justified by the benefit of
SWP&nbsp;or unrolling.
<p>&nbsp;-Raymond
</body>
</html>


From owner-pro64-support@oss.sgi.com Tue Nov 14 18:05:13 2000
Received:  by oss.sgi.com id <S553678AbQKOCFD>;
	Tue, 14 Nov 2000 18:05:03 -0800
Received: from [159.226.39.1] ([159.226.39.1]:19217 "HELO ns.ict.ac.cn")
	by oss.sgi.com with SMTP id <S553671AbQKOCEn>;
	Tue, 14 Nov 2000 18:04:43 -0800
Received: (qmail 14443 invoked from network); 15 Nov 2000 02:00:01 -0000
Received: from unknown (HELO act200) (159.226.40.246)
  by ns.ict.ac.cn with SMTP; 15 Nov 2000 02:00:01 -0000
Message-ID: <00a101c04ea8$69ef8130$260379c8@act200>
From:   "Liu Yang" <ly@ict.ac.cn>
To:     "Raymond Lo" <lo@routefree.com>
Cc:     "pro64" <pro64-support@oss.sgi.com>, <sun.c.chan@intel.com>
References: <002101c04ea0$39b96880$260379c8@act200> <3A11F893.392FC5AF@routefree.com>
Subject: Re: 
Date:   Wed, 15 Nov 2000 10:04:39 +0800
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_009E_01C04EEB.7770B4D0"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2919.6700
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700
Sender: owner-pro64-support@oss.sgi.com
Precedence: bulk
Return-Path: <owner-pro64-support@oss.sgi.com>
X-Orcpt: rfc822;pro64-support-outgoing

This is a multi-part message in MIME format.

------=_NextPart_000_009E_01C04EEB.7770B4D0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Thanks,Raymond.

I found that before in the construction function of  CG_LOOP,all loops =
will be added a prolog and epilog,
the epilog and prolog is not only for SWP,is that right?

Thanks!
With my best regards,
Liu Yang

  ----- Original Message -----=20
  From: Raymond Lo=20
  To: Liu Yang ; sun.c.chan@intel.com=20
  Cc: pro64=20
  Sent: Wednesday, November 15, 2000 10:44 AM
  Subject: Re:=20


  Liu Yang wrote:=20
    Hello,Everyone!Could you find some info about the following problems =
I meet?=20
    1 When I read the source code of Pro64,the comment said that:=20
    Loop unrolling is performed by: BB *CG_LOOP_Unroll(LOOP_DESCR =
*loop), which=20
    returns a new unrolled body if the loop is unrolled.  It may also =
create a=20
    "remainder loop" in the prolog or epilog.=20
    But I do not found this function in Pro64.And another function=20
    unroll_multi_BB never been called in Pro64.I want to know whether =
this is=20
    true.=20

    2 In Single_BB_Do_Loop_SWP,is unrolling also done?=20

    3 Before unroll,the whole loop converted to a single BB,is that =
true?=20

    Thanks!=20

    With my best regards,Liu Yang Advanced Compiler Lab=20
    Institute of Computing Technology=20
    Chinese Academy of Science=20
    E-Mail :  ly@ict.ac.cn


  CG_LOOP_Unroll has been replaced by CG_LOOP_Optimize.  Most of your =
questions can be answered by examining CG_LOOP_Otpimize.  It controls =
the interaction between unrolling and other optimizations.    It invokes =
Unroll_Do_Loop and Unroll_Dowhile_Loop to do the actual unrolling.   =
Unrolling of multibb loop has not been supported/finished.  Unrolling of =
single BB loop (swp, no swp, do-loop, dowhile-loop) are supported.  See =
Unroll_Do_Loop and Unroll_Dowhile_Loop.   Inexpensive if-conversion is =
performed before entering CG_LOOP_Optimize.   CG_LOOP_Optimize, before =
performing unrolling, invokes Force_If_Convert to carry out more =
expensive if-conversions if the cost can be justified by the benefit of =
SWP or unrolling.=20

   -Raymond=20


------=_NextPart_000_009E_01C04EEB.7770B4D0
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META content=3D"text/html; charset=3Diso-8859-1" =
http-equiv=3DContent-Type>
<META content=3D"MSHTML 5.00.2920.0" name=3DGENERATOR></HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3DArial size=3D2>Thanks,Raymond.</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV>I found that before&nbsp;in the construction function of  =
CG_LOOP,all loops=20
will be added a prolog and epilog,</DIV>
<DIV>the&nbsp;epilog and prolog is not only for&nbsp;SWP,is that =
right?</DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>Thanks!</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>With my best regards,</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>Liu Yang</FONT></DIV>
<DIV><FONT face=3DArial size=3D2><SPAN lang=3DEN-US=20
style=3D"FONT-FAMILY: 'Times New Roman'; FONT-SIZE: 10.5pt; =
mso-bidi-font-size: 12.0pt; mso-fareast-font-family: &#23435;&#20307;; =
mso-font-kerning: 1.0pt; mso-ansi-language: EN-US; mso-fareast-language: =
ZH-CN; mso-bidi-language: AR-SA"><SPAN=20
lang=3DEN-US=20
style=3D"FONT-FAMILY: 'Times New Roman'; FONT-SIZE: 10.5pt; =
mso-bidi-font-size: 12.0pt; mso-fareast-font-family: &#23435;&#20307;; =
mso-font-kerning: 1.0pt; mso-ansi-language: EN-US; mso-fareast-language: =
ZH-CN; mso-bidi-language: AR-SA"><SPAN=20
lang=3DEN-US=20
style=3D"FONT-FAMILY: 'Times New Roman'; FONT-SIZE: 10.5pt; =
mso-bidi-font-size: 12.0pt; mso-fareast-font-family: &#23435;&#20307;; =
mso-font-kerning: 1.0pt; mso-ansi-language: EN-US; mso-fareast-language: =
ZH-CN; mso-bidi-language: =
AR-SA"></SPAN></SPAN></SPAN></FONT>&nbsp;</DIV>
<BLOCKQUOTE=20
style=3D"BORDER-LEFT: #000000 2px solid; MARGIN-LEFT: 5px; MARGIN-RIGHT: =
0px; PADDING-LEFT: 5px; PADDING-RIGHT: 0px">
  <DIV style=3D"FONT: 10pt arial">----- Original Message ----- </DIV>
  <DIV=20
  style=3D"BACKGROUND: #e4e4e4; FONT: 10pt arial; font-color: =
black"><B>From:</B>=20
  <A href=3D"mailto:lo@routefree.com" title=3Dlo@routefree.com>Raymond =
Lo</A> </DIV>
  <DIV style=3D"FONT: 10pt arial"><B>To:</B> <A =
href=3D"mailto:ly@ict.ac.cn"=20
  title=3Dly@ict.ac.cn>Liu Yang</A> ; <A =
href=3D"mailto:sun.c.chan@intel.com"=20
  title=3Dsun.c.chan@intel.com>sun.c.chan@intel.com</A> </DIV>
  <DIV style=3D"FONT: 10pt arial"><B>Cc:</B> <A=20
  href=3D"mailto:pro64-support@oss.sgi.com"=20
  title=3Dpro64-support@oss.sgi.com>pro64</A> </DIV>
  <DIV style=3D"FONT: 10pt arial"><B>Sent:</B> Wednesday, November 15, =
2000 10:44=20
  AM</DIV>
  <DIV style=3D"FONT: 10pt arial"><B>Subject:</B> Re: </DIV>
  <DIV><BR></DIV>Liu Yang wrote:=20
  <BLOCKQUOTE TYPE=3D"CITE">
    <STYLE></STYLE>
    <FONT face=3DArial><FONT =
size=3D-1>Hello,Everyone!</FONT></FONT><FONT=20
    face=3DArial><FONT size=3D-1>Could you find some info about the =
following=20
    problems I meet?</FONT></FONT> <BR><FONT face=3DArial><FONT =
size=3D-1>1 When I=20
    read the source code of Pro64,the comment said that:</FONT></FONT> =
<BR><FONT=20
    face=3DArial><FONT size=3D-1>Loop unrolling is performed by: BB=20
    *CG_LOOP_Unroll(LOOP_DESCR *loop), which</FONT></FONT> <BR><FONT=20
    face=3DArial><FONT size=3D-1>returns a new unrolled body if the loop =
is=20
    unrolled.&nbsp; It may also create a</FONT></FONT> <BR><FONT=20
    face=3DArial><FONT size=3D-1>"remainder loop" in the prolog or=20
    epilog.</FONT></FONT>=20
    <P><FONT face=3DArial><FONT size=3D-1>But I do not found this =
function in=20
    Pro64.And another function</FONT></FONT> <BR><FONT =
face=3DArial><FONT=20
    size=3D-1>unroll_multi_BB never been called in Pro64.I want to know =
whether=20
    this is</FONT></FONT> <BR><FONT face=3DArial><FONT =
size=3D-1>true.</FONT></FONT>=20

    <P><FONT face=3DArial><FONT size=3D-1>2 In Single_BB_Do_Loop_SWP,is =
unrolling=20
    also done?</FONT></FONT>=20
    <P><FONT face=3DArial><FONT size=3D-1>3 Before unroll,the whole loop =
converted=20
    to a single BB,is that true?</FONT></FONT>=20
    <P><FONT face=3DArial><FONT size=3D-1>Thanks!</FONT></FONT>=20
    <P><FONT face=3DArial><FONT size=3D-1>With my best =
regards,</FONT></FONT><FONT=20
    face=3DArial><FONT size=3D-1>Liu Yang</FONT></FONT>&nbsp;<FONT =
face=3DArial><FONT=20
    size=3D-1>Advanced Compiler Lab</FONT></FONT> <BR><FONT =
face=3DArial><FONT=20
    size=3D-1>Institute of Computing Technology</FONT></FONT> <BR><FONT=20
    face=3DArial><FONT size=3D-1>Chinese Academy of =
Science</FONT></FONT> <BR><FONT=20
    face=3DArial><FONT size=3D-1>E-Mail :&nbsp; <A=20
    =
href=3D"mailto:ly@ict.ac.cn">ly@ict.ac.cn</A></FONT></FONT></P></BLOCKQUO=
TE>
  <P><BR>CG_LOOP_Unroll has been replaced by CG_LOOP_Optimize.&nbsp; =
Most of=20
  your questions can be answered by examining CG_LOOP_Otpimize.&nbsp; It =

  controls the interaction between unrolling and other=20
  optimizations.&nbsp;&nbsp;&nbsp; It invokes Unroll_Do_Loop and=20
  Unroll_Dowhile_Loop to do the actual unrolling.&nbsp;&nbsp; Unrolling =
of=20
  multibb loop has not been supported/finished.&nbsp; Unrolling of =
single BB=20
  loop (swp, no swp, do-loop, dowhile-loop) are supported.&nbsp; See=20
  Unroll_Do_Loop and Unroll_Dowhile_Loop.&nbsp;&nbsp; Inexpensive =
if-conversion=20
  is performed before entering CG_LOOP_Optimize.&nbsp;&nbsp; =
CG_LOOP_Optimize,=20
  before performing unrolling, invokes Force_If_Convert to carry out =
more=20
  expensive if-conversions if the cost can be justified by the benefit =
of=20
  SWP&nbsp;or unrolling.=20
  <P>&nbsp;-Raymond </P></BLOCKQUOTE></BODY></HTML>

------=_NextPart_000_009E_01C04EEB.7770B4D0--


From owner-pro64-support@oss.sgi.com Tue Nov 14 18:38:33 2000
Received:  by oss.sgi.com id <S553686AbQKOCiY>;
	Tue, 14 Nov 2000 18:38:24 -0800
Received: from [209.21.47.226] ([209.21.47.226]:16656 "EHLO
        therouter.routefree.com") by oss.sgi.com with ESMTP
	id <S553677AbQKOCiE>; Tue, 14 Nov 2000 18:38:04 -0800
Received: from routefree.com (IDENT:lo@osprey.routefree.com [10.0.0.35])
	by therouter.routefree.com (8.9.3/8.9.3) with ESMTP id SAA07755;
	Tue, 14 Nov 2000 18:37:15 -0800
Message-ID: <3A1204E9.CD5219ED@routefree.com>
Date:   Tue, 14 Nov 2000 19:37:13 -0800
From:   Raymond Lo <lo@routefree.com>
Organization: RouteFree Inc.
X-Mailer: Mozilla 4.73 [en] (X11; U; Linux 2.2.14-5.0 i686)
X-Accept-Language: en
MIME-Version: 1.0
To:     Liu Yang <ly@ict.ac.cn>
CC:     pro64 <pro64-support@oss.sgi.com>, sun.c.chan@intel.com
Subject: Re: 
References: <002101c04ea0$39b96880$260379c8@act200> <3A11F893.392FC5AF@routefree.com> <00a101c04ea8$69ef8130$260379c8@act200>
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-pro64-support@oss.sgi.com
Precedence: bulk
Return-Path: <owner-pro64-support@oss.sgi.com>
X-Orcpt: rfc822;pro64-support-outgoing

<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
<body bgcolor="#FFFFFF">
Liu Yang wrote:
<blockquote TYPE=CITE>&nbsp;<font face="Arial"><font size=-1>Thanks,Raymond.</font></font>&nbsp;I
found that before in the construction function of CG_LOOP,all loops will
be added a prolog and epilog,the epilog and prolog is not only for SWP,is
that right?&nbsp;</blockquote>

<p><br>You're right.&nbsp;&nbsp; -Raymond
</body>
</html>


From owner-pro64-support@oss.sgi.com Thu Nov 16 01:34:53 2000
Received:  by oss.sgi.com id <S553681AbQKPJen>;
	Thu, 16 Nov 2000 01:34:43 -0800
Received: from [159.226.39.1] ([159.226.39.1]:15115 "HELO ns.ict.ac.cn")
	by oss.sgi.com with SMTP id <S553648AbQKPJe0>;
	Thu, 16 Nov 2000 01:34:26 -0800
Received: (qmail 6770 invoked from network); 16 Nov 2000 09:29:48 -0000
Received: from unknown (HELO act200) (159.226.40.246)
  by ns.ict.ac.cn with SMTP; 16 Nov 2000 09:29:48 -0000
Message-ID: <007301c04fb0$6349e740$260379c8@act200>
From:   "Liu Yang" <ly@ict.ac.cn>
To:     "pro64" <pro64-support@oss.sgi.com>, <sun.c.chan@intel.com>,
        "Ju, Roy" <roy.ju@intel.com>
Cc:     "MAILLIST" <pro64@act.ict.ac.cn>
Subject: 
Date:   Thu, 16 Nov 2000 17:34:15 +0800
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_0070_01C04FF3.710DC930"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2919.6700
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700
Sender: owner-pro64-support@oss.sgi.com
Precedence: bulk
Return-Path: <owner-pro64-support@oss.sgi.com>
X-Orcpt: rfc822;pro64-support-outgoing

This is a multi-part message in MIME format.

------=_NextPart_000_0070_01C04FF3.710DC930
Content-Type: text/plain;
	charset="gb2312"
Content-Transfer-Encoding: quoted-printable

Hello,everyone.
In CG,the CFLOW_Optimize will be called.I read the source and found that =
Freq_Order_Blocks may be called in the CFLOW_Optimize =
function.Freq_Oreder_Block may create cold regions,this may lead to some =
trouble.But I am not quite sure whether the Freq_Order_Block will be =
called in CG's CFLOW_Optimize for I have not read that part in detail.=20
Could you please give me some help about this question?
Thanks!

With my best regards,
Liu Yang

Graduate Student
Advanced Compiler Lab
Institute of Computing Technology
Chinese Academy of Science
E-Mail :  ly@ict.ac.cn


------=_NextPart_000_0070_01C04FF3.710DC930
Content-Type: text/html;
	charset="gb2312"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META content=3D"text/html; charset=3Dgb2312" http-equiv=3DContent-Type>
<META content=3D"MSHTML 5.00.2920.0" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3DArial size=3D2>Hello,everyone.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>In CG,the CFLOW_Optimize will be =
called.I read the=20
source and found that Freq_Order_Blocks may be called in the =
CFLOW_Optimize=20
function.Freq_Oreder_Block may create cold regions,this may lead to some =

trouble.But I am not quite sure whether the Freq_Order_Block will be =
called in=20
CG's CFLOW_Optimize for I have not read that part in detail. =
</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>Could you please give me some help =
about this=20
question?</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>Thanks!</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>With my best regards,</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>Liu Yang</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>Graduate Student</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>Advanced Compiler Lab<BR>Institute of =
Computing=20
Technology<BR>Chinese Academy of Science<BR>E-Mail :&nbsp; <A=20
href=3D"mailto:ly@ict.ac.cn">ly@ict.ac.cn</A><BR></FONT></DIV></BODY></HT=
ML>

------=_NextPart_000_0070_01C04FF3.710DC930--


From owner-pro64-support@oss.sgi.com Thu Nov 16 06:15:44 2000
Received:  by oss.sgi.com id <S553733AbQKPOPe>;
	Thu, 16 Nov 2000 06:15:34 -0800
Received: from pneumatic-tube.sgi.com ([204.94.214.22]:58445 "EHLO
        pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP
	id <S553715AbQKPOPZ>; Thu, 16 Nov 2000 06:15:25 -0800
Received: from sgihud.hudson.sgi.com (sgihud.hudson.sgi.com [169.238.41.4]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id GAA01921
	for <pro64-support@oss.sgi.com>; Thu, 16 Nov 2000 06:23:12 -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 JAA89181; Thu, 16 Nov 2000 09:10:21 -0500 (EST)
Date:   Thu, 16 Nov 2000 09:10:21 -0500 (EST)
From:   lesniak@sgihud.hudson.sgi.com (Ken Lesniak)
Message-Id: <200011161410.JAA89181@sgihud.hudson.sgi.com>
To:     "Ju, Roy" <roy.ju@intel.com>, <sun.c.chan@intel.com>,
        "pro64" <pro64-support@oss.sgi.com>, "Liu Yang" <ly@ict.ac.cn>
Cc:     "MAILLIST" <pro64@act.ict.ac.cn>
Reply-To: lesniak@sgihud.hudson.sgi.com
Sender: owner-pro64-support@oss.sgi.com
Precedence: bulk
Return-Path: <owner-pro64-support@oss.sgi.com>
X-Orcpt: rfc822;pro64-support-outgoing

>Hello,everyone.
>In CG,the CFLOW_Optimize will be called.I read the source and found that =
>Freq_Order_Blocks may be called in the CFLOW_Optimize =
>function.Freq_Oreder_Block may create cold regions,this may lead to some =
>trouble.But I am not quite sure whether the Freq_Order_Block will be =
>called in CG's CFLOW_Optimize for I have not read that part in detail.=20
>Could you please give me some help about this question?
>Thanks!
>
>With my best regards,
>Liu Yang

I'm not 100% sure what you're asking here.

Freq_Order_Blocks is indeed called for any opt level above -O0.

But to the best of my memory, I don't believe it will create an
explicit cold region as I think we needed some more tool support to
fully support this feature.

Hope this helps...

Ken

From owner-pro64-support@oss.sgi.com Thu Nov 16 12:06:27 2000
Received:  by oss.sgi.com id <S553766AbQKPUGH>;
	Thu, 16 Nov 2000 12:06:07 -0800
Received: from deliverator.sgi.com ([204.94.214.10]:20250 "EHLO
        deliverator.sgi.com") by oss.sgi.com with ESMTP id <S553759AbQKPUFo>;
	Thu, 16 Nov 2000 12:05:44 -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 LAA01725
	for <pro64-support@oss.sgi.com>; Thu, 16 Nov 2000 11:57:52 -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 MAA03226 for pro64-support@oss.sgi.com; Thu, 16 Nov 2000 12:02:32 -0800 (PST)
From:   "Ross A. Towle" <rat@cchkms.engr.sgi.com>
Message-Id: <10011161202.ZM3169@cchkms.engr.sgi.com>
Date:   Thu, 16 Nov 2000 12:02:31 -0800
X-Mailer: Z-Mail (3.2.3 08feb96 MediaMail)
To:     pro64-support@oss.sgi.com
Subject: a friendly reminder
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: owner-pro64-support@oss.sgi.com
Precedence: bulk
Return-Path: <owner-pro64-support@oss.sgi.com>
X-Orcpt: rfc822;pro64-support-outgoing

email sent to pro64-support@oss.sgi.com is reflected to EVERY subscriber
on the mail list.  Thus what is sent becomes publicly known.

Please do not submit a but report containing proprietary code.

-Ross

From owner-pro64-support@oss.sgi.com Mon Nov 27 11:19:22 2000
Received:  by oss.sgi.com id <S553652AbQK0TTD>;
	Mon, 27 Nov 2000 11:19:03 -0800
Received: from dymwsm05.mailwatch.com ([204.253.83.41]:29194 "EHLO
        dymwsm05.mailwatch.com") by oss.sgi.com with ESMTP
	id <S553647AbQK0TSc>; Mon, 27 Nov 2000 11:18:32 -0800
Received: from dymw0104.mailwatch.com (dymw0104.allegro.net [204.253.83.244])
	by dymwsm05.mailwatch.com (8.11.0/8.11.0) with SMTP id eARJIGG18859
	for <pro64-support@oss.sgi.com>; Mon, 27 Nov 2000 14:18:17 -0500
Received: from 204.253.83.26 by dymw0104.mailwatch.com with ESMTP (
 WorldSecure Server SMTP Relay(WSS) v4.3); Mon, 27 Nov 00 14:18:16 -0500
X-Server-Uuid: d007647a-7e79-11d4-a501-00508bd358de
Received: from eccmfw2.ford.com (mailfw2.ford.com [136.1.1.27]) by
 dymwsm11.mailwatch.com (8.11.0/8.11.0) with ESMTP id eARJIGM02216 for
 <pro64-support@oss.sgi.com>; Mon, 27 Nov 2000 14:18:16 -0500
Message-ID: <200011271918.eARJIGM02216@dymwsm11.mailwatch.com>
Received: by mailfw2.ford.com id OAA28574 (InterLock SMTP Gateway 4.2
 for pro64-support@oss.sgi.com); Mon, 27 Nov 2000 14:17:59 -0500 (EST)
Received: by mailfw2.ford.com (Internal Mail Agent-1); Mon, 27 Nov 2000
 14:17:59 -0500 (EST)
Received: by mailfw2.ford.com (Internal Mail Agent-0); Mon, 27 Nov 2000
 14:17:59 -0500 (EST)
Date:   Mon, 27 Nov 2000 14:17:46 -0500
From:   "Penney, Chris" <cpenney@ford.com>
X-Mailer: Mozilla 4.73C-CCK-MCD vg_472 [en] (X11; U; HP-UX B.10.20
 9000/770)
X-Accept-Language: en,en-GB,de,fr,ja,ko,zh
MIME-Version: 1.0
To:     pro64-support@oss.sgi.com
Subject: Pro64 Fortran Compiler Frequently Segmentation Faults
X-WSS-ID: 163C6CF29332-01-01
Content-Type: text/plain; 
 charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-pro64-support@oss.sgi.com
Precedence: bulk
Return-Path: <owner-pro64-support@oss.sgi.com>
X-Orcpt: rfc822;pro64-support-outgoing

Hi.  I work for Ford and we have a ia64 box on loan from Dell that we
are using to run some Fortran / C code (for very rough benchmarking). 
We have the latest SGIpro compilers as listed on the web site and we
have having a problem where the Fortran compiler randomly seg faults and
dumps core during compilation.  I included some examples below.  The
faults don't happen consistently, in fact many times I can just rerun
'make' and it will build the file.

Is there a new version of the compilers I could try?  Can I help by
providing core files?

Machine Specifics:

   OS: Red Hat Linux release 6.97 (Pinstripe)
       Kernel 2.4.0-0.34smp on an ia64
   uname -a: Linux pms248 2.4.0-0.34smp #1 SMP Wed Nov 1 15:25:40 EST
2000 ia64 unknown
   sgicc -version: SGIcc Compilers: Version 0.01.0-12

Examples:

sgif90 -I/mnt/share/home/tchapm10/mpich/build/LINUX/ch_p4/include -O1 -c
eclosure.f
Signal: Segmentation fault in Hyberlock Scheduler phase.
Error: Signal Segmentation fault in phase Hyberlock Scheduler --
processing aborted
sgif90 ERROR:  /usr/lib/gcc-lib/ia64-sgi-linux/sgicc-1.0/be died due to
signal 4
sgif90 ERROR:  core dumped
make: *** [eclosure.o] Error 32


sgif90 -I/mnt/share/home/tchapm10/mpich/build/LINUX/ch_p4/include -O2 -c
cellpct.f
Signal: Segmentation fault in Global Optimization -- MainOpt emitter
phase.
Error: Signal Segmentation fault in phase Global Optimization -- MainOpt
emitter -- processing aborted
sgif90 ERROR:  /usr/lib/gcc-lib/ia64-sgi-linux/sgicc-1.0/be died due to
signal 4
sgif90 ERROR:  core dumped


From owner-pro64-support@oss.sgi.com Mon Nov 27 11:28:12 2000
Received:  by oss.sgi.com id <S553655AbQK0T1x>;
	Mon, 27 Nov 2000 11:27:53 -0800
Received: from munch-it.turbolinux.com ([38.170.88.129]:12530 "EHLO
        mail.us.tlan") by oss.sgi.com with ESMTP id <S553647AbQK0T1i>;
	Mon, 27 Nov 2000 11:27:38 -0800
Received: (from nobody@localhost)
	by mail.us.tlan (8.9.3/8.9.3) id LAA11127;
	Mon, 27 Nov 2000 11:27:19 -0800
Received: from ariel.dev.us.tlan(172.16.12.158), claiming to be "turbolinux.com"
 via SMTP by mail.us.tlan, id smtpdOgtRRZ; Mon Nov 27 11:27:11 2000
Message-ID: <3A22B58F.9F16A17F@turbolinux.com>
Date:   Mon, 27 Nov 2000 11:27:11 -0800
From:   Uros Prestor <uros@turbolinux.com>
Organization: Turbolinux Inc.
X-Mailer: Mozilla 4.74 [en] (X11; U; Linux 2.2.13-12 i686)
X-Accept-Language: sl, en
MIME-Version: 1.0
To:     "Penney, Chris" <cpenney@ford.com>
CC:     pro64-support@oss.sgi.com
Subject: Re: Pro64 Fortran Compiler Frequently Segmentation Faults
References: <200011271918.eARJIGM02216@dymwsm11.mailwatch.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-pro64-support@oss.sgi.com
Precedence: bulk
Return-Path: <owner-pro64-support@oss.sgi.com>
X-Orcpt: rfc822;pro64-support-outgoing

"Penney, Chris" wrote:

> Hi.  I work for Ford and we have a ia64 box on loan from Dell that we
> are using to run some Fortran / C code (for very rough benchmarking).
> We have the latest SGIpro compilers as listed on the web site and we
> have having a problem where the Fortran compiler randomly seg faults and
> dumps core during compilation.  I included some examples below.  The
> faults don't happen consistently, in fact many times I can just rerun
> 'make' and it will build the file.

This is not a problem with the Pro64 compiler -- it's the kernel you're
using.  I can't tell which version/IA-64 snapshot you're running based on
the uname output but from the build date (Nov 1) it appears to be a fairly
recent one.  There have been some problems with random segfaults with newer
kernels, especially on Lion servers (which are very similar to your Dell
box).

You might want to contact RedHat for a kernel upgrade.

Uros


--
Uros Prestor
uros@turbolinux.com




From owner-pro64-support@oss.sgi.com Wed Nov 29 03:45:00 2000
Received:  by oss.sgi.com id <S553735AbQK2Lok>;
	Wed, 29 Nov 2000 03:44:40 -0800
Received: from narkis.wisdom.weizmann.ac.il ([132.76.80.32]:60933 "EHLO
        narkis.wisdom.weizmann.ac.il") by oss.sgi.com with ESMTP
	id <S553721AbQK2LoZ>; Wed, 29 Nov 2000 03:44:25 -0800
Received: from wisdom.weizmann.ac.il (amir8-pc.wisdom.weizmann.ac.il [132.76.81.32])
	by narkis.wisdom.weizmann.ac.il (8.9.1a/8.9.1) with ESMTP id NAA01720
	for <pro64-support@oss.sgi.com>; Wed, 29 Nov 2000 13:44:13 +0200 (IST)
Message-ID: <3A24EC01.CE1D8997@wisdom.weizmann.ac.il>
Date:   Wed, 29 Nov 2000 13:44:01 +0200
From:   raya <raya@wisdom.weizmann.ac.il>
Organization: Weizmann Institute of Science
X-Mailer: Mozilla 4.75 [en] (WinNT; U)
X-Accept-Language: il,en
MIME-Version: 1.0
To:     pro64 <pro64-support@oss.sgi.com>
Subject: Very Low Whirl
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: owner-pro64-support@oss.sgi.com
Precedence: bulk
Return-Path: <owner-pro64-support@oss.sgi.com>
X-Orcpt: rfc822;pro64-support-outgoing

Hello,
Is there a way  (i.e. a trace flag) to print the very-low whirl which is
used internally in the code generator?
Is it possible to print out information about  register content,: for
exampe: register Ri has the address of array a, etc.

Thanks,
--
Raya Leviathan
Tel. 972-8-9344208 (office)
Tel. 972-3-6358481 (home)
Email: raya@wisdom.weizmann.ac.il



From owner-pro64-support@oss.sgi.com Wed Nov 29 10:35:34 2000
Received:  by oss.sgi.com id <S553772AbQK2SfO>;
	Wed, 29 Nov 2000 10:35:14 -0800
Received: from pneumatic-tube.sgi.com ([204.94.214.22]:16422 "EHLO
        pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP
	id <S553763AbQK2SfL>; Wed, 29 Nov 2000 10:35:11 -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 KAA02091
	for <pro64-support@oss.sgi.com>; Wed, 29 Nov 2000 10:42:33 -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 KAA93671; Wed, 29 Nov 2000 10:32:42 -0800 (PST)
Date:   Wed, 29 Nov 2000 10:32:42 -0800 (PST)
From:   mpm@rohi.engr.sgi.com (Michael Murphy)
Message-Id: <200011291832.KAA93671@rohi.engr.sgi.com>
To:     pro64 <pro64-support@oss.sgi.com>,
        raya <raya@wisdom.weizmann.ac.il>
Subject: Re:  Very Low Whirl
Sender: owner-pro64-support@oss.sgi.com
Precedence: bulk
Return-Path: <owner-pro64-support@oss.sgi.com>
X-Orcpt: rfc822;pro64-support-outgoing

	From: raya <raya@wisdom.weizmann.ac.il>
	
	Hello,
	Is there a way  (i.e. a trace flag) to print the very-low whirl which is
	used internally in the code generator?

-Wb,-trlow will print out the whirl as it is lowered, with the last dump
showing the whirl that enters CG.  Note that CG itself takes whirl input
and immediately translates it to instructions and then operates on the
instructions.  -Wb,-ttexp:7 will show the translation of whirl into
CG's instruction format (TOPs).  -Wb,-trexp will show show the TOPs after
cgexp, which is the first phase of CG.

	Is it possible to print out information about  register content,: for
	exampe: register Ri has the address of array a, etc.
	
Not really, because the same register can hold multiple values at different
times.  The .s file has comments that show what object a memory location
refers to, which is also in dumps like -Wb,-tremt (the final representation
of TOPs).
-- Mike Murphy
-- mpm@sgi.com
-- quote of the day:
--  "Power offers an easy substitute for the hard task of love.
--   It seems easier to be God than to love God,
--   easier to control people than to love people,
--   easier to own life than to love life."  (Henri Nouwen)

From owner-pro64-support@oss.sgi.com Thu Nov 30 05:50:17 2000
Received:  by oss.sgi.com id <S553838AbQK3Nt5>;
	Thu, 30 Nov 2000 05:49:57 -0800
Received: from thalia.fm.intel.com ([132.233.247.11]:53253 "EHLO
        thalia.fm.intel.com") by oss.sgi.com with ESMTP id <S553683AbQK3Ntx>;
	Thu, 30 Nov 2000 05:49:53 -0800
Received: from SMTP (fmsmsxvs01-1.fm.intel.com [132.233.42.201])
	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 NAA26090
	for <pro64-support@oss.sgi.com>; Thu, 30 Nov 2000 13:50:56 GMT
Received: from fmsmsx27.FM.INTEL.COM ([132.233.48.27]) by 132.233.48.201
  (Norton AntiVirus for Internet Email Gateways 1.0) ;
  Thu, 30 Nov 2000 13:49:37 0000 (GMT)
Received: by fmsmsx27.fm.intel.com with Internet Mail Service (5.5.2650.21)
	id <X7VHH4YL>; Thu, 30 Nov 2000 05:49:36 -0800
Message-ID: <D3DFF77F2F31D211AC3F00A0C9962CDC05702FA0@irsmsx31.ir.intel.com>
From:   "Faccini, Bruno" <bruno.faccini@intel.com>
To:     pro64-support@oss.sgi.com
Subject: "Register Stack Engine" issue with Calling sequences of a lot (>8
	0) of formal parameters ??
Date:   Thu, 30 Nov 2000 05:49:33 -0800
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/mixed;
	boundary="----_=_NextPart_000_01C05AD4.5ED57D30"
Sender: owner-pro64-support@oss.sgi.com
Precedence: bulk
Return-Path: <owner-pro64-support@oss.sgi.com>
X-Orcpt: rfc822;pro64-support-outgoing

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_000_01C05AD4.5ED57D30
Content-Type: text/plain;
	charset="iso-8859-1"


We are currently running with an issue, using Pro64 Fortran compiler with
"-O[1-3]" optimization levels, where the code generated appear to use
earlier defined as "output" (as per the "Register Stack Engine" feature and
its related "alloc" instruction) registers as "local"/scratch ones and this
just prior a call to an underlying subroutine which then bombs due to its
use/assumption about the validity of its corresponding "input"
parameters/registers.

This type/number of call/arguments is quite usual within the application and
this problem seem to only happen in one very special case :

	_ 84 formal parameters to be passed between caller and callee.  

	_ some of these parameters/variables, and at least the one concerned
by the pb, have simply been already passed and received from the previous
caller and not used in the current and intermediate one but simply passed to
the next callees/routines.
 
	_ this only happen for the second and different routine call from
the same caller, and this with about the same number of arguments, where a
lot are also identical between both different routines calls and mainly the
one finally causing the crash/problem in the second callee !! This
particular comment/case may be the trick where the compiler might correctly
prepare the concerned argument for the first callee and then forget to
keep/save it for the next/2nd callee.

The only way to avoid such behavior has been to compile the "calling"
routine/module with "-O0" option.

Are there any known current limitations/issues regarding the number of
arguments to be passed between subroutines and related to the "Register
Stack Engine" feature ??

Seems also, and according to some other assembly code calling sequences
generated by Pro64 Fortan compiler, that there is a default minimum (8 ?)
numbers of formal parameters to be passed thru the "Register Stack Engine",
is this true ??

Is there also any possibility/option to explicitelly avoid the "Register
Stack Engine" usage by Pro64 compilers ??

Will try to provide a test-case, or at least some debugging and generated
assembly code snapshots to better document this problem asap, but already
thank's for any help, idea or answer.

Best Regards.

Bruno.

Bruno Faccini - Tech. Mktg. Engr.
Technical Marketing/Internet Solutions Group (EMEA)
Intel GmbH, Germany
Phone (Intel office): +33-(0)146947228
Fax: +33-(0)146947068
email: bruno.faccini@intel.com

 <<Bruno Faccini (E-mail).vcf>> 

------_=_NextPart_000_01C05AD4.5ED57D30
Content-Type: application/octet-stream;
	name="Bruno Faccini (E-mail).vcf"
Content-Disposition: attachment;
	filename="Bruno Faccini (E-mail).vcf"

BEGIN:VCARD
VERSION:2.1
N:Faccini;Bruno
FN:Bruno Faccini (E-mail)
ORG:Intel;Technical Marketing/Content Group EMEA
TITLE:Tech. Mktg. Engr.
TEL;WORK;VOICE:+33 (0) 146947228
TEL;WORK;VOICE:+33 (0) 155498427
TEL;WORK;FAX:+33 (0) 146947068
ADR;WORK;ENCODING=QUOTED-PRINTABLE:;Munich, Germany.;Intel Corporation=0D=0ATour Chenonceaux=0D=0A204 Rond Poin=
t Du Pont De Sevres;Boulogne Billancourt;Cedex;92516;France
LABEL;WORK;ENCODING=QUOTED-PRINTABLE:Munich, Germany.=0D=0AIntel Corporation=0D=0ATour Chenonceaux=0D=0A204 Rond =
Point Du Pont De Sevres=0D=0ABoulogne Billancourt, Cedex 92516=0D=0AFrance
ADR;HOME:;;20 Rue Du Marechal Joffre;Brie Comte Robert;;77170;France
LABEL;HOME;ENCODING=QUOTED-PRINTABLE:20 Rue Du Marechal Joffre=0D=0ABrie Comte Robert 77170=0D=0AFrance
EMAIL;PREF;INTERNET:bruno.faccini@intel.com
REV:20001111T162700Z
END:VCARD

------_=_NextPart_000_01C05AD4.5ED57D30--


From owner-pro64-support@oss.sgi.com Thu Nov 30 11:21:40 2000
Received:  by oss.sgi.com id <S553899AbQK3TVT>;
	Thu, 30 Nov 2000 11:21:19 -0800
Received: from deliverator.sgi.com ([204.94.214.10]:24601 "EHLO
        deliverator.sgi.com") by oss.sgi.com with ESMTP id <S553896AbQK3TUq>;
	Thu, 30 Nov 2000 11:20:46 -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 LAA05713
	for <pro64-support@oss.sgi.com>; Thu, 30 Nov 2000 11:20:45 -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 LAA99458; Thu, 30 Nov 2000 11:17:52 -0800 (PST)
Date:   Thu, 30 Nov 2000 11:17:52 -0800 (PST)
From:   mpm@rohi.engr.sgi.com (Michael Murphy)
Message-Id: <200011301917.LAA99458@rohi.engr.sgi.com>
To:     pro64-support@oss.sgi.com,
        "Faccini, Bruno" <bruno.faccini@intel.com>
Subject: Re:  "Register Stack Engine" issue with Calling sequences of a lot (>8
    0) of formal parameters ??
Sender: owner-pro64-support@oss.sgi.com
Precedence: bulk
Return-Path: <owner-pro64-support@oss.sgi.com>
X-Orcpt: rfc822;pro64-support-outgoing

	From: "Faccini, Bruno" <bruno.faccini@intel.com>

We would need a test case to demonstrate your problem.
The calling convention states that the first 8 parameters are passed 
in registers, but the rest are passed on the stack.  
However, we also use register-stack "output" registers
as caller-save temporaries in the caller routine.

-- Mike Murphy
-- mpm@sgi.com
-- quote of the day:
--  "It is not what a man does that determines whether his work is
--   sacred or secular, it is why he does it.  
--   The motive is everything."  (A.W. Tozer)