From jkrell at elego.de Tue Jun 1 03:54:56 2010 From: jkrell at elego.de (Jay Krell) Date: Tue, 1 Jun 2010 3:54:56 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100601015457.B38F92474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/06/01 03:54:56 Modified files: cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c Log message: leave m3cg_pop fixed and optimize the common subexpression, print more typenames in tracing (I meant to get them all the first time) From jkrell at elego.de Tue Jun 1 03:58:38 2010 From: jkrell at elego.de (Jay Krell) Date: Tue, 1 Jun 2010 3:58:38 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100601015838.8A8CB2474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/06/01 03:58:38 Modified files: cm3/m3-sys/m3front/src/builtinOps/: IsType.m3 Narrow.m3 Typecode.m3 Log message: do the tag checking using unsigned integers to satisfy m3cc/configure -enable-checking=all and wants the three types to all be the same (two inputs, one output) but we make the output unconditionally unsigned, so the inputs should also be unsigned this seems reasonable, but kind of reasonable either way From jay.krell at cornell.edu Tue Jun 1 04:02:21 2010 From: jay.krell at cornell.edu (Jay K) Date: Tue, 1 Jun 2010 02:02:21 +0000 Subject: [M3commit] CVS Update: cm3 In-Reply-To: References: <20100531113150.B02672474003@birch.elegosoft.com>, Message-ID: I've left it fixed. I can confirm that "side effects(t)" vs. "side efffects(expr(-1))" are often different. I didn't look closely at the resulting code/behavior. I might assert though that the new behavior only ever keeps stuff where the old behavior kept or threw out. That the new behavior isn't throwing stuff out that we kept. ?- Jay ---------------------------------------- > From: jay.krell at cornell.edu > To: jkrell at elego.de; m3commit at elegosoft.com > Date: Mon, 31 May 2010 11:35:07 +0000 > Subject: Re: [M3commit] CVS Update: cm3 > > > I accidentally fixed the m3cg_pop bug here. > That is a bug that might be dangerous to fix. > I'm going to put it back for now, and have -y output which path is taken so we can better > understand the impact of fixing it. > > - Jay > > > ---------------------------------------- >> Date: Mon, 31 May 2010 13:31:50 +0000 >> To: m3commit at elegosoft.com >> From: jkrell at elego.de >> Subject: [M3commit] CVS Update: cm3 >> >> CVSROOT: /usr/cvs >> Changes by: jkrell at birch. 10/05/31 13:31:50 >> >> Modified files: >> cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c >> >> Log message: >> include typenames in trace all -y output, and some altering of trace output >> > From jkrell at elego.de Tue Jun 1 04:29:26 2010 From: jkrell at elego.de (Jay Krell) Date: Tue, 1 Jun 2010 4:29:26 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100601022927.4AE2C2474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/06/01 04:29:26 Modified files: cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c Log message: Check that we don't throw out stuff that we previously kept. From jkrell at elego.de Tue Jun 1 04:35:47 2010 From: jkrell at elego.de (Jay Krell) Date: Tue, 1 Jun 2010 4:35:47 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100601023611.6F5962474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/06/01 04:35:47 Modified files: cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c Log message: remove some newlines in m3_build_type From jkrell at elego.de Tue Jun 1 04:42:47 2010 From: jkrell at elego.de (Jay Krell) Date: Tue, 1 Jun 2010 4:42:47 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100601024247.74F1F2474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/06/01 04:42:47 Modified files: cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c Log message: remove line I didn't mean to commit From jkrell at elego.de Tue Jun 1 04:48:06 2010 From: jkrell at elego.de (Jay Krell) Date: Tue, 1 Jun 2010 4:48:06 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100601024806.9C2952474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/06/01 04:48:06 Modified files: cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c Log message: combine common code in m3_build_type From jkrell at elego.de Tue Jun 1 05:51:04 2010 From: jkrell at elego.de (Jay Krell) Date: Tue, 1 Jun 2010 5:51:04 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100601035105.087862474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/06/01 05:51:04 Modified files: cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c Log message: use the provided typedef for get_alias_set for 4.3 use the default get_alias_set for 4.5; this would probably be good for 4.3 also From jkrell at elego.de Tue Jun 1 14:08:16 2010 From: jkrell at elego.de (Jay Krell) Date: Tue, 1 Jun 2010 14:08:16 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100601120816.90BA32474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/06/01 14:08:16 Modified files: cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c Log message: It turns out extracting 0 bits is allowed. Test p137 does it. I had put in an assert to disallow it. For this case, alwas return 0, rather than risk "over shifting". This seems to be correct per: http://www.cs.purdue.edu/homes/hosking/m3/reference/word-intf.html We take n (0) bits from the input and set the rest of the bits (all of them) to 0. From jkrell at elego.de Tue Jun 1 14:14:07 2010 From: jkrell at elego.de (Jay Krell) Date: Tue, 1 Jun 2010 14:14:07 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100601121407.1D6D72474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/06/01 14:14:07 Modified files: cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c Log message: parentheses around uses of macro parameters From jkrell at elego.de Tue Jun 1 14:15:01 2010 From: jkrell at elego.de (Jay Krell) Date: Tue, 1 Jun 2010 14:15:01 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100601121501.AF0032474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/06/01 14:15:01 Modified files: cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c Log message: spaces between macro parameters From jkrell at elego.de Tue Jun 1 14:16:57 2010 From: jkrell at elego.de (Jay Krell) Date: Tue, 1 Jun 2010 14:16:57 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100601121657.83A542474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/06/01 14:16:57 Modified files: cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c Log message: globals don't need to be initialized to 0, it is the default; removing the initialization is even sometimes an optimization, depending on the compiler From jkrell at elego.de Tue Jun 1 14:17:35 2010 From: jkrell at elego.de (Jay Krell) Date: Tue, 1 Jun 2010 14:17:35 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100601121735.F27552474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/06/01 14:17:35 Modified files: cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c Log message: globals don't need to be initialized to 0, it is the default; removing the initialization is even sometimes an optimization, depending on the compiler From jay.krell at cornell.edu Tue Jun 1 14:10:27 2010 From: jay.krell at cornell.edu (Jay K) Date: Tue, 1 Jun 2010 12:10:27 +0000 Subject: [M3commit] CVS Update: cm3 In-Reply-To: <20100601120816.90BA32474003@birch.elegosoft.com> References: <20100601120816.90BA32474003@birch.elegosoft.com> Message-ID: ---------------------------------------- > Date: Tue, 1 Jun 2010 14:08:16 +0000 > To: m3commit at elegosoft.com > From: jkrell at elego.de > Subject: [M3commit] CVS Update: cm3 > > CVSROOT: /usr/cvs > Changes by: jkrell at birch. 10/06/01 14:08:16 > > Modified files: > cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c > > Log message: > It turns out extracting 0 bits is allowed. > Test p137 does it. > I had put in an assert to disallow it. > For this case, alwas return 0, rather than risk "over shifting". > This seems to be correct per: > http://www.cs.purdue.edu/homes/hosking/m3/reference/word-intf.html > We take n (0) bits from the input and set the rest of the bits (all > of them) to 0. > -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: extract0w.txt URL: From jkrell at elego.de Tue Jun 1 14:29:54 2010 From: jkrell at elego.de (Jay Krell) Date: Tue, 1 Jun 2010 14:29:54 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100601122954.1877B2474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/06/01 14:29:54 Modified files: cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c Log message: minor: put space in -v output, add const, change char* to char[] to save the pointer From jkrell at elego.de Tue Jun 1 14:32:23 2010 From: jkrell at elego.de (Jay Krell) Date: Tue, 1 Jun 2010 14:32:23 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100601123224.33C842474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/06/01 14:32:23 Modified files: cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c Log message: major: remove the add_stmt from m3cg_pop Compiling m3core each way, and optimized and not, the only thing add_stmt does is add unnecessary code (and it survives optimization). Notice that for years the decision to call add_stmt wasn't right and nobody noticed, which isn't conclusive of course.. From jkrell at elego.de Tue Jun 1 14:42:00 2010 From: jkrell at elego.de (Jay Krell) Date: Tue, 1 Jun 2010 14:42:00 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100601124200.8E42B2474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/06/01 14:42:00 Modified files: cm3/m3-libs/m3core/src/convert/: Convert.m3 Log message: initialize locals; I get warnings that some not quite all, are used uninitialized if I remove the volatile/sideeffects on every load/store in parse.c From jkrell at elego.de Tue Jun 1 14:51:28 2010 From: jkrell at elego.de (Jay Krell) Date: Tue, 1 Jun 2010 14:51:28 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100601125128.A57962474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/06/01 14:51:28 Modified files: cm3/m3-libs/m3core/src/thread/PTHREAD/: ThreadPThread.m3 Log message: initialize locals, warning from modified compiler (though said compiler seems not always correct) From jkrell at elego.de Tue Jun 1 14:56:37 2010 From: jkrell at elego.de (Jay Krell) Date: Tue, 1 Jun 2010 14:56:37 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100601125637.8B97E2474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/06/01 14:56:37 Modified files: cm3/m3-libs/m3core/src/runtime/common/: RTCollector.m3 Log message: slight change due to compiler warning..but it definitely seemed ok before ? From jkrell at elego.de Tue Jun 1 15:35:43 2010 From: jkrell at elego.de (Jay Krell) Date: Tue, 1 Jun 2010 15:35:43 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100601133543.DBF162474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/06/01 15:35:43 Modified files: cm3/m3-libs/libm3/src/geometry/: PolyRegion.m3 cm3/m3-libs/libm3/src/os/POSIX/: ProcessPosixCommon.m3 cm3/m3-libs/libm3/src/rw/: Rd.m3 RdUtils.m3 Log message: initialize locals From jkrell at elego.de Tue Jun 1 16:39:36 2010 From: jkrell at elego.de (Jay Krell) Date: Tue, 1 Jun 2010 16:39:36 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100601143937.16D9D2474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/06/01 16:39:36 Modified files: cm3/m3-libs/m3core/src/runtime/common/: RTCollector.m3 Log message: go back a version, the compiler complaint was wrong and for now I have to be less aggressive because I can't figure out the problem in e.g. libm3/Formatter.m3 From jkrell at elego.de Tue Jun 1 20:19:51 2010 From: jkrell at elego.de (Jay Krell) Date: Tue, 1 Jun 2010 20:19:51 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100601181951.DD2792474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/06/01 20:19:51 Modified files: cm3/m3-libs/sysutils/src/: System.m3 Log message: fix use of uninitialized local From jkrell at elego.de Tue Jun 1 20:23:03 2010 From: jkrell at elego.de (Jay Krell) Date: Tue, 1 Jun 2010 20:23:03 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100601182303.817262474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/06/01 20:23:03 Modified files: cm3/m3-sys/m3back/src/: M3x86.m3 Log message: initialize locals From jkrell at elego.de Tue Jun 1 20:26:48 2010 From: jkrell at elego.de (Jay Krell) Date: Tue, 1 Jun 2010 20:26:48 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100601182648.7B8872474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/06/01 20:26:48 Modified files: cm3/m3-sys/m3front/src/misc/: Scanner.m3 Log message: initialize local: compiler is wrong but ok From jkrell at elego.de Tue Jun 1 21:12:38 2010 From: jkrell at elego.de (Jay Krell) Date: Tue, 1 Jun 2010 21:12:38 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100601191245.20AB82474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/06/01 21:12:38 Modified files: cm3/m3-ui/ui/src/vbt/: VBTClass.m3 Log message: initialize local: compiler is wrong but this is a classic case that compilers typically fail on From jkrell at elego.de Tue Jun 1 21:15:21 2010 From: jkrell at elego.de (Jay Krell) Date: Tue, 1 Jun 2010 21:15:21 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100601191522.F13A12474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/06/01 21:15:21 Modified files: cm3/m3-sys/m3tools/src/: M3Const.m3 Log message: initialize locals: compiler is wrong, but it would have to know that Err never returns in order to figure it out From jkrell at elego.de Tue Jun 1 21:43:03 2010 From: jkrell at elego.de (Jay Krell) Date: Tue, 1 Jun 2010 21:43:03 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100601194303.B89432474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/06/01 21:43:03 Modified files: cm3/m3-sys/cm3ide/src/misc/: BrowserDB.m3 Log message: fix use of uninitialized local that appears to occur if input file is malformed From jkrell at elego.de Tue Jun 1 21:47:28 2010 From: jkrell at elego.de (Jay Krell) Date: Tue, 1 Jun 2010 21:47:28 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100601194728.E93852474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/06/01 21:47:28 Modified files: cm3/m3-tools/m3tk/src/pl/: M3LTypeHash.m3 Log message: initialize local: I suspect compiler is wrong, but backend would have to know that the fault proc is noreturn, maybe that is doable? From jkrell at elego.de Tue Jun 1 21:48:32 2010 From: jkrell at elego.de (Jay Krell) Date: Tue, 1 Jun 2010 21:48:32 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100601194832.78F102474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/06/01 21:48:32 Modified files: cm3/m3-tools/m3tk/src/pl/: M3LTypeToText.m3 Log message: again, initialize local: I suspect compiler is wrong, but backend would have to know that the fault proc is noreturn, maybe that is doable? From jkrell at elego.de Tue Jun 1 22:13:01 2010 From: jkrell at elego.de (Jay Krell) Date: Tue, 1 Jun 2010 22:13:01 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100601201301.628802474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/06/01 22:13:01 Modified files: cm3/m3-sys/m3cc/src/: m3makefile Log message: clean also mpc and zlib directories, use the Makefile as the 'configure done' file From jkrell at elego.de Tue Jun 1 22:15:52 2010 From: jkrell at elego.de (Jay Krell) Date: Tue, 1 Jun 2010 22:15:52 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100601201552.484342474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/06/01 22:15:52 Modified files: cm3/m3-sys/m3cc/src/: m3makefile Log message: go back a version From jkrell at elego.de Tue Jun 1 22:21:53 2010 From: jkrell at elego.de (Jay Krell) Date: Tue, 1 Jun 2010 22:21:53 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100601202155.DC4412474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/06/01 22:21:53 Modified files: cm3/m3-sys/m3cc/gcc/gcc/: tree-ssa-sink.c Log message: fix uninitialized variable warning From hosking at cs.purdue.edu Tue Jun 1 23:13:35 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Tue, 1 Jun 2010 16:13:35 -0500 Subject: [M3commit] CVS Update: cm3 In-Reply-To: <20100601194832.78F102474003@birch.elegosoft.com> References: <20100601194832.78F102474003@birch.elegosoft.com> Message-ID: I don't understand what you are doing here. The compiler guarantees that all variables have a legal initial value. Sent from my iPhone On Jun 1, 2010, at 9:48 PM, jkrell at elego.de (Jay Krell) wrote: > CVSROOT: /usr/cvs > Changes by: jkrell at birch. 10/06/01 21:48:32 > > Modified files: > cm3/m3-tools/m3tk/src/pl/: M3LTypeToText.m3 > > Log message: > again, initialize local: I suspect compiler is wrong, but backend > would have to know that the fault proc is noreturn, maybe that is > doable? From hosking at cs.purdue.edu Tue Jun 1 23:29:20 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Tue, 1 Jun 2010 16:29:20 -0500 Subject: [M3commit] CVS Update: cm3 In-Reply-To: <20100601124200.8E42B2474003@birch.elegosoft.com> References: <20100601124200.8E42B2474003@birch.elegosoft.com> Message-ID: This is bogus. The M3 compiler guarantees all variables are initialized. Sent from my iPhone On Jun 1, 2010, at 2:42 PM, jkrell at elego.de (Jay Krell) wrote: > CVSROOT: /usr/cvs > Changes by: jkrell at birch. 10/06/01 14:42:00 > > Modified files: > cm3/m3-libs/m3core/src/convert/: Convert.m3 > > Log message: > initialize locals; I get warnings that some not quite all, are > used uninitialized if I remove the volatile/sideeffects on every > load/store in parse.c From jay.krell at cornell.edu Tue Jun 1 23:44:27 2010 From: jay.krell at cornell.edu (Jay K) Date: Tue, 1 Jun 2010 21:44:27 +0000 Subject: [M3commit] CVS Update: cm3 In-Reply-To: References: <20100601124200.8E42B2474003@birch.elegosoft.com>, Message-ID: Start removing the rampant use of volatile in the backend and these warnings show up. Volatile quashes the uninitialized checks in the backend. Is it really ok for an INTEGER to be uninitialized? I realize it contains an "integer" value, as all bit patterns are. Some of these really do seem like bugs. Some do not. I'll try making fault_proc noreturn, which should remove some of them. - Jay ---------------------------------------- > From: hosking at cs.purdue.edu > To: jkrell at elego.de > Date: Tue, 1 Jun 2010 16:29:20 -0500 > CC: m3commit at elegosoft.com > Subject: Re: [M3commit] CVS Update: cm3 > > This is bogus. The M3 compiler guarantees all variables are initialized. > > Sent from my iPhone > > On Jun 1, 2010, at 2:42 PM, jkrell at elego.de (Jay Krell) wrote: > >> CVSROOT: /usr/cvs >> Changes by: jkrell at birch. 10/06/01 14:42:00 >> >> Modified files: >> cm3/m3-libs/m3core/src/convert/: Convert.m3 >> >> Log message: >> initialize locals; I get warnings that some not quite all, are >> used uninitialized if I remove the volatile/sideeffects on every >> load/store in parse.c From hosking at cs.purdue.edu Wed Jun 2 02:04:00 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Tue, 1 Jun 2010 20:04:00 -0400 Subject: [M3commit] CVS Update: cm3 In-Reply-To: References: <20100601124200.8E42B2474003@birch.elegosoft.com>, Message-ID: <5458A114-F000-4A90-9998-FD7DF63E06C0@cs.purdue.edu> Sure, an INTEGER is a valid value whatever the bits. On 1 Jun 2010, at 17:44, Jay K wrote: > > Start removing the rampant use of volatile in the backend and these warnings show up. > > Volatile quashes the uninitialized checks in the backend. > > Is it really ok for an INTEGER to be uninitialized? I realize it contains an "integer" value, as all bit patterns are. > > Some of these really do seem like bugs. Some do not. > I'll try making fault_proc noreturn, which should remove some of them. > > > - Jay > > > > > ---------------------------------------- >> From: hosking at cs.purdue.edu >> To: jkrell at elego.de >> Date: Tue, 1 Jun 2010 16:29:20 -0500 >> CC: m3commit at elegosoft.com >> Subject: Re: [M3commit] CVS Update: cm3 >> >> This is bogus. The M3 compiler guarantees all variables are initialized. >> >> Sent from my iPhone >> >> On Jun 1, 2010, at 2:42 PM, jkrell at elego.de (Jay Krell) wrote: >> >>> CVSROOT: /usr/cvs >>> Changes by: jkrell at birch. 10/06/01 14:42:00 >>> >>> Modified files: >>> cm3/m3-libs/m3core/src/convert/: Convert.m3 >>> >>> Log message: >>> initialize locals; I get warnings that some not quite all, are >>> used uninitialized if I remove the volatile/sideeffects on every >>> load/store in parse.c From jay.krell at cornell.edu Wed Jun 2 02:10:02 2010 From: jay.krell at cornell.edu (Jay K) Date: Wed, 2 Jun 2010 00:10:02 +0000 Subject: [M3commit] CVS Update: cm3 In-Reply-To: <5458A114-F000-4A90-9998-FD7DF63E06C0@cs.purdue.edu> References: <20100601124200.8E42B2474003@birch.elegosoft.com>, , <5458A114-F000-4A90-9998-FD7DF63E06C0@cs.purdue.edu> Message-ID: ok, so in C: int F() { int i; return i; } should warn or not? Prevailing wisdom is definitely. Main known exception is code to generate random numbers. I believe this is how Debian broke key generation. Modula-3: PROCEDURE F(): INTEGER = VAR i: INTEGER; BEGIN RETURN i; END F; Should warn or not? Since this identical to the C, prevailing wisdom is definitely. They are, I guess, "safe", but most likely, incorrect. The compiler may have made "safety" guarantees, and they are significant, but safe is far from correct, and however smart the compiler can be to look for correctness issues, is also nice. (Friend of mine conjectured something like: Safety guarantees have people deluded. Software will still have plenty of bugs and be plenty difficult to get correct and require plenty of testing. Safety guarantees help, but they are only a small step toward actual correctness.) - Jay ---------------------------------------- > Subject: Re: [M3commit] CVS Update: cm3 > From: hosking at cs.purdue.edu > Date: Tue, 1 Jun 2010 20:04:00 -0400 > CC: jkrell at elego.de; m3commit at elegosoft.com > To: jay.krell at cornell.edu > > Sure, an INTEGER is a valid value whatever the bits. > > > On 1 Jun 2010, at 17:44, Jay K wrote: > >> >> Start removing the rampant use of volatile in the backend and these warnings show up. >> >> Volatile quashes the uninitialized checks in the backend. >> >> Is it really ok for an INTEGER to be uninitialized? I realize it contains an "integer" value, as all bit patterns are. >> >> Some of these really do seem like bugs. Some do not. >> I'll try making fault_proc noreturn, which should remove some of them. >> >> >> - Jay >> >> >> >> >> ---------------------------------------- >>> From: hosking at cs.purdue.edu >>> To: jkrell at elego.de >>> Date: Tue, 1 Jun 2010 16:29:20 -0500 >>> CC: m3commit at elegosoft.com >>> Subject: Re: [M3commit] CVS Update: cm3 >>> >>> This is bogus. The M3 compiler guarantees all variables are initialized. >>> >>> Sent from my iPhone >>> >>> On Jun 1, 2010, at 2:42 PM, jkrell at elego.de (Jay Krell) wrote: >>> >>>> CVSROOT: /usr/cvs >>>> Changes by: jkrell at birch. 10/06/01 14:42:00 >>>> >>>> Modified files: >>>> cm3/m3-libs/m3core/src/convert/: Convert.m3 >>>> >>>> Log message: >>>> initialize locals; I get warnings that some not quite all, are >>>> used uninitialized if I remove the volatile/sideeffects on every >>>> load/store in parse.c > From jkrell at elego.de Wed Jun 2 10:46:10 2010 From: jkrell at elego.de (Jay Krell) Date: Wed, 2 Jun 2010 10:46:10 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100602084610.BC8FE2474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/06/02 10:46:10 Modified files: cm3/m3-comm/tcp/src/POSIX/: TCP.m3 Log message: use socklen_t, not int socklen_t is chosen for convenience, not to match the underlying platform, therefore it is INTEGER or Word.T, and the underlying C wrappers copy back and forth From jkrell at elego.de Wed Jun 2 10:58:34 2010 From: jkrell at elego.de (Jay Krell) Date: Wed, 2 Jun 2010 10:58:34 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100602085835.0F7E12474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/06/02 10:58:34 Added files: cm3/m3-sys/cm3ide/: .cvsignore Log message: add .cvsignore From jkrell at elego.de Wed Jun 2 11:06:07 2010 From: jkrell at elego.de (Jay Krell) Date: Wed, 2 Jun 2010 11:06:07 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100602090607.22E0D2474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/06/02 11:06:07 Modified files: cm3/m3-sys/cm3ide/: .cvsignore Log message: add more From jkrell at elego.de Wed Jun 2 13:12:04 2010 From: jkrell at elego.de (Jay Krell) Date: Wed, 2 Jun 2010 13:12:04 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100602111204.108A92474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/06/02 13:12:04 Modified files: cm3/m3-sys/cminstall/src/config-no-install/: Unix.common Solaris.common Log message: just building cm3 for SOLgnu uses too many PIC slots for small PIC so go back to big PIC..I get the feeling ELF is kind of lame.. From jkrell at elego.de Wed Jun 2 15:27:06 2010 From: jkrell at elego.de (Jay Krell) Date: Wed, 2 Jun 2010 15:27:06 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100602132710.4A8F32474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/06/02 15:27:06 Modified files: cm3/m3-sys/m3cc/src/: m3makefile Log message: fill in a bunch of '-with-gnu-as -with-gnu-ld' for cross builds to e.g. avoid the warning that visibility isn't supported and is being ignored; use Makefile instead of .configure-done From jkrell at elego.de Wed Jun 2 15:50:29 2010 From: jkrell at elego.de (Jay Krell) Date: Wed, 2 Jun 2010 15:50:29 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100602135029.83AF42474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/06/02 15:50:29 Modified files: cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c Log message: in extract/insert_[m]n, trace m and n, under -y From jkrell at elego.de Wed Jun 2 15:59:40 2010 From: jkrell at elego.de (Jay Krell) Date: Wed, 2 Jun 2010 15:59:40 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100602135940.380512474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/06/02 15:59:40 Modified files: cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c Log message: a little reformating, mainly newlines before and after the tracing code From jkrell at elego.de Wed Jun 2 16:04:51 2010 From: jkrell at elego.de (Jay Krell) Date: Wed, 2 Jun 2010 16:04:51 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100602140451.6B6782474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/06/02 16:04:51 Modified files: cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c Log message: a tiny bit more reformat From hosking at cs.purdue.edu Wed Jun 2 16:38:59 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Wed, 2 Jun 2010 10:38:59 -0400 Subject: [M3commit] CVS Update: cm3 In-Reply-To: References: <20100601124200.8E42B2474003@birch.elegosoft.com>, , <5458A114-F000-4A90-9998-FD7DF63E06C0@cs.purdue.edu> Message-ID: C provides no guarantees about initialisation. Modula-3 requires that all variables be initialised (explicitly or by the compiler) as necessary to ensure they have a valid value for their type. So, basically, the warning you are getting from the gcc backend is not pertinent to Modula-3. On 1 Jun 2010, at 20:10, Jay K wrote: > > ok, so in C: > > int F() > { > int i; > return i; > } > > should warn or not? > Prevailing wisdom is definitely. > Main known exception is code to generate random numbers. > I believe this is how Debian broke key generation. > > > Modula-3: > > > PROCEDURE F(): INTEGER = > VAR i: INTEGER; > BEGIN > RETURN i; > END F; > > > Should warn or not? > Since this identical to the C, prevailing wisdom is definitely. No, because Modula-3 guarantees the value of i is valid for the type. It could be a random value of bits in this case because all bit combinations are valid for a Modula-3 INTEGER. If you tried something like a subrange [0..3] then you will see explicit initialisation with a value in the range [0..3]. > They are, I guess, "safe", but most likely, incorrect. > > > The compiler may have made "safety" guarantees, and they are significant, > but safe is far from correct, and however smart the compiler can be to look for correctness issues, is also nice. You are living in C land. > (Friend of mine conjectured something like: Safety guarantees have people deluded. Software will still have plenty of bugs and be plenty difficult to get correct and require plenty of testing. Safety guarantees help, but they are only a small step toward actual correctness.) > > > > - Jay > > > ---------------------------------------- >> Subject: Re: [M3commit] CVS Update: cm3 >> From: hosking at cs.purdue.edu >> Date: Tue, 1 Jun 2010 20:04:00 -0400 >> CC: jkrell at elego.de; m3commit at elegosoft.com >> To: jay.krell at cornell.edu >> >> Sure, an INTEGER is a valid value whatever the bits. >> >> >> On 1 Jun 2010, at 17:44, Jay K wrote: >> >>> >>> Start removing the rampant use of volatile in the backend and these warnings show up. >>> >>> Volatile quashes the uninitialized checks in the backend. >>> >>> Is it really ok for an INTEGER to be uninitialized? I realize it contains an "integer" value, as all bit patterns are. >>> >>> Some of these really do seem like bugs. Some do not. >>> I'll try making fault_proc noreturn, which should remove some of them. >>> >>> >>> - Jay >>> >>> >>> >>> >>> ---------------------------------------- >>>> From: hosking at cs.purdue.edu >>>> To: jkrell at elego.de >>>> Date: Tue, 1 Jun 2010 16:29:20 -0500 >>>> CC: m3commit at elegosoft.com >>>> Subject: Re: [M3commit] CVS Update: cm3 >>>> >>>> This is bogus. The M3 compiler guarantees all variables are initialized. >>>> >>>> Sent from my iPhone >>>> >>>> On Jun 1, 2010, at 2:42 PM, jkrell at elego.de (Jay Krell) wrote: >>>> >>>>> CVSROOT: /usr/cvs >>>>> Changes by: jkrell at birch. 10/06/01 14:42:00 >>>>> >>>>> Modified files: >>>>> cm3/m3-libs/m3core/src/convert/: Convert.m3 >>>>> >>>>> Log message: >>>>> initialize locals; I get warnings that some not quite all, are >>>>> used uninitialized if I remove the volatile/sideeffects on every >>>>> load/store in parse.c >> From jkrell at elego.de Wed Jun 2 18:35:40 2010 From: jkrell at elego.de (Jay Krell) Date: Wed, 2 Jun 2010 18:35:40 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100602163540.ABBFE2474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/06/02 18:35:40 Modified files: cm3/m3-sys/m3cc/src/: platforms.quake Log message: bump cross target=Solaris/sparc32 builds from 'solaris2' to 'solaris2.10'; native builds worked and this *seemed* to do it, still more to look into though (try 2.8, try removing volatils, try enabling 'gas weak', another difference I noticed between cross and native..this all goes to show, autoconf totally breaks down in the fact of cross builds, would be good to just not use it...oh well) From jkrell at elego.de Wed Jun 2 18:58:16 2010 From: jkrell at elego.de (Jay Krell) Date: Wed, 2 Jun 2010 18:58:16 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100602165816.E672F2474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/06/02 18:58:16 Modified files: cm3/scripts/python/: pylib.py Log message: print posixy 'export' instead of win32 'set' when on posix From jkrell at elego.de Wed Jun 2 18:59:55 2010 From: jkrell at elego.de (Jay Krell) Date: Wed, 2 Jun 2010 18:59:55 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100602165955.30FCD2474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/06/02 18:59:55 Modified files: cm3/scripts/python/: pylib.py Log message: print posixy 'unset' when clearing, I really don't understand the sh nuances though, I guess variable can be defined to be empty..but which shells do support unset? anyway, this is just printed for human to see approximation of internal actions, it's not actual executed From jkrell at elego.de Wed Jun 2 19:30:51 2010 From: jkrell at elego.de (Jay Krell) Date: Wed, 2 Jun 2010 19:30:51 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100602173051.643522474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/06/02 19:30:51 Modified files: cm3/m3-sys/m3cc/src/: m3makefile Log message: update Solaris and sparc64 non-auto-conf (add 'gas weak'), fix typo in comment From jkrell at elego.de Wed Jun 2 20:31:34 2010 From: jkrell at elego.de (Jay Krell) Date: Wed, 2 Jun 2010 20:31:34 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100602183134.99E862474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/06/02 20:31:34 Modified files: cm3/m3-sys/m3cc/gcc/gcc/config/: sol2.h cm3/m3-sys/m3cc/gcc/gcc/config/sparc/: sparc.h cm3/m3-sys/m3cc/gcc/gcc/m3cg/: m3gty43.h m3gty45.h parse.c Log message: significantly remove use of volatile Allowing the optimizer to actually do anything volatile remains on Solaris/sparc32 probably just need to experiment extensively volatile remains on all floating point loads, quite unfortunate for the scientific computing crowed.. volatile is added to more locals and temporaries within functions that call setjmp/vfork (setjmp is very common!?) volatile store after insert_mn, small lame hack, because otherwise we have a read before write a few optimizations are turned off, though I did solve the "unit at a time" problem, with TREE_USED or so I thought, but no...I had confused "ui" and "vbtkit" packages prototype marking fault_proc as noreturn but then I get a warning that it does return, even if I removed the return Provide and use m3_build_pointer_type that presently is pointless, but maybe will mean something in future There is a bit to turn off alias analysis. pre/fre still crashed. I didn't try vrp, it is the most painful to test when it goes wrong, because it successfully compiles everything. Mostly tested on AMD64_DARWIN. Needs broader coverage. Need to consider the warnings it causes. Need to get fault_proc marked noreturn first. Could use better for Solaris/sparc32, but machine is so slow experimentation is painful. From jkrell at elego.de Wed Jun 2 20:34:52 2010 From: jkrell at elego.de (Jay Krell) Date: Wed, 2 Jun 2010 20:34:52 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100602183452.399A22474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/06/02 20:34:52 Modified files: cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c Log message: fix accidental wierd bad form, might even help bring back the nested function that gets optimized out?? probably not but worth more trying or investigation.. From jay.krell at cornell.edu Wed Jun 2 20:35:51 2010 From: jay.krell at cornell.edu (Jay K) Date: Wed, 2 Jun 2010 18:35:51 +0000 Subject: [M3commit] CVS Update: cm3 In-Reply-To: <20100602183134.99E862474003@birch.elegosoft.com> References: <20100602183134.99E862474003@birch.elegosoft.com> Message-ID: Basically the same as before. ?- Jay ---------------------------------------- > Date: Wed, 2 Jun 2010 20:31:34 +0000 > To: m3commit at elegosoft.com > From: jkrell at elego.de > Subject: [M3commit] CVS Update: cm3 > > CVSROOT: /usr/cvs > Changes by: jkrell at birch. 10/06/02 20:31:34 > > Modified files: > cm3/m3-sys/m3cc/gcc/gcc/config/: sol2.h > cm3/m3-sys/m3cc/gcc/gcc/config/sparc/: sparc.h > cm3/m3-sys/m3cc/gcc/gcc/m3cg/: m3gty43.h m3gty45.h parse.c > > Log message: > significantly remove use of volatile > Allowing the optimizer to actually do anything > > volatile remains on Solaris/sparc32 > probably just need to experiment extensively > > volatile remains on all floating point loads, > quite unfortunate for the scientific computing crowed.. > > volatile is added to more locals and temporaries > within functions that call setjmp/vfork > (setjmp is very common!?) > > volatile store after insert_mn, small lame hack, > because otherwise we have a read before write > > a few optimizations are turned off, > though I did solve the "unit at a time" problem, with TREE_USED > or so I thought, but no...I had confused "ui" and "vbtkit" packages > > prototype marking fault_proc as noreturn > but then I get a warning that it does return, > even if I removed the return > > Provide and use m3_build_pointer_type that presently is pointless, > but maybe will mean something in future > There is a bit to turn off alias analysis. > pre/fre still crashed. I didn't try vrp, it is > the most painful to test when it goes wrong, because > it successfully compiles everything. > > Mostly tested on AMD64_DARWIN. > Needs broader coverage. > Need to consider the warnings it causes. > Need to get fault_proc marked noreturn first. > Could use better for Solaris/sparc32, but machine > is so slow experimentation is painful. > -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: volatile1.txt URL: From jkrell at elego.de Fri Jun 4 07:51:20 2010 From: jkrell at elego.de (Jay Krell) Date: Fri, 4 Jun 2010 7:51:20 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100604055121.8B2652474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/06/04 07:51:20 Modified files: cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c Log message: add m3_load_volatile, not currently used, but I get tired of putting it in to experiment, taking it out, repeat, etc. From jkrell at elego.de Fri Jun 4 17:41:45 2010 From: jkrell at elego.de (Jay Krell) Date: Fri, 4 Jun 2010 17:41:45 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100604154145.DC6CE2474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/06/04 17:41:45 Modified files: cm3/m3-sys/m3cc/gcc/gcc/m3cg/: Tag: release_branch_cm3_5_8 parse.c Log message: Port unfortunate fix from head, unless/until a better fix is found. The program: MODULE Main; PROCEDURE F1() = PROCEDURE NestedUnused1() = BEGIN END NestedUnused1; BEGIN IF FALSE THEN NestedUnused1(); END; END F1; BEGIN F1(); END Main. fails to link with: Undefined symbols: "_Main__F1__NestedUnused1.496", referenced from: _L_1 in Main.mo unless we do: flag_unit_at_a_time = 0; in parse.c From jkrell at elego.de Fri Jun 4 17:43:56 2010 From: jkrell at elego.de (Jay Krell) Date: Fri, 4 Jun 2010 17:43:56 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100604154356.5BFFE2474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/06/04 17:43:56 Modified files: cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c Log message: make comment match release regarding unit_at_a_time From jkrell at elego.de Fri Jun 4 18:15:09 2010 From: jkrell at elego.de (Jay Krell) Date: Fri, 4 Jun 2010 18:15:09 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100604161520.CB0D02474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/06/04 18:15:09 Modified files: cm3/m3-sys/m3cc/gcc/gcc/m3cg/: Tag: release_branch_cm3_5_8 parse.c Log message: turn off "pre" optimization, which crashes compiling m3-tools/cvsup/server/FSServer.m3 From jkrell at elego.de Fri Jun 4 18:18:09 2010 From: jkrell at elego.de (Jay Krell) Date: Fri, 4 Jun 2010 18:18:09 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100604161809.670FC2474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/06/04 18:18:09 Modified files: cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c Log message: always turn off "pre" (partial redundancy elimination), even when there is a stack walker, as it crashes on release Testing on Solaris/sparc32 would be appropriate though to see if it causes compiler crash there (or just doing cross build) From jkrell at elego.de Fri Jun 4 18:18:55 2010 From: jkrell at elego.de (Jay Krell) Date: Fri, 4 Jun 2010 18:18:55 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100604161855.1E6232474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/06/04 18:18:55 Modified files: cm3/m3-sys/m3cc/gcc/gcc/m3cg/: Tag: release_branch_cm3_5_8 parse.c Log message: adjust comment: spell out 'pre' means From hosking at cs.purdue.edu Fri Jun 4 18:36:24 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Fri, 4 Jun 2010 12:36:24 -0400 Subject: [M3commit] CVS Update: cm3 In-Reply-To: <20100604161520.CB0D02474003@birch.elegosoft.com> References: <20100604161520.CB0D02474003@birch.elegosoft.com> Message-ID: <06C73A71-2ECD-4EA2-BE48-52A573DCAFF3@cs.purdue.edu> Are you planning to go through and fix things so we can re-enable optimisations? I worked pretty hard to get everything to compile with -O2/-O3 when I worked on this with the current m3cg. Antony Hosking | Associate Professor | Computer Science | Purdue University 305 N. University Street | West Lafayette | IN 47907 | USA Office +1 765 494 6001 | Mobile +1 765 427 5484 On 4 Jun 2010, at 18:15, Jay Krell wrote: > CVSROOT: /usr/cvs > Changes by: jkrell at birch. 10/06/04 18:15:09 > > Modified files: > cm3/m3-sys/m3cc/gcc/gcc/m3cg/: Tag: release_branch_cm3_5_8 > parse.c > > Log message: > turn off "pre" optimization, which crashes compiling > m3-tools/cvsup/server/FSServer.m3 -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Fri Jun 4 19:16:35 2010 From: jay.krell at cornell.edu (Jay K) Date: Fri, 4 Jun 2010 17:16:35 +0000 Subject: [M3commit] CVS Update: cm3 In-Reply-To: <06C73A71-2ECD-4EA2-BE48-52A573DCAFF3@cs.purdue.edu> References: <20100604161520.CB0D02474003@birch.elegosoft.com>, <06C73A71-2ECD-4EA2-BE48-52A573DCAFF3@cs.purdue.edu> Message-ID: Unclear. I've also worked very hard at this and I believe it is in better shape than before. Granted, some steps forward, some backward. But I think much more forward. I'm using -O3. Sometimes what I do is in parse.c I explicitly enable everything but setting all the flags. We should perhaps do that anyway, esp. for optimizations that don't take long and don't hurt debugging. I suspect these two bugs were present back then, you just didn't hit them because: 1) we didn't have the unused nested function? 2) we didn't have cvsup? I disabled very very little. In trade, we don't throw around volatile all over the place. I think if you look into it, things were broken back then just the same. But we didn't have the code to tickle the bugs. I would like to get back "unit at a time". That seems a good optimization wrt inlining and it is being disabled for something that should be easily fixable some other way. vrp/fre/pre I don't know. It'll take quite some debugging to fix those. vrp produces bad code. fre and/or pre crash in the compiler. I'd also like to fix the volatile float problem. I've worked on that quite a bit too. I tried to make loophole always go through a volatile temporary for example. I tried making loophole go through a union. No luck yet. I guess I should see what: int a; float j; a = *(int*)&j; does in C. Notice that some of this is in the release branch. Where all I've done is test more code. I didn't remove the volatility on all load/store for example. - Jay ________________________________ > From: hosking at cs.purdue.edu > Date: Fri, 4 Jun 2010 12:36:24 -0400 > To: jkrell at elego.de > CC: m3commit at elegosoft.com > Subject: Re: [M3commit] CVS Update: cm3 > > > > Are you planning to go through and fix things so we can re-enable optimisations? > > I worked pretty hard to get everything to compile with -O2/-O3 when I worked on this with the current m3cg. > > > Antony Hosking | Associate Professor | Computer Science | Purdue University > 305 N. University Street | West Lafayette | IN 47907 | USA > Office +1 765 494 6001 | Mobile +1 765 427 5484 > > > > > > > On 4 Jun 2010, at 18:15, Jay Krell wrote: > > CVSROOT: /usr/cvs > Changes by: jkrell at birch. 10/06/04 18:15:09 > > Modified files: > cm3/m3-sys/m3cc/gcc/gcc/m3cg/: Tag: release_branch_cm3_5_8 > parse.c > > Log message: > turn off "pre" optimization, which crashes compiling > m3-tools/cvsup/server/FSServer.m3 > From hosking at cs.purdue.edu Fri Jun 4 19:58:59 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Fri, 4 Jun 2010 13:58:59 -0400 Subject: [M3commit] CVS Update: cm3 In-Reply-To: References: <20100604161520.CB0D02474003@birch.elegosoft.com>, <06C73A71-2ECD-4EA2-BE48-52A573DCAFF3@cs.purdue.edu> Message-ID: Cool. Thanks for putting the time in on this. On 4 Jun 2010, at 13:16, Jay K wrote: > > Unclear. I've also worked very hard at this and I believe it is in better shape than before. > Granted, some steps forward, some backward. But I think much more forward. > > I'm using -O3. > Sometimes what I do is in parse.c I explicitly enable everything but setting all the flags. > We should perhaps do that anyway, esp. for optimizations that don't take long and don't hurt debugging. > > > I suspect these two bugs were present back then, you just didn't hit them because: > 1) we didn't have the unused nested function? > 2) we didn't have cvsup? > > > I disabled very very little. > In trade, we don't throw around volatile all over the place. > > > I think if you look into it, things were broken back then just the same. > But we didn't have the code to tickle the bugs. > > > I would like to get back "unit at a time". That seems a good optimization wrt inlining and it is being disabled for something that should be easily fixable some other way. > > > vrp/fre/pre I don't know. > It'll take quite some debugging to fix those. > vrp produces bad code. > fre and/or pre crash in the compiler. > > > I'd also like to fix the volatile float problem. I've worked on that quite a bit too. > I tried to make loophole always go through a volatile temporary for example. > I tried making loophole go through a union. > No luck yet. > I guess I should see what: > int a; > float j; > a = *(int*)&j; > > > does in C. > > > Notice that some of this is in the release branch. Where all I've done is test more code. > I didn't remove the volatility on all load/store for example. > > > - Jay > > > ________________________________ >> From: hosking at cs.purdue.edu >> Date: Fri, 4 Jun 2010 12:36:24 -0400 >> To: jkrell at elego.de >> CC: m3commit at elegosoft.com >> Subject: Re: [M3commit] CVS Update: cm3 >> >> >> >> Are you planning to go through and fix things so we can re-enable optimisations? >> >> I worked pretty hard to get everything to compile with -O2/-O3 when I worked on this with the current m3cg. >> >> >> Antony Hosking | Associate Professor | Computer Science | Purdue University >> 305 N. University Street | West Lafayette | IN 47907 | USA >> Office +1 765 494 6001 | Mobile +1 765 427 5484 >> >> >> >> >> >> >> On 4 Jun 2010, at 18:15, Jay Krell wrote: >> >> CVSROOT: /usr/cvs >> Changes by: jkrell at birch. 10/06/04 18:15:09 >> >> Modified files: >> cm3/m3-sys/m3cc/gcc/gcc/m3cg/: Tag: release_branch_cm3_5_8 >> parse.c >> >> Log message: >> turn off "pre" optimization, which crashes compiling >> m3-tools/cvsup/server/FSServer.m3 >> From jkrell at elego.de Sat Jun 5 19:15:44 2010 From: jkrell at elego.de (Jay Krell) Date: Sat, 5 Jun 2010 19:15:44 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100605171544.E92B8CC37F@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/06/05 19:15:44 Modified files: cm3/m3-sys/m3middle/src/: Target.i3 Target.m3 Log message: restore ALPHA_OSF, but this time probably without stack walker just because I'm lazy, and resort the list again, it was only slightly unsorted From jkrell at elego.de Sat Jun 5 19:16:57 2010 From: jkrell at elego.de (Jay Krell) Date: Sat, 5 Jun 2010 19:16:57 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100605171657.98A79CC37F@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/06/05 19:16:57 Modified files: cm3/m3-libs/libm3/src/: platforms.quake Log message: restore ALPHA_OSF some day I will merge all this data into fewer places.. From jkrell at elego.de Sat Jun 5 19:19:26 2010 From: jkrell at elego.de (Jay Krell) Date: Sat, 5 Jun 2010 19:19:26 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100605171926.CF283CC37F@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/06/05 19:19:26 Added files: cm3/m3-libs/m3core/src/runtime/ALPHA_OSF/: m3makefile-old Removed files: cm3/m3-libs/m3core/src/runtime/ALPHA_OSF/: m3makefile Log message: rename m3makefile => m3makefile-old, so the common directory will notice no m3makefile and give us the portable files I'm omitting the stack walker, at least "for now", but realistically, probably the target-specific code will never come back, hopefully we'll have a somewhat portable stack walker using libunwind/libgcc/m3cc, at least on platforms that have libgcc, which is almost all From jkrell at elego.de Sat Jun 5 19:20:20 2010 From: jkrell at elego.de (Jay Krell) Date: Sat, 5 Jun 2010 19:20:20 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100605172020.BAA5C2474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/06/05 19:20:20 Modified files: cm3/m3-libs/m3core/src/unix/Common/: Usocket.c Log message: more information when there is an assertion failure From jkrell at elego.de Sat Jun 5 19:21:27 2010 From: jkrell at elego.de (Jay Krell) Date: Sat, 5 Jun 2010 19:21:27 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100605172127.E6C352474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/06/05 19:21:27 Modified files: cm3/m3-libs/m3core/src/: platforms.quake Log message: add ALPHA_OSF Really need to consolidate these lists.. From jkrell at elego.de Sat Jun 5 19:22:16 2010 From: jkrell at elego.de (Jay Krell) Date: Sat, 5 Jun 2010 19:22:16 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100605172216.74A412474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/06/05 19:22:16 Modified files: cm3/scripts/python/: pylib.py Log message: some suppoft for ALPHA_OSF, more needed here, soon later From jkrell at elego.de Sat Jun 5 19:24:37 2010 From: jkrell at elego.de (Jay Krell) Date: Sat, 5 Jun 2010 19:24:37 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100605172437.4C96E2474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/06/05 19:24:37 Modified files: cm3/m3-sys/m3cc/src/: platforms.quake Log message: upgrade from 'osf1' to 'osf5.1' From jkrell at elego.de Sat Jun 5 19:41:54 2010 From: jkrell at elego.de (Jay Krell) Date: Sat, 5 Jun 2010 19:41:54 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100605174155.0CAF4CC380@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/06/05 19:41:54 Modified files: cm3/m3-sys/m3cc/src/: m3makefile Log message: add -e flag on sh invocations; there is a problem here that when compilation/link fails, cm3 still succeeds, this doesn't seem to fix it, gr. From jkrell at elego.de Sat Jun 5 19:43:03 2010 From: jkrell at elego.de (Jay Krell) Date: Sat, 5 Jun 2010 19:43:03 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100605174303.54535CC380@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/06/05 19:43:03 Modified files: cm3/m3-libs/m3core/src/unix/: m3makefile Log message: add ALPHA_OSF From jkrell at elego.de Sat Jun 5 19:49:37 2010 From: jkrell at elego.de (Jay Krell) Date: Sat, 5 Jun 2010 19:49:37 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100605174938.717592474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/06/05 19:49:37 Modified files: cm3/m3-libs/libm3/src/os/POSIX/: m3makefile Log message: 'OSF' => 'Digital Unix', as we had for 'TRU64' From hosking at cs.purdue.edu Sat Jun 5 21:24:33 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sat, 5 Jun 2010 15:24:33 -0400 Subject: [M3commit] CVS Update: cm3 In-Reply-To: <20100605171544.E92B8CC37F@birch.elegosoft.com> References: <20100605171544.E92B8CC37F@birch.elegosoft.com> Message-ID: Please restore the stack walker. ALPHA_OSF is the one platform that does this properly! On 5 Jun 2010, at 19:15, Jay Krell wrote: > CVSROOT: /usr/cvs > Changes by: jkrell at birch. 10/06/05 19:15:44 > > Modified files: > cm3/m3-sys/m3middle/src/: Target.i3 Target.m3 > > Log message: > restore ALPHA_OSF, but this time probably without stack walker > just because I'm lazy, and resort the list again, it was only > slightly unsorted From jay.krell at cornell.edu Sat Jun 5 21:30:18 2010 From: jay.krell at cornell.edu (Jay K) Date: Sat, 5 Jun 2010 19:30:18 +0000 Subject: [M3commit] CVS Update: cm3 In-Reply-To: References: <20100605171544.E92B8CC37F@birch.elegosoft.com>, Message-ID: Solaris/sparc32 isn't enough to keep it alive? It's just that I have to restore the header cloning in m3core/src/unix. ?- Jay ---------------------------------------- > From: hosking at cs.purdue.edu > Date: Sat, 5 Jun 2010 15:24:33 -0400 > To: jkrell at elego.de > CC: m3commit at elegosoft.com > Subject: Re: [M3commit] CVS Update: cm3 > > Please restore the stack walker. ALPHA_OSF is the one platform that does this properly! > > > On 5 Jun 2010, at 19:15, Jay Krell wrote: > >> CVSROOT: /usr/cvs >> Changes by: jkrell at birch. 10/06/05 19:15:44 >> >> Modified files: >> cm3/m3-sys/m3middle/src/: Target.i3 Target.m3 >> >> Log message: >> restore ALPHA_OSF, but this time probably without stack walker >> just because I'm lazy, and resort the list again, it was only >> slightly unsorted > From hosking at cs.purdue.edu Sat Jun 5 23:44:35 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sat, 5 Jun 2010 17:44:35 -0400 Subject: [M3commit] CVS Update: cm3 In-Reply-To: References: <20100605171544.E92B8CC37F@birch.elegosoft.com>, Message-ID: <94F17EE8-B6FD-4B93-9FD4-4275AC0C64D0@cs.purdue.edu> I suppose. Though it does illustrate how the system can more properly support unwinding using a suitable API. On 5 Jun 2010, at 15:30, Jay K wrote: > > Solaris/sparc32 isn't enough to keep it alive? > It's just that I have to restore the header cloning in m3core/src/unix. > > - Jay > > ---------------------------------------- >> From: hosking at cs.purdue.edu >> Date: Sat, 5 Jun 2010 15:24:33 -0400 >> To: jkrell at elego.de >> CC: m3commit at elegosoft.com >> Subject: Re: [M3commit] CVS Update: cm3 >> >> Please restore the stack walker. ALPHA_OSF is the one platform that does this properly! >> >> >> On 5 Jun 2010, at 19:15, Jay Krell wrote: >> >>> CVSROOT: /usr/cvs >>> Changes by: jkrell at birch. 10/06/05 19:15:44 >>> >>> Modified files: >>> cm3/m3-sys/m3middle/src/: Target.i3 Target.m3 >>> >>> Log message: >>> restore ALPHA_OSF, but this time probably without stack walker >>> just because I'm lazy, and resort the list again, it was only >>> slightly unsorted >> > From jkrell at elego.de Sat Jun 5 20:47:41 2010 From: jkrell at elego.de (Jay Krell) Date: Sat, 5 Jun 2010 20:47:41 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100605184741.A2F562474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/06/05 20:47:41 Modified files: cm3/m3-libs/libm3/src/uid/POSIX/: MachineIDPosixC.c Log message: enable/test/fix the OSF1 case From jay.krell at cornell.edu Sun Jun 6 00:22:42 2010 From: jay.krell at cornell.edu (Jay K) Date: Sat, 5 Jun 2010 22:22:42 +0000 Subject: [M3commit] CVS Update: cm3 In-Reply-To: <94F17EE8-B6FD-4B93-9FD4-4275AC0C64D0@cs.purdue.edu> References: <20100605171544.E92B8CC37F@birch.elegosoft.com>, , , , <94F17EE8-B6FD-4B93-9FD4-4275AC0C64D0@cs.purdue.edu> Message-ID: I'll probably put it back. Esp. if it works the first time I try. ?- Jay ---------------------------------------- > From: hosking at cs.purdue.edu > Date: Sat, 5 Jun 2010 17:44:35 -0400 > To: jay.krell at cornell.edu > CC: m3commit at elegosoft.com > Subject: Re: [M3commit] CVS Update: cm3 > > I suppose. Though it does illustrate how the system can more properly support unwinding using a suitable API. > > On 5 Jun 2010, at 15:30, Jay K wrote: > >> >> Solaris/sparc32 isn't enough to keep it alive? >> It's just that I have to restore the header cloning in m3core/src/unix. >> >> - Jay >> >> ---------------------------------------- >>> From: hosking at cs.purdue.edu >>> Date: Sat, 5 Jun 2010 15:24:33 -0400 >>> To: jkrell at elego.de >>> CC: m3commit at elegosoft.com >>> Subject: Re: [M3commit] CVS Update: cm3 >>> >>> Please restore the stack walker. ALPHA_OSF is the one platform that does this properly! >>> >>> >>> On 5 Jun 2010, at 19:15, Jay Krell wrote: >>> >>>> CVSROOT: /usr/cvs >>>> Changes by: jkrell at birch. 10/06/05 19:15:44 >>>> >>>> Modified files: >>>> cm3/m3-sys/m3middle/src/: Target.i3 Target.m3 >>>> >>>> Log message: >>>> restore ALPHA_OSF, but this time probably without stack walker >>>> just because I'm lazy, and resort the list again, it was only >>>> slightly unsorted >>> >> > From jkrell at elego.de Sun Jun 6 02:12:14 2010 From: jkrell at elego.de (Jay Krell) Date: Sun, 6 Jun 2010 2:12:14 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100606001214.EA6BC2474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/06/06 02:12:14 Modified files: cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c Log message: change #ifdef GCC42 to #if GCC42 and if GCC42, but not real change, at this point From jkrell at elego.de Sun Jun 6 02:28:09 2010 From: jkrell at elego.de (Jay Krell) Date: Sun, 6 Jun 2010 2:28:09 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100606002809.E4C452474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/06/06 02:28:09 Modified files: cm3/m3-libs/m3core/src/runtime/POSIX/: test_signal.c Log message: make the test case even better, and even better; that is, first I made it print too 'close' numbers, the address of a function and the crashing address, but then, even better, jump to a hardcoded constant, we should crash at that place From jkrell at elego.de Sun Jun 6 02:42:29 2010 From: jkrell at elego.de (Jay Krell) Date: Sun, 6 Jun 2010 2:42:29 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100606004230.77EE12474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/06/06 02:42:29 Modified files: cm3/m3-libs/m3core/src/runtime/POSIX/: RTSignalC.c Log message: adapt for ALPHA_OSF The printed value is not the "controlled" value, and is only in the vague vicinity of another possible one -- the calling function..a little worrisome, might want to revisit, but this doesn't really have to work, it is just for printing where crashes occured and on some platforms we just return NULL. From jkrell at elego.de Sun Jun 6 02:50:16 2010 From: jkrell at elego.de (Jay Krell) Date: Sun, 6 Jun 2010 2:50:16 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100606005017.187962474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/06/06 02:50:16 Modified files: cm3/m3-libs/m3core/src/: m3core.h Log message: adaptions for ALPHA_OSF: - gcc doesn't support visibility here - socklen_t is only typedefed if you #define something, which at this point I'm not going to to, typedef socklen_t myself instead From jkrell at elego.de Sun Jun 6 03:21:54 2010 From: jkrell at elego.de (Jay Krell) Date: Sun, 6 Jun 2010 3:21:54 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100606012159.2A3762474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/06/06 03:21:54 Modified files: cm3/m3-sys/cminstall/src/config/: ALPHA_OSF Added files: cm3/m3-sys/cminstall/src/config-no-install/: ALPHA_OSF Log message: initial version in slightly new form and stub out old one like others already are From jkrell at elego.de Sun Jun 6 17:08:39 2010 From: jkrell at elego.de (Jay Krell) Date: Sun, 6 Jun 2010 17:08:39 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100606150839.1693E2474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/06/06 17:08:39 Modified files: cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c Log message: #ifdef HAVE_GAS_HIDDEN /* otherwise varasm.c warns: "visibility attribute not supported in this configuration; ignored" */ From jkrell at elego.de Sun Jun 6 17:25:42 2010 From: jkrell at elego.de (Jay Krell) Date: Sun, 6 Jun 2010 17:25:42 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100606152542.B7F312474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/06/06 17:25:42 Modified files: cm3/m3-libs/m3core/src/thread/Common/: ThreadInternal.c Log message: 'except' is keyword on OSF/1, use 'xcept' instead From jkrell at elego.de Sun Jun 6 17:49:28 2010 From: jkrell at elego.de (Jay Krell) Date: Sun, 6 Jun 2010 17:49:28 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100606154929.1D8882474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/06/06 17:49:28 Modified files: cm3/m3-libs/m3core/src/: m3core.h Log message: #ifdef __osf__ #ifndef _OSF_SOURCE #define _OSF_SOURCE #endif #ifndef _XOPEN_SOURCE #define _XOPEN_SOURCE 500 #endif #endif remove manual OSF/1 socklen_t I tried a few combinations. Without any #defines, socket.h omits stuff like recvfrom. If you just #define _XOPEN_SOURCE, then struct tm is missing the BSD members, which you can then handle with #ifdef, but I think socket.h was still missing stuff, I forgot. This works and is reasonable. From jkrell at elego.de Sun Jun 6 17:51:35 2010 From: jkrell at elego.de (Jay Krell) Date: Sun, 6 Jun 2010 17:51:35 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100606155135.B1C7D2474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/06/06 17:51:35 Modified files: cm3/m3-libs/m3core/src/time/POSIX/: DatePosixC.c Log message: add comment about OSF/1 From jkrell at elego.de Sun Jun 6 17:55:29 2010 From: jkrell at elego.de (Jay Krell) Date: Sun, 6 Jun 2010 17:55:29 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100606155529.DBA02CC37F@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/06/06 17:55:29 Modified files: cm3/scripts/python/: pylib.py Log message: pylib.py From jkrell at elego.de Sun Jun 6 18:00:54 2010 From: jkrell at elego.de (Jay Krell) Date: Sun, 6 Jun 2010 18:00:54 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100606160054.203E72474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/06/06 18:00:54 Modified files: cm3/scripts/python/: pylib.py Log message: failed to comment previous due to wrong cvs command line: adapt for ALPHA_OSF: use /usr/bin/cc -g, specifically -fPIC causes the error, like, "-g2 invalid hex number" or such, I think -fPIC means something else, and I think there is only one model on ALPHA_OSF anyway and it is PIC (consistent with Digital generally doing things better, and PIC being optional not a useful idea in general: proliferation of unnecessary and uncompatible options) switch Solaris to "big PIC" instead of "small PIC" Bad enough that there is PIC and non-PIC, add to the mix having to chose big PIC or small PIC! Ugh. Small PIC is more efficient but doesn't always work, and you don't know until you link, at And it doesn't work because of yet other poor ABI design, the general defaulting of everything to be external to the .so.. You get to go back and recompile some/all files.. There should be just one model and it should just work. The processor and the ABI should be designed together so that it is reasonably efficient. If there are, say, 32bit limits, then the linker should be able to fix things up, like, for tangential example, creation of branch islands. From jay.krell at cornell.edu Sun Jun 6 18:03:20 2010 From: jay.krell at cornell.edu (Jay K) Date: Sun, 6 Jun 2010 16:03:20 +0000 Subject: [M3commit] CVS Update: cm3 In-Reply-To: <20100606154929.1D8882474003@birch.elegosoft.com> References: <20100606154929.1D8882474003@birch.elegosoft.com> Message-ID: ?>> but I think socket.h was still missing stuff, I forgot. Some combinations resulted in missing u_char, u_short, u_int, u_long, and MachineIDPosixC.c not compiling. ?- Jay ---------------------------------------- > Date: Sun, 6 Jun 2010 17:49:28 +0000 > To: m3commit at elegosoft.com > From: jkrell at elego.de > Subject: [M3commit] CVS Update: cm3 > > CVSROOT: /usr/cvs > Changes by: jkrell at birch. 10/06/06 17:49:28 > > Modified files: > cm3/m3-libs/m3core/src/: m3core.h > > Log message: > #ifdef __osf__ > #ifndef _OSF_SOURCE > #define _OSF_SOURCE > #endif > #ifndef _XOPEN_SOURCE > #define _XOPEN_SOURCE 500 > #endif > #endif > > remove manual OSF/1 socklen_t > > I tried a few combinations. > Without any #defines, socket.h omits stuff like recvfrom. > If you just #define _XOPEN_SOURCE, then struct tm is missing the BSD members, > which you can then handle with #ifdef, but I think socket.h > was still missing stuff, I forgot. This works and is reasonable. > From jkrell at elego.de Sun Jun 6 22:46:15 2010 From: jkrell at elego.de (Jay Krell) Date: Sun, 6 Jun 2010 22:46:15 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100606204616.DD9152474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/06/06 22:46:15 Modified files: cm3/m3-libs/m3core/src/time/POSIX/: TimePosixC.c Log message: Three calls to ComputeGrainOnce take a long time to coincide on OSF/1 so only use two. This area seems a bit weak and in need of more attention. From jkrell at elego.de Sun Jun 6 23:07:48 2010 From: jkrell at elego.de (Jay Krell) Date: Sun, 6 Jun 2010 23:07:48 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100606210748.3F4372474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/06/06 23:07:48 Modified files: cm3/m3-libs/m3core/src/runtime/: m3makefile Log message: remove three newlines From jkrell at elego.de Sun Jun 6 23:09:52 2010 From: jkrell at elego.de (Jay Krell) Date: Sun, 6 Jun 2010 23:09:52 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100606210952.799952474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/06/06 23:09:52 Modified files: cm3/m3-libs/m3core/src/runtime/: m3makefile Log message: disable ALPHA_OSF stack walker here too 'for now' From jkrell at elego.de Sun Jun 6 23:11:32 2010 From: jkrell at elego.de (Jay Krell) Date: Sun, 6 Jun 2010 23:11:32 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100606211132.2E0742474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/06/06 23:11:32 Added files: cm3/m3-libs/m3core/src/C/ALPHA_OSF/: Csetjmp.i3 m3makefile Log message: restore ALPHA_OSF/Csetjmp.i3 From jkrell at elego.de Sun Jun 6 23:11:56 2010 From: jkrell at elego.de (Jay Krell) Date: Sun, 6 Jun 2010 23:11:56 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100606211156.EB9702474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/06/06 23:11:56 Modified files: cm3/m3-libs/m3core/src/: m3core.h cm3/m3-libs/m3core/src/time/POSIX/: DatePosixC.c TimePosixC.c cm3/m3-libs/m3core/src/unix/Common/: UtimeC.c Log message: use 64bit time_t (time64_t) on ALPHA_OSF From jay.krell at cornell.edu Sun Jun 6 23:13:01 2010 From: jay.krell at cornell.edu (Jay K) Date: Sun, 6 Jun 2010 21:13:01 +0000 Subject: [M3commit] CVS Update: cm3 In-Reply-To: <20100606211156.EB9702474003@birch.elegosoft.com> References: <20100606211156.EB9702474003@birch.elegosoft.com> Message-ID: ---------------------------------------- > Date: Sun, 6 Jun 2010 23:11:56 +0000 > To: m3commit at elegosoft.com > From: jkrell at elego.de > Subject: [M3commit] CVS Update: cm3 > > CVSROOT: /usr/cvs > Changes by: jkrell at birch. 10/06/06 23:11:56 > > Modified files: > cm3/m3-libs/m3core/src/: m3core.h > cm3/m3-libs/m3core/src/time/POSIX/: DatePosixC.c TimePosixC.c > cm3/m3-libs/m3core/src/unix/Common/: UtimeC.c > > Log message: > use 64bit time_t (time64_t) on ALPHA_OSF > -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: time64.txt URL: From jkrell at elego.de Sun Jun 6 23:57:15 2010 From: jkrell at elego.de (Jay Krell) Date: Sun, 6 Jun 2010 23:57:15 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100606215715.2CF862474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/06/06 23:57:15 Modified files: cm3/scripts/python/: pylib.py Log message: remove spaces in assembler command line too, share code to do so From jkrell at elego.de Mon Jun 7 00:15:19 2010 From: jkrell at elego.de (Jay Krell) Date: Mon, 7 Jun 2010 0:15:19 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100606221520.284C92474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/06/07 00:15:19 Modified files: cm3/scripts/python/: pylib.py Log message: fix From jkrell at elego.de Mon Jun 7 00:15:47 2010 From: jkrell at elego.de (Jay Krell) Date: Mon, 7 Jun 2010 0:15:47 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100606221547.E6E2F2474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/06/07 00:15:47 Modified files: cm3/scripts/python/: pylib.py Log message: comments From jkrell at elego.de Mon Jun 7 00:37:51 2010 From: jkrell at elego.de (Jay Krell) Date: Mon, 7 Jun 2010 0:37:51 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100606223752.4455A2474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/06/07 00:37:51 Modified files: cm3/scripts/python/: pylib.py Log message: put version and timestamp, in boot and distribution archive names From jkrell at elego.de Mon Jun 7 03:25:12 2010 From: jkrell at elego.de (Jay Krell) Date: Mon, 7 Jun 2010 3:25:12 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100607012512.BBD712474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/06/07 03:25:12 Modified files: cm3/scripts/python/: pylib.py Log message: support ALPHA_OSF host From jkrell at elego.de Wed Jun 9 19:20:18 2010 From: jkrell at elego.de (Jay Krell) Date: Wed, 9 Jun 2010 19:20:18 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100609172018.79E7F2474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/06/09 19:20:18 Modified files: cm3/m3-libs/m3core/src/unix/Common/: Uexec.c Log message: Only call WEXITSTATUS if WIFEXITED. Only call WTERMSIG if WIFSIGNALED. Otherwise we get -1 and a subrange violation on OSF/1, due to: /* evaluates to the low-order 8 bits of the child exit status */ #define WEXITSTATUS(x) (WIFEXITED(x) ? ((_W_INT(x) >> 8) & 0377) : -1) /* evaluates to a non-zero value if status returned for abnormal termination */ #define WIFSIGNALED(x) (_WSTATUS(x) != _WSTOPPED && _WSTATUS(x) != 0) /* evaluates to the number of the signal that caused the child to terminate */ #define WTERMSIG(x) (WIFSIGNALED(x) ? _WSTATUS(x) : -1) and a careful read of Posix validates this change. They don't say what WEXITSTATUS and WTERMSIG do if WIFEXITED, WIFSIGNALED are false, only if true. From jay.krell at cornell.edu Wed Jun 9 19:23:31 2010 From: jay.krell at cornell.edu (Jay K) Date: Wed, 9 Jun 2010 17:23:31 +0000 Subject: [M3commit] CVS Update: cm3 In-Reply-To: <20100609172018.79E7F2474003@birch.elegosoft.com> References: <20100609172018.79E7F2474003@birch.elegosoft.com> Message-ID: attached ALPHA_OSF can now (again) get at least as far as starting to build natively in m3-sys/m3cc..waiting.. (stack walker disabled, granted) ?- Jay ---------------------------------------- > Date: Wed, 9 Jun 2010 19:20:18 +0000 > To: m3commit at elegosoft.com > From: jkrell at elego.de > Subject: [M3commit] CVS Update: cm3 > > CVSROOT: /usr/cvs > Changes by: jkrell at birch. 10/06/09 19:20:18 > > Modified files: > cm3/m3-libs/m3core/src/unix/Common/: Uexec.c > > Log message: > Only call WEXITSTATUS if WIFEXITED. > Only call WTERMSIG if WIFSIGNALED. > Otherwise we get -1 and a subrange violation on OSF/1, due to: > /* evaluates to the low-order 8 bits of the child exit status */ > #define WEXITSTATUS(x) (WIFEXITED(x) ? ((_W_INT(x)>> 8) & 0377) : -1) > /* evaluates to a non-zero value if status returned for abnormal termination */ > #define WIFSIGNALED(x) (_WSTATUS(x) != _WSTOPPED && _WSTATUS(x) != 0) > /* evaluates to the number of the signal that caused the child to terminate */ > #define WTERMSIG(x) (WIFSIGNALED(x) ? _WSTATUS(x) : -1) > > and a careful read of Posix validates this change. > They don't say what WEXITSTATUS and WTERMSIG do if WIFEXITED, WIFSIGNALED > are false, only if true. > -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: wait.txt URL: From jkrell at elego.de Wed Jun 9 20:32:31 2010 From: jkrell at elego.de (Jay Krell) Date: Wed, 9 Jun 2010 20:32:31 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100609183231.2154F2474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/06/09 20:32:31 Modified files: cm3/m3-sys/cminstall/src/config-no-install/: ALPHA_OSF Log message: use -pthread (not -lpthread) and -lm on compiler/linker From jkrell at elego.de Wed Jun 9 20:33:38 2010 From: jkrell at elego.de (Jay Krell) Date: Wed, 9 Jun 2010 20:33:38 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100609183339.BF092CC37F@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/06/09 20:33:38 Modified files: cm3/m3-sys/m3cc/src/: m3makefile Log message: disable mips-tfile pending research, seems to work without it, though gcc does do something similar here From jkrell at elego.de Wed Jun 9 22:32:48 2010 From: jkrell at elego.de (Jay Krell) Date: Wed, 9 Jun 2010 22:32:48 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100609203248.77A802474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/06/09 22:32:48 Modified files: cm3/m3-libs/m3core/src/unix/Common/: UtimeC.c Log message: missed a use of time_t in doing the 64bit time change for OSF/1 From jkrell at elego.de Sat Jun 12 12:13:27 2010 From: jkrell at elego.de (Jay Krell) Date: Sat, 12 Jun 2010 12:13:27 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100612101327.946CB2474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/06/12 12:13:27 Modified files: cm3/m3-libs/m3core/src/: thread.quake Log message: er, let's use pthreads on ALPHA_OSF, not doing so was just an accident by me, though it ought it work either way From jkrell at elego.de Sat Jun 12 16:04:41 2010 From: jkrell at elego.de (Jay Krell) Date: Sat, 12 Jun 2010 16:04:41 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100612140441.870E82474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/06/12 16:04:41 Modified files: cm3/scripts/python/: pylib.py Log message: use -nocpp on Alpha/OSF assembler, as the preprocessor isn't needed and Mika broke his by accident; running /usr/lib/cmplrs/cc/as0 directly is also viable, it is documented on the man page From jkrell at elego.de Sat Jun 12 16:07:02 2010 From: jkrell at elego.de (Jay Krell) Date: Sat, 12 Jun 2010 16:07:02 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100612140702.4411CCC37F@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/06/12 16:07:02 Modified files: cm3/scripts/python/: pylib.py Log message: run /usr/lib/cmplrs/cc/as0 directly on Alpha/OSF From jkrell at elego.de Sat Jun 12 16:09:17 2010 From: jkrell at elego.de (Jay Krell) Date: Sat, 12 Jun 2010 16:09:17 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100612140920.6EFD42474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/06/12 16:09:17 Modified files: cm3/m3-sys/cminstall/src/config-no-install/: ALPHA_OSF Log message: disable stack walker here too (is that what broke the self-built cm3? run /usr/lib/cmplrs/cc/as0 directly (hey I would not have noticed the stack walker change here so fast Mika not broken /usr/bin/as!) From jkrell at elego.de Sat Jun 12 16:41:45 2010 From: jkrell at elego.de (Jay Krell) Date: Sat, 12 Jun 2010 16:41:45 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100612144145.2A2BFCC37F@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/06/12 16:41:45 Modified files: cm3/m3-libs/m3core/src/thread/PTHREAD/: ThreadPThreadC.c Log message: Pick SIG_SUSPEND for Alpha/OSF1/Tru64. Otherwise pthreads fails to compile for it, due to picking a non-constant. Here are some of the choices: /usr/include/signal.h: #define SIGUSR1 30 /* user defined signal 1 */ #define SIGUSR2 31 /* user defined signal 2 */ #define SIGRTMIN (sysconf(131)) #define SIGRTMAX (sysconf(132)) bash-4.1$ ./a.out 33 48 #include #include int main(int argc, char** argv) { printf("%ld %ld\n", (long)SIGRTMIN, (long)SIGRTMAX); return 0; } Using 33, 48 seems dangerous -- does it vary per machine/OS version? Diff here is: <#elif defined(SIGRTMAX) && !defined(__osf__) >#elif defined(SIGRTMAX) && !defined(__osf__) /* This might be a function call, in which case try _SIGRTMAX or initializing it somewhere. */ EXTERN_CONST int SIG_SUSPEND = SIGRTMAX; #elif defined(SIGUSR2) EXTERN_CONST int SIG_SUSPEND = SIGUSR2; so we end up using SIGUSR2, which is the same as on Solaris and maybe others. Note that OSF/1 and Darwin share a common base in Mach. And therefore "direct suspend" is probably a good easy idea here? mach_suspend/resume are in the headers, but I haven't found how to get the mach thread for a pthread, or the current mach thread, to compare see if they match. I'm more comfortable using the common code though actually. esp. since I haven't written any of this. From jkrell at elego.de Sat Jun 12 16:48:14 2010 From: jkrell at elego.de (Jay Krell) Date: Sat, 12 Jun 2010 16:48:14 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100612144815.068972474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/06/12 16:48:14 Modified files: cm3/m3-libs/m3core/src/thread/PTHREAD/: ThreadPThreadC.c Log message: make ThreadPThread__RestartThread and ThreadPThread__SuspendThread, as Tru64 cc complains that they weren't returning anything. Note we are playing just slightly fast/loose here. They are declared as returning BOOLEAN in the *.i3 files. But these versions just abort() and should never be called. You know, like, sometimes there is a "noreturn" marker on abort, sometimes not. That's why other compilers haven't been warning here. From jkrell at elego.de Sat Jun 12 16:52:24 2010 From: jkrell at elego.de (Jay Krell) Date: Sat, 12 Jun 2010 16:52:24 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100612145224.451942474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/06/12 16:52:24 Modified files: cm3/m3-sys/cminstall/src/config-no-install/: ALPHA_OSF Log message: hm, looks like as0 has to be followed by as1 Just use as -nocpp. Need -lrt for nanosleep, sem_*, now that using pthreads. From jkrell at elego.de Sat Jun 12 16:54:35 2010 From: jkrell at elego.de (Jay Krell) Date: Sat, 12 Jun 2010 16:54:35 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100612145436.0F4CCCC37F@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/06/12 16:54:35 Modified files: cm3/scripts/python/: pylib.py Log message: back to /usr/bin/as -nocpp on Alpha/OSF From jkrell at elego.de Sat Jun 12 16:57:41 2010 From: jkrell at elego.de (Jay Krell) Date: Sat, 12 Jun 2010 16:57:41 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100612145741.EFB202474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/06/12 16:57:41 Modified files: cm3/m3-libs/m3core/src/: thread.quake Log message: empty out platform list, the default of true is correct for all current platforms except OpenBSD, which are left in the list From jay.krell at cornell.edu Sat Jun 12 17:01:18 2010 From: jay.krell at cornell.edu (Jay K) Date: Sat, 12 Jun 2010 15:01:18 +0000 Subject: [M3commit] CVS Update: cm3 In-Reply-To: <20100612144815.068972474003@birch.elegosoft.com> References: <20100612144815.068972474003@birch.elegosoft.com> Message-ID: This was supposed to say, make them "return void". ?- Jay ---------------------------------------- > Date: Sat, 12 Jun 2010 16:48:14 +0000 > To: m3commit at elegosoft.com > From: jkrell at elego.de > Subject: [M3commit] CVS Update: cm3 > > CVSROOT: /usr/cvs > Changes by: jkrell at birch. 10/06/12 16:48:14 > > Modified files: > cm3/m3-libs/m3core/src/thread/PTHREAD/: ThreadPThreadC.c > > Log message: > make ThreadPThread__RestartThread and ThreadPThread__SuspendThread, > as Tru64 cc complains that they weren't returning anything. > > Note we are playing just slightly fast/loose here. > They are declared as returning BOOLEAN in the *.i3 files. > But these versions just abort() and should never be called. > > You know, like, sometimes there is a "noreturn" marker > on abort, sometimes not. That's why other compilers > haven't been warning here. > From jkrell at elego.de Sat Jun 12 17:22:44 2010 From: jkrell at elego.de (Jay Krell) Date: Sat, 12 Jun 2010 17:22:44 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100612152244.8115B2474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/06/12 17:22:44 Modified files: cm3/m3-libs/m3core/src/: thread.quake cm3/m3-libs/m3core/src/thread/: m3makefile Log message: user threads are now very portable and rarely require per-target work, so we can remove the list of targets that don't offer them (I was rarely doing the work for any new target) (still, NT/Cygwin don't have them, that's encoded differently) From jkrell at elego.de Sat Jun 12 17:25:49 2010 From: jkrell at elego.de (Jay Krell) Date: Sat, 12 Jun 2010 17:25:49 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100612152549.32A4D2474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/06/12 17:25:49 Modified files: cm3/m3-libs/m3core/src/thread/PTHREAD/: ThreadPThreadC.c Log message: remove errant line in the OSF change From jkrell at elego.de Sat Jun 12 22:26:03 2010 From: jkrell at elego.de (Jay Krell) Date: Sat, 12 Jun 2010 22:26:03 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100612202603.D87322474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/06/12 22:26:03 Modified files: cm3/www/uploaded-archives/: targets.txt Log message: add ALPHA_OSF From jkrell at elego.de Sun Jun 13 04:48:54 2010 From: jkrell at elego.de (Jay Krell) Date: Sun, 13 Jun 2010 4:48:54 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100613024858.5BDE02474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/06/13 04:48:54 Modified files: cm3/m3-sys/cminstall/src/config-no-install/: ALPHA_OSF Unix.common Log message: -mieee is needed to support denormal floating point, such as m3-libs/m3core/src/float/IEEE/LongReal.i3 MinPos: T = 4.9406564584124654D-324; (* The minimum positive value in T. *) MinPosNormal: T = 2.2250738585072014D-308; (* The minimum positive "normal" value in T; differs from MinPos only for implementations with denormalized numbers. *) Otherwise MinPos is NaN and multiplication with it here: m3-libs/arithmetic/src/basictypes/float/FloatTrans.ig Tiny = R.MinPos * FLOAT(1000.0, T); (* nearly 0.0 *) issues a SIGFPE, when R = LongReal. I also wonder if maybe MinPos should be adjusted to be normal or ALPHA_OSF should do so (i.e. not use generic IEEE directory, e.g.: VAX/LongReal.i3: MinPos: T = 2.93873587705571880D-39; VAX/LongReal.i3: MinPosNormal: T = MinPos; ) Probably best to be like all the other architectures though, even if it costs some perf. You know, some people like floating point to be really really the same across all architectures..witness Java, Java -strictfp, and the lack of any Java for VAX. see: http://gcc.gnu.org/onlinedocs/gcc-4.5.0/gcc/DEC-Alpha-Options.html#DEC-Alpha-Options A program like this demontrates it, I think it was, from memory: int main() { long a = 0x3E8; /* NaN */ double b = *(double*)&a; double c = b * 1000;; return 0; } or: int main() { double a = 4.9406564584124654e-324; double b = a * 1000; return 0; } We should probably hardcode this in parse.c for Alpha instead of relying on the config files. From jay.krell at cornell.edu Sun Jun 13 04:50:40 2010 From: jay.krell at cornell.edu (Jay K) Date: Sun, 13 Jun 2010 02:50:40 +0000 Subject: [M3commit] CVS Update: cm3 In-Reply-To: <20100613024858.5BDE02474003@birch.elegosoft.com> References: <20100613024858.5BDE02474003@birch.elegosoft.com> Message-ID: Index: ALPHA_OSF =================================================================== RCS file: /usr/cvs/cm3/m3-sys/cminstall/src/config-no-install/ALPHA_OSF,v retrieving revision 1.4 diff -u -r1.4 ALPHA_OSF --- ALPHA_OSF??? 12 Jun 2010 14:52:24 -0000??? 1.4 +++ ALPHA_OSF??? 13 Jun 2010 02:48:19 -0000 @@ -61,6 +61,7 @@ ? ?m3back_pic = "" % It seems that -fPIC isn't needed!? cool. ?m3back_m64 = "" % -m64 not allowed +m3back_mieee = "-mieee" ? ?%--------------------------------------------------------------- C compiler --- ?% "compile_c" is called to compile C source files.? Note that this function Index: Unix.common =================================================================== RCS file: /usr/cvs/cm3/m3-sys/cminstall/src/config-no-install/Unix.common,v retrieving revision 1.62 diff -u -r1.62 Unix.common --- Unix.common??? 2 Jun 2010 11:12:03 -0000??? 1.62 +++ Unix.common??? 13 Jun 2010 02:48:19 -0000 @@ -80,11 +80,16 @@ ?? m3back_m64 = {"32BITS" : "", "64BITS" : "-m64"}{WORD_SIZE} ?end ? +if not defined("m3back_mieee") +? m3back_mieee = "" +end + ?proc m3_backend(source, object, optimize, debug) is ???? local args = [ "-quiet", ??????????????????? "-fno-reorder-blocks", ??????????????????? m3back_unwind_table, ??????????????????? m3back_pic, +?????????????????? m3back_mieee, ??????????????????? m3back_m32, ??????????????????? m3back_m64 ] ???? if optimize ---------------------------------------- > Date: Sun, 13 Jun 2010 04:48:54 +0000 > To: m3commit at elegosoft.com > From: jkrell at elego.de > Subject: [M3commit] CVS Update: cm3 > > CVSROOT: /usr/cvs > Changes by: jkrell at birch. 10/06/13 04:48:54 > > Modified files: > cm3/m3-sys/cminstall/src/config-no-install/: ALPHA_OSF > Unix.common > > Log message: > -mieee is needed to support denormal floating point, such > as m3-libs/m3core/src/float/IEEE/LongReal.i3 > MinPos: T = 4.9406564584124654D-324; > (* The minimum positive value in T. *) > > MinPosNormal: T = 2.2250738585072014D-308; > (* The minimum positive "normal" value in T; differs from MinPos > only for implementations with denormalized numbers. *) > > Otherwise MinPos is NaN and multiplication with it here: > > m3-libs/arithmetic/src/basictypes/float/FloatTrans.ig > Tiny = R.MinPos * FLOAT(1000.0, T); (* nearly 0.0 *) > > issues a SIGFPE, when R = LongReal. > > I also wonder if maybe MinPos should be adjusted to be normal > or ALPHA_OSF should do so (i.e. not use generic IEEE directory, e.g.: > VAX/LongReal.i3: MinPos: T = 2.93873587705571880D-39; > VAX/LongReal.i3: MinPosNormal: T = MinPos; > ) > > Probably best to be like all the other architectures though, > even if it costs some perf. You know, some people like floating point > to be really really the same across all architectures..witness > Java, Java -strictfp, and the lack of any Java for VAX. > > see: > http://gcc.gnu.org/onlinedocs/gcc-4.5.0/gcc/DEC-Alpha-Options.html#DEC-Alpha-Options > > A program like this demontrates it, I think it was, from memory: > > int main() > { > long a = 0x3E8; /* NaN */ > double b = *(double*)&a; > double c = b * 1000;; > return 0; > } > > or: > int main() > { > double a = 4.9406564584124654e-324; > double b = a * 1000; > return 0; > } > > We should probably hardcode this in parse.c for Alpha instead > of relying on the config files. > From jkrell at elego.de Sun Jun 13 05:05:43 2010 From: jkrell at elego.de (Jay Krell) Date: Sun, 13 Jun 2010 5:05:43 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100613030543.6D3A92474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/06/13 05:05:43 Modified files: cm3/m3-ui/jvideo/src/POSIX/: m3makefile Log message: Comment out the decision to use target specific code and just use the generic version, it does compile, whereas the osf1/decunix versions no longer do. Is the target specific version faster or did these systems previously not handle the generic version? Either I doubt it matters much, out here in jvideo. From jkrell at elego.de Sun Jun 13 06:54:53 2010 From: jkrell at elego.de (Jay Krell) Date: Sun, 13 Jun 2010 6:54:53 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100613045453.2920E2474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/06/13 06:54:53 Modified files: cm3/m3-sys/cminstall/src/config-no-install/: ALPHA_OSF Log message: solitaire needs -ldnet_stub (dnet=decnet, and this was already there in the old config file that I wasn't immediately copying everything from) From jkrell at elego.de Sun Jun 13 07:09:58 2010 From: jkrell at elego.de (Jay Krell) Date: Sun, 13 Jun 2010 7:09:58 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100613050958.E63AA2474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/06/13 07:09:58 Modified files: cm3/scripts/python/: upload.sh Log message: also upload *.tar.xz and *.tgz files, and also translate jayk to jkrell From jkrell at elego.de Sun Jun 13 07:11:32 2010 From: jkrell at elego.de (Jay Krell) Date: Sun, 13 Jun 2010 7:11:32 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100613051132.B94122474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/06/13 07:11:32 Modified files: cm3/scripts/python/: upload.sh Log message: also chmod 644 From jkrell at elego.de Sun Jun 13 07:47:41 2010 From: jkrell at elego.de (Jay Krell) Date: Sun, 13 Jun 2010 7:47:41 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100613054742.4ABE2CC389@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/06/13 07:47:41 Modified files: cm3/m3-sys/cminstall/src/config-no-install/: ALPHA_OSF Log message: improve cc options: -g -readonly_strings, -lm doesn't belong here From jkrell at elego.de Sun Jun 13 23:30:55 2010 From: jkrell at elego.de (Jay Krell) Date: Sun, 13 Jun 2010 23:30:55 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100613213055.CBC4A2474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/06/13 23:30:55 Modified files: cm3/m3-sys/m3cc/src/: m3makefile Log message: some comment editing and fitting in 80 columns From jkrell at elego.de Mon Jun 14 06:42:45 2010 From: jkrell at elego.de (Jay Krell) Date: Mon, 14 Jun 2010 6:42:45 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100614044245.F1AE82474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/06/14 06:42:45 Modified files: cm3/m3-sys/m3cc/src/: m3makefile Log message: build and ship mips-tfile, though it doesn't yet work for me It gives errors, same as the mips-tfile that building gcc gives me, when used against Modula-3, mips-tfile does get used and work with C. From jkrell at elego.de Mon Jun 14 07:25:39 2010 From: jkrell at elego.de (Jay Krell) Date: Mon, 14 Jun 2010 7:25:39 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100614052539.F200E2474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/06/14 07:25:39 Modified files: cm3/m3-sys/cminstall/src/config-no-install/: ALPHA_OSF Unix.common Log message: put the .so files in lib and symlink back from pkg like other Posix platforms all now do I kind of think we might as well move the .a files too. move options to SYSTEM_CC (-ieee_with_no_inexact, -pthread) more refinement of compile/link flags: -error_unresolved -readonly_strings run assembler with the same flags that gcc does: -g -oldas -c -O0 (and -nocpp) Neither -oldas nor -c are documented. Always using -g seems wrong, never -g0 or -g3, etc., but it seems to be what gcc always does, I tried a few different -g and -O parameters (compiling C) run mips-tfile Changing the flags to the assembler appears to have helped significantly here. Previously it was always issuing errors. Reading osf.h and osf5.h confirm this. Debugging is a little better now in gdb. m3gdb crashes if I just set a breakpoint. From jkrell at elego.de Mon Jun 14 23:16:39 2010 From: jkrell at elego.de (Jay Krell) Date: Mon, 14 Jun 2010 23:16:39 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100614211639.89E06CC382@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/06/14 23:16:39 Modified files: cm3/m3-sys/cminstall/src/config-no-install/: ALPHA_OSF Log message: always compile C with -O3 -g3 -g in particular inhibits optimization path -rpath to cc instead of -Wl,-rpath use -B symbolic I verified, even though this isn't really documented for cc, it does work. It is documented for ld. -B foo means something else for cc, but it appears to recognize -B symbolic. If in doubt, use -Wl,-B,symbolic or maybe -WL,-B,symbolic instead cleanup comments about shared remove SYSTEM_LD -- just always use SYSTEM_CC From jkrell at elego.de Wed Jun 16 09:16:58 2010 From: jkrell at elego.de (Jay Krell) Date: Wed, 16 Jun 2010 9:16:58 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100616071658.769162474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/06/16 09:16:58 Added files: cm3/doc/notes/: todo.txt Log message: record backlog From jkrell at elego.de Wed Jun 16 09:21:23 2010 From: jkrell at elego.de (Jay Krell) Date: Wed, 16 Jun 2010 9:21:23 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100616072123.9F0F02474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/06/16 09:21:23 Modified files: cm3/doc/notes/: porting.txt Log message: some updates esp. about user threads being much more portable now From jkrell at elego.de Wed Jun 16 09:23:41 2010 From: jkrell at elego.de (Jay Krell) Date: Wed, 16 Jun 2010 9:23:41 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100616072343.AE3D52474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/06/16 09:23:41 Modified files: cm3/doc/notes/: todo.txt Log message: more backlog: reduce C header cloning From jkrell at elego.de Wed Jun 16 09:30:17 2010 From: jkrell at elego.de (Jay Krell) Date: Wed, 16 Jun 2010 9:30:17 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100616073017.AE2A22474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/06/16 09:30:17 Modified files: cm3/m3-libs/m3core/src/unix/Common/: Usocket.c Log message: ZeroMemory is *perhaps* preferable to = { 0 } because: 1) it portable zeros all of a union 2) gcc warns about missing initializers Though really = { 0 } is imho a great terse portable syntax that isn't worth warning about, unless there is a union with not the largest first. From rodney at elego.de Wed Jun 16 16:12:26 2010 From: rodney at elego.de (Rodney M. Bates) Date: Wed, 16 Jun 2010 16:12:26 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100616141226.3B7EA2474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: rodney at birch. 10/06/16 16:12:26 Modified files: cm3/m3-sys/m3front/src/misc/: Scanner.m3 Log message: Complete case-insensitivity for: 1) 'w'/'W' to denote wide character and wide text literals 2) 'x'/'X' as hex escape inside character and text literals From jkrell at elego.de Sat Jun 19 06:51:10 2010 From: jkrell at elego.de (Jay Krell) Date: Sat, 19 Jun 2010 6:51:10 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100619045111.2C3632474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/06/19 06:51:10 Added files: cm3/m3-sys/cminstall/src/config-no-install/: ARMEL_LINUX Log message: initial config file for ARMEL_LINUX (e=embedded, l=little endian) From jkrell at elego.de Sat Jun 19 06:56:33 2010 From: jkrell at elego.de (Jay Krell) Date: Sat, 19 Jun 2010 6:56:33 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100619045633.3B3992474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/06/19 06:56:33 Modified files: cm3/m3-sys/m3middle/src/: Target.i3 Target.m3 Log message: add ARMEL_LINUX with correct jmbuf size/align guessing about alignment "ARM" is an older ABI "ARME" is the usual modern ABI L for little endian From jkrell at elego.de Sat Jun 19 06:57:58 2010 From: jkrell at elego.de (Jay Krell) Date: Sat, 19 Jun 2010 6:57:58 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100619045758.0DF422474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/06/19 06:57:58 Modified files: cm3/m3-libs/m3core/src/: platforms.quake Log message: add ARMEL_LINUX (not to be confused with Android/Bionic which I suspect might be different.. From jkrell at elego.de Sat Jun 19 07:10:13 2010 From: jkrell at elego.de (Jay Krell) Date: Sat, 19 Jun 2010 7:10:13 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100619051013.EF8AB2474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/06/19 07:10:13 Modified files: cm3/m3-sys/m3cc/src/: platforms.quake Log message: add ARMEL_LINUX=arm-linux-gnueabi From jkrell at elego.de Sat Jun 19 07:26:00 2010 From: jkrell at elego.de (Jay Krell) Date: Sat, 19 Jun 2010 7:26:00 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100619052600.D57B52474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/06/19 07:26:00 Modified files: cm3/m3-sys/m3cc/src/: m3makefile Log message: Always specify -target. in native builds, always specify -build and -host. This should provide for more consistency, though is also a bit experimental and unorthodox. From jkrell at elego.de Sat Jun 19 07:35:19 2010 From: jkrell at elego.de (Jay Krell) Date: Sat, 19 Jun 2010 7:35:19 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100619053520.45FB42474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/06/19 07:35:19 Modified files: cm3/m3-sys/m3cc/src/: gnucc.common m3makefile Log message: always specify -build, -host, -target, for cross and native consistent but experimenta/unorthodox Usually people let config.guess do all the work for native and always for build. Default build to host, not target. From jkrell at elego.de Sat Jun 19 07:50:51 2010 From: jkrell at elego.de (Jay Krell) Date: Sat, 19 Jun 2010 7:50:51 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100619055052.45354CC38A@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/06/19 07:50:51 Added files: cm3/m3-libs/m3core/src/C/ARMEL_LINUX/: m3makefile Log message: add ARMEL_LINUX (really want to get rid of this stuff..compiler should inject it..) From jkrell at elego.de Sat Jun 19 10:26:59 2010 From: jkrell at elego.de (Jay Krell) Date: Sat, 19 Jun 2010 10:26:59 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100619082659.15A582474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/06/19 10:26:59 Modified files: cm3/m3-libs/m3core/src/Csupport/Common/: hand.c Log message: add m3_modL for ARM, it seems to need it From jkrell at elego.de Sat Jun 19 10:38:24 2010 From: jkrell at elego.de (Jay Krell) Date: Sat, 19 Jun 2010 10:38:24 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100619083824.740662474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/06/19 10:38:24 Modified files: cm3/m3-libs/m3core/src/Csupport/Common/: hand.c Log message: leave it called m3_div64 instead of m3_divL From jay.krell at cornell.edu Sat Jun 19 10:39:14 2010 From: jay.krell at cornell.edu (Jay K) Date: Sat, 19 Jun 2010 08:39:14 +0000 Subject: [M3commit] CVS Update: cm3 In-Reply-To: <20100619082659.15A582474003@birch.elegosoft.com> References: <20100619082659.15A582474003@birch.elegosoft.com> Message-ID: Meant to say add *back*. ?- Jay ---------------------------------------- > Date: Sat, 19 Jun 2010 10:26:59 +0000 > To: m3commit at elegosoft.com > From: jkrell at elego.de > Subject: [M3commit] CVS Update: cm3 > > CVSROOT: /usr/cvs > Changes by: jkrell at birch. 10/06/19 10:26:59 > > Modified files: > cm3/m3-libs/m3core/src/Csupport/Common/: hand.c > > Log message: > add m3_modL for ARM, it seems to need it > From jay.krell at cornell.edu Sat Jun 19 10:39:46 2010 From: jay.krell at cornell.edu (Jay K) Date: Sat, 19 Jun 2010 08:39:46 +0000 Subject: [M3commit] CVS Update: cm3 In-Reply-To: <20100619083824.740662474003@birch.elegosoft.com> References: <20100619083824.740662474003@birch.elegosoft.com> Message-ID: er. mod64/modL, not div64/divL ?- Jay ---------------------------------------- > Date: Sat, 19 Jun 2010 10:38:24 +0000 > To: m3commit at elegosoft.com > From: jkrell at elego.de > Subject: [M3commit] CVS Update: cm3 > > CVSROOT: /usr/cvs > Changes by: jkrell at birch. 10/06/19 10:38:24 > > Modified files: > cm3/m3-libs/m3core/src/Csupport/Common/: hand.c > > Log message: > leave it called m3_div64 instead of m3_divL > From jkrell at elego.de Sat Jun 19 10:56:58 2010 From: jkrell at elego.de (Jay Krell) Date: Sat, 19 Jun 2010 10:56:58 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100619085658.AA95C2474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/06/19 10:56:58 Modified files: cm3/m3-libs/libm3/src/: platforms.quake Log message: add ARMEL_LINUX From jkrell at elego.de Sat Jun 19 11:01:20 2010 From: jkrell at elego.de (Jay Krell) Date: Sat, 19 Jun 2010 11:01:20 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100619090120.255072474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/06/19 11:01:20 Modified files: cm3/m3-sys/cminstall/src/config-no-install/: ARMEL_LINUX Log message: -m32 not allowed here (probably needed for ARM_DARWIN too) From jkrell at elego.de Sat Jun 19 11:03:53 2010 From: jkrell at elego.de (Jay Krell) Date: Sat, 19 Jun 2010 11:03:53 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100619090353.B59352474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/06/19 11:03:53 Modified files: cm3/m3-sys/m3cc/gcc/gcc/config/arm/: arm.h cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c Log message: use a function call for 64bit mod on ARM, the backend crashes otherwise #if 0'ed out possibly slightly better code From jay.krell at cornell.edu Sat Jun 19 11:07:54 2010 From: jay.krell at cornell.edu (Jay K) Date: Sat, 19 Jun 2010 09:07:54 +0000 Subject: [M3commit] CVS Update: cm3 In-Reply-To: <20100619090353.B59352474003@birch.elegosoft.com> References: <20100619090353.B59352474003@birch.elegosoft.com> Message-ID: diff attached ---------------------------------------- > Date: Sat, 19 Jun 2010 11:03:53 +0000 > To: m3commit at elegosoft.com > From: jkrell at elego.de > Subject: [M3commit] CVS Update: cm3 > > CVSROOT: /usr/cvs > Changes by: jkrell at birch. 10/06/19 11:03:53 > > Modified files: > cm3/m3-sys/m3cc/gcc/gcc/config/arm/: arm.h > cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c > > Log message: > use a function call for 64bit mod on ARM, the backend crashes otherwise > #if 0'ed out possibly slightly better code > -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: arm1.txt URL: From jkrell at elego.de Sat Jun 19 11:17:03 2010 From: jkrell at elego.de (Jay Krell) Date: Sat, 19 Jun 2010 11:17:03 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100619091703.B6F752474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/06/19 11:17:03 Modified files: cm3/scripts/python/: pylib.py Log message: add ARMEL, change ?= to = avoid any confusion, edit the Makefile if it is wrong From jkrell at elego.de Sat Jun 19 11:20:25 2010 From: jkrell at elego.de (Jay Krell) Date: Sat, 19 Jun 2010 11:20:25 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100619092025.D39DD2474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/06/19 11:20:25 Modified files: cm3/scripts/python/: pylib.py Log message: add GnuPlatformPrefix{ARMEL_LINUX} = arm-linux-gnueabi-; aka use cross tools by default, since that is what I currently have From jkrell at elego.de Sat Jun 19 11:24:10 2010 From: jkrell at elego.de (Jay Krell) Date: Sat, 19 Jun 2010 11:24:10 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100619092410.0B9D62474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/06/19 11:24:10 Modified files: cm3/m3-libs/m3core/src/runtime/POSIX/: RTSignalC.c Log message: add Linux/arm (probably works for all Linux/arm variants) From jkrell at elego.de Sat Jun 19 11:26:47 2010 From: jkrell at elego.de (Jay Krell) Date: Sat, 19 Jun 2010 11:26:47 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100619092647.960352474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/06/19 11:26:47 Modified files: cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c Log message: oops From jkrell at elego.de Sat Jun 19 11:31:11 2010 From: jkrell at elego.de (Jay Krell) Date: Sat, 19 Jun 2010 11:31:11 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100619093111.4E77E2474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/06/19 11:31:11 Modified files: cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c Log message: #include tm_p.h to fix warning From jkrell at elego.de Sat Jun 19 11:37:20 2010 From: jkrell at elego.de (Jay Krell) Date: Sat, 19 Jun 2010 11:37:20 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100619093720.7B93B2474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/06/19 11:37:20 Modified files: cm3/scripts/python/: pylib.py Log message: no --32 for ARM assembler -- this bit is a bit of a mess and probably should just have a table for the remaining architectures that do accept --64 or --32 From jkrell at elego.de Sat Jun 19 11:38:45 2010 From: jkrell at elego.de (Jay Krell) Date: Sat, 19 Jun 2010 11:38:45 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100619093845.7F4022474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/06/19 11:38:45 Modified files: cm3/scripts/python/: pylib.py Log message: oops: remove double gnu platform prefix from linker From jkrell at elego.de Sat Jun 19 11:44:56 2010 From: jkrell at elego.de (Jay Krell) Date: Sat, 19 Jun 2010 11:44:56 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100619094456.4DA1E2474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/06/19 11:44:56 Modified files: cm3/m3-libs/m3core/src/atomic/: m3makefile Log message: remove all atomics on ARMEL_LINUX -- gcc 4.5 does implement them though.. From jkrell at elego.de Sat Jun 19 12:03:26 2010 From: jkrell at elego.de (Jay Krell) Date: Sat, 19 Jun 2010 12:03:26 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100619100326.372AB2474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/06/19 12:03:26 Modified files: cm3/m3-libs/m3core/src/unix/: m3makefile Log message: forgot to commit ARMEL_LINUX line here From jkrell at elego.de Sat Jun 19 12:04:03 2010 From: jkrell at elego.de (Jay Krell) Date: Sat, 19 Jun 2010 12:04:03 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100619100403.F09092474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/06/19 12:04:03 Modified files: cm3/m3-libs/m3core/src/runtime/common/: Compiler.tmpl Log message: forgot to commit ARMEL_LINUX line here From jkrell at elego.de Mon Jun 21 07:05:56 2010 From: jkrell at elego.de (Jay Krell) Date: Mon, 21 Jun 2010 7:05:56 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100621050557.39AB62474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/06/21 07:05:56 Modified files: cm3/m3-libs/m3core/src/Csupport/Common/: hand.c Log message: add back all four div/mod helpers for Posix, through rewritten to use unsigned arithmetic and not depend on silent signed wraparound Floor div/mod is a fairly target-specific and under used part of gcc and I am now nervous to depend upon it. Perhaps do more research though and trust it. From jkrell at elego.de Mon Jun 21 08:05:55 2010 From: jkrell at elego.de (Jay Krell) Date: Mon, 21 Jun 2010 8:05:55 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100621060555.B56FACC10F@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/06/21 08:05:55 Modified files: cm3/m3-sys/m3cc/gcc/gcc/config/: darwin-protos.h Log message: forward declare enum machine_mode to fix warningu From jkrell at elego.de Mon Jun 21 08:12:11 2010 From: jkrell at elego.de (Jay Krell) Date: Mon, 21 Jun 2010 8:12:11 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100621061211.6358C2474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/06/21 08:12:11 Modified files: cm3/m3-sys/m3cc/gcc/gcc/config/arm/: arm.h cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c Log message: put div/mod back to long standing and release form: almost always call a function, unless both parameters known to be positive or the type is unsigned Modula-3 very unfortunately defines div/mod differently than pretty much everyone else. Perhaps perhaps the language definition can be repaired. It turns out there are several reasonable definitions of div and mod. Modula-3 doesn't chose the obvious correct one and C doesn't chose the obvious incorrect one. We may yet be able to use the gcc support but it makes me nervous. It requires at least in a very minimal sense, for the frontend to support TImode (aka int128_t). See: http://gcc.gnu.org/ml/gcc/2010-06/msg00647.html (which is just from me, talking to myself..) From jkrell at elego.de Mon Jun 21 08:26:41 2010 From: jkrell at elego.de (Jay Krell) Date: Mon, 21 Jun 2010 8:26:41 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100621062641.C21EBCC10F@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/06/21 08:26:41 Modified files: cm3/m3-sys/m3cc/gcc-4.5/gcc/: final.c ira-conflicts.c loop-iv.c lower-subreg.c sel-sched-dump.c sel-sched.c Log message: Fix warnings about possible use of uninitialized locals by very clearly initializing them (as all locals should probably be). See bug: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44600 which again, is basically me talking to myself.. From jkrell at elego.de Mon Jun 21 09:57:13 2010 From: jkrell at elego.de (Jay Krell) Date: Mon, 21 Jun 2010 9:57:13 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100621075714.089CACC10F@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/06/21 09:57:13 Modified files: cm3/m3-sys/m3tests/src/: m3makefile Added files: cm3/m3-sys/m3tests/src/p2/p238/: Main.m3 m3makefile stdout.pgm Log message: add 'man vs. boy' aka nested procedures+recursion aka static chain test From jkrell at elego.de Mon Jun 21 10:11:27 2010 From: jkrell at elego.de (Jay Krell) Date: Mon, 21 Jun 2010 10:11:27 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100621081129.E9A21CC110@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/06/21 10:11:27 Added files: cm3/m3-sys/m3tests/src/p2/p238/: man-or-boy.c Log message: initial version from http://rosettacode.org/wiki/Man_or_boy_test that requires C9x and reuses identifiers in a confusing way From jkrell at elego.de Mon Jun 21 10:20:04 2010 From: jkrell at elego.de (Jay Krell) Date: Mon, 21 Jun 2010 10:20:04 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100621082004.B9F752474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/06/21 10:20:04 Modified files: cm3/m3-sys/m3tests/src/p2/p238/: man-or-boy.c Log message: before: type ARG and macro ARG; after: type ARG and macro MAKE_ARG; should be less confusing From jkrell at elego.de Mon Jun 21 10:31:47 2010 From: jkrell at elego.de (Jay Krell) Date: Mon, 21 Jun 2010 10:31:47 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100621083148.6D36F2474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/06/21 10:31:47 Modified files: cm3/m3-sys/m3tests/src/p2/p238/: man-or-boy.c Log message: remove C9x dependency From rodney_bates at lcwb.coop Tue Jun 22 03:07:04 2010 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Mon, 21 Jun 2010 20:07:04 -0500 Subject: [M3commit] CVS Update: cm3 In-Reply-To: <20100621061211.6358C2474003@birch.elegosoft.com> References: <20100621061211.6358C2474003@birch.elegosoft.com> Message-ID: <4C200CB8.7070809@lcwb.coop> Jay Krell wrote: > CVSROOT: /usr/cvs > Changes by: jkrell at birch. 10/06/21 08:12:11 > > Modified files: > cm3/m3-sys/m3cc/gcc/gcc/config/arm/: arm.h > cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c > > Log message: > put div/mod back to long standing and release form: > almost always call a function, unless both parameters known > to be positive or the type is unsigned > > Modula-3 very unfortunately defines div/mod differently than > pretty much everyone else. Perhaps perhaps the language > definition can be repaired. No, the language is correct. This is the mathematically correct definition of mod/div. We can be thankful that at least one language actually got it right. Moreover, the mathematicians knew what they were doing. Try some example coding with, e.g., arrays as circular buffers, using mod/div to increment/decrement your way around them. So many times in other languages, I have struggled with the frustration of having to write overcomplicated code to compensate for incorrect mod/div in other than the first quadrant. C is particularly exasperating, because it doesn't define them at all outside the first quadrant. It is implementor's option. This means these operators are entirely unusable for code that needs to be the least bit portable--even different compilers on the same machine. You always have to adjust your operands to first quadrant, do the operation, and then readjust. In Modula-3, you just do the operation. It turns out there are several > reasonable definitions of div and mod. Modula-3 doesn't > chose the obvious correct one and C doesn't chose the > obvious incorrect one. > > We may yet be able to use the gcc support but it makes me nervous. > It requires at least in a very minimal sense, for the frontend > to support TImode (aka int128_t). > > See: http://gcc.gnu.org/ml/gcc/2010-06/msg00647.html > (which is just from me, talking to myself..) > > From jay.krell at cornell.edu Tue Jun 22 03:32:23 2010 From: jay.krell at cornell.edu (Jay K) Date: Tue, 22 Jun 2010 01:32:23 +0000 Subject: [M3commit] CVS Update: cm3 In-Reply-To: <4C200CB8.7070809@lcwb.coop> References: <20100621061211.6358C2474003@birch.elegosoft.com>, <4C200CB8.7070809@lcwb.coop> Message-ID: I researched this -- searched the web, read Wikipedia, etc..I realize that calling "research" may be an exaggeration. There are approximately four reasonable definitions of div and mod for negative numbers. The most important thing is that div and mod are defined in terms of each other, in all variations, but that doesn't actually pin it down. There is round up (toward positive infinity), round down (toward negative infinity), toward 0 (truncation), there is Euclidean way. One might expect n mod m to be in the range [0,m), or perhaps the absolute value to be in [0,m), but I think Modula-3 doesn't make that so. It is surprising imho for mod to be outside that range. C89 left it undefined. So implementor could pick whatever was fastest/easiest. Fortran specified truncation. Nobody complained. C99 adopted Fortran's definition. So it is well defined now. Negative numbers are overused anyway. Everyone defines it the same for positive numbers, and that's generally sufficient anyway. As well C's ldiv function was explicitly defined to be truncating and therefore portable. (Notice that Modula-3's implementation was long broken for other reasons as well: It dependended on silent overflow, which gcc can warn about and break, and it didn't work for maximum/minimal numbers.) - Jay ---------------------------------------- > Date: Mon, 21 Jun 2010 20:07:04 -0500 > From: rodney_bates at lcwb.coop > To: m3commit at elegosoft.com > Subject: Re: [M3commit] CVS Update: cm3 > > > > Jay Krell wrote: >> CVSROOT: /usr/cvs >> Changes by: jkrell at birch. 10/06/21 08:12:11 >> >> Modified files: >> cm3/m3-sys/m3cc/gcc/gcc/config/arm/: arm.h >> cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c >> >> Log message: >> put div/mod back to long standing and release form: >> almost always call a function, unless both parameters known >> to be positive or the type is unsigned >> >> Modula-3 very unfortunately defines div/mod differently than >> pretty much everyone else. Perhaps perhaps the language >> definition can be repaired. > > No, the language is correct. This is the mathematically correct definition > of mod/div. We can be thankful that at least one language actually got it > right. Moreover, the mathematicians knew what they were doing. Try some > example coding with, e.g., arrays as circular buffers, using mod/div to > increment/decrement your way around them. So many times in other languages, > I have struggled with the frustration of having to write overcomplicated code > to compensate for incorrect mod/div in other than the first quadrant. > > C is particularly exasperating, because it doesn't define them at all outside > the first quadrant. It is implementor's option. This means these operators > are entirely unusable for code that needs to be the least bit portable--even > different compilers on the same machine. You always have to adjust your > operands to first quadrant, do the operation, and then readjust. > > In Modula-3, you just do the operation. > > It turns out there are several >> reasonable definitions of div and mod. Modula-3 doesn't >> chose the obvious correct one and C doesn't chose the >> obvious incorrect one. >> >> We may yet be able to use the gcc support but it makes me nervous. >> It requires at least in a very minimal sense, for the frontend >> to support TImode (aka int128_t). >> >> See: http://gcc.gnu.org/ml/gcc/2010-06/msg00647.html >> (which is just from me, talking to myself..) >> >> From hosking at cs.purdue.edu Tue Jun 22 03:35:52 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 21 Jun 2010 21:35:52 -0400 Subject: [M3commit] CVS Update: cm3 In-Reply-To: References: <20100621061211.6358C2474003@birch.elegosoft.com>, <4C200CB8.7070809@lcwb.coop> Message-ID: <0D1E563C-4499-404A-B4FB-9B27556581BA@cs.purdue.edu> On 21 Jun 2010, at 21:32, Jay K wrote: > > I researched this -- searched the web, read Wikipedia, etc..I realize that calling "research" may be an exaggeration. > There are approximately four reasonable definitions of div and mod for negative numbers. > > > The most important thing is that div and mod are defined in terms of each other, in all variations, but that doesn't actually pin it down. > > > There is round up (toward positive infinity), round down (toward negative infinity), toward 0 (truncation), there is Euclidean way. > > > One might expect n mod m to be in the range [0,m), or perhaps the absolute value to be in [0,m), but I think Modula-3 doesn't make that so. It is surprising imho for mod to be outside that range. > > > > C89 left it undefined. So implementor could pick whatever was fastest/easiest. > Fortran specified truncation. Nobody complained. > C99 adopted Fortran's definition. > So it is well defined now. > Negative numbers are overused anyway. > Everyone defines it the same for positive numbers, and that's generally sufficient anyway. But not if you can index arrays using negative indexes as in Modula-3. C, Fortran, etc. don't have this feature so they can get it wrong and nobody will notice. > > > > As well C's ldiv function was explicitly defined to be truncating and therefore portable. > > > > (Notice that Modula-3's implementation was long broken for other reasons as well: It dependended on silent overflow, which gcc can warn about and break, and it didn't work for maximum/minimal numbers.) > > > - Jay > > > ---------------------------------------- >> Date: Mon, 21 Jun 2010 20:07:04 -0500 >> From: rodney_bates at lcwb.coop >> To: m3commit at elegosoft.com >> Subject: Re: [M3commit] CVS Update: cm3 >> >> >> >> Jay Krell wrote: >>> CVSROOT: /usr/cvs >>> Changes by: jkrell at birch. 10/06/21 08:12:11 >>> >>> Modified files: >>> cm3/m3-sys/m3cc/gcc/gcc/config/arm/: arm.h >>> cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c >>> >>> Log message: >>> put div/mod back to long standing and release form: >>> almost always call a function, unless both parameters known >>> to be positive or the type is unsigned >>> >>> Modula-3 very unfortunately defines div/mod differently than >>> pretty much everyone else. Perhaps perhaps the language >>> definition can be repaired. >> >> No, the language is correct. This is the mathematically correct definition >> of mod/div. We can be thankful that at least one language actually got it >> right. Moreover, the mathematicians knew what they were doing. Try some >> example coding with, e.g., arrays as circular buffers, using mod/div to >> increment/decrement your way around them. So many times in other languages, >> I have struggled with the frustration of having to write overcomplicated code >> to compensate for incorrect mod/div in other than the first quadrant. >> >> C is particularly exasperating, because it doesn't define them at all outside >> the first quadrant. It is implementor's option. This means these operators >> are entirely unusable for code that needs to be the least bit portable--even >> different compilers on the same machine. You always have to adjust your >> operands to first quadrant, do the operation, and then readjust. >> >> In Modula-3, you just do the operation. >> >> It turns out there are several >>> reasonable definitions of div and mod. Modula-3 doesn't >>> chose the obvious correct one and C doesn't chose the >>> obvious incorrect one. >>> >>> We may yet be able to use the gcc support but it makes me nervous. >>> It requires at least in a very minimal sense, for the frontend >>> to support TImode (aka int128_t). >>> >>> See: http://gcc.gnu.org/ml/gcc/2010-06/msg00647.html >>> (which is just from me, talking to myself..) >>> >>> From jkrell at elego.de Thu Jun 24 11:26:47 2010 From: jkrell at elego.de (Jay Krell) Date: Thu, 24 Jun 2010 11:26:47 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100624092648.11DE3CC37E@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/06/24 11:26:47 Modified files: cm3/m3-sys/m3cc/gcc/gcc/: lower-subreg.c Log message: initialize local due to warning that it might be used uninitialized From jkrell at elego.de Thu Jun 24 11:37:44 2010 From: jkrell at elego.de (Jay Krell) Date: Thu, 24 Jun 2010 11:37:44 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100624093744.E715ECC37E@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/06/24 11:37:44 Modified files: cm3/m3-libs/m3core/src/Csupport/Common/: hand.c Log message: fix div/mod helpers to operate on INTEGER/WORD_T instead of INT32/UINT32; still there is a problem and I will next try using the release version of these From jkrell at elego.de Thu Jun 24 11:47:30 2010 From: jkrell at elego.de (Jay Krell) Date: Thu, 24 Jun 2010 11:47:30 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100624094730.BC58C2474006@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/06/24 11:47:30 Modified files: cm3/m3-libs/m3core/src/Csupport/Common/: hand.c Log message: go back to release form of div/mod helpers for now, though these don't fix the problem either (X.i3 could not find a legal alignment for the packed type From jkrell at elego.de Thu Jun 24 11:54:35 2010 From: jkrell at elego.de (Jay Krell) Date: Thu, 24 Jun 2010 11:54:35 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100624095436.142832474006@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/06/24 11:54:35 Added files: cm3/m3-libs/m3core/src/C/ARMEL_LINUX/: Csetjmp.i3 Log message: I forgot to commit this last weekend. From jkrell at elego.de Thu Jun 24 12:40:42 2010 From: jkrell at elego.de (Jay Krell) Date: Thu, 24 Jun 2010 12:40:42 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100624104042.AE6C4CC37E@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/06/24 12:40:42 Modified files: cm3/m3-ui/X11R4/src/Common/: X.i3 Log message: make lots of fields private to match current headers and DisplayStar = UNTRACED BRANDED REF ADDRESS to push all of Display toward private, like current headers From jkrell at elego.de Thu Jun 24 12:51:31 2010 From: jkrell at elego.de (Jay Krell) Date: Thu, 24 Jun 2010 12:51:31 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100624105133.4CC05CC110@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/06/24 12:51:31 Modified files: cm3/m3-ui/X11R4/src/Common/: X.i3 Log message: slightly further privatize display and gc (graphics context) in accordance with current headers Note that Xlib is I believe considered obsolete/deprecated/legacy and there is a new xcb X C binding. See http://en.wikipedia.org/wiki/XCB etc. (I'd have to research how widely xcb is distributed and used.) From jkrell at elego.de Thu Jun 24 13:05:49 2010 From: jkrell at elego.de (Jay Krell) Date: Thu, 24 Jun 2010 13:05:49 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100624110549.92EF52474006@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/06/24 13:05:49 Modified files: cm3/m3-libs/m3core/src/runtime/common/: RTType.m3 Log message: make it compatible with new ADR old ADR(T):ADDRESS new ADR(T):UNTRACED REF T From jay.krell at cornell.edu Thu Jun 24 13:06:14 2010 From: jay.krell at cornell.edu (Jay K) Date: Thu, 24 Jun 2010 11:06:14 +0000 Subject: [M3commit] CVS Update: cm3 In-Reply-To: <20100624110549.92EF52474006@birch.elegosoft.com> References: <20100624110549.92EF52474006@birch.elegosoft.com> Message-ID: =================================================================== RCS file: /usr/cvs/cm3/m3-libs/m3core/src/runtime/common/RTType.m3,v retrieving revision 1.10 diff -u -r1.10 RTType.m3 --- runtime/common/RTType.m3??? 3 Nov 2009 20:30:21 -0000??? 1.10 +++ runtime/common/RTType.m3??? 24 Jun 2010 11:02:06 -0000 @@ -455,8 +455,8 @@ ???? GenBuiltin (ADR (NULL_typecell),???? "NULL"); ???? GenBuiltin (ADR (REFANY_typecell),?? "REFANY"); ???? GenBuiltin (ADR (ADDRESS_typecell),? "ADDRESS"); -??? GenBuiltin (ADR (ROOT_typecell),???? "ROOT"); -??? GenBuiltin (ADR (UNROOT_typecell),?? "UNTRACED ROOT"); +??? GenBuiltin (ADR (ROOT_typecell.common), "ROOT"); +??? GenBuiltin (ADR (UNROOT_typecell.common), "UNTRACED ROOT"); ???? types.cnt := MAX (types.cnt, RT0.FirstUserTypecode); ?? END AssignBuiltinTypes; ---------------------------------------- > Date: Thu, 24 Jun 2010 13:05:49 +0000 > To: m3commit at elegosoft.com > From: jkrell at elego.de > Subject: [M3commit] CVS Update: cm3 > > CVSROOT: /usr/cvs > Changes by: jkrell at birch. 10/06/24 13:05:49 > > Modified files: > cm3/m3-libs/m3core/src/runtime/common/: RTType.m3 > > Log message: > make it compatible with new ADR > old ADR(T):ADDRESS > new ADR(T):UNTRACED REF T > From jkrell at elego.de Thu Jun 24 13:34:11 2010 From: jkrell at elego.de (Jay Krell) Date: Thu, 24 Jun 2010 13:34:11 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100624113412.671642474006@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/06/24 13:34:11 Modified files: cm3/m3-sys/m3tests/src/p0/p073/: Main.m3 stderr.pgm Log message: augment div/mod test (this might be redundant, but it is fast) From jkrell at elego.de Thu Jun 24 13:47:44 2010 From: jkrell at elego.de (Jay Krell) Date: Thu, 24 Jun 2010 13:47:44 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100624114744.E3B3ECC37E@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/06/24 13:47:44 Modified files: cm3/m3-sys/m3tests/src/p0/p073/: Main.m3 Log message: more checks From jkrell at elego.de Thu Jun 24 13:51:28 2010 From: jkrell at elego.de (Jay Krell) Date: Thu, 24 Jun 2010 13:51:28 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100624115128.BC147CC37E@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/06/24 13:51:28 Modified files: cm3/m3-sys/m3tests/src/p0/p073/: Main.m3 Log message: more/clearer checks From jkrell at elego.de Fri Jun 25 10:00:22 2010 From: jkrell at elego.de (Jay Krell) Date: Fri, 25 Jun 2010 10:00:22 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100625080022.8AB37CC110@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/06/25 10:00:22 Modified files: cm3/m3-libs/m3core/src/Csupport/Common/: hand.c Log message: back to versions that avoid overflowing signed numbers From jkrell at elego.de Fri Jun 25 11:02:40 2010 From: jkrell at elego.de (Jay Krell) Date: Fri, 25 Jun 2010 11:02:40 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100625090240.5467CCC37E@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/06/25 11:02:40 Modified files: cm3/m3-sys/m3cc/gcc/gcc/: tree-nested.c Log message: add an assert, based on a suspicion: STATIC_CHAIN_EXPR must always have a target_context, whatever that is From jkrell at elego.de Sat Jun 26 13:27:30 2010 From: jkrell at elego.de (Jay Krell) Date: Sat, 26 Jun 2010 13:27:30 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100626112730.0EADFCC37F@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/06/26 13:27:30 Modified files: cm3/m3-sys/m3cc/gcc-4.5/gcc/config/: darwin-protos.h Log message: ../../gcc-4.5/gcc/config/darwin-protos.h:57: warning: ???enum machine_mode??? declared inside parameter list ../../gcc-4.5/gcc/config/darwin-protos.h:57: warning: its scope is only this definition or declaration, which is probably not what you want throw in forward declaration: "enum machine_mode;" could be we are missing an #include From jkrell at elego.de Sat Jun 26 13:35:31 2010 From: jkrell at elego.de (Jay Krell) Date: Sat, 26 Jun 2010 13:35:31 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100626113531.50E39CC37F@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/06/26 13:35:31 Modified files: cm3/m3-sys/m3cc/gcc-4.5/gcc/: genpeep.c Log message: quash Darwin-specific warning from ranlib see http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44308 (which gcc maintainers won't fix) From jkrell at elego.de Sat Jun 26 13:36:43 2010 From: jkrell at elego.de (Jay Krell) Date: Sat, 26 Jun 2010 13:36:43 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100626113643.A47742474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/06/26 13:36:43 Modified files: cm3/m3-sys/m3cc/gcc-4.5/gcc/: genpeep.c Log message: move newlines around From jkrell at elego.de Sat Jun 26 13:37:27 2010 From: jkrell at elego.de (Jay Krell) Date: Sat, 26 Jun 2010 13:37:27 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100626113727.40CA82474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/06/26 13:37:27 Modified files: cm3/m3-sys/m3cc/gcc-4.5/gcc/: genpeep.c Log message: change symbol From jkrell at elego.de Sat Jun 26 15:08:46 2010 From: jkrell at elego.de (Jay Krell) Date: Sat, 26 Jun 2010 15:08:46 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100626130846.713D7CC37F@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/06/26 15:08:46 Modified files: cm3/m3-sys/m3middle/src/: TFloat.m3 Log message: LOOPHOLE so it works with -new_adr From jay.krell at cornell.edu Sat Jun 26 15:09:44 2010 From: jay.krell at cornell.edu (Jay K) Date: Sat, 26 Jun 2010 13:09:44 +0000 Subject: [M3commit] CVS Update: cm3 In-Reply-To: <20100626130846.713D7CC37F@birch.elegosoft.com> References: <20100626130846.713D7CC37F@birch.elegosoft.com> Message-ID: @@ -200,15 +200,15 @@ ? ???? CASE p OF ???? | Precision.Short => -??????? ptr := ADR (x1); +??????? ptr := LOOPHOLE(ADR (x1), Ptr); ???????? SUBARRAY (ptr^, 0, len) := SUBARRAY (buf, 0, len); ???????? f.fraction := FLOAT (x1, EXTENDED); ???? | Precision.Long => -??????? ptr := ADR (x2); +??????? ptr := LOOPHOLE(ADR (x2), Ptr); ???????? SUBARRAY (ptr^, 0, len) := SUBARRAY (buf, 0, len); ???????? f.fraction := FLOAT (x2, EXTENDED); ???? | Precision.Extended => -??????? ptr := ADR (x3); +??????? ptr := LOOPHOLE(ADR (x3), Ptr); ???????? SUBARRAY (ptr^, 0, len) := SUBARRAY (buf, 0, len); ???????? f.fraction := x3; ???? END; ---------------------------------------- > Date: Sat, 26 Jun 2010 15:08:46 +0000 > To: m3commit at elegosoft.com > From: jkrell at elego.de > Subject: [M3commit] CVS Update: cm3 > > CVSROOT: /usr/cvs > Changes by: jkrell at birch. 10/06/26 15:08:46 > > Modified files: > cm3/m3-sys/m3middle/src/: TFloat.m3 > > Log message: > LOOPHOLE so it works with -new_adr > From jkrell at elego.de Sat Jun 26 15:15:39 2010 From: jkrell at elego.de (Jay Krell) Date: Sat, 26 Jun 2010 15:15:39 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100626131539.E8FB62474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/06/26 15:15:39 Modified files: cm3/m3-comm/tcp/src/POSIX/: TCPPeer.m3 TCPExtras.m3 Log message: fix memory corrupting bug that I probably introduced, 64bit only, found by -new_adr int to socklen_t From jay.krell at cornell.edu Sat Jun 26 15:16:14 2010 From: jay.krell at cornell.edu (Jay K) Date: Sat, 26 Jun 2010 13:16:14 +0000 Subject: [M3commit] CVS Update: cm3 In-Reply-To: <20100626131539.E8FB62474003@birch.elegosoft.com> References: <20100626131539.E8FB62474003@birch.elegosoft.com> Message-ID: =================================================================== RCS file: /usr/cvs/cm3/m3-comm/tcp/src/POSIX/TCPExtras.m3,v retrieving revision 1.1.1.1 diff -u -r1.1.1.1 TCPExtras.m3 --- TCPExtras.m3??? 13 Jan 2001 14:15:14 -0000??? 1.1.1.1 +++ TCPExtras.m3??? 26 Jun 2010 13:13:58 -0000 @@ -9,7 +9,7 @@ ?PROCEDURE LocalEndpoint (conn: TCP.T): IP.Endpoint RAISES {IP.Error} = ?? VAR ???? addr : Uin.struct_sockaddr_in; -??? len? : Ctypes.int := BYTESIZE (addr); +??? len? : Usocket.socklen_t := BYTESIZE (addr); ???? ep?? : IP.Endpoint; ?? BEGIN ???? LOCK conn DO Index: TCPPeer.m3 =================================================================== RCS file: /usr/cvs/cm3/m3-comm/tcp/src/POSIX/TCPPeer.m3,v retrieving revision 1.1.1.1 diff -u -r1.1.1.1 TCPPeer.m3 --- TCPPeer.m3??? 13 Jan 2001 14:15:14 -0000??? 1.1.1.1 +++ TCPPeer.m3??? 26 Jun 2010 13:13:58 -0000 @@ -45,7 +45,7 @@ ? ?PROCEDURE GetSockAddr (channel: TCP.T;? VAR(*OUT*) addr: Addr) ?? RAISES {IP.Error} = -? VAR len: Ctypes.int := BYTESIZE (addr); +? VAR len: Usocket.socklen_t := BYTESIZE (addr); ?? BEGIN ???? LOCK channel DO ?????? IF (channel.closed) THEN IPError.Raise (TCP.Closed); END; ---------------------------------------- > Date: Sat, 26 Jun 2010 15:15:39 +0000 > To: m3commit at elegosoft.com > From: jkrell at elego.de > Subject: [M3commit] CVS Update: cm3 > > CVSROOT: /usr/cvs > Changes by: jkrell at birch. 10/06/26 15:15:39 > > Modified files: > cm3/m3-comm/tcp/src/POSIX/: TCPPeer.m3 TCPExtras.m3 > > Log message: > fix memory corrupting bug that I probably introduced, 64bit only, found by -new_adr int to socklen_t > From jkrell at elego.de Sat Jun 26 15:17:53 2010 From: jkrell at elego.de (Jay Krell) Date: Sat, 26 Jun 2010 15:17:53 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100626131753.F2D342474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/06/26 15:17:53 Modified files: cm3/m3-comm/udp/src/POSIX/: UDPPosix.m3 Log message: int to socklen_t so it works with -new_adr and doesn't corrupt memory on 64bit From jay.krell at cornell.edu Sat Jun 26 15:18:15 2010 From: jay.krell at cornell.edu (Jay K) Date: Sat, 26 Jun 2010 13:18:15 +0000 Subject: [M3commit] CVS Update: cm3 In-Reply-To: <20100626131753.F2D342474003@birch.elegosoft.com> References: <20100626131753.F2D342474003@birch.elegosoft.com> Message-ID: Index: src/POSIX/UDPPosix.m3 =================================================================== RCS file: /usr/cvs/cm3/m3-comm/udp/src/POSIX/UDPPosix.m3,v retrieving revision 1.3 diff -u -r1.3 UDPPosix.m3 --- src/POSIX/UDPPosix.m3??? 14 Apr 2003 20:18:44 -0000??? 1.3 +++ src/POSIX/UDPPosix.m3??? 26 Jun 2010 13:17:16 -0000 @@ -122,7 +122,7 @@ ???? waitRes: SchedulerPosix.WaitResult; ???? numRead: INTEGER; ???? sockaddr: Uin.struct_sockaddr_in; -??? saSize: Ctypes.int; +??? saSize: Usocket.socklen_t; ?? BEGIN ???? <* ASSERT self.open *> ???? waitRes := SchedulerPosix.IOAlertWait(self.fileno, TRUE, timeout); ---------------------------------------- > Date: Sat, 26 Jun 2010 15:17:53 +0000 > To: m3commit at elegosoft.com > From: jkrell at elego.de > Subject: [M3commit] CVS Update: cm3 > > CVSROOT: /usr/cvs > Changes by: jkrell at birch. 10/06/26 15:17:53 > > Modified files: > cm3/m3-comm/udp/src/POSIX/: UDPPosix.m3 > > Log message: > int to socklen_t so it works with -new_adr and doesn't corrupt memory on 64bit > From jkrell at elego.de Sat Jun 26 15:19:58 2010 From: jkrell at elego.de (Jay Krell) Date: Sat, 26 Jun 2010 15:19:58 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100626131958.7C94A2474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/06/26 15:19:58 Modified files: cm3/m3-libs/sysutils/src/POSIX/: SystemPosix.m3 Log message: LOOPHOLE to char_star so it works with -new_adr From jkrell at elego.de Sat Jun 26 15:25:58 2010 From: jkrell at elego.de (Jay Krell) Date: Sat, 26 Jun 2010 15:25:58 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100626132558.E05AC2474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/06/26 15:25:58 Modified files: cm3/m3-libs/libm3/src/os/POSIX/: SocketPosix.m3 Log message: int/INTEGER => socklen_t LOOPHOLE to char_star so it works with -new_adr and doesn't corrupt stack From jay.krell at cornell.edu Sat Jun 26 15:20:16 2010 From: jay.krell at cornell.edu (Jay K) Date: Sat, 26 Jun 2010 13:20:16 +0000 Subject: [M3commit] CVS Update: cm3 In-Reply-To: <20100626131958.7C94A2474003@birch.elegosoft.com> References: <20100626131958.7C94A2474003@birch.elegosoft.com> Message-ID: Index: src/POSIX/SystemPosix.m3 =================================================================== RCS file: /usr/cvs/cm3/m3-libs/sysutils/src/POSIX/SystemPosix.m3,v retrieving revision 1.16 diff -u -r1.16 SystemPosix.m3 --- src/POSIX/SystemPosix.m3??? 10 Mar 2010 10:45:44 -0000??? 1.16 +++ src/POSIX/SystemPosix.m3??? 26 Jun 2010 13:19:32 -0000 @@ -34,7 +34,7 @@ ???? buf : ARRAY [0..1024] OF CHAR; ???? len := 1024; ?? BEGIN -??? IF gethostname(ADR(buf), len) = 0 THEN +??? IF gethostname(LOOPHOLE(ADR(buf), Ctypes.char_star), len) = 0 THEN ?????? buf[1024] := '\000'; ?????? len := 0; ?????? WHILE len < 1024 AND buf[len] # '\000' DO ---------------------------------------- > Date: Sat, 26 Jun 2010 15:19:58 +0000 > To: m3commit at elegosoft.com > From: jkrell at elego.de > Subject: [M3commit] CVS Update: cm3 > > CVSROOT: /usr/cvs > Changes by: jkrell at birch. 10/06/26 15:19:58 > > Modified files: > cm3/m3-libs/sysutils/src/POSIX/: SystemPosix.m3 > > Log message: > LOOPHOLE to char_star so it works with -new_adr > From jkrell at elego.de Sat Jun 26 15:29:46 2010 From: jkrell at elego.de (Jay Krell) Date: Sat, 26 Jun 2010 15:29:46 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100626132946.AAB282474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/06/26 15:29:46 Modified files: cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c Log message: fix minor typo in trace output From jay.krell at cornell.edu Sat Jun 26 15:28:04 2010 From: jay.krell at cornell.edu (Jay K) Date: Sat, 26 Jun 2010 13:28:04 +0000 Subject: [M3commit] CVS Update: cm3 In-Reply-To: <20100626132558.E05AC2474003@birch.elegosoft.com> References: <20100626132558.E05AC2474003@birch.elegosoft.com> Message-ID: oops I deleted the diff, but simple enough ---------------------------------------- > Date: Sat, 26 Jun 2010 15:25:58 +0000 > To: m3commit at elegosoft.com > From: jkrell at elego.de > Subject: [M3commit] CVS Update: cm3 > > CVSROOT: /usr/cvs > Changes by: jkrell at birch. 10/06/26 15:25:58 > > Modified files: > cm3/m3-libs/libm3/src/os/POSIX/: SocketPosix.m3 > > Log message: > int/INTEGER => socklen_t > LOOPHOLE to char_star > so it works with -new_adr and doesn't corrupt stack > From jkrell at elego.de Sun Jun 27 10:52:53 2010 From: jkrell at elego.de (Jay Krell) Date: Sun, 27 Jun 2010 10:52:53 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100627085253.CA57B2474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/06/27 10:52:53 Modified files: cm3/m3-sys/m3cc/src/: gnucc.common Log message: allow -DO0 to turn off optimizations From jkrell at elego.de Sun Jun 27 12:09:53 2010 From: jkrell at elego.de (Jay Krell) Date: Sun, 27 Jun 2010 12:09:53 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100627100953.835322474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/06/27 12:09:53 Modified files: cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c Log message: #ifdef GCC45 to #if GCC45, #ifndef to #if ! From jkrell at elego.de Sun Jun 27 12:19:51 2010 From: jkrell at elego.de (Jay Krell) Date: Sun, 27 Jun 2010 12:19:51 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100627101951.3F9D32474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/06/27 12:19:51 Modified files: cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c Log message: change some #if GCC45 to if (GCC45), where both arms should compile with either code base From jkrell at elego.de Sun Jun 27 12:21:24 2010 From: jkrell at elego.de (Jay Krell) Date: Sun, 27 Jun 2010 12:21:24 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100627102124.F3B4ACC10F@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/06/27 12:21:24 Modified files: cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c Log message: remove initial #define GCC45 0 From jkrell at elego.de Sun Jun 27 12:30:48 2010 From: jkrell at elego.de (Jay Krell) Date: Sun, 27 Jun 2010 12:30:48 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100627103048.E1C072474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/06/27 12:30:48 Modified files: cm3/m3-sys/m3cc/src/: m3makefile cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c Log message: a little more #ifdef to #if, GCC_APPLE and GCC42 (which really mean the same thing) From jkrell at elego.de Sun Jun 27 12:58:39 2010 From: jkrell at elego.de (Jay Krell) Date: Sun, 27 Jun 2010 12:58:39 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100627105839.2F8802474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/06/27 12:58:39 Modified files: cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c Log message: fold gcc45 and non-gcc45 code mostly via: enum tree_code plus = (GCC45 ? POINTER_PLUS_EXPR : PLUS_EXPR); From jkrell at elego.de Sun Jun 27 13:36:38 2010 From: jkrell at elego.de (Jay Krell) Date: Sun, 27 Jun 2010 13:36:38 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100627113638.913772474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/06/27 13:36:38 Modified files: cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c Log message: in m3cg_set_label, use a loop to put the asm("") before and after the label, instead of duplicating the code also in m3cg_set_label, a possible gcc 4.5 fix, use DECL_NONLOCAL(l) = true; instead of manipulating nonlocal_goto_handler_labels, which doesn't work (it crashes) From jkrell at elego.de Sun Jun 27 13:56:52 2010 From: jkrell at elego.de (Jay Krell) Date: Sun, 27 Jun 2010 13:56:52 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100627115653.035C92474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/06/27 13:56:52 Modified files: cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c Log message: fix m3cg_set_label change From jkrell at elego.de Sun Jun 27 15:17:37 2010 From: jkrell at elego.de (Jay Krell) Date: Sun, 27 Jun 2010 15:17:37 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100627131737.AE1812474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/06/27 15:17:37 Modified files: cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c Log message: reduce diff in gcc 4.3 m3cg_set_label From jkrell at elego.de Sun Jun 27 15:19:43 2010 From: jkrell at elego.de (Jay Krell) Date: Sun, 27 Jun 2010 15:19:43 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100627131943.1D4D42474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/06/27 15:19:43 Modified files: cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c Log message: fix type to fix warning From jkrell at elego.de Sun Jun 27 15:23:14 2010 From: jkrell at elego.de (Jay Krell) Date: Sun, 27 Jun 2010 15:23:14 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100627132314.9DE152474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/06/27 15:23:14 Modified files: cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c Log message: provide IS_INTEGER_TYPE_TREE and IS_WORD_TYPE_TREE macros even for gcc <4.5; forward declare enum machine_mode to quash warning on other targets From jkrell at elego.de Sun Jun 27 15:24:10 2010 From: jkrell at elego.de (Jay Krell) Date: Sun, 27 Jun 2010 15:24:10 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100627132410.BBD782474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/06/27 15:24:10 Modified files: cm3/m3-sys/m3cc/gcc/gcc/config/: darwin-protos.h Log message: remove the enum machine_mode forward declare from here, now that we have in parse.c From jkrell at elego.de Sun Jun 27 16:09:33 2010 From: jkrell at elego.de (Jay Krell) Date: Sun, 27 Jun 2010 16:09:33 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100627140933.123E12474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/06/27 16:09:33 Modified files: cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c Log message: fix 4.5 compilation regarding x_nonlocal_goto_handler_labels From jkrell at elego.de Mon Jun 28 03:30:29 2010 From: jkrell at elego.de (Jay Krell) Date: Mon, 28 Jun 2010 3:30:29 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100628013029.E17DE2474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/06/28 03:30:29 Modified files: cm3/m3-sys/m3front/src/misc/: CG.m3 Log message: go back to spelling out Target.Integer|Word.cg_type; there are several (at least instances) of type mismatches here, that gcc 4.5 complains about, we need to use Integer less and Word more, but that isn't changed here yet From jkrell at elego.de Mon Jun 28 11:03:25 2010 From: jkrell at elego.de (Jay Krell) Date: Mon, 28 Jun 2010 11:03:25 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100628090325.118072474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/06/28 11:03:25 Modified files: cm3/m3-libs/m3core/src/: m3core.h Log message: fix Visual C++ warning under -Wall From jkrell at elego.de Mon Jun 28 11:05:08 2010 From: jkrell at elego.de (Jay Krell) Date: Mon, 28 Jun 2010 11:05:08 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100628090508.0DD482474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/06/28 11:05:08 Modified files: cm3/m3-libs/m3core/src/: m3core.h Log message: remove duplicate #define of EXTERN_CONST From jkrell at elego.de Mon Jun 28 11:07:08 2010 From: jkrell at elego.de (Jay Krell) Date: Mon, 28 Jun 2010 11:07:08 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100628090708.541752474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/06/28 11:07:08 Modified files: cm3/m3-libs/m3core/src/Csupport/Common/: hand.c Log message: fix Windows compilation (uint64 => UINT64) From jkrell at elego.de Mon Jun 28 22:29:57 2010 From: jkrell at elego.de (Jay Krell) Date: Mon, 28 Jun 2010 22:29:57 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100628202957.294622474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/06/28 22:29:56 Modified files: cm3/m3-libs/m3core/src/: m3core.h Log message: put back warning, better than consequent error From jkrell at elego.de Tue Jun 29 09:06:33 2010 From: jkrell at elego.de (Jay Krell) Date: Tue, 29 Jun 2010 9:06:33 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100629070634.0A6082474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/06/29 09:06:33 Modified files: cm3/scripts/win/: sysinfo.cmd Log message: support spaces in INCLUDE and PATH, though spaces in CM3_INSTALL are missing quotes when -I is passed to C compiler From jkrell at elego.de Tue Jun 29 09:07:07 2010 From: jkrell at elego.de (Jay Krell) Date: Tue, 29 Jun 2010 9:07:07 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100629070707.CF4BE2474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/06/29 09:07:07 Modified files: cm3/scripts/win/: cvs.c Log message: set CVS_RSH=/bin/ssh if it is ssh or empty From jkrell at elego.de Tue Jun 29 09:07:34 2010 From: jkrell at elego.de (Jay Krell) Date: Tue, 29 Jun 2010 9:07:34 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100629070734.42E602474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/06/29 09:07:34 Modified files: cm3/scripts/win/: cvs.c Log message: remove tab From jkrell at elego.de Tue Jun 29 12:56:36 2010 From: jkrell at elego.de (Jay Krell) Date: Tue, 29 Jun 2010 12:56:36 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100629105636.D40B42474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/06/29 12:56:36 Modified files: cm3/m3-sys/m3tests/src/p2/p230/: Main.m3 Added files: cm3/m3-sys/m3tests/src/p2/p230/: stdout.pgm32-big_endian stdout.pgm32-little_endian stdout.pgm64-big_endian stdout.pgm64-little_endian Removed files: cm3/m3-sys/m3tests/src/p2/p230/: stdout.pgm-big_endian stdout.pgm-little_endian Log message: The output here is word size specific, besides endian specific, because the sets aren't an multiple of 64 bits in size. The 64bit big endian file here is just a copy of 32bit big endian. From jkrell at elego.de Tue Jun 29 13:04:55 2010 From: jkrell at elego.de (Jay Krell) Date: Tue, 29 Jun 2010 13:04:55 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100629110455.957802474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/06/29 13:04:55 Added files: cm3/m3-sys/m3tests/src/p2/p230/: stdout.pgm-big_endian32 stdout.pgm-big_endian64 stdout.pgm-little_endian32 stdout.pgm-little_endian64 Removed files: cm3/m3-sys/m3tests/src/p2/p230/: stdout.pgm32-big_endian stdout.pgm32-little_endian stdout.pgm64-big_endian stdout.pgm64-little_endian Log message: correct the names From jkrell at elego.de Tue Jun 29 13:33:25 2010 From: jkrell at elego.de (Jay Krell) Date: Tue, 29 Jun 2010 13:33:25 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100629113325.7A8542474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/06/29 13:33:25 Added files: cm3/m3-sys/m3tests/src/p2/p239/: Main.m3 Main.ms-AMD64_DARWIN m3makefile Log message: Experimentally..start a line of tests where we checkin the "exact" codegen, so we can later compare. Several caveats/notes: the infrastructure to do the compares is not here yet (shortly) we should probably allow just "i386" or "amd64", instead of the full "AMD64_DARWIN" this kind of testing is "very sensitive" The sensitivity has at least been somewhat reduced by omitting debugging info, and noise reduced by omitting pic and unwind tables The test is far from complete. More targets need current output before changes are made. From jkrell at elego.de Tue Jun 29 13:33:59 2010 From: jkrell at elego.de (Jay Krell) Date: Tue, 29 Jun 2010 13:33:59 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100629113359.555532474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/06/29 13:33:59 Modified files: cm3/m3-sys/m3tests/src/: m3makefile Log message: add test p239 and infra to compare it er, not sure what this will do on other targets, probably fail but not too noisily From jkrell at elego.de Tue Jun 29 13:45:58 2010 From: jkrell at elego.de (Jay Krell) Date: Tue, 29 Jun 2010 13:45:58 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100629114558.377DB2474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/06/29 13:45:58 Modified files: cm3/m3-sys/m3tests/src/p2/p239/: Main.m3 Main.ms-AMD64_DARWIN Log message: add bit-and tests From jkrell at elego.de Tue Jun 29 13:59:29 2010 From: jkrell at elego.de (Jay Krell) Date: Tue, 29 Jun 2010 13:59:29 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100629115929.B82F62474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/06/29 13:59:29 Modified files: cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c Log message: change m3_build1 (CONVERT_EXPR, ...) to m3_convert (...) no great reason, but based on m3_cast convert/cast will be the subject of likely near future other changes, until configure -enable-checking is satisfied (some changes might be elsewhere, e.g. m3front) With this change, the assembly output for AMD64_DARWIN m3core is unchanged. From jkrell at elego.de Tue Jun 29 14:08:31 2010 From: jkrell at elego.de (Jay Krell) Date: Tue, 29 Jun 2010 14:08:31 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100629120831.215B2CC110@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/06/29 14:08:31 Modified files: cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c Log message: Start fixing configure -enable-checking problems. Start with the very simplest: bit-or/and/xor/not. There are some small changes in m3core as a result but they don't appear to be semantically interesting, mostly stuff like: - movq -32(%rbp), %rdx - movq -24(%rbp), %rax + movq -24(%rbp), %rdx + movq -32(%rbp), %rax orq %rdx, %rax when I tried reversing the parameter order, the changes where larger. From jay.krell at cornell.edu Tue Jun 29 14:09:26 2010 From: jay.krell at cornell.edu (Jay K) Date: Tue, 29 Jun 2010 12:09:26 +0000 Subject: [M3commit] CVS Update: cm3 In-Reply-To: <20100629120831.215B2CC110@birch.elegosoft.com> References: <20100629120831.215B2CC110@birch.elegosoft.com> Message-ID: Index: gcc/gcc/m3cg/parse.c =================================================================== RCS file: /usr/cvs/cm3/m3-sys/m3cc/gcc/gcc/m3cg/parse.c,v retrieving revision 1.202 diff -u -r1.202 parse.c --- gcc/gcc/m3cg/parse.c??? 29 Jun 2010 11:59:29 -0000??? 1.202 +++ gcc/gcc/m3cg/parse.c??? 29 Jun 2010 12:07:03 -0000 @@ -4412,8 +4412,7 @@ ?{ ?? MTYPE (t); ? -? EXPR_REF (-1) = m3_build1 (BIT_NOT_EXPR, m3_unsigned_type (t), -???????????????????????????? EXPR_REF (-1)); +? EXPR_REF (-1) = m3_build1 (BIT_NOT_EXPR, t, m3_cast (t, EXPR_REF (-1))); ?} ? ?static void @@ -4421,8 +4420,9 @@ ?{ ?? MTYPE (t); ? -? EXPR_REF (-2) = m3_build2 (BIT_AND_EXPR, m3_unsigned_type (t), -???????????????????????????? EXPR_REF (-2), EXPR_REF (-1)); +? EXPR_REF (-2) = m3_build2 (BIT_AND_EXPR, t, +???????????????????????????? m3_cast (t, EXPR_REF (-2)), +???????????????????????????? m3_cast (t, EXPR_REF (-1))); ?? EXPR_POP (); ?} ? @@ -4431,8 +4431,9 @@ ?{ ?? MTYPE (t); ? -? EXPR_REF (-2) = m3_build2 (BIT_IOR_EXPR, m3_unsigned_type (t), -???????????????????????????? EXPR_REF (-2), EXPR_REF (-1)); +? EXPR_REF (-2) = m3_build2 (BIT_IOR_EXPR, t, +???????????????????????????? m3_cast (t, EXPR_REF (-2)), +???????????????????????????? m3_cast (t, EXPR_REF (-1))); ?? EXPR_POP (); ?} ? @@ -4441,8 +4442,9 @@ ?{ ?? MTYPE (t); ? -? EXPR_REF (-2) = m3_build2 (BIT_XOR_EXPR, m3_unsigned_type (t), -???????????????????????????? EXPR_REF (-2), EXPR_REF (-1)); +? EXPR_REF (-2) = m3_build2 (BIT_XOR_EXPR, t, +???????????????????????????? m3_convert (t, EXPR_REF (-2)), +???????????????????????????? m3_convert (t, EXPR_REF (-1))); ?? EXPR_POP (); ?} ? ---------------------------------------- > Date: Tue, 29 Jun 2010 14:08:31 +0000 > To: m3commit at elegosoft.com > From: jkrell at elego.de > Subject: [M3commit] CVS Update: cm3 > > CVSROOT: /usr/cvs > Changes by: jkrell at birch. 10/06/29 14:08:31 > > Modified files: > cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c > > Log message: > Start fixing configure -enable-checking problems. > Start with the very simplest: bit-or/and/xor/not. > There are some small changes in m3core as a result but > they don't appear to be semantically interesting, mostly stuff like: > - movq -32(%rbp), %rdx > - movq -24(%rbp), %rax > + movq -24(%rbp), %rdx > + movq -32(%rbp), %rax > orq %rdx, %rax > > when I tried reversing the parameter order, the changes where larger. > From jkrell at elego.de Tue Jun 29 14:25:42 2010 From: jkrell at elego.de (Jay Krell) Date: Tue, 29 Jun 2010 14:25:42 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100629122544.BAB2B2474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/06/29 14:25:42 Modified files: cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c Log message: oops, also m3_cast for xor, not m3_convert This again shuffles things around in a way that doesn't seem meaningful. From jkrell at elego.de Tue Jun 29 14:42:12 2010 From: jkrell at elego.de (Jay Krell) Date: Tue, 29 Jun 2010 14:42:12 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100629124212.117E12474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/06/29 14:42:12 Modified files: cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c Log message: cleanup m3cg_index_address - same code for gcc 4.2/3/5 - should address the configure -enable-checking errors I am leary of using m3_cast instead of m3_covert though. From jay.krell at cornell.edu Tue Jun 29 14:42:57 2010 From: jay.krell at cornell.edu (Jay K) Date: Tue, 29 Jun 2010 12:42:57 +0000 Subject: [M3commit] CVS Update: cm3 In-Reply-To: <20100629124212.117E12474003@birch.elegosoft.com> References: <20100629124212.117E12474003@birch.elegosoft.com> Message-ID: Index: parse.c =================================================================== RCS file: /usr/cvs/cm3/m3-sys/m3cc/gcc/gcc/m3cg/parse.c,v retrieving revision 1.204 diff -u -r1.204 parse.c --- parse.c??? 29 Jun 2010 12:25:40 -0000??? 1.204 +++ parse.c??? 29 Jun 2010 12:40:47 -0000 @@ -4982,24 +4982,27 @@ ?static void ?m3cg_index_address (void) ?{ -? enum tree_code plus = (GCC45 ? POINTER_PLUS_EXPR : PLUS_EXPR); ?? tree a = { 0 }; +? bool signd = { 0 }; +? long bytes = { 0 }; + ?? MTYPE2?? (t, T); -? BYTESIZE (n); +? BYTESIZE (bits); +? +? bytes = (bits / BITS_PER_UNIT); ? ?? if (option_vars_trace) -??? fprintf(stderr, "? index address n:0x%lx n_bytes:0x%lx type:%s\n", -??????????? n, n / BITS_PER_UNIT, m3cg_typename(T)); +??? fprintf(stderr, "? index address n_bytes:0x%lx type:%s\n", +??????????? bytes, m3cg_typename(T)); ? -? a = m3_build2 (MULT_EXPR, t, EXPR_REF (-1), size_int (n / BITS_PER_UNIT)); -? if (GCC45) -? { -??? gcc_assert(IS_INTEGER_TYPE_TREE(t) || IS_WORD_TYPE_TREE(t)); -??? if (IS_INTEGER_TYPE_TREE(t)) -????? a = m3_cast(ssizetype, a); -??? a = m3_cast(sizetype, a); -? } -? EXPR_REF (-2) = m3_build2 (plus, t_addr, m3_cast (t_addr, EXPR_REF (-2)), a); +? signd = IS_INTEGER_TYPE_TREE(t); +? gcc_assert(signd || IS_WORD_TYPE_TREE(t)); +? a = (signd ? ssize_int (bytes) : size_int (bytes)); +? a = m3_build2 (MULT_EXPR, t, EXPR_REF (-1), a); +? if (IS_INTEGER_TYPE_TREE(t)) +??? a = m3_cast (ssizetype, a); +? a = m3_cast (sizetype, a); +? EXPR_REF (-2) = m3_build2 (POINTER_PLUS_EXPR, t_addr, m3_cast (t_addr, EXPR_REF (-2)), a); ?? EXPR_POP (); ?} ? ?- Jay ---------------------------------------- > Date: Tue, 29 Jun 2010 14:42:12 +0000 > To: m3commit at elegosoft.com > From: jkrell at elego.de > Subject: [M3commit] CVS Update: cm3 > > CVSROOT: /usr/cvs > Changes by: jkrell at birch. 10/06/29 14:42:12 > > Modified files: > cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c > > Log message: > cleanup m3cg_index_address > - same code for gcc 4.2/3/5 > - should address the configure -enable-checking errors > > I am leary of using m3_cast instead of m3_covert though. > From jkrell at elego.de Tue Jun 29 14:55:46 2010 From: jkrell at elego.de (Jay Krell) Date: Tue, 29 Jun 2010 14:55:46 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100629125546.839972474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/06/29 14:55:46 Modified files: cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c Log message: cleanup m3_do_fixed_extract, no temporaries (in parse.c, not the generated code) needed From jkrell at elego.de Tue Jun 29 15:12:41 2010 From: jkrell at elego.de (Jay Krell) Date: Tue, 29 Jun 2010 15:12:41 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100629131241.21AF12474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/06/29 15:12:41 Modified files: cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c Log message: This should cleanup configure -enable-checking a little more, regarding m3_do_fixed_extract, which is often used for integer division, signed and unsigned. The only change in m3core was a small optimization: +++ AMD64_DARWIN/RTTipe.ms 2010-06-29 05:59:08.000000000 -0700 @@ -3366,41 +3366,39 @@ .stabd 68,0,516 - movq -8(%rbp), %rax - sarq %rax - movq %rax, -8(%rbp) + sarq -8(%rbp) It is not all clear. The tree ended up with, as configure -enable-checking reports, two types, the input and output. -enable-checking demands they be the same. For the left shift, the type doesn't matter. For the right shift, I believe we want the possibly signed type. From jay.krell at cornell.edu Tue Jun 29 15:14:06 2010 From: jay.krell at cornell.edu (Jay K) Date: Tue, 29 Jun 2010 13:14:06 +0000 Subject: [M3commit] CVS Update: cm3 In-Reply-To: <20100629131241.21AF12474003@birch.elegosoft.com> References: <20100629131241.21AF12474003@birch.elegosoft.com> Message-ID: Index: gcc/gcc/m3cg/parse.c =================================================================== RCS file: /usr/cvs/cm3/m3-sys/m3cc/gcc/gcc/m3cg/parse.c,v retrieving revision 1.206 diff -u -r1.206 parse.c --- gcc/gcc/m3cg/parse.c??? 29 Jun 2010 12:55:45 -0000??? 1.206 +++ gcc/gcc/m3cg/parse.c??? 29 Jun 2010 13:09:39 -0000 @@ -4611,7 +4611,7 @@ ???????????????????????????? t); ???? } ? -? x = m3_convert (m3_unsigned_type (t), x); +? x = m3_convert (t, x); ?? x = (b ? m3_build2 (LSHIFT_EXPR, t, x, build_int_cst (t_int, b)) : x); ?? x = (a ? m3_build2 (RSHIFT_EXPR, t, x, build_int_cst (t_int, a)) : x); ?? return x; We might not need the convert, or cast might do. ?- Jay ---------------------------------------- > Date: Tue, 29 Jun 2010 15:12:41 +0000 > To: m3commit at elegosoft.com > From: jkrell at elego.de > Subject: [M3commit] CVS Update: cm3 > > CVSROOT: /usr/cvs > Changes by: jkrell at birch. 10/06/29 15:12:41 > > Modified files: > cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c > > Log message: > This should cleanup configure -enable-checking a little more, > regarding m3_do_fixed_extract, which is often used for > integer division, signed and unsigned. > > The only change in m3core was a small optimization: > +++ AMD64_DARWIN/RTTipe.ms 2010-06-29 05:59:08.000000000 -0700 > @@ -3366,41 +3366,39 @@ > .stabd 68,0,516 > - movq -8(%rbp), %rax > - sarq %rax > - movq %rax, -8(%rbp) > + sarq -8(%rbp) > > It is not all clear. > The tree ended up with, as configure -enable-checking reports, > two types, the input and output. -enable-checking demands > they be the same. For the left shift, the type doesn't matter. > For the right shift, I believe we want the possibly signed type. > From jkrell at elego.de Tue Jun 29 22:58:27 2010 From: jkrell at elego.de (Jay Krell) Date: Tue, 29 Jun 2010 22:58:27 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100629205827.4E3F02474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/06/29 22:58:27 Modified files: cm3/m3-sys/m3cc/gcc-4.5/gcc/: calls.c fold-const.c gimple.c gimplify.c tree-cfg.c tree-nested.c cm3/m3-sys/m3cc/gcc-4.5/gcc/config/i386/: i386.c Log message: checkpoint gcc 4.5 Modula-3 changes including: make some of configure -enable-checking always on making -enable-checking issue warnings instead of errors This can compile cm3 and run a bit of code in it, but does fail and needs further work. Will come back to this once gcc 4.3 -enable-checking is ok. From jay.krell at cornell.edu Tue Jun 29 23:01:43 2010 From: jay.krell at cornell.edu (Jay K) Date: Tue, 29 Jun 2010 21:01:43 +0000 Subject: [M3commit] CVS Update: cm3 In-Reply-To: <20100629205827.4E3F02474003@birch.elegosoft.com> References: <20100629205827.4E3F02474003@birch.elegosoft.com> Message-ID: diff attached ---------------------------------------- > Date: Tue, 29 Jun 2010 22:58:27 +0000 > To: m3commit at elegosoft.com > From: jkrell at elego.de > Subject: [M3commit] CVS Update: cm3 > > CVSROOT: /usr/cvs > Changes by: jkrell at birch. 10/06/29 22:58:27 > > Modified files: > cm3/m3-sys/m3cc/gcc-4.5/gcc/: calls.c fold-const.c gimple.c > gimplify.c tree-cfg.c > tree-nested.c > cm3/m3-sys/m3cc/gcc-4.5/gcc/config/i386/: i386.c > > Log message: > checkpoint gcc 4.5 Modula-3 changes > including: > make some of configure -enable-checking always on > making -enable-checking issue warnings instead of errors > > This can compile cm3 and run a bit of code in it, but does fail > and needs further work. Will come back to this once gcc 4.3 -enable-checking > is ok. > -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: m3cc45-1.txt URL: From jkrell at elego.de Tue Jun 1 03:54:56 2010 From: jkrell at elego.de (Jay Krell) Date: Tue, 1 Jun 2010 3:54:56 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100601015457.B38F92474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/06/01 03:54:56 Modified files: cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c Log message: leave m3cg_pop fixed and optimize the common subexpression, print more typenames in tracing (I meant to get them all the first time) From jkrell at elego.de Tue Jun 1 03:58:38 2010 From: jkrell at elego.de (Jay Krell) Date: Tue, 1 Jun 2010 3:58:38 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100601015838.8A8CB2474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/06/01 03:58:38 Modified files: cm3/m3-sys/m3front/src/builtinOps/: IsType.m3 Narrow.m3 Typecode.m3 Log message: do the tag checking using unsigned integers to satisfy m3cc/configure -enable-checking=all and wants the three types to all be the same (two inputs, one output) but we make the output unconditionally unsigned, so the inputs should also be unsigned this seems reasonable, but kind of reasonable either way From jay.krell at cornell.edu Tue Jun 1 04:02:21 2010 From: jay.krell at cornell.edu (Jay K) Date: Tue, 1 Jun 2010 02:02:21 +0000 Subject: [M3commit] CVS Update: cm3 In-Reply-To: References: <20100531113150.B02672474003@birch.elegosoft.com>, Message-ID: I've left it fixed. I can confirm that "side effects(t)" vs. "side efffects(expr(-1))" are often different. I didn't look closely at the resulting code/behavior. I might assert though that the new behavior only ever keeps stuff where the old behavior kept or threw out. That the new behavior isn't throwing stuff out that we kept. ?- Jay ---------------------------------------- > From: jay.krell at cornell.edu > To: jkrell at elego.de; m3commit at elegosoft.com > Date: Mon, 31 May 2010 11:35:07 +0000 > Subject: Re: [M3commit] CVS Update: cm3 > > > I accidentally fixed the m3cg_pop bug here. > That is a bug that might be dangerous to fix. > I'm going to put it back for now, and have -y output which path is taken so we can better > understand the impact of fixing it. > > - Jay > > > ---------------------------------------- >> Date: Mon, 31 May 2010 13:31:50 +0000 >> To: m3commit at elegosoft.com >> From: jkrell at elego.de >> Subject: [M3commit] CVS Update: cm3 >> >> CVSROOT: /usr/cvs >> Changes by: jkrell at birch. 10/05/31 13:31:50 >> >> Modified files: >> cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c >> >> Log message: >> include typenames in trace all -y output, and some altering of trace output >> > From jkrell at elego.de Tue Jun 1 04:29:26 2010 From: jkrell at elego.de (Jay Krell) Date: Tue, 1 Jun 2010 4:29:26 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100601022927.4AE2C2474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/06/01 04:29:26 Modified files: cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c Log message: Check that we don't throw out stuff that we previously kept. From jkrell at elego.de Tue Jun 1 04:35:47 2010 From: jkrell at elego.de (Jay Krell) Date: Tue, 1 Jun 2010 4:35:47 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100601023611.6F5962474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/06/01 04:35:47 Modified files: cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c Log message: remove some newlines in m3_build_type From jkrell at elego.de Tue Jun 1 04:42:47 2010 From: jkrell at elego.de (Jay Krell) Date: Tue, 1 Jun 2010 4:42:47 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100601024247.74F1F2474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/06/01 04:42:47 Modified files: cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c Log message: remove line I didn't mean to commit From jkrell at elego.de Tue Jun 1 04:48:06 2010 From: jkrell at elego.de (Jay Krell) Date: Tue, 1 Jun 2010 4:48:06 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100601024806.9C2952474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/06/01 04:48:06 Modified files: cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c Log message: combine common code in m3_build_type From jkrell at elego.de Tue Jun 1 05:51:04 2010 From: jkrell at elego.de (Jay Krell) Date: Tue, 1 Jun 2010 5:51:04 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100601035105.087862474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/06/01 05:51:04 Modified files: cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c Log message: use the provided typedef for get_alias_set for 4.3 use the default get_alias_set for 4.5; this would probably be good for 4.3 also From jkrell at elego.de Tue Jun 1 14:08:16 2010 From: jkrell at elego.de (Jay Krell) Date: Tue, 1 Jun 2010 14:08:16 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100601120816.90BA32474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/06/01 14:08:16 Modified files: cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c Log message: It turns out extracting 0 bits is allowed. Test p137 does it. I had put in an assert to disallow it. For this case, alwas return 0, rather than risk "over shifting". This seems to be correct per: http://www.cs.purdue.edu/homes/hosking/m3/reference/word-intf.html We take n (0) bits from the input and set the rest of the bits (all of them) to 0. From jkrell at elego.de Tue Jun 1 14:14:07 2010 From: jkrell at elego.de (Jay Krell) Date: Tue, 1 Jun 2010 14:14:07 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100601121407.1D6D72474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/06/01 14:14:07 Modified files: cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c Log message: parentheses around uses of macro parameters From jkrell at elego.de Tue Jun 1 14:15:01 2010 From: jkrell at elego.de (Jay Krell) Date: Tue, 1 Jun 2010 14:15:01 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100601121501.AF0032474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/06/01 14:15:01 Modified files: cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c Log message: spaces between macro parameters From jkrell at elego.de Tue Jun 1 14:16:57 2010 From: jkrell at elego.de (Jay Krell) Date: Tue, 1 Jun 2010 14:16:57 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100601121657.83A542474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/06/01 14:16:57 Modified files: cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c Log message: globals don't need to be initialized to 0, it is the default; removing the initialization is even sometimes an optimization, depending on the compiler From jkrell at elego.de Tue Jun 1 14:17:35 2010 From: jkrell at elego.de (Jay Krell) Date: Tue, 1 Jun 2010 14:17:35 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100601121735.F27552474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/06/01 14:17:35 Modified files: cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c Log message: globals don't need to be initialized to 0, it is the default; removing the initialization is even sometimes an optimization, depending on the compiler From jay.krell at cornell.edu Tue Jun 1 14:10:27 2010 From: jay.krell at cornell.edu (Jay K) Date: Tue, 1 Jun 2010 12:10:27 +0000 Subject: [M3commit] CVS Update: cm3 In-Reply-To: <20100601120816.90BA32474003@birch.elegosoft.com> References: <20100601120816.90BA32474003@birch.elegosoft.com> Message-ID: ---------------------------------------- > Date: Tue, 1 Jun 2010 14:08:16 +0000 > To: m3commit at elegosoft.com > From: jkrell at elego.de > Subject: [M3commit] CVS Update: cm3 > > CVSROOT: /usr/cvs > Changes by: jkrell at birch. 10/06/01 14:08:16 > > Modified files: > cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c > > Log message: > It turns out extracting 0 bits is allowed. > Test p137 does it. > I had put in an assert to disallow it. > For this case, alwas return 0, rather than risk "over shifting". > This seems to be correct per: > http://www.cs.purdue.edu/homes/hosking/m3/reference/word-intf.html > We take n (0) bits from the input and set the rest of the bits (all > of them) to 0. > -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: extract0w.txt URL: From jkrell at elego.de Tue Jun 1 14:29:54 2010 From: jkrell at elego.de (Jay Krell) Date: Tue, 1 Jun 2010 14:29:54 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100601122954.1877B2474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/06/01 14:29:54 Modified files: cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c Log message: minor: put space in -v output, add const, change char* to char[] to save the pointer From jkrell at elego.de Tue Jun 1 14:32:23 2010 From: jkrell at elego.de (Jay Krell) Date: Tue, 1 Jun 2010 14:32:23 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100601123224.33C842474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/06/01 14:32:23 Modified files: cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c Log message: major: remove the add_stmt from m3cg_pop Compiling m3core each way, and optimized and not, the only thing add_stmt does is add unnecessary code (and it survives optimization). Notice that for years the decision to call add_stmt wasn't right and nobody noticed, which isn't conclusive of course.. From jkrell at elego.de Tue Jun 1 14:42:00 2010 From: jkrell at elego.de (Jay Krell) Date: Tue, 1 Jun 2010 14:42:00 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100601124200.8E42B2474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/06/01 14:42:00 Modified files: cm3/m3-libs/m3core/src/convert/: Convert.m3 Log message: initialize locals; I get warnings that some not quite all, are used uninitialized if I remove the volatile/sideeffects on every load/store in parse.c From jkrell at elego.de Tue Jun 1 14:51:28 2010 From: jkrell at elego.de (Jay Krell) Date: Tue, 1 Jun 2010 14:51:28 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100601125128.A57962474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/06/01 14:51:28 Modified files: cm3/m3-libs/m3core/src/thread/PTHREAD/: ThreadPThread.m3 Log message: initialize locals, warning from modified compiler (though said compiler seems not always correct) From jkrell at elego.de Tue Jun 1 14:56:37 2010 From: jkrell at elego.de (Jay Krell) Date: Tue, 1 Jun 2010 14:56:37 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100601125637.8B97E2474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/06/01 14:56:37 Modified files: cm3/m3-libs/m3core/src/runtime/common/: RTCollector.m3 Log message: slight change due to compiler warning..but it definitely seemed ok before ? From jkrell at elego.de Tue Jun 1 15:35:43 2010 From: jkrell at elego.de (Jay Krell) Date: Tue, 1 Jun 2010 15:35:43 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100601133543.DBF162474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/06/01 15:35:43 Modified files: cm3/m3-libs/libm3/src/geometry/: PolyRegion.m3 cm3/m3-libs/libm3/src/os/POSIX/: ProcessPosixCommon.m3 cm3/m3-libs/libm3/src/rw/: Rd.m3 RdUtils.m3 Log message: initialize locals From jkrell at elego.de Tue Jun 1 16:39:36 2010 From: jkrell at elego.de (Jay Krell) Date: Tue, 1 Jun 2010 16:39:36 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100601143937.16D9D2474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/06/01 16:39:36 Modified files: cm3/m3-libs/m3core/src/runtime/common/: RTCollector.m3 Log message: go back a version, the compiler complaint was wrong and for now I have to be less aggressive because I can't figure out the problem in e.g. libm3/Formatter.m3 From jkrell at elego.de Tue Jun 1 20:19:51 2010 From: jkrell at elego.de (Jay Krell) Date: Tue, 1 Jun 2010 20:19:51 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100601181951.DD2792474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/06/01 20:19:51 Modified files: cm3/m3-libs/sysutils/src/: System.m3 Log message: fix use of uninitialized local From jkrell at elego.de Tue Jun 1 20:23:03 2010 From: jkrell at elego.de (Jay Krell) Date: Tue, 1 Jun 2010 20:23:03 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100601182303.817262474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/06/01 20:23:03 Modified files: cm3/m3-sys/m3back/src/: M3x86.m3 Log message: initialize locals From jkrell at elego.de Tue Jun 1 20:26:48 2010 From: jkrell at elego.de (Jay Krell) Date: Tue, 1 Jun 2010 20:26:48 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100601182648.7B8872474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/06/01 20:26:48 Modified files: cm3/m3-sys/m3front/src/misc/: Scanner.m3 Log message: initialize local: compiler is wrong but ok From jkrell at elego.de Tue Jun 1 21:12:38 2010 From: jkrell at elego.de (Jay Krell) Date: Tue, 1 Jun 2010 21:12:38 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100601191245.20AB82474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/06/01 21:12:38 Modified files: cm3/m3-ui/ui/src/vbt/: VBTClass.m3 Log message: initialize local: compiler is wrong but this is a classic case that compilers typically fail on From jkrell at elego.de Tue Jun 1 21:15:21 2010 From: jkrell at elego.de (Jay Krell) Date: Tue, 1 Jun 2010 21:15:21 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100601191522.F13A12474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/06/01 21:15:21 Modified files: cm3/m3-sys/m3tools/src/: M3Const.m3 Log message: initialize locals: compiler is wrong, but it would have to know that Err never returns in order to figure it out From jkrell at elego.de Tue Jun 1 21:43:03 2010 From: jkrell at elego.de (Jay Krell) Date: Tue, 1 Jun 2010 21:43:03 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100601194303.B89432474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/06/01 21:43:03 Modified files: cm3/m3-sys/cm3ide/src/misc/: BrowserDB.m3 Log message: fix use of uninitialized local that appears to occur if input file is malformed From jkrell at elego.de Tue Jun 1 21:47:28 2010 From: jkrell at elego.de (Jay Krell) Date: Tue, 1 Jun 2010 21:47:28 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100601194728.E93852474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/06/01 21:47:28 Modified files: cm3/m3-tools/m3tk/src/pl/: M3LTypeHash.m3 Log message: initialize local: I suspect compiler is wrong, but backend would have to know that the fault proc is noreturn, maybe that is doable? From jkrell at elego.de Tue Jun 1 21:48:32 2010 From: jkrell at elego.de (Jay Krell) Date: Tue, 1 Jun 2010 21:48:32 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100601194832.78F102474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/06/01 21:48:32 Modified files: cm3/m3-tools/m3tk/src/pl/: M3LTypeToText.m3 Log message: again, initialize local: I suspect compiler is wrong, but backend would have to know that the fault proc is noreturn, maybe that is doable? From jkrell at elego.de Tue Jun 1 22:13:01 2010 From: jkrell at elego.de (Jay Krell) Date: Tue, 1 Jun 2010 22:13:01 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100601201301.628802474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/06/01 22:13:01 Modified files: cm3/m3-sys/m3cc/src/: m3makefile Log message: clean also mpc and zlib directories, use the Makefile as the 'configure done' file From jkrell at elego.de Tue Jun 1 22:15:52 2010 From: jkrell at elego.de (Jay Krell) Date: Tue, 1 Jun 2010 22:15:52 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100601201552.484342474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/06/01 22:15:52 Modified files: cm3/m3-sys/m3cc/src/: m3makefile Log message: go back a version From jkrell at elego.de Tue Jun 1 22:21:53 2010 From: jkrell at elego.de (Jay Krell) Date: Tue, 1 Jun 2010 22:21:53 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100601202155.DC4412474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/06/01 22:21:53 Modified files: cm3/m3-sys/m3cc/gcc/gcc/: tree-ssa-sink.c Log message: fix uninitialized variable warning From hosking at cs.purdue.edu Tue Jun 1 23:13:35 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Tue, 1 Jun 2010 16:13:35 -0500 Subject: [M3commit] CVS Update: cm3 In-Reply-To: <20100601194832.78F102474003@birch.elegosoft.com> References: <20100601194832.78F102474003@birch.elegosoft.com> Message-ID: I don't understand what you are doing here. The compiler guarantees that all variables have a legal initial value. Sent from my iPhone On Jun 1, 2010, at 9:48 PM, jkrell at elego.de (Jay Krell) wrote: > CVSROOT: /usr/cvs > Changes by: jkrell at birch. 10/06/01 21:48:32 > > Modified files: > cm3/m3-tools/m3tk/src/pl/: M3LTypeToText.m3 > > Log message: > again, initialize local: I suspect compiler is wrong, but backend > would have to know that the fault proc is noreturn, maybe that is > doable? From hosking at cs.purdue.edu Tue Jun 1 23:29:20 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Tue, 1 Jun 2010 16:29:20 -0500 Subject: [M3commit] CVS Update: cm3 In-Reply-To: <20100601124200.8E42B2474003@birch.elegosoft.com> References: <20100601124200.8E42B2474003@birch.elegosoft.com> Message-ID: This is bogus. The M3 compiler guarantees all variables are initialized. Sent from my iPhone On Jun 1, 2010, at 2:42 PM, jkrell at elego.de (Jay Krell) wrote: > CVSROOT: /usr/cvs > Changes by: jkrell at birch. 10/06/01 14:42:00 > > Modified files: > cm3/m3-libs/m3core/src/convert/: Convert.m3 > > Log message: > initialize locals; I get warnings that some not quite all, are > used uninitialized if I remove the volatile/sideeffects on every > load/store in parse.c From jay.krell at cornell.edu Tue Jun 1 23:44:27 2010 From: jay.krell at cornell.edu (Jay K) Date: Tue, 1 Jun 2010 21:44:27 +0000 Subject: [M3commit] CVS Update: cm3 In-Reply-To: References: <20100601124200.8E42B2474003@birch.elegosoft.com>, Message-ID: Start removing the rampant use of volatile in the backend and these warnings show up. Volatile quashes the uninitialized checks in the backend. Is it really ok for an INTEGER to be uninitialized? I realize it contains an "integer" value, as all bit patterns are. Some of these really do seem like bugs. Some do not. I'll try making fault_proc noreturn, which should remove some of them. - Jay ---------------------------------------- > From: hosking at cs.purdue.edu > To: jkrell at elego.de > Date: Tue, 1 Jun 2010 16:29:20 -0500 > CC: m3commit at elegosoft.com > Subject: Re: [M3commit] CVS Update: cm3 > > This is bogus. The M3 compiler guarantees all variables are initialized. > > Sent from my iPhone > > On Jun 1, 2010, at 2:42 PM, jkrell at elego.de (Jay Krell) wrote: > >> CVSROOT: /usr/cvs >> Changes by: jkrell at birch. 10/06/01 14:42:00 >> >> Modified files: >> cm3/m3-libs/m3core/src/convert/: Convert.m3 >> >> Log message: >> initialize locals; I get warnings that some not quite all, are >> used uninitialized if I remove the volatile/sideeffects on every >> load/store in parse.c From hosking at cs.purdue.edu Wed Jun 2 02:04:00 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Tue, 1 Jun 2010 20:04:00 -0400 Subject: [M3commit] CVS Update: cm3 In-Reply-To: References: <20100601124200.8E42B2474003@birch.elegosoft.com>, Message-ID: <5458A114-F000-4A90-9998-FD7DF63E06C0@cs.purdue.edu> Sure, an INTEGER is a valid value whatever the bits. On 1 Jun 2010, at 17:44, Jay K wrote: > > Start removing the rampant use of volatile in the backend and these warnings show up. > > Volatile quashes the uninitialized checks in the backend. > > Is it really ok for an INTEGER to be uninitialized? I realize it contains an "integer" value, as all bit patterns are. > > Some of these really do seem like bugs. Some do not. > I'll try making fault_proc noreturn, which should remove some of them. > > > - Jay > > > > > ---------------------------------------- >> From: hosking at cs.purdue.edu >> To: jkrell at elego.de >> Date: Tue, 1 Jun 2010 16:29:20 -0500 >> CC: m3commit at elegosoft.com >> Subject: Re: [M3commit] CVS Update: cm3 >> >> This is bogus. The M3 compiler guarantees all variables are initialized. >> >> Sent from my iPhone >> >> On Jun 1, 2010, at 2:42 PM, jkrell at elego.de (Jay Krell) wrote: >> >>> CVSROOT: /usr/cvs >>> Changes by: jkrell at birch. 10/06/01 14:42:00 >>> >>> Modified files: >>> cm3/m3-libs/m3core/src/convert/: Convert.m3 >>> >>> Log message: >>> initialize locals; I get warnings that some not quite all, are >>> used uninitialized if I remove the volatile/sideeffects on every >>> load/store in parse.c From jay.krell at cornell.edu Wed Jun 2 02:10:02 2010 From: jay.krell at cornell.edu (Jay K) Date: Wed, 2 Jun 2010 00:10:02 +0000 Subject: [M3commit] CVS Update: cm3 In-Reply-To: <5458A114-F000-4A90-9998-FD7DF63E06C0@cs.purdue.edu> References: <20100601124200.8E42B2474003@birch.elegosoft.com>, , <5458A114-F000-4A90-9998-FD7DF63E06C0@cs.purdue.edu> Message-ID: ok, so in C: int F() { int i; return i; } should warn or not? Prevailing wisdom is definitely. Main known exception is code to generate random numbers. I believe this is how Debian broke key generation. Modula-3: PROCEDURE F(): INTEGER = VAR i: INTEGER; BEGIN RETURN i; END F; Should warn or not? Since this identical to the C, prevailing wisdom is definitely. They are, I guess, "safe", but most likely, incorrect. The compiler may have made "safety" guarantees, and they are significant, but safe is far from correct, and however smart the compiler can be to look for correctness issues, is also nice. (Friend of mine conjectured something like: Safety guarantees have people deluded. Software will still have plenty of bugs and be plenty difficult to get correct and require plenty of testing. Safety guarantees help, but they are only a small step toward actual correctness.) - Jay ---------------------------------------- > Subject: Re: [M3commit] CVS Update: cm3 > From: hosking at cs.purdue.edu > Date: Tue, 1 Jun 2010 20:04:00 -0400 > CC: jkrell at elego.de; m3commit at elegosoft.com > To: jay.krell at cornell.edu > > Sure, an INTEGER is a valid value whatever the bits. > > > On 1 Jun 2010, at 17:44, Jay K wrote: > >> >> Start removing the rampant use of volatile in the backend and these warnings show up. >> >> Volatile quashes the uninitialized checks in the backend. >> >> Is it really ok for an INTEGER to be uninitialized? I realize it contains an "integer" value, as all bit patterns are. >> >> Some of these really do seem like bugs. Some do not. >> I'll try making fault_proc noreturn, which should remove some of them. >> >> >> - Jay >> >> >> >> >> ---------------------------------------- >>> From: hosking at cs.purdue.edu >>> To: jkrell at elego.de >>> Date: Tue, 1 Jun 2010 16:29:20 -0500 >>> CC: m3commit at elegosoft.com >>> Subject: Re: [M3commit] CVS Update: cm3 >>> >>> This is bogus. The M3 compiler guarantees all variables are initialized. >>> >>> Sent from my iPhone >>> >>> On Jun 1, 2010, at 2:42 PM, jkrell at elego.de (Jay Krell) wrote: >>> >>>> CVSROOT: /usr/cvs >>>> Changes by: jkrell at birch. 10/06/01 14:42:00 >>>> >>>> Modified files: >>>> cm3/m3-libs/m3core/src/convert/: Convert.m3 >>>> >>>> Log message: >>>> initialize locals; I get warnings that some not quite all, are >>>> used uninitialized if I remove the volatile/sideeffects on every >>>> load/store in parse.c > From jkrell at elego.de Wed Jun 2 10:46:10 2010 From: jkrell at elego.de (Jay Krell) Date: Wed, 2 Jun 2010 10:46:10 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100602084610.BC8FE2474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/06/02 10:46:10 Modified files: cm3/m3-comm/tcp/src/POSIX/: TCP.m3 Log message: use socklen_t, not int socklen_t is chosen for convenience, not to match the underlying platform, therefore it is INTEGER or Word.T, and the underlying C wrappers copy back and forth From jkrell at elego.de Wed Jun 2 10:58:34 2010 From: jkrell at elego.de (Jay Krell) Date: Wed, 2 Jun 2010 10:58:34 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100602085835.0F7E12474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/06/02 10:58:34 Added files: cm3/m3-sys/cm3ide/: .cvsignore Log message: add .cvsignore From jkrell at elego.de Wed Jun 2 11:06:07 2010 From: jkrell at elego.de (Jay Krell) Date: Wed, 2 Jun 2010 11:06:07 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100602090607.22E0D2474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/06/02 11:06:07 Modified files: cm3/m3-sys/cm3ide/: .cvsignore Log message: add more From jkrell at elego.de Wed Jun 2 13:12:04 2010 From: jkrell at elego.de (Jay Krell) Date: Wed, 2 Jun 2010 13:12:04 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100602111204.108A92474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/06/02 13:12:04 Modified files: cm3/m3-sys/cminstall/src/config-no-install/: Unix.common Solaris.common Log message: just building cm3 for SOLgnu uses too many PIC slots for small PIC so go back to big PIC..I get the feeling ELF is kind of lame.. From jkrell at elego.de Wed Jun 2 15:27:06 2010 From: jkrell at elego.de (Jay Krell) Date: Wed, 2 Jun 2010 15:27:06 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100602132710.4A8F32474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/06/02 15:27:06 Modified files: cm3/m3-sys/m3cc/src/: m3makefile Log message: fill in a bunch of '-with-gnu-as -with-gnu-ld' for cross builds to e.g. avoid the warning that visibility isn't supported and is being ignored; use Makefile instead of .configure-done From jkrell at elego.de Wed Jun 2 15:50:29 2010 From: jkrell at elego.de (Jay Krell) Date: Wed, 2 Jun 2010 15:50:29 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100602135029.83AF42474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/06/02 15:50:29 Modified files: cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c Log message: in extract/insert_[m]n, trace m and n, under -y From jkrell at elego.de Wed Jun 2 15:59:40 2010 From: jkrell at elego.de (Jay Krell) Date: Wed, 2 Jun 2010 15:59:40 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100602135940.380512474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/06/02 15:59:40 Modified files: cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c Log message: a little reformating, mainly newlines before and after the tracing code From jkrell at elego.de Wed Jun 2 16:04:51 2010 From: jkrell at elego.de (Jay Krell) Date: Wed, 2 Jun 2010 16:04:51 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100602140451.6B6782474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/06/02 16:04:51 Modified files: cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c Log message: a tiny bit more reformat From hosking at cs.purdue.edu Wed Jun 2 16:38:59 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Wed, 2 Jun 2010 10:38:59 -0400 Subject: [M3commit] CVS Update: cm3 In-Reply-To: References: <20100601124200.8E42B2474003@birch.elegosoft.com>, , <5458A114-F000-4A90-9998-FD7DF63E06C0@cs.purdue.edu> Message-ID: C provides no guarantees about initialisation. Modula-3 requires that all variables be initialised (explicitly or by the compiler) as necessary to ensure they have a valid value for their type. So, basically, the warning you are getting from the gcc backend is not pertinent to Modula-3. On 1 Jun 2010, at 20:10, Jay K wrote: > > ok, so in C: > > int F() > { > int i; > return i; > } > > should warn or not? > Prevailing wisdom is definitely. > Main known exception is code to generate random numbers. > I believe this is how Debian broke key generation. > > > Modula-3: > > > PROCEDURE F(): INTEGER = > VAR i: INTEGER; > BEGIN > RETURN i; > END F; > > > Should warn or not? > Since this identical to the C, prevailing wisdom is definitely. No, because Modula-3 guarantees the value of i is valid for the type. It could be a random value of bits in this case because all bit combinations are valid for a Modula-3 INTEGER. If you tried something like a subrange [0..3] then you will see explicit initialisation with a value in the range [0..3]. > They are, I guess, "safe", but most likely, incorrect. > > > The compiler may have made "safety" guarantees, and they are significant, > but safe is far from correct, and however smart the compiler can be to look for correctness issues, is also nice. You are living in C land. > (Friend of mine conjectured something like: Safety guarantees have people deluded. Software will still have plenty of bugs and be plenty difficult to get correct and require plenty of testing. Safety guarantees help, but they are only a small step toward actual correctness.) > > > > - Jay > > > ---------------------------------------- >> Subject: Re: [M3commit] CVS Update: cm3 >> From: hosking at cs.purdue.edu >> Date: Tue, 1 Jun 2010 20:04:00 -0400 >> CC: jkrell at elego.de; m3commit at elegosoft.com >> To: jay.krell at cornell.edu >> >> Sure, an INTEGER is a valid value whatever the bits. >> >> >> On 1 Jun 2010, at 17:44, Jay K wrote: >> >>> >>> Start removing the rampant use of volatile in the backend and these warnings show up. >>> >>> Volatile quashes the uninitialized checks in the backend. >>> >>> Is it really ok for an INTEGER to be uninitialized? I realize it contains an "integer" value, as all bit patterns are. >>> >>> Some of these really do seem like bugs. Some do not. >>> I'll try making fault_proc noreturn, which should remove some of them. >>> >>> >>> - Jay >>> >>> >>> >>> >>> ---------------------------------------- >>>> From: hosking at cs.purdue.edu >>>> To: jkrell at elego.de >>>> Date: Tue, 1 Jun 2010 16:29:20 -0500 >>>> CC: m3commit at elegosoft.com >>>> Subject: Re: [M3commit] CVS Update: cm3 >>>> >>>> This is bogus. The M3 compiler guarantees all variables are initialized. >>>> >>>> Sent from my iPhone >>>> >>>> On Jun 1, 2010, at 2:42 PM, jkrell at elego.de (Jay Krell) wrote: >>>> >>>>> CVSROOT: /usr/cvs >>>>> Changes by: jkrell at birch. 10/06/01 14:42:00 >>>>> >>>>> Modified files: >>>>> cm3/m3-libs/m3core/src/convert/: Convert.m3 >>>>> >>>>> Log message: >>>>> initialize locals; I get warnings that some not quite all, are >>>>> used uninitialized if I remove the volatile/sideeffects on every >>>>> load/store in parse.c >> From jkrell at elego.de Wed Jun 2 18:35:40 2010 From: jkrell at elego.de (Jay Krell) Date: Wed, 2 Jun 2010 18:35:40 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100602163540.ABBFE2474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/06/02 18:35:40 Modified files: cm3/m3-sys/m3cc/src/: platforms.quake Log message: bump cross target=Solaris/sparc32 builds from 'solaris2' to 'solaris2.10'; native builds worked and this *seemed* to do it, still more to look into though (try 2.8, try removing volatils, try enabling 'gas weak', another difference I noticed between cross and native..this all goes to show, autoconf totally breaks down in the fact of cross builds, would be good to just not use it...oh well) From jkrell at elego.de Wed Jun 2 18:58:16 2010 From: jkrell at elego.de (Jay Krell) Date: Wed, 2 Jun 2010 18:58:16 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100602165816.E672F2474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/06/02 18:58:16 Modified files: cm3/scripts/python/: pylib.py Log message: print posixy 'export' instead of win32 'set' when on posix From jkrell at elego.de Wed Jun 2 18:59:55 2010 From: jkrell at elego.de (Jay Krell) Date: Wed, 2 Jun 2010 18:59:55 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100602165955.30FCD2474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/06/02 18:59:55 Modified files: cm3/scripts/python/: pylib.py Log message: print posixy 'unset' when clearing, I really don't understand the sh nuances though, I guess variable can be defined to be empty..but which shells do support unset? anyway, this is just printed for human to see approximation of internal actions, it's not actual executed From jkrell at elego.de Wed Jun 2 19:30:51 2010 From: jkrell at elego.de (Jay Krell) Date: Wed, 2 Jun 2010 19:30:51 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100602173051.643522474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/06/02 19:30:51 Modified files: cm3/m3-sys/m3cc/src/: m3makefile Log message: update Solaris and sparc64 non-auto-conf (add 'gas weak'), fix typo in comment From jkrell at elego.de Wed Jun 2 20:31:34 2010 From: jkrell at elego.de (Jay Krell) Date: Wed, 2 Jun 2010 20:31:34 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100602183134.99E862474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/06/02 20:31:34 Modified files: cm3/m3-sys/m3cc/gcc/gcc/config/: sol2.h cm3/m3-sys/m3cc/gcc/gcc/config/sparc/: sparc.h cm3/m3-sys/m3cc/gcc/gcc/m3cg/: m3gty43.h m3gty45.h parse.c Log message: significantly remove use of volatile Allowing the optimizer to actually do anything volatile remains on Solaris/sparc32 probably just need to experiment extensively volatile remains on all floating point loads, quite unfortunate for the scientific computing crowed.. volatile is added to more locals and temporaries within functions that call setjmp/vfork (setjmp is very common!?) volatile store after insert_mn, small lame hack, because otherwise we have a read before write a few optimizations are turned off, though I did solve the "unit at a time" problem, with TREE_USED or so I thought, but no...I had confused "ui" and "vbtkit" packages prototype marking fault_proc as noreturn but then I get a warning that it does return, even if I removed the return Provide and use m3_build_pointer_type that presently is pointless, but maybe will mean something in future There is a bit to turn off alias analysis. pre/fre still crashed. I didn't try vrp, it is the most painful to test when it goes wrong, because it successfully compiles everything. Mostly tested on AMD64_DARWIN. Needs broader coverage. Need to consider the warnings it causes. Need to get fault_proc marked noreturn first. Could use better for Solaris/sparc32, but machine is so slow experimentation is painful. From jkrell at elego.de Wed Jun 2 20:34:52 2010 From: jkrell at elego.de (Jay Krell) Date: Wed, 2 Jun 2010 20:34:52 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100602183452.399A22474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/06/02 20:34:52 Modified files: cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c Log message: fix accidental wierd bad form, might even help bring back the nested function that gets optimized out?? probably not but worth more trying or investigation.. From jay.krell at cornell.edu Wed Jun 2 20:35:51 2010 From: jay.krell at cornell.edu (Jay K) Date: Wed, 2 Jun 2010 18:35:51 +0000 Subject: [M3commit] CVS Update: cm3 In-Reply-To: <20100602183134.99E862474003@birch.elegosoft.com> References: <20100602183134.99E862474003@birch.elegosoft.com> Message-ID: Basically the same as before. ?- Jay ---------------------------------------- > Date: Wed, 2 Jun 2010 20:31:34 +0000 > To: m3commit at elegosoft.com > From: jkrell at elego.de > Subject: [M3commit] CVS Update: cm3 > > CVSROOT: /usr/cvs > Changes by: jkrell at birch. 10/06/02 20:31:34 > > Modified files: > cm3/m3-sys/m3cc/gcc/gcc/config/: sol2.h > cm3/m3-sys/m3cc/gcc/gcc/config/sparc/: sparc.h > cm3/m3-sys/m3cc/gcc/gcc/m3cg/: m3gty43.h m3gty45.h parse.c > > Log message: > significantly remove use of volatile > Allowing the optimizer to actually do anything > > volatile remains on Solaris/sparc32 > probably just need to experiment extensively > > volatile remains on all floating point loads, > quite unfortunate for the scientific computing crowed.. > > volatile is added to more locals and temporaries > within functions that call setjmp/vfork > (setjmp is very common!?) > > volatile store after insert_mn, small lame hack, > because otherwise we have a read before write > > a few optimizations are turned off, > though I did solve the "unit at a time" problem, with TREE_USED > or so I thought, but no...I had confused "ui" and "vbtkit" packages > > prototype marking fault_proc as noreturn > but then I get a warning that it does return, > even if I removed the return > > Provide and use m3_build_pointer_type that presently is pointless, > but maybe will mean something in future > There is a bit to turn off alias analysis. > pre/fre still crashed. I didn't try vrp, it is > the most painful to test when it goes wrong, because > it successfully compiles everything. > > Mostly tested on AMD64_DARWIN. > Needs broader coverage. > Need to consider the warnings it causes. > Need to get fault_proc marked noreturn first. > Could use better for Solaris/sparc32, but machine > is so slow experimentation is painful. > -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: volatile1.txt URL: From jkrell at elego.de Fri Jun 4 07:51:20 2010 From: jkrell at elego.de (Jay Krell) Date: Fri, 4 Jun 2010 7:51:20 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100604055121.8B2652474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/06/04 07:51:20 Modified files: cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c Log message: add m3_load_volatile, not currently used, but I get tired of putting it in to experiment, taking it out, repeat, etc. From jkrell at elego.de Fri Jun 4 17:41:45 2010 From: jkrell at elego.de (Jay Krell) Date: Fri, 4 Jun 2010 17:41:45 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100604154145.DC6CE2474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/06/04 17:41:45 Modified files: cm3/m3-sys/m3cc/gcc/gcc/m3cg/: Tag: release_branch_cm3_5_8 parse.c Log message: Port unfortunate fix from head, unless/until a better fix is found. The program: MODULE Main; PROCEDURE F1() = PROCEDURE NestedUnused1() = BEGIN END NestedUnused1; BEGIN IF FALSE THEN NestedUnused1(); END; END F1; BEGIN F1(); END Main. fails to link with: Undefined symbols: "_Main__F1__NestedUnused1.496", referenced from: _L_1 in Main.mo unless we do: flag_unit_at_a_time = 0; in parse.c From jkrell at elego.de Fri Jun 4 17:43:56 2010 From: jkrell at elego.de (Jay Krell) Date: Fri, 4 Jun 2010 17:43:56 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100604154356.5BFFE2474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/06/04 17:43:56 Modified files: cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c Log message: make comment match release regarding unit_at_a_time From jkrell at elego.de Fri Jun 4 18:15:09 2010 From: jkrell at elego.de (Jay Krell) Date: Fri, 4 Jun 2010 18:15:09 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100604161520.CB0D02474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/06/04 18:15:09 Modified files: cm3/m3-sys/m3cc/gcc/gcc/m3cg/: Tag: release_branch_cm3_5_8 parse.c Log message: turn off "pre" optimization, which crashes compiling m3-tools/cvsup/server/FSServer.m3 From jkrell at elego.de Fri Jun 4 18:18:09 2010 From: jkrell at elego.de (Jay Krell) Date: Fri, 4 Jun 2010 18:18:09 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100604161809.670FC2474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/06/04 18:18:09 Modified files: cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c Log message: always turn off "pre" (partial redundancy elimination), even when there is a stack walker, as it crashes on release Testing on Solaris/sparc32 would be appropriate though to see if it causes compiler crash there (or just doing cross build) From jkrell at elego.de Fri Jun 4 18:18:55 2010 From: jkrell at elego.de (Jay Krell) Date: Fri, 4 Jun 2010 18:18:55 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100604161855.1E6232474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/06/04 18:18:55 Modified files: cm3/m3-sys/m3cc/gcc/gcc/m3cg/: Tag: release_branch_cm3_5_8 parse.c Log message: adjust comment: spell out 'pre' means From hosking at cs.purdue.edu Fri Jun 4 18:36:24 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Fri, 4 Jun 2010 12:36:24 -0400 Subject: [M3commit] CVS Update: cm3 In-Reply-To: <20100604161520.CB0D02474003@birch.elegosoft.com> References: <20100604161520.CB0D02474003@birch.elegosoft.com> Message-ID: <06C73A71-2ECD-4EA2-BE48-52A573DCAFF3@cs.purdue.edu> Are you planning to go through and fix things so we can re-enable optimisations? I worked pretty hard to get everything to compile with -O2/-O3 when I worked on this with the current m3cg. Antony Hosking | Associate Professor | Computer Science | Purdue University 305 N. University Street | West Lafayette | IN 47907 | USA Office +1 765 494 6001 | Mobile +1 765 427 5484 On 4 Jun 2010, at 18:15, Jay Krell wrote: > CVSROOT: /usr/cvs > Changes by: jkrell at birch. 10/06/04 18:15:09 > > Modified files: > cm3/m3-sys/m3cc/gcc/gcc/m3cg/: Tag: release_branch_cm3_5_8 > parse.c > > Log message: > turn off "pre" optimization, which crashes compiling > m3-tools/cvsup/server/FSServer.m3 -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Fri Jun 4 19:16:35 2010 From: jay.krell at cornell.edu (Jay K) Date: Fri, 4 Jun 2010 17:16:35 +0000 Subject: [M3commit] CVS Update: cm3 In-Reply-To: <06C73A71-2ECD-4EA2-BE48-52A573DCAFF3@cs.purdue.edu> References: <20100604161520.CB0D02474003@birch.elegosoft.com>, <06C73A71-2ECD-4EA2-BE48-52A573DCAFF3@cs.purdue.edu> Message-ID: Unclear. I've also worked very hard at this and I believe it is in better shape than before. Granted, some steps forward, some backward. But I think much more forward. I'm using -O3. Sometimes what I do is in parse.c I explicitly enable everything but setting all the flags. We should perhaps do that anyway, esp. for optimizations that don't take long and don't hurt debugging. I suspect these two bugs were present back then, you just didn't hit them because: 1) we didn't have the unused nested function? 2) we didn't have cvsup? I disabled very very little. In trade, we don't throw around volatile all over the place. I think if you look into it, things were broken back then just the same. But we didn't have the code to tickle the bugs. I would like to get back "unit at a time". That seems a good optimization wrt inlining and it is being disabled for something that should be easily fixable some other way. vrp/fre/pre I don't know. It'll take quite some debugging to fix those. vrp produces bad code. fre and/or pre crash in the compiler. I'd also like to fix the volatile float problem. I've worked on that quite a bit too. I tried to make loophole always go through a volatile temporary for example. I tried making loophole go through a union. No luck yet. I guess I should see what: int a; float j; a = *(int*)&j; does in C. Notice that some of this is in the release branch. Where all I've done is test more code. I didn't remove the volatility on all load/store for example. - Jay ________________________________ > From: hosking at cs.purdue.edu > Date: Fri, 4 Jun 2010 12:36:24 -0400 > To: jkrell at elego.de > CC: m3commit at elegosoft.com > Subject: Re: [M3commit] CVS Update: cm3 > > > > Are you planning to go through and fix things so we can re-enable optimisations? > > I worked pretty hard to get everything to compile with -O2/-O3 when I worked on this with the current m3cg. > > > Antony Hosking | Associate Professor | Computer Science | Purdue University > 305 N. University Street | West Lafayette | IN 47907 | USA > Office +1 765 494 6001 | Mobile +1 765 427 5484 > > > > > > > On 4 Jun 2010, at 18:15, Jay Krell wrote: > > CVSROOT: /usr/cvs > Changes by: jkrell at birch. 10/06/04 18:15:09 > > Modified files: > cm3/m3-sys/m3cc/gcc/gcc/m3cg/: Tag: release_branch_cm3_5_8 > parse.c > > Log message: > turn off "pre" optimization, which crashes compiling > m3-tools/cvsup/server/FSServer.m3 > From hosking at cs.purdue.edu Fri Jun 4 19:58:59 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Fri, 4 Jun 2010 13:58:59 -0400 Subject: [M3commit] CVS Update: cm3 In-Reply-To: References: <20100604161520.CB0D02474003@birch.elegosoft.com>, <06C73A71-2ECD-4EA2-BE48-52A573DCAFF3@cs.purdue.edu> Message-ID: Cool. Thanks for putting the time in on this. On 4 Jun 2010, at 13:16, Jay K wrote: > > Unclear. I've also worked very hard at this and I believe it is in better shape than before. > Granted, some steps forward, some backward. But I think much more forward. > > I'm using -O3. > Sometimes what I do is in parse.c I explicitly enable everything but setting all the flags. > We should perhaps do that anyway, esp. for optimizations that don't take long and don't hurt debugging. > > > I suspect these two bugs were present back then, you just didn't hit them because: > 1) we didn't have the unused nested function? > 2) we didn't have cvsup? > > > I disabled very very little. > In trade, we don't throw around volatile all over the place. > > > I think if you look into it, things were broken back then just the same. > But we didn't have the code to tickle the bugs. > > > I would like to get back "unit at a time". That seems a good optimization wrt inlining and it is being disabled for something that should be easily fixable some other way. > > > vrp/fre/pre I don't know. > It'll take quite some debugging to fix those. > vrp produces bad code. > fre and/or pre crash in the compiler. > > > I'd also like to fix the volatile float problem. I've worked on that quite a bit too. > I tried to make loophole always go through a volatile temporary for example. > I tried making loophole go through a union. > No luck yet. > I guess I should see what: > int a; > float j; > a = *(int*)&j; > > > does in C. > > > Notice that some of this is in the release branch. Where all I've done is test more code. > I didn't remove the volatility on all load/store for example. > > > - Jay > > > ________________________________ >> From: hosking at cs.purdue.edu >> Date: Fri, 4 Jun 2010 12:36:24 -0400 >> To: jkrell at elego.de >> CC: m3commit at elegosoft.com >> Subject: Re: [M3commit] CVS Update: cm3 >> >> >> >> Are you planning to go through and fix things so we can re-enable optimisations? >> >> I worked pretty hard to get everything to compile with -O2/-O3 when I worked on this with the current m3cg. >> >> >> Antony Hosking | Associate Professor | Computer Science | Purdue University >> 305 N. University Street | West Lafayette | IN 47907 | USA >> Office +1 765 494 6001 | Mobile +1 765 427 5484 >> >> >> >> >> >> >> On 4 Jun 2010, at 18:15, Jay Krell wrote: >> >> CVSROOT: /usr/cvs >> Changes by: jkrell at birch. 10/06/04 18:15:09 >> >> Modified files: >> cm3/m3-sys/m3cc/gcc/gcc/m3cg/: Tag: release_branch_cm3_5_8 >> parse.c >> >> Log message: >> turn off "pre" optimization, which crashes compiling >> m3-tools/cvsup/server/FSServer.m3 >> From jkrell at elego.de Sat Jun 5 19:15:44 2010 From: jkrell at elego.de (Jay Krell) Date: Sat, 5 Jun 2010 19:15:44 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100605171544.E92B8CC37F@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/06/05 19:15:44 Modified files: cm3/m3-sys/m3middle/src/: Target.i3 Target.m3 Log message: restore ALPHA_OSF, but this time probably without stack walker just because I'm lazy, and resort the list again, it was only slightly unsorted From jkrell at elego.de Sat Jun 5 19:16:57 2010 From: jkrell at elego.de (Jay Krell) Date: Sat, 5 Jun 2010 19:16:57 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100605171657.98A79CC37F@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/06/05 19:16:57 Modified files: cm3/m3-libs/libm3/src/: platforms.quake Log message: restore ALPHA_OSF some day I will merge all this data into fewer places.. From jkrell at elego.de Sat Jun 5 19:19:26 2010 From: jkrell at elego.de (Jay Krell) Date: Sat, 5 Jun 2010 19:19:26 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100605171926.CF283CC37F@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/06/05 19:19:26 Added files: cm3/m3-libs/m3core/src/runtime/ALPHA_OSF/: m3makefile-old Removed files: cm3/m3-libs/m3core/src/runtime/ALPHA_OSF/: m3makefile Log message: rename m3makefile => m3makefile-old, so the common directory will notice no m3makefile and give us the portable files I'm omitting the stack walker, at least "for now", but realistically, probably the target-specific code will never come back, hopefully we'll have a somewhat portable stack walker using libunwind/libgcc/m3cc, at least on platforms that have libgcc, which is almost all From jkrell at elego.de Sat Jun 5 19:20:20 2010 From: jkrell at elego.de (Jay Krell) Date: Sat, 5 Jun 2010 19:20:20 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100605172020.BAA5C2474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/06/05 19:20:20 Modified files: cm3/m3-libs/m3core/src/unix/Common/: Usocket.c Log message: more information when there is an assertion failure From jkrell at elego.de Sat Jun 5 19:21:27 2010 From: jkrell at elego.de (Jay Krell) Date: Sat, 5 Jun 2010 19:21:27 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100605172127.E6C352474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/06/05 19:21:27 Modified files: cm3/m3-libs/m3core/src/: platforms.quake Log message: add ALPHA_OSF Really need to consolidate these lists.. From jkrell at elego.de Sat Jun 5 19:22:16 2010 From: jkrell at elego.de (Jay Krell) Date: Sat, 5 Jun 2010 19:22:16 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100605172216.74A412474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/06/05 19:22:16 Modified files: cm3/scripts/python/: pylib.py Log message: some suppoft for ALPHA_OSF, more needed here, soon later From jkrell at elego.de Sat Jun 5 19:24:37 2010 From: jkrell at elego.de (Jay Krell) Date: Sat, 5 Jun 2010 19:24:37 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100605172437.4C96E2474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/06/05 19:24:37 Modified files: cm3/m3-sys/m3cc/src/: platforms.quake Log message: upgrade from 'osf1' to 'osf5.1' From jkrell at elego.de Sat Jun 5 19:41:54 2010 From: jkrell at elego.de (Jay Krell) Date: Sat, 5 Jun 2010 19:41:54 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100605174155.0CAF4CC380@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/06/05 19:41:54 Modified files: cm3/m3-sys/m3cc/src/: m3makefile Log message: add -e flag on sh invocations; there is a problem here that when compilation/link fails, cm3 still succeeds, this doesn't seem to fix it, gr. From jkrell at elego.de Sat Jun 5 19:43:03 2010 From: jkrell at elego.de (Jay Krell) Date: Sat, 5 Jun 2010 19:43:03 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100605174303.54535CC380@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/06/05 19:43:03 Modified files: cm3/m3-libs/m3core/src/unix/: m3makefile Log message: add ALPHA_OSF From jkrell at elego.de Sat Jun 5 19:49:37 2010 From: jkrell at elego.de (Jay Krell) Date: Sat, 5 Jun 2010 19:49:37 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100605174938.717592474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/06/05 19:49:37 Modified files: cm3/m3-libs/libm3/src/os/POSIX/: m3makefile Log message: 'OSF' => 'Digital Unix', as we had for 'TRU64' From hosking at cs.purdue.edu Sat Jun 5 21:24:33 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sat, 5 Jun 2010 15:24:33 -0400 Subject: [M3commit] CVS Update: cm3 In-Reply-To: <20100605171544.E92B8CC37F@birch.elegosoft.com> References: <20100605171544.E92B8CC37F@birch.elegosoft.com> Message-ID: Please restore the stack walker. ALPHA_OSF is the one platform that does this properly! On 5 Jun 2010, at 19:15, Jay Krell wrote: > CVSROOT: /usr/cvs > Changes by: jkrell at birch. 10/06/05 19:15:44 > > Modified files: > cm3/m3-sys/m3middle/src/: Target.i3 Target.m3 > > Log message: > restore ALPHA_OSF, but this time probably without stack walker > just because I'm lazy, and resort the list again, it was only > slightly unsorted From jay.krell at cornell.edu Sat Jun 5 21:30:18 2010 From: jay.krell at cornell.edu (Jay K) Date: Sat, 5 Jun 2010 19:30:18 +0000 Subject: [M3commit] CVS Update: cm3 In-Reply-To: References: <20100605171544.E92B8CC37F@birch.elegosoft.com>, Message-ID: Solaris/sparc32 isn't enough to keep it alive? It's just that I have to restore the header cloning in m3core/src/unix. ?- Jay ---------------------------------------- > From: hosking at cs.purdue.edu > Date: Sat, 5 Jun 2010 15:24:33 -0400 > To: jkrell at elego.de > CC: m3commit at elegosoft.com > Subject: Re: [M3commit] CVS Update: cm3 > > Please restore the stack walker. ALPHA_OSF is the one platform that does this properly! > > > On 5 Jun 2010, at 19:15, Jay Krell wrote: > >> CVSROOT: /usr/cvs >> Changes by: jkrell at birch. 10/06/05 19:15:44 >> >> Modified files: >> cm3/m3-sys/m3middle/src/: Target.i3 Target.m3 >> >> Log message: >> restore ALPHA_OSF, but this time probably without stack walker >> just because I'm lazy, and resort the list again, it was only >> slightly unsorted > From hosking at cs.purdue.edu Sat Jun 5 23:44:35 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sat, 5 Jun 2010 17:44:35 -0400 Subject: [M3commit] CVS Update: cm3 In-Reply-To: References: <20100605171544.E92B8CC37F@birch.elegosoft.com>, Message-ID: <94F17EE8-B6FD-4B93-9FD4-4275AC0C64D0@cs.purdue.edu> I suppose. Though it does illustrate how the system can more properly support unwinding using a suitable API. On 5 Jun 2010, at 15:30, Jay K wrote: > > Solaris/sparc32 isn't enough to keep it alive? > It's just that I have to restore the header cloning in m3core/src/unix. > > - Jay > > ---------------------------------------- >> From: hosking at cs.purdue.edu >> Date: Sat, 5 Jun 2010 15:24:33 -0400 >> To: jkrell at elego.de >> CC: m3commit at elegosoft.com >> Subject: Re: [M3commit] CVS Update: cm3 >> >> Please restore the stack walker. ALPHA_OSF is the one platform that does this properly! >> >> >> On 5 Jun 2010, at 19:15, Jay Krell wrote: >> >>> CVSROOT: /usr/cvs >>> Changes by: jkrell at birch. 10/06/05 19:15:44 >>> >>> Modified files: >>> cm3/m3-sys/m3middle/src/: Target.i3 Target.m3 >>> >>> Log message: >>> restore ALPHA_OSF, but this time probably without stack walker >>> just because I'm lazy, and resort the list again, it was only >>> slightly unsorted >> > From jkrell at elego.de Sat Jun 5 20:47:41 2010 From: jkrell at elego.de (Jay Krell) Date: Sat, 5 Jun 2010 20:47:41 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100605184741.A2F562474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/06/05 20:47:41 Modified files: cm3/m3-libs/libm3/src/uid/POSIX/: MachineIDPosixC.c Log message: enable/test/fix the OSF1 case From jay.krell at cornell.edu Sun Jun 6 00:22:42 2010 From: jay.krell at cornell.edu (Jay K) Date: Sat, 5 Jun 2010 22:22:42 +0000 Subject: [M3commit] CVS Update: cm3 In-Reply-To: <94F17EE8-B6FD-4B93-9FD4-4275AC0C64D0@cs.purdue.edu> References: <20100605171544.E92B8CC37F@birch.elegosoft.com>, , , , <94F17EE8-B6FD-4B93-9FD4-4275AC0C64D0@cs.purdue.edu> Message-ID: I'll probably put it back. Esp. if it works the first time I try. ?- Jay ---------------------------------------- > From: hosking at cs.purdue.edu > Date: Sat, 5 Jun 2010 17:44:35 -0400 > To: jay.krell at cornell.edu > CC: m3commit at elegosoft.com > Subject: Re: [M3commit] CVS Update: cm3 > > I suppose. Though it does illustrate how the system can more properly support unwinding using a suitable API. > > On 5 Jun 2010, at 15:30, Jay K wrote: > >> >> Solaris/sparc32 isn't enough to keep it alive? >> It's just that I have to restore the header cloning in m3core/src/unix. >> >> - Jay >> >> ---------------------------------------- >>> From: hosking at cs.purdue.edu >>> Date: Sat, 5 Jun 2010 15:24:33 -0400 >>> To: jkrell at elego.de >>> CC: m3commit at elegosoft.com >>> Subject: Re: [M3commit] CVS Update: cm3 >>> >>> Please restore the stack walker. ALPHA_OSF is the one platform that does this properly! >>> >>> >>> On 5 Jun 2010, at 19:15, Jay Krell wrote: >>> >>>> CVSROOT: /usr/cvs >>>> Changes by: jkrell at birch. 10/06/05 19:15:44 >>>> >>>> Modified files: >>>> cm3/m3-sys/m3middle/src/: Target.i3 Target.m3 >>>> >>>> Log message: >>>> restore ALPHA_OSF, but this time probably without stack walker >>>> just because I'm lazy, and resort the list again, it was only >>>> slightly unsorted >>> >> > From jkrell at elego.de Sun Jun 6 02:12:14 2010 From: jkrell at elego.de (Jay Krell) Date: Sun, 6 Jun 2010 2:12:14 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100606001214.EA6BC2474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/06/06 02:12:14 Modified files: cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c Log message: change #ifdef GCC42 to #if GCC42 and if GCC42, but not real change, at this point From jkrell at elego.de Sun Jun 6 02:28:09 2010 From: jkrell at elego.de (Jay Krell) Date: Sun, 6 Jun 2010 2:28:09 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100606002809.E4C452474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/06/06 02:28:09 Modified files: cm3/m3-libs/m3core/src/runtime/POSIX/: test_signal.c Log message: make the test case even better, and even better; that is, first I made it print too 'close' numbers, the address of a function and the crashing address, but then, even better, jump to a hardcoded constant, we should crash at that place From jkrell at elego.de Sun Jun 6 02:42:29 2010 From: jkrell at elego.de (Jay Krell) Date: Sun, 6 Jun 2010 2:42:29 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100606004230.77EE12474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/06/06 02:42:29 Modified files: cm3/m3-libs/m3core/src/runtime/POSIX/: RTSignalC.c Log message: adapt for ALPHA_OSF The printed value is not the "controlled" value, and is only in the vague vicinity of another possible one -- the calling function..a little worrisome, might want to revisit, but this doesn't really have to work, it is just for printing where crashes occured and on some platforms we just return NULL. From jkrell at elego.de Sun Jun 6 02:50:16 2010 From: jkrell at elego.de (Jay Krell) Date: Sun, 6 Jun 2010 2:50:16 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100606005017.187962474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/06/06 02:50:16 Modified files: cm3/m3-libs/m3core/src/: m3core.h Log message: adaptions for ALPHA_OSF: - gcc doesn't support visibility here - socklen_t is only typedefed if you #define something, which at this point I'm not going to to, typedef socklen_t myself instead From jkrell at elego.de Sun Jun 6 03:21:54 2010 From: jkrell at elego.de (Jay Krell) Date: Sun, 6 Jun 2010 3:21:54 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100606012159.2A3762474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/06/06 03:21:54 Modified files: cm3/m3-sys/cminstall/src/config/: ALPHA_OSF Added files: cm3/m3-sys/cminstall/src/config-no-install/: ALPHA_OSF Log message: initial version in slightly new form and stub out old one like others already are From jkrell at elego.de Sun Jun 6 17:08:39 2010 From: jkrell at elego.de (Jay Krell) Date: Sun, 6 Jun 2010 17:08:39 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100606150839.1693E2474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/06/06 17:08:39 Modified files: cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c Log message: #ifdef HAVE_GAS_HIDDEN /* otherwise varasm.c warns: "visibility attribute not supported in this configuration; ignored" */ From jkrell at elego.de Sun Jun 6 17:25:42 2010 From: jkrell at elego.de (Jay Krell) Date: Sun, 6 Jun 2010 17:25:42 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100606152542.B7F312474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/06/06 17:25:42 Modified files: cm3/m3-libs/m3core/src/thread/Common/: ThreadInternal.c Log message: 'except' is keyword on OSF/1, use 'xcept' instead From jkrell at elego.de Sun Jun 6 17:49:28 2010 From: jkrell at elego.de (Jay Krell) Date: Sun, 6 Jun 2010 17:49:28 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100606154929.1D8882474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/06/06 17:49:28 Modified files: cm3/m3-libs/m3core/src/: m3core.h Log message: #ifdef __osf__ #ifndef _OSF_SOURCE #define _OSF_SOURCE #endif #ifndef _XOPEN_SOURCE #define _XOPEN_SOURCE 500 #endif #endif remove manual OSF/1 socklen_t I tried a few combinations. Without any #defines, socket.h omits stuff like recvfrom. If you just #define _XOPEN_SOURCE, then struct tm is missing the BSD members, which you can then handle with #ifdef, but I think socket.h was still missing stuff, I forgot. This works and is reasonable. From jkrell at elego.de Sun Jun 6 17:51:35 2010 From: jkrell at elego.de (Jay Krell) Date: Sun, 6 Jun 2010 17:51:35 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100606155135.B1C7D2474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/06/06 17:51:35 Modified files: cm3/m3-libs/m3core/src/time/POSIX/: DatePosixC.c Log message: add comment about OSF/1 From jkrell at elego.de Sun Jun 6 17:55:29 2010 From: jkrell at elego.de (Jay Krell) Date: Sun, 6 Jun 2010 17:55:29 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100606155529.DBA02CC37F@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/06/06 17:55:29 Modified files: cm3/scripts/python/: pylib.py Log message: pylib.py From jkrell at elego.de Sun Jun 6 18:00:54 2010 From: jkrell at elego.de (Jay Krell) Date: Sun, 6 Jun 2010 18:00:54 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100606160054.203E72474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/06/06 18:00:54 Modified files: cm3/scripts/python/: pylib.py Log message: failed to comment previous due to wrong cvs command line: adapt for ALPHA_OSF: use /usr/bin/cc -g, specifically -fPIC causes the error, like, "-g2 invalid hex number" or such, I think -fPIC means something else, and I think there is only one model on ALPHA_OSF anyway and it is PIC (consistent with Digital generally doing things better, and PIC being optional not a useful idea in general: proliferation of unnecessary and uncompatible options) switch Solaris to "big PIC" instead of "small PIC" Bad enough that there is PIC and non-PIC, add to the mix having to chose big PIC or small PIC! Ugh. Small PIC is more efficient but doesn't always work, and you don't know until you link, at And it doesn't work because of yet other poor ABI design, the general defaulting of everything to be external to the .so.. You get to go back and recompile some/all files.. There should be just one model and it should just work. The processor and the ABI should be designed together so that it is reasonably efficient. If there are, say, 32bit limits, then the linker should be able to fix things up, like, for tangential example, creation of branch islands. From jay.krell at cornell.edu Sun Jun 6 18:03:20 2010 From: jay.krell at cornell.edu (Jay K) Date: Sun, 6 Jun 2010 16:03:20 +0000 Subject: [M3commit] CVS Update: cm3 In-Reply-To: <20100606154929.1D8882474003@birch.elegosoft.com> References: <20100606154929.1D8882474003@birch.elegosoft.com> Message-ID: ?>> but I think socket.h was still missing stuff, I forgot. Some combinations resulted in missing u_char, u_short, u_int, u_long, and MachineIDPosixC.c not compiling. ?- Jay ---------------------------------------- > Date: Sun, 6 Jun 2010 17:49:28 +0000 > To: m3commit at elegosoft.com > From: jkrell at elego.de > Subject: [M3commit] CVS Update: cm3 > > CVSROOT: /usr/cvs > Changes by: jkrell at birch. 10/06/06 17:49:28 > > Modified files: > cm3/m3-libs/m3core/src/: m3core.h > > Log message: > #ifdef __osf__ > #ifndef _OSF_SOURCE > #define _OSF_SOURCE > #endif > #ifndef _XOPEN_SOURCE > #define _XOPEN_SOURCE 500 > #endif > #endif > > remove manual OSF/1 socklen_t > > I tried a few combinations. > Without any #defines, socket.h omits stuff like recvfrom. > If you just #define _XOPEN_SOURCE, then struct tm is missing the BSD members, > which you can then handle with #ifdef, but I think socket.h > was still missing stuff, I forgot. This works and is reasonable. > From jkrell at elego.de Sun Jun 6 22:46:15 2010 From: jkrell at elego.de (Jay Krell) Date: Sun, 6 Jun 2010 22:46:15 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100606204616.DD9152474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/06/06 22:46:15 Modified files: cm3/m3-libs/m3core/src/time/POSIX/: TimePosixC.c Log message: Three calls to ComputeGrainOnce take a long time to coincide on OSF/1 so only use two. This area seems a bit weak and in need of more attention. From jkrell at elego.de Sun Jun 6 23:07:48 2010 From: jkrell at elego.de (Jay Krell) Date: Sun, 6 Jun 2010 23:07:48 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100606210748.3F4372474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/06/06 23:07:48 Modified files: cm3/m3-libs/m3core/src/runtime/: m3makefile Log message: remove three newlines From jkrell at elego.de Sun Jun 6 23:09:52 2010 From: jkrell at elego.de (Jay Krell) Date: Sun, 6 Jun 2010 23:09:52 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100606210952.799952474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/06/06 23:09:52 Modified files: cm3/m3-libs/m3core/src/runtime/: m3makefile Log message: disable ALPHA_OSF stack walker here too 'for now' From jkrell at elego.de Sun Jun 6 23:11:32 2010 From: jkrell at elego.de (Jay Krell) Date: Sun, 6 Jun 2010 23:11:32 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100606211132.2E0742474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/06/06 23:11:32 Added files: cm3/m3-libs/m3core/src/C/ALPHA_OSF/: Csetjmp.i3 m3makefile Log message: restore ALPHA_OSF/Csetjmp.i3 From jkrell at elego.de Sun Jun 6 23:11:56 2010 From: jkrell at elego.de (Jay Krell) Date: Sun, 6 Jun 2010 23:11:56 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100606211156.EB9702474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/06/06 23:11:56 Modified files: cm3/m3-libs/m3core/src/: m3core.h cm3/m3-libs/m3core/src/time/POSIX/: DatePosixC.c TimePosixC.c cm3/m3-libs/m3core/src/unix/Common/: UtimeC.c Log message: use 64bit time_t (time64_t) on ALPHA_OSF From jay.krell at cornell.edu Sun Jun 6 23:13:01 2010 From: jay.krell at cornell.edu (Jay K) Date: Sun, 6 Jun 2010 21:13:01 +0000 Subject: [M3commit] CVS Update: cm3 In-Reply-To: <20100606211156.EB9702474003@birch.elegosoft.com> References: <20100606211156.EB9702474003@birch.elegosoft.com> Message-ID: ---------------------------------------- > Date: Sun, 6 Jun 2010 23:11:56 +0000 > To: m3commit at elegosoft.com > From: jkrell at elego.de > Subject: [M3commit] CVS Update: cm3 > > CVSROOT: /usr/cvs > Changes by: jkrell at birch. 10/06/06 23:11:56 > > Modified files: > cm3/m3-libs/m3core/src/: m3core.h > cm3/m3-libs/m3core/src/time/POSIX/: DatePosixC.c TimePosixC.c > cm3/m3-libs/m3core/src/unix/Common/: UtimeC.c > > Log message: > use 64bit time_t (time64_t) on ALPHA_OSF > -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: time64.txt URL: From jkrell at elego.de Sun Jun 6 23:57:15 2010 From: jkrell at elego.de (Jay Krell) Date: Sun, 6 Jun 2010 23:57:15 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100606215715.2CF862474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/06/06 23:57:15 Modified files: cm3/scripts/python/: pylib.py Log message: remove spaces in assembler command line too, share code to do so From jkrell at elego.de Mon Jun 7 00:15:19 2010 From: jkrell at elego.de (Jay Krell) Date: Mon, 7 Jun 2010 0:15:19 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100606221520.284C92474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/06/07 00:15:19 Modified files: cm3/scripts/python/: pylib.py Log message: fix From jkrell at elego.de Mon Jun 7 00:15:47 2010 From: jkrell at elego.de (Jay Krell) Date: Mon, 7 Jun 2010 0:15:47 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100606221547.E6E2F2474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/06/07 00:15:47 Modified files: cm3/scripts/python/: pylib.py Log message: comments From jkrell at elego.de Mon Jun 7 00:37:51 2010 From: jkrell at elego.de (Jay Krell) Date: Mon, 7 Jun 2010 0:37:51 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100606223752.4455A2474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/06/07 00:37:51 Modified files: cm3/scripts/python/: pylib.py Log message: put version and timestamp, in boot and distribution archive names From jkrell at elego.de Mon Jun 7 03:25:12 2010 From: jkrell at elego.de (Jay Krell) Date: Mon, 7 Jun 2010 3:25:12 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100607012512.BBD712474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/06/07 03:25:12 Modified files: cm3/scripts/python/: pylib.py Log message: support ALPHA_OSF host From jkrell at elego.de Wed Jun 9 19:20:18 2010 From: jkrell at elego.de (Jay Krell) Date: Wed, 9 Jun 2010 19:20:18 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100609172018.79E7F2474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/06/09 19:20:18 Modified files: cm3/m3-libs/m3core/src/unix/Common/: Uexec.c Log message: Only call WEXITSTATUS if WIFEXITED. Only call WTERMSIG if WIFSIGNALED. Otherwise we get -1 and a subrange violation on OSF/1, due to: /* evaluates to the low-order 8 bits of the child exit status */ #define WEXITSTATUS(x) (WIFEXITED(x) ? ((_W_INT(x) >> 8) & 0377) : -1) /* evaluates to a non-zero value if status returned for abnormal termination */ #define WIFSIGNALED(x) (_WSTATUS(x) != _WSTOPPED && _WSTATUS(x) != 0) /* evaluates to the number of the signal that caused the child to terminate */ #define WTERMSIG(x) (WIFSIGNALED(x) ? _WSTATUS(x) : -1) and a careful read of Posix validates this change. They don't say what WEXITSTATUS and WTERMSIG do if WIFEXITED, WIFSIGNALED are false, only if true. From jay.krell at cornell.edu Wed Jun 9 19:23:31 2010 From: jay.krell at cornell.edu (Jay K) Date: Wed, 9 Jun 2010 17:23:31 +0000 Subject: [M3commit] CVS Update: cm3 In-Reply-To: <20100609172018.79E7F2474003@birch.elegosoft.com> References: <20100609172018.79E7F2474003@birch.elegosoft.com> Message-ID: attached ALPHA_OSF can now (again) get at least as far as starting to build natively in m3-sys/m3cc..waiting.. (stack walker disabled, granted) ?- Jay ---------------------------------------- > Date: Wed, 9 Jun 2010 19:20:18 +0000 > To: m3commit at elegosoft.com > From: jkrell at elego.de > Subject: [M3commit] CVS Update: cm3 > > CVSROOT: /usr/cvs > Changes by: jkrell at birch. 10/06/09 19:20:18 > > Modified files: > cm3/m3-libs/m3core/src/unix/Common/: Uexec.c > > Log message: > Only call WEXITSTATUS if WIFEXITED. > Only call WTERMSIG if WIFSIGNALED. > Otherwise we get -1 and a subrange violation on OSF/1, due to: > /* evaluates to the low-order 8 bits of the child exit status */ > #define WEXITSTATUS(x) (WIFEXITED(x) ? ((_W_INT(x)>> 8) & 0377) : -1) > /* evaluates to a non-zero value if status returned for abnormal termination */ > #define WIFSIGNALED(x) (_WSTATUS(x) != _WSTOPPED && _WSTATUS(x) != 0) > /* evaluates to the number of the signal that caused the child to terminate */ > #define WTERMSIG(x) (WIFSIGNALED(x) ? _WSTATUS(x) : -1) > > and a careful read of Posix validates this change. > They don't say what WEXITSTATUS and WTERMSIG do if WIFEXITED, WIFSIGNALED > are false, only if true. > -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: wait.txt URL: From jkrell at elego.de Wed Jun 9 20:32:31 2010 From: jkrell at elego.de (Jay Krell) Date: Wed, 9 Jun 2010 20:32:31 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100609183231.2154F2474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/06/09 20:32:31 Modified files: cm3/m3-sys/cminstall/src/config-no-install/: ALPHA_OSF Log message: use -pthread (not -lpthread) and -lm on compiler/linker From jkrell at elego.de Wed Jun 9 20:33:38 2010 From: jkrell at elego.de (Jay Krell) Date: Wed, 9 Jun 2010 20:33:38 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100609183339.BF092CC37F@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/06/09 20:33:38 Modified files: cm3/m3-sys/m3cc/src/: m3makefile Log message: disable mips-tfile pending research, seems to work without it, though gcc does do something similar here From jkrell at elego.de Wed Jun 9 22:32:48 2010 From: jkrell at elego.de (Jay Krell) Date: Wed, 9 Jun 2010 22:32:48 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100609203248.77A802474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/06/09 22:32:48 Modified files: cm3/m3-libs/m3core/src/unix/Common/: UtimeC.c Log message: missed a use of time_t in doing the 64bit time change for OSF/1 From jkrell at elego.de Sat Jun 12 12:13:27 2010 From: jkrell at elego.de (Jay Krell) Date: Sat, 12 Jun 2010 12:13:27 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100612101327.946CB2474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/06/12 12:13:27 Modified files: cm3/m3-libs/m3core/src/: thread.quake Log message: er, let's use pthreads on ALPHA_OSF, not doing so was just an accident by me, though it ought it work either way From jkrell at elego.de Sat Jun 12 16:04:41 2010 From: jkrell at elego.de (Jay Krell) Date: Sat, 12 Jun 2010 16:04:41 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100612140441.870E82474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/06/12 16:04:41 Modified files: cm3/scripts/python/: pylib.py Log message: use -nocpp on Alpha/OSF assembler, as the preprocessor isn't needed and Mika broke his by accident; running /usr/lib/cmplrs/cc/as0 directly is also viable, it is documented on the man page From jkrell at elego.de Sat Jun 12 16:07:02 2010 From: jkrell at elego.de (Jay Krell) Date: Sat, 12 Jun 2010 16:07:02 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100612140702.4411CCC37F@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/06/12 16:07:02 Modified files: cm3/scripts/python/: pylib.py Log message: run /usr/lib/cmplrs/cc/as0 directly on Alpha/OSF From jkrell at elego.de Sat Jun 12 16:09:17 2010 From: jkrell at elego.de (Jay Krell) Date: Sat, 12 Jun 2010 16:09:17 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100612140920.6EFD42474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/06/12 16:09:17 Modified files: cm3/m3-sys/cminstall/src/config-no-install/: ALPHA_OSF Log message: disable stack walker here too (is that what broke the self-built cm3? run /usr/lib/cmplrs/cc/as0 directly (hey I would not have noticed the stack walker change here so fast Mika not broken /usr/bin/as!) From jkrell at elego.de Sat Jun 12 16:41:45 2010 From: jkrell at elego.de (Jay Krell) Date: Sat, 12 Jun 2010 16:41:45 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100612144145.2A2BFCC37F@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/06/12 16:41:45 Modified files: cm3/m3-libs/m3core/src/thread/PTHREAD/: ThreadPThreadC.c Log message: Pick SIG_SUSPEND for Alpha/OSF1/Tru64. Otherwise pthreads fails to compile for it, due to picking a non-constant. Here are some of the choices: /usr/include/signal.h: #define SIGUSR1 30 /* user defined signal 1 */ #define SIGUSR2 31 /* user defined signal 2 */ #define SIGRTMIN (sysconf(131)) #define SIGRTMAX (sysconf(132)) bash-4.1$ ./a.out 33 48 #include #include int main(int argc, char** argv) { printf("%ld %ld\n", (long)SIGRTMIN, (long)SIGRTMAX); return 0; } Using 33, 48 seems dangerous -- does it vary per machine/OS version? Diff here is: <#elif defined(SIGRTMAX) && !defined(__osf__) >#elif defined(SIGRTMAX) && !defined(__osf__) /* This might be a function call, in which case try _SIGRTMAX or initializing it somewhere. */ EXTERN_CONST int SIG_SUSPEND = SIGRTMAX; #elif defined(SIGUSR2) EXTERN_CONST int SIG_SUSPEND = SIGUSR2; so we end up using SIGUSR2, which is the same as on Solaris and maybe others. Note that OSF/1 and Darwin share a common base in Mach. And therefore "direct suspend" is probably a good easy idea here? mach_suspend/resume are in the headers, but I haven't found how to get the mach thread for a pthread, or the current mach thread, to compare see if they match. I'm more comfortable using the common code though actually. esp. since I haven't written any of this. From jkrell at elego.de Sat Jun 12 16:48:14 2010 From: jkrell at elego.de (Jay Krell) Date: Sat, 12 Jun 2010 16:48:14 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100612144815.068972474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/06/12 16:48:14 Modified files: cm3/m3-libs/m3core/src/thread/PTHREAD/: ThreadPThreadC.c Log message: make ThreadPThread__RestartThread and ThreadPThread__SuspendThread, as Tru64 cc complains that they weren't returning anything. Note we are playing just slightly fast/loose here. They are declared as returning BOOLEAN in the *.i3 files. But these versions just abort() and should never be called. You know, like, sometimes there is a "noreturn" marker on abort, sometimes not. That's why other compilers haven't been warning here. From jkrell at elego.de Sat Jun 12 16:52:24 2010 From: jkrell at elego.de (Jay Krell) Date: Sat, 12 Jun 2010 16:52:24 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100612145224.451942474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/06/12 16:52:24 Modified files: cm3/m3-sys/cminstall/src/config-no-install/: ALPHA_OSF Log message: hm, looks like as0 has to be followed by as1 Just use as -nocpp. Need -lrt for nanosleep, sem_*, now that using pthreads. From jkrell at elego.de Sat Jun 12 16:54:35 2010 From: jkrell at elego.de (Jay Krell) Date: Sat, 12 Jun 2010 16:54:35 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100612145436.0F4CCCC37F@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/06/12 16:54:35 Modified files: cm3/scripts/python/: pylib.py Log message: back to /usr/bin/as -nocpp on Alpha/OSF From jkrell at elego.de Sat Jun 12 16:57:41 2010 From: jkrell at elego.de (Jay Krell) Date: Sat, 12 Jun 2010 16:57:41 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100612145741.EFB202474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/06/12 16:57:41 Modified files: cm3/m3-libs/m3core/src/: thread.quake Log message: empty out platform list, the default of true is correct for all current platforms except OpenBSD, which are left in the list From jay.krell at cornell.edu Sat Jun 12 17:01:18 2010 From: jay.krell at cornell.edu (Jay K) Date: Sat, 12 Jun 2010 15:01:18 +0000 Subject: [M3commit] CVS Update: cm3 In-Reply-To: <20100612144815.068972474003@birch.elegosoft.com> References: <20100612144815.068972474003@birch.elegosoft.com> Message-ID: This was supposed to say, make them "return void". ?- Jay ---------------------------------------- > Date: Sat, 12 Jun 2010 16:48:14 +0000 > To: m3commit at elegosoft.com > From: jkrell at elego.de > Subject: [M3commit] CVS Update: cm3 > > CVSROOT: /usr/cvs > Changes by: jkrell at birch. 10/06/12 16:48:14 > > Modified files: > cm3/m3-libs/m3core/src/thread/PTHREAD/: ThreadPThreadC.c > > Log message: > make ThreadPThread__RestartThread and ThreadPThread__SuspendThread, > as Tru64 cc complains that they weren't returning anything. > > Note we are playing just slightly fast/loose here. > They are declared as returning BOOLEAN in the *.i3 files. > But these versions just abort() and should never be called. > > You know, like, sometimes there is a "noreturn" marker > on abort, sometimes not. That's why other compilers > haven't been warning here. > From jkrell at elego.de Sat Jun 12 17:22:44 2010 From: jkrell at elego.de (Jay Krell) Date: Sat, 12 Jun 2010 17:22:44 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100612152244.8115B2474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/06/12 17:22:44 Modified files: cm3/m3-libs/m3core/src/: thread.quake cm3/m3-libs/m3core/src/thread/: m3makefile Log message: user threads are now very portable and rarely require per-target work, so we can remove the list of targets that don't offer them (I was rarely doing the work for any new target) (still, NT/Cygwin don't have them, that's encoded differently) From jkrell at elego.de Sat Jun 12 17:25:49 2010 From: jkrell at elego.de (Jay Krell) Date: Sat, 12 Jun 2010 17:25:49 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100612152549.32A4D2474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/06/12 17:25:49 Modified files: cm3/m3-libs/m3core/src/thread/PTHREAD/: ThreadPThreadC.c Log message: remove errant line in the OSF change From jkrell at elego.de Sat Jun 12 22:26:03 2010 From: jkrell at elego.de (Jay Krell) Date: Sat, 12 Jun 2010 22:26:03 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100612202603.D87322474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/06/12 22:26:03 Modified files: cm3/www/uploaded-archives/: targets.txt Log message: add ALPHA_OSF From jkrell at elego.de Sun Jun 13 04:48:54 2010 From: jkrell at elego.de (Jay Krell) Date: Sun, 13 Jun 2010 4:48:54 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100613024858.5BDE02474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/06/13 04:48:54 Modified files: cm3/m3-sys/cminstall/src/config-no-install/: ALPHA_OSF Unix.common Log message: -mieee is needed to support denormal floating point, such as m3-libs/m3core/src/float/IEEE/LongReal.i3 MinPos: T = 4.9406564584124654D-324; (* The minimum positive value in T. *) MinPosNormal: T = 2.2250738585072014D-308; (* The minimum positive "normal" value in T; differs from MinPos only for implementations with denormalized numbers. *) Otherwise MinPos is NaN and multiplication with it here: m3-libs/arithmetic/src/basictypes/float/FloatTrans.ig Tiny = R.MinPos * FLOAT(1000.0, T); (* nearly 0.0 *) issues a SIGFPE, when R = LongReal. I also wonder if maybe MinPos should be adjusted to be normal or ALPHA_OSF should do so (i.e. not use generic IEEE directory, e.g.: VAX/LongReal.i3: MinPos: T = 2.93873587705571880D-39; VAX/LongReal.i3: MinPosNormal: T = MinPos; ) Probably best to be like all the other architectures though, even if it costs some perf. You know, some people like floating point to be really really the same across all architectures..witness Java, Java -strictfp, and the lack of any Java for VAX. see: http://gcc.gnu.org/onlinedocs/gcc-4.5.0/gcc/DEC-Alpha-Options.html#DEC-Alpha-Options A program like this demontrates it, I think it was, from memory: int main() { long a = 0x3E8; /* NaN */ double b = *(double*)&a; double c = b * 1000;; return 0; } or: int main() { double a = 4.9406564584124654e-324; double b = a * 1000; return 0; } We should probably hardcode this in parse.c for Alpha instead of relying on the config files. From jay.krell at cornell.edu Sun Jun 13 04:50:40 2010 From: jay.krell at cornell.edu (Jay K) Date: Sun, 13 Jun 2010 02:50:40 +0000 Subject: [M3commit] CVS Update: cm3 In-Reply-To: <20100613024858.5BDE02474003@birch.elegosoft.com> References: <20100613024858.5BDE02474003@birch.elegosoft.com> Message-ID: Index: ALPHA_OSF =================================================================== RCS file: /usr/cvs/cm3/m3-sys/cminstall/src/config-no-install/ALPHA_OSF,v retrieving revision 1.4 diff -u -r1.4 ALPHA_OSF --- ALPHA_OSF??? 12 Jun 2010 14:52:24 -0000??? 1.4 +++ ALPHA_OSF??? 13 Jun 2010 02:48:19 -0000 @@ -61,6 +61,7 @@ ? ?m3back_pic = "" % It seems that -fPIC isn't needed!? cool. ?m3back_m64 = "" % -m64 not allowed +m3back_mieee = "-mieee" ? ?%--------------------------------------------------------------- C compiler --- ?% "compile_c" is called to compile C source files.? Note that this function Index: Unix.common =================================================================== RCS file: /usr/cvs/cm3/m3-sys/cminstall/src/config-no-install/Unix.common,v retrieving revision 1.62 diff -u -r1.62 Unix.common --- Unix.common??? 2 Jun 2010 11:12:03 -0000??? 1.62 +++ Unix.common??? 13 Jun 2010 02:48:19 -0000 @@ -80,11 +80,16 @@ ?? m3back_m64 = {"32BITS" : "", "64BITS" : "-m64"}{WORD_SIZE} ?end ? +if not defined("m3back_mieee") +? m3back_mieee = "" +end + ?proc m3_backend(source, object, optimize, debug) is ???? local args = [ "-quiet", ??????????????????? "-fno-reorder-blocks", ??????????????????? m3back_unwind_table, ??????????????????? m3back_pic, +?????????????????? m3back_mieee, ??????????????????? m3back_m32, ??????????????????? m3back_m64 ] ???? if optimize ---------------------------------------- > Date: Sun, 13 Jun 2010 04:48:54 +0000 > To: m3commit at elegosoft.com > From: jkrell at elego.de > Subject: [M3commit] CVS Update: cm3 > > CVSROOT: /usr/cvs > Changes by: jkrell at birch. 10/06/13 04:48:54 > > Modified files: > cm3/m3-sys/cminstall/src/config-no-install/: ALPHA_OSF > Unix.common > > Log message: > -mieee is needed to support denormal floating point, such > as m3-libs/m3core/src/float/IEEE/LongReal.i3 > MinPos: T = 4.9406564584124654D-324; > (* The minimum positive value in T. *) > > MinPosNormal: T = 2.2250738585072014D-308; > (* The minimum positive "normal" value in T; differs from MinPos > only for implementations with denormalized numbers. *) > > Otherwise MinPos is NaN and multiplication with it here: > > m3-libs/arithmetic/src/basictypes/float/FloatTrans.ig > Tiny = R.MinPos * FLOAT(1000.0, T); (* nearly 0.0 *) > > issues a SIGFPE, when R = LongReal. > > I also wonder if maybe MinPos should be adjusted to be normal > or ALPHA_OSF should do so (i.e. not use generic IEEE directory, e.g.: > VAX/LongReal.i3: MinPos: T = 2.93873587705571880D-39; > VAX/LongReal.i3: MinPosNormal: T = MinPos; > ) > > Probably best to be like all the other architectures though, > even if it costs some perf. You know, some people like floating point > to be really really the same across all architectures..witness > Java, Java -strictfp, and the lack of any Java for VAX. > > see: > http://gcc.gnu.org/onlinedocs/gcc-4.5.0/gcc/DEC-Alpha-Options.html#DEC-Alpha-Options > > A program like this demontrates it, I think it was, from memory: > > int main() > { > long a = 0x3E8; /* NaN */ > double b = *(double*)&a; > double c = b * 1000;; > return 0; > } > > or: > int main() > { > double a = 4.9406564584124654e-324; > double b = a * 1000; > return 0; > } > > We should probably hardcode this in parse.c for Alpha instead > of relying on the config files. > From jkrell at elego.de Sun Jun 13 05:05:43 2010 From: jkrell at elego.de (Jay Krell) Date: Sun, 13 Jun 2010 5:05:43 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100613030543.6D3A92474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/06/13 05:05:43 Modified files: cm3/m3-ui/jvideo/src/POSIX/: m3makefile Log message: Comment out the decision to use target specific code and just use the generic version, it does compile, whereas the osf1/decunix versions no longer do. Is the target specific version faster or did these systems previously not handle the generic version? Either I doubt it matters much, out here in jvideo. From jkrell at elego.de Sun Jun 13 06:54:53 2010 From: jkrell at elego.de (Jay Krell) Date: Sun, 13 Jun 2010 6:54:53 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100613045453.2920E2474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/06/13 06:54:53 Modified files: cm3/m3-sys/cminstall/src/config-no-install/: ALPHA_OSF Log message: solitaire needs -ldnet_stub (dnet=decnet, and this was already there in the old config file that I wasn't immediately copying everything from) From jkrell at elego.de Sun Jun 13 07:09:58 2010 From: jkrell at elego.de (Jay Krell) Date: Sun, 13 Jun 2010 7:09:58 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100613050958.E63AA2474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/06/13 07:09:58 Modified files: cm3/scripts/python/: upload.sh Log message: also upload *.tar.xz and *.tgz files, and also translate jayk to jkrell From jkrell at elego.de Sun Jun 13 07:11:32 2010 From: jkrell at elego.de (Jay Krell) Date: Sun, 13 Jun 2010 7:11:32 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100613051132.B94122474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/06/13 07:11:32 Modified files: cm3/scripts/python/: upload.sh Log message: also chmod 644 From jkrell at elego.de Sun Jun 13 07:47:41 2010 From: jkrell at elego.de (Jay Krell) Date: Sun, 13 Jun 2010 7:47:41 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100613054742.4ABE2CC389@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/06/13 07:47:41 Modified files: cm3/m3-sys/cminstall/src/config-no-install/: ALPHA_OSF Log message: improve cc options: -g -readonly_strings, -lm doesn't belong here From jkrell at elego.de Sun Jun 13 23:30:55 2010 From: jkrell at elego.de (Jay Krell) Date: Sun, 13 Jun 2010 23:30:55 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100613213055.CBC4A2474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/06/13 23:30:55 Modified files: cm3/m3-sys/m3cc/src/: m3makefile Log message: some comment editing and fitting in 80 columns From jkrell at elego.de Mon Jun 14 06:42:45 2010 From: jkrell at elego.de (Jay Krell) Date: Mon, 14 Jun 2010 6:42:45 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100614044245.F1AE82474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/06/14 06:42:45 Modified files: cm3/m3-sys/m3cc/src/: m3makefile Log message: build and ship mips-tfile, though it doesn't yet work for me It gives errors, same as the mips-tfile that building gcc gives me, when used against Modula-3, mips-tfile does get used and work with C. From jkrell at elego.de Mon Jun 14 07:25:39 2010 From: jkrell at elego.de (Jay Krell) Date: Mon, 14 Jun 2010 7:25:39 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100614052539.F200E2474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/06/14 07:25:39 Modified files: cm3/m3-sys/cminstall/src/config-no-install/: ALPHA_OSF Unix.common Log message: put the .so files in lib and symlink back from pkg like other Posix platforms all now do I kind of think we might as well move the .a files too. move options to SYSTEM_CC (-ieee_with_no_inexact, -pthread) more refinement of compile/link flags: -error_unresolved -readonly_strings run assembler with the same flags that gcc does: -g -oldas -c -O0 (and -nocpp) Neither -oldas nor -c are documented. Always using -g seems wrong, never -g0 or -g3, etc., but it seems to be what gcc always does, I tried a few different -g and -O parameters (compiling C) run mips-tfile Changing the flags to the assembler appears to have helped significantly here. Previously it was always issuing errors. Reading osf.h and osf5.h confirm this. Debugging is a little better now in gdb. m3gdb crashes if I just set a breakpoint. From jkrell at elego.de Mon Jun 14 23:16:39 2010 From: jkrell at elego.de (Jay Krell) Date: Mon, 14 Jun 2010 23:16:39 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100614211639.89E06CC382@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/06/14 23:16:39 Modified files: cm3/m3-sys/cminstall/src/config-no-install/: ALPHA_OSF Log message: always compile C with -O3 -g3 -g in particular inhibits optimization path -rpath to cc instead of -Wl,-rpath use -B symbolic I verified, even though this isn't really documented for cc, it does work. It is documented for ld. -B foo means something else for cc, but it appears to recognize -B symbolic. If in doubt, use -Wl,-B,symbolic or maybe -WL,-B,symbolic instead cleanup comments about shared remove SYSTEM_LD -- just always use SYSTEM_CC From jkrell at elego.de Wed Jun 16 09:16:58 2010 From: jkrell at elego.de (Jay Krell) Date: Wed, 16 Jun 2010 9:16:58 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100616071658.769162474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/06/16 09:16:58 Added files: cm3/doc/notes/: todo.txt Log message: record backlog From jkrell at elego.de Wed Jun 16 09:21:23 2010 From: jkrell at elego.de (Jay Krell) Date: Wed, 16 Jun 2010 9:21:23 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100616072123.9F0F02474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/06/16 09:21:23 Modified files: cm3/doc/notes/: porting.txt Log message: some updates esp. about user threads being much more portable now From jkrell at elego.de Wed Jun 16 09:23:41 2010 From: jkrell at elego.de (Jay Krell) Date: Wed, 16 Jun 2010 9:23:41 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100616072343.AE3D52474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/06/16 09:23:41 Modified files: cm3/doc/notes/: todo.txt Log message: more backlog: reduce C header cloning From jkrell at elego.de Wed Jun 16 09:30:17 2010 From: jkrell at elego.de (Jay Krell) Date: Wed, 16 Jun 2010 9:30:17 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100616073017.AE2A22474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/06/16 09:30:17 Modified files: cm3/m3-libs/m3core/src/unix/Common/: Usocket.c Log message: ZeroMemory is *perhaps* preferable to = { 0 } because: 1) it portable zeros all of a union 2) gcc warns about missing initializers Though really = { 0 } is imho a great terse portable syntax that isn't worth warning about, unless there is a union with not the largest first. From rodney at elego.de Wed Jun 16 16:12:26 2010 From: rodney at elego.de (Rodney M. Bates) Date: Wed, 16 Jun 2010 16:12:26 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100616141226.3B7EA2474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: rodney at birch. 10/06/16 16:12:26 Modified files: cm3/m3-sys/m3front/src/misc/: Scanner.m3 Log message: Complete case-insensitivity for: 1) 'w'/'W' to denote wide character and wide text literals 2) 'x'/'X' as hex escape inside character and text literals From jkrell at elego.de Sat Jun 19 06:51:10 2010 From: jkrell at elego.de (Jay Krell) Date: Sat, 19 Jun 2010 6:51:10 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100619045111.2C3632474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/06/19 06:51:10 Added files: cm3/m3-sys/cminstall/src/config-no-install/: ARMEL_LINUX Log message: initial config file for ARMEL_LINUX (e=embedded, l=little endian) From jkrell at elego.de Sat Jun 19 06:56:33 2010 From: jkrell at elego.de (Jay Krell) Date: Sat, 19 Jun 2010 6:56:33 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100619045633.3B3992474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/06/19 06:56:33 Modified files: cm3/m3-sys/m3middle/src/: Target.i3 Target.m3 Log message: add ARMEL_LINUX with correct jmbuf size/align guessing about alignment "ARM" is an older ABI "ARME" is the usual modern ABI L for little endian From jkrell at elego.de Sat Jun 19 06:57:58 2010 From: jkrell at elego.de (Jay Krell) Date: Sat, 19 Jun 2010 6:57:58 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100619045758.0DF422474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/06/19 06:57:58 Modified files: cm3/m3-libs/m3core/src/: platforms.quake Log message: add ARMEL_LINUX (not to be confused with Android/Bionic which I suspect might be different.. From jkrell at elego.de Sat Jun 19 07:10:13 2010 From: jkrell at elego.de (Jay Krell) Date: Sat, 19 Jun 2010 7:10:13 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100619051013.EF8AB2474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/06/19 07:10:13 Modified files: cm3/m3-sys/m3cc/src/: platforms.quake Log message: add ARMEL_LINUX=arm-linux-gnueabi From jkrell at elego.de Sat Jun 19 07:26:00 2010 From: jkrell at elego.de (Jay Krell) Date: Sat, 19 Jun 2010 7:26:00 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100619052600.D57B52474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/06/19 07:26:00 Modified files: cm3/m3-sys/m3cc/src/: m3makefile Log message: Always specify -target. in native builds, always specify -build and -host. This should provide for more consistency, though is also a bit experimental and unorthodox. From jkrell at elego.de Sat Jun 19 07:35:19 2010 From: jkrell at elego.de (Jay Krell) Date: Sat, 19 Jun 2010 7:35:19 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100619053520.45FB42474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/06/19 07:35:19 Modified files: cm3/m3-sys/m3cc/src/: gnucc.common m3makefile Log message: always specify -build, -host, -target, for cross and native consistent but experimenta/unorthodox Usually people let config.guess do all the work for native and always for build. Default build to host, not target. From jkrell at elego.de Sat Jun 19 07:50:51 2010 From: jkrell at elego.de (Jay Krell) Date: Sat, 19 Jun 2010 7:50:51 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100619055052.45354CC38A@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/06/19 07:50:51 Added files: cm3/m3-libs/m3core/src/C/ARMEL_LINUX/: m3makefile Log message: add ARMEL_LINUX (really want to get rid of this stuff..compiler should inject it..) From jkrell at elego.de Sat Jun 19 10:26:59 2010 From: jkrell at elego.de (Jay Krell) Date: Sat, 19 Jun 2010 10:26:59 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100619082659.15A582474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/06/19 10:26:59 Modified files: cm3/m3-libs/m3core/src/Csupport/Common/: hand.c Log message: add m3_modL for ARM, it seems to need it From jkrell at elego.de Sat Jun 19 10:38:24 2010 From: jkrell at elego.de (Jay Krell) Date: Sat, 19 Jun 2010 10:38:24 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100619083824.740662474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/06/19 10:38:24 Modified files: cm3/m3-libs/m3core/src/Csupport/Common/: hand.c Log message: leave it called m3_div64 instead of m3_divL From jay.krell at cornell.edu Sat Jun 19 10:39:14 2010 From: jay.krell at cornell.edu (Jay K) Date: Sat, 19 Jun 2010 08:39:14 +0000 Subject: [M3commit] CVS Update: cm3 In-Reply-To: <20100619082659.15A582474003@birch.elegosoft.com> References: <20100619082659.15A582474003@birch.elegosoft.com> Message-ID: Meant to say add *back*. ?- Jay ---------------------------------------- > Date: Sat, 19 Jun 2010 10:26:59 +0000 > To: m3commit at elegosoft.com > From: jkrell at elego.de > Subject: [M3commit] CVS Update: cm3 > > CVSROOT: /usr/cvs > Changes by: jkrell at birch. 10/06/19 10:26:59 > > Modified files: > cm3/m3-libs/m3core/src/Csupport/Common/: hand.c > > Log message: > add m3_modL for ARM, it seems to need it > From jay.krell at cornell.edu Sat Jun 19 10:39:46 2010 From: jay.krell at cornell.edu (Jay K) Date: Sat, 19 Jun 2010 08:39:46 +0000 Subject: [M3commit] CVS Update: cm3 In-Reply-To: <20100619083824.740662474003@birch.elegosoft.com> References: <20100619083824.740662474003@birch.elegosoft.com> Message-ID: er. mod64/modL, not div64/divL ?- Jay ---------------------------------------- > Date: Sat, 19 Jun 2010 10:38:24 +0000 > To: m3commit at elegosoft.com > From: jkrell at elego.de > Subject: [M3commit] CVS Update: cm3 > > CVSROOT: /usr/cvs > Changes by: jkrell at birch. 10/06/19 10:38:24 > > Modified files: > cm3/m3-libs/m3core/src/Csupport/Common/: hand.c > > Log message: > leave it called m3_div64 instead of m3_divL > From jkrell at elego.de Sat Jun 19 10:56:58 2010 From: jkrell at elego.de (Jay Krell) Date: Sat, 19 Jun 2010 10:56:58 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100619085658.AA95C2474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/06/19 10:56:58 Modified files: cm3/m3-libs/libm3/src/: platforms.quake Log message: add ARMEL_LINUX From jkrell at elego.de Sat Jun 19 11:01:20 2010 From: jkrell at elego.de (Jay Krell) Date: Sat, 19 Jun 2010 11:01:20 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100619090120.255072474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/06/19 11:01:20 Modified files: cm3/m3-sys/cminstall/src/config-no-install/: ARMEL_LINUX Log message: -m32 not allowed here (probably needed for ARM_DARWIN too) From jkrell at elego.de Sat Jun 19 11:03:53 2010 From: jkrell at elego.de (Jay Krell) Date: Sat, 19 Jun 2010 11:03:53 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100619090353.B59352474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/06/19 11:03:53 Modified files: cm3/m3-sys/m3cc/gcc/gcc/config/arm/: arm.h cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c Log message: use a function call for 64bit mod on ARM, the backend crashes otherwise #if 0'ed out possibly slightly better code From jay.krell at cornell.edu Sat Jun 19 11:07:54 2010 From: jay.krell at cornell.edu (Jay K) Date: Sat, 19 Jun 2010 09:07:54 +0000 Subject: [M3commit] CVS Update: cm3 In-Reply-To: <20100619090353.B59352474003@birch.elegosoft.com> References: <20100619090353.B59352474003@birch.elegosoft.com> Message-ID: diff attached ---------------------------------------- > Date: Sat, 19 Jun 2010 11:03:53 +0000 > To: m3commit at elegosoft.com > From: jkrell at elego.de > Subject: [M3commit] CVS Update: cm3 > > CVSROOT: /usr/cvs > Changes by: jkrell at birch. 10/06/19 11:03:53 > > Modified files: > cm3/m3-sys/m3cc/gcc/gcc/config/arm/: arm.h > cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c > > Log message: > use a function call for 64bit mod on ARM, the backend crashes otherwise > #if 0'ed out possibly slightly better code > -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: arm1.txt URL: From jkrell at elego.de Sat Jun 19 11:17:03 2010 From: jkrell at elego.de (Jay Krell) Date: Sat, 19 Jun 2010 11:17:03 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100619091703.B6F752474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/06/19 11:17:03 Modified files: cm3/scripts/python/: pylib.py Log message: add ARMEL, change ?= to = avoid any confusion, edit the Makefile if it is wrong From jkrell at elego.de Sat Jun 19 11:20:25 2010 From: jkrell at elego.de (Jay Krell) Date: Sat, 19 Jun 2010 11:20:25 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100619092025.D39DD2474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/06/19 11:20:25 Modified files: cm3/scripts/python/: pylib.py Log message: add GnuPlatformPrefix{ARMEL_LINUX} = arm-linux-gnueabi-; aka use cross tools by default, since that is what I currently have From jkrell at elego.de Sat Jun 19 11:24:10 2010 From: jkrell at elego.de (Jay Krell) Date: Sat, 19 Jun 2010 11:24:10 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100619092410.0B9D62474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/06/19 11:24:10 Modified files: cm3/m3-libs/m3core/src/runtime/POSIX/: RTSignalC.c Log message: add Linux/arm (probably works for all Linux/arm variants) From jkrell at elego.de Sat Jun 19 11:26:47 2010 From: jkrell at elego.de (Jay Krell) Date: Sat, 19 Jun 2010 11:26:47 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100619092647.960352474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/06/19 11:26:47 Modified files: cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c Log message: oops From jkrell at elego.de Sat Jun 19 11:31:11 2010 From: jkrell at elego.de (Jay Krell) Date: Sat, 19 Jun 2010 11:31:11 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100619093111.4E77E2474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/06/19 11:31:11 Modified files: cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c Log message: #include tm_p.h to fix warning From jkrell at elego.de Sat Jun 19 11:37:20 2010 From: jkrell at elego.de (Jay Krell) Date: Sat, 19 Jun 2010 11:37:20 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100619093720.7B93B2474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/06/19 11:37:20 Modified files: cm3/scripts/python/: pylib.py Log message: no --32 for ARM assembler -- this bit is a bit of a mess and probably should just have a table for the remaining architectures that do accept --64 or --32 From jkrell at elego.de Sat Jun 19 11:38:45 2010 From: jkrell at elego.de (Jay Krell) Date: Sat, 19 Jun 2010 11:38:45 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100619093845.7F4022474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/06/19 11:38:45 Modified files: cm3/scripts/python/: pylib.py Log message: oops: remove double gnu platform prefix from linker From jkrell at elego.de Sat Jun 19 11:44:56 2010 From: jkrell at elego.de (Jay Krell) Date: Sat, 19 Jun 2010 11:44:56 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100619094456.4DA1E2474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/06/19 11:44:56 Modified files: cm3/m3-libs/m3core/src/atomic/: m3makefile Log message: remove all atomics on ARMEL_LINUX -- gcc 4.5 does implement them though.. From jkrell at elego.de Sat Jun 19 12:03:26 2010 From: jkrell at elego.de (Jay Krell) Date: Sat, 19 Jun 2010 12:03:26 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100619100326.372AB2474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/06/19 12:03:26 Modified files: cm3/m3-libs/m3core/src/unix/: m3makefile Log message: forgot to commit ARMEL_LINUX line here From jkrell at elego.de Sat Jun 19 12:04:03 2010 From: jkrell at elego.de (Jay Krell) Date: Sat, 19 Jun 2010 12:04:03 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100619100403.F09092474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/06/19 12:04:03 Modified files: cm3/m3-libs/m3core/src/runtime/common/: Compiler.tmpl Log message: forgot to commit ARMEL_LINUX line here From jkrell at elego.de Mon Jun 21 07:05:56 2010 From: jkrell at elego.de (Jay Krell) Date: Mon, 21 Jun 2010 7:05:56 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100621050557.39AB62474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/06/21 07:05:56 Modified files: cm3/m3-libs/m3core/src/Csupport/Common/: hand.c Log message: add back all four div/mod helpers for Posix, through rewritten to use unsigned arithmetic and not depend on silent signed wraparound Floor div/mod is a fairly target-specific and under used part of gcc and I am now nervous to depend upon it. Perhaps do more research though and trust it. From jkrell at elego.de Mon Jun 21 08:05:55 2010 From: jkrell at elego.de (Jay Krell) Date: Mon, 21 Jun 2010 8:05:55 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100621060555.B56FACC10F@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/06/21 08:05:55 Modified files: cm3/m3-sys/m3cc/gcc/gcc/config/: darwin-protos.h Log message: forward declare enum machine_mode to fix warningu From jkrell at elego.de Mon Jun 21 08:12:11 2010 From: jkrell at elego.de (Jay Krell) Date: Mon, 21 Jun 2010 8:12:11 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100621061211.6358C2474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/06/21 08:12:11 Modified files: cm3/m3-sys/m3cc/gcc/gcc/config/arm/: arm.h cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c Log message: put div/mod back to long standing and release form: almost always call a function, unless both parameters known to be positive or the type is unsigned Modula-3 very unfortunately defines div/mod differently than pretty much everyone else. Perhaps perhaps the language definition can be repaired. It turns out there are several reasonable definitions of div and mod. Modula-3 doesn't chose the obvious correct one and C doesn't chose the obvious incorrect one. We may yet be able to use the gcc support but it makes me nervous. It requires at least in a very minimal sense, for the frontend to support TImode (aka int128_t). See: http://gcc.gnu.org/ml/gcc/2010-06/msg00647.html (which is just from me, talking to myself..) From jkrell at elego.de Mon Jun 21 08:26:41 2010 From: jkrell at elego.de (Jay Krell) Date: Mon, 21 Jun 2010 8:26:41 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100621062641.C21EBCC10F@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/06/21 08:26:41 Modified files: cm3/m3-sys/m3cc/gcc-4.5/gcc/: final.c ira-conflicts.c loop-iv.c lower-subreg.c sel-sched-dump.c sel-sched.c Log message: Fix warnings about possible use of uninitialized locals by very clearly initializing them (as all locals should probably be). See bug: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44600 which again, is basically me talking to myself.. From jkrell at elego.de Mon Jun 21 09:57:13 2010 From: jkrell at elego.de (Jay Krell) Date: Mon, 21 Jun 2010 9:57:13 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100621075714.089CACC10F@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/06/21 09:57:13 Modified files: cm3/m3-sys/m3tests/src/: m3makefile Added files: cm3/m3-sys/m3tests/src/p2/p238/: Main.m3 m3makefile stdout.pgm Log message: add 'man vs. boy' aka nested procedures+recursion aka static chain test From jkrell at elego.de Mon Jun 21 10:11:27 2010 From: jkrell at elego.de (Jay Krell) Date: Mon, 21 Jun 2010 10:11:27 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100621081129.E9A21CC110@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/06/21 10:11:27 Added files: cm3/m3-sys/m3tests/src/p2/p238/: man-or-boy.c Log message: initial version from http://rosettacode.org/wiki/Man_or_boy_test that requires C9x and reuses identifiers in a confusing way From jkrell at elego.de Mon Jun 21 10:20:04 2010 From: jkrell at elego.de (Jay Krell) Date: Mon, 21 Jun 2010 10:20:04 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100621082004.B9F752474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/06/21 10:20:04 Modified files: cm3/m3-sys/m3tests/src/p2/p238/: man-or-boy.c Log message: before: type ARG and macro ARG; after: type ARG and macro MAKE_ARG; should be less confusing From jkrell at elego.de Mon Jun 21 10:31:47 2010 From: jkrell at elego.de (Jay Krell) Date: Mon, 21 Jun 2010 10:31:47 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100621083148.6D36F2474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/06/21 10:31:47 Modified files: cm3/m3-sys/m3tests/src/p2/p238/: man-or-boy.c Log message: remove C9x dependency From rodney_bates at lcwb.coop Tue Jun 22 03:07:04 2010 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Mon, 21 Jun 2010 20:07:04 -0500 Subject: [M3commit] CVS Update: cm3 In-Reply-To: <20100621061211.6358C2474003@birch.elegosoft.com> References: <20100621061211.6358C2474003@birch.elegosoft.com> Message-ID: <4C200CB8.7070809@lcwb.coop> Jay Krell wrote: > CVSROOT: /usr/cvs > Changes by: jkrell at birch. 10/06/21 08:12:11 > > Modified files: > cm3/m3-sys/m3cc/gcc/gcc/config/arm/: arm.h > cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c > > Log message: > put div/mod back to long standing and release form: > almost always call a function, unless both parameters known > to be positive or the type is unsigned > > Modula-3 very unfortunately defines div/mod differently than > pretty much everyone else. Perhaps perhaps the language > definition can be repaired. No, the language is correct. This is the mathematically correct definition of mod/div. We can be thankful that at least one language actually got it right. Moreover, the mathematicians knew what they were doing. Try some example coding with, e.g., arrays as circular buffers, using mod/div to increment/decrement your way around them. So many times in other languages, I have struggled with the frustration of having to write overcomplicated code to compensate for incorrect mod/div in other than the first quadrant. C is particularly exasperating, because it doesn't define them at all outside the first quadrant. It is implementor's option. This means these operators are entirely unusable for code that needs to be the least bit portable--even different compilers on the same machine. You always have to adjust your operands to first quadrant, do the operation, and then readjust. In Modula-3, you just do the operation. It turns out there are several > reasonable definitions of div and mod. Modula-3 doesn't > chose the obvious correct one and C doesn't chose the > obvious incorrect one. > > We may yet be able to use the gcc support but it makes me nervous. > It requires at least in a very minimal sense, for the frontend > to support TImode (aka int128_t). > > See: http://gcc.gnu.org/ml/gcc/2010-06/msg00647.html > (which is just from me, talking to myself..) > > From jay.krell at cornell.edu Tue Jun 22 03:32:23 2010 From: jay.krell at cornell.edu (Jay K) Date: Tue, 22 Jun 2010 01:32:23 +0000 Subject: [M3commit] CVS Update: cm3 In-Reply-To: <4C200CB8.7070809@lcwb.coop> References: <20100621061211.6358C2474003@birch.elegosoft.com>, <4C200CB8.7070809@lcwb.coop> Message-ID: I researched this -- searched the web, read Wikipedia, etc..I realize that calling "research" may be an exaggeration. There are approximately four reasonable definitions of div and mod for negative numbers. The most important thing is that div and mod are defined in terms of each other, in all variations, but that doesn't actually pin it down. There is round up (toward positive infinity), round down (toward negative infinity), toward 0 (truncation), there is Euclidean way. One might expect n mod m to be in the range [0,m), or perhaps the absolute value to be in [0,m), but I think Modula-3 doesn't make that so. It is surprising imho for mod to be outside that range. C89 left it undefined. So implementor could pick whatever was fastest/easiest. Fortran specified truncation. Nobody complained. C99 adopted Fortran's definition. So it is well defined now. Negative numbers are overused anyway. Everyone defines it the same for positive numbers, and that's generally sufficient anyway. As well C's ldiv function was explicitly defined to be truncating and therefore portable. (Notice that Modula-3's implementation was long broken for other reasons as well: It dependended on silent overflow, which gcc can warn about and break, and it didn't work for maximum/minimal numbers.) - Jay ---------------------------------------- > Date: Mon, 21 Jun 2010 20:07:04 -0500 > From: rodney_bates at lcwb.coop > To: m3commit at elegosoft.com > Subject: Re: [M3commit] CVS Update: cm3 > > > > Jay Krell wrote: >> CVSROOT: /usr/cvs >> Changes by: jkrell at birch. 10/06/21 08:12:11 >> >> Modified files: >> cm3/m3-sys/m3cc/gcc/gcc/config/arm/: arm.h >> cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c >> >> Log message: >> put div/mod back to long standing and release form: >> almost always call a function, unless both parameters known >> to be positive or the type is unsigned >> >> Modula-3 very unfortunately defines div/mod differently than >> pretty much everyone else. Perhaps perhaps the language >> definition can be repaired. > > No, the language is correct. This is the mathematically correct definition > of mod/div. We can be thankful that at least one language actually got it > right. Moreover, the mathematicians knew what they were doing. Try some > example coding with, e.g., arrays as circular buffers, using mod/div to > increment/decrement your way around them. So many times in other languages, > I have struggled with the frustration of having to write overcomplicated code > to compensate for incorrect mod/div in other than the first quadrant. > > C is particularly exasperating, because it doesn't define them at all outside > the first quadrant. It is implementor's option. This means these operators > are entirely unusable for code that needs to be the least bit portable--even > different compilers on the same machine. You always have to adjust your > operands to first quadrant, do the operation, and then readjust. > > In Modula-3, you just do the operation. > > It turns out there are several >> reasonable definitions of div and mod. Modula-3 doesn't >> chose the obvious correct one and C doesn't chose the >> obvious incorrect one. >> >> We may yet be able to use the gcc support but it makes me nervous. >> It requires at least in a very minimal sense, for the frontend >> to support TImode (aka int128_t). >> >> See: http://gcc.gnu.org/ml/gcc/2010-06/msg00647.html >> (which is just from me, talking to myself..) >> >> From hosking at cs.purdue.edu Tue Jun 22 03:35:52 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 21 Jun 2010 21:35:52 -0400 Subject: [M3commit] CVS Update: cm3 In-Reply-To: References: <20100621061211.6358C2474003@birch.elegosoft.com>, <4C200CB8.7070809@lcwb.coop> Message-ID: <0D1E563C-4499-404A-B4FB-9B27556581BA@cs.purdue.edu> On 21 Jun 2010, at 21:32, Jay K wrote: > > I researched this -- searched the web, read Wikipedia, etc..I realize that calling "research" may be an exaggeration. > There are approximately four reasonable definitions of div and mod for negative numbers. > > > The most important thing is that div and mod are defined in terms of each other, in all variations, but that doesn't actually pin it down. > > > There is round up (toward positive infinity), round down (toward negative infinity), toward 0 (truncation), there is Euclidean way. > > > One might expect n mod m to be in the range [0,m), or perhaps the absolute value to be in [0,m), but I think Modula-3 doesn't make that so. It is surprising imho for mod to be outside that range. > > > > C89 left it undefined. So implementor could pick whatever was fastest/easiest. > Fortran specified truncation. Nobody complained. > C99 adopted Fortran's definition. > So it is well defined now. > Negative numbers are overused anyway. > Everyone defines it the same for positive numbers, and that's generally sufficient anyway. But not if you can index arrays using negative indexes as in Modula-3. C, Fortran, etc. don't have this feature so they can get it wrong and nobody will notice. > > > > As well C's ldiv function was explicitly defined to be truncating and therefore portable. > > > > (Notice that Modula-3's implementation was long broken for other reasons as well: It dependended on silent overflow, which gcc can warn about and break, and it didn't work for maximum/minimal numbers.) > > > - Jay > > > ---------------------------------------- >> Date: Mon, 21 Jun 2010 20:07:04 -0500 >> From: rodney_bates at lcwb.coop >> To: m3commit at elegosoft.com >> Subject: Re: [M3commit] CVS Update: cm3 >> >> >> >> Jay Krell wrote: >>> CVSROOT: /usr/cvs >>> Changes by: jkrell at birch. 10/06/21 08:12:11 >>> >>> Modified files: >>> cm3/m3-sys/m3cc/gcc/gcc/config/arm/: arm.h >>> cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c >>> >>> Log message: >>> put div/mod back to long standing and release form: >>> almost always call a function, unless both parameters known >>> to be positive or the type is unsigned >>> >>> Modula-3 very unfortunately defines div/mod differently than >>> pretty much everyone else. Perhaps perhaps the language >>> definition can be repaired. >> >> No, the language is correct. This is the mathematically correct definition >> of mod/div. We can be thankful that at least one language actually got it >> right. Moreover, the mathematicians knew what they were doing. Try some >> example coding with, e.g., arrays as circular buffers, using mod/div to >> increment/decrement your way around them. So many times in other languages, >> I have struggled with the frustration of having to write overcomplicated code >> to compensate for incorrect mod/div in other than the first quadrant. >> >> C is particularly exasperating, because it doesn't define them at all outside >> the first quadrant. It is implementor's option. This means these operators >> are entirely unusable for code that needs to be the least bit portable--even >> different compilers on the same machine. You always have to adjust your >> operands to first quadrant, do the operation, and then readjust. >> >> In Modula-3, you just do the operation. >> >> It turns out there are several >>> reasonable definitions of div and mod. Modula-3 doesn't >>> chose the obvious correct one and C doesn't chose the >>> obvious incorrect one. >>> >>> We may yet be able to use the gcc support but it makes me nervous. >>> It requires at least in a very minimal sense, for the frontend >>> to support TImode (aka int128_t). >>> >>> See: http://gcc.gnu.org/ml/gcc/2010-06/msg00647.html >>> (which is just from me, talking to myself..) >>> >>> From jkrell at elego.de Thu Jun 24 11:26:47 2010 From: jkrell at elego.de (Jay Krell) Date: Thu, 24 Jun 2010 11:26:47 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100624092648.11DE3CC37E@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/06/24 11:26:47 Modified files: cm3/m3-sys/m3cc/gcc/gcc/: lower-subreg.c Log message: initialize local due to warning that it might be used uninitialized From jkrell at elego.de Thu Jun 24 11:37:44 2010 From: jkrell at elego.de (Jay Krell) Date: Thu, 24 Jun 2010 11:37:44 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100624093744.E715ECC37E@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/06/24 11:37:44 Modified files: cm3/m3-libs/m3core/src/Csupport/Common/: hand.c Log message: fix div/mod helpers to operate on INTEGER/WORD_T instead of INT32/UINT32; still there is a problem and I will next try using the release version of these From jkrell at elego.de Thu Jun 24 11:47:30 2010 From: jkrell at elego.de (Jay Krell) Date: Thu, 24 Jun 2010 11:47:30 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100624094730.BC58C2474006@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/06/24 11:47:30 Modified files: cm3/m3-libs/m3core/src/Csupport/Common/: hand.c Log message: go back to release form of div/mod helpers for now, though these don't fix the problem either (X.i3 could not find a legal alignment for the packed type From jkrell at elego.de Thu Jun 24 11:54:35 2010 From: jkrell at elego.de (Jay Krell) Date: Thu, 24 Jun 2010 11:54:35 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100624095436.142832474006@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/06/24 11:54:35 Added files: cm3/m3-libs/m3core/src/C/ARMEL_LINUX/: Csetjmp.i3 Log message: I forgot to commit this last weekend. From jkrell at elego.de Thu Jun 24 12:40:42 2010 From: jkrell at elego.de (Jay Krell) Date: Thu, 24 Jun 2010 12:40:42 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100624104042.AE6C4CC37E@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/06/24 12:40:42 Modified files: cm3/m3-ui/X11R4/src/Common/: X.i3 Log message: make lots of fields private to match current headers and DisplayStar = UNTRACED BRANDED REF ADDRESS to push all of Display toward private, like current headers From jkrell at elego.de Thu Jun 24 12:51:31 2010 From: jkrell at elego.de (Jay Krell) Date: Thu, 24 Jun 2010 12:51:31 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100624105133.4CC05CC110@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/06/24 12:51:31 Modified files: cm3/m3-ui/X11R4/src/Common/: X.i3 Log message: slightly further privatize display and gc (graphics context) in accordance with current headers Note that Xlib is I believe considered obsolete/deprecated/legacy and there is a new xcb X C binding. See http://en.wikipedia.org/wiki/XCB etc. (I'd have to research how widely xcb is distributed and used.) From jkrell at elego.de Thu Jun 24 13:05:49 2010 From: jkrell at elego.de (Jay Krell) Date: Thu, 24 Jun 2010 13:05:49 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100624110549.92EF52474006@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/06/24 13:05:49 Modified files: cm3/m3-libs/m3core/src/runtime/common/: RTType.m3 Log message: make it compatible with new ADR old ADR(T):ADDRESS new ADR(T):UNTRACED REF T From jay.krell at cornell.edu Thu Jun 24 13:06:14 2010 From: jay.krell at cornell.edu (Jay K) Date: Thu, 24 Jun 2010 11:06:14 +0000 Subject: [M3commit] CVS Update: cm3 In-Reply-To: <20100624110549.92EF52474006@birch.elegosoft.com> References: <20100624110549.92EF52474006@birch.elegosoft.com> Message-ID: =================================================================== RCS file: /usr/cvs/cm3/m3-libs/m3core/src/runtime/common/RTType.m3,v retrieving revision 1.10 diff -u -r1.10 RTType.m3 --- runtime/common/RTType.m3??? 3 Nov 2009 20:30:21 -0000??? 1.10 +++ runtime/common/RTType.m3??? 24 Jun 2010 11:02:06 -0000 @@ -455,8 +455,8 @@ ???? GenBuiltin (ADR (NULL_typecell),???? "NULL"); ???? GenBuiltin (ADR (REFANY_typecell),?? "REFANY"); ???? GenBuiltin (ADR (ADDRESS_typecell),? "ADDRESS"); -??? GenBuiltin (ADR (ROOT_typecell),???? "ROOT"); -??? GenBuiltin (ADR (UNROOT_typecell),?? "UNTRACED ROOT"); +??? GenBuiltin (ADR (ROOT_typecell.common), "ROOT"); +??? GenBuiltin (ADR (UNROOT_typecell.common), "UNTRACED ROOT"); ???? types.cnt := MAX (types.cnt, RT0.FirstUserTypecode); ?? END AssignBuiltinTypes; ---------------------------------------- > Date: Thu, 24 Jun 2010 13:05:49 +0000 > To: m3commit at elegosoft.com > From: jkrell at elego.de > Subject: [M3commit] CVS Update: cm3 > > CVSROOT: /usr/cvs > Changes by: jkrell at birch. 10/06/24 13:05:49 > > Modified files: > cm3/m3-libs/m3core/src/runtime/common/: RTType.m3 > > Log message: > make it compatible with new ADR > old ADR(T):ADDRESS > new ADR(T):UNTRACED REF T > From jkrell at elego.de Thu Jun 24 13:34:11 2010 From: jkrell at elego.de (Jay Krell) Date: Thu, 24 Jun 2010 13:34:11 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100624113412.671642474006@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/06/24 13:34:11 Modified files: cm3/m3-sys/m3tests/src/p0/p073/: Main.m3 stderr.pgm Log message: augment div/mod test (this might be redundant, but it is fast) From jkrell at elego.de Thu Jun 24 13:47:44 2010 From: jkrell at elego.de (Jay Krell) Date: Thu, 24 Jun 2010 13:47:44 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100624114744.E3B3ECC37E@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/06/24 13:47:44 Modified files: cm3/m3-sys/m3tests/src/p0/p073/: Main.m3 Log message: more checks From jkrell at elego.de Thu Jun 24 13:51:28 2010 From: jkrell at elego.de (Jay Krell) Date: Thu, 24 Jun 2010 13:51:28 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100624115128.BC147CC37E@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/06/24 13:51:28 Modified files: cm3/m3-sys/m3tests/src/p0/p073/: Main.m3 Log message: more/clearer checks From jkrell at elego.de Fri Jun 25 10:00:22 2010 From: jkrell at elego.de (Jay Krell) Date: Fri, 25 Jun 2010 10:00:22 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100625080022.8AB37CC110@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/06/25 10:00:22 Modified files: cm3/m3-libs/m3core/src/Csupport/Common/: hand.c Log message: back to versions that avoid overflowing signed numbers From jkrell at elego.de Fri Jun 25 11:02:40 2010 From: jkrell at elego.de (Jay Krell) Date: Fri, 25 Jun 2010 11:02:40 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100625090240.5467CCC37E@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/06/25 11:02:40 Modified files: cm3/m3-sys/m3cc/gcc/gcc/: tree-nested.c Log message: add an assert, based on a suspicion: STATIC_CHAIN_EXPR must always have a target_context, whatever that is From jkrell at elego.de Sat Jun 26 13:27:30 2010 From: jkrell at elego.de (Jay Krell) Date: Sat, 26 Jun 2010 13:27:30 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100626112730.0EADFCC37F@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/06/26 13:27:30 Modified files: cm3/m3-sys/m3cc/gcc-4.5/gcc/config/: darwin-protos.h Log message: ../../gcc-4.5/gcc/config/darwin-protos.h:57: warning: ???enum machine_mode??? declared inside parameter list ../../gcc-4.5/gcc/config/darwin-protos.h:57: warning: its scope is only this definition or declaration, which is probably not what you want throw in forward declaration: "enum machine_mode;" could be we are missing an #include From jkrell at elego.de Sat Jun 26 13:35:31 2010 From: jkrell at elego.de (Jay Krell) Date: Sat, 26 Jun 2010 13:35:31 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100626113531.50E39CC37F@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/06/26 13:35:31 Modified files: cm3/m3-sys/m3cc/gcc-4.5/gcc/: genpeep.c Log message: quash Darwin-specific warning from ranlib see http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44308 (which gcc maintainers won't fix) From jkrell at elego.de Sat Jun 26 13:36:43 2010 From: jkrell at elego.de (Jay Krell) Date: Sat, 26 Jun 2010 13:36:43 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100626113643.A47742474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/06/26 13:36:43 Modified files: cm3/m3-sys/m3cc/gcc-4.5/gcc/: genpeep.c Log message: move newlines around From jkrell at elego.de Sat Jun 26 13:37:27 2010 From: jkrell at elego.de (Jay Krell) Date: Sat, 26 Jun 2010 13:37:27 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100626113727.40CA82474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/06/26 13:37:27 Modified files: cm3/m3-sys/m3cc/gcc-4.5/gcc/: genpeep.c Log message: change symbol From jkrell at elego.de Sat Jun 26 15:08:46 2010 From: jkrell at elego.de (Jay Krell) Date: Sat, 26 Jun 2010 15:08:46 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100626130846.713D7CC37F@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/06/26 15:08:46 Modified files: cm3/m3-sys/m3middle/src/: TFloat.m3 Log message: LOOPHOLE so it works with -new_adr From jay.krell at cornell.edu Sat Jun 26 15:09:44 2010 From: jay.krell at cornell.edu (Jay K) Date: Sat, 26 Jun 2010 13:09:44 +0000 Subject: [M3commit] CVS Update: cm3 In-Reply-To: <20100626130846.713D7CC37F@birch.elegosoft.com> References: <20100626130846.713D7CC37F@birch.elegosoft.com> Message-ID: @@ -200,15 +200,15 @@ ? ???? CASE p OF ???? | Precision.Short => -??????? ptr := ADR (x1); +??????? ptr := LOOPHOLE(ADR (x1), Ptr); ???????? SUBARRAY (ptr^, 0, len) := SUBARRAY (buf, 0, len); ???????? f.fraction := FLOAT (x1, EXTENDED); ???? | Precision.Long => -??????? ptr := ADR (x2); +??????? ptr := LOOPHOLE(ADR (x2), Ptr); ???????? SUBARRAY (ptr^, 0, len) := SUBARRAY (buf, 0, len); ???????? f.fraction := FLOAT (x2, EXTENDED); ???? | Precision.Extended => -??????? ptr := ADR (x3); +??????? ptr := LOOPHOLE(ADR (x3), Ptr); ???????? SUBARRAY (ptr^, 0, len) := SUBARRAY (buf, 0, len); ???????? f.fraction := x3; ???? END; ---------------------------------------- > Date: Sat, 26 Jun 2010 15:08:46 +0000 > To: m3commit at elegosoft.com > From: jkrell at elego.de > Subject: [M3commit] CVS Update: cm3 > > CVSROOT: /usr/cvs > Changes by: jkrell at birch. 10/06/26 15:08:46 > > Modified files: > cm3/m3-sys/m3middle/src/: TFloat.m3 > > Log message: > LOOPHOLE so it works with -new_adr > From jkrell at elego.de Sat Jun 26 15:15:39 2010 From: jkrell at elego.de (Jay Krell) Date: Sat, 26 Jun 2010 15:15:39 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100626131539.E8FB62474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/06/26 15:15:39 Modified files: cm3/m3-comm/tcp/src/POSIX/: TCPPeer.m3 TCPExtras.m3 Log message: fix memory corrupting bug that I probably introduced, 64bit only, found by -new_adr int to socklen_t From jay.krell at cornell.edu Sat Jun 26 15:16:14 2010 From: jay.krell at cornell.edu (Jay K) Date: Sat, 26 Jun 2010 13:16:14 +0000 Subject: [M3commit] CVS Update: cm3 In-Reply-To: <20100626131539.E8FB62474003@birch.elegosoft.com> References: <20100626131539.E8FB62474003@birch.elegosoft.com> Message-ID: =================================================================== RCS file: /usr/cvs/cm3/m3-comm/tcp/src/POSIX/TCPExtras.m3,v retrieving revision 1.1.1.1 diff -u -r1.1.1.1 TCPExtras.m3 --- TCPExtras.m3??? 13 Jan 2001 14:15:14 -0000??? 1.1.1.1 +++ TCPExtras.m3??? 26 Jun 2010 13:13:58 -0000 @@ -9,7 +9,7 @@ ?PROCEDURE LocalEndpoint (conn: TCP.T): IP.Endpoint RAISES {IP.Error} = ?? VAR ???? addr : Uin.struct_sockaddr_in; -??? len? : Ctypes.int := BYTESIZE (addr); +??? len? : Usocket.socklen_t := BYTESIZE (addr); ???? ep?? : IP.Endpoint; ?? BEGIN ???? LOCK conn DO Index: TCPPeer.m3 =================================================================== RCS file: /usr/cvs/cm3/m3-comm/tcp/src/POSIX/TCPPeer.m3,v retrieving revision 1.1.1.1 diff -u -r1.1.1.1 TCPPeer.m3 --- TCPPeer.m3??? 13 Jan 2001 14:15:14 -0000??? 1.1.1.1 +++ TCPPeer.m3??? 26 Jun 2010 13:13:58 -0000 @@ -45,7 +45,7 @@ ? ?PROCEDURE GetSockAddr (channel: TCP.T;? VAR(*OUT*) addr: Addr) ?? RAISES {IP.Error} = -? VAR len: Ctypes.int := BYTESIZE (addr); +? VAR len: Usocket.socklen_t := BYTESIZE (addr); ?? BEGIN ???? LOCK channel DO ?????? IF (channel.closed) THEN IPError.Raise (TCP.Closed); END; ---------------------------------------- > Date: Sat, 26 Jun 2010 15:15:39 +0000 > To: m3commit at elegosoft.com > From: jkrell at elego.de > Subject: [M3commit] CVS Update: cm3 > > CVSROOT: /usr/cvs > Changes by: jkrell at birch. 10/06/26 15:15:39 > > Modified files: > cm3/m3-comm/tcp/src/POSIX/: TCPPeer.m3 TCPExtras.m3 > > Log message: > fix memory corrupting bug that I probably introduced, 64bit only, found by -new_adr int to socklen_t > From jkrell at elego.de Sat Jun 26 15:17:53 2010 From: jkrell at elego.de (Jay Krell) Date: Sat, 26 Jun 2010 15:17:53 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100626131753.F2D342474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/06/26 15:17:53 Modified files: cm3/m3-comm/udp/src/POSIX/: UDPPosix.m3 Log message: int to socklen_t so it works with -new_adr and doesn't corrupt memory on 64bit From jay.krell at cornell.edu Sat Jun 26 15:18:15 2010 From: jay.krell at cornell.edu (Jay K) Date: Sat, 26 Jun 2010 13:18:15 +0000 Subject: [M3commit] CVS Update: cm3 In-Reply-To: <20100626131753.F2D342474003@birch.elegosoft.com> References: <20100626131753.F2D342474003@birch.elegosoft.com> Message-ID: Index: src/POSIX/UDPPosix.m3 =================================================================== RCS file: /usr/cvs/cm3/m3-comm/udp/src/POSIX/UDPPosix.m3,v retrieving revision 1.3 diff -u -r1.3 UDPPosix.m3 --- src/POSIX/UDPPosix.m3??? 14 Apr 2003 20:18:44 -0000??? 1.3 +++ src/POSIX/UDPPosix.m3??? 26 Jun 2010 13:17:16 -0000 @@ -122,7 +122,7 @@ ???? waitRes: SchedulerPosix.WaitResult; ???? numRead: INTEGER; ???? sockaddr: Uin.struct_sockaddr_in; -??? saSize: Ctypes.int; +??? saSize: Usocket.socklen_t; ?? BEGIN ???? <* ASSERT self.open *> ???? waitRes := SchedulerPosix.IOAlertWait(self.fileno, TRUE, timeout); ---------------------------------------- > Date: Sat, 26 Jun 2010 15:17:53 +0000 > To: m3commit at elegosoft.com > From: jkrell at elego.de > Subject: [M3commit] CVS Update: cm3 > > CVSROOT: /usr/cvs > Changes by: jkrell at birch. 10/06/26 15:17:53 > > Modified files: > cm3/m3-comm/udp/src/POSIX/: UDPPosix.m3 > > Log message: > int to socklen_t so it works with -new_adr and doesn't corrupt memory on 64bit > From jkrell at elego.de Sat Jun 26 15:19:58 2010 From: jkrell at elego.de (Jay Krell) Date: Sat, 26 Jun 2010 15:19:58 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100626131958.7C94A2474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/06/26 15:19:58 Modified files: cm3/m3-libs/sysutils/src/POSIX/: SystemPosix.m3 Log message: LOOPHOLE to char_star so it works with -new_adr From jkrell at elego.de Sat Jun 26 15:25:58 2010 From: jkrell at elego.de (Jay Krell) Date: Sat, 26 Jun 2010 15:25:58 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100626132558.E05AC2474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/06/26 15:25:58 Modified files: cm3/m3-libs/libm3/src/os/POSIX/: SocketPosix.m3 Log message: int/INTEGER => socklen_t LOOPHOLE to char_star so it works with -new_adr and doesn't corrupt stack From jay.krell at cornell.edu Sat Jun 26 15:20:16 2010 From: jay.krell at cornell.edu (Jay K) Date: Sat, 26 Jun 2010 13:20:16 +0000 Subject: [M3commit] CVS Update: cm3 In-Reply-To: <20100626131958.7C94A2474003@birch.elegosoft.com> References: <20100626131958.7C94A2474003@birch.elegosoft.com> Message-ID: Index: src/POSIX/SystemPosix.m3 =================================================================== RCS file: /usr/cvs/cm3/m3-libs/sysutils/src/POSIX/SystemPosix.m3,v retrieving revision 1.16 diff -u -r1.16 SystemPosix.m3 --- src/POSIX/SystemPosix.m3??? 10 Mar 2010 10:45:44 -0000??? 1.16 +++ src/POSIX/SystemPosix.m3??? 26 Jun 2010 13:19:32 -0000 @@ -34,7 +34,7 @@ ???? buf : ARRAY [0..1024] OF CHAR; ???? len := 1024; ?? BEGIN -??? IF gethostname(ADR(buf), len) = 0 THEN +??? IF gethostname(LOOPHOLE(ADR(buf), Ctypes.char_star), len) = 0 THEN ?????? buf[1024] := '\000'; ?????? len := 0; ?????? WHILE len < 1024 AND buf[len] # '\000' DO ---------------------------------------- > Date: Sat, 26 Jun 2010 15:19:58 +0000 > To: m3commit at elegosoft.com > From: jkrell at elego.de > Subject: [M3commit] CVS Update: cm3 > > CVSROOT: /usr/cvs > Changes by: jkrell at birch. 10/06/26 15:19:58 > > Modified files: > cm3/m3-libs/sysutils/src/POSIX/: SystemPosix.m3 > > Log message: > LOOPHOLE to char_star so it works with -new_adr > From jkrell at elego.de Sat Jun 26 15:29:46 2010 From: jkrell at elego.de (Jay Krell) Date: Sat, 26 Jun 2010 15:29:46 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100626132946.AAB282474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/06/26 15:29:46 Modified files: cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c Log message: fix minor typo in trace output From jay.krell at cornell.edu Sat Jun 26 15:28:04 2010 From: jay.krell at cornell.edu (Jay K) Date: Sat, 26 Jun 2010 13:28:04 +0000 Subject: [M3commit] CVS Update: cm3 In-Reply-To: <20100626132558.E05AC2474003@birch.elegosoft.com> References: <20100626132558.E05AC2474003@birch.elegosoft.com> Message-ID: oops I deleted the diff, but simple enough ---------------------------------------- > Date: Sat, 26 Jun 2010 15:25:58 +0000 > To: m3commit at elegosoft.com > From: jkrell at elego.de > Subject: [M3commit] CVS Update: cm3 > > CVSROOT: /usr/cvs > Changes by: jkrell at birch. 10/06/26 15:25:58 > > Modified files: > cm3/m3-libs/libm3/src/os/POSIX/: SocketPosix.m3 > > Log message: > int/INTEGER => socklen_t > LOOPHOLE to char_star > so it works with -new_adr and doesn't corrupt stack > From jkrell at elego.de Sun Jun 27 10:52:53 2010 From: jkrell at elego.de (Jay Krell) Date: Sun, 27 Jun 2010 10:52:53 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100627085253.CA57B2474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/06/27 10:52:53 Modified files: cm3/m3-sys/m3cc/src/: gnucc.common Log message: allow -DO0 to turn off optimizations From jkrell at elego.de Sun Jun 27 12:09:53 2010 From: jkrell at elego.de (Jay Krell) Date: Sun, 27 Jun 2010 12:09:53 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100627100953.835322474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/06/27 12:09:53 Modified files: cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c Log message: #ifdef GCC45 to #if GCC45, #ifndef to #if ! From jkrell at elego.de Sun Jun 27 12:19:51 2010 From: jkrell at elego.de (Jay Krell) Date: Sun, 27 Jun 2010 12:19:51 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100627101951.3F9D32474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/06/27 12:19:51 Modified files: cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c Log message: change some #if GCC45 to if (GCC45), where both arms should compile with either code base From jkrell at elego.de Sun Jun 27 12:21:24 2010 From: jkrell at elego.de (Jay Krell) Date: Sun, 27 Jun 2010 12:21:24 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100627102124.F3B4ACC10F@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/06/27 12:21:24 Modified files: cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c Log message: remove initial #define GCC45 0 From jkrell at elego.de Sun Jun 27 12:30:48 2010 From: jkrell at elego.de (Jay Krell) Date: Sun, 27 Jun 2010 12:30:48 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100627103048.E1C072474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/06/27 12:30:48 Modified files: cm3/m3-sys/m3cc/src/: m3makefile cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c Log message: a little more #ifdef to #if, GCC_APPLE and GCC42 (which really mean the same thing) From jkrell at elego.de Sun Jun 27 12:58:39 2010 From: jkrell at elego.de (Jay Krell) Date: Sun, 27 Jun 2010 12:58:39 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100627105839.2F8802474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/06/27 12:58:39 Modified files: cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c Log message: fold gcc45 and non-gcc45 code mostly via: enum tree_code plus = (GCC45 ? POINTER_PLUS_EXPR : PLUS_EXPR); From jkrell at elego.de Sun Jun 27 13:36:38 2010 From: jkrell at elego.de (Jay Krell) Date: Sun, 27 Jun 2010 13:36:38 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100627113638.913772474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/06/27 13:36:38 Modified files: cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c Log message: in m3cg_set_label, use a loop to put the asm("") before and after the label, instead of duplicating the code also in m3cg_set_label, a possible gcc 4.5 fix, use DECL_NONLOCAL(l) = true; instead of manipulating nonlocal_goto_handler_labels, which doesn't work (it crashes) From jkrell at elego.de Sun Jun 27 13:56:52 2010 From: jkrell at elego.de (Jay Krell) Date: Sun, 27 Jun 2010 13:56:52 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100627115653.035C92474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/06/27 13:56:52 Modified files: cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c Log message: fix m3cg_set_label change From jkrell at elego.de Sun Jun 27 15:17:37 2010 From: jkrell at elego.de (Jay Krell) Date: Sun, 27 Jun 2010 15:17:37 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100627131737.AE1812474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/06/27 15:17:37 Modified files: cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c Log message: reduce diff in gcc 4.3 m3cg_set_label From jkrell at elego.de Sun Jun 27 15:19:43 2010 From: jkrell at elego.de (Jay Krell) Date: Sun, 27 Jun 2010 15:19:43 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100627131943.1D4D42474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/06/27 15:19:43 Modified files: cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c Log message: fix type to fix warning From jkrell at elego.de Sun Jun 27 15:23:14 2010 From: jkrell at elego.de (Jay Krell) Date: Sun, 27 Jun 2010 15:23:14 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100627132314.9DE152474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/06/27 15:23:14 Modified files: cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c Log message: provide IS_INTEGER_TYPE_TREE and IS_WORD_TYPE_TREE macros even for gcc <4.5; forward declare enum machine_mode to quash warning on other targets From jkrell at elego.de Sun Jun 27 15:24:10 2010 From: jkrell at elego.de (Jay Krell) Date: Sun, 27 Jun 2010 15:24:10 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100627132410.BBD782474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/06/27 15:24:10 Modified files: cm3/m3-sys/m3cc/gcc/gcc/config/: darwin-protos.h Log message: remove the enum machine_mode forward declare from here, now that we have in parse.c From jkrell at elego.de Sun Jun 27 16:09:33 2010 From: jkrell at elego.de (Jay Krell) Date: Sun, 27 Jun 2010 16:09:33 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100627140933.123E12474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/06/27 16:09:33 Modified files: cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c Log message: fix 4.5 compilation regarding x_nonlocal_goto_handler_labels From jkrell at elego.de Mon Jun 28 03:30:29 2010 From: jkrell at elego.de (Jay Krell) Date: Mon, 28 Jun 2010 3:30:29 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100628013029.E17DE2474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/06/28 03:30:29 Modified files: cm3/m3-sys/m3front/src/misc/: CG.m3 Log message: go back to spelling out Target.Integer|Word.cg_type; there are several (at least instances) of type mismatches here, that gcc 4.5 complains about, we need to use Integer less and Word more, but that isn't changed here yet From jkrell at elego.de Mon Jun 28 11:03:25 2010 From: jkrell at elego.de (Jay Krell) Date: Mon, 28 Jun 2010 11:03:25 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100628090325.118072474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/06/28 11:03:25 Modified files: cm3/m3-libs/m3core/src/: m3core.h Log message: fix Visual C++ warning under -Wall From jkrell at elego.de Mon Jun 28 11:05:08 2010 From: jkrell at elego.de (Jay Krell) Date: Mon, 28 Jun 2010 11:05:08 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100628090508.0DD482474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/06/28 11:05:08 Modified files: cm3/m3-libs/m3core/src/: m3core.h Log message: remove duplicate #define of EXTERN_CONST From jkrell at elego.de Mon Jun 28 11:07:08 2010 From: jkrell at elego.de (Jay Krell) Date: Mon, 28 Jun 2010 11:07:08 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100628090708.541752474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/06/28 11:07:08 Modified files: cm3/m3-libs/m3core/src/Csupport/Common/: hand.c Log message: fix Windows compilation (uint64 => UINT64) From jkrell at elego.de Mon Jun 28 22:29:57 2010 From: jkrell at elego.de (Jay Krell) Date: Mon, 28 Jun 2010 22:29:57 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100628202957.294622474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/06/28 22:29:56 Modified files: cm3/m3-libs/m3core/src/: m3core.h Log message: put back warning, better than consequent error From jkrell at elego.de Tue Jun 29 09:06:33 2010 From: jkrell at elego.de (Jay Krell) Date: Tue, 29 Jun 2010 9:06:33 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100629070634.0A6082474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/06/29 09:06:33 Modified files: cm3/scripts/win/: sysinfo.cmd Log message: support spaces in INCLUDE and PATH, though spaces in CM3_INSTALL are missing quotes when -I is passed to C compiler From jkrell at elego.de Tue Jun 29 09:07:07 2010 From: jkrell at elego.de (Jay Krell) Date: Tue, 29 Jun 2010 9:07:07 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100629070707.CF4BE2474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/06/29 09:07:07 Modified files: cm3/scripts/win/: cvs.c Log message: set CVS_RSH=/bin/ssh if it is ssh or empty From jkrell at elego.de Tue Jun 29 09:07:34 2010 From: jkrell at elego.de (Jay Krell) Date: Tue, 29 Jun 2010 9:07:34 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100629070734.42E602474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/06/29 09:07:34 Modified files: cm3/scripts/win/: cvs.c Log message: remove tab From jkrell at elego.de Tue Jun 29 12:56:36 2010 From: jkrell at elego.de (Jay Krell) Date: Tue, 29 Jun 2010 12:56:36 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100629105636.D40B42474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/06/29 12:56:36 Modified files: cm3/m3-sys/m3tests/src/p2/p230/: Main.m3 Added files: cm3/m3-sys/m3tests/src/p2/p230/: stdout.pgm32-big_endian stdout.pgm32-little_endian stdout.pgm64-big_endian stdout.pgm64-little_endian Removed files: cm3/m3-sys/m3tests/src/p2/p230/: stdout.pgm-big_endian stdout.pgm-little_endian Log message: The output here is word size specific, besides endian specific, because the sets aren't an multiple of 64 bits in size. The 64bit big endian file here is just a copy of 32bit big endian. From jkrell at elego.de Tue Jun 29 13:04:55 2010 From: jkrell at elego.de (Jay Krell) Date: Tue, 29 Jun 2010 13:04:55 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100629110455.957802474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/06/29 13:04:55 Added files: cm3/m3-sys/m3tests/src/p2/p230/: stdout.pgm-big_endian32 stdout.pgm-big_endian64 stdout.pgm-little_endian32 stdout.pgm-little_endian64 Removed files: cm3/m3-sys/m3tests/src/p2/p230/: stdout.pgm32-big_endian stdout.pgm32-little_endian stdout.pgm64-big_endian stdout.pgm64-little_endian Log message: correct the names From jkrell at elego.de Tue Jun 29 13:33:25 2010 From: jkrell at elego.de (Jay Krell) Date: Tue, 29 Jun 2010 13:33:25 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100629113325.7A8542474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/06/29 13:33:25 Added files: cm3/m3-sys/m3tests/src/p2/p239/: Main.m3 Main.ms-AMD64_DARWIN m3makefile Log message: Experimentally..start a line of tests where we checkin the "exact" codegen, so we can later compare. Several caveats/notes: the infrastructure to do the compares is not here yet (shortly) we should probably allow just "i386" or "amd64", instead of the full "AMD64_DARWIN" this kind of testing is "very sensitive" The sensitivity has at least been somewhat reduced by omitting debugging info, and noise reduced by omitting pic and unwind tables The test is far from complete. More targets need current output before changes are made. From jkrell at elego.de Tue Jun 29 13:33:59 2010 From: jkrell at elego.de (Jay Krell) Date: Tue, 29 Jun 2010 13:33:59 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100629113359.555532474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/06/29 13:33:59 Modified files: cm3/m3-sys/m3tests/src/: m3makefile Log message: add test p239 and infra to compare it er, not sure what this will do on other targets, probably fail but not too noisily From jkrell at elego.de Tue Jun 29 13:45:58 2010 From: jkrell at elego.de (Jay Krell) Date: Tue, 29 Jun 2010 13:45:58 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100629114558.377DB2474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/06/29 13:45:58 Modified files: cm3/m3-sys/m3tests/src/p2/p239/: Main.m3 Main.ms-AMD64_DARWIN Log message: add bit-and tests From jkrell at elego.de Tue Jun 29 13:59:29 2010 From: jkrell at elego.de (Jay Krell) Date: Tue, 29 Jun 2010 13:59:29 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100629115929.B82F62474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/06/29 13:59:29 Modified files: cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c Log message: change m3_build1 (CONVERT_EXPR, ...) to m3_convert (...) no great reason, but based on m3_cast convert/cast will be the subject of likely near future other changes, until configure -enable-checking is satisfied (some changes might be elsewhere, e.g. m3front) With this change, the assembly output for AMD64_DARWIN m3core is unchanged. From jkrell at elego.de Tue Jun 29 14:08:31 2010 From: jkrell at elego.de (Jay Krell) Date: Tue, 29 Jun 2010 14:08:31 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100629120831.215B2CC110@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/06/29 14:08:31 Modified files: cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c Log message: Start fixing configure -enable-checking problems. Start with the very simplest: bit-or/and/xor/not. There are some small changes in m3core as a result but they don't appear to be semantically interesting, mostly stuff like: - movq -32(%rbp), %rdx - movq -24(%rbp), %rax + movq -24(%rbp), %rdx + movq -32(%rbp), %rax orq %rdx, %rax when I tried reversing the parameter order, the changes where larger. From jay.krell at cornell.edu Tue Jun 29 14:09:26 2010 From: jay.krell at cornell.edu (Jay K) Date: Tue, 29 Jun 2010 12:09:26 +0000 Subject: [M3commit] CVS Update: cm3 In-Reply-To: <20100629120831.215B2CC110@birch.elegosoft.com> References: <20100629120831.215B2CC110@birch.elegosoft.com> Message-ID: Index: gcc/gcc/m3cg/parse.c =================================================================== RCS file: /usr/cvs/cm3/m3-sys/m3cc/gcc/gcc/m3cg/parse.c,v retrieving revision 1.202 diff -u -r1.202 parse.c --- gcc/gcc/m3cg/parse.c??? 29 Jun 2010 11:59:29 -0000??? 1.202 +++ gcc/gcc/m3cg/parse.c??? 29 Jun 2010 12:07:03 -0000 @@ -4412,8 +4412,7 @@ ?{ ?? MTYPE (t); ? -? EXPR_REF (-1) = m3_build1 (BIT_NOT_EXPR, m3_unsigned_type (t), -???????????????????????????? EXPR_REF (-1)); +? EXPR_REF (-1) = m3_build1 (BIT_NOT_EXPR, t, m3_cast (t, EXPR_REF (-1))); ?} ? ?static void @@ -4421,8 +4420,9 @@ ?{ ?? MTYPE (t); ? -? EXPR_REF (-2) = m3_build2 (BIT_AND_EXPR, m3_unsigned_type (t), -???????????????????????????? EXPR_REF (-2), EXPR_REF (-1)); +? EXPR_REF (-2) = m3_build2 (BIT_AND_EXPR, t, +???????????????????????????? m3_cast (t, EXPR_REF (-2)), +???????????????????????????? m3_cast (t, EXPR_REF (-1))); ?? EXPR_POP (); ?} ? @@ -4431,8 +4431,9 @@ ?{ ?? MTYPE (t); ? -? EXPR_REF (-2) = m3_build2 (BIT_IOR_EXPR, m3_unsigned_type (t), -???????????????????????????? EXPR_REF (-2), EXPR_REF (-1)); +? EXPR_REF (-2) = m3_build2 (BIT_IOR_EXPR, t, +???????????????????????????? m3_cast (t, EXPR_REF (-2)), +???????????????????????????? m3_cast (t, EXPR_REF (-1))); ?? EXPR_POP (); ?} ? @@ -4441,8 +4442,9 @@ ?{ ?? MTYPE (t); ? -? EXPR_REF (-2) = m3_build2 (BIT_XOR_EXPR, m3_unsigned_type (t), -???????????????????????????? EXPR_REF (-2), EXPR_REF (-1)); +? EXPR_REF (-2) = m3_build2 (BIT_XOR_EXPR, t, +???????????????????????????? m3_convert (t, EXPR_REF (-2)), +???????????????????????????? m3_convert (t, EXPR_REF (-1))); ?? EXPR_POP (); ?} ? ---------------------------------------- > Date: Tue, 29 Jun 2010 14:08:31 +0000 > To: m3commit at elegosoft.com > From: jkrell at elego.de > Subject: [M3commit] CVS Update: cm3 > > CVSROOT: /usr/cvs > Changes by: jkrell at birch. 10/06/29 14:08:31 > > Modified files: > cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c > > Log message: > Start fixing configure -enable-checking problems. > Start with the very simplest: bit-or/and/xor/not. > There are some small changes in m3core as a result but > they don't appear to be semantically interesting, mostly stuff like: > - movq -32(%rbp), %rdx > - movq -24(%rbp), %rax > + movq -24(%rbp), %rdx > + movq -32(%rbp), %rax > orq %rdx, %rax > > when I tried reversing the parameter order, the changes where larger. > From jkrell at elego.de Tue Jun 29 14:25:42 2010 From: jkrell at elego.de (Jay Krell) Date: Tue, 29 Jun 2010 14:25:42 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100629122544.BAB2B2474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/06/29 14:25:42 Modified files: cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c Log message: oops, also m3_cast for xor, not m3_convert This again shuffles things around in a way that doesn't seem meaningful. From jkrell at elego.de Tue Jun 29 14:42:12 2010 From: jkrell at elego.de (Jay Krell) Date: Tue, 29 Jun 2010 14:42:12 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100629124212.117E12474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/06/29 14:42:12 Modified files: cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c Log message: cleanup m3cg_index_address - same code for gcc 4.2/3/5 - should address the configure -enable-checking errors I am leary of using m3_cast instead of m3_covert though. From jay.krell at cornell.edu Tue Jun 29 14:42:57 2010 From: jay.krell at cornell.edu (Jay K) Date: Tue, 29 Jun 2010 12:42:57 +0000 Subject: [M3commit] CVS Update: cm3 In-Reply-To: <20100629124212.117E12474003@birch.elegosoft.com> References: <20100629124212.117E12474003@birch.elegosoft.com> Message-ID: Index: parse.c =================================================================== RCS file: /usr/cvs/cm3/m3-sys/m3cc/gcc/gcc/m3cg/parse.c,v retrieving revision 1.204 diff -u -r1.204 parse.c --- parse.c??? 29 Jun 2010 12:25:40 -0000??? 1.204 +++ parse.c??? 29 Jun 2010 12:40:47 -0000 @@ -4982,24 +4982,27 @@ ?static void ?m3cg_index_address (void) ?{ -? enum tree_code plus = (GCC45 ? POINTER_PLUS_EXPR : PLUS_EXPR); ?? tree a = { 0 }; +? bool signd = { 0 }; +? long bytes = { 0 }; + ?? MTYPE2?? (t, T); -? BYTESIZE (n); +? BYTESIZE (bits); +? +? bytes = (bits / BITS_PER_UNIT); ? ?? if (option_vars_trace) -??? fprintf(stderr, "? index address n:0x%lx n_bytes:0x%lx type:%s\n", -??????????? n, n / BITS_PER_UNIT, m3cg_typename(T)); +??? fprintf(stderr, "? index address n_bytes:0x%lx type:%s\n", +??????????? bytes, m3cg_typename(T)); ? -? a = m3_build2 (MULT_EXPR, t, EXPR_REF (-1), size_int (n / BITS_PER_UNIT)); -? if (GCC45) -? { -??? gcc_assert(IS_INTEGER_TYPE_TREE(t) || IS_WORD_TYPE_TREE(t)); -??? if (IS_INTEGER_TYPE_TREE(t)) -????? a = m3_cast(ssizetype, a); -??? a = m3_cast(sizetype, a); -? } -? EXPR_REF (-2) = m3_build2 (plus, t_addr, m3_cast (t_addr, EXPR_REF (-2)), a); +? signd = IS_INTEGER_TYPE_TREE(t); +? gcc_assert(signd || IS_WORD_TYPE_TREE(t)); +? a = (signd ? ssize_int (bytes) : size_int (bytes)); +? a = m3_build2 (MULT_EXPR, t, EXPR_REF (-1), a); +? if (IS_INTEGER_TYPE_TREE(t)) +??? a = m3_cast (ssizetype, a); +? a = m3_cast (sizetype, a); +? EXPR_REF (-2) = m3_build2 (POINTER_PLUS_EXPR, t_addr, m3_cast (t_addr, EXPR_REF (-2)), a); ?? EXPR_POP (); ?} ? ?- Jay ---------------------------------------- > Date: Tue, 29 Jun 2010 14:42:12 +0000 > To: m3commit at elegosoft.com > From: jkrell at elego.de > Subject: [M3commit] CVS Update: cm3 > > CVSROOT: /usr/cvs > Changes by: jkrell at birch. 10/06/29 14:42:12 > > Modified files: > cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c > > Log message: > cleanup m3cg_index_address > - same code for gcc 4.2/3/5 > - should address the configure -enable-checking errors > > I am leary of using m3_cast instead of m3_covert though. > From jkrell at elego.de Tue Jun 29 14:55:46 2010 From: jkrell at elego.de (Jay Krell) Date: Tue, 29 Jun 2010 14:55:46 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100629125546.839972474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/06/29 14:55:46 Modified files: cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c Log message: cleanup m3_do_fixed_extract, no temporaries (in parse.c, not the generated code) needed From jkrell at elego.de Tue Jun 29 15:12:41 2010 From: jkrell at elego.de (Jay Krell) Date: Tue, 29 Jun 2010 15:12:41 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100629131241.21AF12474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/06/29 15:12:41 Modified files: cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c Log message: This should cleanup configure -enable-checking a little more, regarding m3_do_fixed_extract, which is often used for integer division, signed and unsigned. The only change in m3core was a small optimization: +++ AMD64_DARWIN/RTTipe.ms 2010-06-29 05:59:08.000000000 -0700 @@ -3366,41 +3366,39 @@ .stabd 68,0,516 - movq -8(%rbp), %rax - sarq %rax - movq %rax, -8(%rbp) + sarq -8(%rbp) It is not all clear. The tree ended up with, as configure -enable-checking reports, two types, the input and output. -enable-checking demands they be the same. For the left shift, the type doesn't matter. For the right shift, I believe we want the possibly signed type. From jay.krell at cornell.edu Tue Jun 29 15:14:06 2010 From: jay.krell at cornell.edu (Jay K) Date: Tue, 29 Jun 2010 13:14:06 +0000 Subject: [M3commit] CVS Update: cm3 In-Reply-To: <20100629131241.21AF12474003@birch.elegosoft.com> References: <20100629131241.21AF12474003@birch.elegosoft.com> Message-ID: Index: gcc/gcc/m3cg/parse.c =================================================================== RCS file: /usr/cvs/cm3/m3-sys/m3cc/gcc/gcc/m3cg/parse.c,v retrieving revision 1.206 diff -u -r1.206 parse.c --- gcc/gcc/m3cg/parse.c??? 29 Jun 2010 12:55:45 -0000??? 1.206 +++ gcc/gcc/m3cg/parse.c??? 29 Jun 2010 13:09:39 -0000 @@ -4611,7 +4611,7 @@ ???????????????????????????? t); ???? } ? -? x = m3_convert (m3_unsigned_type (t), x); +? x = m3_convert (t, x); ?? x = (b ? m3_build2 (LSHIFT_EXPR, t, x, build_int_cst (t_int, b)) : x); ?? x = (a ? m3_build2 (RSHIFT_EXPR, t, x, build_int_cst (t_int, a)) : x); ?? return x; We might not need the convert, or cast might do. ?- Jay ---------------------------------------- > Date: Tue, 29 Jun 2010 15:12:41 +0000 > To: m3commit at elegosoft.com > From: jkrell at elego.de > Subject: [M3commit] CVS Update: cm3 > > CVSROOT: /usr/cvs > Changes by: jkrell at birch. 10/06/29 15:12:41 > > Modified files: > cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c > > Log message: > This should cleanup configure -enable-checking a little more, > regarding m3_do_fixed_extract, which is often used for > integer division, signed and unsigned. > > The only change in m3core was a small optimization: > +++ AMD64_DARWIN/RTTipe.ms 2010-06-29 05:59:08.000000000 -0700 > @@ -3366,41 +3366,39 @@ > .stabd 68,0,516 > - movq -8(%rbp), %rax > - sarq %rax > - movq %rax, -8(%rbp) > + sarq -8(%rbp) > > It is not all clear. > The tree ended up with, as configure -enable-checking reports, > two types, the input and output. -enable-checking demands > they be the same. For the left shift, the type doesn't matter. > For the right shift, I believe we want the possibly signed type. > From jkrell at elego.de Tue Jun 29 22:58:27 2010 From: jkrell at elego.de (Jay Krell) Date: Tue, 29 Jun 2010 22:58:27 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100629205827.4E3F02474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/06/29 22:58:27 Modified files: cm3/m3-sys/m3cc/gcc-4.5/gcc/: calls.c fold-const.c gimple.c gimplify.c tree-cfg.c tree-nested.c cm3/m3-sys/m3cc/gcc-4.5/gcc/config/i386/: i386.c Log message: checkpoint gcc 4.5 Modula-3 changes including: make some of configure -enable-checking always on making -enable-checking issue warnings instead of errors This can compile cm3 and run a bit of code in it, but does fail and needs further work. Will come back to this once gcc 4.3 -enable-checking is ok. From jay.krell at cornell.edu Tue Jun 29 23:01:43 2010 From: jay.krell at cornell.edu (Jay K) Date: Tue, 29 Jun 2010 21:01:43 +0000 Subject: [M3commit] CVS Update: cm3 In-Reply-To: <20100629205827.4E3F02474003@birch.elegosoft.com> References: <20100629205827.4E3F02474003@birch.elegosoft.com> Message-ID: diff attached ---------------------------------------- > Date: Tue, 29 Jun 2010 22:58:27 +0000 > To: m3commit at elegosoft.com > From: jkrell at elego.de > Subject: [M3commit] CVS Update: cm3 > > CVSROOT: /usr/cvs > Changes by: jkrell at birch. 10/06/29 22:58:27 > > Modified files: > cm3/m3-sys/m3cc/gcc-4.5/gcc/: calls.c fold-const.c gimple.c > gimplify.c tree-cfg.c > tree-nested.c > cm3/m3-sys/m3cc/gcc-4.5/gcc/config/i386/: i386.c > > Log message: > checkpoint gcc 4.5 Modula-3 changes > including: > make some of configure -enable-checking always on > making -enable-checking issue warnings instead of errors > > This can compile cm3 and run a bit of code in it, but does fail > and needs further work. Will come back to this once gcc 4.3 -enable-checking > is ok. > -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: m3cc45-1.txt URL: From jkrell at elego.de Tue Jun 1 03:54:56 2010 From: jkrell at elego.de (Jay Krell) Date: Tue, 1 Jun 2010 3:54:56 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100601015457.B38F92474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/06/01 03:54:56 Modified files: cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c Log message: leave m3cg_pop fixed and optimize the common subexpression, print more typenames in tracing (I meant to get them all the first time) From jkrell at elego.de Tue Jun 1 03:58:38 2010 From: jkrell at elego.de (Jay Krell) Date: Tue, 1 Jun 2010 3:58:38 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100601015838.8A8CB2474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/06/01 03:58:38 Modified files: cm3/m3-sys/m3front/src/builtinOps/: IsType.m3 Narrow.m3 Typecode.m3 Log message: do the tag checking using unsigned integers to satisfy m3cc/configure -enable-checking=all and wants the three types to all be the same (two inputs, one output) but we make the output unconditionally unsigned, so the inputs should also be unsigned this seems reasonable, but kind of reasonable either way From jay.krell at cornell.edu Tue Jun 1 04:02:21 2010 From: jay.krell at cornell.edu (Jay K) Date: Tue, 1 Jun 2010 02:02:21 +0000 Subject: [M3commit] CVS Update: cm3 In-Reply-To: References: <20100531113150.B02672474003@birch.elegosoft.com>, Message-ID: I've left it fixed. I can confirm that "side effects(t)" vs. "side efffects(expr(-1))" are often different. I didn't look closely at the resulting code/behavior. I might assert though that the new behavior only ever keeps stuff where the old behavior kept or threw out. That the new behavior isn't throwing stuff out that we kept. ?- Jay ---------------------------------------- > From: jay.krell at cornell.edu > To: jkrell at elego.de; m3commit at elegosoft.com > Date: Mon, 31 May 2010 11:35:07 +0000 > Subject: Re: [M3commit] CVS Update: cm3 > > > I accidentally fixed the m3cg_pop bug here. > That is a bug that might be dangerous to fix. > I'm going to put it back for now, and have -y output which path is taken so we can better > understand the impact of fixing it. > > - Jay > > > ---------------------------------------- >> Date: Mon, 31 May 2010 13:31:50 +0000 >> To: m3commit at elegosoft.com >> From: jkrell at elego.de >> Subject: [M3commit] CVS Update: cm3 >> >> CVSROOT: /usr/cvs >> Changes by: jkrell at birch. 10/05/31 13:31:50 >> >> Modified files: >> cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c >> >> Log message: >> include typenames in trace all -y output, and some altering of trace output >> > From jkrell at elego.de Tue Jun 1 04:29:26 2010 From: jkrell at elego.de (Jay Krell) Date: Tue, 1 Jun 2010 4:29:26 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100601022927.4AE2C2474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/06/01 04:29:26 Modified files: cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c Log message: Check that we don't throw out stuff that we previously kept. From jkrell at elego.de Tue Jun 1 04:35:47 2010 From: jkrell at elego.de (Jay Krell) Date: Tue, 1 Jun 2010 4:35:47 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100601023611.6F5962474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/06/01 04:35:47 Modified files: cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c Log message: remove some newlines in m3_build_type From jkrell at elego.de Tue Jun 1 04:42:47 2010 From: jkrell at elego.de (Jay Krell) Date: Tue, 1 Jun 2010 4:42:47 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100601024247.74F1F2474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/06/01 04:42:47 Modified files: cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c Log message: remove line I didn't mean to commit From jkrell at elego.de Tue Jun 1 04:48:06 2010 From: jkrell at elego.de (Jay Krell) Date: Tue, 1 Jun 2010 4:48:06 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100601024806.9C2952474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/06/01 04:48:06 Modified files: cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c Log message: combine common code in m3_build_type From jkrell at elego.de Tue Jun 1 05:51:04 2010 From: jkrell at elego.de (Jay Krell) Date: Tue, 1 Jun 2010 5:51:04 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100601035105.087862474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/06/01 05:51:04 Modified files: cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c Log message: use the provided typedef for get_alias_set for 4.3 use the default get_alias_set for 4.5; this would probably be good for 4.3 also From jkrell at elego.de Tue Jun 1 14:08:16 2010 From: jkrell at elego.de (Jay Krell) Date: Tue, 1 Jun 2010 14:08:16 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100601120816.90BA32474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/06/01 14:08:16 Modified files: cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c Log message: It turns out extracting 0 bits is allowed. Test p137 does it. I had put in an assert to disallow it. For this case, alwas return 0, rather than risk "over shifting". This seems to be correct per: http://www.cs.purdue.edu/homes/hosking/m3/reference/word-intf.html We take n (0) bits from the input and set the rest of the bits (all of them) to 0. From jkrell at elego.de Tue Jun 1 14:14:07 2010 From: jkrell at elego.de (Jay Krell) Date: Tue, 1 Jun 2010 14:14:07 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100601121407.1D6D72474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/06/01 14:14:07 Modified files: cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c Log message: parentheses around uses of macro parameters From jkrell at elego.de Tue Jun 1 14:15:01 2010 From: jkrell at elego.de (Jay Krell) Date: Tue, 1 Jun 2010 14:15:01 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100601121501.AF0032474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/06/01 14:15:01 Modified files: cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c Log message: spaces between macro parameters From jkrell at elego.de Tue Jun 1 14:16:57 2010 From: jkrell at elego.de (Jay Krell) Date: Tue, 1 Jun 2010 14:16:57 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100601121657.83A542474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/06/01 14:16:57 Modified files: cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c Log message: globals don't need to be initialized to 0, it is the default; removing the initialization is even sometimes an optimization, depending on the compiler From jkrell at elego.de Tue Jun 1 14:17:35 2010 From: jkrell at elego.de (Jay Krell) Date: Tue, 1 Jun 2010 14:17:35 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100601121735.F27552474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/06/01 14:17:35 Modified files: cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c Log message: globals don't need to be initialized to 0, it is the default; removing the initialization is even sometimes an optimization, depending on the compiler From jay.krell at cornell.edu Tue Jun 1 14:10:27 2010 From: jay.krell at cornell.edu (Jay K) Date: Tue, 1 Jun 2010 12:10:27 +0000 Subject: [M3commit] CVS Update: cm3 In-Reply-To: <20100601120816.90BA32474003@birch.elegosoft.com> References: <20100601120816.90BA32474003@birch.elegosoft.com> Message-ID: ---------------------------------------- > Date: Tue, 1 Jun 2010 14:08:16 +0000 > To: m3commit at elegosoft.com > From: jkrell at elego.de > Subject: [M3commit] CVS Update: cm3 > > CVSROOT: /usr/cvs > Changes by: jkrell at birch. 10/06/01 14:08:16 > > Modified files: > cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c > > Log message: > It turns out extracting 0 bits is allowed. > Test p137 does it. > I had put in an assert to disallow it. > For this case, alwas return 0, rather than risk "over shifting". > This seems to be correct per: > http://www.cs.purdue.edu/homes/hosking/m3/reference/word-intf.html > We take n (0) bits from the input and set the rest of the bits (all > of them) to 0. > -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: extract0w.txt URL: From jkrell at elego.de Tue Jun 1 14:29:54 2010 From: jkrell at elego.de (Jay Krell) Date: Tue, 1 Jun 2010 14:29:54 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100601122954.1877B2474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/06/01 14:29:54 Modified files: cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c Log message: minor: put space in -v output, add const, change char* to char[] to save the pointer From jkrell at elego.de Tue Jun 1 14:32:23 2010 From: jkrell at elego.de (Jay Krell) Date: Tue, 1 Jun 2010 14:32:23 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100601123224.33C842474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/06/01 14:32:23 Modified files: cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c Log message: major: remove the add_stmt from m3cg_pop Compiling m3core each way, and optimized and not, the only thing add_stmt does is add unnecessary code (and it survives optimization). Notice that for years the decision to call add_stmt wasn't right and nobody noticed, which isn't conclusive of course.. From jkrell at elego.de Tue Jun 1 14:42:00 2010 From: jkrell at elego.de (Jay Krell) Date: Tue, 1 Jun 2010 14:42:00 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100601124200.8E42B2474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/06/01 14:42:00 Modified files: cm3/m3-libs/m3core/src/convert/: Convert.m3 Log message: initialize locals; I get warnings that some not quite all, are used uninitialized if I remove the volatile/sideeffects on every load/store in parse.c From jkrell at elego.de Tue Jun 1 14:51:28 2010 From: jkrell at elego.de (Jay Krell) Date: Tue, 1 Jun 2010 14:51:28 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100601125128.A57962474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/06/01 14:51:28 Modified files: cm3/m3-libs/m3core/src/thread/PTHREAD/: ThreadPThread.m3 Log message: initialize locals, warning from modified compiler (though said compiler seems not always correct) From jkrell at elego.de Tue Jun 1 14:56:37 2010 From: jkrell at elego.de (Jay Krell) Date: Tue, 1 Jun 2010 14:56:37 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100601125637.8B97E2474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/06/01 14:56:37 Modified files: cm3/m3-libs/m3core/src/runtime/common/: RTCollector.m3 Log message: slight change due to compiler warning..but it definitely seemed ok before ? From jkrell at elego.de Tue Jun 1 15:35:43 2010 From: jkrell at elego.de (Jay Krell) Date: Tue, 1 Jun 2010 15:35:43 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100601133543.DBF162474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/06/01 15:35:43 Modified files: cm3/m3-libs/libm3/src/geometry/: PolyRegion.m3 cm3/m3-libs/libm3/src/os/POSIX/: ProcessPosixCommon.m3 cm3/m3-libs/libm3/src/rw/: Rd.m3 RdUtils.m3 Log message: initialize locals From jkrell at elego.de Tue Jun 1 16:39:36 2010 From: jkrell at elego.de (Jay Krell) Date: Tue, 1 Jun 2010 16:39:36 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100601143937.16D9D2474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/06/01 16:39:36 Modified files: cm3/m3-libs/m3core/src/runtime/common/: RTCollector.m3 Log message: go back a version, the compiler complaint was wrong and for now I have to be less aggressive because I can't figure out the problem in e.g. libm3/Formatter.m3 From jkrell at elego.de Tue Jun 1 20:19:51 2010 From: jkrell at elego.de (Jay Krell) Date: Tue, 1 Jun 2010 20:19:51 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100601181951.DD2792474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/06/01 20:19:51 Modified files: cm3/m3-libs/sysutils/src/: System.m3 Log message: fix use of uninitialized local From jkrell at elego.de Tue Jun 1 20:23:03 2010 From: jkrell at elego.de (Jay Krell) Date: Tue, 1 Jun 2010 20:23:03 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100601182303.817262474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/06/01 20:23:03 Modified files: cm3/m3-sys/m3back/src/: M3x86.m3 Log message: initialize locals From jkrell at elego.de Tue Jun 1 20:26:48 2010 From: jkrell at elego.de (Jay Krell) Date: Tue, 1 Jun 2010 20:26:48 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100601182648.7B8872474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/06/01 20:26:48 Modified files: cm3/m3-sys/m3front/src/misc/: Scanner.m3 Log message: initialize local: compiler is wrong but ok From jkrell at elego.de Tue Jun 1 21:12:38 2010 From: jkrell at elego.de (Jay Krell) Date: Tue, 1 Jun 2010 21:12:38 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100601191245.20AB82474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/06/01 21:12:38 Modified files: cm3/m3-ui/ui/src/vbt/: VBTClass.m3 Log message: initialize local: compiler is wrong but this is a classic case that compilers typically fail on From jkrell at elego.de Tue Jun 1 21:15:21 2010 From: jkrell at elego.de (Jay Krell) Date: Tue, 1 Jun 2010 21:15:21 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100601191522.F13A12474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/06/01 21:15:21 Modified files: cm3/m3-sys/m3tools/src/: M3Const.m3 Log message: initialize locals: compiler is wrong, but it would have to know that Err never returns in order to figure it out From jkrell at elego.de Tue Jun 1 21:43:03 2010 From: jkrell at elego.de (Jay Krell) Date: Tue, 1 Jun 2010 21:43:03 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100601194303.B89432474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/06/01 21:43:03 Modified files: cm3/m3-sys/cm3ide/src/misc/: BrowserDB.m3 Log message: fix use of uninitialized local that appears to occur if input file is malformed From jkrell at elego.de Tue Jun 1 21:47:28 2010 From: jkrell at elego.de (Jay Krell) Date: Tue, 1 Jun 2010 21:47:28 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100601194728.E93852474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/06/01 21:47:28 Modified files: cm3/m3-tools/m3tk/src/pl/: M3LTypeHash.m3 Log message: initialize local: I suspect compiler is wrong, but backend would have to know that the fault proc is noreturn, maybe that is doable? From jkrell at elego.de Tue Jun 1 21:48:32 2010 From: jkrell at elego.de (Jay Krell) Date: Tue, 1 Jun 2010 21:48:32 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100601194832.78F102474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/06/01 21:48:32 Modified files: cm3/m3-tools/m3tk/src/pl/: M3LTypeToText.m3 Log message: again, initialize local: I suspect compiler is wrong, but backend would have to know that the fault proc is noreturn, maybe that is doable? From jkrell at elego.de Tue Jun 1 22:13:01 2010 From: jkrell at elego.de (Jay Krell) Date: Tue, 1 Jun 2010 22:13:01 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100601201301.628802474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/06/01 22:13:01 Modified files: cm3/m3-sys/m3cc/src/: m3makefile Log message: clean also mpc and zlib directories, use the Makefile as the 'configure done' file From jkrell at elego.de Tue Jun 1 22:15:52 2010 From: jkrell at elego.de (Jay Krell) Date: Tue, 1 Jun 2010 22:15:52 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100601201552.484342474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/06/01 22:15:52 Modified files: cm3/m3-sys/m3cc/src/: m3makefile Log message: go back a version From jkrell at elego.de Tue Jun 1 22:21:53 2010 From: jkrell at elego.de (Jay Krell) Date: Tue, 1 Jun 2010 22:21:53 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100601202155.DC4412474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/06/01 22:21:53 Modified files: cm3/m3-sys/m3cc/gcc/gcc/: tree-ssa-sink.c Log message: fix uninitialized variable warning From hosking at cs.purdue.edu Tue Jun 1 23:13:35 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Tue, 1 Jun 2010 16:13:35 -0500 Subject: [M3commit] CVS Update: cm3 In-Reply-To: <20100601194832.78F102474003@birch.elegosoft.com> References: <20100601194832.78F102474003@birch.elegosoft.com> Message-ID: I don't understand what you are doing here. The compiler guarantees that all variables have a legal initial value. Sent from my iPhone On Jun 1, 2010, at 9:48 PM, jkrell at elego.de (Jay Krell) wrote: > CVSROOT: /usr/cvs > Changes by: jkrell at birch. 10/06/01 21:48:32 > > Modified files: > cm3/m3-tools/m3tk/src/pl/: M3LTypeToText.m3 > > Log message: > again, initialize local: I suspect compiler is wrong, but backend > would have to know that the fault proc is noreturn, maybe that is > doable? From hosking at cs.purdue.edu Tue Jun 1 23:29:20 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Tue, 1 Jun 2010 16:29:20 -0500 Subject: [M3commit] CVS Update: cm3 In-Reply-To: <20100601124200.8E42B2474003@birch.elegosoft.com> References: <20100601124200.8E42B2474003@birch.elegosoft.com> Message-ID: This is bogus. The M3 compiler guarantees all variables are initialized. Sent from my iPhone On Jun 1, 2010, at 2:42 PM, jkrell at elego.de (Jay Krell) wrote: > CVSROOT: /usr/cvs > Changes by: jkrell at birch. 10/06/01 14:42:00 > > Modified files: > cm3/m3-libs/m3core/src/convert/: Convert.m3 > > Log message: > initialize locals; I get warnings that some not quite all, are > used uninitialized if I remove the volatile/sideeffects on every > load/store in parse.c From jay.krell at cornell.edu Tue Jun 1 23:44:27 2010 From: jay.krell at cornell.edu (Jay K) Date: Tue, 1 Jun 2010 21:44:27 +0000 Subject: [M3commit] CVS Update: cm3 In-Reply-To: References: <20100601124200.8E42B2474003@birch.elegosoft.com>, Message-ID: Start removing the rampant use of volatile in the backend and these warnings show up. Volatile quashes the uninitialized checks in the backend. Is it really ok for an INTEGER to be uninitialized? I realize it contains an "integer" value, as all bit patterns are. Some of these really do seem like bugs. Some do not. I'll try making fault_proc noreturn, which should remove some of them. - Jay ---------------------------------------- > From: hosking at cs.purdue.edu > To: jkrell at elego.de > Date: Tue, 1 Jun 2010 16:29:20 -0500 > CC: m3commit at elegosoft.com > Subject: Re: [M3commit] CVS Update: cm3 > > This is bogus. The M3 compiler guarantees all variables are initialized. > > Sent from my iPhone > > On Jun 1, 2010, at 2:42 PM, jkrell at elego.de (Jay Krell) wrote: > >> CVSROOT: /usr/cvs >> Changes by: jkrell at birch. 10/06/01 14:42:00 >> >> Modified files: >> cm3/m3-libs/m3core/src/convert/: Convert.m3 >> >> Log message: >> initialize locals; I get warnings that some not quite all, are >> used uninitialized if I remove the volatile/sideeffects on every >> load/store in parse.c From hosking at cs.purdue.edu Wed Jun 2 02:04:00 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Tue, 1 Jun 2010 20:04:00 -0400 Subject: [M3commit] CVS Update: cm3 In-Reply-To: References: <20100601124200.8E42B2474003@birch.elegosoft.com>, Message-ID: <5458A114-F000-4A90-9998-FD7DF63E06C0@cs.purdue.edu> Sure, an INTEGER is a valid value whatever the bits. On 1 Jun 2010, at 17:44, Jay K wrote: > > Start removing the rampant use of volatile in the backend and these warnings show up. > > Volatile quashes the uninitialized checks in the backend. > > Is it really ok for an INTEGER to be uninitialized? I realize it contains an "integer" value, as all bit patterns are. > > Some of these really do seem like bugs. Some do not. > I'll try making fault_proc noreturn, which should remove some of them. > > > - Jay > > > > > ---------------------------------------- >> From: hosking at cs.purdue.edu >> To: jkrell at elego.de >> Date: Tue, 1 Jun 2010 16:29:20 -0500 >> CC: m3commit at elegosoft.com >> Subject: Re: [M3commit] CVS Update: cm3 >> >> This is bogus. The M3 compiler guarantees all variables are initialized. >> >> Sent from my iPhone >> >> On Jun 1, 2010, at 2:42 PM, jkrell at elego.de (Jay Krell) wrote: >> >>> CVSROOT: /usr/cvs >>> Changes by: jkrell at birch. 10/06/01 14:42:00 >>> >>> Modified files: >>> cm3/m3-libs/m3core/src/convert/: Convert.m3 >>> >>> Log message: >>> initialize locals; I get warnings that some not quite all, are >>> used uninitialized if I remove the volatile/sideeffects on every >>> load/store in parse.c From jay.krell at cornell.edu Wed Jun 2 02:10:02 2010 From: jay.krell at cornell.edu (Jay K) Date: Wed, 2 Jun 2010 00:10:02 +0000 Subject: [M3commit] CVS Update: cm3 In-Reply-To: <5458A114-F000-4A90-9998-FD7DF63E06C0@cs.purdue.edu> References: <20100601124200.8E42B2474003@birch.elegosoft.com>, , <5458A114-F000-4A90-9998-FD7DF63E06C0@cs.purdue.edu> Message-ID: ok, so in C: int F() { int i; return i; } should warn or not? Prevailing wisdom is definitely. Main known exception is code to generate random numbers. I believe this is how Debian broke key generation. Modula-3: PROCEDURE F(): INTEGER = VAR i: INTEGER; BEGIN RETURN i; END F; Should warn or not? Since this identical to the C, prevailing wisdom is definitely. They are, I guess, "safe", but most likely, incorrect. The compiler may have made "safety" guarantees, and they are significant, but safe is far from correct, and however smart the compiler can be to look for correctness issues, is also nice. (Friend of mine conjectured something like: Safety guarantees have people deluded. Software will still have plenty of bugs and be plenty difficult to get correct and require plenty of testing. Safety guarantees help, but they are only a small step toward actual correctness.) - Jay ---------------------------------------- > Subject: Re: [M3commit] CVS Update: cm3 > From: hosking at cs.purdue.edu > Date: Tue, 1 Jun 2010 20:04:00 -0400 > CC: jkrell at elego.de; m3commit at elegosoft.com > To: jay.krell at cornell.edu > > Sure, an INTEGER is a valid value whatever the bits. > > > On 1 Jun 2010, at 17:44, Jay K wrote: > >> >> Start removing the rampant use of volatile in the backend and these warnings show up. >> >> Volatile quashes the uninitialized checks in the backend. >> >> Is it really ok for an INTEGER to be uninitialized? I realize it contains an "integer" value, as all bit patterns are. >> >> Some of these really do seem like bugs. Some do not. >> I'll try making fault_proc noreturn, which should remove some of them. >> >> >> - Jay >> >> >> >> >> ---------------------------------------- >>> From: hosking at cs.purdue.edu >>> To: jkrell at elego.de >>> Date: Tue, 1 Jun 2010 16:29:20 -0500 >>> CC: m3commit at elegosoft.com >>> Subject: Re: [M3commit] CVS Update: cm3 >>> >>> This is bogus. The M3 compiler guarantees all variables are initialized. >>> >>> Sent from my iPhone >>> >>> On Jun 1, 2010, at 2:42 PM, jkrell at elego.de (Jay Krell) wrote: >>> >>>> CVSROOT: /usr/cvs >>>> Changes by: jkrell at birch. 10/06/01 14:42:00 >>>> >>>> Modified files: >>>> cm3/m3-libs/m3core/src/convert/: Convert.m3 >>>> >>>> Log message: >>>> initialize locals; I get warnings that some not quite all, are >>>> used uninitialized if I remove the volatile/sideeffects on every >>>> load/store in parse.c > From jkrell at elego.de Wed Jun 2 10:46:10 2010 From: jkrell at elego.de (Jay Krell) Date: Wed, 2 Jun 2010 10:46:10 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100602084610.BC8FE2474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/06/02 10:46:10 Modified files: cm3/m3-comm/tcp/src/POSIX/: TCP.m3 Log message: use socklen_t, not int socklen_t is chosen for convenience, not to match the underlying platform, therefore it is INTEGER or Word.T, and the underlying C wrappers copy back and forth From jkrell at elego.de Wed Jun 2 10:58:34 2010 From: jkrell at elego.de (Jay Krell) Date: Wed, 2 Jun 2010 10:58:34 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100602085835.0F7E12474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/06/02 10:58:34 Added files: cm3/m3-sys/cm3ide/: .cvsignore Log message: add .cvsignore From jkrell at elego.de Wed Jun 2 11:06:07 2010 From: jkrell at elego.de (Jay Krell) Date: Wed, 2 Jun 2010 11:06:07 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100602090607.22E0D2474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/06/02 11:06:07 Modified files: cm3/m3-sys/cm3ide/: .cvsignore Log message: add more From jkrell at elego.de Wed Jun 2 13:12:04 2010 From: jkrell at elego.de (Jay Krell) Date: Wed, 2 Jun 2010 13:12:04 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100602111204.108A92474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/06/02 13:12:04 Modified files: cm3/m3-sys/cminstall/src/config-no-install/: Unix.common Solaris.common Log message: just building cm3 for SOLgnu uses too many PIC slots for small PIC so go back to big PIC..I get the feeling ELF is kind of lame.. From jkrell at elego.de Wed Jun 2 15:27:06 2010 From: jkrell at elego.de (Jay Krell) Date: Wed, 2 Jun 2010 15:27:06 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100602132710.4A8F32474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/06/02 15:27:06 Modified files: cm3/m3-sys/m3cc/src/: m3makefile Log message: fill in a bunch of '-with-gnu-as -with-gnu-ld' for cross builds to e.g. avoid the warning that visibility isn't supported and is being ignored; use Makefile instead of .configure-done From jkrell at elego.de Wed Jun 2 15:50:29 2010 From: jkrell at elego.de (Jay Krell) Date: Wed, 2 Jun 2010 15:50:29 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100602135029.83AF42474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/06/02 15:50:29 Modified files: cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c Log message: in extract/insert_[m]n, trace m and n, under -y From jkrell at elego.de Wed Jun 2 15:59:40 2010 From: jkrell at elego.de (Jay Krell) Date: Wed, 2 Jun 2010 15:59:40 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100602135940.380512474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/06/02 15:59:40 Modified files: cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c Log message: a little reformating, mainly newlines before and after the tracing code From jkrell at elego.de Wed Jun 2 16:04:51 2010 From: jkrell at elego.de (Jay Krell) Date: Wed, 2 Jun 2010 16:04:51 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100602140451.6B6782474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/06/02 16:04:51 Modified files: cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c Log message: a tiny bit more reformat From hosking at cs.purdue.edu Wed Jun 2 16:38:59 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Wed, 2 Jun 2010 10:38:59 -0400 Subject: [M3commit] CVS Update: cm3 In-Reply-To: References: <20100601124200.8E42B2474003@birch.elegosoft.com>, , <5458A114-F000-4A90-9998-FD7DF63E06C0@cs.purdue.edu> Message-ID: C provides no guarantees about initialisation. Modula-3 requires that all variables be initialised (explicitly or by the compiler) as necessary to ensure they have a valid value for their type. So, basically, the warning you are getting from the gcc backend is not pertinent to Modula-3. On 1 Jun 2010, at 20:10, Jay K wrote: > > ok, so in C: > > int F() > { > int i; > return i; > } > > should warn or not? > Prevailing wisdom is definitely. > Main known exception is code to generate random numbers. > I believe this is how Debian broke key generation. > > > Modula-3: > > > PROCEDURE F(): INTEGER = > VAR i: INTEGER; > BEGIN > RETURN i; > END F; > > > Should warn or not? > Since this identical to the C, prevailing wisdom is definitely. No, because Modula-3 guarantees the value of i is valid for the type. It could be a random value of bits in this case because all bit combinations are valid for a Modula-3 INTEGER. If you tried something like a subrange [0..3] then you will see explicit initialisation with a value in the range [0..3]. > They are, I guess, "safe", but most likely, incorrect. > > > The compiler may have made "safety" guarantees, and they are significant, > but safe is far from correct, and however smart the compiler can be to look for correctness issues, is also nice. You are living in C land. > (Friend of mine conjectured something like: Safety guarantees have people deluded. Software will still have plenty of bugs and be plenty difficult to get correct and require plenty of testing. Safety guarantees help, but they are only a small step toward actual correctness.) > > > > - Jay > > > ---------------------------------------- >> Subject: Re: [M3commit] CVS Update: cm3 >> From: hosking at cs.purdue.edu >> Date: Tue, 1 Jun 2010 20:04:00 -0400 >> CC: jkrell at elego.de; m3commit at elegosoft.com >> To: jay.krell at cornell.edu >> >> Sure, an INTEGER is a valid value whatever the bits. >> >> >> On 1 Jun 2010, at 17:44, Jay K wrote: >> >>> >>> Start removing the rampant use of volatile in the backend and these warnings show up. >>> >>> Volatile quashes the uninitialized checks in the backend. >>> >>> Is it really ok for an INTEGER to be uninitialized? I realize it contains an "integer" value, as all bit patterns are. >>> >>> Some of these really do seem like bugs. Some do not. >>> I'll try making fault_proc noreturn, which should remove some of them. >>> >>> >>> - Jay >>> >>> >>> >>> >>> ---------------------------------------- >>>> From: hosking at cs.purdue.edu >>>> To: jkrell at elego.de >>>> Date: Tue, 1 Jun 2010 16:29:20 -0500 >>>> CC: m3commit at elegosoft.com >>>> Subject: Re: [M3commit] CVS Update: cm3 >>>> >>>> This is bogus. The M3 compiler guarantees all variables are initialized. >>>> >>>> Sent from my iPhone >>>> >>>> On Jun 1, 2010, at 2:42 PM, jkrell at elego.de (Jay Krell) wrote: >>>> >>>>> CVSROOT: /usr/cvs >>>>> Changes by: jkrell at birch. 10/06/01 14:42:00 >>>>> >>>>> Modified files: >>>>> cm3/m3-libs/m3core/src/convert/: Convert.m3 >>>>> >>>>> Log message: >>>>> initialize locals; I get warnings that some not quite all, are >>>>> used uninitialized if I remove the volatile/sideeffects on every >>>>> load/store in parse.c >> From jkrell at elego.de Wed Jun 2 18:35:40 2010 From: jkrell at elego.de (Jay Krell) Date: Wed, 2 Jun 2010 18:35:40 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100602163540.ABBFE2474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/06/02 18:35:40 Modified files: cm3/m3-sys/m3cc/src/: platforms.quake Log message: bump cross target=Solaris/sparc32 builds from 'solaris2' to 'solaris2.10'; native builds worked and this *seemed* to do it, still more to look into though (try 2.8, try removing volatils, try enabling 'gas weak', another difference I noticed between cross and native..this all goes to show, autoconf totally breaks down in the fact of cross builds, would be good to just not use it...oh well) From jkrell at elego.de Wed Jun 2 18:58:16 2010 From: jkrell at elego.de (Jay Krell) Date: Wed, 2 Jun 2010 18:58:16 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100602165816.E672F2474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/06/02 18:58:16 Modified files: cm3/scripts/python/: pylib.py Log message: print posixy 'export' instead of win32 'set' when on posix From jkrell at elego.de Wed Jun 2 18:59:55 2010 From: jkrell at elego.de (Jay Krell) Date: Wed, 2 Jun 2010 18:59:55 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100602165955.30FCD2474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/06/02 18:59:55 Modified files: cm3/scripts/python/: pylib.py Log message: print posixy 'unset' when clearing, I really don't understand the sh nuances though, I guess variable can be defined to be empty..but which shells do support unset? anyway, this is just printed for human to see approximation of internal actions, it's not actual executed From jkrell at elego.de Wed Jun 2 19:30:51 2010 From: jkrell at elego.de (Jay Krell) Date: Wed, 2 Jun 2010 19:30:51 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100602173051.643522474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/06/02 19:30:51 Modified files: cm3/m3-sys/m3cc/src/: m3makefile Log message: update Solaris and sparc64 non-auto-conf (add 'gas weak'), fix typo in comment From jkrell at elego.de Wed Jun 2 20:31:34 2010 From: jkrell at elego.de (Jay Krell) Date: Wed, 2 Jun 2010 20:31:34 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100602183134.99E862474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/06/02 20:31:34 Modified files: cm3/m3-sys/m3cc/gcc/gcc/config/: sol2.h cm3/m3-sys/m3cc/gcc/gcc/config/sparc/: sparc.h cm3/m3-sys/m3cc/gcc/gcc/m3cg/: m3gty43.h m3gty45.h parse.c Log message: significantly remove use of volatile Allowing the optimizer to actually do anything volatile remains on Solaris/sparc32 probably just need to experiment extensively volatile remains on all floating point loads, quite unfortunate for the scientific computing crowed.. volatile is added to more locals and temporaries within functions that call setjmp/vfork (setjmp is very common!?) volatile store after insert_mn, small lame hack, because otherwise we have a read before write a few optimizations are turned off, though I did solve the "unit at a time" problem, with TREE_USED or so I thought, but no...I had confused "ui" and "vbtkit" packages prototype marking fault_proc as noreturn but then I get a warning that it does return, even if I removed the return Provide and use m3_build_pointer_type that presently is pointless, but maybe will mean something in future There is a bit to turn off alias analysis. pre/fre still crashed. I didn't try vrp, it is the most painful to test when it goes wrong, because it successfully compiles everything. Mostly tested on AMD64_DARWIN. Needs broader coverage. Need to consider the warnings it causes. Need to get fault_proc marked noreturn first. Could use better for Solaris/sparc32, but machine is so slow experimentation is painful. From jkrell at elego.de Wed Jun 2 20:34:52 2010 From: jkrell at elego.de (Jay Krell) Date: Wed, 2 Jun 2010 20:34:52 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100602183452.399A22474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/06/02 20:34:52 Modified files: cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c Log message: fix accidental wierd bad form, might even help bring back the nested function that gets optimized out?? probably not but worth more trying or investigation.. From jay.krell at cornell.edu Wed Jun 2 20:35:51 2010 From: jay.krell at cornell.edu (Jay K) Date: Wed, 2 Jun 2010 18:35:51 +0000 Subject: [M3commit] CVS Update: cm3 In-Reply-To: <20100602183134.99E862474003@birch.elegosoft.com> References: <20100602183134.99E862474003@birch.elegosoft.com> Message-ID: Basically the same as before. ?- Jay ---------------------------------------- > Date: Wed, 2 Jun 2010 20:31:34 +0000 > To: m3commit at elegosoft.com > From: jkrell at elego.de > Subject: [M3commit] CVS Update: cm3 > > CVSROOT: /usr/cvs > Changes by: jkrell at birch. 10/06/02 20:31:34 > > Modified files: > cm3/m3-sys/m3cc/gcc/gcc/config/: sol2.h > cm3/m3-sys/m3cc/gcc/gcc/config/sparc/: sparc.h > cm3/m3-sys/m3cc/gcc/gcc/m3cg/: m3gty43.h m3gty45.h parse.c > > Log message: > significantly remove use of volatile > Allowing the optimizer to actually do anything > > volatile remains on Solaris/sparc32 > probably just need to experiment extensively > > volatile remains on all floating point loads, > quite unfortunate for the scientific computing crowed.. > > volatile is added to more locals and temporaries > within functions that call setjmp/vfork > (setjmp is very common!?) > > volatile store after insert_mn, small lame hack, > because otherwise we have a read before write > > a few optimizations are turned off, > though I did solve the "unit at a time" problem, with TREE_USED > or so I thought, but no...I had confused "ui" and "vbtkit" packages > > prototype marking fault_proc as noreturn > but then I get a warning that it does return, > even if I removed the return > > Provide and use m3_build_pointer_type that presently is pointless, > but maybe will mean something in future > There is a bit to turn off alias analysis. > pre/fre still crashed. I didn't try vrp, it is > the most painful to test when it goes wrong, because > it successfully compiles everything. > > Mostly tested on AMD64_DARWIN. > Needs broader coverage. > Need to consider the warnings it causes. > Need to get fault_proc marked noreturn first. > Could use better for Solaris/sparc32, but machine > is so slow experimentation is painful. > -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: volatile1.txt URL: From jkrell at elego.de Fri Jun 4 07:51:20 2010 From: jkrell at elego.de (Jay Krell) Date: Fri, 4 Jun 2010 7:51:20 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100604055121.8B2652474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/06/04 07:51:20 Modified files: cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c Log message: add m3_load_volatile, not currently used, but I get tired of putting it in to experiment, taking it out, repeat, etc. From jkrell at elego.de Fri Jun 4 17:41:45 2010 From: jkrell at elego.de (Jay Krell) Date: Fri, 4 Jun 2010 17:41:45 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100604154145.DC6CE2474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/06/04 17:41:45 Modified files: cm3/m3-sys/m3cc/gcc/gcc/m3cg/: Tag: release_branch_cm3_5_8 parse.c Log message: Port unfortunate fix from head, unless/until a better fix is found. The program: MODULE Main; PROCEDURE F1() = PROCEDURE NestedUnused1() = BEGIN END NestedUnused1; BEGIN IF FALSE THEN NestedUnused1(); END; END F1; BEGIN F1(); END Main. fails to link with: Undefined symbols: "_Main__F1__NestedUnused1.496", referenced from: _L_1 in Main.mo unless we do: flag_unit_at_a_time = 0; in parse.c From jkrell at elego.de Fri Jun 4 17:43:56 2010 From: jkrell at elego.de (Jay Krell) Date: Fri, 4 Jun 2010 17:43:56 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100604154356.5BFFE2474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/06/04 17:43:56 Modified files: cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c Log message: make comment match release regarding unit_at_a_time From jkrell at elego.de Fri Jun 4 18:15:09 2010 From: jkrell at elego.de (Jay Krell) Date: Fri, 4 Jun 2010 18:15:09 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100604161520.CB0D02474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/06/04 18:15:09 Modified files: cm3/m3-sys/m3cc/gcc/gcc/m3cg/: Tag: release_branch_cm3_5_8 parse.c Log message: turn off "pre" optimization, which crashes compiling m3-tools/cvsup/server/FSServer.m3 From jkrell at elego.de Fri Jun 4 18:18:09 2010 From: jkrell at elego.de (Jay Krell) Date: Fri, 4 Jun 2010 18:18:09 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100604161809.670FC2474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/06/04 18:18:09 Modified files: cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c Log message: always turn off "pre" (partial redundancy elimination), even when there is a stack walker, as it crashes on release Testing on Solaris/sparc32 would be appropriate though to see if it causes compiler crash there (or just doing cross build) From jkrell at elego.de Fri Jun 4 18:18:55 2010 From: jkrell at elego.de (Jay Krell) Date: Fri, 4 Jun 2010 18:18:55 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100604161855.1E6232474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/06/04 18:18:55 Modified files: cm3/m3-sys/m3cc/gcc/gcc/m3cg/: Tag: release_branch_cm3_5_8 parse.c Log message: adjust comment: spell out 'pre' means From hosking at cs.purdue.edu Fri Jun 4 18:36:24 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Fri, 4 Jun 2010 12:36:24 -0400 Subject: [M3commit] CVS Update: cm3 In-Reply-To: <20100604161520.CB0D02474003@birch.elegosoft.com> References: <20100604161520.CB0D02474003@birch.elegosoft.com> Message-ID: <06C73A71-2ECD-4EA2-BE48-52A573DCAFF3@cs.purdue.edu> Are you planning to go through and fix things so we can re-enable optimisations? I worked pretty hard to get everything to compile with -O2/-O3 when I worked on this with the current m3cg. Antony Hosking | Associate Professor | Computer Science | Purdue University 305 N. University Street | West Lafayette | IN 47907 | USA Office +1 765 494 6001 | Mobile +1 765 427 5484 On 4 Jun 2010, at 18:15, Jay Krell wrote: > CVSROOT: /usr/cvs > Changes by: jkrell at birch. 10/06/04 18:15:09 > > Modified files: > cm3/m3-sys/m3cc/gcc/gcc/m3cg/: Tag: release_branch_cm3_5_8 > parse.c > > Log message: > turn off "pre" optimization, which crashes compiling > m3-tools/cvsup/server/FSServer.m3 -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Fri Jun 4 19:16:35 2010 From: jay.krell at cornell.edu (Jay K) Date: Fri, 4 Jun 2010 17:16:35 +0000 Subject: [M3commit] CVS Update: cm3 In-Reply-To: <06C73A71-2ECD-4EA2-BE48-52A573DCAFF3@cs.purdue.edu> References: <20100604161520.CB0D02474003@birch.elegosoft.com>, <06C73A71-2ECD-4EA2-BE48-52A573DCAFF3@cs.purdue.edu> Message-ID: Unclear. I've also worked very hard at this and I believe it is in better shape than before. Granted, some steps forward, some backward. But I think much more forward. I'm using -O3. Sometimes what I do is in parse.c I explicitly enable everything but setting all the flags. We should perhaps do that anyway, esp. for optimizations that don't take long and don't hurt debugging. I suspect these two bugs were present back then, you just didn't hit them because: 1) we didn't have the unused nested function? 2) we didn't have cvsup? I disabled very very little. In trade, we don't throw around volatile all over the place. I think if you look into it, things were broken back then just the same. But we didn't have the code to tickle the bugs. I would like to get back "unit at a time". That seems a good optimization wrt inlining and it is being disabled for something that should be easily fixable some other way. vrp/fre/pre I don't know. It'll take quite some debugging to fix those. vrp produces bad code. fre and/or pre crash in the compiler. I'd also like to fix the volatile float problem. I've worked on that quite a bit too. I tried to make loophole always go through a volatile temporary for example. I tried making loophole go through a union. No luck yet. I guess I should see what: int a; float j; a = *(int*)&j; does in C. Notice that some of this is in the release branch. Where all I've done is test more code. I didn't remove the volatility on all load/store for example. - Jay ________________________________ > From: hosking at cs.purdue.edu > Date: Fri, 4 Jun 2010 12:36:24 -0400 > To: jkrell at elego.de > CC: m3commit at elegosoft.com > Subject: Re: [M3commit] CVS Update: cm3 > > > > Are you planning to go through and fix things so we can re-enable optimisations? > > I worked pretty hard to get everything to compile with -O2/-O3 when I worked on this with the current m3cg. > > > Antony Hosking | Associate Professor | Computer Science | Purdue University > 305 N. University Street | West Lafayette | IN 47907 | USA > Office +1 765 494 6001 | Mobile +1 765 427 5484 > > > > > > > On 4 Jun 2010, at 18:15, Jay Krell wrote: > > CVSROOT: /usr/cvs > Changes by: jkrell at birch. 10/06/04 18:15:09 > > Modified files: > cm3/m3-sys/m3cc/gcc/gcc/m3cg/: Tag: release_branch_cm3_5_8 > parse.c > > Log message: > turn off "pre" optimization, which crashes compiling > m3-tools/cvsup/server/FSServer.m3 > From hosking at cs.purdue.edu Fri Jun 4 19:58:59 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Fri, 4 Jun 2010 13:58:59 -0400 Subject: [M3commit] CVS Update: cm3 In-Reply-To: References: <20100604161520.CB0D02474003@birch.elegosoft.com>, <06C73A71-2ECD-4EA2-BE48-52A573DCAFF3@cs.purdue.edu> Message-ID: Cool. Thanks for putting the time in on this. On 4 Jun 2010, at 13:16, Jay K wrote: > > Unclear. I've also worked very hard at this and I believe it is in better shape than before. > Granted, some steps forward, some backward. But I think much more forward. > > I'm using -O3. > Sometimes what I do is in parse.c I explicitly enable everything but setting all the flags. > We should perhaps do that anyway, esp. for optimizations that don't take long and don't hurt debugging. > > > I suspect these two bugs were present back then, you just didn't hit them because: > 1) we didn't have the unused nested function? > 2) we didn't have cvsup? > > > I disabled very very little. > In trade, we don't throw around volatile all over the place. > > > I think if you look into it, things were broken back then just the same. > But we didn't have the code to tickle the bugs. > > > I would like to get back "unit at a time". That seems a good optimization wrt inlining and it is being disabled for something that should be easily fixable some other way. > > > vrp/fre/pre I don't know. > It'll take quite some debugging to fix those. > vrp produces bad code. > fre and/or pre crash in the compiler. > > > I'd also like to fix the volatile float problem. I've worked on that quite a bit too. > I tried to make loophole always go through a volatile temporary for example. > I tried making loophole go through a union. > No luck yet. > I guess I should see what: > int a; > float j; > a = *(int*)&j; > > > does in C. > > > Notice that some of this is in the release branch. Where all I've done is test more code. > I didn't remove the volatility on all load/store for example. > > > - Jay > > > ________________________________ >> From: hosking at cs.purdue.edu >> Date: Fri, 4 Jun 2010 12:36:24 -0400 >> To: jkrell at elego.de >> CC: m3commit at elegosoft.com >> Subject: Re: [M3commit] CVS Update: cm3 >> >> >> >> Are you planning to go through and fix things so we can re-enable optimisations? >> >> I worked pretty hard to get everything to compile with -O2/-O3 when I worked on this with the current m3cg. >> >> >> Antony Hosking | Associate Professor | Computer Science | Purdue University >> 305 N. University Street | West Lafayette | IN 47907 | USA >> Office +1 765 494 6001 | Mobile +1 765 427 5484 >> >> >> >> >> >> >> On 4 Jun 2010, at 18:15, Jay Krell wrote: >> >> CVSROOT: /usr/cvs >> Changes by: jkrell at birch. 10/06/04 18:15:09 >> >> Modified files: >> cm3/m3-sys/m3cc/gcc/gcc/m3cg/: Tag: release_branch_cm3_5_8 >> parse.c >> >> Log message: >> turn off "pre" optimization, which crashes compiling >> m3-tools/cvsup/server/FSServer.m3 >> From jkrell at elego.de Sat Jun 5 19:15:44 2010 From: jkrell at elego.de (Jay Krell) Date: Sat, 5 Jun 2010 19:15:44 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100605171544.E92B8CC37F@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/06/05 19:15:44 Modified files: cm3/m3-sys/m3middle/src/: Target.i3 Target.m3 Log message: restore ALPHA_OSF, but this time probably without stack walker just because I'm lazy, and resort the list again, it was only slightly unsorted From jkrell at elego.de Sat Jun 5 19:16:57 2010 From: jkrell at elego.de (Jay Krell) Date: Sat, 5 Jun 2010 19:16:57 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100605171657.98A79CC37F@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/06/05 19:16:57 Modified files: cm3/m3-libs/libm3/src/: platforms.quake Log message: restore ALPHA_OSF some day I will merge all this data into fewer places.. From jkrell at elego.de Sat Jun 5 19:19:26 2010 From: jkrell at elego.de (Jay Krell) Date: Sat, 5 Jun 2010 19:19:26 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100605171926.CF283CC37F@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/06/05 19:19:26 Added files: cm3/m3-libs/m3core/src/runtime/ALPHA_OSF/: m3makefile-old Removed files: cm3/m3-libs/m3core/src/runtime/ALPHA_OSF/: m3makefile Log message: rename m3makefile => m3makefile-old, so the common directory will notice no m3makefile and give us the portable files I'm omitting the stack walker, at least "for now", but realistically, probably the target-specific code will never come back, hopefully we'll have a somewhat portable stack walker using libunwind/libgcc/m3cc, at least on platforms that have libgcc, which is almost all From jkrell at elego.de Sat Jun 5 19:20:20 2010 From: jkrell at elego.de (Jay Krell) Date: Sat, 5 Jun 2010 19:20:20 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100605172020.BAA5C2474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/06/05 19:20:20 Modified files: cm3/m3-libs/m3core/src/unix/Common/: Usocket.c Log message: more information when there is an assertion failure From jkrell at elego.de Sat Jun 5 19:21:27 2010 From: jkrell at elego.de (Jay Krell) Date: Sat, 5 Jun 2010 19:21:27 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100605172127.E6C352474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/06/05 19:21:27 Modified files: cm3/m3-libs/m3core/src/: platforms.quake Log message: add ALPHA_OSF Really need to consolidate these lists.. From jkrell at elego.de Sat Jun 5 19:22:16 2010 From: jkrell at elego.de (Jay Krell) Date: Sat, 5 Jun 2010 19:22:16 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100605172216.74A412474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/06/05 19:22:16 Modified files: cm3/scripts/python/: pylib.py Log message: some suppoft for ALPHA_OSF, more needed here, soon later From jkrell at elego.de Sat Jun 5 19:24:37 2010 From: jkrell at elego.de (Jay Krell) Date: Sat, 5 Jun 2010 19:24:37 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100605172437.4C96E2474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/06/05 19:24:37 Modified files: cm3/m3-sys/m3cc/src/: platforms.quake Log message: upgrade from 'osf1' to 'osf5.1' From jkrell at elego.de Sat Jun 5 19:41:54 2010 From: jkrell at elego.de (Jay Krell) Date: Sat, 5 Jun 2010 19:41:54 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100605174155.0CAF4CC380@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/06/05 19:41:54 Modified files: cm3/m3-sys/m3cc/src/: m3makefile Log message: add -e flag on sh invocations; there is a problem here that when compilation/link fails, cm3 still succeeds, this doesn't seem to fix it, gr. From jkrell at elego.de Sat Jun 5 19:43:03 2010 From: jkrell at elego.de (Jay Krell) Date: Sat, 5 Jun 2010 19:43:03 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100605174303.54535CC380@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/06/05 19:43:03 Modified files: cm3/m3-libs/m3core/src/unix/: m3makefile Log message: add ALPHA_OSF From jkrell at elego.de Sat Jun 5 19:49:37 2010 From: jkrell at elego.de (Jay Krell) Date: Sat, 5 Jun 2010 19:49:37 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100605174938.717592474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/06/05 19:49:37 Modified files: cm3/m3-libs/libm3/src/os/POSIX/: m3makefile Log message: 'OSF' => 'Digital Unix', as we had for 'TRU64' From hosking at cs.purdue.edu Sat Jun 5 21:24:33 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sat, 5 Jun 2010 15:24:33 -0400 Subject: [M3commit] CVS Update: cm3 In-Reply-To: <20100605171544.E92B8CC37F@birch.elegosoft.com> References: <20100605171544.E92B8CC37F@birch.elegosoft.com> Message-ID: Please restore the stack walker. ALPHA_OSF is the one platform that does this properly! On 5 Jun 2010, at 19:15, Jay Krell wrote: > CVSROOT: /usr/cvs > Changes by: jkrell at birch. 10/06/05 19:15:44 > > Modified files: > cm3/m3-sys/m3middle/src/: Target.i3 Target.m3 > > Log message: > restore ALPHA_OSF, but this time probably without stack walker > just because I'm lazy, and resort the list again, it was only > slightly unsorted From jay.krell at cornell.edu Sat Jun 5 21:30:18 2010 From: jay.krell at cornell.edu (Jay K) Date: Sat, 5 Jun 2010 19:30:18 +0000 Subject: [M3commit] CVS Update: cm3 In-Reply-To: References: <20100605171544.E92B8CC37F@birch.elegosoft.com>, Message-ID: Solaris/sparc32 isn't enough to keep it alive? It's just that I have to restore the header cloning in m3core/src/unix. ?- Jay ---------------------------------------- > From: hosking at cs.purdue.edu > Date: Sat, 5 Jun 2010 15:24:33 -0400 > To: jkrell at elego.de > CC: m3commit at elegosoft.com > Subject: Re: [M3commit] CVS Update: cm3 > > Please restore the stack walker. ALPHA_OSF is the one platform that does this properly! > > > On 5 Jun 2010, at 19:15, Jay Krell wrote: > >> CVSROOT: /usr/cvs >> Changes by: jkrell at birch. 10/06/05 19:15:44 >> >> Modified files: >> cm3/m3-sys/m3middle/src/: Target.i3 Target.m3 >> >> Log message: >> restore ALPHA_OSF, but this time probably without stack walker >> just because I'm lazy, and resort the list again, it was only >> slightly unsorted > From hosking at cs.purdue.edu Sat Jun 5 23:44:35 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sat, 5 Jun 2010 17:44:35 -0400 Subject: [M3commit] CVS Update: cm3 In-Reply-To: References: <20100605171544.E92B8CC37F@birch.elegosoft.com>, Message-ID: <94F17EE8-B6FD-4B93-9FD4-4275AC0C64D0@cs.purdue.edu> I suppose. Though it does illustrate how the system can more properly support unwinding using a suitable API. On 5 Jun 2010, at 15:30, Jay K wrote: > > Solaris/sparc32 isn't enough to keep it alive? > It's just that I have to restore the header cloning in m3core/src/unix. > > - Jay > > ---------------------------------------- >> From: hosking at cs.purdue.edu >> Date: Sat, 5 Jun 2010 15:24:33 -0400 >> To: jkrell at elego.de >> CC: m3commit at elegosoft.com >> Subject: Re: [M3commit] CVS Update: cm3 >> >> Please restore the stack walker. ALPHA_OSF is the one platform that does this properly! >> >> >> On 5 Jun 2010, at 19:15, Jay Krell wrote: >> >>> CVSROOT: /usr/cvs >>> Changes by: jkrell at birch. 10/06/05 19:15:44 >>> >>> Modified files: >>> cm3/m3-sys/m3middle/src/: Target.i3 Target.m3 >>> >>> Log message: >>> restore ALPHA_OSF, but this time probably without stack walker >>> just because I'm lazy, and resort the list again, it was only >>> slightly unsorted >> > From jkrell at elego.de Sat Jun 5 20:47:41 2010 From: jkrell at elego.de (Jay Krell) Date: Sat, 5 Jun 2010 20:47:41 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100605184741.A2F562474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/06/05 20:47:41 Modified files: cm3/m3-libs/libm3/src/uid/POSIX/: MachineIDPosixC.c Log message: enable/test/fix the OSF1 case From jay.krell at cornell.edu Sun Jun 6 00:22:42 2010 From: jay.krell at cornell.edu (Jay K) Date: Sat, 5 Jun 2010 22:22:42 +0000 Subject: [M3commit] CVS Update: cm3 In-Reply-To: <94F17EE8-B6FD-4B93-9FD4-4275AC0C64D0@cs.purdue.edu> References: <20100605171544.E92B8CC37F@birch.elegosoft.com>, , , , <94F17EE8-B6FD-4B93-9FD4-4275AC0C64D0@cs.purdue.edu> Message-ID: I'll probably put it back. Esp. if it works the first time I try. ?- Jay ---------------------------------------- > From: hosking at cs.purdue.edu > Date: Sat, 5 Jun 2010 17:44:35 -0400 > To: jay.krell at cornell.edu > CC: m3commit at elegosoft.com > Subject: Re: [M3commit] CVS Update: cm3 > > I suppose. Though it does illustrate how the system can more properly support unwinding using a suitable API. > > On 5 Jun 2010, at 15:30, Jay K wrote: > >> >> Solaris/sparc32 isn't enough to keep it alive? >> It's just that I have to restore the header cloning in m3core/src/unix. >> >> - Jay >> >> ---------------------------------------- >>> From: hosking at cs.purdue.edu >>> Date: Sat, 5 Jun 2010 15:24:33 -0400 >>> To: jkrell at elego.de >>> CC: m3commit at elegosoft.com >>> Subject: Re: [M3commit] CVS Update: cm3 >>> >>> Please restore the stack walker. ALPHA_OSF is the one platform that does this properly! >>> >>> >>> On 5 Jun 2010, at 19:15, Jay Krell wrote: >>> >>>> CVSROOT: /usr/cvs >>>> Changes by: jkrell at birch. 10/06/05 19:15:44 >>>> >>>> Modified files: >>>> cm3/m3-sys/m3middle/src/: Target.i3 Target.m3 >>>> >>>> Log message: >>>> restore ALPHA_OSF, but this time probably without stack walker >>>> just because I'm lazy, and resort the list again, it was only >>>> slightly unsorted >>> >> > From jkrell at elego.de Sun Jun 6 02:12:14 2010 From: jkrell at elego.de (Jay Krell) Date: Sun, 6 Jun 2010 2:12:14 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100606001214.EA6BC2474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/06/06 02:12:14 Modified files: cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c Log message: change #ifdef GCC42 to #if GCC42 and if GCC42, but not real change, at this point From jkrell at elego.de Sun Jun 6 02:28:09 2010 From: jkrell at elego.de (Jay Krell) Date: Sun, 6 Jun 2010 2:28:09 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100606002809.E4C452474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/06/06 02:28:09 Modified files: cm3/m3-libs/m3core/src/runtime/POSIX/: test_signal.c Log message: make the test case even better, and even better; that is, first I made it print too 'close' numbers, the address of a function and the crashing address, but then, even better, jump to a hardcoded constant, we should crash at that place From jkrell at elego.de Sun Jun 6 02:42:29 2010 From: jkrell at elego.de (Jay Krell) Date: Sun, 6 Jun 2010 2:42:29 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100606004230.77EE12474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/06/06 02:42:29 Modified files: cm3/m3-libs/m3core/src/runtime/POSIX/: RTSignalC.c Log message: adapt for ALPHA_OSF The printed value is not the "controlled" value, and is only in the vague vicinity of another possible one -- the calling function..a little worrisome, might want to revisit, but this doesn't really have to work, it is just for printing where crashes occured and on some platforms we just return NULL. From jkrell at elego.de Sun Jun 6 02:50:16 2010 From: jkrell at elego.de (Jay Krell) Date: Sun, 6 Jun 2010 2:50:16 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100606005017.187962474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/06/06 02:50:16 Modified files: cm3/m3-libs/m3core/src/: m3core.h Log message: adaptions for ALPHA_OSF: - gcc doesn't support visibility here - socklen_t is only typedefed if you #define something, which at this point I'm not going to to, typedef socklen_t myself instead From jkrell at elego.de Sun Jun 6 03:21:54 2010 From: jkrell at elego.de (Jay Krell) Date: Sun, 6 Jun 2010 3:21:54 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100606012159.2A3762474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/06/06 03:21:54 Modified files: cm3/m3-sys/cminstall/src/config/: ALPHA_OSF Added files: cm3/m3-sys/cminstall/src/config-no-install/: ALPHA_OSF Log message: initial version in slightly new form and stub out old one like others already are From jkrell at elego.de Sun Jun 6 17:08:39 2010 From: jkrell at elego.de (Jay Krell) Date: Sun, 6 Jun 2010 17:08:39 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100606150839.1693E2474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/06/06 17:08:39 Modified files: cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c Log message: #ifdef HAVE_GAS_HIDDEN /* otherwise varasm.c warns: "visibility attribute not supported in this configuration; ignored" */ From jkrell at elego.de Sun Jun 6 17:25:42 2010 From: jkrell at elego.de (Jay Krell) Date: Sun, 6 Jun 2010 17:25:42 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100606152542.B7F312474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/06/06 17:25:42 Modified files: cm3/m3-libs/m3core/src/thread/Common/: ThreadInternal.c Log message: 'except' is keyword on OSF/1, use 'xcept' instead From jkrell at elego.de Sun Jun 6 17:49:28 2010 From: jkrell at elego.de (Jay Krell) Date: Sun, 6 Jun 2010 17:49:28 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100606154929.1D8882474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/06/06 17:49:28 Modified files: cm3/m3-libs/m3core/src/: m3core.h Log message: #ifdef __osf__ #ifndef _OSF_SOURCE #define _OSF_SOURCE #endif #ifndef _XOPEN_SOURCE #define _XOPEN_SOURCE 500 #endif #endif remove manual OSF/1 socklen_t I tried a few combinations. Without any #defines, socket.h omits stuff like recvfrom. If you just #define _XOPEN_SOURCE, then struct tm is missing the BSD members, which you can then handle with #ifdef, but I think socket.h was still missing stuff, I forgot. This works and is reasonable. From jkrell at elego.de Sun Jun 6 17:51:35 2010 From: jkrell at elego.de (Jay Krell) Date: Sun, 6 Jun 2010 17:51:35 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100606155135.B1C7D2474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/06/06 17:51:35 Modified files: cm3/m3-libs/m3core/src/time/POSIX/: DatePosixC.c Log message: add comment about OSF/1 From jkrell at elego.de Sun Jun 6 17:55:29 2010 From: jkrell at elego.de (Jay Krell) Date: Sun, 6 Jun 2010 17:55:29 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100606155529.DBA02CC37F@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/06/06 17:55:29 Modified files: cm3/scripts/python/: pylib.py Log message: pylib.py From jkrell at elego.de Sun Jun 6 18:00:54 2010 From: jkrell at elego.de (Jay Krell) Date: Sun, 6 Jun 2010 18:00:54 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100606160054.203E72474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/06/06 18:00:54 Modified files: cm3/scripts/python/: pylib.py Log message: failed to comment previous due to wrong cvs command line: adapt for ALPHA_OSF: use /usr/bin/cc -g, specifically -fPIC causes the error, like, "-g2 invalid hex number" or such, I think -fPIC means something else, and I think there is only one model on ALPHA_OSF anyway and it is PIC (consistent with Digital generally doing things better, and PIC being optional not a useful idea in general: proliferation of unnecessary and uncompatible options) switch Solaris to "big PIC" instead of "small PIC" Bad enough that there is PIC and non-PIC, add to the mix having to chose big PIC or small PIC! Ugh. Small PIC is more efficient but doesn't always work, and you don't know until you link, at And it doesn't work because of yet other poor ABI design, the general defaulting of everything to be external to the .so.. You get to go back and recompile some/all files.. There should be just one model and it should just work. The processor and the ABI should be designed together so that it is reasonably efficient. If there are, say, 32bit limits, then the linker should be able to fix things up, like, for tangential example, creation of branch islands. From jay.krell at cornell.edu Sun Jun 6 18:03:20 2010 From: jay.krell at cornell.edu (Jay K) Date: Sun, 6 Jun 2010 16:03:20 +0000 Subject: [M3commit] CVS Update: cm3 In-Reply-To: <20100606154929.1D8882474003@birch.elegosoft.com> References: <20100606154929.1D8882474003@birch.elegosoft.com> Message-ID: ?>> but I think socket.h was still missing stuff, I forgot. Some combinations resulted in missing u_char, u_short, u_int, u_long, and MachineIDPosixC.c not compiling. ?- Jay ---------------------------------------- > Date: Sun, 6 Jun 2010 17:49:28 +0000 > To: m3commit at elegosoft.com > From: jkrell at elego.de > Subject: [M3commit] CVS Update: cm3 > > CVSROOT: /usr/cvs > Changes by: jkrell at birch. 10/06/06 17:49:28 > > Modified files: > cm3/m3-libs/m3core/src/: m3core.h > > Log message: > #ifdef __osf__ > #ifndef _OSF_SOURCE > #define _OSF_SOURCE > #endif > #ifndef _XOPEN_SOURCE > #define _XOPEN_SOURCE 500 > #endif > #endif > > remove manual OSF/1 socklen_t > > I tried a few combinations. > Without any #defines, socket.h omits stuff like recvfrom. > If you just #define _XOPEN_SOURCE, then struct tm is missing the BSD members, > which you can then handle with #ifdef, but I think socket.h > was still missing stuff, I forgot. This works and is reasonable. > From jkrell at elego.de Sun Jun 6 22:46:15 2010 From: jkrell at elego.de (Jay Krell) Date: Sun, 6 Jun 2010 22:46:15 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100606204616.DD9152474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/06/06 22:46:15 Modified files: cm3/m3-libs/m3core/src/time/POSIX/: TimePosixC.c Log message: Three calls to ComputeGrainOnce take a long time to coincide on OSF/1 so only use two. This area seems a bit weak and in need of more attention. From jkrell at elego.de Sun Jun 6 23:07:48 2010 From: jkrell at elego.de (Jay Krell) Date: Sun, 6 Jun 2010 23:07:48 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100606210748.3F4372474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/06/06 23:07:48 Modified files: cm3/m3-libs/m3core/src/runtime/: m3makefile Log message: remove three newlines From jkrell at elego.de Sun Jun 6 23:09:52 2010 From: jkrell at elego.de (Jay Krell) Date: Sun, 6 Jun 2010 23:09:52 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100606210952.799952474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/06/06 23:09:52 Modified files: cm3/m3-libs/m3core/src/runtime/: m3makefile Log message: disable ALPHA_OSF stack walker here too 'for now' From jkrell at elego.de Sun Jun 6 23:11:32 2010 From: jkrell at elego.de (Jay Krell) Date: Sun, 6 Jun 2010 23:11:32 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100606211132.2E0742474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/06/06 23:11:32 Added files: cm3/m3-libs/m3core/src/C/ALPHA_OSF/: Csetjmp.i3 m3makefile Log message: restore ALPHA_OSF/Csetjmp.i3 From jkrell at elego.de Sun Jun 6 23:11:56 2010 From: jkrell at elego.de (Jay Krell) Date: Sun, 6 Jun 2010 23:11:56 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100606211156.EB9702474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/06/06 23:11:56 Modified files: cm3/m3-libs/m3core/src/: m3core.h cm3/m3-libs/m3core/src/time/POSIX/: DatePosixC.c TimePosixC.c cm3/m3-libs/m3core/src/unix/Common/: UtimeC.c Log message: use 64bit time_t (time64_t) on ALPHA_OSF From jay.krell at cornell.edu Sun Jun 6 23:13:01 2010 From: jay.krell at cornell.edu (Jay K) Date: Sun, 6 Jun 2010 21:13:01 +0000 Subject: [M3commit] CVS Update: cm3 In-Reply-To: <20100606211156.EB9702474003@birch.elegosoft.com> References: <20100606211156.EB9702474003@birch.elegosoft.com> Message-ID: ---------------------------------------- > Date: Sun, 6 Jun 2010 23:11:56 +0000 > To: m3commit at elegosoft.com > From: jkrell at elego.de > Subject: [M3commit] CVS Update: cm3 > > CVSROOT: /usr/cvs > Changes by: jkrell at birch. 10/06/06 23:11:56 > > Modified files: > cm3/m3-libs/m3core/src/: m3core.h > cm3/m3-libs/m3core/src/time/POSIX/: DatePosixC.c TimePosixC.c > cm3/m3-libs/m3core/src/unix/Common/: UtimeC.c > > Log message: > use 64bit time_t (time64_t) on ALPHA_OSF > -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: time64.txt URL: From jkrell at elego.de Sun Jun 6 23:57:15 2010 From: jkrell at elego.de (Jay Krell) Date: Sun, 6 Jun 2010 23:57:15 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100606215715.2CF862474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/06/06 23:57:15 Modified files: cm3/scripts/python/: pylib.py Log message: remove spaces in assembler command line too, share code to do so From jkrell at elego.de Mon Jun 7 00:15:19 2010 From: jkrell at elego.de (Jay Krell) Date: Mon, 7 Jun 2010 0:15:19 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100606221520.284C92474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/06/07 00:15:19 Modified files: cm3/scripts/python/: pylib.py Log message: fix From jkrell at elego.de Mon Jun 7 00:15:47 2010 From: jkrell at elego.de (Jay Krell) Date: Mon, 7 Jun 2010 0:15:47 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100606221547.E6E2F2474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/06/07 00:15:47 Modified files: cm3/scripts/python/: pylib.py Log message: comments From jkrell at elego.de Mon Jun 7 00:37:51 2010 From: jkrell at elego.de (Jay Krell) Date: Mon, 7 Jun 2010 0:37:51 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100606223752.4455A2474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/06/07 00:37:51 Modified files: cm3/scripts/python/: pylib.py Log message: put version and timestamp, in boot and distribution archive names From jkrell at elego.de Mon Jun 7 03:25:12 2010 From: jkrell at elego.de (Jay Krell) Date: Mon, 7 Jun 2010 3:25:12 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100607012512.BBD712474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/06/07 03:25:12 Modified files: cm3/scripts/python/: pylib.py Log message: support ALPHA_OSF host From jkrell at elego.de Wed Jun 9 19:20:18 2010 From: jkrell at elego.de (Jay Krell) Date: Wed, 9 Jun 2010 19:20:18 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100609172018.79E7F2474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/06/09 19:20:18 Modified files: cm3/m3-libs/m3core/src/unix/Common/: Uexec.c Log message: Only call WEXITSTATUS if WIFEXITED. Only call WTERMSIG if WIFSIGNALED. Otherwise we get -1 and a subrange violation on OSF/1, due to: /* evaluates to the low-order 8 bits of the child exit status */ #define WEXITSTATUS(x) (WIFEXITED(x) ? ((_W_INT(x) >> 8) & 0377) : -1) /* evaluates to a non-zero value if status returned for abnormal termination */ #define WIFSIGNALED(x) (_WSTATUS(x) != _WSTOPPED && _WSTATUS(x) != 0) /* evaluates to the number of the signal that caused the child to terminate */ #define WTERMSIG(x) (WIFSIGNALED(x) ? _WSTATUS(x) : -1) and a careful read of Posix validates this change. They don't say what WEXITSTATUS and WTERMSIG do if WIFEXITED, WIFSIGNALED are false, only if true. From jay.krell at cornell.edu Wed Jun 9 19:23:31 2010 From: jay.krell at cornell.edu (Jay K) Date: Wed, 9 Jun 2010 17:23:31 +0000 Subject: [M3commit] CVS Update: cm3 In-Reply-To: <20100609172018.79E7F2474003@birch.elegosoft.com> References: <20100609172018.79E7F2474003@birch.elegosoft.com> Message-ID: attached ALPHA_OSF can now (again) get at least as far as starting to build natively in m3-sys/m3cc..waiting.. (stack walker disabled, granted) ?- Jay ---------------------------------------- > Date: Wed, 9 Jun 2010 19:20:18 +0000 > To: m3commit at elegosoft.com > From: jkrell at elego.de > Subject: [M3commit] CVS Update: cm3 > > CVSROOT: /usr/cvs > Changes by: jkrell at birch. 10/06/09 19:20:18 > > Modified files: > cm3/m3-libs/m3core/src/unix/Common/: Uexec.c > > Log message: > Only call WEXITSTATUS if WIFEXITED. > Only call WTERMSIG if WIFSIGNALED. > Otherwise we get -1 and a subrange violation on OSF/1, due to: > /* evaluates to the low-order 8 bits of the child exit status */ > #define WEXITSTATUS(x) (WIFEXITED(x) ? ((_W_INT(x)>> 8) & 0377) : -1) > /* evaluates to a non-zero value if status returned for abnormal termination */ > #define WIFSIGNALED(x) (_WSTATUS(x) != _WSTOPPED && _WSTATUS(x) != 0) > /* evaluates to the number of the signal that caused the child to terminate */ > #define WTERMSIG(x) (WIFSIGNALED(x) ? _WSTATUS(x) : -1) > > and a careful read of Posix validates this change. > They don't say what WEXITSTATUS and WTERMSIG do if WIFEXITED, WIFSIGNALED > are false, only if true. > -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: wait.txt URL: From jkrell at elego.de Wed Jun 9 20:32:31 2010 From: jkrell at elego.de (Jay Krell) Date: Wed, 9 Jun 2010 20:32:31 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100609183231.2154F2474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/06/09 20:32:31 Modified files: cm3/m3-sys/cminstall/src/config-no-install/: ALPHA_OSF Log message: use -pthread (not -lpthread) and -lm on compiler/linker From jkrell at elego.de Wed Jun 9 20:33:38 2010 From: jkrell at elego.de (Jay Krell) Date: Wed, 9 Jun 2010 20:33:38 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100609183339.BF092CC37F@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/06/09 20:33:38 Modified files: cm3/m3-sys/m3cc/src/: m3makefile Log message: disable mips-tfile pending research, seems to work without it, though gcc does do something similar here From jkrell at elego.de Wed Jun 9 22:32:48 2010 From: jkrell at elego.de (Jay Krell) Date: Wed, 9 Jun 2010 22:32:48 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100609203248.77A802474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/06/09 22:32:48 Modified files: cm3/m3-libs/m3core/src/unix/Common/: UtimeC.c Log message: missed a use of time_t in doing the 64bit time change for OSF/1 From jkrell at elego.de Sat Jun 12 12:13:27 2010 From: jkrell at elego.de (Jay Krell) Date: Sat, 12 Jun 2010 12:13:27 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100612101327.946CB2474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/06/12 12:13:27 Modified files: cm3/m3-libs/m3core/src/: thread.quake Log message: er, let's use pthreads on ALPHA_OSF, not doing so was just an accident by me, though it ought it work either way From jkrell at elego.de Sat Jun 12 16:04:41 2010 From: jkrell at elego.de (Jay Krell) Date: Sat, 12 Jun 2010 16:04:41 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100612140441.870E82474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/06/12 16:04:41 Modified files: cm3/scripts/python/: pylib.py Log message: use -nocpp on Alpha/OSF assembler, as the preprocessor isn't needed and Mika broke his by accident; running /usr/lib/cmplrs/cc/as0 directly is also viable, it is documented on the man page From jkrell at elego.de Sat Jun 12 16:07:02 2010 From: jkrell at elego.de (Jay Krell) Date: Sat, 12 Jun 2010 16:07:02 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100612140702.4411CCC37F@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/06/12 16:07:02 Modified files: cm3/scripts/python/: pylib.py Log message: run /usr/lib/cmplrs/cc/as0 directly on Alpha/OSF From jkrell at elego.de Sat Jun 12 16:09:17 2010 From: jkrell at elego.de (Jay Krell) Date: Sat, 12 Jun 2010 16:09:17 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100612140920.6EFD42474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/06/12 16:09:17 Modified files: cm3/m3-sys/cminstall/src/config-no-install/: ALPHA_OSF Log message: disable stack walker here too (is that what broke the self-built cm3? run /usr/lib/cmplrs/cc/as0 directly (hey I would not have noticed the stack walker change here so fast Mika not broken /usr/bin/as!) From jkrell at elego.de Sat Jun 12 16:41:45 2010 From: jkrell at elego.de (Jay Krell) Date: Sat, 12 Jun 2010 16:41:45 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100612144145.2A2BFCC37F@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/06/12 16:41:45 Modified files: cm3/m3-libs/m3core/src/thread/PTHREAD/: ThreadPThreadC.c Log message: Pick SIG_SUSPEND for Alpha/OSF1/Tru64. Otherwise pthreads fails to compile for it, due to picking a non-constant. Here are some of the choices: /usr/include/signal.h: #define SIGUSR1 30 /* user defined signal 1 */ #define SIGUSR2 31 /* user defined signal 2 */ #define SIGRTMIN (sysconf(131)) #define SIGRTMAX (sysconf(132)) bash-4.1$ ./a.out 33 48 #include #include int main(int argc, char** argv) { printf("%ld %ld\n", (long)SIGRTMIN, (long)SIGRTMAX); return 0; } Using 33, 48 seems dangerous -- does it vary per machine/OS version? Diff here is: <#elif defined(SIGRTMAX) && !defined(__osf__) >#elif defined(SIGRTMAX) && !defined(__osf__) /* This might be a function call, in which case try _SIGRTMAX or initializing it somewhere. */ EXTERN_CONST int SIG_SUSPEND = SIGRTMAX; #elif defined(SIGUSR2) EXTERN_CONST int SIG_SUSPEND = SIGUSR2; so we end up using SIGUSR2, which is the same as on Solaris and maybe others. Note that OSF/1 and Darwin share a common base in Mach. And therefore "direct suspend" is probably a good easy idea here? mach_suspend/resume are in the headers, but I haven't found how to get the mach thread for a pthread, or the current mach thread, to compare see if they match. I'm more comfortable using the common code though actually. esp. since I haven't written any of this. From jkrell at elego.de Sat Jun 12 16:48:14 2010 From: jkrell at elego.de (Jay Krell) Date: Sat, 12 Jun 2010 16:48:14 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100612144815.068972474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/06/12 16:48:14 Modified files: cm3/m3-libs/m3core/src/thread/PTHREAD/: ThreadPThreadC.c Log message: make ThreadPThread__RestartThread and ThreadPThread__SuspendThread, as Tru64 cc complains that they weren't returning anything. Note we are playing just slightly fast/loose here. They are declared as returning BOOLEAN in the *.i3 files. But these versions just abort() and should never be called. You know, like, sometimes there is a "noreturn" marker on abort, sometimes not. That's why other compilers haven't been warning here. From jkrell at elego.de Sat Jun 12 16:52:24 2010 From: jkrell at elego.de (Jay Krell) Date: Sat, 12 Jun 2010 16:52:24 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100612145224.451942474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/06/12 16:52:24 Modified files: cm3/m3-sys/cminstall/src/config-no-install/: ALPHA_OSF Log message: hm, looks like as0 has to be followed by as1 Just use as -nocpp. Need -lrt for nanosleep, sem_*, now that using pthreads. From jkrell at elego.de Sat Jun 12 16:54:35 2010 From: jkrell at elego.de (Jay Krell) Date: Sat, 12 Jun 2010 16:54:35 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100612145436.0F4CCCC37F@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/06/12 16:54:35 Modified files: cm3/scripts/python/: pylib.py Log message: back to /usr/bin/as -nocpp on Alpha/OSF From jkrell at elego.de Sat Jun 12 16:57:41 2010 From: jkrell at elego.de (Jay Krell) Date: Sat, 12 Jun 2010 16:57:41 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100612145741.EFB202474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/06/12 16:57:41 Modified files: cm3/m3-libs/m3core/src/: thread.quake Log message: empty out platform list, the default of true is correct for all current platforms except OpenBSD, which are left in the list From jay.krell at cornell.edu Sat Jun 12 17:01:18 2010 From: jay.krell at cornell.edu (Jay K) Date: Sat, 12 Jun 2010 15:01:18 +0000 Subject: [M3commit] CVS Update: cm3 In-Reply-To: <20100612144815.068972474003@birch.elegosoft.com> References: <20100612144815.068972474003@birch.elegosoft.com> Message-ID: This was supposed to say, make them "return void". ?- Jay ---------------------------------------- > Date: Sat, 12 Jun 2010 16:48:14 +0000 > To: m3commit at elegosoft.com > From: jkrell at elego.de > Subject: [M3commit] CVS Update: cm3 > > CVSROOT: /usr/cvs > Changes by: jkrell at birch. 10/06/12 16:48:14 > > Modified files: > cm3/m3-libs/m3core/src/thread/PTHREAD/: ThreadPThreadC.c > > Log message: > make ThreadPThread__RestartThread and ThreadPThread__SuspendThread, > as Tru64 cc complains that they weren't returning anything. > > Note we are playing just slightly fast/loose here. > They are declared as returning BOOLEAN in the *.i3 files. > But these versions just abort() and should never be called. > > You know, like, sometimes there is a "noreturn" marker > on abort, sometimes not. That's why other compilers > haven't been warning here. > From jkrell at elego.de Sat Jun 12 17:22:44 2010 From: jkrell at elego.de (Jay Krell) Date: Sat, 12 Jun 2010 17:22:44 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100612152244.8115B2474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/06/12 17:22:44 Modified files: cm3/m3-libs/m3core/src/: thread.quake cm3/m3-libs/m3core/src/thread/: m3makefile Log message: user threads are now very portable and rarely require per-target work, so we can remove the list of targets that don't offer them (I was rarely doing the work for any new target) (still, NT/Cygwin don't have them, that's encoded differently) From jkrell at elego.de Sat Jun 12 17:25:49 2010 From: jkrell at elego.de (Jay Krell) Date: Sat, 12 Jun 2010 17:25:49 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100612152549.32A4D2474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/06/12 17:25:49 Modified files: cm3/m3-libs/m3core/src/thread/PTHREAD/: ThreadPThreadC.c Log message: remove errant line in the OSF change From jkrell at elego.de Sat Jun 12 22:26:03 2010 From: jkrell at elego.de (Jay Krell) Date: Sat, 12 Jun 2010 22:26:03 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100612202603.D87322474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/06/12 22:26:03 Modified files: cm3/www/uploaded-archives/: targets.txt Log message: add ALPHA_OSF From jkrell at elego.de Sun Jun 13 04:48:54 2010 From: jkrell at elego.de (Jay Krell) Date: Sun, 13 Jun 2010 4:48:54 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100613024858.5BDE02474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/06/13 04:48:54 Modified files: cm3/m3-sys/cminstall/src/config-no-install/: ALPHA_OSF Unix.common Log message: -mieee is needed to support denormal floating point, such as m3-libs/m3core/src/float/IEEE/LongReal.i3 MinPos: T = 4.9406564584124654D-324; (* The minimum positive value in T. *) MinPosNormal: T = 2.2250738585072014D-308; (* The minimum positive "normal" value in T; differs from MinPos only for implementations with denormalized numbers. *) Otherwise MinPos is NaN and multiplication with it here: m3-libs/arithmetic/src/basictypes/float/FloatTrans.ig Tiny = R.MinPos * FLOAT(1000.0, T); (* nearly 0.0 *) issues a SIGFPE, when R = LongReal. I also wonder if maybe MinPos should be adjusted to be normal or ALPHA_OSF should do so (i.e. not use generic IEEE directory, e.g.: VAX/LongReal.i3: MinPos: T = 2.93873587705571880D-39; VAX/LongReal.i3: MinPosNormal: T = MinPos; ) Probably best to be like all the other architectures though, even if it costs some perf. You know, some people like floating point to be really really the same across all architectures..witness Java, Java -strictfp, and the lack of any Java for VAX. see: http://gcc.gnu.org/onlinedocs/gcc-4.5.0/gcc/DEC-Alpha-Options.html#DEC-Alpha-Options A program like this demontrates it, I think it was, from memory: int main() { long a = 0x3E8; /* NaN */ double b = *(double*)&a; double c = b * 1000;; return 0; } or: int main() { double a = 4.9406564584124654e-324; double b = a * 1000; return 0; } We should probably hardcode this in parse.c for Alpha instead of relying on the config files. From jay.krell at cornell.edu Sun Jun 13 04:50:40 2010 From: jay.krell at cornell.edu (Jay K) Date: Sun, 13 Jun 2010 02:50:40 +0000 Subject: [M3commit] CVS Update: cm3 In-Reply-To: <20100613024858.5BDE02474003@birch.elegosoft.com> References: <20100613024858.5BDE02474003@birch.elegosoft.com> Message-ID: Index: ALPHA_OSF =================================================================== RCS file: /usr/cvs/cm3/m3-sys/cminstall/src/config-no-install/ALPHA_OSF,v retrieving revision 1.4 diff -u -r1.4 ALPHA_OSF --- ALPHA_OSF??? 12 Jun 2010 14:52:24 -0000??? 1.4 +++ ALPHA_OSF??? 13 Jun 2010 02:48:19 -0000 @@ -61,6 +61,7 @@ ? ?m3back_pic = "" % It seems that -fPIC isn't needed!? cool. ?m3back_m64 = "" % -m64 not allowed +m3back_mieee = "-mieee" ? ?%--------------------------------------------------------------- C compiler --- ?% "compile_c" is called to compile C source files.? Note that this function Index: Unix.common =================================================================== RCS file: /usr/cvs/cm3/m3-sys/cminstall/src/config-no-install/Unix.common,v retrieving revision 1.62 diff -u -r1.62 Unix.common --- Unix.common??? 2 Jun 2010 11:12:03 -0000??? 1.62 +++ Unix.common??? 13 Jun 2010 02:48:19 -0000 @@ -80,11 +80,16 @@ ?? m3back_m64 = {"32BITS" : "", "64BITS" : "-m64"}{WORD_SIZE} ?end ? +if not defined("m3back_mieee") +? m3back_mieee = "" +end + ?proc m3_backend(source, object, optimize, debug) is ???? local args = [ "-quiet", ??????????????????? "-fno-reorder-blocks", ??????????????????? m3back_unwind_table, ??????????????????? m3back_pic, +?????????????????? m3back_mieee, ??????????????????? m3back_m32, ??????????????????? m3back_m64 ] ???? if optimize ---------------------------------------- > Date: Sun, 13 Jun 2010 04:48:54 +0000 > To: m3commit at elegosoft.com > From: jkrell at elego.de > Subject: [M3commit] CVS Update: cm3 > > CVSROOT: /usr/cvs > Changes by: jkrell at birch. 10/06/13 04:48:54 > > Modified files: > cm3/m3-sys/cminstall/src/config-no-install/: ALPHA_OSF > Unix.common > > Log message: > -mieee is needed to support denormal floating point, such > as m3-libs/m3core/src/float/IEEE/LongReal.i3 > MinPos: T = 4.9406564584124654D-324; > (* The minimum positive value in T. *) > > MinPosNormal: T = 2.2250738585072014D-308; > (* The minimum positive "normal" value in T; differs from MinPos > only for implementations with denormalized numbers. *) > > Otherwise MinPos is NaN and multiplication with it here: > > m3-libs/arithmetic/src/basictypes/float/FloatTrans.ig > Tiny = R.MinPos * FLOAT(1000.0, T); (* nearly 0.0 *) > > issues a SIGFPE, when R = LongReal. > > I also wonder if maybe MinPos should be adjusted to be normal > or ALPHA_OSF should do so (i.e. not use generic IEEE directory, e.g.: > VAX/LongReal.i3: MinPos: T = 2.93873587705571880D-39; > VAX/LongReal.i3: MinPosNormal: T = MinPos; > ) > > Probably best to be like all the other architectures though, > even if it costs some perf. You know, some people like floating point > to be really really the same across all architectures..witness > Java, Java -strictfp, and the lack of any Java for VAX. > > see: > http://gcc.gnu.org/onlinedocs/gcc-4.5.0/gcc/DEC-Alpha-Options.html#DEC-Alpha-Options > > A program like this demontrates it, I think it was, from memory: > > int main() > { > long a = 0x3E8; /* NaN */ > double b = *(double*)&a; > double c = b * 1000;; > return 0; > } > > or: > int main() > { > double a = 4.9406564584124654e-324; > double b = a * 1000; > return 0; > } > > We should probably hardcode this in parse.c for Alpha instead > of relying on the config files. > From jkrell at elego.de Sun Jun 13 05:05:43 2010 From: jkrell at elego.de (Jay Krell) Date: Sun, 13 Jun 2010 5:05:43 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100613030543.6D3A92474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/06/13 05:05:43 Modified files: cm3/m3-ui/jvideo/src/POSIX/: m3makefile Log message: Comment out the decision to use target specific code and just use the generic version, it does compile, whereas the osf1/decunix versions no longer do. Is the target specific version faster or did these systems previously not handle the generic version? Either I doubt it matters much, out here in jvideo. From jkrell at elego.de Sun Jun 13 06:54:53 2010 From: jkrell at elego.de (Jay Krell) Date: Sun, 13 Jun 2010 6:54:53 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100613045453.2920E2474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/06/13 06:54:53 Modified files: cm3/m3-sys/cminstall/src/config-no-install/: ALPHA_OSF Log message: solitaire needs -ldnet_stub (dnet=decnet, and this was already there in the old config file that I wasn't immediately copying everything from) From jkrell at elego.de Sun Jun 13 07:09:58 2010 From: jkrell at elego.de (Jay Krell) Date: Sun, 13 Jun 2010 7:09:58 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100613050958.E63AA2474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/06/13 07:09:58 Modified files: cm3/scripts/python/: upload.sh Log message: also upload *.tar.xz and *.tgz files, and also translate jayk to jkrell From jkrell at elego.de Sun Jun 13 07:11:32 2010 From: jkrell at elego.de (Jay Krell) Date: Sun, 13 Jun 2010 7:11:32 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100613051132.B94122474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/06/13 07:11:32 Modified files: cm3/scripts/python/: upload.sh Log message: also chmod 644 From jkrell at elego.de Sun Jun 13 07:47:41 2010 From: jkrell at elego.de (Jay Krell) Date: Sun, 13 Jun 2010 7:47:41 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100613054742.4ABE2CC389@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/06/13 07:47:41 Modified files: cm3/m3-sys/cminstall/src/config-no-install/: ALPHA_OSF Log message: improve cc options: -g -readonly_strings, -lm doesn't belong here From jkrell at elego.de Sun Jun 13 23:30:55 2010 From: jkrell at elego.de (Jay Krell) Date: Sun, 13 Jun 2010 23:30:55 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100613213055.CBC4A2474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/06/13 23:30:55 Modified files: cm3/m3-sys/m3cc/src/: m3makefile Log message: some comment editing and fitting in 80 columns From jkrell at elego.de Mon Jun 14 06:42:45 2010 From: jkrell at elego.de (Jay Krell) Date: Mon, 14 Jun 2010 6:42:45 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100614044245.F1AE82474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/06/14 06:42:45 Modified files: cm3/m3-sys/m3cc/src/: m3makefile Log message: build and ship mips-tfile, though it doesn't yet work for me It gives errors, same as the mips-tfile that building gcc gives me, when used against Modula-3, mips-tfile does get used and work with C. From jkrell at elego.de Mon Jun 14 07:25:39 2010 From: jkrell at elego.de (Jay Krell) Date: Mon, 14 Jun 2010 7:25:39 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100614052539.F200E2474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/06/14 07:25:39 Modified files: cm3/m3-sys/cminstall/src/config-no-install/: ALPHA_OSF Unix.common Log message: put the .so files in lib and symlink back from pkg like other Posix platforms all now do I kind of think we might as well move the .a files too. move options to SYSTEM_CC (-ieee_with_no_inexact, -pthread) more refinement of compile/link flags: -error_unresolved -readonly_strings run assembler with the same flags that gcc does: -g -oldas -c -O0 (and -nocpp) Neither -oldas nor -c are documented. Always using -g seems wrong, never -g0 or -g3, etc., but it seems to be what gcc always does, I tried a few different -g and -O parameters (compiling C) run mips-tfile Changing the flags to the assembler appears to have helped significantly here. Previously it was always issuing errors. Reading osf.h and osf5.h confirm this. Debugging is a little better now in gdb. m3gdb crashes if I just set a breakpoint. From jkrell at elego.de Mon Jun 14 23:16:39 2010 From: jkrell at elego.de (Jay Krell) Date: Mon, 14 Jun 2010 23:16:39 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100614211639.89E06CC382@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/06/14 23:16:39 Modified files: cm3/m3-sys/cminstall/src/config-no-install/: ALPHA_OSF Log message: always compile C with -O3 -g3 -g in particular inhibits optimization path -rpath to cc instead of -Wl,-rpath use -B symbolic I verified, even though this isn't really documented for cc, it does work. It is documented for ld. -B foo means something else for cc, but it appears to recognize -B symbolic. If in doubt, use -Wl,-B,symbolic or maybe -WL,-B,symbolic instead cleanup comments about shared remove SYSTEM_LD -- just always use SYSTEM_CC From jkrell at elego.de Wed Jun 16 09:16:58 2010 From: jkrell at elego.de (Jay Krell) Date: Wed, 16 Jun 2010 9:16:58 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100616071658.769162474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/06/16 09:16:58 Added files: cm3/doc/notes/: todo.txt Log message: record backlog From jkrell at elego.de Wed Jun 16 09:21:23 2010 From: jkrell at elego.de (Jay Krell) Date: Wed, 16 Jun 2010 9:21:23 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100616072123.9F0F02474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/06/16 09:21:23 Modified files: cm3/doc/notes/: porting.txt Log message: some updates esp. about user threads being much more portable now From jkrell at elego.de Wed Jun 16 09:23:41 2010 From: jkrell at elego.de (Jay Krell) Date: Wed, 16 Jun 2010 9:23:41 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100616072343.AE3D52474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/06/16 09:23:41 Modified files: cm3/doc/notes/: todo.txt Log message: more backlog: reduce C header cloning From jkrell at elego.de Wed Jun 16 09:30:17 2010 From: jkrell at elego.de (Jay Krell) Date: Wed, 16 Jun 2010 9:30:17 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100616073017.AE2A22474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/06/16 09:30:17 Modified files: cm3/m3-libs/m3core/src/unix/Common/: Usocket.c Log message: ZeroMemory is *perhaps* preferable to = { 0 } because: 1) it portable zeros all of a union 2) gcc warns about missing initializers Though really = { 0 } is imho a great terse portable syntax that isn't worth warning about, unless there is a union with not the largest first. From rodney at elego.de Wed Jun 16 16:12:26 2010 From: rodney at elego.de (Rodney M. Bates) Date: Wed, 16 Jun 2010 16:12:26 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100616141226.3B7EA2474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: rodney at birch. 10/06/16 16:12:26 Modified files: cm3/m3-sys/m3front/src/misc/: Scanner.m3 Log message: Complete case-insensitivity for: 1) 'w'/'W' to denote wide character and wide text literals 2) 'x'/'X' as hex escape inside character and text literals From jkrell at elego.de Sat Jun 19 06:51:10 2010 From: jkrell at elego.de (Jay Krell) Date: Sat, 19 Jun 2010 6:51:10 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100619045111.2C3632474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/06/19 06:51:10 Added files: cm3/m3-sys/cminstall/src/config-no-install/: ARMEL_LINUX Log message: initial config file for ARMEL_LINUX (e=embedded, l=little endian) From jkrell at elego.de Sat Jun 19 06:56:33 2010 From: jkrell at elego.de (Jay Krell) Date: Sat, 19 Jun 2010 6:56:33 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100619045633.3B3992474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/06/19 06:56:33 Modified files: cm3/m3-sys/m3middle/src/: Target.i3 Target.m3 Log message: add ARMEL_LINUX with correct jmbuf size/align guessing about alignment "ARM" is an older ABI "ARME" is the usual modern ABI L for little endian From jkrell at elego.de Sat Jun 19 06:57:58 2010 From: jkrell at elego.de (Jay Krell) Date: Sat, 19 Jun 2010 6:57:58 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100619045758.0DF422474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/06/19 06:57:58 Modified files: cm3/m3-libs/m3core/src/: platforms.quake Log message: add ARMEL_LINUX (not to be confused with Android/Bionic which I suspect might be different.. From jkrell at elego.de Sat Jun 19 07:10:13 2010 From: jkrell at elego.de (Jay Krell) Date: Sat, 19 Jun 2010 7:10:13 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100619051013.EF8AB2474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/06/19 07:10:13 Modified files: cm3/m3-sys/m3cc/src/: platforms.quake Log message: add ARMEL_LINUX=arm-linux-gnueabi From jkrell at elego.de Sat Jun 19 07:26:00 2010 From: jkrell at elego.de (Jay Krell) Date: Sat, 19 Jun 2010 7:26:00 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100619052600.D57B52474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/06/19 07:26:00 Modified files: cm3/m3-sys/m3cc/src/: m3makefile Log message: Always specify -target. in native builds, always specify -build and -host. This should provide for more consistency, though is also a bit experimental and unorthodox. From jkrell at elego.de Sat Jun 19 07:35:19 2010 From: jkrell at elego.de (Jay Krell) Date: Sat, 19 Jun 2010 7:35:19 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100619053520.45FB42474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/06/19 07:35:19 Modified files: cm3/m3-sys/m3cc/src/: gnucc.common m3makefile Log message: always specify -build, -host, -target, for cross and native consistent but experimenta/unorthodox Usually people let config.guess do all the work for native and always for build. Default build to host, not target. From jkrell at elego.de Sat Jun 19 07:50:51 2010 From: jkrell at elego.de (Jay Krell) Date: Sat, 19 Jun 2010 7:50:51 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100619055052.45354CC38A@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/06/19 07:50:51 Added files: cm3/m3-libs/m3core/src/C/ARMEL_LINUX/: m3makefile Log message: add ARMEL_LINUX (really want to get rid of this stuff..compiler should inject it..) From jkrell at elego.de Sat Jun 19 10:26:59 2010 From: jkrell at elego.de (Jay Krell) Date: Sat, 19 Jun 2010 10:26:59 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100619082659.15A582474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/06/19 10:26:59 Modified files: cm3/m3-libs/m3core/src/Csupport/Common/: hand.c Log message: add m3_modL for ARM, it seems to need it From jkrell at elego.de Sat Jun 19 10:38:24 2010 From: jkrell at elego.de (Jay Krell) Date: Sat, 19 Jun 2010 10:38:24 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100619083824.740662474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/06/19 10:38:24 Modified files: cm3/m3-libs/m3core/src/Csupport/Common/: hand.c Log message: leave it called m3_div64 instead of m3_divL From jay.krell at cornell.edu Sat Jun 19 10:39:14 2010 From: jay.krell at cornell.edu (Jay K) Date: Sat, 19 Jun 2010 08:39:14 +0000 Subject: [M3commit] CVS Update: cm3 In-Reply-To: <20100619082659.15A582474003@birch.elegosoft.com> References: <20100619082659.15A582474003@birch.elegosoft.com> Message-ID: Meant to say add *back*. ?- Jay ---------------------------------------- > Date: Sat, 19 Jun 2010 10:26:59 +0000 > To: m3commit at elegosoft.com > From: jkrell at elego.de > Subject: [M3commit] CVS Update: cm3 > > CVSROOT: /usr/cvs > Changes by: jkrell at birch. 10/06/19 10:26:59 > > Modified files: > cm3/m3-libs/m3core/src/Csupport/Common/: hand.c > > Log message: > add m3_modL for ARM, it seems to need it > From jay.krell at cornell.edu Sat Jun 19 10:39:46 2010 From: jay.krell at cornell.edu (Jay K) Date: Sat, 19 Jun 2010 08:39:46 +0000 Subject: [M3commit] CVS Update: cm3 In-Reply-To: <20100619083824.740662474003@birch.elegosoft.com> References: <20100619083824.740662474003@birch.elegosoft.com> Message-ID: er. mod64/modL, not div64/divL ?- Jay ---------------------------------------- > Date: Sat, 19 Jun 2010 10:38:24 +0000 > To: m3commit at elegosoft.com > From: jkrell at elego.de > Subject: [M3commit] CVS Update: cm3 > > CVSROOT: /usr/cvs > Changes by: jkrell at birch. 10/06/19 10:38:24 > > Modified files: > cm3/m3-libs/m3core/src/Csupport/Common/: hand.c > > Log message: > leave it called m3_div64 instead of m3_divL > From jkrell at elego.de Sat Jun 19 10:56:58 2010 From: jkrell at elego.de (Jay Krell) Date: Sat, 19 Jun 2010 10:56:58 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100619085658.AA95C2474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/06/19 10:56:58 Modified files: cm3/m3-libs/libm3/src/: platforms.quake Log message: add ARMEL_LINUX From jkrell at elego.de Sat Jun 19 11:01:20 2010 From: jkrell at elego.de (Jay Krell) Date: Sat, 19 Jun 2010 11:01:20 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100619090120.255072474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/06/19 11:01:20 Modified files: cm3/m3-sys/cminstall/src/config-no-install/: ARMEL_LINUX Log message: -m32 not allowed here (probably needed for ARM_DARWIN too) From jkrell at elego.de Sat Jun 19 11:03:53 2010 From: jkrell at elego.de (Jay Krell) Date: Sat, 19 Jun 2010 11:03:53 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100619090353.B59352474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/06/19 11:03:53 Modified files: cm3/m3-sys/m3cc/gcc/gcc/config/arm/: arm.h cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c Log message: use a function call for 64bit mod on ARM, the backend crashes otherwise #if 0'ed out possibly slightly better code From jay.krell at cornell.edu Sat Jun 19 11:07:54 2010 From: jay.krell at cornell.edu (Jay K) Date: Sat, 19 Jun 2010 09:07:54 +0000 Subject: [M3commit] CVS Update: cm3 In-Reply-To: <20100619090353.B59352474003@birch.elegosoft.com> References: <20100619090353.B59352474003@birch.elegosoft.com> Message-ID: diff attached ---------------------------------------- > Date: Sat, 19 Jun 2010 11:03:53 +0000 > To: m3commit at elegosoft.com > From: jkrell at elego.de > Subject: [M3commit] CVS Update: cm3 > > CVSROOT: /usr/cvs > Changes by: jkrell at birch. 10/06/19 11:03:53 > > Modified files: > cm3/m3-sys/m3cc/gcc/gcc/config/arm/: arm.h > cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c > > Log message: > use a function call for 64bit mod on ARM, the backend crashes otherwise > #if 0'ed out possibly slightly better code > -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: arm1.txt URL: From jkrell at elego.de Sat Jun 19 11:17:03 2010 From: jkrell at elego.de (Jay Krell) Date: Sat, 19 Jun 2010 11:17:03 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100619091703.B6F752474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/06/19 11:17:03 Modified files: cm3/scripts/python/: pylib.py Log message: add ARMEL, change ?= to = avoid any confusion, edit the Makefile if it is wrong From jkrell at elego.de Sat Jun 19 11:20:25 2010 From: jkrell at elego.de (Jay Krell) Date: Sat, 19 Jun 2010 11:20:25 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100619092025.D39DD2474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/06/19 11:20:25 Modified files: cm3/scripts/python/: pylib.py Log message: add GnuPlatformPrefix{ARMEL_LINUX} = arm-linux-gnueabi-; aka use cross tools by default, since that is what I currently have From jkrell at elego.de Sat Jun 19 11:24:10 2010 From: jkrell at elego.de (Jay Krell) Date: Sat, 19 Jun 2010 11:24:10 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100619092410.0B9D62474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/06/19 11:24:10 Modified files: cm3/m3-libs/m3core/src/runtime/POSIX/: RTSignalC.c Log message: add Linux/arm (probably works for all Linux/arm variants) From jkrell at elego.de Sat Jun 19 11:26:47 2010 From: jkrell at elego.de (Jay Krell) Date: Sat, 19 Jun 2010 11:26:47 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100619092647.960352474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/06/19 11:26:47 Modified files: cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c Log message: oops From jkrell at elego.de Sat Jun 19 11:31:11 2010 From: jkrell at elego.de (Jay Krell) Date: Sat, 19 Jun 2010 11:31:11 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100619093111.4E77E2474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/06/19 11:31:11 Modified files: cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c Log message: #include tm_p.h to fix warning From jkrell at elego.de Sat Jun 19 11:37:20 2010 From: jkrell at elego.de (Jay Krell) Date: Sat, 19 Jun 2010 11:37:20 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100619093720.7B93B2474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/06/19 11:37:20 Modified files: cm3/scripts/python/: pylib.py Log message: no --32 for ARM assembler -- this bit is a bit of a mess and probably should just have a table for the remaining architectures that do accept --64 or --32 From jkrell at elego.de Sat Jun 19 11:38:45 2010 From: jkrell at elego.de (Jay Krell) Date: Sat, 19 Jun 2010 11:38:45 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100619093845.7F4022474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/06/19 11:38:45 Modified files: cm3/scripts/python/: pylib.py Log message: oops: remove double gnu platform prefix from linker From jkrell at elego.de Sat Jun 19 11:44:56 2010 From: jkrell at elego.de (Jay Krell) Date: Sat, 19 Jun 2010 11:44:56 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100619094456.4DA1E2474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/06/19 11:44:56 Modified files: cm3/m3-libs/m3core/src/atomic/: m3makefile Log message: remove all atomics on ARMEL_LINUX -- gcc 4.5 does implement them though.. From jkrell at elego.de Sat Jun 19 12:03:26 2010 From: jkrell at elego.de (Jay Krell) Date: Sat, 19 Jun 2010 12:03:26 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100619100326.372AB2474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/06/19 12:03:26 Modified files: cm3/m3-libs/m3core/src/unix/: m3makefile Log message: forgot to commit ARMEL_LINUX line here From jkrell at elego.de Sat Jun 19 12:04:03 2010 From: jkrell at elego.de (Jay Krell) Date: Sat, 19 Jun 2010 12:04:03 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100619100403.F09092474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/06/19 12:04:03 Modified files: cm3/m3-libs/m3core/src/runtime/common/: Compiler.tmpl Log message: forgot to commit ARMEL_LINUX line here From jkrell at elego.de Mon Jun 21 07:05:56 2010 From: jkrell at elego.de (Jay Krell) Date: Mon, 21 Jun 2010 7:05:56 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100621050557.39AB62474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/06/21 07:05:56 Modified files: cm3/m3-libs/m3core/src/Csupport/Common/: hand.c Log message: add back all four div/mod helpers for Posix, through rewritten to use unsigned arithmetic and not depend on silent signed wraparound Floor div/mod is a fairly target-specific and under used part of gcc and I am now nervous to depend upon it. Perhaps do more research though and trust it. From jkrell at elego.de Mon Jun 21 08:05:55 2010 From: jkrell at elego.de (Jay Krell) Date: Mon, 21 Jun 2010 8:05:55 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100621060555.B56FACC10F@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/06/21 08:05:55 Modified files: cm3/m3-sys/m3cc/gcc/gcc/config/: darwin-protos.h Log message: forward declare enum machine_mode to fix warningu From jkrell at elego.de Mon Jun 21 08:12:11 2010 From: jkrell at elego.de (Jay Krell) Date: Mon, 21 Jun 2010 8:12:11 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100621061211.6358C2474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/06/21 08:12:11 Modified files: cm3/m3-sys/m3cc/gcc/gcc/config/arm/: arm.h cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c Log message: put div/mod back to long standing and release form: almost always call a function, unless both parameters known to be positive or the type is unsigned Modula-3 very unfortunately defines div/mod differently than pretty much everyone else. Perhaps perhaps the language definition can be repaired. It turns out there are several reasonable definitions of div and mod. Modula-3 doesn't chose the obvious correct one and C doesn't chose the obvious incorrect one. We may yet be able to use the gcc support but it makes me nervous. It requires at least in a very minimal sense, for the frontend to support TImode (aka int128_t). See: http://gcc.gnu.org/ml/gcc/2010-06/msg00647.html (which is just from me, talking to myself..) From jkrell at elego.de Mon Jun 21 08:26:41 2010 From: jkrell at elego.de (Jay Krell) Date: Mon, 21 Jun 2010 8:26:41 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100621062641.C21EBCC10F@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/06/21 08:26:41 Modified files: cm3/m3-sys/m3cc/gcc-4.5/gcc/: final.c ira-conflicts.c loop-iv.c lower-subreg.c sel-sched-dump.c sel-sched.c Log message: Fix warnings about possible use of uninitialized locals by very clearly initializing them (as all locals should probably be). See bug: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44600 which again, is basically me talking to myself.. From jkrell at elego.de Mon Jun 21 09:57:13 2010 From: jkrell at elego.de (Jay Krell) Date: Mon, 21 Jun 2010 9:57:13 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100621075714.089CACC10F@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/06/21 09:57:13 Modified files: cm3/m3-sys/m3tests/src/: m3makefile Added files: cm3/m3-sys/m3tests/src/p2/p238/: Main.m3 m3makefile stdout.pgm Log message: add 'man vs. boy' aka nested procedures+recursion aka static chain test From jkrell at elego.de Mon Jun 21 10:11:27 2010 From: jkrell at elego.de (Jay Krell) Date: Mon, 21 Jun 2010 10:11:27 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100621081129.E9A21CC110@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/06/21 10:11:27 Added files: cm3/m3-sys/m3tests/src/p2/p238/: man-or-boy.c Log message: initial version from http://rosettacode.org/wiki/Man_or_boy_test that requires C9x and reuses identifiers in a confusing way From jkrell at elego.de Mon Jun 21 10:20:04 2010 From: jkrell at elego.de (Jay Krell) Date: Mon, 21 Jun 2010 10:20:04 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100621082004.B9F752474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/06/21 10:20:04 Modified files: cm3/m3-sys/m3tests/src/p2/p238/: man-or-boy.c Log message: before: type ARG and macro ARG; after: type ARG and macro MAKE_ARG; should be less confusing From jkrell at elego.de Mon Jun 21 10:31:47 2010 From: jkrell at elego.de (Jay Krell) Date: Mon, 21 Jun 2010 10:31:47 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100621083148.6D36F2474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/06/21 10:31:47 Modified files: cm3/m3-sys/m3tests/src/p2/p238/: man-or-boy.c Log message: remove C9x dependency From rodney_bates at lcwb.coop Tue Jun 22 03:07:04 2010 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Mon, 21 Jun 2010 20:07:04 -0500 Subject: [M3commit] CVS Update: cm3 In-Reply-To: <20100621061211.6358C2474003@birch.elegosoft.com> References: <20100621061211.6358C2474003@birch.elegosoft.com> Message-ID: <4C200CB8.7070809@lcwb.coop> Jay Krell wrote: > CVSROOT: /usr/cvs > Changes by: jkrell at birch. 10/06/21 08:12:11 > > Modified files: > cm3/m3-sys/m3cc/gcc/gcc/config/arm/: arm.h > cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c > > Log message: > put div/mod back to long standing and release form: > almost always call a function, unless both parameters known > to be positive or the type is unsigned > > Modula-3 very unfortunately defines div/mod differently than > pretty much everyone else. Perhaps perhaps the language > definition can be repaired. No, the language is correct. This is the mathematically correct definition of mod/div. We can be thankful that at least one language actually got it right. Moreover, the mathematicians knew what they were doing. Try some example coding with, e.g., arrays as circular buffers, using mod/div to increment/decrement your way around them. So many times in other languages, I have struggled with the frustration of having to write overcomplicated code to compensate for incorrect mod/div in other than the first quadrant. C is particularly exasperating, because it doesn't define them at all outside the first quadrant. It is implementor's option. This means these operators are entirely unusable for code that needs to be the least bit portable--even different compilers on the same machine. You always have to adjust your operands to first quadrant, do the operation, and then readjust. In Modula-3, you just do the operation. It turns out there are several > reasonable definitions of div and mod. Modula-3 doesn't > chose the obvious correct one and C doesn't chose the > obvious incorrect one. > > We may yet be able to use the gcc support but it makes me nervous. > It requires at least in a very minimal sense, for the frontend > to support TImode (aka int128_t). > > See: http://gcc.gnu.org/ml/gcc/2010-06/msg00647.html > (which is just from me, talking to myself..) > > From jay.krell at cornell.edu Tue Jun 22 03:32:23 2010 From: jay.krell at cornell.edu (Jay K) Date: Tue, 22 Jun 2010 01:32:23 +0000 Subject: [M3commit] CVS Update: cm3 In-Reply-To: <4C200CB8.7070809@lcwb.coop> References: <20100621061211.6358C2474003@birch.elegosoft.com>, <4C200CB8.7070809@lcwb.coop> Message-ID: I researched this -- searched the web, read Wikipedia, etc..I realize that calling "research" may be an exaggeration. There are approximately four reasonable definitions of div and mod for negative numbers. The most important thing is that div and mod are defined in terms of each other, in all variations, but that doesn't actually pin it down. There is round up (toward positive infinity), round down (toward negative infinity), toward 0 (truncation), there is Euclidean way. One might expect n mod m to be in the range [0,m), or perhaps the absolute value to be in [0,m), but I think Modula-3 doesn't make that so. It is surprising imho for mod to be outside that range. C89 left it undefined. So implementor could pick whatever was fastest/easiest. Fortran specified truncation. Nobody complained. C99 adopted Fortran's definition. So it is well defined now. Negative numbers are overused anyway. Everyone defines it the same for positive numbers, and that's generally sufficient anyway. As well C's ldiv function was explicitly defined to be truncating and therefore portable. (Notice that Modula-3's implementation was long broken for other reasons as well: It dependended on silent overflow, which gcc can warn about and break, and it didn't work for maximum/minimal numbers.) - Jay ---------------------------------------- > Date: Mon, 21 Jun 2010 20:07:04 -0500 > From: rodney_bates at lcwb.coop > To: m3commit at elegosoft.com > Subject: Re: [M3commit] CVS Update: cm3 > > > > Jay Krell wrote: >> CVSROOT: /usr/cvs >> Changes by: jkrell at birch. 10/06/21 08:12:11 >> >> Modified files: >> cm3/m3-sys/m3cc/gcc/gcc/config/arm/: arm.h >> cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c >> >> Log message: >> put div/mod back to long standing and release form: >> almost always call a function, unless both parameters known >> to be positive or the type is unsigned >> >> Modula-3 very unfortunately defines div/mod differently than >> pretty much everyone else. Perhaps perhaps the language >> definition can be repaired. > > No, the language is correct. This is the mathematically correct definition > of mod/div. We can be thankful that at least one language actually got it > right. Moreover, the mathematicians knew what they were doing. Try some > example coding with, e.g., arrays as circular buffers, using mod/div to > increment/decrement your way around them. So many times in other languages, > I have struggled with the frustration of having to write overcomplicated code > to compensate for incorrect mod/div in other than the first quadrant. > > C is particularly exasperating, because it doesn't define them at all outside > the first quadrant. It is implementor's option. This means these operators > are entirely unusable for code that needs to be the least bit portable--even > different compilers on the same machine. You always have to adjust your > operands to first quadrant, do the operation, and then readjust. > > In Modula-3, you just do the operation. > > It turns out there are several >> reasonable definitions of div and mod. Modula-3 doesn't >> chose the obvious correct one and C doesn't chose the >> obvious incorrect one. >> >> We may yet be able to use the gcc support but it makes me nervous. >> It requires at least in a very minimal sense, for the frontend >> to support TImode (aka int128_t). >> >> See: http://gcc.gnu.org/ml/gcc/2010-06/msg00647.html >> (which is just from me, talking to myself..) >> >> From hosking at cs.purdue.edu Tue Jun 22 03:35:52 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 21 Jun 2010 21:35:52 -0400 Subject: [M3commit] CVS Update: cm3 In-Reply-To: References: <20100621061211.6358C2474003@birch.elegosoft.com>, <4C200CB8.7070809@lcwb.coop> Message-ID: <0D1E563C-4499-404A-B4FB-9B27556581BA@cs.purdue.edu> On 21 Jun 2010, at 21:32, Jay K wrote: > > I researched this -- searched the web, read Wikipedia, etc..I realize that calling "research" may be an exaggeration. > There are approximately four reasonable definitions of div and mod for negative numbers. > > > The most important thing is that div and mod are defined in terms of each other, in all variations, but that doesn't actually pin it down. > > > There is round up (toward positive infinity), round down (toward negative infinity), toward 0 (truncation), there is Euclidean way. > > > One might expect n mod m to be in the range [0,m), or perhaps the absolute value to be in [0,m), but I think Modula-3 doesn't make that so. It is surprising imho for mod to be outside that range. > > > > C89 left it undefined. So implementor could pick whatever was fastest/easiest. > Fortran specified truncation. Nobody complained. > C99 adopted Fortran's definition. > So it is well defined now. > Negative numbers are overused anyway. > Everyone defines it the same for positive numbers, and that's generally sufficient anyway. But not if you can index arrays using negative indexes as in Modula-3. C, Fortran, etc. don't have this feature so they can get it wrong and nobody will notice. > > > > As well C's ldiv function was explicitly defined to be truncating and therefore portable. > > > > (Notice that Modula-3's implementation was long broken for other reasons as well: It dependended on silent overflow, which gcc can warn about and break, and it didn't work for maximum/minimal numbers.) > > > - Jay > > > ---------------------------------------- >> Date: Mon, 21 Jun 2010 20:07:04 -0500 >> From: rodney_bates at lcwb.coop >> To: m3commit at elegosoft.com >> Subject: Re: [M3commit] CVS Update: cm3 >> >> >> >> Jay Krell wrote: >>> CVSROOT: /usr/cvs >>> Changes by: jkrell at birch. 10/06/21 08:12:11 >>> >>> Modified files: >>> cm3/m3-sys/m3cc/gcc/gcc/config/arm/: arm.h >>> cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c >>> >>> Log message: >>> put div/mod back to long standing and release form: >>> almost always call a function, unless both parameters known >>> to be positive or the type is unsigned >>> >>> Modula-3 very unfortunately defines div/mod differently than >>> pretty much everyone else. Perhaps perhaps the language >>> definition can be repaired. >> >> No, the language is correct. This is the mathematically correct definition >> of mod/div. We can be thankful that at least one language actually got it >> right. Moreover, the mathematicians knew what they were doing. Try some >> example coding with, e.g., arrays as circular buffers, using mod/div to >> increment/decrement your way around them. So many times in other languages, >> I have struggled with the frustration of having to write overcomplicated code >> to compensate for incorrect mod/div in other than the first quadrant. >> >> C is particularly exasperating, because it doesn't define them at all outside >> the first quadrant. It is implementor's option. This means these operators >> are entirely unusable for code that needs to be the least bit portable--even >> different compilers on the same machine. You always have to adjust your >> operands to first quadrant, do the operation, and then readjust. >> >> In Modula-3, you just do the operation. >> >> It turns out there are several >>> reasonable definitions of div and mod. Modula-3 doesn't >>> chose the obvious correct one and C doesn't chose the >>> obvious incorrect one. >>> >>> We may yet be able to use the gcc support but it makes me nervous. >>> It requires at least in a very minimal sense, for the frontend >>> to support TImode (aka int128_t). >>> >>> See: http://gcc.gnu.org/ml/gcc/2010-06/msg00647.html >>> (which is just from me, talking to myself..) >>> >>> From jkrell at elego.de Thu Jun 24 11:26:47 2010 From: jkrell at elego.de (Jay Krell) Date: Thu, 24 Jun 2010 11:26:47 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100624092648.11DE3CC37E@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/06/24 11:26:47 Modified files: cm3/m3-sys/m3cc/gcc/gcc/: lower-subreg.c Log message: initialize local due to warning that it might be used uninitialized From jkrell at elego.de Thu Jun 24 11:37:44 2010 From: jkrell at elego.de (Jay Krell) Date: Thu, 24 Jun 2010 11:37:44 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100624093744.E715ECC37E@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/06/24 11:37:44 Modified files: cm3/m3-libs/m3core/src/Csupport/Common/: hand.c Log message: fix div/mod helpers to operate on INTEGER/WORD_T instead of INT32/UINT32; still there is a problem and I will next try using the release version of these From jkrell at elego.de Thu Jun 24 11:47:30 2010 From: jkrell at elego.de (Jay Krell) Date: Thu, 24 Jun 2010 11:47:30 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100624094730.BC58C2474006@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/06/24 11:47:30 Modified files: cm3/m3-libs/m3core/src/Csupport/Common/: hand.c Log message: go back to release form of div/mod helpers for now, though these don't fix the problem either (X.i3 could not find a legal alignment for the packed type From jkrell at elego.de Thu Jun 24 11:54:35 2010 From: jkrell at elego.de (Jay Krell) Date: Thu, 24 Jun 2010 11:54:35 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100624095436.142832474006@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/06/24 11:54:35 Added files: cm3/m3-libs/m3core/src/C/ARMEL_LINUX/: Csetjmp.i3 Log message: I forgot to commit this last weekend. From jkrell at elego.de Thu Jun 24 12:40:42 2010 From: jkrell at elego.de (Jay Krell) Date: Thu, 24 Jun 2010 12:40:42 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100624104042.AE6C4CC37E@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/06/24 12:40:42 Modified files: cm3/m3-ui/X11R4/src/Common/: X.i3 Log message: make lots of fields private to match current headers and DisplayStar = UNTRACED BRANDED REF ADDRESS to push all of Display toward private, like current headers From jkrell at elego.de Thu Jun 24 12:51:31 2010 From: jkrell at elego.de (Jay Krell) Date: Thu, 24 Jun 2010 12:51:31 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100624105133.4CC05CC110@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/06/24 12:51:31 Modified files: cm3/m3-ui/X11R4/src/Common/: X.i3 Log message: slightly further privatize display and gc (graphics context) in accordance with current headers Note that Xlib is I believe considered obsolete/deprecated/legacy and there is a new xcb X C binding. See http://en.wikipedia.org/wiki/XCB etc. (I'd have to research how widely xcb is distributed and used.) From jkrell at elego.de Thu Jun 24 13:05:49 2010 From: jkrell at elego.de (Jay Krell) Date: Thu, 24 Jun 2010 13:05:49 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100624110549.92EF52474006@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/06/24 13:05:49 Modified files: cm3/m3-libs/m3core/src/runtime/common/: RTType.m3 Log message: make it compatible with new ADR old ADR(T):ADDRESS new ADR(T):UNTRACED REF T From jay.krell at cornell.edu Thu Jun 24 13:06:14 2010 From: jay.krell at cornell.edu (Jay K) Date: Thu, 24 Jun 2010 11:06:14 +0000 Subject: [M3commit] CVS Update: cm3 In-Reply-To: <20100624110549.92EF52474006@birch.elegosoft.com> References: <20100624110549.92EF52474006@birch.elegosoft.com> Message-ID: =================================================================== RCS file: /usr/cvs/cm3/m3-libs/m3core/src/runtime/common/RTType.m3,v retrieving revision 1.10 diff -u -r1.10 RTType.m3 --- runtime/common/RTType.m3??? 3 Nov 2009 20:30:21 -0000??? 1.10 +++ runtime/common/RTType.m3??? 24 Jun 2010 11:02:06 -0000 @@ -455,8 +455,8 @@ ???? GenBuiltin (ADR (NULL_typecell),???? "NULL"); ???? GenBuiltin (ADR (REFANY_typecell),?? "REFANY"); ???? GenBuiltin (ADR (ADDRESS_typecell),? "ADDRESS"); -??? GenBuiltin (ADR (ROOT_typecell),???? "ROOT"); -??? GenBuiltin (ADR (UNROOT_typecell),?? "UNTRACED ROOT"); +??? GenBuiltin (ADR (ROOT_typecell.common), "ROOT"); +??? GenBuiltin (ADR (UNROOT_typecell.common), "UNTRACED ROOT"); ???? types.cnt := MAX (types.cnt, RT0.FirstUserTypecode); ?? END AssignBuiltinTypes; ---------------------------------------- > Date: Thu, 24 Jun 2010 13:05:49 +0000 > To: m3commit at elegosoft.com > From: jkrell at elego.de > Subject: [M3commit] CVS Update: cm3 > > CVSROOT: /usr/cvs > Changes by: jkrell at birch. 10/06/24 13:05:49 > > Modified files: > cm3/m3-libs/m3core/src/runtime/common/: RTType.m3 > > Log message: > make it compatible with new ADR > old ADR(T):ADDRESS > new ADR(T):UNTRACED REF T > From jkrell at elego.de Thu Jun 24 13:34:11 2010 From: jkrell at elego.de (Jay Krell) Date: Thu, 24 Jun 2010 13:34:11 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100624113412.671642474006@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/06/24 13:34:11 Modified files: cm3/m3-sys/m3tests/src/p0/p073/: Main.m3 stderr.pgm Log message: augment div/mod test (this might be redundant, but it is fast) From jkrell at elego.de Thu Jun 24 13:47:44 2010 From: jkrell at elego.de (Jay Krell) Date: Thu, 24 Jun 2010 13:47:44 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100624114744.E3B3ECC37E@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/06/24 13:47:44 Modified files: cm3/m3-sys/m3tests/src/p0/p073/: Main.m3 Log message: more checks From jkrell at elego.de Thu Jun 24 13:51:28 2010 From: jkrell at elego.de (Jay Krell) Date: Thu, 24 Jun 2010 13:51:28 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100624115128.BC147CC37E@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/06/24 13:51:28 Modified files: cm3/m3-sys/m3tests/src/p0/p073/: Main.m3 Log message: more/clearer checks From jkrell at elego.de Fri Jun 25 10:00:22 2010 From: jkrell at elego.de (Jay Krell) Date: Fri, 25 Jun 2010 10:00:22 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100625080022.8AB37CC110@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/06/25 10:00:22 Modified files: cm3/m3-libs/m3core/src/Csupport/Common/: hand.c Log message: back to versions that avoid overflowing signed numbers From jkrell at elego.de Fri Jun 25 11:02:40 2010 From: jkrell at elego.de (Jay Krell) Date: Fri, 25 Jun 2010 11:02:40 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100625090240.5467CCC37E@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/06/25 11:02:40 Modified files: cm3/m3-sys/m3cc/gcc/gcc/: tree-nested.c Log message: add an assert, based on a suspicion: STATIC_CHAIN_EXPR must always have a target_context, whatever that is From jkrell at elego.de Sat Jun 26 13:27:30 2010 From: jkrell at elego.de (Jay Krell) Date: Sat, 26 Jun 2010 13:27:30 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100626112730.0EADFCC37F@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/06/26 13:27:30 Modified files: cm3/m3-sys/m3cc/gcc-4.5/gcc/config/: darwin-protos.h Log message: ../../gcc-4.5/gcc/config/darwin-protos.h:57: warning: ???enum machine_mode??? declared inside parameter list ../../gcc-4.5/gcc/config/darwin-protos.h:57: warning: its scope is only this definition or declaration, which is probably not what you want throw in forward declaration: "enum machine_mode;" could be we are missing an #include From jkrell at elego.de Sat Jun 26 13:35:31 2010 From: jkrell at elego.de (Jay Krell) Date: Sat, 26 Jun 2010 13:35:31 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100626113531.50E39CC37F@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/06/26 13:35:31 Modified files: cm3/m3-sys/m3cc/gcc-4.5/gcc/: genpeep.c Log message: quash Darwin-specific warning from ranlib see http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44308 (which gcc maintainers won't fix) From jkrell at elego.de Sat Jun 26 13:36:43 2010 From: jkrell at elego.de (Jay Krell) Date: Sat, 26 Jun 2010 13:36:43 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100626113643.A47742474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/06/26 13:36:43 Modified files: cm3/m3-sys/m3cc/gcc-4.5/gcc/: genpeep.c Log message: move newlines around From jkrell at elego.de Sat Jun 26 13:37:27 2010 From: jkrell at elego.de (Jay Krell) Date: Sat, 26 Jun 2010 13:37:27 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100626113727.40CA82474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/06/26 13:37:27 Modified files: cm3/m3-sys/m3cc/gcc-4.5/gcc/: genpeep.c Log message: change symbol From jkrell at elego.de Sat Jun 26 15:08:46 2010 From: jkrell at elego.de (Jay Krell) Date: Sat, 26 Jun 2010 15:08:46 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100626130846.713D7CC37F@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/06/26 15:08:46 Modified files: cm3/m3-sys/m3middle/src/: TFloat.m3 Log message: LOOPHOLE so it works with -new_adr From jay.krell at cornell.edu Sat Jun 26 15:09:44 2010 From: jay.krell at cornell.edu (Jay K) Date: Sat, 26 Jun 2010 13:09:44 +0000 Subject: [M3commit] CVS Update: cm3 In-Reply-To: <20100626130846.713D7CC37F@birch.elegosoft.com> References: <20100626130846.713D7CC37F@birch.elegosoft.com> Message-ID: @@ -200,15 +200,15 @@ ? ???? CASE p OF ???? | Precision.Short => -??????? ptr := ADR (x1); +??????? ptr := LOOPHOLE(ADR (x1), Ptr); ???????? SUBARRAY (ptr^, 0, len) := SUBARRAY (buf, 0, len); ???????? f.fraction := FLOAT (x1, EXTENDED); ???? | Precision.Long => -??????? ptr := ADR (x2); +??????? ptr := LOOPHOLE(ADR (x2), Ptr); ???????? SUBARRAY (ptr^, 0, len) := SUBARRAY (buf, 0, len); ???????? f.fraction := FLOAT (x2, EXTENDED); ???? | Precision.Extended => -??????? ptr := ADR (x3); +??????? ptr := LOOPHOLE(ADR (x3), Ptr); ???????? SUBARRAY (ptr^, 0, len) := SUBARRAY (buf, 0, len); ???????? f.fraction := x3; ???? END; ---------------------------------------- > Date: Sat, 26 Jun 2010 15:08:46 +0000 > To: m3commit at elegosoft.com > From: jkrell at elego.de > Subject: [M3commit] CVS Update: cm3 > > CVSROOT: /usr/cvs > Changes by: jkrell at birch. 10/06/26 15:08:46 > > Modified files: > cm3/m3-sys/m3middle/src/: TFloat.m3 > > Log message: > LOOPHOLE so it works with -new_adr > From jkrell at elego.de Sat Jun 26 15:15:39 2010 From: jkrell at elego.de (Jay Krell) Date: Sat, 26 Jun 2010 15:15:39 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100626131539.E8FB62474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/06/26 15:15:39 Modified files: cm3/m3-comm/tcp/src/POSIX/: TCPPeer.m3 TCPExtras.m3 Log message: fix memory corrupting bug that I probably introduced, 64bit only, found by -new_adr int to socklen_t From jay.krell at cornell.edu Sat Jun 26 15:16:14 2010 From: jay.krell at cornell.edu (Jay K) Date: Sat, 26 Jun 2010 13:16:14 +0000 Subject: [M3commit] CVS Update: cm3 In-Reply-To: <20100626131539.E8FB62474003@birch.elegosoft.com> References: <20100626131539.E8FB62474003@birch.elegosoft.com> Message-ID: =================================================================== RCS file: /usr/cvs/cm3/m3-comm/tcp/src/POSIX/TCPExtras.m3,v retrieving revision 1.1.1.1 diff -u -r1.1.1.1 TCPExtras.m3 --- TCPExtras.m3??? 13 Jan 2001 14:15:14 -0000??? 1.1.1.1 +++ TCPExtras.m3??? 26 Jun 2010 13:13:58 -0000 @@ -9,7 +9,7 @@ ?PROCEDURE LocalEndpoint (conn: TCP.T): IP.Endpoint RAISES {IP.Error} = ?? VAR ???? addr : Uin.struct_sockaddr_in; -??? len? : Ctypes.int := BYTESIZE (addr); +??? len? : Usocket.socklen_t := BYTESIZE (addr); ???? ep?? : IP.Endpoint; ?? BEGIN ???? LOCK conn DO Index: TCPPeer.m3 =================================================================== RCS file: /usr/cvs/cm3/m3-comm/tcp/src/POSIX/TCPPeer.m3,v retrieving revision 1.1.1.1 diff -u -r1.1.1.1 TCPPeer.m3 --- TCPPeer.m3??? 13 Jan 2001 14:15:14 -0000??? 1.1.1.1 +++ TCPPeer.m3??? 26 Jun 2010 13:13:58 -0000 @@ -45,7 +45,7 @@ ? ?PROCEDURE GetSockAddr (channel: TCP.T;? VAR(*OUT*) addr: Addr) ?? RAISES {IP.Error} = -? VAR len: Ctypes.int := BYTESIZE (addr); +? VAR len: Usocket.socklen_t := BYTESIZE (addr); ?? BEGIN ???? LOCK channel DO ?????? IF (channel.closed) THEN IPError.Raise (TCP.Closed); END; ---------------------------------------- > Date: Sat, 26 Jun 2010 15:15:39 +0000 > To: m3commit at elegosoft.com > From: jkrell at elego.de > Subject: [M3commit] CVS Update: cm3 > > CVSROOT: /usr/cvs > Changes by: jkrell at birch. 10/06/26 15:15:39 > > Modified files: > cm3/m3-comm/tcp/src/POSIX/: TCPPeer.m3 TCPExtras.m3 > > Log message: > fix memory corrupting bug that I probably introduced, 64bit only, found by -new_adr int to socklen_t > From jkrell at elego.de Sat Jun 26 15:17:53 2010 From: jkrell at elego.de (Jay Krell) Date: Sat, 26 Jun 2010 15:17:53 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100626131753.F2D342474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/06/26 15:17:53 Modified files: cm3/m3-comm/udp/src/POSIX/: UDPPosix.m3 Log message: int to socklen_t so it works with -new_adr and doesn't corrupt memory on 64bit From jay.krell at cornell.edu Sat Jun 26 15:18:15 2010 From: jay.krell at cornell.edu (Jay K) Date: Sat, 26 Jun 2010 13:18:15 +0000 Subject: [M3commit] CVS Update: cm3 In-Reply-To: <20100626131753.F2D342474003@birch.elegosoft.com> References: <20100626131753.F2D342474003@birch.elegosoft.com> Message-ID: Index: src/POSIX/UDPPosix.m3 =================================================================== RCS file: /usr/cvs/cm3/m3-comm/udp/src/POSIX/UDPPosix.m3,v retrieving revision 1.3 diff -u -r1.3 UDPPosix.m3 --- src/POSIX/UDPPosix.m3??? 14 Apr 2003 20:18:44 -0000??? 1.3 +++ src/POSIX/UDPPosix.m3??? 26 Jun 2010 13:17:16 -0000 @@ -122,7 +122,7 @@ ???? waitRes: SchedulerPosix.WaitResult; ???? numRead: INTEGER; ???? sockaddr: Uin.struct_sockaddr_in; -??? saSize: Ctypes.int; +??? saSize: Usocket.socklen_t; ?? BEGIN ???? <* ASSERT self.open *> ???? waitRes := SchedulerPosix.IOAlertWait(self.fileno, TRUE, timeout); ---------------------------------------- > Date: Sat, 26 Jun 2010 15:17:53 +0000 > To: m3commit at elegosoft.com > From: jkrell at elego.de > Subject: [M3commit] CVS Update: cm3 > > CVSROOT: /usr/cvs > Changes by: jkrell at birch. 10/06/26 15:17:53 > > Modified files: > cm3/m3-comm/udp/src/POSIX/: UDPPosix.m3 > > Log message: > int to socklen_t so it works with -new_adr and doesn't corrupt memory on 64bit > From jkrell at elego.de Sat Jun 26 15:19:58 2010 From: jkrell at elego.de (Jay Krell) Date: Sat, 26 Jun 2010 15:19:58 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100626131958.7C94A2474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/06/26 15:19:58 Modified files: cm3/m3-libs/sysutils/src/POSIX/: SystemPosix.m3 Log message: LOOPHOLE to char_star so it works with -new_adr From jkrell at elego.de Sat Jun 26 15:25:58 2010 From: jkrell at elego.de (Jay Krell) Date: Sat, 26 Jun 2010 15:25:58 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100626132558.E05AC2474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/06/26 15:25:58 Modified files: cm3/m3-libs/libm3/src/os/POSIX/: SocketPosix.m3 Log message: int/INTEGER => socklen_t LOOPHOLE to char_star so it works with -new_adr and doesn't corrupt stack From jay.krell at cornell.edu Sat Jun 26 15:20:16 2010 From: jay.krell at cornell.edu (Jay K) Date: Sat, 26 Jun 2010 13:20:16 +0000 Subject: [M3commit] CVS Update: cm3 In-Reply-To: <20100626131958.7C94A2474003@birch.elegosoft.com> References: <20100626131958.7C94A2474003@birch.elegosoft.com> Message-ID: Index: src/POSIX/SystemPosix.m3 =================================================================== RCS file: /usr/cvs/cm3/m3-libs/sysutils/src/POSIX/SystemPosix.m3,v retrieving revision 1.16 diff -u -r1.16 SystemPosix.m3 --- src/POSIX/SystemPosix.m3??? 10 Mar 2010 10:45:44 -0000??? 1.16 +++ src/POSIX/SystemPosix.m3??? 26 Jun 2010 13:19:32 -0000 @@ -34,7 +34,7 @@ ???? buf : ARRAY [0..1024] OF CHAR; ???? len := 1024; ?? BEGIN -??? IF gethostname(ADR(buf), len) = 0 THEN +??? IF gethostname(LOOPHOLE(ADR(buf), Ctypes.char_star), len) = 0 THEN ?????? buf[1024] := '\000'; ?????? len := 0; ?????? WHILE len < 1024 AND buf[len] # '\000' DO ---------------------------------------- > Date: Sat, 26 Jun 2010 15:19:58 +0000 > To: m3commit at elegosoft.com > From: jkrell at elego.de > Subject: [M3commit] CVS Update: cm3 > > CVSROOT: /usr/cvs > Changes by: jkrell at birch. 10/06/26 15:19:58 > > Modified files: > cm3/m3-libs/sysutils/src/POSIX/: SystemPosix.m3 > > Log message: > LOOPHOLE to char_star so it works with -new_adr > From jkrell at elego.de Sat Jun 26 15:29:46 2010 From: jkrell at elego.de (Jay Krell) Date: Sat, 26 Jun 2010 15:29:46 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100626132946.AAB282474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/06/26 15:29:46 Modified files: cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c Log message: fix minor typo in trace output From jay.krell at cornell.edu Sat Jun 26 15:28:04 2010 From: jay.krell at cornell.edu (Jay K) Date: Sat, 26 Jun 2010 13:28:04 +0000 Subject: [M3commit] CVS Update: cm3 In-Reply-To: <20100626132558.E05AC2474003@birch.elegosoft.com> References: <20100626132558.E05AC2474003@birch.elegosoft.com> Message-ID: oops I deleted the diff, but simple enough ---------------------------------------- > Date: Sat, 26 Jun 2010 15:25:58 +0000 > To: m3commit at elegosoft.com > From: jkrell at elego.de > Subject: [M3commit] CVS Update: cm3 > > CVSROOT: /usr/cvs > Changes by: jkrell at birch. 10/06/26 15:25:58 > > Modified files: > cm3/m3-libs/libm3/src/os/POSIX/: SocketPosix.m3 > > Log message: > int/INTEGER => socklen_t > LOOPHOLE to char_star > so it works with -new_adr and doesn't corrupt stack > From jkrell at elego.de Sun Jun 27 10:52:53 2010 From: jkrell at elego.de (Jay Krell) Date: Sun, 27 Jun 2010 10:52:53 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100627085253.CA57B2474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/06/27 10:52:53 Modified files: cm3/m3-sys/m3cc/src/: gnucc.common Log message: allow -DO0 to turn off optimizations From jkrell at elego.de Sun Jun 27 12:09:53 2010 From: jkrell at elego.de (Jay Krell) Date: Sun, 27 Jun 2010 12:09:53 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100627100953.835322474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/06/27 12:09:53 Modified files: cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c Log message: #ifdef GCC45 to #if GCC45, #ifndef to #if ! From jkrell at elego.de Sun Jun 27 12:19:51 2010 From: jkrell at elego.de (Jay Krell) Date: Sun, 27 Jun 2010 12:19:51 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100627101951.3F9D32474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/06/27 12:19:51 Modified files: cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c Log message: change some #if GCC45 to if (GCC45), where both arms should compile with either code base From jkrell at elego.de Sun Jun 27 12:21:24 2010 From: jkrell at elego.de (Jay Krell) Date: Sun, 27 Jun 2010 12:21:24 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100627102124.F3B4ACC10F@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/06/27 12:21:24 Modified files: cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c Log message: remove initial #define GCC45 0 From jkrell at elego.de Sun Jun 27 12:30:48 2010 From: jkrell at elego.de (Jay Krell) Date: Sun, 27 Jun 2010 12:30:48 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100627103048.E1C072474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/06/27 12:30:48 Modified files: cm3/m3-sys/m3cc/src/: m3makefile cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c Log message: a little more #ifdef to #if, GCC_APPLE and GCC42 (which really mean the same thing) From jkrell at elego.de Sun Jun 27 12:58:39 2010 From: jkrell at elego.de (Jay Krell) Date: Sun, 27 Jun 2010 12:58:39 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100627105839.2F8802474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/06/27 12:58:39 Modified files: cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c Log message: fold gcc45 and non-gcc45 code mostly via: enum tree_code plus = (GCC45 ? POINTER_PLUS_EXPR : PLUS_EXPR); From jkrell at elego.de Sun Jun 27 13:36:38 2010 From: jkrell at elego.de (Jay Krell) Date: Sun, 27 Jun 2010 13:36:38 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100627113638.913772474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/06/27 13:36:38 Modified files: cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c Log message: in m3cg_set_label, use a loop to put the asm("") before and after the label, instead of duplicating the code also in m3cg_set_label, a possible gcc 4.5 fix, use DECL_NONLOCAL(l) = true; instead of manipulating nonlocal_goto_handler_labels, which doesn't work (it crashes) From jkrell at elego.de Sun Jun 27 13:56:52 2010 From: jkrell at elego.de (Jay Krell) Date: Sun, 27 Jun 2010 13:56:52 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100627115653.035C92474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/06/27 13:56:52 Modified files: cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c Log message: fix m3cg_set_label change From jkrell at elego.de Sun Jun 27 15:17:37 2010 From: jkrell at elego.de (Jay Krell) Date: Sun, 27 Jun 2010 15:17:37 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100627131737.AE1812474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/06/27 15:17:37 Modified files: cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c Log message: reduce diff in gcc 4.3 m3cg_set_label From jkrell at elego.de Sun Jun 27 15:19:43 2010 From: jkrell at elego.de (Jay Krell) Date: Sun, 27 Jun 2010 15:19:43 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100627131943.1D4D42474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/06/27 15:19:43 Modified files: cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c Log message: fix type to fix warning From jkrell at elego.de Sun Jun 27 15:23:14 2010 From: jkrell at elego.de (Jay Krell) Date: Sun, 27 Jun 2010 15:23:14 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100627132314.9DE152474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/06/27 15:23:14 Modified files: cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c Log message: provide IS_INTEGER_TYPE_TREE and IS_WORD_TYPE_TREE macros even for gcc <4.5; forward declare enum machine_mode to quash warning on other targets From jkrell at elego.de Sun Jun 27 15:24:10 2010 From: jkrell at elego.de (Jay Krell) Date: Sun, 27 Jun 2010 15:24:10 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100627132410.BBD782474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/06/27 15:24:10 Modified files: cm3/m3-sys/m3cc/gcc/gcc/config/: darwin-protos.h Log message: remove the enum machine_mode forward declare from here, now that we have in parse.c From jkrell at elego.de Sun Jun 27 16:09:33 2010 From: jkrell at elego.de (Jay Krell) Date: Sun, 27 Jun 2010 16:09:33 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100627140933.123E12474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/06/27 16:09:33 Modified files: cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c Log message: fix 4.5 compilation regarding x_nonlocal_goto_handler_labels From jkrell at elego.de Mon Jun 28 03:30:29 2010 From: jkrell at elego.de (Jay Krell) Date: Mon, 28 Jun 2010 3:30:29 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100628013029.E17DE2474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/06/28 03:30:29 Modified files: cm3/m3-sys/m3front/src/misc/: CG.m3 Log message: go back to spelling out Target.Integer|Word.cg_type; there are several (at least instances) of type mismatches here, that gcc 4.5 complains about, we need to use Integer less and Word more, but that isn't changed here yet From jkrell at elego.de Mon Jun 28 11:03:25 2010 From: jkrell at elego.de (Jay Krell) Date: Mon, 28 Jun 2010 11:03:25 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100628090325.118072474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/06/28 11:03:25 Modified files: cm3/m3-libs/m3core/src/: m3core.h Log message: fix Visual C++ warning under -Wall From jkrell at elego.de Mon Jun 28 11:05:08 2010 From: jkrell at elego.de (Jay Krell) Date: Mon, 28 Jun 2010 11:05:08 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100628090508.0DD482474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/06/28 11:05:08 Modified files: cm3/m3-libs/m3core/src/: m3core.h Log message: remove duplicate #define of EXTERN_CONST From jkrell at elego.de Mon Jun 28 11:07:08 2010 From: jkrell at elego.de (Jay Krell) Date: Mon, 28 Jun 2010 11:07:08 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100628090708.541752474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/06/28 11:07:08 Modified files: cm3/m3-libs/m3core/src/Csupport/Common/: hand.c Log message: fix Windows compilation (uint64 => UINT64) From jkrell at elego.de Mon Jun 28 22:29:57 2010 From: jkrell at elego.de (Jay Krell) Date: Mon, 28 Jun 2010 22:29:57 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100628202957.294622474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/06/28 22:29:56 Modified files: cm3/m3-libs/m3core/src/: m3core.h Log message: put back warning, better than consequent error From jkrell at elego.de Tue Jun 29 09:06:33 2010 From: jkrell at elego.de (Jay Krell) Date: Tue, 29 Jun 2010 9:06:33 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100629070634.0A6082474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/06/29 09:06:33 Modified files: cm3/scripts/win/: sysinfo.cmd Log message: support spaces in INCLUDE and PATH, though spaces in CM3_INSTALL are missing quotes when -I is passed to C compiler From jkrell at elego.de Tue Jun 29 09:07:07 2010 From: jkrell at elego.de (Jay Krell) Date: Tue, 29 Jun 2010 9:07:07 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100629070707.CF4BE2474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/06/29 09:07:07 Modified files: cm3/scripts/win/: cvs.c Log message: set CVS_RSH=/bin/ssh if it is ssh or empty From jkrell at elego.de Tue Jun 29 09:07:34 2010 From: jkrell at elego.de (Jay Krell) Date: Tue, 29 Jun 2010 9:07:34 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100629070734.42E602474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/06/29 09:07:34 Modified files: cm3/scripts/win/: cvs.c Log message: remove tab From jkrell at elego.de Tue Jun 29 12:56:36 2010 From: jkrell at elego.de (Jay Krell) Date: Tue, 29 Jun 2010 12:56:36 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100629105636.D40B42474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/06/29 12:56:36 Modified files: cm3/m3-sys/m3tests/src/p2/p230/: Main.m3 Added files: cm3/m3-sys/m3tests/src/p2/p230/: stdout.pgm32-big_endian stdout.pgm32-little_endian stdout.pgm64-big_endian stdout.pgm64-little_endian Removed files: cm3/m3-sys/m3tests/src/p2/p230/: stdout.pgm-big_endian stdout.pgm-little_endian Log message: The output here is word size specific, besides endian specific, because the sets aren't an multiple of 64 bits in size. The 64bit big endian file here is just a copy of 32bit big endian. From jkrell at elego.de Tue Jun 29 13:04:55 2010 From: jkrell at elego.de (Jay Krell) Date: Tue, 29 Jun 2010 13:04:55 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100629110455.957802474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/06/29 13:04:55 Added files: cm3/m3-sys/m3tests/src/p2/p230/: stdout.pgm-big_endian32 stdout.pgm-big_endian64 stdout.pgm-little_endian32 stdout.pgm-little_endian64 Removed files: cm3/m3-sys/m3tests/src/p2/p230/: stdout.pgm32-big_endian stdout.pgm32-little_endian stdout.pgm64-big_endian stdout.pgm64-little_endian Log message: correct the names From jkrell at elego.de Tue Jun 29 13:33:25 2010 From: jkrell at elego.de (Jay Krell) Date: Tue, 29 Jun 2010 13:33:25 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100629113325.7A8542474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/06/29 13:33:25 Added files: cm3/m3-sys/m3tests/src/p2/p239/: Main.m3 Main.ms-AMD64_DARWIN m3makefile Log message: Experimentally..start a line of tests where we checkin the "exact" codegen, so we can later compare. Several caveats/notes: the infrastructure to do the compares is not here yet (shortly) we should probably allow just "i386" or "amd64", instead of the full "AMD64_DARWIN" this kind of testing is "very sensitive" The sensitivity has at least been somewhat reduced by omitting debugging info, and noise reduced by omitting pic and unwind tables The test is far from complete. More targets need current output before changes are made. From jkrell at elego.de Tue Jun 29 13:33:59 2010 From: jkrell at elego.de (Jay Krell) Date: Tue, 29 Jun 2010 13:33:59 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100629113359.555532474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/06/29 13:33:59 Modified files: cm3/m3-sys/m3tests/src/: m3makefile Log message: add test p239 and infra to compare it er, not sure what this will do on other targets, probably fail but not too noisily From jkrell at elego.de Tue Jun 29 13:45:58 2010 From: jkrell at elego.de (Jay Krell) Date: Tue, 29 Jun 2010 13:45:58 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100629114558.377DB2474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/06/29 13:45:58 Modified files: cm3/m3-sys/m3tests/src/p2/p239/: Main.m3 Main.ms-AMD64_DARWIN Log message: add bit-and tests From jkrell at elego.de Tue Jun 29 13:59:29 2010 From: jkrell at elego.de (Jay Krell) Date: Tue, 29 Jun 2010 13:59:29 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100629115929.B82F62474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/06/29 13:59:29 Modified files: cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c Log message: change m3_build1 (CONVERT_EXPR, ...) to m3_convert (...) no great reason, but based on m3_cast convert/cast will be the subject of likely near future other changes, until configure -enable-checking is satisfied (some changes might be elsewhere, e.g. m3front) With this change, the assembly output for AMD64_DARWIN m3core is unchanged. From jkrell at elego.de Tue Jun 29 14:08:31 2010 From: jkrell at elego.de (Jay Krell) Date: Tue, 29 Jun 2010 14:08:31 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100629120831.215B2CC110@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/06/29 14:08:31 Modified files: cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c Log message: Start fixing configure -enable-checking problems. Start with the very simplest: bit-or/and/xor/not. There are some small changes in m3core as a result but they don't appear to be semantically interesting, mostly stuff like: - movq -32(%rbp), %rdx - movq -24(%rbp), %rax + movq -24(%rbp), %rdx + movq -32(%rbp), %rax orq %rdx, %rax when I tried reversing the parameter order, the changes where larger. From jay.krell at cornell.edu Tue Jun 29 14:09:26 2010 From: jay.krell at cornell.edu (Jay K) Date: Tue, 29 Jun 2010 12:09:26 +0000 Subject: [M3commit] CVS Update: cm3 In-Reply-To: <20100629120831.215B2CC110@birch.elegosoft.com> References: <20100629120831.215B2CC110@birch.elegosoft.com> Message-ID: Index: gcc/gcc/m3cg/parse.c =================================================================== RCS file: /usr/cvs/cm3/m3-sys/m3cc/gcc/gcc/m3cg/parse.c,v retrieving revision 1.202 diff -u -r1.202 parse.c --- gcc/gcc/m3cg/parse.c??? 29 Jun 2010 11:59:29 -0000??? 1.202 +++ gcc/gcc/m3cg/parse.c??? 29 Jun 2010 12:07:03 -0000 @@ -4412,8 +4412,7 @@ ?{ ?? MTYPE (t); ? -? EXPR_REF (-1) = m3_build1 (BIT_NOT_EXPR, m3_unsigned_type (t), -???????????????????????????? EXPR_REF (-1)); +? EXPR_REF (-1) = m3_build1 (BIT_NOT_EXPR, t, m3_cast (t, EXPR_REF (-1))); ?} ? ?static void @@ -4421,8 +4420,9 @@ ?{ ?? MTYPE (t); ? -? EXPR_REF (-2) = m3_build2 (BIT_AND_EXPR, m3_unsigned_type (t), -???????????????????????????? EXPR_REF (-2), EXPR_REF (-1)); +? EXPR_REF (-2) = m3_build2 (BIT_AND_EXPR, t, +???????????????????????????? m3_cast (t, EXPR_REF (-2)), +???????????????????????????? m3_cast (t, EXPR_REF (-1))); ?? EXPR_POP (); ?} ? @@ -4431,8 +4431,9 @@ ?{ ?? MTYPE (t); ? -? EXPR_REF (-2) = m3_build2 (BIT_IOR_EXPR, m3_unsigned_type (t), -???????????????????????????? EXPR_REF (-2), EXPR_REF (-1)); +? EXPR_REF (-2) = m3_build2 (BIT_IOR_EXPR, t, +???????????????????????????? m3_cast (t, EXPR_REF (-2)), +???????????????????????????? m3_cast (t, EXPR_REF (-1))); ?? EXPR_POP (); ?} ? @@ -4441,8 +4442,9 @@ ?{ ?? MTYPE (t); ? -? EXPR_REF (-2) = m3_build2 (BIT_XOR_EXPR, m3_unsigned_type (t), -???????????????????????????? EXPR_REF (-2), EXPR_REF (-1)); +? EXPR_REF (-2) = m3_build2 (BIT_XOR_EXPR, t, +???????????????????????????? m3_convert (t, EXPR_REF (-2)), +???????????????????????????? m3_convert (t, EXPR_REF (-1))); ?? EXPR_POP (); ?} ? ---------------------------------------- > Date: Tue, 29 Jun 2010 14:08:31 +0000 > To: m3commit at elegosoft.com > From: jkrell at elego.de > Subject: [M3commit] CVS Update: cm3 > > CVSROOT: /usr/cvs > Changes by: jkrell at birch. 10/06/29 14:08:31 > > Modified files: > cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c > > Log message: > Start fixing configure -enable-checking problems. > Start with the very simplest: bit-or/and/xor/not. > There are some small changes in m3core as a result but > they don't appear to be semantically interesting, mostly stuff like: > - movq -32(%rbp), %rdx > - movq -24(%rbp), %rax > + movq -24(%rbp), %rdx > + movq -32(%rbp), %rax > orq %rdx, %rax > > when I tried reversing the parameter order, the changes where larger. > From jkrell at elego.de Tue Jun 29 14:25:42 2010 From: jkrell at elego.de (Jay Krell) Date: Tue, 29 Jun 2010 14:25:42 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100629122544.BAB2B2474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/06/29 14:25:42 Modified files: cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c Log message: oops, also m3_cast for xor, not m3_convert This again shuffles things around in a way that doesn't seem meaningful. From jkrell at elego.de Tue Jun 29 14:42:12 2010 From: jkrell at elego.de (Jay Krell) Date: Tue, 29 Jun 2010 14:42:12 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100629124212.117E12474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/06/29 14:42:12 Modified files: cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c Log message: cleanup m3cg_index_address - same code for gcc 4.2/3/5 - should address the configure -enable-checking errors I am leary of using m3_cast instead of m3_covert though. From jay.krell at cornell.edu Tue Jun 29 14:42:57 2010 From: jay.krell at cornell.edu (Jay K) Date: Tue, 29 Jun 2010 12:42:57 +0000 Subject: [M3commit] CVS Update: cm3 In-Reply-To: <20100629124212.117E12474003@birch.elegosoft.com> References: <20100629124212.117E12474003@birch.elegosoft.com> Message-ID: Index: parse.c =================================================================== RCS file: /usr/cvs/cm3/m3-sys/m3cc/gcc/gcc/m3cg/parse.c,v retrieving revision 1.204 diff -u -r1.204 parse.c --- parse.c??? 29 Jun 2010 12:25:40 -0000??? 1.204 +++ parse.c??? 29 Jun 2010 12:40:47 -0000 @@ -4982,24 +4982,27 @@ ?static void ?m3cg_index_address (void) ?{ -? enum tree_code plus = (GCC45 ? POINTER_PLUS_EXPR : PLUS_EXPR); ?? tree a = { 0 }; +? bool signd = { 0 }; +? long bytes = { 0 }; + ?? MTYPE2?? (t, T); -? BYTESIZE (n); +? BYTESIZE (bits); +? +? bytes = (bits / BITS_PER_UNIT); ? ?? if (option_vars_trace) -??? fprintf(stderr, "? index address n:0x%lx n_bytes:0x%lx type:%s\n", -??????????? n, n / BITS_PER_UNIT, m3cg_typename(T)); +??? fprintf(stderr, "? index address n_bytes:0x%lx type:%s\n", +??????????? bytes, m3cg_typename(T)); ? -? a = m3_build2 (MULT_EXPR, t, EXPR_REF (-1), size_int (n / BITS_PER_UNIT)); -? if (GCC45) -? { -??? gcc_assert(IS_INTEGER_TYPE_TREE(t) || IS_WORD_TYPE_TREE(t)); -??? if (IS_INTEGER_TYPE_TREE(t)) -????? a = m3_cast(ssizetype, a); -??? a = m3_cast(sizetype, a); -? } -? EXPR_REF (-2) = m3_build2 (plus, t_addr, m3_cast (t_addr, EXPR_REF (-2)), a); +? signd = IS_INTEGER_TYPE_TREE(t); +? gcc_assert(signd || IS_WORD_TYPE_TREE(t)); +? a = (signd ? ssize_int (bytes) : size_int (bytes)); +? a = m3_build2 (MULT_EXPR, t, EXPR_REF (-1), a); +? if (IS_INTEGER_TYPE_TREE(t)) +??? a = m3_cast (ssizetype, a); +? a = m3_cast (sizetype, a); +? EXPR_REF (-2) = m3_build2 (POINTER_PLUS_EXPR, t_addr, m3_cast (t_addr, EXPR_REF (-2)), a); ?? EXPR_POP (); ?} ? ?- Jay ---------------------------------------- > Date: Tue, 29 Jun 2010 14:42:12 +0000 > To: m3commit at elegosoft.com > From: jkrell at elego.de > Subject: [M3commit] CVS Update: cm3 > > CVSROOT: /usr/cvs > Changes by: jkrell at birch. 10/06/29 14:42:12 > > Modified files: > cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c > > Log message: > cleanup m3cg_index_address > - same code for gcc 4.2/3/5 > - should address the configure -enable-checking errors > > I am leary of using m3_cast instead of m3_covert though. > From jkrell at elego.de Tue Jun 29 14:55:46 2010 From: jkrell at elego.de (Jay Krell) Date: Tue, 29 Jun 2010 14:55:46 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100629125546.839972474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/06/29 14:55:46 Modified files: cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c Log message: cleanup m3_do_fixed_extract, no temporaries (in parse.c, not the generated code) needed From jkrell at elego.de Tue Jun 29 15:12:41 2010 From: jkrell at elego.de (Jay Krell) Date: Tue, 29 Jun 2010 15:12:41 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100629131241.21AF12474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/06/29 15:12:41 Modified files: cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c Log message: This should cleanup configure -enable-checking a little more, regarding m3_do_fixed_extract, which is often used for integer division, signed and unsigned. The only change in m3core was a small optimization: +++ AMD64_DARWIN/RTTipe.ms 2010-06-29 05:59:08.000000000 -0700 @@ -3366,41 +3366,39 @@ .stabd 68,0,516 - movq -8(%rbp), %rax - sarq %rax - movq %rax, -8(%rbp) + sarq -8(%rbp) It is not all clear. The tree ended up with, as configure -enable-checking reports, two types, the input and output. -enable-checking demands they be the same. For the left shift, the type doesn't matter. For the right shift, I believe we want the possibly signed type. From jay.krell at cornell.edu Tue Jun 29 15:14:06 2010 From: jay.krell at cornell.edu (Jay K) Date: Tue, 29 Jun 2010 13:14:06 +0000 Subject: [M3commit] CVS Update: cm3 In-Reply-To: <20100629131241.21AF12474003@birch.elegosoft.com> References: <20100629131241.21AF12474003@birch.elegosoft.com> Message-ID: Index: gcc/gcc/m3cg/parse.c =================================================================== RCS file: /usr/cvs/cm3/m3-sys/m3cc/gcc/gcc/m3cg/parse.c,v retrieving revision 1.206 diff -u -r1.206 parse.c --- gcc/gcc/m3cg/parse.c??? 29 Jun 2010 12:55:45 -0000??? 1.206 +++ gcc/gcc/m3cg/parse.c??? 29 Jun 2010 13:09:39 -0000 @@ -4611,7 +4611,7 @@ ???????????????????????????? t); ???? } ? -? x = m3_convert (m3_unsigned_type (t), x); +? x = m3_convert (t, x); ?? x = (b ? m3_build2 (LSHIFT_EXPR, t, x, build_int_cst (t_int, b)) : x); ?? x = (a ? m3_build2 (RSHIFT_EXPR, t, x, build_int_cst (t_int, a)) : x); ?? return x; We might not need the convert, or cast might do. ?- Jay ---------------------------------------- > Date: Tue, 29 Jun 2010 15:12:41 +0000 > To: m3commit at elegosoft.com > From: jkrell at elego.de > Subject: [M3commit] CVS Update: cm3 > > CVSROOT: /usr/cvs > Changes by: jkrell at birch. 10/06/29 15:12:41 > > Modified files: > cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c > > Log message: > This should cleanup configure -enable-checking a little more, > regarding m3_do_fixed_extract, which is often used for > integer division, signed and unsigned. > > The only change in m3core was a small optimization: > +++ AMD64_DARWIN/RTTipe.ms 2010-06-29 05:59:08.000000000 -0700 > @@ -3366,41 +3366,39 @@ > .stabd 68,0,516 > - movq -8(%rbp), %rax > - sarq %rax > - movq %rax, -8(%rbp) > + sarq -8(%rbp) > > It is not all clear. > The tree ended up with, as configure -enable-checking reports, > two types, the input and output. -enable-checking demands > they be the same. For the left shift, the type doesn't matter. > For the right shift, I believe we want the possibly signed type. > From jkrell at elego.de Tue Jun 29 22:58:27 2010 From: jkrell at elego.de (Jay Krell) Date: Tue, 29 Jun 2010 22:58:27 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100629205827.4E3F02474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/06/29 22:58:27 Modified files: cm3/m3-sys/m3cc/gcc-4.5/gcc/: calls.c fold-const.c gimple.c gimplify.c tree-cfg.c tree-nested.c cm3/m3-sys/m3cc/gcc-4.5/gcc/config/i386/: i386.c Log message: checkpoint gcc 4.5 Modula-3 changes including: make some of configure -enable-checking always on making -enable-checking issue warnings instead of errors This can compile cm3 and run a bit of code in it, but does fail and needs further work. Will come back to this once gcc 4.3 -enable-checking is ok. From jay.krell at cornell.edu Tue Jun 29 23:01:43 2010 From: jay.krell at cornell.edu (Jay K) Date: Tue, 29 Jun 2010 21:01:43 +0000 Subject: [M3commit] CVS Update: cm3 In-Reply-To: <20100629205827.4E3F02474003@birch.elegosoft.com> References: <20100629205827.4E3F02474003@birch.elegosoft.com> Message-ID: diff attached ---------------------------------------- > Date: Tue, 29 Jun 2010 22:58:27 +0000 > To: m3commit at elegosoft.com > From: jkrell at elego.de > Subject: [M3commit] CVS Update: cm3 > > CVSROOT: /usr/cvs > Changes by: jkrell at birch. 10/06/29 22:58:27 > > Modified files: > cm3/m3-sys/m3cc/gcc-4.5/gcc/: calls.c fold-const.c gimple.c > gimplify.c tree-cfg.c > tree-nested.c > cm3/m3-sys/m3cc/gcc-4.5/gcc/config/i386/: i386.c > > Log message: > checkpoint gcc 4.5 Modula-3 changes > including: > make some of configure -enable-checking always on > making -enable-checking issue warnings instead of errors > > This can compile cm3 and run a bit of code in it, but does fail > and needs further work. Will come back to this once gcc 4.3 -enable-checking > is ok. > -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: m3cc45-1.txt URL: