From owner-pro64-support@oss.sgi.com Wed Aug 1 11:16:44 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f71IGid09637 for pro64-support-outgoing; Wed, 1 Aug 2001 11:16:44 -0700 Received: from mail.ee.gatech.edu (mail.ee.gatech.edu [130.207.225.105]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f71IGgV09634 for ; Wed, 1 Aug 2001 11:16:42 -0700 Received: from magic.ece-int.gatech.edu.ece.gatech.edu (IDENT:hardnett@magic.ece-int.gatech.edu [192.168.10.206]) by mail.ee.gatech.edu (8.11.3/8.11.0) with SMTP id f71IGfA20229 for ; Wed, 1 Aug 2001 14:16:41 -0400 (EDT) Message-ID: <3B670084.34817E35@cc.gatech.edu> X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.2.17-21mdksmp i686) X-Accept-Language: en MIME-Version: 1.0 Newsgroups: comp.compilers Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: 4f7069f0b0e259e81f0970430f0a0f7e From: Charles Hardnett Subject: GCC Front End: Finding the location of a Symbol Definition Date: Tue, 31 Jul 2001 15:01:24 -0400 Sender: owner-pro64-support@oss.sgi.com Precedence: bulk Hi Everyone, I fixed the problem of having declarations elaborating within if, while, etc. consditional expressions. For those that are interested, a new context was needed for var decls that determines whether the type should be an incomplete or complete type specification. Now I have a another problem that needs some support from gfec. The problem I am currently experiencing is that the resulting source code will regenerate the type definition for a composite type i.e. a struct or union that is actually defined in a library header file. So, when the new code is compiled I get a redefinition error. Example: #include ... struct stat mbuf; .... is translated into: struct stat { ... ... } mbuf; And so now the #include and this definition conflict. This happens because during the retranslation the module encounters stat for the first time in the declaration of mbuf and then creates a declaration for it. This is a problem with any type defined in a header file such as a struct.. My Idea: If the GCC frontend determines that struct stat is defined in another location either a library header or another file, then I want to preserve this information to have the BE translator use it to determine whether or not to create a definition of this type. Does anyone have any idea of how / where I can get this kind of information? or any other suggestions on how to tackle this problem. Thanks, Charles -- -------------------------------------------------------------------- Charles R. Hardnett CREST at Ga Tech www.crest.gatech.edu From owner-pro64-support@oss.sgi.com Thu Aug 2 04:46:42 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f72Bkg806284 for pro64-support-outgoing; Thu, 2 Aug 2001 04:46:42 -0700 Received: from beta.dmz-eu.st.com (beta.dmz-eu.st.com [164.129.1.35]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f72BkZV06264 for ; Thu, 2 Aug 2001 04:46:36 -0700 Received: from zeta.dmz-eu.st.com (zeta.dmz-eu.st.com [164.129.230.9]) by beta.dmz-eu.st.com (STMicroelectronics) with SMTP id 2E1374AA6 for ; Thu, 2 Aug 2001 11:44:33 +0000 (GMT) Received: by zeta.dmz-eu.st.com (STMicroelectronics, from userid 0) id 3EA5A4A4A; Thu, 2 Aug 2001 11:44:38 +0000 (GMT) Received: from eux220.sgp.st.com (localhost [127.0.0.1]) by zeta.dmz-eu.st.com (STMicroelectronics) with ESMTP id 166E71845 for ; Thu, 2 Aug 2001 11:44:38 +0000 (GMT) Received: from gnx009.gnb.st.com (gnx009.gnb.st.com [164.129.103.229]) by eux220.sgp.st.com (8.9.3 (PHNE_18546)/8.8.6) with ESMTP id NAA00413 for ; Thu, 2 Aug 2001 13:44:32 +0200 (METDST) Received: from st.com (pcx0011.gnb.st.com [164.129.122.42]) by gnx009.gnb.st.com (8.9.3 (PHNE_18546)/8.8.6) with ESMTP id NAA10462; Thu, 2 Aug 2001 13:44:31 +0200 (METDST) Message-ID: <3B693D1F.A6F1ECE9@st.com> Date: Thu, 02 Aug 2001 13:44:31 +0200 From: Arthur Stoutchinin Reply-To: Arthur.Stoutchinin@st.com Organization: STMicroelectronics X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.14-5.0 i686) X-Accept-Language: ru, en MIME-Version: 1.0 To: pro64-support@oss.sgi.com, Arthur.Stoutchinin@st.com Subject: How are ARRAYs represented in WHIRL ? Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-pro64-support@oss.sgi.com Precedence: bulk In the following example: 2-dimensional arrays seem to be represented as 1-dimensional array of 1-dimensional arrays, therefore WN_num_dim(array) = 1. How will it be recognized in the back-end as being WN_num_dim(array) = 2 ? The fact that it is a single-dimensional array seems to annoy ARRAY_ACCESS analysis in the LNO (Do_Automatic_Transformation in lno/snl_test.cxx). A.Stoutchinin =============================================================== C program: void interchange () { int i, j; short x[1000][100]; short a[1000][100]; for (i=0; i<1000; i++) { for (j=0; j<100; j++) { x[i][j] = x[i][j] * a[i][j]; } } for (i=0; i<1000; i++) { for (j=0; j<100; j++) { printf ("%d\n", x[i][j]); } } return; } =============================================================== The front-end WHIRL output looks like so: =============================================================== LOC 1 4 FUNC_ENTRY <1,39,interchange> BODY BLOCK END_BLOCK BLOCK END_BLOCK BLOCK PRAGMA 0 120 0 (0x0) # PREAMBLE_END LOC 1 9 I4INTCONST 0 (0x0) I4STID 0 <2,1,i> T<4,.predef_I4,4> WHILE_DO I4I4LDID 0 <2,1,i> T<4,.predef_I4,4> I4INTCONST 999 (0x3e7) I4I4LE BODY BLOCK LOC 1 10 I4INTCONST 0 (0x0) I4STID 0 <2,2,j> T<4,.predef_I4,4> WHILE_DO I4I4LDID 0 <2,2,j> T<4,.predef_I4,4> I4INTCONST 99 (0x63) I4I4LE BODY BLOCK LOC 1 11 A4LDA 0 <2,3,x> T<49,anon_ptr.,4> I4INTCONST 1000 (0x3e8) I4I4LDID 0 <2,1,i> T<4,.predef_I4,4> A4ARRAY 1 200 I4INTCONST 100 (0x64) I4I4LDID 0 <2,2,j> T<4,.predef_I4,4> A4ARRAY 1 2 I4I2ILOAD 0 T<3,.predef_I2,2> T<50,anon_ptr.,4> A4LDA 0 <2,4,a> T<49,anon_ptr.,4> I4INTCONST 1000 (0x3e8) I4I4LDID 0 <2,1,i> T<4,.predef_I4,4> A4ARRAY 1 200 I4INTCONST 100 (0x64) I4I4LDID 0 <2,2,j> T<4,.predef_I4,4> A4ARRAY 1 2 I4I2ILOAD 0 T<3,.predef_I2,2> T<50,anon_ptr.,4> I4MPY A4LDA 0 <2,3,x> T<49,anon_ptr.,4> I4INTCONST 1000 (0x3e8) I4I4LDID 0 <2,1,i> T<4,.predef_I4,4> A4ARRAY 1 200 I4INTCONST 100 (0x64) I4I4LDID 0 <2,2,j> T<4,.predef_I4,4> A4ARRAY 1 2 I2ISTORE 0 T<50,anon_ptr.,4> LOC 1 12 LABEL L2 0 I4I4LDID 0 <2,2,j> T<4,.predef_I4,4> I4INTCONST 1 (0x1) I4ADD I4STID 0 <2,2,j> T<4,.predef_I4,4> END_BLOCK LOC 1 13 LABEL L1 0 I4I4LDID 0 <2,1,i> T<4,.predef_I4,4> I4INTCONST 1 (0x1) I4ADD I4STID 0 <2,1,i> T<4,.predef_I4,4> END_BLOCK LOC 1 15 I4INTCONST 0 (0x0) I4STID 0 <2,1,i> T<4,.predef_I4,4> WHILE_DO I4I4LDID 0 <2,1,i> T<4,.predef_I4,4> I4INTCONST 999 (0x3e7) I4I4LE BODY BLOCK LOC 1 16 I4INTCONST 0 (0x0) I4STID 0 <2,2,j> T<4,.predef_I4,4> WHILE_DO I4I4LDID 0 <2,2,j> T<4,.predef_I4,4> I4INTCONST 99 (0x63) I4I4LE BODY BLOCK LOC 1 17 A4LDA 0 <1,41,(4_bytes)_"%d\n\000"> T<53,anon_ptr.,4> A4PARM 2 T<30,anon_ptr.,4> # by_value A4LDA 0 <2,3,x> T<49,anon_ptr.,4> I4INTCONST 1000 (0x3e8) I4I4LDID 0 <2,1,i> T<4,.predef_I4,4> A4ARRAY 1 200 I4INTCONST 100 (0x64) I4I4LDID 0 <2,2,j> T<4,.predef_I4,4> A4ARRAY 1 2 I4I2ILOAD 0 T<4,.predef_I4,4> T<50,anon_ptr.,4> I4PARM 2 T<4,.predef_I4,4> # by_value VCALL 126 <1,40,printf> # flags 0x7e LOC 1 18 LABEL L4 0 I4I4LDID 0 <2,2,j> T<4,.predef_I4,4> I4INTCONST 1 (0x1) I4ADD I4STID 0 <2,2,j> T<4,.predef_I4,4> END_BLOCK LOC 1 19 LABEL L3 0 I4I4LDID 0 <2,1,i> T<4,.predef_I4,4> I4INTCONST 1 (0x1) I4ADD I4STID 0 <2,1,i> T<4,.predef_I4,4> END_BLOCK LOC 1 21 RETURN END_BLOCK From owner-pro64-support@oss.sgi.com Thu Aug 2 10:53:26 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f72HrQ213433 for pro64-support-outgoing; Thu, 2 Aug 2001 10:53:26 -0700 Received: from yog-sothoth.sgi.com (eugate.sgi.com [192.48.160.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f72HrOV13430 for ; Thu, 2 Aug 2001 10:53:24 -0700 Received: from rohi.engr.sgi.com (rohi.engr.sgi.com [130.62.180.74]) by yog-sothoth.sgi.com (980305.SGI.8.8.8-aspam-6.2/980304.SGI-aspam-europe) via ESMTP id TAA540209 for ; Thu, 2 Aug 2001 19:51:12 +0200 (CEST) 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 KAA44444; Thu, 2 Aug 2001 10:50:49 -0700 (PDT) Date: Thu, 2 Aug 2001 10:50:49 -0700 (PDT) From: mpm@rohi.engr.sgi.com (Michael Murphy) Message-Id: <200108021750.KAA44444@rohi.engr.sgi.com> To: Arthur.Stoutchinin@st.com, pro64-support@oss.sgi.com, Arthur.Stoutchinin@st.com Subject: Re: How are ARRAYs represented in WHIRL ? Sender: owner-pro64-support@oss.sgi.com Precedence: bulk A known limitation in gfec is that it does not recognize multi-dimensional arrays, instead treating them as arrays of arrays. This hinders performance, as lno and other optimizations expect multi-dimensional information. sgif90 will produce the better array format. -- Mike Murphy -- mpm@sgi.com -- quote of the day: -- "The ultimate measure of a man is not where he stands in moments of -- comfort and convenience, but where he stands at times of challenge -- and controversy." (Martin Luther King, Jr.) From owner-pro64-support@oss.sgi.com Thu Aug 2 15:56:28 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f72MuS701674 for pro64-support-outgoing; Thu, 2 Aug 2001 15:56:28 -0700 Received: from web3501.mail.yahoo.com (web3501.mail.yahoo.com [216.115.111.68]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f72MuPV01661 for ; Thu, 2 Aug 2001 15:56:25 -0700 Message-ID: <20010802225625.23850.qmail@web3501.mail.yahoo.com> Received: from [156.153.254.42] by web3501.mail.yahoo.com via HTTP; Thu, 02 Aug 2001 15:56:25 PDT Date: Thu, 2 Aug 2001 15:56:25 -0700 (PDT) From: Shin-Ming Liu Subject: Re: How are ARRAYs represented in WHIRL ? To: Arthur.Stoutchinin@st.com, pro64-support@oss.sgi.com In-Reply-To: <3B693D1F.A6F1ECE9@st.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-pro64-support@oss.sgi.com Precedence: bulk This is something has not been done since the initial port of SGI compiler from MIPS to Itanium, because gcc's internal tree represents C multi-dimensional arrays as array of array. As the result, the LNO for C won't be able to match the performance of F90 multi-dimentional array. I believe this is something on the TODO list. I would encourge developers in Pro64 community to sign up this activity. It is absolutely crucial for C/C++ performance. Shin --- Arthur Stoutchinin wrote: > In the following example: > > 2-dimensional arrays seem to be represented as > 1-dimensional array of > 1-dimensional arrays, therefore WN_num_dim(array) = > 1. How will it be > recognized > in the back-end as being WN_num_dim(array) = 2 ? The > fact that > it is a single-dimensional array seems to annoy > ARRAY_ACCESS analysis in > > the LNO (Do_Automatic_Transformation in > lno/snl_test.cxx). > > A.Stoutchinin > > =============================================================== > C program: > > void interchange () { > int i, j; > short x[1000][100]; > short a[1000][100]; > > for (i=0; i<1000; i++) { > for (j=0; j<100; j++) { > x[i][j] = x[i][j] * a[i][j]; > } > } > > for (i=0; i<1000; i++) { > for (j=0; j<100; j++) { > printf ("%d\n", x[i][j]); > } > } > > return; > } > > =============================================================== > The front-end WHIRL output looks like so: > =============================================================== > > LOC 1 4 > FUNC_ENTRY <1,39,interchange> > BODY > BLOCK > END_BLOCK > BLOCK > END_BLOCK > BLOCK > PRAGMA 0 120 0 (0x0) # PREAMBLE_END > LOC 1 9 > I4INTCONST 0 (0x0) > I4STID 0 <2,1,i> T<4,.predef_I4,4> > WHILE_DO > I4I4LDID 0 <2,1,i> T<4,.predef_I4,4> > I4INTCONST 999 (0x3e7) > I4I4LE > BODY > BLOCK > LOC 1 10 > I4INTCONST 0 (0x0) > I4STID 0 <2,2,j> T<4,.predef_I4,4> > WHILE_DO > I4I4LDID 0 <2,2,j> T<4,.predef_I4,4> > I4INTCONST 99 (0x63) > I4I4LE > BODY > BLOCK > LOC 1 11 > A4LDA 0 <2,3,x> T<49,anon_ptr.,4> > I4INTCONST 1000 (0x3e8) > I4I4LDID 0 <2,1,i> T<4,.predef_I4,4> > A4ARRAY 1 200 > I4INTCONST 100 (0x64) > I4I4LDID 0 <2,2,j> T<4,.predef_I4,4> > A4ARRAY 1 2 > I4I2ILOAD 0 T<3,.predef_I2,2> T<50,anon_ptr.,4> > A4LDA 0 <2,4,a> T<49,anon_ptr.,4> > I4INTCONST 1000 (0x3e8) > I4I4LDID 0 <2,1,i> T<4,.predef_I4,4> > A4ARRAY 1 200 > I4INTCONST 100 (0x64) > I4I4LDID 0 <2,2,j> T<4,.predef_I4,4> > A4ARRAY 1 2 > I4I2ILOAD 0 T<3,.predef_I2,2> T<50,anon_ptr.,4> > I4MPY > A4LDA 0 <2,3,x> T<49,anon_ptr.,4> > I4INTCONST 1000 (0x3e8) > I4I4LDID 0 <2,1,i> T<4,.predef_I4,4> > A4ARRAY 1 200 > I4INTCONST 100 (0x64) > I4I4LDID 0 <2,2,j> T<4,.predef_I4,4> > A4ARRAY 1 2 > I2ISTORE 0 T<50,anon_ptr.,4> > LOC 1 12 > LABEL L2 0 > I4I4LDID 0 <2,2,j> T<4,.predef_I4,4> > I4INTCONST 1 (0x1) > I4ADD > I4STID 0 <2,2,j> T<4,.predef_I4,4> > END_BLOCK > LOC 1 13 > LABEL L1 0 > I4I4LDID 0 <2,1,i> T<4,.predef_I4,4> > I4INTCONST 1 (0x1) > I4ADD > I4STID 0 <2,1,i> T<4,.predef_I4,4> > END_BLOCK > LOC 1 15 > I4INTCONST 0 (0x0) > I4STID 0 <2,1,i> T<4,.predef_I4,4> > WHILE_DO > I4I4LDID 0 <2,1,i> T<4,.predef_I4,4> > I4INTCONST 999 (0x3e7) > I4I4LE > BODY > BLOCK > LOC 1 16 > I4INTCONST 0 (0x0) > I4STID 0 <2,2,j> T<4,.predef_I4,4> > WHILE_DO > I4I4LDID 0 <2,2,j> T<4,.predef_I4,4> > I4INTCONST 99 (0x63) > I4I4LE > BODY > BLOCK > LOC 1 17 > A4LDA 0 <1,41,(4_bytes)_"%d\n\000"> > T<53,anon_ptr.,4> > A4PARM 2 T<30,anon_ptr.,4> # by_value > A4LDA 0 <2,3,x> T<49,anon_ptr.,4> > I4INTCONST 1000 (0x3e8) > I4I4LDID 0 <2,1,i> T<4,.predef_I4,4> > A4ARRAY 1 200 > I4INTCONST 100 (0x64) > I4I4LDID 0 <2,2,j> T<4,.predef_I4,4> > A4ARRAY 1 2 > I4I2ILOAD 0 T<4,.predef_I4,4> T<50,anon_ptr.,4> > I4PARM 2 T<4,.predef_I4,4> # by_value > VCALL 126 <1,40,printf> # flags 0x7e > LOC 1 18 > LABEL L4 0 > I4I4LDID 0 <2,2,j> T<4,.predef_I4,4> > I4INTCONST 1 (0x1) > I4ADD > I4STID 0 <2,2,j> T<4,.predef_I4,4> > END_BLOCK > LOC 1 19 > LABEL L3 0 > I4I4LDID 0 <2,1,i> T<4,.predef_I4,4> > I4INTCONST 1 (0x1) > I4ADD > I4STID 0 <2,1,i> T<4,.predef_I4,4> > END_BLOCK > LOC 1 21 > RETURN > END_BLOCK > > __________________________________________________ Do You Yahoo!? Make international calls for as low as $.04/minute with Yahoo! Messenger http://phonecard.yahoo.com/ From owner-pro64-support@oss.sgi.com Fri Aug 10 00:54:13 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7A7sD104688 for pro64-support-outgoing; Fri, 10 Aug 2001 00:54:13 -0700 Received: from www.pspl.co.in (www.pspl.co.in [202.54.11.65]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7A7sAV04685 for ; Fri, 10 Aug 2001 00:54:12 -0700 Received: from hubli (gateway.pspl.co.in [203.199.147.2]) by www.pspl.co.in (8.11.0/8.11.0) with SMTP id f7A7pOY16622 for ; Fri, 10 Aug 2001 13:21:24 +0530 Reply-To: From: "Venkatesh Hammigi" To: Subject: Does sgicc supports linker option -export-dynamic? Date: Fri, 10 Aug 2001 13:35:58 +0530 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 Importance: Normal Sender: owner-pro64-support@oss.sgi.com Precedence: bulk Hello, I would like to know that whether the "sgicc" handles the linker option -export-dynamic or not. I am using pro64-0.01.0-13ia64.rpm on Itanium box. Any help is appreciated, Regards, Venkatesh H From owner-pro64-support@oss.sgi.com Fri Aug 10 11:05:31 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7AI5VX18920 for pro64-support-outgoing; Fri, 10 Aug 2001 11:05:31 -0700 Received: from yog-sothoth.sgi.com (eugate.sgi.com [192.48.160.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7AI5RV18917 for ; Fri, 10 Aug 2001 11:05:28 -0700 Received: from rohi.engr.sgi.com (rohi.engr.sgi.com [130.62.180.74]) by yog-sothoth.sgi.com (980305.SGI.8.8.8-aspam-6.2/980304.SGI-aspam-europe) via ESMTP id UAA975510 for ; Fri, 10 Aug 2001 20:04:15 +0200 (CEST) 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 LAA63066; Fri, 10 Aug 2001 11:04:52 -0700 (PDT) Date: Fri, 10 Aug 2001 11:04:52 -0700 (PDT) From: mpm@rohi.engr.sgi.com (Michael Murphy) Message-Id: <200108101804.LAA63066@rohi.engr.sgi.com> To: , Subject: Re: Does sgicc supports linker option -export-dynamic? Sender: owner-pro64-support@oss.sgi.com Precedence: bulk I did add support for -export-dynamic, but I forget if that made it into the released version (and I can't test that right now). In general, if there is a linker flag that sgicc does not accept, you can pass it through with -Wl,, or go ahead and add it to the driver source, e.g. in driver/OPTIONS add: -export-dynamic ; LINK ld self "" -- Mike Murphy -- mpm@sgi.com -- quote of the day: -- "How can we remember our ignorance, which growth requires, -- when we are using our knowledge all the time?" (Thoreau) From owner-pro64-support@oss.sgi.com Wed Aug 15 07:24:36 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7FEOa503156 for pro64-support-outgoing; Wed, 15 Aug 2001 07:24:36 -0700 Received: from thalia.fm.intel.com (fmfdns02.fm.intel.com [132.233.247.11]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7FEOOj03096 for ; Wed, 15 Aug 2001 07:24:29 -0700 Received: from fmsmsxvs040.fm.intel.com (fmsmsxv040-1.fm.intel.com [132.233.48.108]) by thalia.fm.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.41 2001/07/09 21:06:22 root Exp $) with SMTP id OAA06208 for ; Wed, 15 Aug 2001 14:24:23 GMT Received: from fmsmsx17.intel.com ([132.233.48.17]) by fmsmsxvs040.fm.intel.com (NAVGW 2.5.1.6) with SMTP id M2001081507240313784 for ; Wed, 15 Aug 2001 07:24:03 -0700 Received: by fmsmsx17.fm.intel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 15 Aug 2001 07:25:23 -0700 Received: from fmsmsxfw01.fm.intel.com ([10.1.199.21]) by fmsmsx27.FM.INTEL.COM with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id QXG9Y2HL; Wed, 15 Aug 2001 07:24:14 -0700 Received: by fmsmsxfw01.fm.intel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 15 Aug 2001 22:24:25 +0800 Message-ID: From: "Huang, Tao" To: pro64-support@oss.sgi.com Subject: RE: C to Whirl Date: Wed, 15 Aug 2001 22:24:10 +0800 X-Mailer: Internet Mail Service (5.5.2653.19) Sender: owner-pro64-support@oss.sgi.com Precedence: bulk I had a try to fix this bug, the modification place can be described as below: 1)in function W2C_Enter_Global_Symbols() of file w2c_driver.cxx line 541 ~ 549 change to: for (UINT ty = 1; ty < TY_Table_Size(); ty++) { TY_IDX ty_current = make_TY_IDX(ty); if (TY_Is_Structured(ty_current)) { (void)W2CF_Symtab_Nameof_Ty(ty_current); for (fld = TY_flist(Ty_Table[ty_current]); !fld.Is_Null (); fld = FLD_next(fld)) (void)W2CF_Symtab_Nameof_Fld(fld); } /* if a struct */ } /* for all types */ Reason: index variable need left shift 8 bits to transform to TY_IDX. 2) in function WN2C_Append_Symtab_Types() file wn2c.cxx line 1969 ~ 1988 change to: /* Declare structure types. */ for (ty = 1; ty < TY_Table_Size(); ty++) { TY_IDX ty_current = make_TY_IDX(ty); if (TY_Is_Structured(ty_current) && !TY_split(Ty_Table[ty_current]) && !TY_is_translated_to_c(ty_current) && !Stab_Reserved_Ty(ty_current)) { tmp_tokens = New_Token_Buffer(); TY2C_translate_unqualified(tmp_tokens, ty_current); Append_Token_Special(tmp_tokens, ';'); Append_Indented_Newline(tmp_tokens, lines_between_decls); if (tokens != NULL) Append_And_Reclaim_Token_List(tokens, &tmp_tokens); else Write_And_Reclaim_Tokens(W2C_File[W2C_DOTH_FILE], NULL, /* No srcpos map */ &tmp_tokens); } } Reason: similiar to 1) 3) in function skip_till_next_field() in file ty2c.cxx line 280 ~ 288 change to: while (!next_fld.Is_Null () && (FLD_ofst(this_fld) >= FLD_ofst(next_fld) || PTR_OR_ALIGNED_WITH_STRUCT(FLD_type(next_fld), struct_align) || (!TY_Is_Pointer(FLD_type(next_fld)) && FLD_ofst(next_fld) % TY_align(FLD_type(next_fld)) != 0) || (!is_union && FLD_Is_Bitfield(next_fld, FLD_next(next_fld), struct_size - FLD_ofst(next_fld))))) The modification is to erase ! operator before stmt PTR_OR_ALIGNED_WITH_STRUCT(FLD_type(next_fld), struct_align) 4) in function function TY2C_prepend_FLD_list() in file ./be/whirl2c/ty2c.cxx line 372 ~ 374 change to: if (PTR_OR_ALIGNED_WITH_STRUCT(FLD_type(fld), struct_align) || (!is_union && FLD_Is_Bitfield(fld, FLD_next(fld), remaining_bytes))) The modification is to erase ! operator before stmt PTR_OR_ALIGNED_WITH_STRUCT(FLD_type(next_fld), struct_align) After modification, the code seems like attached files. There is still a mistake in structure variable number. That's because in this case there is ambigous name for a intrinsic call stat() and a intrinsic struct stat, so cause error in symbol table in function W2CF_Symtab_Nameof_St() of file w2cf_symtab.cxx. At last, I'd like to thank for Rune, Peng tu, shin-ming liu for the help and advice. -Tao Huang -----Original Message----- From: Charles R. Hardnett [mailto:hardnett@cc.gatech.edu] Sent: 2001?6?25? 21:48 To: pro64-support@oss.sgi.com Subject: C to Whirl Hello, I have a question that involves the C to Whirl generation. I am using the whirl2C module, and noticed a bug with code such as the following: struct stat sbuf; if (sbuf.st_mode) { printf("hello"); } The above code comes out of pro64 after whirl2c translation to look something like: if((_UINT32)(*(struct stat0 { _UINT64 st_dev; _UINT32 st_ino; _INT32 __pad1; _UINT32 st_mode; _UINT32 st_nlink; _UINT32 st_uid; _UINT32 st_gid; _UINT64 st_rdev; _INT64 st_size; _INT64 st_atime; _INT64 st_mtime; _INT64 st_ctime; _INT32 st_blocks; _INT32 __pad2; _UINT32 st_blksize; _INT32 __pad3; _INT64 __unused[6LL]; } *)(((_INT8 *) & sbuf) + 16LL)) != 0U) { printf((const _INT8 *)(_INT8(*)[6LL]) "hello"); } The problem of course is cast contains a declaration of the struct, and not just the name of the struct. I have tracked down the problem to where this only occurs when a struct field is accessed within a cond exp i.e. within while, if, for, etc. I have also convinced myself that the problem is not in the whirl2c conversion because it appears that whirl2C is only outputing the token information that is stored in the WN for this object's type. Therefore, it appears that the problem is the translation from C to whirl by GFEC is most likely the culprit. My questions are: 1. Is there anyone else looking at the whirl2c module that may have run into this problem? 2. If not, does anyone have any good information on GFEC and how its exprs are stored? operated on to create the whirl? I was looking at the code this weekend, and could use any documentation anyone may have on it. Thanks, Charles -- -------------------------------------------------------------------- Charles R. Hardnett www.spelman.edu/~hardnett begin 600 problem.w2c.h M+RH@26YC;'5D92!B=6EL=&EN('1Y<&5S(&%N9"!O<&5R871O'1E7,O Append_Indented_Newline(tmp_tokens, lines_between_decls); > if (tokens != NULL) > Append_And_Reclaim_Token_List(tokens, &tmp_tokens); > else > Write_And_Reclaim_Tokens(W2C_File[W2C_DOTH_FILE], > NULL, /* No srcpos map */ > &tmp_tokens); > } > } > Reason: similiar to 1) > > 3) in function skip_till_next_field() in file ty2c.cxx line 280 ~ 288 change to: > while (!next_fld.Is_Null () && > (FLD_ofst(this_fld) >= FLD_ofst(next_fld) || > PTR_OR_ALIGNED_WITH_STRUCT(FLD_type(next_fld), struct_align) || > (!TY_Is_Pointer(FLD_type(next_fld)) && > FLD_ofst(next_fld) % TY_align(FLD_type(next_fld)) != 0) || > (!is_union && FLD_Is_Bitfield(next_fld, FLD_next(next_fld), > struct_size - FLD_ofst(next_fld))))) > > The modification is to erase ! operator before stmt PTR_OR_ALIGNED_WITH_STRUCT(FLD_type(next_fld), struct_align) > > 4) in function function TY2C_prepend_FLD_list() in file ./be/whirl2c/ty2c.cxx line 372 ~ 374 change to: > if (PTR_OR_ALIGNED_WITH_STRUCT(FLD_type(fld), struct_align) || > (!is_union && > FLD_Is_Bitfield(fld, FLD_next(fld), remaining_bytes))) > > The modification is to erase ! operator before stmt PTR_OR_ALIGNED_WITH_STRUCT(FLD_type(next_fld), struct_align) > > After modification, the code seems like attached files. > > There is still a mistake in structure variable number. That's because in this case there is ambigous name for a intrinsic call stat() and a intrinsic struct stat, so cause error in symbol table in function W2CF_Symtab_Nameof_St() of file w2cf_symtab.cxx. > > At last, I'd like to thank for Rune, Peng tu, shin-ming liu for the help and advice. > > -Tao Huang > > -----Original Message----- > From: Charles R. Hardnett [mailto:hardnett@cc.gatech.edu] > Sent: 2001?6?25? 21:48 > To: pro64-support@oss.sgi.com > Subject: C to Whirl > > > > > Hello, > > I have a question that involves the C to Whirl generation. I am using > the whirl2C module, and noticed a bug with code such as the following: > > > struct stat sbuf; > > if (sbuf.st_mode) { > printf("hello"); > } > > > The above code comes out of pro64 after whirl2c translation to look > something like: > > if((_UINT32)(*(struct stat0 { > _UINT64 st_dev; > _UINT32 st_ino; > _INT32 __pad1; > _UINT32 st_mode; > _UINT32 st_nlink; > _UINT32 st_uid; > _UINT32 st_gid; > _UINT64 st_rdev; > _INT64 st_size; > _INT64 st_atime; > _INT64 st_mtime; > _INT64 st_ctime; > _INT32 st_blocks; > _INT32 __pad2; > _UINT32 st_blksize; > _INT32 __pad3; > _INT64 __unused[6LL]; > } *)(((_INT8 *) & sbuf) + 16LL)) != 0U) > { > printf((const _INT8 *)(_INT8(*)[6LL]) "hello"); > } > > The problem of course is cast contains a declaration of the struct, > and not just the name of the struct. I have tracked down the problem > to where this only occurs when a struct field is accessed within a > cond exp i.e. within while, if, for, etc. > > I have also convinced myself that the problem is not in the whirl2c > conversion because it appears that whirl2C is only outputing the token > information that is stored in the WN for this object's > type. Therefore, it appears that the problem is the translation from C > to whirl by GFEC is most likely the culprit. > > My questions are: > > 1. Is there anyone else looking at the whirl2c module that may have > run into this problem? > > 2. If not, does anyone have any good information on GFEC and how > its exprs are stored? operated on to create the whirl? I was looking > at the code this weekend, and could use any documentation anyone may > have on it. > > Thanks, > > Charles > > -- > -------------------------------------------------------------------- > Charles R. Hardnett www.spelman.edu/~hardnett > > > > > > begin 600 problem.w2c.h > M+RH@26YC;'5D92!B=6EL=&EN('1Y<&5S(&%N9"!O<&5R871O M8VQU9&4@/'=H:7)L,F,N:#X*"B\J(%1Y<&5S("HO"G-T M("!?54E.5#8T('-T7V1E=CL*("!?54E.5#,R('-T7VEN;SL*("!?24Y4,S(@ > M7U]P860Q.PH@(%]524Y4,S(@ M.PH@(%]524Y4,S(@ M-C0@ M;64["B`@7TE.5#8T('-T7VUT:6UE.PH@(%])3E0V-"!S=%]C=&EM93L*("!? > M24Y4,S(@ M=%]B;&MS:7IE.PH@(%])3E0S,B!?7W!A9#,["B`@7TE.5#8T(%]?=6YU M6S9,3%T["GT["@HO*B!&:6QE+6QE=F5L('-Y;6)O;&EC(&-O;G-T86YT M+PIS=&%T:6,@7TE.5#@@86YO;ELV3$Q=(#T@(FAE;&QO(CL*"B\J($9I;&4M > M;&5V96P@=F%R M870P*&-O;G-T(%])3E0X("HL('-T M24Y4,S(@7U]X M=&%T,2`J*3L*"E]?:6YL:6YE(%])3E0S,B!L M+"!S=')U8W0@'1E M3E0S,BP@8V]N M;F4@7TE.5#,R(&9S=&%T*%])3E0S,BP@ M97)N(%])3E0S,B!?7V9X M870Q("HI.PH*7U]I;FQI;F4@7TE.5#,R(&UK;F]D*&-O;G-T(%])3E0X("HL > M(%]524Y4,S(L(%]524Y4-C0I.PH*97AT97)N(%])3E0S,B!?7WAM:VYO9"A? > M24Y4,S(L(&-O;G-T(%])3E0X("HL(%]524Y4,S(L(%]524Y4-C0@*BD["@IE > M>'1E 4;G-T(%])3E0X("HL("XN+BD["@H= > ` > end > > begin 600 problem.c > M(VEN8VQU9&4@/'-T9&EO+F@^"B-I;F-L=61E(#QS>7,O M;'5D92`\=6YI M8G5F.PH*"6EF("AS8G5F+G-T7VUO9&4I"@D)<')I;G1F*")H96QL;R(I.PI] > !"@== > ` > end > > begin 600 problem.w2c.c > M+RHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ > M*BHJ*BHJ*BHJ*BH*("H@0R!F:6QE('1R86YS;&%T960@9G)O;2!72$E23"!7 > M960@075G(#$U(#(R.C`W.C$X(#(P,#$*("HJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ > M*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHO"@HO*B!);F-L > M=61E(&9I;&4M;&5V96P@='EP92!A;F0@=F%R:6%B;&4@9&5C;',@*B\*(VEN > M8VQU9&4@(G!R;V)L96TN=S)C+F@B"@H*7U]I;FQI;F4@7TE.5#,R('-T870P > M*`H@(&-O;G-T(%])3E0X("H@7U]P871H+`H@('-T MPH@(')E9VES=&5R(%])3E0S,B!?7V-O;6UA.PH@(`H@(%]? > M8V]M;6$@/2!?7WAS=&%T*#$L(%]?<&%T:"P@7U]S=&%T8G5F*3L*("!R971U > M M M*B!?7W-T871B=68I"GL*("!R96=I M("!?7V-O;6UA(#T@7U]L>'-T870H,2P@7U]P871H+"!?7W-T871B=68I.PH@ > M(')E='5R;B!?7V-O;6UA.PI]("\J(&QS=&%T("HO"@H*7U]I;FQI;F4@7TE. > M5#,R(&9S=&%T*`H@(%])3E0S,B!?7V9D+`H@('-T MPH@(')E9VES=&5R(%])3E0S,B!?7V-O;6UA.PH@(`H@(%]? > M8V]M;6$@/2!?7V9X M;B!?7V-O;6UA.PI]("\J(&9S=&%T("HO"@H*7U]I;FQI;F4@7TE.5#,R(&UK > M;F]D*`H@(&-O;G-T(%])3E0X("H@7U]P871H+`H@(%]524Y4,S(@7U]M;V1E > M+`H@(%]524Y4-C0@7U]D978I"GL*("!R96=I M83L*("`*("!?7V-O;6UA(#T@7U]X;6MN;V0H,"P@7U]P871H+"!?7VUO9&4L > M("9?7V1E=BD["B`@ M24Y4,S(@;6%I;B@I"GL*("!R96=I M8W0@ M=#$@*BDH*"A?24Y4."`J*2`F('-B=68I("L@,39,3"DI("$](#!5*0H@('L* > M("`@('!R:6YT9B@H8V]N H;&QO(BD["B`@?0H@(')E='5R;B!R96 ` > end > -- -------------------------------------------------------------------- Charles R. Hardnett www.spelman.edu/~hardnett From owner-pro64-support@oss.sgi.com Wed Aug 15 07:57:10 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7FEvA711895 for pro64-support-outgoing; Wed, 15 Aug 2001 07:57:10 -0700 Received: from thalia.fm.intel.com (fmfdns02.fm.intel.com [132.233.247.11]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7FEv4j11888 for ; Wed, 15 Aug 2001 07:57:04 -0700 Received: from SMTP (fmsmsxvs05-1.fm.intel.com [132.233.42.205]) by thalia.fm.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.41 2001/07/09 21:06:22 root Exp $) with SMTP id OAA19858; Wed, 15 Aug 2001 14:56:59 GMT Received: from fmsmsx28.fm.intel.com ([132.233.48.28]) by 132.233.48.205 (Norton AntiVirus for Internet Email Gateways 1.0) ; Wed, 15 Aug 2001 14:56:58 0000 (GMT) Received: by fmsmsx28.fm.intel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 15 Aug 2001 07:56:57 -0700 Received: from fmsmsxfw01.fm.intel.com ([10.1.199.21]) by fmsmsx27.FM.INTEL.COM with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id QXG9YLGS; Wed, 15 Aug 2001 07:56:54 -0700 Received: by fmsmsxfw01.fm.intel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 15 Aug 2001 22:57:05 +0800 Message-ID: From: "Huang, Tao" To: "'hardnett@cc.gatech.edu'" Cc: pro64-support@oss.sgi.com Subject: RE: C to Whirl Date: Wed, 15 Aug 2001 22:51:15 +0800 X-Mailer: Internet Mail Service (5.5.2653.19) Sender: owner-pro64-support@oss.sgi.com Precedence: bulk Great! in fact, my modification is very trivial. 1)change ty to TY_IDX by using make_TY_IDX() call 2)erase "!" operator in two statements That's all. :-) Sorry for not distinguish modified statements from original statements because there is something wrong with my outlook, I can not change it into another color or font. Thx -Tao Huang -----Original Message----- From: Charles R. Hardnett [mailto:hardnett@cc.gatech.edu] Sent: 2001å¹´8æoe^15æ-¥ 22:34 To: tao.huang@intel.com Cc: pro64-support@oss.sgi.com Subject: RE: C to Whirl Thanks. I also fixed the elaboration bug by creating a declaration context, and then just checking for that context. As for the ambiguity problem. I have a solution that I am working on that uses information collected by gfec to help make decisions about the ambiguities. It should be done sometime this week. Regards, Charles Huang, Tao writes: > I had a try to fix this bug, the modification place can be described as below: > > 1)in function W2C_Enter_Global_Symbols() of file w2c_driver.cxx line 541 ~ 549 change to: > for (UINT ty = 1; ty < TY_Table_Size(); ty++) > { > TY_IDX ty_current = make_TY_IDX(ty); > if (TY_Is_Structured(ty_current)) > { > (void)W2CF_Symtab_Nameof_Ty(ty_current); > for (fld = TY_flist(Ty_Table[ty_current]); !fld.Is_Null (); fld = FLD_next(fld)) > (void)W2CF_Symtab_Nameof_Fld(fld); > } /* if a struct */ > } /* for all types */ > > Reason: index variable need left shift 8 bits to transform to TY_IDX. > > 2) in function WN2C_Append_Symtab_Types() file wn2c.cxx line 1969 ~ 1988 change to: > /* Declare structure types. */ > for (ty = 1; ty < TY_Table_Size(); ty++) > { > TY_IDX ty_current = make_TY_IDX(ty); > if (TY_Is_Structured(ty_current) && > !TY_split(Ty_Table[ty_current]) && > !TY_is_translated_to_c(ty_current) && > !Stab_Reserved_Ty(ty_current)) > { > tmp_tokens = New_Token_Buffer(); > TY2C_translate_unqualified(tmp_tokens, ty_current); > Append_Token_Special(tmp_tokens, ';'); > Append_Indented_Newline(tmp_tokens, lines_between_decls); > if (tokens != NULL) > Append_And_Reclaim_Token_List(tokens, &tmp_tokens); > else > Write_And_Reclaim_Tokens(W2C_File[W2C_DOTH_FILE], > NULL, /* No srcpos map */ > &tmp_tokens); > } > } > Reason: similiar to 1) > > 3) in function skip_till_next_field() in file ty2c.cxx line 280 ~ 288 change to: > while (!next_fld.Is_Null () && > (FLD_ofst(this_fld) >= FLD_ofst(next_fld) || > PTR_OR_ALIGNED_WITH_STRUCT(FLD_type(next_fld), struct_align) || > (!TY_Is_Pointer(FLD_type(next_fld)) && > FLD_ofst(next_fld) % TY_align(FLD_type(next_fld)) != 0) || > (!is_union && FLD_Is_Bitfield(next_fld, FLD_next(next_fld), > struct_size - FLD_ofst(next_fld))))) > > The modification is to erase ! operator before stmt PTR_OR_ALIGNED_WITH_STRUCT(FLD_type(next_fld), struct_align) > > 4) in function function TY2C_prepend_FLD_list() in file ./be/whirl2c/ty2c.cxx line 372 ~ 374 change to: > if (PTR_OR_ALIGNED_WITH_STRUCT(FLD_type(fld), struct_align) || > (!is_union && > FLD_Is_Bitfield(fld, FLD_next(fld), remaining_bytes))) > > The modification is to erase ! operator before stmt PTR_OR_ALIGNED_WITH_STRUCT(FLD_type(next_fld), struct_align) > > After modification, the code seems like attached files. > > There is still a mistake in structure variable number. That's because in this case there is ambigous name for a intrinsic call stat() and a intrinsic struct stat, so cause error in symbol table in function W2CF_Symtab_Nameof_St() of file w2cf_symtab.cxx. > > At last, I'd like to thank for Rune, Peng tu, shin-ming liu for the help and advice. > > -Tao Huang > > -----Original Message----- > From: Charles R. Hardnett [mailto:hardnett@cc.gatech.edu] > Sent: 2001?6?25? 21:48 > To: pro64-support@oss.sgi.com > Subject: C to Whirl > > > > > Hello, > > I have a question that involves the C to Whirl generation. I am using > the whirl2C module, and noticed a bug with code such as the following: > > > struct stat sbuf; > > if (sbuf.st_mode) { > printf("hello"); > } > > > The above code comes out of pro64 after whirl2c translation to look > something like: > > if((_UINT32)(*(struct stat0 { > _UINT64 st_dev; > _UINT32 st_ino; > _INT32 __pad1; > _UINT32 st_mode; > _UINT32 st_nlink; > _UINT32 st_uid; > _UINT32 st_gid; > _UINT64 st_rdev; > _INT64 st_size; > _INT64 st_atime; > _INT64 st_mtime; > _INT64 st_ctime; > _INT32 st_blocks; > _INT32 __pad2; > _UINT32 st_blksize; > _INT32 __pad3; > _INT64 __unused[6LL]; > } *)(((_INT8 *) & sbuf) + 16LL)) != 0U) > { > printf((const _INT8 *)(_INT8(*)[6LL]) "hello"); > } > > The problem of course is cast contains a declaration of the struct, > and not just the name of the struct. I have tracked down the problem > to where this only occurs when a struct field is accessed within a > cond exp i.e. within while, if, for, etc. > > I have also convinced myself that the problem is not in the whirl2c > conversion because it appears that whirl2C is only outputing the token > information that is stored in the WN for this object's > type. Therefore, it appears that the problem is the translation from C > to whirl by GFEC is most likely the culprit. > > My questions are: > > 1. Is there anyone else looking at the whirl2c module that may have > run into this problem? > > 2. If not, does anyone have any good information on GFEC and how > its exprs are stored? operated on to create the whirl? I was looking > at the code this weekend, and could use any documentation anyone may > have on it. > > Thanks, > > Charles > > -- > -------------------------------------------------------------------- > Charles R. Hardnett www.spelman.edu/~hardnett > > > > > > begin 600 problem.w2c.h > M+RH@26YC;'5D92!B=6EL=&EN('1Y<&5S(&%N9"!O<&5R871O M8VQU9&4@/'=H:7)L,F,N:#X*"B\J(%1Y<&5S("HO"G-T M("!?54E.5#8T('-T7V1E=CL*("!?54E.5#,R('-T7VEN;SL*("!?24Y4,S(@ > M7U]P860Q.PH@(%]524Y4,S(@ M.PH@(%]524Y4,S(@ M-C0@ M;64["B`@7TE.5#8T('-T7VUT:6UE.PH@(%])3E0V-"!S=%]C=&EM93L*("!? > M24Y4,S(@ M=%]B;&MS:7IE.PH@(%])3E0S,B!?7W!A9#,["B`@7TE.5#8T(%]?=6YU M6S9,3%T["GT["@HO*B!&:6QE+6QE=F5L('-Y;6)O;&EC(&-O;G-T86YT M+PIS=&%T:6,@7TE.5#@@86YO;ELV3$Q=(#T@(FAE;&QO(CL*"B\J($9I;&4M > M;&5V96P@=F%R M870P*&-O;G-T(%])3E0X("HL('-T M24Y4,S(@7U]X M=&%T,2`J*3L*"E]?:6YL:6YE(%])3E0S,B!L M+"!S=')U8W0@'1E M3E0S,BP@8V]N M;F4@7TE.5#,R(&9S=&%T*%])3E0S,BP@ M97)N(%])3E0S,B!?7V9X M870Q("HI.PH*7U]I;FQI;F4@7TE.5#,R(&UK;F]D*&-O;G-T(%])3E0X("HL > M(%]524Y4,S(L(%]524Y4-C0I.PH*97AT97)N(%])3E0S,B!?7WAM:VYO9"A? > M24Y4,S(L(&-O;G-T(%])3E0X("HL(%]524Y4,S(L(%]524Y4-C0@*BD["@IE > M>'1E 4;G-T(%])3E0X("HL("XN+BD["@H= > ` > end > > begin 600 problem.c > M(VEN8VQU9&4@/'-T9&EO+F@^"B-I;F-L=61E(#QS>7,O M;'5D92`\=6YI M8G5F.PH*"6EF("AS8G5F+G-T7VUO9&4I"@D)<')I;G1F*")H96QL;R(I.PI] > !"@== > ` > end > > begin 600 problem.w2c.c > M+RHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ > M*BHJ*BHJ*BHJ*BH*("H@0R!F:6QE('1R86YS;&%T960@9G)O;2!72$E23"!7 > M960@075G(#$U(#(R.C`W.C$X(#(P,#$*("HJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ > M*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHO"@HO*B!);F-L > M=61E(&9I;&4M;&5V96P@='EP92!A;F0@=F%R:6%B;&4@9&5C;',@*B\*(VEN > M8VQU9&4@(G!R;V)L96TN=S)C+F@B"@H*7U]I;FQI;F4@7TE.5#,R('-T870P > M*`H@(&-O;G-T(%])3E0X("H@7U]P871H+`H@('-T MPH@(')E9VES=&5R(%])3E0S,B!?7V-O;6UA.PH@(`H@(%]? > M8V]M;6$@/2!?7WAS=&%T*#$L(%]?<&%T:"P@7U]S=&%T8G5F*3L*("!R971U > M M M*B!?7W-T871B=68I"GL*("!R96=I M("!?7V-O;6UA(#T@7U]L>'-T870H,2P@7U]P871H+"!?7W-T871B=68I.PH@ > M(')E='5R;B!?7V-O;6UA.PI]("\J(&QS=&%T("HO"@H*7U]I;FQI;F4@7TE. > M5#,R(&9S=&%T*`H@(%])3E0S,B!?7V9D+`H@('-T MPH@(')E9VES=&5R(%])3E0S,B!?7V-O;6UA.PH@(`H@(%]? > M8V]M;6$@/2!?7V9X M;B!?7V-O;6UA.PI]("\J(&9S=&%T("HO"@H*7U]I;FQI;F4@7TE.5#,R(&UK > M;F]D*`H@(&-O;G-T(%])3E0X("H@7U]P871H+`H@(%]524Y4,S(@7U]M;V1E > M+`H@(%]524Y4-C0@7U]D978I"GL*("!R96=I M83L*("`*("!?7V-O;6UA(#T@7U]X;6MN;V0H,"P@7U]P871H+"!?7VUO9&4L > M("9?7V1E=BD["B`@ M24Y4,S(@;6%I;B@I"GL*("!R96=I M8W0@ M=#$@*BDH*"A?24Y4."`J*2`F('-B=68I("L@,39,3"DI("$](#!5*0H@('L* > M("`@('!R:6YT9B@H8V]N H;&QO(BD["B`@?0H@(')E='5R;B!R96 ` > end > -- -------------------------------------------------------------------- Charles R. Hardnett www.spelman.edu/~hardnett From owner-pro64-support@oss.sgi.com Wed Aug 15 12:58:46 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7FJwkh17475 for pro64-support-outgoing; Wed, 15 Aug 2001 12:58:46 -0700 Received: from zok.sgi.com (zok.sgi.com [204.94.215.101]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7FJwjj17467 for ; Wed, 15 Aug 2001 12:58:45 -0700 Received: from rohi.engr.sgi.com (rohi.engr.sgi.com [130.62.180.74]) by zok.sgi.com (8.11.4/8.11.4/linux-outbound_gateway-1.0) with ESMTP id f7FK4aW20054 for ; Wed, 15 Aug 2001 13:04:36 -0700 Received: (from mpm@localhost) by rohi.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) id MAA74760 for pro64-support@oss.sgi.com; Wed, 15 Aug 2001 12:58:11 -0700 (PDT) Date: Wed, 15 Aug 2001 12:58:11 -0700 (PDT) From: mpm@rohi.engr.sgi.com (Michael Murphy) Message-Id: <200108151958.MAA74760@rohi.engr.sgi.com> To: pro64-support@oss.sgi.com Subject: Pro64 discontinued Sender: owner-pro64-support@oss.sgi.com Precedence: bulk In case you haven't seen the announcement at http:/oss.sgi.com/projects/Pro64 I'm including it here. Sad but true. I'm told that the pro64-* email lists will also be going away. SGI has discontinued development of SGI Pro64 compiler development tools. SGI marketing is interested in hearing from Linux developers. Please send any comments or suggestions to IA64devtools@oss.sgi.com. Thank you for your interest in SGI Pro64 compiler development tools. -- Mike Murphy -- mpm@sgi.com -- quote of the day: -- "Consider the postage stamp. It secures success through its ability -- to stick to one thing till it gets there." (Josh Billings) From owner-pro64-support@oss.sgi.com Wed Aug 15 13:36:02 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7FKa2227417 for pro64-support-outgoing; Wed, 15 Aug 2001 13:36:02 -0700 Received: from hypnos.cps.intel.com (hypnos.cps.intel.com [192.198.165.17]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7FKZuj27397 for ; Wed, 15 Aug 2001 13:36:01 -0700 Received: from SMTP (fmsmsxvs01-1.fm.intel.com [132.233.42.201]) by hypnos.cps.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.41 2001/07/09 21:06:22 root Exp $) with SMTP id UAA05299; Wed, 15 Aug 2001 20:35:30 GMT Received: from fmsmsx27.FM.INTEL.COM ([132.233.48.27]) by 132.233.48.201 (Norton AntiVirus for Internet Email Gateways 1.0) ; Wed, 15 Aug 2001 20:35:30 0000 (GMT) Received: by fmsmsx27.fm.intel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 15 Aug 2001 13:35:29 -0700 Message-ID: <9287DC1579B0D411AA2F009027F44C3F0ABD0629@FMSMSX41> From: "Chan, Sun C" To: "'mpm@rohi.engr.sgi.com'" , pro64-support@oss.sgi.com Subject: RE: Pro64 discontinued Date: Wed, 15 Aug 2001 13:35:21 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-pro64-support@oss.sgi.com Precedence: bulk Pro64 supporters and users, Before its too late that this mailing alias is gone, just want to let you know that we are contemplating ways to continue the mailing list for support and various matters for continuing Pro64 development work. If you are interested or has suggestions, please send mail to sun.c.chan@intel.com. When the mailing list is finally setup, I will notify people who has expressed interest. Sun Chan. > -----Original Message----- > From: mpm@rohi.engr.sgi.com [mailto:mpm@rohi.engr.sgi.com] > Sent: Wednesday, August 15, 2001 12:58 PM > To: pro64-support@oss.sgi.com > Subject: Pro64 discontinued > > > In case you haven't seen the announcement at > http:/oss.sgi.com/projects/Pro64 > I'm including it here. Sad but true. > I'm told that the pro64-* email lists will also be going away. > > SGI has discontinued development of SGI Pro64 > compiler development tools. SGI marketing is > interested in hearing from Linux developers. > Please send any comments or suggestions to > IA64devtools@oss.sgi.com. Thank you for your > interest in SGI Pro64 compiler development tools. > > -- Mike Murphy > -- mpm@sgi.com > -- quote of the day: > -- "Consider the postage stamp. It secures success through > its ability > -- to stick to one thing till it gets there." (Josh Billings) > From owner-pro64-support@oss.sgi.com Wed Aug 15 14:46:51 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7FLkpB11444 for pro64-support-outgoing; Wed, 15 Aug 2001 14:46:51 -0700 Received: from postal1.lbl.gov (postal1.lbl.gov [128.3.7.82]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7FLkij11426 for ; Wed, 15 Aug 2001 14:46:44 -0700 Received: from SpamWall.lbl.gov (localhost [127.0.0.1]) by postal1.lbl.gov (8.11.2/8.11.2) with ESMTP id f7FLkir04426 for ; Wed, 15 Aug 2001 14:46:44 -0700 (PDT) From: RMSilva@lbl.gov Received: from lbl.gov (imapa.lbl.gov [128.3.41.28]) by SpamWall.lbl.gov (8.11.2/8.11.2) with ESMTP id f7FLkh504418; Wed, 15 Aug 2001 14:46:43 -0700 (PDT) To: "Chan, Sun C" , pro64-support@oss.sgi.com Message-ID: <22be2122fe6b.22fe6b22be21@lbl.gov> Date: Wed, 15 Aug 2001 18:46:43 -0300 X-Mailer: Netscape Webmail MIME-Version: 1.0 Content-Language: en Subject: Re: RE: Pro64 discontinued X-Accept-Language: en Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: 7bit Sender: owner-pro64-support@oss.sgi.com Precedence: bulk Hi, I`ll be happy to help, but my aknowledge in insternals of compilers is not to much, but I can help like a alpha/beta user, or at least in documentation and ftp-space. Le'me know the news. Regards, Ricardo. ----- Original Message ----- From: "Chan, Sun C" Date: Wednesday, August 15, 2001 5:35 pm Subject: RE: Pro64 discontinued > Pro64 supporters and users, > Before its too late that this mailing alias is gone, just want to > let you > know that we are contemplating ways to continue the mailing list > for support > and various matters for continuing Pro64 development work. > If you are interested or has suggestions, please send mail to > sun.c.chan@intel.com. > When the mailing list is finally setup, I will notify people who has > expressed interest. > Sun Chan. > > > -----Original Message----- > > From: mpm@rohi.engr.sgi.com [mailto:mpm@rohi.engr.sgi.com] > > Sent: Wednesday, August 15, 2001 12:58 PM > > To: pro64-support@oss.sgi.com > > Subject: Pro64 discontinued > > > > > > In case you haven't seen the announcement at > > http:/oss.sgi.com/projects/Pro64 > > I'm including it here. Sad but true. > > I'm told that the pro64-* email lists will also be going away. > > > > SGI has discontinued development of SGI Pro64 > > compiler development tools. SGI marketing is > > interested in hearing from Linux developers. > > Please send any comments or suggestions to > > IA64devtools@oss.sgi.com. Thank you for your > > interest in SGI Pro64 compiler development tools. > > > > -- Mike Murphy > > -- mpm@sgi.com > > -- quote of the day: > > -- "Consider the postage stamp. It secures success through > > its ability > > -- to stick to one thing till it gets there." (Josh Billings) > > > > From owner-pro64-support@oss.sgi.com Wed Aug 15 16:28:03 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7FNS3B29445 for pro64-support-outgoing; Wed, 15 Aug 2001 16:28:03 -0700 Received: from thalia.fm.intel.com (fmfdns02.fm.intel.com [132.233.247.11]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7FNRuj29415 for ; Wed, 15 Aug 2001 16:28:01 -0700 Received: from SMTP (fmsmsxvs02-1.fm.intel.com [132.233.42.202]) by thalia.fm.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.41 2001/07/09 21:06:22 root Exp $) with SMTP id XAA06743 for ; Wed, 15 Aug 2001 23:27:54 GMT Received: from fmsmsx18.intel.com ([132.233.48.18]) by 132.233.48.202 (Norton AntiVirus for Internet Email Gateways 1.0) ; Wed, 15 Aug 2001 23:14:23 0000 (GMT) Received: from SMTP (fmsmsxvs02-1.fm.intel.com [132.233.42.202]) by fmsmsx18.intel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id QXD911TX; Wed, 15 Aug 2001 16:05:09 -0700 Received: from fmsmsx18.intel.com ([132.233.48.18]) by 132.233.48.202 (Norton AntiVirus for Internet Email Gateways 1.0) ; Wed, 15 Aug 2001 21:32:45 0000 (GMT) Received: by fmsmsx18.fm.intel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 15 Aug 2001 14:32:44 -0700 Message-ID: <9287DC1579B0D411AA2F009027F44C3F0ABD062D@FMSMSX41> From: "Chan, Sun C" To: "'pro64-support@oss.sgi.com'" Cc: "Ju, Roy" , "Chan, Sun C" Subject: moving forward with Pro64 development and support Date: Wed, 15 Aug 2001 14:32:44 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="ISO-8859-1" Sender: owner-pro64-support@oss.sgi.com Precedence: bulk Folks, As you might have heard, Microprocessor Research Lab of Intel and Institute of Computing Technology, Chinese Academy of Science has a joint compiler development effort going on that is based on Pro64. The compiler is called Open Research Compiler (ORC). We are not in a position to pledge resource commitment. It goes without saying that it is to our interest to keep some organized support and discussion mailing group going on, now that SGI has officially withdraw its support of it. This is what we are committed in the near future: 1. Open source our modified version of the compiler, release date is expected to be around the end of this year. Modification includes new optimizations to exploit IA64 features. 2. Tutorial session in this year's Micro at Austin, Tx (Dec 1). We will give details about our compiler, release date as well as what kind of support we will commit at that time. We are planning a discussion/support group (possibly in sourceforge) to keep discussions about this compiler (and variations of it) going. We are also interested in knowing what your needs are, what you can contribute in terms of projects, resource, ... Your input is also key in helping us to map out future commitments to our own release of the ORC compiler. Sun Chan, Roy Ju Programming Systems Lab, MRL Intel Corp. From owner-pro64-support@oss.sgi.com Thu Aug 16 07:47:59 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7GElxP30884 for pro64-support-outgoing; Thu, 16 Aug 2001 07:47:59 -0700 Received: from beta.dmz-eu.st.com (beta.dmz-eu.st.com [164.129.1.35]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7GEltj30865 for ; Thu, 16 Aug 2001 07:47:56 -0700 Received: from zeta.dmz-eu.st.com (zeta.dmz-eu.st.com [164.129.230.9]) by beta.dmz-eu.st.com (STMicroelectronics) with SMTP id 226C04907; Thu, 16 Aug 2001 14:47:48 +0000 (GMT) Received: by zeta.dmz-eu.st.com (STMicroelectronics, from userid 0) id 1C3974BC0; Thu, 16 Aug 2001 14:47:58 +0000 (GMT) Received: from thistle.bri.st.com (localhost [127.0.0.1]) by zeta.dmz-eu.st.com (STMicroelectronics) with ESMTP id 8EBE51845; Thu, 16 Aug 2001 14:47:57 +0000 (GMT) Received: from harpo ([164.129.14.93] helo=st.com) by thistle.bristol.st.com with esmtp (Exim 3.03 #5) id 15XOR0-0002X3-00; Thu, 16 Aug 2001 15:47:46 +0100 Message-ID: <3B7BDEC2.BA5296D7@st.com> Date: Thu, 16 Aug 2001 15:54:58 +0100 From: "Benedict R. Gaster" Organization: STMicroelectronics X-Mailer: Mozilla 4.7 [en-gb] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: sun.c.chan@intel.com Cc: pro64-support@oss.sgi.com, roy.ju@intel.com Subject: Re: moving forward with Pro64 development and support References: <9287DC1579B0D411AA2F009027F44C3F0ABD062D@FMSMSX41> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-pro64-support@oss.sgi.com Precedence: bulk Hello, Thank you for your email outlining the development of the Open Research Compiler. Here at SuperH we have been working with the Pro64 compiler for some time now (initially within STMicroelectronics) and are currently in the process of porting this technology to the SH-5 SHmedia instruction set architecture, with the aim of supporting current and future SuperH technologies. The current expectation is that we shall make an internal beta release towards the end of November (this is unlikely to include support for debugging) and a full release towards the end of Q1 2002. We expect to have a demo available in time for Micro in December. Are there any plans to: 1. Improve the infrastructure for configuring and building (e.g., selecting different targets) the Pro64 compiler? 2. Replace the GNU C and C++ frontends, including machine RTL descriptions, currently taken from a snapshot of a 2.96 variant, with the ABI modified 3.x frontends? 3. Release any of the missing SGI documentation for the current Pro64 compiler or document the ORC release? We are commited to providing and supporting developement tools, for SuperH architectures, based on Open Source technology, including the GNU tools (i.e., GCC, binutils, GDB, and Linux) and the Pro64 compiler. Of course, we would hope to intergrate our work on the Pro64 with a future release of ORC. We look forward to meeting and talking with you at Micro in December. Ben Gaster, Tony Bowers Software Architecture Group SuperH, Inc. sun.c.chan@intel.com wrote: > Folks, > As you might have heard, Microprocessor Research Lab of Intel and Institute > of Computing > Technology, Chinese Academy of Science has a joint compiler development > effort going on > that is based on Pro64. The compiler is called Open Research Compiler (ORC). > We are > not in a position to pledge resource commitment. It goes without saying that > it is to our > interest to keep some organized support and discussion mailing group going > on, now that SGI > has officially withdraw its support of it. > This is what we are committed in the near future: > 1. Open source our modified version of the compiler, release date is > expected to be around > the end of this year. Modification includes new optimizations to > exploit IA64 features. > > 2. Tutorial session in this year's Micro at Austin, Tx (Dec 1). We will give > details about > our compiler, release date as well as what kind of support we will > commit at that time. > > We are planning a discussion/support group (possibly in sourceforge) to keep > discussions about > this compiler (and variations of it) going. > We are also interested in knowing what your needs are, what you can > contribute in terms of > projects, resource, ... > Your input is also key in helping us to map out future commitments to our > own release of the > ORC compiler. > > Sun Chan, Roy Ju > Programming Systems Lab, MRL > Intel Corp. From owner-pro64-support@oss.sgi.com Thu Aug 16 08:26:51 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7GFQp831862 for pro64-support-outgoing; Thu, 16 Aug 2001 08:26:51 -0700 Received: from thalia.fm.intel.com (fmfdns02.fm.intel.com [132.233.247.11]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7GFQgj31858 for ; Thu, 16 Aug 2001 08:26:47 -0700 Received: from fmsmsxvs043.fm.intel.com (fmsmsxvs043.fm.intel.com [132.233.42.129]) by thalia.fm.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.41 2001/07/09 21:06:22 root Exp $) with SMTP id PAA22664 for ; Thu, 16 Aug 2001 15:26:42 GMT Received: from fmsmsx29.FM.INTEL.COM ([132.233.48.29]) by fmsmsxvs043.fm.intel.com (NAVGW 2.5.1.6) with SMTP id M2001081608260208821 ; Thu, 16 Aug 2001 08:26:02 -0700 Received: by fmsmsx29.fm.intel.com with Internet Mail Service (5.5.2653.19) id ; Thu, 16 Aug 2001 08:26:42 -0700 Message-ID: <9287DC1579B0D411AA2F009027F44C3F0ABD0630@FMSMSX41> From: "Chan, Sun C" To: "'Benedict R. Gaster'" Cc: pro64-support@oss.sgi.com Subject: RE: moving forward with Pro64 development and support Date: Thu, 16 Aug 2001 08:26:40 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-pro64-support@oss.sgi.com Precedence: bulk > -----Original Message----- > From: Benedict R. Gaster [mailto:benedict.gaster@st.com] > Sent: Thursday, August 16, 2001 7:55 AM > To: sun.c.chan@intel.com > Cc: pro64-support@oss.sgi.com; roy.ju@intel.com > Subject: Re: moving forward with Pro64 development and support > > > Hello, > > Thank you for your email outlining the development of the > Open Research > Compiler. > > Here at SuperH we have been working with the Pro64 compiler > for some time > now (initially within STMicroelectronics) and are currently in the > process of porting this technology to the SH-5 SHmedia instruction set > architecture, with the aim of supporting current and future SuperH > technologies. The current expectation is that we shall make > an internal > beta release towards the end of November (this is unlikely to include > support for debugging) and a full release towards the end of > Q1 2002. We > expect to have a demo available in time for Micro in December. > > Are there any plans to: > > 1. Improve the infrastructure for configuring and building (e.g., > selecting different targets) the Pro64 compiler? Since we are not retargetting, no. I know of several efforts retargetting, perhaps this is a topic of general interest. > > 2. Replace the GNU C and C++ frontends, including machine RTL > descriptions, currently taken from a snapshot of a 2.96 variant, with > the ABI modified 3.x frontends? This is a genuine concern shared amongst a number of groups. For our site, we have no immediate plan until after our own first release. > > 3. Release any of the missing SGI documentation for the current Pro64 > compiler or document the ORC release? We will make an attempt to do that. I've tried to cover the important ones for developers (such as Mempool usage, 0.13 release running on NUE, ...) > > We are commited to providing and supporting developement > tools, for SuperH > architectures, based on Open Source technology, including the > GNU tools > (i.e., GCC, binutils, GDB, and Linux) and the Pro64 compiler. > Of course, > we would hope to intergrate our work on the Pro64 with a > future release > of ORC. > > We look forward to meeting and talking with you at Micro in December. > > Ben Gaster, Tony Bowers > Software Architecture Group > SuperH, Inc. > > sun.c.chan@intel.com wrote: > > > Folks, > > As you might have heard, Microprocessor Research Lab of > Intel and Institute > > of Computing > > Technology, Chinese Academy of Science has a joint compiler > development > > effort going on > > that is based on Pro64. The compiler is called Open > Research Compiler (ORC). > > We are > > not in a position to pledge resource commitment. It goes > without saying that > > it is to our > > interest to keep some organized support and discussion > mailing group going > > on, now that SGI > > has officially withdraw its support of it. > > This is what we are committed in the near future: > > 1. Open source our modified version of the compiler, release date is > > expected to be around > > the end of this year. Modification includes new > optimizations to > > exploit IA64 features. > > > > 2. Tutorial session in this year's Micro at Austin, Tx (Dec > 1). We will give > > details about > > our compiler, release date as well as what kind of > support we will > > commit at that time. > > > > We are planning a discussion/support group (possibly in > sourceforge) to keep > > discussions about > > this compiler (and variations of it) going. > > We are also interested in knowing what your needs are, what you can > > contribute in terms of > > projects, resource, ... > > Your input is also key in helping us to map out future > commitments to our > > own release of the > > ORC compiler. > > > > Sun Chan, Roy Ju > > Programming Systems Lab, MRL > > Intel Corp. > > From owner-pro64-support@oss.sgi.com Fri Aug 17 09:06:50 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7HG6oH06001 for pro64-support-outgoing; Fri, 17 Aug 2001 09:06:50 -0700 Received: from olsen.capsl.udel.edu (olsen.capsl.udel.edu [128.4.10.3]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7HG6mj05998 for ; Fri, 17 Aug 2001 09:06:48 -0700 Received: from kakulavarapu.capsl.udel.edu (kakulavarapu.capsl.udel.edu [128.4.10.48]) by olsen.capsl.udel.edu (8.9.1/8.9.1) with ESMTP id MAA29663 for ; Fri, 17 Aug 2001 12:06:46 -0400 (EDT) Date: Fri, 17 Aug 2001 12:06:46 -0400 (EDT) From: Hongbo Yang To: Subject: How to compile SGI Pro64 Source code on Itanium Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-pro64-support@oss.sgi.com Precedence: bulk Assume I have an Itanium machine, can I compile SGI Pro64 source code on the machine and get an executable SGI Pro64 compiler? If so, which targ_* directory among targcygnus_ia32_ia64, targ_ia32_ia64_nodebug, targ_ia64 should I compile? -------------------------------- Hongbo Yang Electrical Engineering Univ of Delaware From owner-pro64-support@oss.sgi.com Fri Aug 17 10:20:37 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7HHKbP07450 for pro64-support-outgoing; Fri, 17 Aug 2001 10:20:37 -0700 Received: from web3501.mail.yahoo.com (web3501.mail.yahoo.com [216.115.111.68]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7HHKZj07446 for ; Fri, 17 Aug 2001 10:20:35 -0700 Message-ID: <20010817172034.21362.qmail@web3501.mail.yahoo.com> Received: from [156.153.254.41] by web3501.mail.yahoo.com via HTTP; Fri, 17 Aug 2001 10:20:34 PDT Date: Fri, 17 Aug 2001 10:20:34 -0700 (PDT) From: Shin-Ming Liu Subject: Re: How to compile SGI Pro64 Source code on Itanium To: Hongbo Yang , pro64-support@oss.sgi.com In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-pro64-support@oss.sgi.com Precedence: bulk It sounds like you are going to use Itanium g++ from Redhat to build osprey1.0. There might be some work to straight out the set of header files you want to use for this build. You also want to pay attention on issues specific to the LP64 model. For example, the memory consumption due to the 64 bit pointers. The directory naming convention is host_target[_nodebug]. In this situation, you are building a cross compiler. I would probably use targrhia64_ia64 since the host environment is Redhat ia64 compiler and targeting for ia64 architecture. The suffix _nodebug is for the release build. Without it, the compiler build should include "-g -DDEBUG -DIs_True_On" to enable the debugging code and debugger symbol generation. These are my 2 cents. Regards, Shin-Ming --- Hongbo Yang wrote: > > Assume I have an Itanium machine, can I compile SGI > Pro64 source code on > the machine and get an executable SGI Pro64 > compiler? If so, which targ_* > directory among targcygnus_ia32_ia64, > targ_ia32_ia64_nodebug, targ_ia64 > should I compile? > > -------------------------------- > Hongbo Yang > > Electrical Engineering > Univ of Delaware > > __________________________________________________ Do You Yahoo!? Make international calls for as low as $.04/minute with Yahoo! Messenger http://phonecard.yahoo.com/ From owner-pro64-support@oss.sgi.com Fri Aug 17 11:05:39 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7HI5dK08429 for pro64-support-outgoing; Fri, 17 Aug 2001 11:05:39 -0700 Received: from rj.sgi.com (rj.sgi.com [204.94.215.100]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7HI5cj08426 for ; Fri, 17 Aug 2001 11:05:38 -0700 Received: from yog-sothoth.sgi.com (eugate.neu.sgi.com [144.253.131.5]) by rj.sgi.com (8.11.4/8.11.4/linux-outbound_gateway-1.0) with ESMTP id f7HIAV805986 for <@rj.corp.sgi.com:pro64-support@oss.sgi.com>; Fri, 17 Aug 2001 11:10:31 -0700 Received: from rohi.engr.sgi.com (rohi.engr.sgi.com [130.62.180.74]) by yog-sothoth.sgi.com (980305.SGI.8.8.8-aspam-6.2/980304.SGI-aspam-europe) via ESMTP id UAA149342 for ; Fri, 17 Aug 2001 20:05:30 +0200 (CEST) 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 LAA79718; Fri, 17 Aug 2001 11:05:02 -0700 (PDT) Date: Fri, 17 Aug 2001 11:05:02 -0700 (PDT) From: mpm@rohi.engr.sgi.com (Michael Murphy) Message-Id: <200108171805.LAA79718@rohi.engr.sgi.com> To: , Hongbo Yang Subject: Re: How to compile SGI Pro64 Source code on Itanium Sender: owner-pro64-support@oss.sgi.com Precedence: bulk From: Hongbo Yang Assume I have an Itanium machine, can I compile SGI Pro64 source code on the machine and get an executable SGI Pro64 compiler? If so, which targ_* directory among targcygnus_ia32_ia64, targ_ia32_ia64_nodebug, targ_ia64 should I compile? We were working on this before the project was discontinued. We could build the compiler, but it had more failures then the ia32-host compiler (and I'm not sure if the sources we last released had all the necessary changes for building). So if you want to push this through, be aware that there is work yet to be done. As far as where to build it, we just built it under targia64. -- Mike Murphy -- mpm@sgi.com -- quote of the day: -- "No man is an island" (John Donne) From owner-pro64-support@oss.sgi.com Fri Aug 17 11:32:01 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7HIW1x09043 for pro64-support-outgoing; Fri, 17 Aug 2001 11:32:01 -0700 Received: from ganymede.or.intel.com (jffdns01.or.intel.com [134.134.248.3]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7HIVsj09036 for ; Fri, 17 Aug 2001 11:31:59 -0700 Received: from SMTP (orsmsxvs02-1.jf.intel.com [192.168.65.201]) by ganymede.or.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.41 2001/07/09 21:06:22 root Exp $) with SMTP id SAA23800; Fri, 17 Aug 2001 18:31:00 GMT Received: from orsmsx26.jf.intel.com ([192.168.70.26]) by 192.168.70.201 (Norton AntiVirus for Internet Email Gateways 1.0) ; Fri, 17 Aug 2001 18:26:25 0000 (GMT) Received: by orsmsx26.jf.intel.com with Internet Mail Service (5.5.2653.19) id ; Fri, 17 Aug 2001 11:17:19 -0700 Message-ID: <9287DC1579B0D411AA2F009027F44C3F0ABD063F@FMSMSX41> From: "Chan, Sun C" To: "'Hongbo Yang'" , pro64-support@oss.sgi.com Subject: RE: How to compile SGI Pro64 Source code on Itanium Date: Fri, 17 Aug 2001 11:17:15 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-pro64-support@oss.sgi.com Precedence: bulk I suggest you hold off doing that. There are issues in that GCC is not stable enough to give you a native compiler. Someone in my group tried that. You'll be better off with a cross compiler. If you want, I can ask him to forward you his findings. Sun > -----Original Message----- > From: Hongbo Yang [mailto:hyang@capsl.udel.edu] > Sent: Friday, August 17, 2001 9:07 AM > To: pro64-support@oss.sgi.com > Subject: How to compile SGI Pro64 Source code on Itanium > > > > Assume I have an Itanium machine, can I compile SGI Pro64 > source code on > the machine and get an executable SGI Pro64 compiler? If so, > which targ_* > directory among targcygnus_ia32_ia64, targ_ia32_ia64_nodebug, > targ_ia64 > should I compile? > > -------------------------------- > Hongbo Yang > > Electrical Engineering > Univ of Delaware > > > From owner-pro64-support@oss.sgi.com Fri Aug 17 11:55:02 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7HIt2x09501 for pro64-support-outgoing; Fri, 17 Aug 2001 11:55:02 -0700 Received: from zok.sgi.com (zok.sgi.com [204.94.215.101]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7HIt1j09498 for ; Fri, 17 Aug 2001 11:55:01 -0700 Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by zok.sgi.com (8.11.4/8.11.4/linux-outbound_gateway-1.0) with ESMTP id f7HJ0wa25215 for ; Fri, 17 Aug 2001 12:00:58 -0700 Received: from sgi.com (gaea.engr.sgi.com [130.62.180.97]) by cthulhu.engr.sgi.com (SGI-8.9.3/8.9.3) with ESMTP id LAA46381; Fri, 17 Aug 2001 11:53:39 -0700 (PDT) Message-ID: <3B7D6833.E23CD792@sgi.com> Date: Fri, 17 Aug 2001 11:53:39 -0700 From: Chandrasekhar Murthy X-Mailer: Mozilla 4.51C-SGI [en] (X11; I; IRIX 6.5 IP32) X-Accept-Language: en MIME-Version: 1.0 To: Hongbo Yang CC: pro64-support@oss.sgi.com Subject: Re: How to compile SGI Pro64 Source code on Itanium References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-pro64-support@oss.sgi.com Precedence: bulk Hongbo Yang wrote: > Assume I have an Itanium machine, can I compile SGI Pro64 source code on > the machine and get an executable SGI Pro64 compiler? If so, which targ_* > directory among targcygnus_ia32_ia64, targ_ia32_ia64_nodebug, targ_ia64 > should I compile? > > -------------------------------- > Hongbo Yang > > Electrical Engineering > Univ of Delaware We were able to do native builds, but you might not be able to do so because of problems with g++. You need to build in the targia64 directory. I used to have the following Makefile.override in the targia64 directory BUILD_OPTIMIZE = NODEBUG BUILD_COMPILER = GNU BUILD_HOST = IA64 NODEBUG was required especially for the backend as g++ was choking on several files in CG. GNU is required to force it to use g++. There is also the possibility that although we were able to build it here internally, the oss website might not have been updated. Some of the files would require modifying the assembler file in order to compile successfully (there were about 3 or 4 of these), mainly dealing with operator== (and other variants of these). For all practical purposes, gdb was practically unuseable on these compilers, and I had to resort to debugging the old fashioned way by using printfs. Murthy From owner-pro64-support@oss.sgi.com Fri Aug 17 13:28:40 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7HKSeL11861 for pro64-support-outgoing; Fri, 17 Aug 2001 13:28:40 -0700 Received: from Cantor.suse.de (ns.suse.de [213.95.15.193]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7HKScj11858 for ; Fri, 17 Aug 2001 13:28:38 -0700 Received: from Hermes.suse.de (Hermes.suse.de [213.95.15.136]) by Cantor.suse.de (Postfix) with ESMTP id 70E7F1E848; Fri, 17 Aug 2001 21:46:34 +0200 (MEST) Date: Fri, 17 Aug 2001 21:35:05 +0200 From: Andi Kleen To: "Chan, Sun C" Cc: "'Hongbo Yang'" , pro64-support@oss.sgi.com Subject: Re: How to compile SGI Pro64 Source code on Itanium Message-ID: <20010817213505.A2466@gruyere.muc.suse.de> References: <9287DC1579B0D411AA2F009027F44C3F0ABD063F@FMSMSX41> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <9287DC1579B0D411AA2F009027F44C3F0ABD063F@FMSMSX41>; from sun.c.chan@intel.com on Fri, Aug 17, 2001 at 11:17:15AM -0700 Sender: owner-pro64-support@oss.sgi.com Precedence: bulk On Fri, Aug 17, 2001 at 11:17:15AM -0700, Chan, Sun C wrote: > I suggest you hold off doing that. There are issues in that > GCC is not stable enough to give you a native compiler. Someone > in my group tried that. You'll be better off with a cross compiler. > If you want, I can ask him to forward you his findings. At one time for some reason I also tried to generate a ppc to ia64 cross compiler. This first needed various hackery in the source to compile with gcc 2.95 and to set some big endian symbols; but then in the end I got very strange crashes in the C frontend. I eventually gave up when I discovered that the ppc gdb at that time wasn't strong enough to properly process the resulting core files. -Andi From owner-pro64-support@oss.sgi.com Wed Aug 22 14:25:25 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7MLPPk06508 for pro64-support-outgoing; Wed, 22 Aug 2001 14:25:25 -0700 Received: from sunkay.cs.ualberta.ca (sunkay.cs.ualberta.ca [129.128.4.11]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7MLPId06503 for ; Wed, 22 Aug 2001 14:25:18 -0700 Received: (from localhost user: 'pengzhao' uid#483 fake: STDIN (pengzhao@peers)) by sunkay.cs.ualberta.ca id ; Wed, 22 Aug 2001 15:24:49 -0600 Date: Wed, 22 Aug 2001 15:24:49 -0600 (MDT) From: Peng Zhao To: sgi Subject: some questions Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-pro64-support@oss.sgi.com Precedence: bulk Hi, Following are some questions about whirltree and symbol table. 1. what is the difference between WN_PARM_BY_REFERENCE & WN_PARM_BY_VALUE? I found that it doesnot necessarily use BY_REFERENCE when Pro64 want to generate a "pointer" parameter. I got this opinion by checking the dumped whirl tree. e.g. from InnerProduct(&a); we get: U8LDA [[0]] <2,3,a> T<30,anon_ptr.,8> U8PARM #2 T<30,anon_ptr.,8> # by_value VCALL #126 <1,21,InnerProduct> # flags 0x7e the parameter is "by_value" instead of "by-reference" 2. From the "WHIRL SYMBOL TABLE SPECIFICATION", " in a nested procedure, three ST_TABs are visible: its own local ST_TAB, the parent PU's ST_TAB and the global ST_TAB". Can somebody explain me why the parent PU's ST_TAB should be visible to the nested function? 3. What is the difference between STR_TAB & TCON_STR_TAB? the document mentions there difference in terms of null-terminatation. But I still cannot see the point? why we need the same thing with two styles? 4. Is there any possibility that a function is placed dis-contiguously in the final executable (use jmp to connect the control flow)? Thanks From owner-pro64-support@oss.sgi.com Wed Aug 22 14:37:20 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7MLbKu06830 for pro64-support-outgoing; Wed, 22 Aug 2001 14:37:20 -0700 Received: from baucis.sc.intel.com (ns3.intel.com [143.183.152.22]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7MLbCd06818 for ; Wed, 22 Aug 2001 14:37:17 -0700 Received: from SMTP (fmsmsxvs03-1.fm.intel.com [132.233.42.203]) by baucis.sc.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.41 2001/07/09 21:06:22 root Exp $) with SMTP id VAA02189; Wed, 22 Aug 2001 21:36:59 GMT Received: from fmsmsx26.fm.intel.com ([132.233.48.26]) by 132.233.48.203 (Norton AntiVirus for Internet Email Gateways 1.0) ; Wed, 22 Aug 2001 21:36:58 0000 (GMT) Received: by fmsmsx26.fm.intel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 22 Aug 2001 14:36:57 -0700 Message-ID: <9287DC1579B0D411AA2F009027F44C3F0ABD0670@FMSMSX41> From: "Chan, Sun C" To: "'Peng Zhao'" , sgi Subject: RE: some questions Date: Wed, 22 Aug 2001 14:36:55 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-pro64-support@oss.sgi.com Precedence: bulk > -----Original Message----- > From: Peng Zhao [mailto:pengzhao@cs.ualberta.ca] > Sent: Wednesday, August 22, 2001 2:25 PM > To: sgi > Subject: some questions > > > Hi, > > Following are some questions about whirltree and symbol table. > > 1. what is the difference between WN_PARM_BY_REFERENCE & > WN_PARM_BY_VALUE? I found that it doesnot necessarily use BY_REFERENCE F90 can have reference parm > when Pro64 want to generate a "pointer" parameter. I got this opinion > by checking the dumped whirl tree. > > e.g. from InnerProduct(&a); > we get: > > U8LDA [[0]] <2,3,a> T<30,anon_ptr.,8> > U8PARM #2 T<30,anon_ptr.,8> # by_value > VCALL #126 <1,21,InnerProduct> # flags 0x7e > > the parameter is "by_value" instead of "by-reference" > > 2. From the "WHIRL SYMBOL TABLE SPECIFICATION", " in a nested > procedure, three ST_TABs are visible: its own local ST_TAB, the parent > PU's ST_TAB and the global ST_TAB". Can somebody explain me > why the parent > PU's ST_TAB should be visible to the nested function? Again, F90 typed nested function > > 3. What is the difference between STR_TAB & TCON_STR_TAB? the > document mentions there difference in terms of > null-terminatation. But I > still cannot see the point? why we need the same thing with > two styles? > > 4. Is there any possibility that a function is placed > dis-contiguously in the final executable (use jmp to connect > the control > flow)? This is a function of the code generator cabability. In general, yes, there is nothing against that. One needs to be careful about exception handling and stack unwinding when you put out debug info for stack tracing. Sun From owner-pro64-support@oss.sgi.com Wed Aug 22 14:40:13 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7MLeDe06913 for pro64-support-outgoing; Wed, 22 Aug 2001 14:40:13 -0700 Received: from pneumatic-tube.sgi.com (pneumatic-tube.sgi.com [204.94.214.22]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7MLeBd06910 for ; Wed, 22 Aug 2001 14:40:11 -0700 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 OAA02137 for ; Wed, 22 Aug 2001 14:38:21 -0700 (PDT) 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 OAA94743; Wed, 22 Aug 2001 14:39:47 -0700 (PDT) Date: Wed, 22 Aug 2001 14:39:47 -0700 (PDT) From: mpm@rohi.engr.sgi.com (Michael Murphy) Message-Id: <200108222139.OAA94743@rohi.engr.sgi.com> To: sgi , Peng Zhao Subject: Re: some questions Sender: owner-pro64-support@oss.sgi.com Precedence: bulk From: Peng Zhao 2. From the "WHIRL SYMBOL TABLE SPECIFICATION", " in a nested procedure, three ST_TABs are visible: its own local ST_TAB, the parent PU's ST_TAB and the global ST_TAB". Can somebody explain me why the parent PU's ST_TAB should be visible to the nested function? Because you can access variables in your parent PU. 4. Is there any possibility that a function is placed dis-contiguously in the final executable (use jmp to connect the control flow)? The bb's may be reordered, so that you jump to less-used blocks. But the function bb's are all contiguous. -- Mike Murphy -- mpm@sgi.com -- quote of the day: -- "We always have time for the things we put first" From owner-pro64-support@oss.sgi.com Wed Aug 22 21:12:56 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7N4Cu513899 for pro64-support-outgoing; Wed, 22 Aug 2001 21:12:56 -0700 Received: from web3506.mail.yahoo.com (web3506.mail.yahoo.com [216.115.111.73]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7N4Ctd13896 for ; Wed, 22 Aug 2001 21:12:55 -0700 Message-ID: <20010823041255.29186.qmail@web3506.mail.yahoo.com> Received: from [65.5.107.155] by web3506.mail.yahoo.com via HTTP; Wed, 22 Aug 2001 21:12:55 PDT Date: Wed, 22 Aug 2001 21:12:55 -0700 (PDT) From: Shin-Ming Liu Subject: RE: some questions To: "Chan, Sun C" , "'Peng Zhao'" , sgi In-Reply-To: <9287DC1579B0D411AA2F009027F44C3F0ABD0670@FMSMSX41> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-pro64-support@oss.sgi.com Precedence: bulk > > 3. What is the difference between STR_TAB & > TCON_STR_TAB? the > > document mentions there difference in terms of > > null-terminatation. But I > > still cannot see the point? why we need the same > thing with > > two styles? This is also due to Fortran. __________________________________________________ Do You Yahoo!? Make international calls for as low as $.04/minute with Yahoo! Messenger http://phonecard.yahoo.com/ From owner-pro64-support@oss.sgi.com Thu Aug 23 13:52:20 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7NKqK505476 for pro64-support-outgoing; Thu, 23 Aug 2001 13:52:20 -0700 Received: from sunkay.cs.ualberta.ca (root@sunkay.cs.ualberta.ca [129.128.4.11]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7NKqBd05471 for ; Thu, 23 Aug 2001 13:52:11 -0700 Received: (from localhost user: 'pengzhao' uid#483 fake: STDIN (pengzhao@peers)) by sunkay.cs.ualberta.ca id ; Thu, 23 Aug 2001 14:43:40 -0600 Date: Thu, 23 Aug 2001 14:43:40 -0600 (MDT) From: Peng Zhao To: sgi Subject: Still a question about scope Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-pro64-support@oss.sgi.com Precedence: bulk Hi, "Whirl Symbol Table Specification" says (bottom of page 4), "Associated with each PU, a SCOPE array is defined for specifying the list of visible tables, ..., index 2 refers to the local symbol tables. A nested procedure will have an index starting at 3, depending on the level of nesting." Here is my understanding, please correct me if I am wrong. 1. the nested procedure means a procedure defined in another procedure. Like: void A() { // local variables for A() ... int B() { ..... } } but if A calls another procedure C, C is not a nested procedure. 2. Each procedure in the program has a scope table for itself. and index 1 always points to the global symbol table. The 2nd element of the scope table always points to the local symbol table. Now the question comes: I have the following programs: main() { int a ; void A() { int b; printf("a=%d,b=%d\n",a,b); } printf("--------------------\n"); } } I get the whirl tree for A(), LOC 1 8 int b; LOC 1 9 printf("a=%d,b=%d\n",a,b); U8LDA [[0]] <1,23,(11_bytes)_"a=%d,b=%d\n\000"> T<32,anon_ptr.,8> U8PARM #2 T<29,anon_ptr.,8> # by_value I4I4LDID [[0]] <2,1,a> T<4,.predef_I4,4> I4PARM #2 T<4,.predef_I4,4> # by_value I4I4LDID [[0]] <3,1,b> T<4,.predef_I4,4> I4PARM #2 T<4,.predef_I4,4> # by_value VCALL #126 <1,22,printf> # flags 0x7e there is <2,1,a> and <3,1,b> Can I draw the conclusion that in a nested procedure, the local symbol table will not be the second element of its scope array? e.g. if we have four procedures, and A > B > C > D, in which "x>y" means y is nested in x. Then the lexical level of A,B,C and D's symbol table will be 2,3,4,5, respectively. Right? 3. And if A>B, and B wants to access a variable(say X) in A, there is no need for B's local symbol table to hold any information about X. It is just like a local variable to B, though the whirl node's related field (about the lexical level) should be modified. Right? Thanks From owner-pro64-support@oss.sgi.com Fri Aug 24 11:30:21 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7OIULd20758 for pro64-support-outgoing; Fri, 24 Aug 2001 11:30:21 -0700 Received: from sgi.com (sgi.SGI.COM [192.48.153.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7OIUFd20751 for ; Fri, 24 Aug 2001 11:30:15 -0700 Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id LAA04065 for ; Fri, 24 Aug 2001 11:30:15 -0700 (PDT) mail_from (murthy@sgi.com) Received: from sgi.com (gaea.engr.sgi.com [130.62.180.97]) by cthulhu.engr.sgi.com (SGI-8.9.3/8.9.3) with ESMTP id LAA44562; Fri, 24 Aug 2001 11:28:58 -0700 (PDT) Message-ID: <3B869CEA.667A9C1F@sgi.com> Date: Fri, 24 Aug 2001 11:28:58 -0700 From: Chandrasekhar Murthy X-Mailer: Mozilla 4.51C-SGI [en] (X11; I; IRIX 6.5 IP32) X-Accept-Language: en MIME-Version: 1.0 To: Peng Zhao CC: sgi Subject: Re: Still a question about scope References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-pro64-support@oss.sgi.com Precedence: bulk Peng Zhao wrote: > Hi, > > "Whirl Symbol Table Specification" says (bottom of page 4), > "Associated with each PU, a SCOPE array is defined for specifying the list > of visible tables, ..., index 2 refers to the local symbol tables. A > nested procedure will have an index starting at 3, depending on the level > of nesting." > > Here is my understanding, please correct me if I am wrong. > > 1. the nested procedure means a procedure defined in another > procedure. Like: > > void A() > { > // local variables for A() > ... > > int B() > { > ..... > } > } > > but if A calls another procedure C, C is not a nested procedure. > That is correct assuming that C is not defined in the scope of A. > > 2. Each procedure in the program has a scope table for itself. and > index 1 always points to the global symbol table. The 2nd element of the > scope table always points to the local symbol table. > > Now the question comes: > > I have the following programs: > > main() > { > int a ; > void A() > { > int b; > printf("a=%d,b=%d\n",a,b); > > } > printf("--------------------\n"); } > } > > > I get the whirl tree for A(), > > LOC 1 8 int b; > LOC 1 9 printf("a=%d,b=%d\n",a,b); > U8LDA [[0]] <1,23,(11_bytes)_"a=%d,b=%d\n\000"> T<32,anon_ptr.,8> > U8PARM #2 T<29,anon_ptr.,8> # by_value > I4I4LDID [[0]] <2,1,a> T<4,.predef_I4,4> > I4PARM #2 T<4,.predef_I4,4> # by_value > I4I4LDID [[0]] <3,1,b> T<4,.predef_I4,4> > I4PARM #2 T<4,.predef_I4,4> # by_value > VCALL #126 <1,22,printf> # flags 0x7e > > there is <2,1,a> and <3,1,b> > > Can I draw the conclusion that in a nested procedure, the local > symbol table will not be the second element of its scope array? > > e.g. > if we have four procedures, and A > B > C > D, in which > "x>y" means y is nested in x. > Then the lexical level of A,B,C and D's symbol table will be > 2,3,4,5, respectively. Right? > That is correct. > > 3. And if A>B, and B wants to access a variable(say X) in A, > there is no need for B's local symbol table to hold any information about > X. It is just like a local variable to B, though the whirl node's related > field (about the lexical level) should be modified. Right? > > > Thanks You are correct in assuming that B's local symbol table should not hold any information about X. I would not view X as being a local variable in B as it is defined outside the scope of B. Most of the WHIRL generation routines deal with ST*, but if you are dealing with ST_IDX, you need to set the right nesting level. Murthy From owner-pro64-support@oss.sgi.com Sun Aug 26 16:23:07 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7QNN7R08720 for pro64-support-outgoing; Sun, 26 Aug 2001 16:23:07 -0700 Received: from sunkay.cs.ualberta.ca (root@sunkay.cs.ualberta.ca [129.128.4.11]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7QNMdd08715 for ; Sun, 26 Aug 2001 16:22:41 -0700 Received: (from localhost user: 'pengzhao' uid#483 fake: STDIN (pengzhao@peers)) by sunkay.cs.ualberta.ca id ; Sun, 26 Aug 2001 17:22:30 -0600 Date: Sun, 26 Aug 2001 17:22:30 -0600 (MDT) From: Peng Zhao To: sgi Subject: multi-entry CFG Message-ID: MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="-2138965737-424574681-998868150=:26972" Sender: owner-pro64-support@oss.sgi.com Precedence: bulk This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. Send mail to mime@docserver.cac.washington.edu for more info. ---2138965737-424574681-998868150=:26972 Content-Type: TEXT/PLAIN; charset=US-ASCII Hi, Enclosed two files are a simple C program and the related CFG created in the pre_optimizer. There are several entries for the CFG. And I want to use cfg->Entry_bb()->Id() & cfg->Exit_bb()->Id() to get the entry&exit of the CFG(Initially, I had thought there should be only one entry and one exit). The result is: entry=16,exit=17 Can somebody explain me when this kind of CFG is generated? Thanks. -- Regards Peng -- Peng Zhao pengzhao@cs.ualberta.ca http://www.cs.ualberta.ca/~pengzhao TEL (Lab): (780)492-3725 Lab: CSC251 ---2138965737-424574681-998868150=:26972 Content-Type: APPLICATION/PostScript; name=cfg Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: Content-Disposition: attachment; filename=cfg JSFQUy1BZG9iZS0zLjAgRVBTRi0zLjAKJSVCb3VuZGluZ0JveDogMCAwIDUz NCA4MTcKJSVDcmVhdG9yOiBkYVZpbmNpIFYyLjEgKGluZm8gYXZhaWxhYmxl IGZyb20gZGFWaW5jaUBJbmZvcm1hdGlrLlVuaS1CcmVtZW4uREUpCiUlRm9y OiBwZW5nemhhb0BzYWt3YXRhbWF1IChQZW5nIFpoYW8pCiUlVGl0bGU6IAol JUNyZWF0aW9uRGF0ZTogVGh1IEp1bCAyNiAxMzozNToxMCAyMDAxCgolJVBh Z2VzOiAxCiUlRG9jdW1lbnROZWVkZWRSZXNvdXJjZXM6CiUlKyBmb250IEx1 Y2lkYVNhbnMKJSUrIGZvbnQgTHVjaWRhU2Fucy1Cb2xkCiUlKyBmb250IEx1 Y2lkYVNhbnMtSXRhbGljCiUlKyBmb250IEx1Y2lkYVNhbnMtQm9sZEl0YWxp YwolJSsgZm9udCBUaW1lcy1Sb21hbgolJSsgZm9udCBUaW1lcy1Cb2xkCiUl KyBmb250IFRpbWVzLUl0YWxpYwolJSsgZm9udCBUaW1lcy1Cb2xkSXRhbGlj CiUlKyBmb250IEhlbHZldGljYQolJSsgZm9udCBIZWx2ZXRpY2EtQm9sZAol JSsgZm9udCBIZWx2ZXRpY2EtT2JsaXF1ZQolJSsgZm9udCBIZWx2ZXRpY2Et Qm9sZE9ibGlxdWUKJSUrIGZvbnQgSGVsdmV0aWNhLU5hcnJvdwolJSsgZm9u dCBIZWx2ZXRpY2EtTmFycm93LUJvbGQKJSUrIGZvbnQgSGVsdmV0aWNhLU5h cnJvdy1PYmxpcXVlCiUlKyBmb250IEhlbHZldGljYS1OYXJyb3ctQm9sZE9i bGlxdWUKJSUrIGZvbnQgQ291cmllcgolJSsgZm9udCBDb3VyaWVyLUJvbGQK JSUrIGZvbnQgQ291cmllci1PYmxpcXVlCiUlKyBmb250IENvdXJpZXItQm9s ZE9ibGlxdWUKJSUrIGZvbnQgWmFwZkNoYW5jZXJ5LU1lZGl1bUl0YWxpYwol JUVuZENvbW1lbnRzCgolJUJlZ2luUHJvbG9nCi9kYVZpbmNpX2RpY3QgMjAw IGRpY3QgZGVmCmRhVmluY2lfZGljdCBiZWdpbgovZm9udHNpemUgMTIgZGVm CgovY3AgJSBOYW1lT2ZGb250VG9CZUNvcGllZAp7IGZpbmRmb250IGR1cCBs ZW5ndGggZGljdCBiZWdpbiAKICB7IDEgaW5kZXggL0ZJRCBuZSB7ZGVmfSB7 cG9wIHBvcH0gaWZlbHNlfSBmb3JhbGwgCiAgL0VuY29kaW5nIElTT0xhdGlu MUVuY29kaW5nIGRlZiBjdXJyZW50ZGljdCBlbmQgCn0gZGVmCi9ybiAlIE5h bWVPZk5ld0ZvbnRXaXRoSXNvRW5jb2RpbmcKeyBleGNoIGRlZmluZWZvbnQg cG9wIH0gZGVmCi9zZiAlIE5hbWVPZkZvbnRUb0JlU2V0CnsgZmluZGZvbnQg Zm9udHNpemUgc2NhbGVmb250IHNldGZvbnQgfSBkZWYKCiUgQ29weSBhbGwg Zm9udHMgdG8gZ2V0IElTTyA4LWJpdCBjaGFycwovVGltZXMtUm9tYW4gY3Ag L0ZvbnRUaW1lcyBybgovVGltZXMtQm9sZCBjcCAvRm9udFRpbWVzQm9sZCBy bgovVGltZXMtSXRhbGljIGNwIC9Gb250VGltZXNJdGFsaWMgcm4KL1RpbWVz LUJvbGRJdGFsaWMgY3AgL0ZvbnRUaW1lc0JvbGRJdGFsaWMgcm4KL0hlbHZl dGljYS1OYXJyb3cgY3AgL0ZvbnRIZWx2ZXRpY2FOYXJyb3cgcm4KL0hlbHZl dGljYS1OYXJyb3ctQm9sZCBjcCAvRm9udEhlbHZldGljYU5hcnJvd0JvbGQg cm4KL0hlbHZldGljYS1OYXJyb3ctT2JsaXF1ZSBjcCAvRm9udEhlbHZldGlj YU5hcnJvd0l0YWxpYyBybgovSGVsdmV0aWNhLU5hcnJvdy1Cb2xkT2JsaXF1 ZSBjcCAvRm9udEhlbHZldGljYU5hcnJvd0JvbGRJdGFsaWMgcm4KL0NvdXJp ZXIgY3AgL0ZvbnRDb3VyaWVyIHJuCi9Db3VyaWVyLUJvbGQgY3AgL0ZvbnRD b3VyaWVyQm9sZCBybgovQ291cmllci1PYmxpcXVlIGNwIC9Gb250Q291cmll ckl0YWxpYyBybgovQ291cmllci1Cb2xkT2JsaXF1ZSBjcCAvRm9udENvdXJp ZXJCb2xkSXRhbGljIHJuCi9MdWNpZGFTYW5zIGNwIC9Gb250THVjaWRhIHJu Ci9MdWNpZGFTYW5zLUJvbGQgY3AgL0ZvbnRMdWNpZGFCb2xkIHJuCi9MdWNp ZGFTYW5zLUl0YWxpYyBjcCAvRm9udEx1Y2lkYUl0YWxpYyBybgovTHVjaWRh U2Fucy1Cb2xkSXRhbGljIGNwIC9Gb250THVjaWRhQm9sZEl0YWxpYyBybgov SGVsdmV0aWNhIGNwIC9Gb250SGVsdmV0aWNhIHJuCi9IZWx2ZXRpY2EtQm9s ZCBjcCAvRm9udEhlbHZldGljYUJvbGQgcm4KL0hlbHZldGljYS1PYmxpcXVl IGNwIC9Gb250SGVsdmV0aWNhSXRhbGljIHJuCi9IZWx2ZXRpY2EtQm9sZE9i bGlxdWUgY3AgL0ZvbnRIZWx2ZXRpY2FCb2xkSXRhbGljIHJuCgolIERlZmlu ZSBmb250cwovZm9udF90aW1lc19ub3JtYWwgeyAvRm9udFRpbWVzIHNmIH0g ZGVmCi9mb250X3RpbWVzX2JvbGQgeyAvRm9udFRpbWVzQm9sZCBzZiB9IGRl ZgovZm9udF90aW1lc19pdGFsaWMgeyAvRm9udFRpbWVzSXRhbGljIHNmIH0g ZGVmCi9mb250X3RpbWVzX2JvbGRfaXRhbGljIHsgL0ZvbnRUaW1lc0JvbGRJ dGFsaWMgc2YgfSBkZWYKL2ZvbnRfaGVsdmV0aWNhX25vcm1hbCB7IC9Gb250 SGVsdmV0aWNhTmFycm93IHNmIH0gZGVmCi9mb250X2hlbHZldGljYV9ib2xk IHsgL0ZvbnRIZWx2ZXRpY2FOYXJyb3dCb2xkIHNmIH0gZGVmCi9mb250X2hl bHZldGljYV9pdGFsaWMgeyAvRm9udEhlbHZldGljYU5hcnJvd0l0YWxpYyBz ZiB9IGRlZgovZm9udF9oZWx2ZXRpY2FfYm9sZF9pdGFsaWMgeyAvRm9udEhl bHZldGljYU5hcnJvd0JvbGRJdGFsaWMgc2YgfSBkZWYKL2ZvbnRfY291cmll cl9ub3JtYWwgeyAvRm9udENvdXJpZXIgc2YgfSBkZWYKL2ZvbnRfY291cmll cl9ib2xkIHsgL0ZvbnRDb3VyaWVyQm9sZCBzZiB9IGRlZgovZm9udF9jb3Vy aWVyX2l0YWxpYyB7IC9Gb250Q291cmllckl0YWxpYyBzZiB9IGRlZgovZm9u dF9jb3VyaWVyX2JvbGRfaXRhbGljIHsgL0ZvbnRDb3VyaWVyQm9sZEl0YWxp YyBzZiB9IGRlZgoKJSBTcGVjaWFsIGNhc2U6IHVzZSBmb250IEhlbHZldGlj YSwgaWYgTHVjaWRhIGlzIG5vdCBzdXBwb3J0ZWQKL2ZvbnRfbHVjaWRhX25v cm1hbAp7IC9MdWNpZGFTYW5zIGR1cCBGb250RGlyZWN0b3J5IGV4Y2gga25v d24KICB7IC9Gb250THVjaWRhIHNmIH0geyAvRm9udEhlbHZldGljYSBzZiB9 IGlmZWxzZSBwb3AKfSBkZWYKL2ZvbnRfbHVjaWRhX2JvbGQgCnsgL0x1Y2lk YVNhbnMtQm9sZCBkdXAgRm9udERpcmVjdG9yeSBleGNoIGtub3duCiAgeyAv Rm9udEx1Y2lkYUJvbGQgc2YgfSB7IC9Gb250SGVsdmV0aWNhQm9sZCBzZiB9 IGlmZWxzZSBwb3AKfSBkZWYKL2ZvbnRfbHVjaWRhX2l0YWxpYyAKeyAvTHVj aWRhU2Fucy1JdGFsaWMgZHVwIEZvbnREaXJlY3RvcnkgZXhjaCBrbm93bgog IHsgL0ZvbnRMdWNpZGFJdGFsaWMgc2YgfSB7IC9Gb250SGVsdmV0aWNhSXRh bGljIHNmIH0gaWZlbHNlIHBvcAp9IGRlZgovZm9udF9sdWNpZGFfYm9sZF9p dGFsaWMgCnsgL0x1Y2lkYVNhbnMtQm9sZEl0YWxpYyBkdXAgRm9udERpcmVj dG9yeSBleGNoIGtub3duCiAgeyAvRm9udEx1Y2lkYUJvbGRJdGFsaWMgc2Yg fSB7IC9Gb250SGVsdmV0aWNhQm9sZEl0YWxpYyBzZiB9IGlmZWxzZSBwb3AK fSBkZWYKCi93aGl0ZSB7MSAxIDEgc2V0cmdiY29sb3J9IGRlZgovYmxhY2sg ezAgMCAwIHNldHJnYmNvbG9yfSBkZWYKCi9zb2xpZCB7IH0gYmluZCBkZWYK L2RvdHRlZCB7IFsxIDJdIDEgc2V0ZGFzaH0gYmluZCBkZWYKL2Rhc2hlZCB7 IFs0IDhdIDAgc2V0ZGFzaH0gYmluZCBkZWYKCi9yZWN0YW5nbGUgJSBPcmln aW5YIE9yaWdpblkgV2lkdGggSGVpZ2h0CnsgbmV3cGF0aAogIDMgaW5kZXgg MyBpbmRleCBtb3ZldG8gJSBPcmlnaW5YL09yaWdpblkKICAxIGluZGV4IDAg cmxpbmV0byAlIE9yaWdpblgrV2lkdGgvT3JpZ2luWQogIDAgMSBpbmRleCBu ZWcgcmxpbmV0byAlIE9yaWdpblgrV2lkdGgvT3JpZ2luWStIZWlnaHQKICBl eGNoIG5lZyAwIHJsaW5ldG8gJSBPcmlnaW5YL09yaWdpblkrSGVpZ2h0CiAg MCBleGNoIHJsaW5ldG8gJSBPcmlnaW5YL09yaWdpblkKICBjbG9zZXBhdGgg cG9wIHBvcAp9IGRlZgovZHJhd19yZWN0YW5nbGUgeyBnc2F2ZSByZWN0YW5n bGUgc3Ryb2tlIGdyZXN0b3JlfSBkZWYKL2ZpbGxfcmVjdGFuZ2xlIHsgZ3Nh dmUgcmVjdGFuZ2xlIGZpbGwgZ3Jlc3RvcmV9IGRlZgoKL2NpcmNsZSAlIE9y aWdpblggT3JpZ2luWSAyKlJhZGl1cwp7IG5ld3BhdGgKICAyIGluZGV4IDEg aW5kZXggMiBkaXYgYWRkIDIgaW5kZXggMiBpbmRleCAyIGRpdiBzdWIgJSBD ZW50ZXJYL0NlbnRlclkKICAyIGluZGV4IDIgZGl2IDAgMzYwIGFyYwogIGNs b3NlcGF0aCBwb3AgcG9wIHBvcAp9IGRlZgovZHJhd19jaXJjbGUgeyBnc2F2 ZSBjaXJjbGUgc3Ryb2tlIGdyZXN0b3JlfSBkZWYKL2ZpbGxfY2lyY2xlIHsg Z3NhdmUgY2lyY2xlIGZpbGwgZ3Jlc3RvcmV9IGRlZgoKL2VsbGlwc2UgJSBP cmlnaW5YIE9yaWdpblkgV2lkdGggSGVpZ2h0CnsgbmV3cGF0aAogIDMgaW5k ZXggMyBpbmRleCAyIGluZGV4IDAuNSBtdWwgc3ViIG1vdmV0byAlIE9yaWdp blgvT3JpZ2luWS0oSGVpZ2h0LzIpCiAgMyBpbmRleCAzIGluZGV4IDIgaW5k ZXggMC4xNCBtdWwgYWRkICUgT3JpZ2luWC9PcmlnaW5ZKyhIZWlnaHQqMC4x NCkKICA1IGluZGV4IDQgaW5kZXggYWRkIDUgaW5kZXggNCBpbmRleCAwLjE0 IG11bCBhZGQgJSBPcmlnaW5YK1dpZHRoL09yaWdpblkrKEhlaWdodCowLjE0 KQogIDcgaW5kZXggNiBpbmRleCBhZGQgNyBpbmRleCA2IGluZGV4IDAuNSBt dWwgc3ViIGN1cnZldG8gJSBPcmlnaW5YK1dpZHRoL09yaWdpblktKEhlaWdo dC8yKQogIDMgaW5kZXggMiBpbmRleCBhZGQgMyBpbmRleCAyIGluZGV4IDEu MTQgbXVsIHN1YiAlIE9yaWdpblgrV2lkdGgvT3JpZ2luWS0oSGVpZ2h0KjEu MTQpCiAgNSBpbmRleCA1IGluZGV4IDQgaW5kZXggMS4xNCBtdWwgc3ViICUg T3JpZ2luWC9PcmlnaW5ZLShIZWlnaHQqMS4xNCkKICA3IGluZGV4IDcgaW5k ZXggNiBpbmRleCAwLjUgbXVsIHN1YiBjdXJ2ZXRvICUgT3JpZ2luWC9Pcmln aW5ZLShIZWlnaHQvMikKICBjbG9zZXBhdGggcG9wIHBvcCBwb3AgcG9wCn0g ZGVmCi9kcmF3X2VsbGlwc2Uge2dzYXZlIGVsbGlwc2Ugc3Ryb2tlIGdyZXN0 b3JlfSBkZWYKL2ZpbGxfZWxsaXBzZSB7Z3NhdmUgZWxsaXBzZSBmaWxsIGdy ZXN0b3JlfSBkZWYKCi9yaG9tYnVzICUgT3JpZ2luWCBPcmlnaW5ZIFdpZHRo IEhlaWdodAp7IG5ld3BhdGgKICAzIGluZGV4IDIgaW5kZXggMiBkaXYgYWRk IDMgaW5kZXggbW92ZXRvICUgT3JpZ2luWCsoV2lkdGgvMikvT3JpZ2luWQog IDEgaW5kZXggMiBkaXYgMSBpbmRleCAyIGRpdiBuZWcgcmxpbmV0byAlIE9y aWdpblgrV2lkdGgvT3JpZ2luWS0oSGVpZ2h0LzIpCiAgMSBpbmRleCAyIGRp diBuZWcgMSBpbmRleCAyIGRpdiBuZWcgcmxpbmV0byAlIE9yaWdpblgrKFdp ZHRoLzIpL09yaWdpblktSGVpZ2h0CiAgMSBpbmRleCAyIGRpdiBuZWcgMSBp bmRleCAyIGRpdiBybGluZXRvICUgT3JpZ2luWC9PcmlnaW5ZLShIZWlnaHQv MikKICBjbG9zZXBhdGggcG9wIHBvcCBwb3AgcG9wCn0gZGVmCi9kcmF3X3Jo b21idXMge2dzYXZlIHJob21idXMgc3Ryb2tlIGdyZXN0b3JlfSBkZWYKL2Zp bGxfcmhvbWJ1cyB7Z3NhdmUgcmhvbWJ1cyBmaWxsIGdyZXN0b3JlfSBkZWYK Ci90cmlhbmdsZSAlIE9yaWdpblggT3JpZ2luWSBXaWR0aCBIZWlnaHQKeyBu ZXdwYXRoCiAgMyBpbmRleCAyIGluZGV4IDIgZGl2IGFkZCAzIGluZGV4IG1v dmV0byAlIE9yaWdpblgrKFdpZHRoLzIpL09yaWdpblkKICAxIGluZGV4IDIg ZGl2IDEgaW5kZXggbmVnIHJsaW5ldG8gJSBPcmlnaW5YK1dpZHRoL09yaWdp blktSGVpZ2h0CiAgMSBpbmRleCBuZWcgMCBybGluZXRvICUgT3JpZ2luWC9P cmlnaW5ZLUhlaWdodAogIGNsb3NlcGF0aCBwb3AgcG9wIHBvcCBwb3AKfSBk ZWYKL2RyYXdfdHJpYW5nbGUge2dzYXZlIHRyaWFuZ2xlIHN0cm9rZSBncmVz dG9yZX0gZGVmCi9maWxsX3RyaWFuZ2xlIHtnc2F2ZSB0cmlhbmdsZSBmaWxs IGdyZXN0b3JlfSBkZWYKCi9kcmF3X3N0cmluZyAlIFN0cmluZyBDZW50ZXJY IENlbnRlclkKeyBnc2F2ZSBtb3ZldG8gc2hvdyBncmVzdG9yZQp9IGRlZgoK L2RyYXdfY2VudGVyZWRfc3RyaW5nICUgU3RyaW5nIENlbnRlclggQ2VudGVy WQp7IGdzYXZlIG5ld3BhdGggCglleGNoIDIgaW5kZXggc3RyaW5nd2lkdGgg cG9wIDIgZGl2IHN1YiBleGNoIAoJbW92ZXRvIHNob3cgZ3Jlc3RvcmUKfSBk ZWYKCi9kcmF3X2xpbmUgJSBTdGFydFggU3RhcnRZIEVuZFggRW5kWAp7IGdz YXZlIG5ld3BhdGggMyBpbmRleCAzIGluZGV4IG1vdmV0byBsaW5ldG8gY2xv c2VwYXRoIHBvcCBwb3AgCglzdHJva2UgZ3Jlc3RvcmUKfSBkZWYKCi9kcmF3 X2Fycm93ICUgSGVhZFggSGVhZFkgUG9pbnQxWCBQb2ludDFZIFBvaW50Mlgg UG9pbnQyWQp7IGdzYXZlIG5ld3BhdGggbW92ZXRvIGxpbmV0byBsaW5ldG8g Y2xvc2VwYXRoIHN0cm9rZSBncmVzdG9yZX0gZGVmCgovZmlsbF9hcnJvdyAl IEhlYWRYIEhlYWRZIFBvaW50MVggUG9pbnQxWSBQb2ludDJYIFBvaW50MlkK eyBnc2F2ZSBuZXdwYXRoIG1vdmV0byBsaW5ldG8gbGluZXRvIGNsb3NlcGF0 aCBmaWxsIGdyZXN0b3JlfSBkZWYKCi9kcmF3X3NlbGZyZWZfY2lyY2xlICUg T3JpZ2luWCBPcmlnaW5ZIDIqUmFkaXVzCnsgZ3NhdmUgbmV3cGF0aAogIDIg aW5kZXggMSBpbmRleCAyIGRpdiBhZGQgMiBpbmRleCAyIGluZGV4IDIgZGl2 IHN1YiAlIENlbnRlclgvQ2VudGVyWQogIDIgaW5kZXggMiBkaXYgNDUgMzYw IGFyYwogIHBvcCBwb3AgcG9wIHN0cm9rZSBncmVzdG9yZQp9IGRlZgoKL2Ry YXdfc2VsZnJlZl9jaXJjbGVfaG9yaXpvbnRhbCAlIE9yaWdpblggT3JpZ2lu WSAyKlJhZGl1cwp7IGdzYXZlIG5ld3BhdGgKICAyIGluZGV4IDEgaW5kZXgg MiBkaXYgYWRkIDIgaW5kZXggMiBpbmRleCAyIGRpdiBzdWIgJSBDZW50ZXJY L0NlbnRlclkKICAyIGluZGV4IDIgZGl2IDEzNSA0NTAgYXJjCiAgcG9wIHBv cCBwb3Agc3Ryb2tlIGdyZXN0b3JlCn0gZGVmCgovcmVhZHN0cmluZyB7CiAg Y3VycmVudGZpbGUgZXhjaCByZWFkaGV4c3RyaW5nIHBvcCAgCn0gYmluZCBk ZWYKL3BpY3N0ciAxIHN0cmluZyBkZWYKCi9kYVZpbmNpX2xvZ28KeyAvWmFw ZkNoYW5jZXJ5LU1lZGl1bUl0YWxpYyBmaW5kZm9udCAxMCBzY2FsZWZvbnQg c2V0Zm9udAogIChkYVZpbmNpKSBzaG93CiAgNCAwIHJtb3ZldG8gL0hlbHZl dGljYSBmaW5kZm9udCA4IHNjYWxlZm9udCBzZXRmb250IChWMi4xKSBzaG93 fSBkZWYKCiUlRW5kUHJvbG9nCgolJUJlZ2luU2V0dXAKJSVJbmNsdWRlUmVz b3VyY2U6CiUlKyBmb250IEx1Y2lkYVNhbnMKJSUrIGZvbnQgTHVjaWRhU2Fu cy1Cb2xkCiUlKyBmb250IEx1Y2lkYVNhbnMtSXRhbGljCiUlKyBmb250IEx1 Y2lkYVNhbnMtQm9sZEl0YWxpYwolJSsgZm9udCBUaW1lcy1Sb21hbgolJSsg Zm9udCBUaW1lcy1Cb2xkCiUlKyBmb250IFRpbWVzLUl0YWxpYwolJSsgZm9u dCBUaW1lcy1Cb2xkSXRhbGljCiUlKyBmb250IEhlbHZldGljYQolJSsgZm9u dCBIZWx2ZXRpY2EtQm9sZAolJSsgZm9udCBIZWx2ZXRpY2EtT2JsaXF1ZQol JSsgZm9udCBIZWx2ZXRpY2EtQm9sZE9ibGlxdWUKJSUrIGZvbnQgSGVsdmV0 aWNhLU5hcnJvdwolJSsgZm9udCBIZWx2ZXRpY2EtTmFycm93LUJvbGQKJSUr IGZvbnQgSGVsdmV0aWNhLU5hcnJvdy1PYmxpcXVlCiUlKyBmb250IEhlbHZl dGljYS1OYXJyb3ctQm9sZE9ibGlxdWUKJSUrIGZvbnQgQ291cmllcgolJSsg Zm9udCBDb3VyaWVyLUJvbGQKJSUrIGZvbnQgQ291cmllci1PYmxpcXVlCiUl KyBmb250IENvdXJpZXItQm9sZE9ibGlxdWUKJSUrIGZvbnQgWmFwZkNoYW5j ZXJ5LU1lZGl1bUl0YWxpYwolJUVuZFNldHVwCgolJVBhZ2U6IDEgMQoKZ3Nh dmUgMjAgMTUgbW92ZXRvIDkwIHJvdGF0ZSBkYVZpbmNpX2xvZ28gZ3Jlc3Rv cmUKMjUgZHVwIHRyYW5zbGF0ZQowLjYzNjQgZHVwIHNjYWxlCgpnc2F2ZSAx IHNldGxpbmV3aWR0aAogMC4wMCAwLjAwIDAuMDAgc2V0cmdiY29sb3IgIDI0 OSAxMTEwIDI0NCAxMTI0IDI1NCAxMTI0IGZpbGxfYXJyb3cgMSBzZXRsaW5l d2lkdGgKMjQ5IDExNzAgMjQ5IDExMjQgZHJhd19saW5lCjEgc2V0bGluZXdp ZHRoIGdyZXN0b3JlCgpmb250X2x1Y2lkYV9ib2xkCiAwLjU2IDAuOTMgMC41 NiBzZXRyZ2Jjb2xvciAgMjE5IDEyMjUgNjAgNTUgZmlsbF9yZWN0YW5nbGUK YmxhY2sgMjE5IDEyMjUgNjAgNTUgZHJhd19yZWN0YW5nbGUKKDE6ICkgMjI0 IDEyMDkgZHJhd19zdHJpbmcKKGluICA9IDAhKSAyMjQgMTE5MyBkcmF3X3N0 cmluZwoob3V0ID0gMSEpIDIyNCAxMTc3IGRyYXdfc3RyaW5nCmdzYXZlIDEg c2V0bGluZXdpZHRoCiAwLjAwIDAuMDAgMC4wMCBzZXRyZ2Jjb2xvciAgMjYx IDc1IDI2MSA4OSAyNzAgODYgZmlsbF9hcnJvdyAxIHNldGxpbmV3aWR0aAoy OTQgMTYzIDI2NSA4OCBkcmF3X2xpbmUKMSBzZXRsaW5ld2lkdGggZ3Jlc3Rv cmUKZ3NhdmUgMSBzZXRsaW5ld2lkdGgKIDAuMDAgMC4wMCAwLjAwIHNldHJn YmNvbG9yICAxIHNldGxpbmV3aWR0aAoyOTQgMjc4IDI5NCAxNjMgZHJhd19s aW5lCjEgc2V0bGluZXdpZHRoIGdyZXN0b3JlCmdzYXZlIDEgc2V0bGluZXdp ZHRoCiAwLjAwIDAuMDAgMC4wMCBzZXRyZ2Jjb2xvciAgMSBzZXRsaW5ld2lk dGgKMjk0IDM5MyAyOTQgMjc4IGRyYXdfbGluZQoxIHNldGxpbmV3aWR0aCBn cmVzdG9yZQpnc2F2ZSAxIHNldGxpbmV3aWR0aAogMC4wMCAwLjAwIDAuMDAg c2V0cmdiY29sb3IgIDEgc2V0bGluZXdpZHRoCjI5NCA1MDggMjk0IDM5MyBk cmF3X2xpbmUKMSBzZXRsaW5ld2lkdGggZ3Jlc3RvcmUKZ3NhdmUgMSBzZXRs aW5ld2lkdGgKIDAuMDAgMC4wMCAwLjAwIHNldHJnYmNvbG9yICAxIHNldGxp bmV3aWR0aAoyOTQgNjIzIDI5NCA1MDggZHJhd19saW5lCjEgc2V0bGluZXdp ZHRoIGdyZXN0b3JlCmdzYXZlIDEgc2V0bGluZXdpZHRoCiAwLjAwIDAuMDAg MC4wMCBzZXRyZ2Jjb2xvciAgMSBzZXRsaW5ld2lkdGgKMjk0IDczOCAyOTQg NjIzIGRyYXdfbGluZQoxIHNldGxpbmV3aWR0aCBncmVzdG9yZQpnc2F2ZSAx IHNldGxpbmV3aWR0aAogMC4wMCAwLjAwIDAuMDAgc2V0cmdiY29sb3IgIDEg c2V0bGluZXdpZHRoCjI5NCA4NTMgMjk0IDczOCBkcmF3X2xpbmUKMSBzZXRs aW5ld2lkdGggZ3Jlc3RvcmUKZ3NhdmUgMSBzZXRsaW5ld2lkdGgKIDAuMDAg MC4wMCAwLjAwIHNldHJnYmNvbG9yICAxIHNldGxpbmV3aWR0aAoyOTQgOTY4 IDI5NCA4NTMgZHJhd19saW5lCjEgc2V0bGluZXdpZHRoIGdyZXN0b3JlCmdz YXZlIDEgc2V0bGluZXdpZHRoCiAwLjAwIDAuMDAgMC4wMCBzZXRyZ2Jjb2xv ciAgMSBzZXRsaW5ld2lkdGgKMjU5IDEwNTUgMjk0IDk2OCBkcmF3X2xpbmUK MSBzZXRsaW5ld2lkdGggZ3Jlc3RvcmUKZ3NhdmUgMSBzZXRsaW5ld2lkdGgK IDAuMDAgMC4wMCAwLjAwIHNldHJnYmNvbG9yICAxODEgOTk1IDE4NSAxMDA5 IDE5MyAxMDAyIGZpbGxfYXJyb3cgMSBzZXRsaW5ld2lkdGgKMjI4IDEwNTUg MTg5IDEwMDYgZHJhd19saW5lCjEgc2V0bGluZXdpZHRoIGdyZXN0b3JlCgpm b250X2x1Y2lkYV9ib2xkCiAxLjAwIDEuMDAgMS4wMCBzZXRyZ2Jjb2xvciAg MjE5IDExMTAgNjAgNTUgZmlsbF9yZWN0YW5nbGUKYmxhY2sgMjE5IDExMTAg NjAgNTUgZHJhd19yZWN0YW5nbGUKKDI6ICkgMjI0IDEwOTQgZHJhd19zdHJp bmcKKGluICA9IDEhKSAyMjQgMTA3OCBkcmF3X3N0cmluZwoob3V0ID0gMSEp IDIyNCAxMDYyIGRyYXdfc3RyaW5nCmdzYXZlIDEgc2V0bGluZXdpZHRoCiAw LjAwIDAuMDAgMC4wMCBzZXRyZ2Jjb2xvciAgMTYxIDg4MCAxNTYgODk0IDE2 NiA4OTQgZmlsbF9hcnJvdyAxIHNldGxpbmV3aWR0aAoxNjEgOTQwIDE2MSA4 OTQgZHJhd19saW5lCjEgc2V0bGluZXdpZHRoIGdyZXN0b3JlCgpmb250X2x1 Y2lkYV9ib2xkCiAxLjAwIDEuMDAgMS4wMCBzZXRyZ2Jjb2xvciAgMTMxIDk5 NSA2MCA1NSBmaWxsX3JlY3RhbmdsZQpibGFjayAxMzEgOTk1IDYwIDU1IGRy YXdfcmVjdGFuZ2xlCigzOiApIDEzNiA5NzkgZHJhd19zdHJpbmcKKGluICA9 IDEhKSAxMzYgOTYzIGRyYXdfc3RyaW5nCihvdXQgPSAxISkgMTM2IDk0NyBk cmF3X3N0cmluZwpnc2F2ZSAxIHNldGxpbmV3aWR0aAogMC4wMCAwLjAwIDAu MDAgc2V0cmdiY29sb3IgIDEgc2V0bGluZXdpZHRoCjI3MiAzOTMgMjIzIDMw NSBkcmF3X2xpbmUKMSBzZXRsaW5ld2lkdGggZ3Jlc3RvcmUKZ3NhdmUgMSBz ZXRsaW5ld2lkdGgKIDAuMDAgMC4wMCAwLjAwIHNldHJnYmNvbG9yICAxIHNl dGxpbmV3aWR0aAoyNzIgNTA4IDI3MiAzOTMgZHJhd19saW5lCjEgc2V0bGlu ZXdpZHRoIGdyZXN0b3JlCmdzYXZlIDEgc2V0bGluZXdpZHRoCiAwLjAwIDAu MDAgMC4wMCBzZXRyZ2Jjb2xvciAgMSBzZXRsaW5ld2lkdGgKMjcyIDYyMyAy NzIgNTA4IGRyYXdfbGluZQoxIHNldGxpbmV3aWR0aCBncmVzdG9yZQpnc2F2 ZSAxIHNldGxpbmV3aWR0aAogMC4wMCAwLjAwIDAuMDAgc2V0cmdiY29sb3Ig IDEgc2V0bGluZXdpZHRoCjI3MiA3MzggMjcyIDYyMyBkcmF3X2xpbmUKMSBz ZXRsaW5ld2lkdGggZ3Jlc3RvcmUKZ3NhdmUgMSBzZXRsaW5ld2lkdGgKIDAu MDAgMC4wMCAwLjAwIHNldHJnYmNvbG9yICAxODggODI1IDIwMSA4MTkgMTk0 IDgxMiBmaWxsX2Fycm93IDEgc2V0bGluZXdpZHRoCjE5NyA4MTUgMjcyIDcz OCBkcmF3X2xpbmUKMSBzZXRsaW5ld2lkdGggZ3Jlc3RvcmUKZ3NhdmUgMSBz ZXRsaW5ld2lkdGgKIDAuMDAgMC4wMCAwLjAwIHNldHJnYmNvbG9yICAxNjEg NzY1IDE1NiA3NzkgMTY2IDc3OSBmaWxsX2Fycm93IDEgc2V0bGluZXdpZHRo CjE2MSA4MjUgMTYxIDc3OSBkcmF3X2xpbmUKMSBzZXRsaW5ld2lkdGggZ3Jl c3RvcmUKZ3NhdmUgMSBzZXRsaW5ld2lkdGgKIDAuMDAgMC4wMCAwLjAwIHNl dHJnYmNvbG9yICA3NiA3NjUgODIgNzc4IDg5IDc3MSBmaWxsX2Fycm93IDEg c2V0bGluZXdpZHRoCjEzNCA4MjUgODUgNzc1IGRyYXdfbGluZQoxIHNldGxp bmV3aWR0aCBncmVzdG9yZQoKZm9udF9sdWNpZGFfYm9sZAogMS4wMCAxLjAw IDEuMDAgc2V0cmdiY29sb3IgIDEyNyA4ODAgNjggNTUgZmlsbF9yZWN0YW5n bGUKYmxhY2sgMTI3IDg4MCA2OCA1NSBkcmF3X3JlY3RhbmdsZQooNDogKSAx MzIgODY0IGRyYXdfc3RyaW5nCihpbiAgPSAxMCEpIDEzMiA4NDggZHJhd19z dHJpbmcKKG91dCA9IDEwISkgMTMyIDgzMiBkcmF3X3N0cmluZwpnc2F2ZSAx IHNldGxpbmV3aWR0aAogMC4wMCAwLjAwIDAuMDAgc2V0cmdiY29sb3IgIDc0 IDUzNSA2NiA1NDcgNzUgNTQ5IGZpbGxfYXJyb3cgMSBzZXRsaW5ld2lkdGgK NTAgNjIzIDcxIDU0OCBkcmF3X2xpbmUKMSBzZXRsaW5ld2lkdGggZ3Jlc3Rv cmUKZ3NhdmUgMSBzZXRsaW5ld2lkdGgKIDAuMDAgMC4wMCAwLjAwIHNldHJn YmNvbG9yICAxIHNldGxpbmV3aWR0aAo1MCA3MTAgNTAgNjIzIGRyYXdfbGlu ZQoxIHNldGxpbmV3aWR0aCBncmVzdG9yZQoKZm9udF9sdWNpZGFfYm9sZApi bGFjayAyNSA3NjAgNjAgNTUgZmlsbF9yZWN0YW5nbGUKIDEuMDAgMS4wMCAx LjAwIHNldHJnYmNvbG9yICAyMCA3NjUgNjAgNTUgZmlsbF9yZWN0YW5nbGUK YmxhY2sgMjAgNzY1IDYwIDU1IGRyYXdfcmVjdGFuZ2xlCig1OiApIDI1IDc0 OSBkcmF3X3N0cmluZwooaW4gID0gOCEpIDI1IDczMyBkcmF3X3N0cmluZwoo b3V0ID0gOCEpIDI1IDcxNyBkcmF3X3N0cmluZwpnc2F2ZSAxIHNldGxpbmV3 aWR0aAogMC4wMCAwLjAwIDAuMDAgc2V0cmdiY29sb3IgIDIwMCA2NTAgMTkw IDY2MCAxOTkgNjY0IGZpbGxfYXJyb3cgMSBzZXRsaW5ld2lkdGgKMTczIDcx MCAxOTUgNjYyIGRyYXdfbGluZQoxIHNldGxpbmV3aWR0aCBncmVzdG9yZQpn c2F2ZSAxIHNldGxpbmV3aWR0aAogMC4wMCAwLjAwIDAuMDAgc2V0cmdiY29s b3IgIDEyMiA2NTAgMTIzIDY2NCAxMzIgNjYwIGZpbGxfYXJyb3cgMSBzZXRs aW5ld2lkdGgKMTQ5IDcxMCAxMjcgNjYyIGRyYXdfbGluZQoxIHNldGxpbmV3 aWR0aCBncmVzdG9yZQoKZm9udF9sdWNpZGFfYm9sZAogMS4wMCAxLjAwIDEu MDAgc2V0cmdiY29sb3IgIDEzMSA3NjUgNjAgNTUgZmlsbF9yZWN0YW5nbGUK YmxhY2sgMTMxIDc2NSA2MCA1NSBkcmF3X3JlY3RhbmdsZQooNjogKSAxMzYg NzQ5IGRyYXdfc3RyaW5nCihpbiAgPSAyISkgMTM2IDczMyBkcmF3X3N0cmlu Zwoob3V0ID0gMiEpIDEzNiA3MTcgZHJhd19zdHJpbmcKZ3NhdmUgMSBzZXRs aW5ld2lkdGgKIDAuMDAgMC4wMCAwLjAwIHNldHJnYmNvbG9yICA4OCA1MzUg ODcgNTQ5IDk2IDU0NyBmaWxsX2Fycm93IDEgc2V0bGluZXdpZHRoCjEwNCA1 OTUgOTEgNTQ4IGRyYXdfbGluZQoxIHNldGxpbmV3aWR0aCBncmVzdG9yZQoK Zm9udF9sdWNpZGFfYm9sZAogMS4wMCAxLjAwIDEuMDAgc2V0cmdiY29sb3Ig IDgxIDY1MCA2MCA1NSBmaWxsX3JlY3RhbmdsZQpibGFjayA4MSA2NTAgNjAg NTUgZHJhd19yZWN0YW5nbGUKKDc6ICkgODYgNjM0IGRyYXdfc3RyaW5nCihp biAgPSAxISkgODYgNjE4IGRyYXdfc3RyaW5nCihvdXQgPSAxISkgODYgNjAy IGRyYXdfc3RyaW5nCmdzYXZlIDEgc2V0bGluZXdpZHRoCiAwLjAwIDAuMDAg MC4wMCBzZXRyZ2Jjb2xvciAgMTYxIDQyMCAxNjMgNDM0IDE3MiA0MjkgZmls bF9hcnJvdyAxIHNldGxpbmV3aWR0aAoyMTEgNTA4IDE2NyA0MzIgZHJhd19s aW5lCjEgc2V0bGluZXdpZHRoIGdyZXN0b3JlCmdzYXZlIDEgc2V0bGluZXdp ZHRoCiAwLjAwIDAuMDAgMC4wMCBzZXRyZ2Jjb2xvciAgMSBzZXRsaW5ld2lk dGgKMjExIDU5NSAyMTEgNTA4IGRyYXdfbGluZQoxIHNldGxpbmV3aWR0aCBn cmVzdG9yZQoKZm9udF9sdWNpZGFfYm9sZAogMS4wMCAxLjAwIDEuMDAgc2V0 cmdiY29sb3IgIDE4MSA2NTAgNjAgNTUgZmlsbF9yZWN0YW5nbGUKYmxhY2sg MTgxIDY1MCA2MCA1NSBkcmF3X3JlY3RhbmdsZQooODogKSAxODYgNjM0IGRy YXdfc3RyaW5nCihpbiAgPSAxISkgMTg2IDYxOCBkcmF3X3N0cmluZwoob3V0 ID0gMSEpIDE4NiA2MDIgZHJhd19zdHJpbmcKZ3NhdmUgMSBzZXRsaW5ld2lk dGgKIDAuMDAgMC4wMCAwLjAwIHNldHJnYmNvbG9yICA1OTAgMTExMCA1ODAg MTEyMCA1ODkgMTEyNCBmaWxsX2Fycm93IDEgc2V0bGluZXdpZHRoCjU2MyAx MTcwIDU4NSAxMTIyIGRyYXdfbGluZQoxIHNldGxpbmV3aWR0aCBncmVzdG9y ZQoKZm9udF9sdWNpZGFfYm9sZAogMS4wMCAxLjAwIDEuMDAgc2V0cmdiY29s b3IgIDUyMSAxMjI1IDYwIDU1IGZpbGxfcmVjdGFuZ2xlCmJsYWNrIDUyMSAx MjI1IDYwIDU1IGRyYXdfcmVjdGFuZ2xlCig5OiApIDUyNiAxMjA5IGRyYXdf c3RyaW5nCihpbiAgPSAwISkgNTI2IDExOTMgZHJhd19zdHJpbmcKKG91dCA9 IDAhKSA1MjYgMTE3NyBkcmF3X3N0cmluZwpnc2F2ZSAxIHNldGxpbmV3aWR0 aAogMC4wMCAwLjAwIDAuMDAgc2V0cmdiY29sb3IgIDYxMiAxMTEwIDYxMyAx MTI0IDYyMiAxMTIwIGZpbGxfYXJyb3cgMSBzZXRsaW5ld2lkdGgKNjM5IDEx NzAgNjE3IDExMjIgZHJhd19saW5lCjEgc2V0bGluZXdpZHRoIGdyZXN0b3Jl Cgpmb250X2x1Y2lkYV9ib2xkCiAxLjAwIDEuMDAgMS4wMCBzZXRyZ2Jjb2xv ciAgNjIxIDEyMjUgNjAgNTUgZmlsbF9yZWN0YW5nbGUKYmxhY2sgNjIxIDEy MjUgNjAgNTUgZHJhd19yZWN0YW5nbGUKKDEwOiApIDYyNiAxMjA5IGRyYXdf c3RyaW5nCihpbiAgPSAwISkgNjI2IDExOTMgZHJhd19zdHJpbmcKKG91dCA9 IDAhKSA2MjYgMTE3NyBkcmF3X3N0cmluZwpnc2F2ZSAxIHNldGxpbmV3aWR0 aAogMC4wMCAwLjAwIDAuMDAgc2V0cmdiY29sb3IgIDEzMSA0MjAgMTIwIDQy OSAxMjkgNDM0IGZpbGxfYXJyb3cgMSBzZXRsaW5ld2lkdGgKOTYgNDgwIDEy NCA0MzIgZHJhd19saW5lCjEgc2V0bGluZXdpZHRoIGdyZXN0b3JlCgpmb250 X2x1Y2lkYV9ib2xkCiAxLjAwIDEuMDAgMS4wMCBzZXRyZ2Jjb2xvciAgNTEg NTM1IDYwIDU1IGZpbGxfcmVjdGFuZ2xlCmJsYWNrIDUxIDUzNSA2MCA1NSBk cmF3X3JlY3RhbmdsZQooMTE6ICkgNTYgNTE5IGRyYXdfc3RyaW5nCihpbiAg PSA5ISkgNTYgNTAzIGRyYXdfc3RyaW5nCihvdXQgPSA5ISkgNTYgNDg3IGRy YXdfc3RyaW5nCmdzYXZlIDEgc2V0bGluZXdpZHRoCiAwLjAwIDAuMDAgMC4w MCBzZXRyZ2Jjb2xvciAgMTk1IDMwNSAxODQgMzE0IDE5MyAzMTkgZmlsbF9h cnJvdyAxIHNldGxpbmV3aWR0aAoxNjEgMzY1IDE4OSAzMTcgZHJhd19saW5l CjEgc2V0bGluZXdpZHRoIGdyZXN0b3JlCgpmb250X2x1Y2lkYV9ib2xkCiAx LjAwIDEuMDAgMS4wMCBzZXRyZ2Jjb2xvciAgMTEyIDQyMCA2OCA1NSBmaWxs X3JlY3RhbmdsZQpibGFjayAxMTIgNDIwIDY4IDU1IGRyYXdfcmVjdGFuZ2xl CigxMjogKSAxMTcgNDA0IGRyYXdfc3RyaW5nCihpbiAgPSAxMCEpIDExNyAz ODggZHJhd19zdHJpbmcKKG91dCA9IDEwISkgMTE3IDM3MiBkcmF3X3N0cmlu Zwpnc2F2ZSAxIHNldGxpbmV3aWR0aAogMC4wMCAwLjAwIDAuMDAgc2V0cmdi Y29sb3IgIDIwOSAxOTAgMjA0IDIwNCAyMTQgMjA0IGZpbGxfYXJyb3cgMSBz ZXRsaW5ld2lkdGgKMjA5IDI1MCAyMDkgMjA0IGRyYXdfbGluZQoxIHNldGxp bmV3aWR0aCBncmVzdG9yZQoKZm9udF9sdWNpZGFfYm9sZAogMS4wMCAxLjAw IDEuMDAgc2V0cmdiY29sb3IgIDE3NSAzMDUgNjggNTUgZmlsbF9yZWN0YW5n bGUKYmxhY2sgMTc1IDMwNSA2OCA1NSBkcmF3X3JlY3RhbmdsZQooMTM6ICkg MTgwIDI4OSBkcmF3X3N0cmluZwooaW4gID0gMTAhKSAxODAgMjczIGRyYXdf c3RyaW5nCihvdXQgPSAxMCEpIDE4MCAyNTcgZHJhd19zdHJpbmcKZ3NhdmUg MSBzZXRsaW5ld2lkdGgKIDAuMDAgMC4wMCAwLjAwIHNldHJnYmNvbG9yICAy NDIgNzUgMjMzIDg2IDI0MiA4OSBmaWxsX2Fycm93IDEgc2V0bGluZXdpZHRo CjIxOSAxMzUgMjM3IDg4IGRyYXdfbGluZQoxIHNldGxpbmV3aWR0aCBncmVz dG9yZQoKZm9udF9sdWNpZGFfYm9sZAogMS4wMCAxLjAwIDEuMDAgc2V0cmdi Y29sb3IgIDE3OSAxOTAgNjAgNTUgZmlsbF9yZWN0YW5nbGUKYmxhY2sgMTc5 IDE5MCA2MCA1NSBkcmF3X3JlY3RhbmdsZQooMTQ6ICkgMTg0IDE3NCBkcmF3 X3N0cmluZwooaW4gID0gMSEpIDE4NCAxNTggZHJhd19zdHJpbmcKKG91dCA9 IDEhKSAxODQgMTQyIGRyYXdfc3RyaW5nCgpmb250X2x1Y2lkYV9ib2xkCiAw LjU2IDAuOTMgMC41NiBzZXRyZ2Jjb2xvciAgMjIyIDc1IDYwIDU1IGZpbGxf cmVjdGFuZ2xlCmJsYWNrIDIyMiA3NSA2MCA1NSBkcmF3X3JlY3RhbmdsZQoo MTU6ICkgMjI3IDU5IGRyYXdfc3RyaW5nCihpbiAgPSAxISkgMjI3IDQzIGRy YXdfc3RyaW5nCihvdXQgPSAwISkgMjI3IDI3IGRyYXdfc3RyaW5nCgpmb250 X2x1Y2lkYV9ib2xkCiAxLjAwIDEuMDAgMS4wMCBzZXRyZ2Jjb2xvciAgNzIx IDEyMjUgNjAgNTUgZmlsbF9yZWN0YW5nbGUKYmxhY2sgNzIxIDEyMjUgNjAg NTUgZHJhd19yZWN0YW5nbGUKKDE2OiApIDcyNiAxMjA5IGRyYXdfc3RyaW5n CihpbiAgPSAwISkgNzI2IDExOTMgZHJhd19zdHJpbmcKKG91dCA9IDAhKSA3 MjYgMTE3NyBkcmF3X3N0cmluZwoKZm9udF9sdWNpZGFfYm9sZAogMS4wMCAx LjAwIDEuMDAgc2V0cmdiY29sb3IgIDU3MSAxMTEwIDYwIDU1IGZpbGxfcmVj dGFuZ2xlCmJsYWNrIDU3MSAxMTEwIDYwIDU1IGRyYXdfcmVjdGFuZ2xlCigx NzogKSA1NzYgMTA5NCBkcmF3X3N0cmluZwooaW4gID0gMCEpIDU3NiAxMDc4 IGRyYXdfc3RyaW5nCihvdXQgPSAwISkgNTc2IDEwNjIgZHJhd19zdHJpbmcK CmVuZApzaG93cGFnZQolJVRyYWlsZXIKJSVFT0YK ---2138965737-424574681-998868150=:26972 Content-Type: TEXT/PLAIN; charset=US-ASCII; name="test.c" Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: Content-Disposition: attachment; filename="test.c" I2luY2x1ZGUgICA8c3RkaW8uaD4NCiNkZWZpbmUgICAgTUFYX0xFTkdUSCAx MDAwMA0KDQoNCm1haW4oaW50IGFyZ2MsIGNoYXIqIGFyZ3ZbXSkNCnsNCiAg aW50ICBsZW5ndGg9IDEwOw0KICBpbnQgIGksaixrOw0KDQogIGsgPSBqPTE7 DQoNCiAgZm9yKGk9MCA7IGk8bGVuZ3RoIDsgaSsrKQ0KICAgIHsNCgkJaWYo IChpIDwgKGxlbmd0aCAtMikpKQ0KCQl7DQoJCQlwcmludGYoIiglZCkiLGkp OwkNCgkJCWdvdG8gTDE7DQoJCX0NCgkJZWxzZQ0KCQl7DQoJCQlpZiAoaSA9 PSAobGVuZ3RoIC0yKSkNCgkJCXsNCgkJCQlnb3RvIEwxOwkJCQ0KCQkJfWVs c2UNCgkJCXsNCgkJCQlwcmludGYoIiBpID09IChsZW5ndGggLTEpICVkXG4i LCBpKTsJDQoJCQkJZ290byBMMjsNCgkJCX0NCgkJfQ0KDQoJCUwxOiBwcmlu dGYoIiAxMTExMTExMTExMTFcbiIpOw0KCQlMMjogcHJpbnRmKCIgMjIyMjIy MjIyMjIyXG4iKTsNCiAgICB9DQp9DQoNCg== ---2138965737-424574681-998868150=:26972-- From owner-pro64-support@oss.sgi.com Sun Aug 26 20:50:46 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7R3okX12974 for pro64-support-outgoing; Sun, 26 Aug 2001 20:50:46 -0700 Received: from deliverator.sgi.com (deliverator.sgi.com [204.94.214.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7R3ogd12971 for ; Sun, 26 Aug 2001 20:50:42 -0700 Received: from dsl-proof.corp.sgi.com (dsl-proof.corp.sgi.com [192.102.142.250]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id UAA05609 for ; Sun, 26 Aug 2001 20:50:24 -0700 (PDT) mail_from (dlstephe@sgi.com) Received: from sgi.com (localhost [127.0.0.1]) by dsl-proof.corp.sgi.com (SGI-8.9.3/8.9.3) with ESMTP id UAA02801; Sun, 26 Aug 2001 20:51:34 -0700 (PDT) Message-ID: <3B89C3C5.14173E84@sgi.com> Date: Sun, 26 Aug 2001 20:51:33 -0700 From: David Stephenson Organization: SGI -- Compilers X-Mailer: Mozilla 4.76C-SGI [en] (X11; I; IRIX 6.5 IP32) X-Accept-Language: en MIME-Version: 1.0 To: Peng Zhao CC: sgi Subject: Re: multi-entry CFG References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-pro64-support@oss.sgi.com Precedence: bulk Peng Zhao wrote: > Enclosed two files are a simple C program and the related CFG > created in the pre_optimizer. There are several entries for the CFG. And > I want to use cfg->Entry_bb()->Id() & cfg->Exit_bb()->Id() to get the > entry&exit of the CFG(Initially, I had thought there should be only one > entry and one exit). The result is: > > entry=16,exit=17 > > Can somebody explain me when this kind of CFG is generated? In the WOPT CFG, blocks 9 and 10 are leftovers. Consider the inner branch statement: if (i == (length -2)) { goto L1; } else { printf(" i == (length -1) %d\n", i); goto L2; } If there were no goto statements, then WOPT would have generated a CFG like: | 6 / \ 7 8 \ / 9 | Instead, the gotos cause blocks 7 and 8 to branch to blocks 11 and 12 which contain the labels L1 and L2, respectively. Block 9 is still generated, but is left dangling with no predecessors. DCE will later eliminate it. Now, in order to keep all of the dominance relations well defined, a new "fake entry" block 16 is introduced. This happens whenever the CFG contains more than one block with no predecessors. The successors of the "fake entry" block are all blocks with no predecessors: 1, 9, and 10. Similarly a "fake exit" block is introduced with predecessors 15, 9, and 10. (One subtlety: although 1 is a successor of 16, 16 is not a predecessor of 1. Fake entries and exits use "one-sided" edges to connect.) The postscript graph you are looking at is from optimizer feedback, and it looks a little different from the CFG graph. In particular, the "one-sided edges" from 16 to 1,9,10 and from 15,9,10 are not all shown. - David -- David Stephenson http://reality.sgi.com/dlstephe_engr/ From owner-pro64-support@oss.sgi.com Sun Aug 26 22:03:32 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7R53WE13836 for pro64-support-outgoing; Sun, 26 Aug 2001 22:03:32 -0700 Received: from sunkay.cs.ualberta.ca (root@sunkay.cs.ualberta.ca [129.128.4.11]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7R53Gd13833 for ; Sun, 26 Aug 2001 22:03:28 -0700 Received: (from localhost user: 'pengzhao' uid#483 fake: STDIN (pengzhao@peers)) by sunkay.cs.ualberta.ca id ; Sun, 26 Aug 2001 23:02:46 -0600 Date: Sun, 26 Aug 2001 23:02:45 -0600 (MDT) From: Peng Zhao To: David Stephenson cc: sgi Subject: Re: multi-entry CFG In-Reply-To: <3B89C3C5.14173E84@sgi.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-pro64-support@oss.sgi.com Precedence: bulk On Sun, 26 Aug 2001, David Stephenson wrote: > Peng Zhao wrote: > > > Enclosed two files are a simple C program and the related CFG > > created in the pre_optimizer. There are several entries for the CFG. And > > I want to use cfg->Entry_bb()->Id() & cfg->Exit_bb()->Id() to get the > > entry&exit of the CFG(Initially, I had thought there should be only one > > entry and one exit). The result is: > > > > entry=16,exit=17 > > > > Can somebody explain me when this kind of CFG is generated? 1. Is there any flag that mark the essential difference of the "real" entry and the "fake" & "dangling" entry? I noticed the real entry and exit are represented by green blocks. It seems that it is green because it is not in_out_same. 2. Is there any special reason to left the "dangling" entry there? 3. Another question is about the SWITCH casegotos. In the whirl tree for Programs containing switch structure, why not make the BLOCKs for each "case" the children of the CASES? In pro64, casegotos are used and the BLOCKS for the cases are NOT in the subtree rooted from the SWITCH wn. 4. I know that Pro64 introduces the concept of region to divide a very big function into different parts to deal with them separately. What is the guide to split the function into regions? Does Pro64 generates regions into which there are several entry from the original function (e.g. GOTOs)? > > In the WOPT CFG, blocks 9 and 10 are leftovers. Consider the inner > branch statement: > > if (i == (length -2)) { > goto L1; > } else { > printf(" i == (length -1) %d\n", i); > goto L2; > } > > If there were no goto statements, then WOPT would have generated a > CFG like: > | > 6 > / \ > 7 8 > \ / > 9 > | > > Instead, the gotos cause blocks 7 and 8 to branch to blocks 11 and 12 > which contain the labels L1 and L2, respectively. Block 9 is still > generated, but is left dangling with no predecessors. DCE will later > eliminate it. > > Now, in order to keep all of the dominance relations well defined, > a new "fake entry" block 16 is introduced. This happens whenever > the CFG contains more than one block with no predecessors. The > successors of the "fake entry" block are all blocks with no > predecessors: 1, 9, and 10. Similarly a "fake exit" block is > introduced with predecessors 15, 9, and 10. (One subtlety: > although 1 is a successor of 16, 16 is not a predecessor of 1. > Fake entries and exits use "one-sided" edges to connect.) > > The postscript graph you are looking at is from optimizer feedback, > and it looks a little different from the CFG graph. In particular, > the "one-sided edges" from 16 to 1,9,10 and from 15,9,10 are not > all shown. > > - David > > -- Regards Peng -- Peng Zhao pengzhao@cs.ualberta.ca http://www.cs.ualberta.ca/~pengzhao TEL (Lab): (780)492-3725 Lab: CSC251 From owner-pro64-support@oss.sgi.com Mon Aug 27 11:17:31 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7RIHVN31269 for pro64-support-outgoing; Mon, 27 Aug 2001 11:17:31 -0700 Received: from zok.sgi.com (zok.sgi.com [204.94.215.101]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7RIHSd31266 for ; Mon, 27 Aug 2001 11:17:28 -0700 Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by zok.sgi.com (8.11.4/8.11.4/linux-outbound_gateway-1.0) with ESMTP id f7RINwa11088 for ; Mon, 27 Aug 2001 11:23:58 -0700 Received: from sgi.com (gaea.engr.sgi.com [130.62.180.97]) by cthulhu.engr.sgi.com (SGI-8.9.3/8.9.3) with ESMTP id LAA92765; Mon, 27 Aug 2001 11:16:06 -0700 (PDT) Message-ID: <3B8A8E66.EC883312@sgi.com> Date: Mon, 27 Aug 2001 11:16:06 -0700 From: Chandrasekhar Murthy X-Mailer: Mozilla 4.51C-SGI [en] (X11; I; IRIX 6.5 IP32) X-Accept-Language: en MIME-Version: 1.0 To: Peng Zhao CC: sgi Subject: Re: multi-entry CFG References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-pro64-support@oss.sgi.com Precedence: bulk > > 3. Another question is about the SWITCH casegotos. In the whirl tree for > Programs containing switch structure, why not make the BLOCKs for each > "case" the children of the CASES? In pro64, casegotos are used and the > BLOCKS for the cases are NOT in the subtree rooted from the SWITCH wn. > > In WHIRL a node can appear only once in the tree. Consider the following example switch (c) { ... case 'a': case 'b': case 'c': case 'd': { // block of code ... } // fall thru case '1': case '2': { // block of code ... break; } ... } ... You would need to duplicate the blocks for both of the cases above. Murthy From owner-pro64-support@oss.sgi.com Mon Aug 27 12:47:10 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7RJlAd01074 for pro64-support-outgoing; Mon, 27 Aug 2001 12:47:10 -0700 Received: from pneumatic-tube.sgi.com (pneumatic-tube.sgi.com [204.94.214.22]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7RJl8d01071 for ; Mon, 27 Aug 2001 12:47:08 -0700 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 MAA06159 for ; Mon, 27 Aug 2001 12:45:23 -0700 (PDT) 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 MAA02226; Mon, 27 Aug 2001 12:46:43 -0700 (PDT) Date: Mon, 27 Aug 2001 12:46:43 -0700 (PDT) From: mpm@rohi.engr.sgi.com (Michael Murphy) Message-Id: <200108271946.MAA02226@rohi.engr.sgi.com> To: David Stephenson , Peng Zhao Subject: Re: multi-entry CFG Cc: sgi Sender: owner-pro64-support@oss.sgi.com Precedence: bulk From: Peng Zhao 4. I know that Pro64 introduces the concept of region to divide a very big function into different parts to deal with them separately. What is the guide to split the function into regions? Does Pro64 generates regions into which there are several entry from the original function (e.g. GOTOs)? Regions were never finished. They worked in some cases, but not all, and we ran out of time/resources, so they were dropped. You will see some special versions of regions for exception handling and mp support, but the general regions are not used. If you wanted to play with it, see the be/region/ori.cxx code which is what split functions into regions. A region is defined as single-entry, multiple-exit, so you can't have multiple-entry regions. -- Mike Murphy -- mpm@sgi.com -- quote of the day: -- "Love one another and you will be happy. -- It is as simple and as difficult as that." (Michael Leunig) From owner-pro64-support@oss.sgi.com Mon Aug 27 13:04:44 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7RK4iK01826 for pro64-support-outgoing; Mon, 27 Aug 2001 13:04:44 -0700 Received: from rj.sgi.com (rj.SGI.COM [204.94.215.100]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7RK4fd01823 for ; Mon, 27 Aug 2001 13:04:41 -0700 Received: from dsl-proof.corp.sgi.com (dsl-proof.corp.sgi.com [192.102.142.250]) by rj.sgi.com (8.11.4/8.11.4/linux-outbound_gateway-1.0) with ESMTP id f7RKA8810993 for ; Mon, 27 Aug 2001 13:10:08 -0700 Received: from sgi.com (localhost [127.0.0.1]) by dsl-proof.corp.sgi.com (SGI-8.9.3/8.9.3) with ESMTP id NAA91116; Mon, 27 Aug 2001 13:05:39 -0700 (PDT) Message-ID: <3B8AA813.2E853EDB@sgi.com> Date: Mon, 27 Aug 2001 13:05:39 -0700 From: David Stephenson Organization: SGI -- Compilers X-Mailer: Mozilla 4.76C-SGI [en] (X11; I; IRIX 6.5 IP32) X-Accept-Language: en MIME-Version: 1.0 To: Peng Zhao CC: sgi Subject: Re: multi-entry CFG References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-pro64-support@oss.sgi.com Precedence: bulk Peng Zhao wrote: > 1. Is there any flag that mark the essential difference of the > "real" entry and the "fake" & "dangling" entry? I noticed the real entry > and exit are represented by green blocks. It seems that it is green > because it is not in_out_same. Fake entries and exits can be detected via code such as: if (bb == cfg->Fake_entry_bb() || bb == cfg->Fake_exit_bb()) To check whether a particular block is a "real" entry, use: if (bb->Kind() == BB_ENTRY && bb != Cfg()->Fake_entry_bb()) Dangling blocks will have bb->Kind() != BB_ENTRY. Here is some code from opt_alias_analysis.cxx that searches for all true entry blocks: if (Cfg()->Fake_entry_bb() != NULL) { BB_NODE *bb; BB_LIST_ITER bb_iter; FOR_ALL_ELEM (bb, bb_iter, Init(Cfg()->Fake_entry_bb()->Succ())) { if (bb->Kind() == BB_ENTRY) { ... } } } else { BB_NODE *bb = Cfg()->Entry_bb(); ... } Also, take a look at the code in opt_cfg.cxx for the method CFG::Process_multi_entryexit for the construction of the fake entry and exit blocks. > 2. Is there any special reason to left the "dangling" entry there? They are generated by default, then eliminated by DCE. This is typical for WOPT; one phase uses another phase to perform some of its work. - David -- David Stephenson http://reality.sgi.com/dlstephe_engr/ From owner-pro64-support@oss.sgi.com Tue Aug 28 09:24:50 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7SGOoq28556 for pro64-support-outgoing; Tue, 28 Aug 2001 09:24:50 -0700 Received: from web3505.mail.yahoo.com (web3505.mail.yahoo.com [216.115.111.72]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7SGOnd28553 for ; Tue, 28 Aug 2001 09:24:49 -0700 Message-ID: <20010828162448.8586.qmail@web3505.mail.yahoo.com> Received: from [156.153.254.41] by web3505.mail.yahoo.com via HTTP; Tue, 28 Aug 2001 09:24:48 PDT Date: Tue, 28 Aug 2001 09:24:48 -0700 (PDT) From: Shin-Ming Liu Subject: Re: multi-entry CFG To: Peng Zhao , David Stephenson Cc: sgi In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-pro64-support@oss.sgi.com Precedence: bulk --- Peng Zhao wrote: > > 2. Is there any special reason to left the > "dangling" entry there? The existence of dangling block is the consequence of funny code as David has pointed out. Either you avoid generating it or clean up in a separate pass. We have chosen the latter by utilizing DCE. It appeared to be the most cost effective solution at that time. Does the dangling block give you extra headache? __________________________________________________ Do You Yahoo!? Make international calls for as low as $.04/minute with Yahoo! Messenger http://phonecard.yahoo.com/ From owner-pro64-support@oss.sgi.com Tue Aug 28 13:47:37 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7SKlbK02710 for pro64-support-outgoing; Tue, 28 Aug 2001 13:47:37 -0700 Received: from sunkay.cs.ualberta.ca (root@sunkay.cs.ualberta.ca [129.128.4.11]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7SKlYd02707 for ; Tue, 28 Aug 2001 13:47:34 -0700 Received: (from localhost user: 'pengzhao' uid#483 fake: STDIN (pengzhao@peers)) by sunkay.cs.ualberta.ca id ; Tue, 28 Aug 2001 14:47:14 -0600 Date: Tue, 28 Aug 2001 14:47:14 -0600 (MDT) From: Peng Zhao To: Shin-Ming Liu cc: David Stephenson , sgi Subject: Re: multi-entry CFG In-Reply-To: <20010828162448.8586.qmail@web3505.mail.yahoo.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-pro64-support@oss.sgi.com Precedence: bulk On Tue, 28 Aug 2001, Shin-Ming Liu wrote: > > > --- Peng Zhao wrote: > > > > > 2. Is there any special reason to left the > > "dangling" entry there? > > The existence of dangling block is the consequence > of funny code as David has pointed out. Either you > avoid generating it or clean up in a separate pass. > We have chosen the latter by utilizing DCE. It > appeared to be the most cost effective solution at > that time. Does the dangling block give you extra > headache? No. Thanks > > > > __________________________________________________ > Do You Yahoo!? > Make international calls for as low as $.04/minute with Yahoo! Messenger > http://phonecard.yahoo.com/ > -- Regards Peng -- Peng Zhao pengzhao@cs.ualberta.ca http://www.cs.ualberta.ca/~pengzhao TEL (Lab): (780)492-3725 Lab: CSC251 From owner-pro64-support@oss.sgi.com Fri Aug 31 04:40:32 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7VBeWH16783 for pro64-support-outgoing; Fri, 31 Aug 2001 04:40:32 -0700 Received: from beta.dmz-eu.st.com (beta.dmz-eu.st.com [164.129.1.35]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7VBeOd16772; Fri, 31 Aug 2001 04:40:24 -0700 Received: from zeta.dmz-eu.st.com (zeta.dmz-eu.st.com [164.129.230.9]) by beta.dmz-eu.st.com (STMicroelectronics) with SMTP id 5783A4938; Fri, 31 Aug 2001 10:24:35 +0000 (GMT) Received: by zeta.dmz-eu.st.com (STMicroelectronics, from userid 0) id 4B3DE48CE; Fri, 31 Aug 2001 10:24:50 +0000 (GMT) Received: from thistle.bri.st.com (localhost [127.0.0.1]) by zeta.dmz-eu.st.com (STMicroelectronics) with ESMTP id CAEDF1841; Fri, 31 Aug 2001 10:24:49 +0000 (GMT) Received: from harpo ([164.129.14.93] helo=st.com) by thistle.bristol.st.com with esmtp (Exim 3.03 #5) id 15clTV-0006NE-00; Fri, 31 Aug 2001 11:24:33 +0100 Message-ID: <3B8F6786.6F97E962@st.com> Date: Fri, 31 Aug 2001 11:31:34 +0100 From: "Benedict R. Gaster" Organization: STMicroelectronics X-Mailer: Mozilla 4.7 [en-gb] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Pro64 Support , Pro64 Contrib Subject: Job advert: Compiler designer/architect Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-pro64-support@oss.sgi.com Precedence: bulk SuperH, Inc is a new company formed by STMicroelectronics and Hitachi in order to market and develop the SuperH series of microprocessors as an independent company. The SuperH series will be offered as licensable cores for synthesis into embedded applications. See www.superh.com for more information. SuperH is headquartered in San Jose CA with R&D centers in Bristol UK and Tokyo Japan. SuperH will be developing software systems based on Open Source tecnology, including Gnu tools (i.e., gcc, gdb, etc.) and Pro64, and is looking for a range of engineers who have interests and/or experience in the following skill areas: o Code generation and optimization. Software pipelining, register allocation. Specific experience with gcc or Pro64 would be an advantage. o JIT compilation and dynamic optimization. o Linux development. o Architecture design. o Benchmarking. o Debugging technologies including gdb. SuperH will be developing products based on Gnu and Linux technogy as well as carrying out research into new innovative architectures and advanced compiler design, including the Pro64 and dynamic optimization. The main location for these posts is Bristol, UK. SuperH will be offering a comprehensive benefits package as well as an emloyee stock option scheme and bonus schemes. Job Title: Compiler designer/architect. Qualifications. Good knowledge of compiler optimizations, experience with Gnu or Pro64 would be useful. In depth knowledge of C & C++. Java an advantage. Experience in embedded system design. Please send CVs to: benedict.gaster@st.com Benedict R. Gaster SuperH, Inc.