From jkrell at elego.de Thu Jul 1 09:56:00 2010 From: jkrell at elego.de (Jay Krell) Date: Thu, 1 Jul 2010 9:56:00 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100701075600.3D2092474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/01 09:56:00 Added files: cm3/m3-sys/m3tests/src/c1/c135/: Main.m3 m3makefile cm3/m3-sys/m3tests/src/c1/c135/expected/AMD64_DARWIN/: Main.ms Log message: moving and slightly restructing test p239 From jkrell at elego.de Thu Jul 1 10:57:05 2010 From: jkrell at elego.de (Jay Krell) Date: Thu, 1 Jul 2010 10:57:05 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100701085705.757622474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/01 10:57:05 Modified files: cm3/m3-sys/m3cc/gcc/gcc/config/: darwin.h Log message: always support hidden aka private extern aka don't export every function from shared libraries, preferably only one - listed in an .i3 file - an .i3 file that is Interface and not merely interface I believe currently I've only achieved the first condition. I suspect this regressed because I put in specifying -target explicitly for consistency with cross builds, and so maybe that doesn't use autoconf as much? I'm not sure. From jkrell at elego.de Thu Jul 1 12:54:39 2010 From: jkrell at elego.de (Jay Krell) Date: Thu, 1 Jul 2010 12:54:39 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100701105439.9A92E2474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/01 12:54:39 Modified files: cm3/m3-sys/m3tests/src/: m3makefile Removed files: cm3/m3-sys/m3tests/src/p2/p239/: Main.m3 Main.ms-AMD64_DARWIN m3makefile Log message: flesh out infrastructure for checking in known/suspected correct assembly and then comparing to current assembly the intent, if not the code, is: in any directory m3-sys/m3tests/src/c1/c123 create m3-sys/m3tests/src/c1/c123/expected/I386_LINUX/Main.ms m3-sys/m3tests/src/c1/c123/expected/I386_LINUX/Foo.ms m3-sys/m3tests/src/c1/c123/expected/AMD64_LINUX/Main.ms m3-sys/m3tests/src/c1/c123/expected/AMD64_LINUX/Foo.ms etc. The name "expected" is a hardcoded part of the interface. I'm open to making it something else or additional flexibility, but this seems adequate or better to me. Any file in expected/TARGET is compared against TARGET. Missing/extra files are just ignored. Note that this probably works for stdout.pgm and such. Future: We should probably allow for: m3-sys/m3tests/src/c1/c123/expected/I386/Foo.ms m3-sys/m3tests/src/c1/c123/expected/AMD64/Main.ms once we confirm that they are often the same. e.g. I wouldn't be surprised if they are the same across all Solaris, *BSD, Linux, though probably not Darwin. Heck, we might even make up something called I386_ELF or I386_SYSV. Cross that bridge later. If the code does not agree with this description, well, this description was my intent. Whether or not creating a directory was worthwhile, it still not clear. The previous implementation allowed for just: m3-sys/m3tests/src/c1/c123/Main.ms-AMD64_LINUX and then you could either glom everything into Main.m3, or use multiple test cases. At the moment I'm thinking of having multiple files but just one large test case. We'll see. It's not a big deal either way. From jkrell at elego.de Thu Jul 1 14:41:08 2010 From: jkrell at elego.de (Jay Krell) Date: Thu, 1 Jul 2010 14:41:08 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100701124109.184902474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/01 14:41:08 Modified files: cm3/m3-sys/m3tests/src/c1/c135/: Main.m3 m3makefile cm3/m3-sys/m3tests/src/c1/c135/expected/AMD64_DARWIN/: Main.ms Added files: cm3/m3-sys/m3tests/src/c1/c135/expected/AMD64_DARWIN/: A.is A.ms Log message: generate code, what we had and a fair amount more we now generate add, subtract, mult, div, mod, or, and, xor for every integer type pair, for either two global variables or two parameters as well as returning each type as a constant or from a global variable or a parameter of any integer type 1104 total little functions, so far I still need to add bit field uses before I can go back and resume configure -enable-checking fixes, as the straightforward type fix there regressed code equality, so I want to try bit field refs again for constant bit insert/extract From jkrell at elego.de Thu Jul 1 15:43:32 2010 From: jkrell at elego.de (Jay Krell) Date: Thu, 1 Jul 2010 15:43:32 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100701134333.2C56E2474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/01 15:43:32 Modified files: cm3/m3-sys/m3tests/src/c1/c135/: m3makefile cm3/m3-sys/m3tests/src/c1/c135/expected/AMD64_DARWIN/: A.ms Log message: start adding float support (and seemingly quite nice generalizations in support of this) From wagner at elego.de Fri Jul 2 08:07:07 2010 From: wagner at elego.de (Olaf Wagner) Date: Fri, 2 Jul 2010 8:07:07 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100702060707.71F422474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: wagner at birch. 10/07/02 08:07:07 Modified files: cm3/scripts/: Tag: release_branch_cm3_5_8 make-dist.sh version version.quake Log message: prepare for final release build From jkrell at elego.de Fri Jul 2 14:41:25 2010 From: jkrell at elego.de (Jay Krell) Date: Fri, 2 Jul 2010 14:41:25 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100702124125.6DAC22474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/02 14:41:25 Added files: cm3/m3-sys/m3tests/src/c1/c135/: Math.quake Log message: addition (Add) and subtraction (Sub) of positive and negative numbers (!) at least in the fixed range [-9999, 9999] Also provide Range(0, n) which creates the array [0, .., n - 1] which you can use with foreach. All built out of hash tables! From jkrell at elego.de Fri Jul 2 14:42:10 2010 From: jkrell at elego.de (Jay Krell) Date: Fri, 2 Jul 2010 14:42:10 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100702124210.7E1082474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/02 14:42:10 Modified files: cm3/m3-sys/m3tests/src/c1/c135/: Math.quake Log message: turn off the test code From jkrell at elego.de Fri Jul 2 14:42:51 2010 From: jkrell at elego.de (Jay Krell) Date: Fri, 2 Jul 2010 14:42:51 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100702124251.3C1662474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/02 14:42:51 Modified files: cm3/m3-sys/m3tests/src/c1/c135/: Math.quake Log message: fix formating error that crept in From jkrell at elego.de Sat Jul 3 08:38:14 2010 From: jkrell at elego.de (Jay Krell) Date: Sat, 3 Jul 2010 8:38:14 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100703063814.C6D342474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/03 08:38:14 Modified files: cm3/m3-sys/m3tests/src/c1/c135/: Math.quake Log message: change Range to InclusiveRange and ExclusiveRange From jkrell at elego.de Sat Jul 3 09:08:54 2010 From: jkrell at elego.de (Jay Krell) Date: Sat, 3 Jul 2010 9:08:54 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100703070854.ADDD12474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/03 09:08:54 Modified files: cm3/m3-sys/m3tests/src/c1/c135/: Math.quake Log message: add Mult, Less, LessOrEqual, Greater, GreaterOrEqual From jkrell at elego.de Sat Jul 3 09:48:07 2010 From: jkrell at elego.de (Jay Krell) Date: Sat, 3 Jul 2010 9:48:07 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100703074807.7BB162474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/03 09:48:07 Modified files: cm3/m3-sys/m3tests/src/c1/c135/: Math.quake Log message: add Div and Mod, and fix a bug in previous From jkrell at elego.de Sat Jul 3 10:27:46 2010 From: jkrell at elego.de (Jay Krell) Date: Sat, 3 Jul 2010 10:27:46 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100703082746.6FA912474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/03 10:27:46 Modified files: cm3/m3-sys/m3tests/src/c1/c135/: Math.quake Log message: provide PowerOf2 and DecToHex PowerOf2 I want as part of testing extract_mn DecToHex is just to make that prettier Though I think extract_mn is more than just about exact powers of 2, need to look into it. I don't see how to provide HexToDec without major duplication/factoring. In particular, I think you'd need a whole other set of tables, and the functions would all have to be given the set of tables to use. Not likely to happen. If we could index strings, that'd help. Maybe we can? Anyway, for now, no matter. I have what I need and slightly more. From jkrell at elego.de Sat Jul 3 10:43:34 2010 From: jkrell at elego.de (Jay Krell) Date: Sat, 3 Jul 2010 10:43:34 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100703084334.A09252474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/03 10:43:34 Modified files: cm3/m3-sys/m3tests/src/c1/c135/: Math.quake Log message: rename DecToHex to just Hex, provide HexPowerOf2 that can deal with large numbers From jkrell at elego.de Sat Jul 3 11:17:54 2010 From: jkrell at elego.de (Jay Krell) Date: Sat, 3 Jul 2010 11:17:54 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100703091755.22F8F2474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/03 11:17:54 Modified files: cm3/m3-sys/m3tests/src/c1/c135/: m3makefile Log message: add a lot more coverage: reads and writes of bitfields division and mod by powers of 2 (I need to check though, it might be not just precise powers of 2 that matter) testing of INTEGER, LONGINT, CARDINAL, LONGCARD (and not just the precisely sized types) some float stuff (maybe that was there already) From jkrell at elego.de Sat Jul 3 11:50:00 2010 From: jkrell at elego.de (Jay Krell) Date: Sat, 3 Jul 2010 11:50:00 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100703095000.D5EDE2474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/03 11:50:00 Modified files: cm3/m3-sys/m3tests/src/c1/c135/: m3makefile Log message: more coverage, esp. div/mod of integer/cardinal/longint/longcard From jkrell at elego.de Sat Jul 3 11:50:46 2010 From: jkrell at elego.de (Jay Krell) Date: Sat, 3 Jul 2010 11:50:46 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100703095046.CEF9D2474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/03 11:50:46 Modified files: cm3/m3-sys/m3cc/gcc/gcc/config/rs6000/: rs6000-protos.h Log message: add #include alias.h to fix compilation break From jkrell at elego.de Sat Jul 3 12:03:50 2010 From: jkrell at elego.de (Jay Krell) Date: Sat, 3 Jul 2010 12:03:50 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100703100350.3158A2474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/03 12:03:50 Modified files: cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c Log message: a little more tracing, of insert/extract From jkrell at elego.de Sat Jul 3 12:05:06 2010 From: jkrell at elego.de (Jay Krell) Date: Sat, 3 Jul 2010 12:05:06 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100703100506.32D642474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/03 12:05:06 Modified files: cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c Log message: fix typo From jkrell at elego.de Sat Jul 3 12:08:17 2010 From: jkrell at elego.de (Jay Krell) Date: Sat, 3 Jul 2010 12:08:17 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100703100817.B35F02474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/03 12:08:17 Modified files: cm3/m3-libs/m3core/src/C/Common/: Cstdint.i3 Log message: remove BITS FOR From jkrell at elego.de Sat Jul 3 12:23:12 2010 From: jkrell at elego.de (Jay Krell) Date: Sat, 3 Jul 2010 12:23:12 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100703102315.47E2C2474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/03 12:23:12 Modified files: cm3/m3-sys/m3tests/src/: m3makefile Log message: port from release: the use of bc causes a problem on Solaris also fix up perhaps the optional use of Cygwin date.exe on NT need some sort of time support in quake? From jkrell at elego.de Sat Jul 3 12:47:11 2010 From: jkrell at elego.de (Jay Krell) Date: Sat, 3 Jul 2010 12:47:11 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100703104711.C99FC2474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/03 12:47:11 Modified files: cm3/m3-sys/cminstall/src/config-no-install/: PPC_LINUX Log message: Don't make executable position independent. It is a nice security feature, but this is the only platform we use it on so far and it breaks debugging (even for C code). From jkrell at elego.de Sat Jul 3 12:48:56 2010 From: jkrell at elego.de (Jay Krell) Date: Sat, 3 Jul 2010 12:48:56 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100703104856.A32A72474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/03 12:48:56 Modified files: cm3/m3-sys/cminstall/src/config-no-install/: Tag: release_branch_cm3_5_8 PPC_LINUX Log message: port from head: don't make PPC_LINUX executables position independent, as it breaks debugging (we do use this on Solaris actually, but the odds of such a bug being portable aren't high) From jkrell at elego.de Sat Jul 3 12:57:09 2010 From: jkrell at elego.de (Jay Krell) Date: Sat, 3 Jul 2010 12:57:09 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100703105709.DBD2E2474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/03 12:57:09 Modified files: cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c Log message: restore volatile for powerpc and powerpc64 platforms This seems to fix PPC_LINUX hanging. This needs further debugging, but I'm not eager. This will also affect PPC_DARWIN, PPC64_DARWIN, PPC32_OPENBSD, PPC32_NETBSD, PPC32_FREEBSD, etc., but these platforms are little used or nonexistant. Having volatile like has been the very long standing situation though. The result is that the optimizer does basically nothing. From jkrell at elego.de Sat Jul 3 12:58:34 2010 From: jkrell at elego.de (Jay Krell) Date: Sat, 3 Jul 2010 12:58:34 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100703105834.337FF2474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/03 12:58:34 Modified files: cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c Log message: fix typo regarding powerpc64 From jkrell at elego.de Sat Jul 3 14:42:37 2010 From: jkrell at elego.de (Jay Krell) Date: Sat, 3 Jul 2010 14:42:37 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100703124239.DA0E02474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/03 14:42:37 Modified files: cm3/m3-sys/m3tests/src/c1/c135/: m3makefile Log message: more coverage cleaner output preparation for still more coverage From jkrell at elego.de Sat Jul 3 15:14:59 2010 From: jkrell at elego.de (Jay Krell) Date: Sat, 3 Jul 2010 15:14:59 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100703131459.438062474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/03 15:14:59 Modified files: cm3/m3-sys/m3tests/src/c1/c135/: m3makefile Log message: add unary negation and unary Word.Not From jkrell at elego.de Sat Jul 3 15:27:41 2010 From: jkrell at elego.de (Jay Krell) Date: Sat, 3 Jul 2010 15:27:41 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100703132741.F037E2474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/03 15:27:41 Modified files: cm3/m3-sys/m3tests/src/c1/c135/: m3makefile Log message: add left/right/other shift/rotate, by non constants limiting second parameter to INTEGER, though other types should have differing / interesting codegen, e.g. CARDINAL would have few range changes hopefully and small ranges would too From jkrell at elego.de Sat Jul 3 15:29:05 2010 From: jkrell at elego.de (Jay Krell) Date: Sat, 3 Jul 2010 15:29:05 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100703132905.381A32474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/03 15:29:05 Modified files: cm3/m3-sys/m3tests/src/c1/c135/: m3makefile Log message: add shift/rotate by cardinal as well From jkrell at elego.de Sat Jul 3 15:31:09 2010 From: jkrell at elego.de (Jay Krell) Date: Sat, 3 Jul 2010 15:31:09 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100703133110.0278B2474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/03 15:31:09 Modified files: cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c Log message: reremove volatile on powerpc, it doesn't seem to hang now..wierd... (should still test it optimized as well) From jkrell at elego.de Sat Jul 3 15:44:42 2010 From: jkrell at elego.de (Jay Krell) Date: Sat, 3 Jul 2010 15:44:42 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100703134442.6254E2474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/03 15:44:42 Modified files: cm3/m3-sys/m3tests/src/c1/c135/: m3makefile Log message: add Word/Long.Insert/Extract coverage, for non-constants and with some of the combinatorics reduced (but constant converage coming shortly) From jkrell at elego.de Sat Jul 3 15:57:20 2010 From: jkrell at elego.de (Jay Krell) Date: Sat, 3 Jul 2010 15:57:20 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100703135720.8D8742474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/03 15:57:20 Modified files: cm3/m3-sys/m3tests/src/c1/c135/: Math.quake Log message: fix direct uses of ExclusiveRange, which I don't use but it had been bugging me From jkrell at elego.de Sat Jul 3 15:58:09 2010 From: jkrell at elego.de (Jay Krell) Date: Sat, 3 Jul 2010 15:58:09 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100703135809.E1A9B2474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/03 15:58:09 Modified files: cm3/m3-sys/m3tests/src/c1/c135/: Math.quake Log message: maybe fix other cases that don't affect me From jkrell at elego.de Sat Jul 3 16:30:25 2010 From: jkrell at elego.de (Jay Krell) Date: Sat, 3 Jul 2010 16:30:25 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100703143028.3F19D2474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/03 16:30:25 Modified files: cm3/m3-sys/m3tests/src/c1/c135/: m3makefile Log message: add insert/extract with one and two constants From jkrell at elego.de Sat Jul 3 17:00:34 2010 From: jkrell at elego.de (Jay Krell) Date: Sat, 3 Jul 2010 17:00:34 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100703150034.F33932474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/03 17:00:34 Modified files: cm3/m3-sys/m3tests/src/c1/c135/: m3makefile Log message: split up some into separate files: bitfield.m3, divmod_pow2.m3, insert.m3, extract.m3, A.m3 From jkrell at elego.de Sat Jul 3 17:01:31 2010 From: jkrell at elego.de (Jay Krell) Date: Sat, 3 Jul 2010 17:01:31 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100703150132.2AA5E2474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/03 17:01:31 Modified files: cm3/m3-sys/m3tests/src/c1/c135/: m3makefile Log message: minor cleanup From jkrell at elego.de Sat Jul 3 17:06:59 2010 From: jkrell at elego.de (Jay Krell) Date: Sat, 3 Jul 2010 17:06:59 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100703150700.057802474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/03 17:06:59 Modified files: cm3/m3-sys/m3tests/src/c1/c135/expected/AMD64_DARWIN/: A.ms Added files: cm3/m3-sys/m3tests/src/c1/c135/expected/AMD64_DARWIN/: bitfield.ms divmod_pow2.ms extract.ms insert.ms Removed files: cm3/m3-sys/m3tests/src/c1/c135/expected/AMD64_DARWIN/: A.is Main.ms Log message: add expected outputs now that maybe maybe this has reached a fairly good state for a while Some of the files are still quite large though and should maybe be broken down more. From jkrell at elego.de Sat Jul 3 17:28:20 2010 From: jkrell at elego.de (Jay Krell) Date: Sat, 3 Jul 2010 17:28:20 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100703152820.CE4B02474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/03 17:28:20 Modified files: cm3/m3-sys/m3tests/src/c1/c135/: m3makefile cm3/m3-sys/m3tests/src/c1/c135/expected/AMD64_DARWIN/: bitfield.ms Log message: keep bitfields to INTEGER, not LONGINT don't have 0 or word-size bitfields, just 1 .. wordsize - 1 From jkrell at elego.de Sat Jul 3 17:38:18 2010 From: jkrell at elego.de (Jay Krell) Date: Sat, 3 Jul 2010 17:38:18 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100703153818.A01FA2474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/03 17:38:18 Added files: cm3/m3-sys/m3tests/src/c1/c135/expected/I386_LINUX/: A.ms bitfield.ms divmod_pow2.ms extract.ms insert.ms Log message: add current outputs From jkrell at elego.de Sat Jul 3 17:41:09 2010 From: jkrell at elego.de (Jay Krell) Date: Sat, 3 Jul 2010 17:41:09 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100703154109.5A7362474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/03 17:41:09 Added files: cm3/m3-sys/m3tests/src/c1/c135/expected/SOLgnu/: A.ms bitfield.ms divmod_pow2.ms extract.ms insert.ms Log message: add current outputs From jkrell at elego.de Sun Jul 4 02:17:19 2010 From: jkrell at elego.de (Jay Krell) Date: Sun, 4 Jul 2010 2:17:19 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100704001720.7BD4B2474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/04 02:17:19 Modified files: cm3/m3-sys/m3tests/src/: m3makefile Added files: cm3/m3-sys/m3tests/src/p2/p240/: Main.m3 Math.quake m3makefile cm3/m3-sys/m3tests/src/p2/p240/expected/AMD64_DARWIN/: A.ms bitfield.ms divmod_pow2.ms extract.ms insert.ms cm3/m3-sys/m3tests/src/p2/p240/expected/I386_LINUX/: A.ms bitfield.ms divmod_pow2.ms extract.ms insert.ms cm3/m3-sys/m3tests/src/p2/p240/expected/SOLgnu/: A.ms bitfield.ms divmod_pow2.ms extract.ms insert.ms Removed files: cm3/m3-sys/m3tests/src/c1/c135/: Main.m3 Math.quake m3makefile cm3/m3-sys/m3tests/src/c1/c135/expected/AMD64_DARWIN/: A.ms bitfield.ms divmod_pow2.ms extract.ms insert.ms cm3/m3-sys/m3tests/src/c1/c135/expected/I386_LINUX/: A.ms bitfield.ms divmod_pow2.ms extract.ms insert.ms cm3/m3-sys/m3tests/src/c1/c135/expected/SOLgnu/: A.ms bitfield.ms divmod_pow2.ms extract.ms insert.ms Log message: restore "c" tests to not running (at least one of them knowingly contains an infinite loop) change c135 to p240 From jkrell at elego.de Sun Jul 4 02:22:35 2010 From: jkrell at elego.de (Jay Krell) Date: Sun, 4 Jul 2010 2:22:35 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100704002241.9F9C72474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/04 02:22:35 Modified files: cm3/m3-sys/cminstall/src/config-no-install/: PPC_LINUX Log message: add comment that gdb 7.1 needed for PIE debugging, keep it disabled at least for now (was it causing other problems??) From hosking at cs.purdue.edu Sun Jul 4 02:36:20 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sat, 3 Jul 2010 20:36:20 -0400 Subject: [M3commit] CVS Update: cm3 In-Reply-To: <20100703105709.DBD2E2474003@birch.elegosoft.com> References: <20100703105709.DBD2E2474003@birch.elegosoft.com> Message-ID: I am very disturbed that volatile is needed here. Can we selectively turn it on for thread-critical files like ThreadPThread and see if it fixes the problem. I wonder if the double-checked locking is broken for PPC memory model. Is this on a multi-processor? On 3 Jul 2010, at 12:57, Jay Krell wrote: > CVSROOT: /usr/cvs > Changes by: jkrell at birch. 10/07/03 12:57:09 > > Modified files: > cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c > > Log message: > restore volatile for powerpc and powerpc64 platforms > This seems to fix PPC_LINUX hanging. > This needs further debugging, but I'm not eager. > This will also affect PPC_DARWIN, PPC64_DARWIN, PPC32_OPENBSD, > PPC32_NETBSD, PPC32_FREEBSD, etc., but these platforms are little used or > nonexistant. > > Having volatile like has been the very long standing situation though. > The result is that the optimizer does basically nothing. From jay.krell at cornell.edu Sun Jul 4 02:42:20 2010 From: jay.krell at cornell.edu (Jay K) Date: Sun, 4 Jul 2010 00:42:20 +0000 Subject: [M3commit] CVS Update: cm3 In-Reply-To: References: <20100703105709.DBD2E2474003@birch.elegosoft.com>, Message-ID: Not a multiprocessor. ? Still interested in selective volatile? This all bothers me too. I don't want volatile. It makes the optimized code terrible. But I don't want to debug any problem from removing it, beyond compilation failure. I can try a few things. This is all wierd. I swear I saw it hang several times. I swear I'm trying to to change "too many" variables at a time. Yes, I know, 2 is too many. Once I started getting version stamp mismatch, I resorted to using a cross built cm3. ?Out of necessity sort of, but that causes more flucuation of variables. Let me try again with volatile and see if it is solid. ?Then I'll try with only volatile stores. I've been trying optimized and unoptimized, and not kept good track of which when. ?- Jay ---------------------------------------- > From: hosking at cs.purdue.edu > Date: Sat, 3 Jul 2010 20:36:20 -0400 > To: jkrell at elego.de > CC: m3commit at elegosoft.com > Subject: Re: [M3commit] CVS Update: cm3 > > I am very disturbed that volatile is needed here. Can we selectively turn it on for thread-critical files like ThreadPThread and see if it fixes the problem. I wonder if the double-checked locking is broken for PPC memory model. Is this on a multi-processor? > > On 3 Jul 2010, at 12:57, Jay Krell wrote: > > > CVSROOT: /usr/cvs > > Changes by: jkrell at birch. 10/07/03 12:57:09 > > > > Modified files: > > cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c > > > > Log message: > > restore volatile for powerpc and powerpc64 platforms > > This seems to fix PPC_LINUX hanging. > > This needs further debugging, but I'm not eager. > > This will also affect PPC_DARWIN, PPC64_DARWIN, PPC32_OPENBSD, > > PPC32_NETBSD, PPC32_FREEBSD, etc., but these platforms are little used or > > nonexistant. > > > > Having volatile like has been the very long standing situation though. > > The result is that the optimizer does basically nothing. > From jay.krell at cornell.edu Sun Jul 4 02:44:37 2010 From: jay.krell at cornell.edu (Jay K) Date: Sun, 4 Jul 2010 00:44:37 +0000 Subject: [M3commit] CVS Update: cm3 In-Reply-To: References: <20100703105709.DBD2E2474003@birch.elegosoft.com>, , Message-ID: Tony, just to be clear..you/I are disturbed by volatile, but it has also, I believe, like always been there. It has been gone only very briefly, and its non-use is probably limited for other reasons (how many people are using it, on how many platforms?). ?- Jay ---------------------------------------- > From: jay.krell at cornell.edu > To: hosking at cs.purdue.edu; jkrell at elego.de > CC: m3commit at elegosoft.com > Subject: RE: [M3commit] CVS Update: cm3 > Date: Sun, 4 Jul 2010 00:42:20 +0000 > > > Not a multiprocessor. > Still interested in selective volatile? > > > This all bothers me too. > I don't want volatile. It makes the optimized code terrible. > But I don't want to debug any problem from removing it, beyond compilation failure. > > > I can try a few things. > This is all wierd. I swear I saw it hang several times. > I swear I'm trying to to change "too many" variables at a time. Yes, I know, 2 is too many. > > > Once I started getting version stamp mismatch, I resorted to using a cross built cm3. > Out of necessity sort of, but that causes more flucuation of variables. > > Let me try again with volatile and see if it is solid. > Then I'll try with only volatile stores. > > I've been trying optimized and unoptimized, and not kept good track of which when. > > > - Jay > > > ---------------------------------------- > > From: hosking at cs.purdue.edu > > Date: Sat, 3 Jul 2010 20:36:20 -0400 > > To: jkrell at elego.de > > CC: m3commit at elegosoft.com > > Subject: Re: [M3commit] CVS Update: cm3 > > > > I am very disturbed that volatile is needed here. Can we selectively turn it on for thread-critical files like ThreadPThread and see if it fixes the problem. I wonder if the double-checked locking is broken for PPC memory model. Is this on a multi-processor? > > > > On 3 Jul 2010, at 12:57, Jay Krell wrote: > > > > > CVSROOT: /usr/cvs > > > Changes by: jkrell at birch. 10/07/03 12:57:09 > > > > > > Modified files: > > > cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c > > > > > > Log message: > > > restore volatile for powerpc and powerpc64 platforms > > > This seems to fix PPC_LINUX hanging. > > > This needs further debugging, but I'm not eager. > > > This will also affect PPC_DARWIN, PPC64_DARWIN, PPC32_OPENBSD, > > > PPC32_NETBSD, PPC32_FREEBSD, etc., but these platforms are little used or > > > nonexistant. > > > > > > Having volatile like has been the very long standing situation though. > > > The result is that the optimizer does basically nothing. > > > From hosking at cs.purdue.edu Sun Jul 4 02:49:11 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sat, 3 Jul 2010 20:49:11 -0400 Subject: [M3commit] CVS Update: cm3 In-Reply-To: References: <20100703105709.DBD2E2474003@birch.elegosoft.com>, Message-ID: <131D2ADF-5AB5-4DFA-B819-1A7F117C94C1@cs.purdue.edu> On 3 Jul 2010, at 20:42, Jay K wrote: > Not a multiprocessor. > Still interested in selective volatile? Not really. This says its something even more troubling unless it happens with the optimiser. > This all bothers me too. > I don't want volatile. It makes the optimized code terrible. Agreed. > But I don't want to debug any problem from removing it, beyond compilation failure. > > > I can try a few things. > This is all wierd. I swear I saw it hang several times. > I swear I'm trying to to change "too many" variables at a time. Yes, I know, 2 is too many. > > > Once I started getting version stamp mismatch, I resorted to using a cross built cm3. > Out of necessity sort of, but that causes more flucuation of variables. > > Let me try again with volatile and see if it is solid. > Then I'll try with only volatile stores. > > I've been trying optimized and unoptimized, and not kept good track of which when. > > > - Jay > > > ---------------------------------------- >> From: hosking at cs.purdue.edu >> Date: Sat, 3 Jul 2010 20:36:20 -0400 >> To: jkrell at elego.de >> CC: m3commit at elegosoft.com >> Subject: Re: [M3commit] CVS Update: cm3 >> >> I am very disturbed that volatile is needed here. Can we selectively turn it on for thread-critical files like ThreadPThread and see if it fixes the problem. I wonder if the double-checked locking is broken for PPC memory model. Is this on a multi-processor? >> >> On 3 Jul 2010, at 12:57, Jay Krell wrote: >> >>> CVSROOT: /usr/cvs >>> Changes by: jkrell at birch. 10/07/03 12:57:09 >>> >>> Modified files: >>> cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c >>> >>> Log message: >>> restore volatile for powerpc and powerpc64 platforms >>> This seems to fix PPC_LINUX hanging. >>> This needs further debugging, but I'm not eager. >>> This will also affect PPC_DARWIN, PPC64_DARWIN, PPC32_OPENBSD, >>> PPC32_NETBSD, PPC32_FREEBSD, etc., but these platforms are little used or >>> nonexistant. >>> >>> Having volatile like has been the very long standing situation though. >>> The result is that the optimizer does basically nothing. >> > From hosking at cs.purdue.edu Sun Jul 4 02:50:11 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sat, 3 Jul 2010 20:50:11 -0400 Subject: [M3commit] CVS Update: cm3 In-Reply-To: References: <20100703105709.DBD2E2474003@birch.elegosoft.com>, , Message-ID: <00538FB2-00DA-4C0E-82F3-D151B9A85A0E@cs.purdue.edu> I added it a long time back only because I saw failures with optimisation turned on. Something to do with the alias analysis (and lack of proper type information) as far as I recall. On 3 Jul 2010, at 20:44, Jay K wrote: > > Tony, just to be clear..you/I are disturbed by volatile, but it has also, I believe, like always been there. > It has been gone only very briefly, and its non-use is probably limited for other reasons (how many people are > using it, on how many platforms?). > > > - Jay > > ---------------------------------------- >> From: jay.krell at cornell.edu >> To: hosking at cs.purdue.edu; jkrell at elego.de >> CC: m3commit at elegosoft.com >> Subject: RE: [M3commit] CVS Update: cm3 >> Date: Sun, 4 Jul 2010 00:42:20 +0000 >> >> >> Not a multiprocessor. >> Still interested in selective volatile? >> >> >> This all bothers me too. >> I don't want volatile. It makes the optimized code terrible. >> But I don't want to debug any problem from removing it, beyond compilation failure. >> >> >> I can try a few things. >> This is all wierd. I swear I saw it hang several times. >> I swear I'm trying to to change "too many" variables at a time. Yes, I know, 2 is too many. >> >> >> Once I started getting version stamp mismatch, I resorted to using a cross built cm3. >> Out of necessity sort of, but that causes more flucuation of variables. >> >> Let me try again with volatile and see if it is solid. >> Then I'll try with only volatile stores. >> >> I've been trying optimized and unoptimized, and not kept good track of which when. >> >> >> - Jay >> >> >> ---------------------------------------- >>> From: hosking at cs.purdue.edu >>> Date: Sat, 3 Jul 2010 20:36:20 -0400 >>> To: jkrell at elego.de >>> CC: m3commit at elegosoft.com >>> Subject: Re: [M3commit] CVS Update: cm3 >>> >>> I am very disturbed that volatile is needed here. Can we selectively turn it on for thread-critical files like ThreadPThread and see if it fixes the problem. I wonder if the double-checked locking is broken for PPC memory model. Is this on a multi-processor? >>> >>> On 3 Jul 2010, at 12:57, Jay Krell wrote: >>> >>>> CVSROOT: /usr/cvs >>>> Changes by: jkrell at birch. 10/07/03 12:57:09 >>>> >>>> Modified files: >>>> cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c >>>> >>>> Log message: >>>> restore volatile for powerpc and powerpc64 platforms >>>> This seems to fix PPC_LINUX hanging. >>>> This needs further debugging, but I'm not eager. >>>> This will also affect PPC_DARWIN, PPC64_DARWIN, PPC32_OPENBSD, >>>> PPC32_NETBSD, PPC32_FREEBSD, etc., but these platforms are little used or >>>> nonexistant. >>>> >>>> Having volatile like has been the very long standing situation though. >>>> The result is that the optimizer does basically nothing. >>> >> > From jkrell at elego.de Sun Jul 4 09:54:39 2010 From: jkrell at elego.de (Jay Krell) Date: Sun, 4 Jul 2010 9:54:39 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100704075439.F06A62474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/04 09:54:39 Modified files: cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c Log message: having restored the historical div/mod implementation.. ARM backend resumes crashing, because it does even for unsigned 64bit divide with any mode (i.e. even the C mode, if the C compiler more resembled the Modula-3 compiler); it needs a non-null pointer from type_for_mode(TImode) In the meantime I have more trust in the gcc builtins than when I stopped using them. So then restore using the gcc builtins. And then to fix the ARM crash, add some TImode/int128 support. Just one line in type_for_mode. remove some tabs From jay.krell at cornell.edu Sun Jul 4 14:58:49 2010 From: jay.krell at cornell.edu (Jay K) Date: Sun, 4 Jul 2010 12:58:49 +0000 Subject: [M3commit] CVS Update: cm3 In-Reply-To: <00538FB2-00DA-4C0E-82F3-D151B9A85A0E@cs.purdue.edu> References: <20100703105709.DBD2E2474003@birch.elegosoft.com>, , , , , , <00538FB2-00DA-4C0E-82F3-D151B9A85A0E@cs.purdue.edu> Message-ID: Darnit and now those version stamp mispatch problems are gone too. I don't know what the heck is/was going on. ?- Jay ---------------------------------------- > From: hosking at cs.purdue.edu > Date: Sat, 3 Jul 2010 20:50:11 -0400 > To: jay.krell at cornell.edu > CC: m3commit at elegosoft.com > Subject: Re: [M3commit] CVS Update: cm3 > > I added it a long time back only because I saw failures with optimisation turned on. Something to do with the alias analysis (and lack of proper type information) as far as I recall. > > > On 3 Jul 2010, at 20:44, Jay K wrote: > > > > > Tony, just to be clear..you/I are disturbed by volatile, but it has also, I believe, like always been there. > > It has been gone only very briefly, and its non-use is probably limited for other reasons (how many people are > > using it, on how many platforms?). > > > > > > - Jay > > > > ---------------------------------------- > >> From: jay.krell at cornell.edu > >> To: hosking at cs.purdue.edu; jkrell at elego.de > >> CC: m3commit at elegosoft.com > >> Subject: RE: [M3commit] CVS Update: cm3 > >> Date: Sun, 4 Jul 2010 00:42:20 +0000 > >> > >> > >> Not a multiprocessor. > >> Still interested in selective volatile? > >> > >> > >> This all bothers me too. > >> I don't want volatile. It makes the optimized code terrible. > >> But I don't want to debug any problem from removing it, beyond compilation failure. > >> > >> > >> I can try a few things. > >> This is all wierd. I swear I saw it hang several times. > >> I swear I'm trying to to change "too many" variables at a time. Yes, I know, 2 is too many. > >> > >> > >> Once I started getting version stamp mismatch, I resorted to using a cross built cm3. > >> Out of necessity sort of, but that causes more flucuation of variables. > >> > >> Let me try again with volatile and see if it is solid. > >> Then I'll try with only volatile stores. > >> > >> I've been trying optimized and unoptimized, and not kept good track of which when. > >> > >> > >> - Jay > >> > >> > >> ---------------------------------------- > >>> From: hosking at cs.purdue.edu > >>> Date: Sat, 3 Jul 2010 20:36:20 -0400 > >>> To: jkrell at elego.de > >>> CC: m3commit at elegosoft.com > >>> Subject: Re: [M3commit] CVS Update: cm3 > >>> > >>> I am very disturbed that volatile is needed here. Can we selectively turn it on for thread-critical files like ThreadPThread and see if it fixes the problem. I wonder if the double-checked locking is broken for PPC memory model. Is this on a multi-processor? > >>> > >>> On 3 Jul 2010, at 12:57, Jay Krell wrote: > >>> > >>>> CVSROOT: /usr/cvs > >>>> Changes by: jkrell at birch. 10/07/03 12:57:09 > >>>> > >>>> Modified files: > >>>> cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c > >>>> > >>>> Log message: > >>>> restore volatile for powerpc and powerpc64 platforms > >>>> This seems to fix PPC_LINUX hanging. > >>>> This needs further debugging, but I'm not eager. > >>>> This will also affect PPC_DARWIN, PPC64_DARWIN, PPC32_OPENBSD, > >>>> PPC32_NETBSD, PPC32_FREEBSD, etc., but these platforms are little used or > >>>> nonexistant. > >>>> > >>>> Having volatile like has been the very long standing situation though. > >>>> The result is that the optimizer does basically nothing. > >>> > >> > > > From jkrell at elego.de Sun Jul 4 15:10:03 2010 From: jkrell at elego.de (Jay Krell) Date: Sun, 4 Jul 2010 15:10:03 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100704131003.E8CAB2474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/04 15:10:03 Modified files: cm3/m3-obliq/obliqlibm3/src/: ObLibM3.m3 Log message: initialize a few local integers that backend warns might be used uninitialized From jay.krell at cornell.edu Sun Jul 4 15:12:36 2010 From: jay.krell at cornell.edu (Jay K) Date: Sun, 4 Jul 2010 13:12:36 +0000 Subject: [M3commit] CVS Update: cm3 In-Reply-To: <20100704131003.E8CAB2474003@birch.elegosoft.com> References: <20100704131003.E8CAB2474003@birch.elegosoft.com> Message-ID: minor diff attached ---------------------------------------- > Date: Sun, 4 Jul 2010 15:10:03 +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/07/04 15:10:03 > > Modified files: > cm3/m3-obliq/obliqlibm3/src/: ObLibM3.m3 > > Log message: > initialize a few local integers that backend warns might be used uninitialized > -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: 1.txt URL: From jkrell at elego.de Sun Jul 4 17:26:33 2010 From: jkrell at elego.de (Jay Krell) Date: Sun, 4 Jul 2010 17:26:33 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100704152633.E6FEF2474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/04 17:26:33 Added files: cm3/m3-libs/m3core/src/float/: test_copysign.c Log message: CopySign in C From jkrell at elego.de Sun Jul 4 17:31:08 2010 From: jkrell at elego.de (Jay Krell) Date: Sun, 4 Jul 2010 17:31:08 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100704153108.E41552474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/04 17:31:08 Modified files: cm3/m3-libs/m3core/src/float/: test_copysign.c Log message: more true to the Modula-3 From jkrell at elego.de Sun Jul 4 17:37:52 2010 From: jkrell at elego.de (Jay Krell) Date: Sun, 4 Jul 2010 17:37:52 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100704153752.EDFB12474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/04 17:37:52 Modified files: cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c Log message: some steps forward and backward: remove the volatile on float stores, good turn off "ter" optimization, not great Need to investigate more. Tested only so far on AMD64_DARWIN. From jay.krell at cornell.edu Sun Jul 4 17:40:26 2010 From: jay.krell at cornell.edu (Jay K) Date: Sun, 4 Jul 2010 15:40:26 +0000 Subject: [M3commit] CVS Update: cm3 In-Reply-To: <20100704153752.EDFB12474003@birch.elegosoft.com> References: <20100704153752.EDFB12474003@birch.elegosoft.com> Message-ID: Just a little two line change attached... (with presumably major impact on floating point code) ---------------------------------------- > Date: Sun, 4 Jul 2010 17:37:52 +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/07/04 17:37:52 > > Modified files: > cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c > > Log message: > some steps forward and backward: > remove the volatile on float stores, good > turn off "ter" optimization, not great > > Need to investigate more. > > Tested only so far on AMD64_DARWIN. > -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: remove_float_volatile_ter.txt URL: From jkrell at elego.de Mon Jul 5 13:22:07 2010 From: jkrell at elego.de (Jay Krell) Date: Mon, 5 Jul 2010 13:22:07 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100705112207.5CD4E2474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/05 13:22:07 Modified files: cm3/m3-libs/m3core/src/float/IEEE/: LongFloat.m3 Log message: ../src/float/IEEE/LongFloat.m3: In function 'LongFloat__Logb': ../src/float/IEEE/LongFloat.m3:35: warning: 'M3_CtKayy_ans' is used uninitialized in this function ../src/float/IEEE/LongFloat.m3: In function 'LongFloat__NextAfter': ../src/float/IEEE/LongFloat.m3:81: warning: 'M3_CtKayy_z' is used uninitialized in this function Not really. Initialize them to 0. There is probably a better fix here, something like: NextAfter: RETURN LOOPHOLE(Rep.T{sign := yy.sign, exponent := 0, significand0 := 0, significand1 := 1}, T) Logb: RETURN LOOPHOLE (Log_of_zero, T); From jkrell at elego.de Mon Jul 5 13:28:32 2010 From: jkrell at elego.de (Jay Krell) Date: Mon, 5 Jul 2010 13:28:32 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100705112833.07AD72474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/05 13:28:32 Modified files: cm3/m3-sys/m3front/src/exprs/: CastExpr.m3 Log message: fix comments: cause => because 'cause => because From jkrell at elego.de Mon Jul 5 14:12:11 2010 From: jkrell at elego.de (Jay Krell) Date: Mon, 5 Jul 2010 14:12:11 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100705121211.4FC9F2474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/05 14:12:11 Modified files: cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c Log message: remove one tab From jkrell at elego.de Mon Jul 5 15:01:38 2010 From: jkrell at elego.de (Jay Krell) Date: Mon, 5 Jul 2010 15:01:38 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100705130138.6A09A2474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/05 15:01:38 Modified files: cm3/m3-libs/m3core/src/float/IEEE/: LongFloat.m3 Log message: go back a version, compiler change coming instead From jkrell at elego.de Mon Jul 5 15:22:28 2010 From: jkrell at elego.de (Jay Krell) Date: Mon, 5 Jul 2010 15:22:28 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100705132228.0E6D52474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/05 15:22:28 Modified files: cm3/m3-tools/cvsup/suplib/src/text_cm3/: SupMiscText.m3 Log message: ../src/text_cm3/SupMiscText.m3: In function 'SupMisc__DecodeWS': ../src/text_cm3/SupMiscText.m3:211: warning: 'M3_Bkn9rd_ch' may be used uninitialized in this function ../src/text_cm3/SupMiscText.m3:211: note: 'M3_Bkn9rd_ch' was declared here because raising an exception isn't currently "noreturn" so initialize it to 0 From jkrell at elego.de Mon Jul 5 15:25:03 2010 From: jkrell at elego.de (Jay Krell) Date: Mon, 5 Jul 2010 15:25:03 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100705132503.B27A82474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/05 15:25:03 Modified files: cm3/m3-tools/cvsup/suplib/src/: MD5Digest.m3 Log message: ../src/MD5Digest.m3: In function 'MD5Digest__FromText': ../src/MD5Digest.m3:162: warning: 'M3_AcxOUs_val' may be used uninitialized in this function ../src/MD5Digest.m3:162: note: 'M3_AcxOUs_val' was declared here From jkrell at elego.de Mon Jul 5 15:27:52 2010 From: jkrell at elego.de (Jay Krell) Date: Mon, 5 Jul 2010 15:27:52 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100705132752.80A422474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/05 15:27:52 Modified files: cm3/m3-comm/events/src/: EventStubLib.m3 Log message: ../src/EventStubLib.m3: In function 'EventStubLib__InInteger': ../src/EventStubLib.m3:1011: warning: 'M3_AcxOUs_i' may be used uninitialized in this function ../src/EventStubLib.m3:1011: note: 'M3_AcxOUs_i' was declared here ../src/EventStubLib.m3: In function 'EventStubLib__InInt32': ../src/EventStubLib.m3:1011: warning: 'M3_ENQ7Kn_i' may be used uninitialized in this function ../src/EventStubLib.m3:1011: note: 'M3_ENQ7Kn_i' was declared here From jkrell at elego.de Mon Jul 5 15:29:58 2010 From: jkrell at elego.de (Jay Krell) Date: Mon, 5 Jul 2010 15:29:58 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100705132958.480262474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/05 15:29:58 Modified files: cm3/m3-ui/juno-2/juno-machine/src/: JunoDisassem.m3 Log message: ../src/JunoDisassem.m3: In function 'JunoDisassem__P__DoSolve': ../src/JunoDisassem.m3:74: warning: 'M3_BlCZOI_z' may be used uninitialized in this function ../src/JunoDisassem.m3:74: warning: 'M3_BlCZOI_y' may be used uninitialized in this function From jkrell at elego.de Mon Jul 5 15:31:43 2010 From: jkrell at elego.de (Jay Krell) Date: Mon, 5 Jul 2010 15:31:43 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100705133143.467692474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/05 15:31:43 Modified files: cm3/m3-ui/juno-2/juno-machine/src/: JunoRT.m3 Log message: ../src/JunoRT.m3: In function 'JunoRT__DoSolve': ../src/JunoRT.m3:1266: warning: 'M3_DGwZEA_z' may be used uninitialized in this function ../src/JunoRT.m3:1266: warning: 'M3_DGwZEA_y' may be used uninitialized in this function From jkrell at elego.de Mon Jul 5 15:33:57 2010 From: jkrell at elego.de (Jay Krell) Date: Mon, 5 Jul 2010 15:33:57 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100705133357.46DC02474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/05 15:33:57 Modified files: cm3/m3-ui/bicycle/src/: PixmapFromXData.m3 Log message: ../src/PixmapFromXData.m3: In function 'PixmapFromXData__P': ../src/PixmapFromXData.m3:136: warning: 'M3_AcxOUs_mask' may be used uninitialized in this function ../src/PixmapFromXData.m3:136: note: 'M3_AcxOUs_mask' was declared here ../src/PixmapFromXData.m3:136: warning: 'M3_AcxOUs_word' may be used uninitialized in this function ../src/PixmapFromXData.m3:136: note: 'M3_AcxOUs_word' was declared here ../src/PixmapFromXData.m3: In function 'PixmapFromXData__Flip': ../src/PixmapFromXData.m3:136: warning: 'M3_AcxOUs_mask' may be used uninitialized in this function ../src/PixmapFromXData.m3:136: note: 'M3_AcxOUs_mask' was declared here ../src/PixmapFromXData.m3:136: warning: 'M3_AcxOUs_word' may be used uninitialized in this function ../src/PixmapFromXData.m3:136: note: 'M3_AcxOUs_word' was declared here From hosking at cs.purdue.edu Mon Jul 5 20:31:01 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 5 Jul 2010 14:31:01 -0400 Subject: [M3commit] CVS Update: cm3 In-Reply-To: <20100705132228.0E6D52474003@birch.elegosoft.com> References: <20100705132228.0E6D52474003@birch.elegosoft.com> Message-ID: <759A98E1-3098-49B8-BC68-B9B3F54D4230@cs.purdue.edu> Jay, I am perplexed that we are adding things to Modula-3 source because of compiler backend brokenness just to avoid back-end warnings. Better to fix the backend so that RAISE is noreturn. This should not be difficult to do. On 5 Jul 2010, at 15:22, Jay Krell wrote: > CVSROOT: /usr/cvs > Changes by: jkrell at birch. 10/07/05 15:22:28 > > Modified files: > cm3/m3-tools/cvsup/suplib/src/text_cm3/: SupMiscText.m3 > > Log message: > ../src/text_cm3/SupMiscText.m3: In function 'SupMisc__DecodeWS': > ../src/text_cm3/SupMiscText.m3:211: warning: 'M3_Bkn9rd_ch' may be used uninitialized in this function > ../src/text_cm3/SupMiscText.m3:211: note: 'M3_Bkn9rd_ch' was declared here > > because raising an exception isn't currently "noreturn" > so initialize it to 0 From hosking at elego.de Mon Jul 5 21:12:02 2010 From: hosking at elego.de (Antony Hosking) Date: Mon, 5 Jul 2010 21:12:02 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100705191202.754142474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: hosking at birch. 10/07/05 21:12:02 Modified files: cm3/m3-sys/m3front/src/misc/: Scanner.m3 Log message: Canonicalize wide char literals to avoid duplicate M3ID for 'w' and 'W'. From jay.krell at cornell.edu Mon Jul 5 22:45:57 2010 From: jay.krell at cornell.edu (Jay K) Date: Mon, 5 Jul 2010 20:45:57 +0000 Subject: [M3commit] CVS Update: cm3 In-Reply-To: <759A98E1-3098-49B8-BC68-B9B3F54D4230@cs.purdue.edu> References: <20100705132228.0E6D52474003@birch.elegosoft.com>, <759A98E1-3098-49B8-BC68-B9B3F54D4230@cs.purdue.edu> Message-ID: I will maybe see about doing better here. Initializing locals doesn't seem like such a bad change though. I like the code to be "obviously correct" by a quick read by a human. ?- Jay ---------------------------------------- > From: hosking at cs.purdue.edu > Date: Mon, 5 Jul 2010 14:31:01 -0400 > To: jkrell at elego.de > CC: m3commit at elegosoft.com > Subject: Re: [M3commit] CVS Update: cm3 > > Jay, I am perplexed that we are adding things to Modula-3 source because of compiler backend brokenness just to avoid back-end warnings. Better to fix the backend so that RAISE is noreturn. This should not be difficult to do. > > On 5 Jul 2010, at 15:22, Jay Krell wrote: > > > CVSROOT: /usr/cvs > > Changes by: jkrell at birch. 10/07/05 15:22:28 > > > > Modified files: > > cm3/m3-tools/cvsup/suplib/src/text_cm3/: SupMiscText.m3 > > > > Log message: > > ../src/text_cm3/SupMiscText.m3: In function 'SupMisc__DecodeWS': > > ../src/text_cm3/SupMiscText.m3:211: warning: 'M3_Bkn9rd_ch' may be used uninitialized in this function > > ../src/text_cm3/SupMiscText.m3:211: note: 'M3_Bkn9rd_ch' was declared here > > > > because raising an exception isn't currently "noreturn" > > so initialize it to 0 > From hosking at cs.purdue.edu Mon Jul 5 22:50:00 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 5 Jul 2010 16:50:00 -0400 Subject: [M3commit] CVS Update: cm3 In-Reply-To: References: <20100705132228.0E6D52474003@birch.elegosoft.com>, <759A98E1-3098-49B8-BC68-B9B3F54D4230@cs.purdue.edu> Message-ID: <3B74FBBA-DEE1-43E8-AB9D-631AA959D6B4@cs.purdue.edu> But we've been this route before. Modula-3 ensures every variable is initialised with a valid value. I don't see how your adding an initialiser makes it more obviously correct. On 5 Jul 2010, at 16:45, Jay K wrote: > > I will maybe see about doing better here. > Initializing locals doesn't seem like such a bad change though. > I like the code to be "obviously correct" by a quick read by a human. > > - Jay > > ---------------------------------------- >> From: hosking at cs.purdue.edu >> Date: Mon, 5 Jul 2010 14:31:01 -0400 >> To: jkrell at elego.de >> CC: m3commit at elegosoft.com >> Subject: Re: [M3commit] CVS Update: cm3 >> >> Jay, I am perplexed that we are adding things to Modula-3 source because of compiler backend brokenness just to avoid back-end warnings. Better to fix the backend so that RAISE is noreturn. This should not be difficult to do. >> >> On 5 Jul 2010, at 15:22, Jay Krell wrote: >> >>> CVSROOT: /usr/cvs >>> Changes by: jkrell at birch. 10/07/05 15:22:28 >>> >>> Modified files: >>> cm3/m3-tools/cvsup/suplib/src/text_cm3/: SupMiscText.m3 >>> >>> Log message: >>> ../src/text_cm3/SupMiscText.m3: In function 'SupMisc__DecodeWS': >>> ../src/text_cm3/SupMiscText.m3:211: warning: 'M3_Bkn9rd_ch' may be used uninitialized in this function >>> ../src/text_cm3/SupMiscText.m3:211: note: 'M3_Bkn9rd_ch' was declared here >>> >>> because raising an exception isn't currently "noreturn" >>> so initialize it to 0 >> > From jay.krell at cornell.edu Mon Jul 5 23:15:35 2010 From: jay.krell at cornell.edu (Jay K) Date: Mon, 5 Jul 2010 21:15:35 +0000 Subject: [M3commit] CVS Update: cm3 In-Reply-To: <3B74FBBA-DEE1-43E8-AB9D-631AA959D6B4@cs.purdue.edu> References: <20100705132228.0E6D52474003@birch.elegosoft.com>, , <759A98E1-3098-49B8-BC68-B9B3F54D4230@cs.purdue.edu>, , <3B74FBBA-DEE1-43E8-AB9D-631AA959D6B4@cs.purdue.edu> Message-ID: At least some of these were Word.T. "valid" is still "random" and the code is unpredictable, at least by a quick read, even if type safe. Type safe is just a minimum bar, one that should always be exceeded, even if the compiler is completely unable to validate it. That is, the compiler guarantees are from sufficient relative to correctness. ?- Jay ---------------------------------------- > From: hosking at cs.purdue.edu > Date: Mon, 5 Jul 2010 16:50:00 -0400 > To: jay.krell at cornell.edu > CC: m3commit at elegosoft.com > Subject: Re: [M3commit] CVS Update: cm3 > > But we've been this route before. Modula-3 ensures every variable is initialised with a valid value. I don't see how your adding an initialiser makes it more obviously correct. > > On 5 Jul 2010, at 16:45, Jay K wrote: > > > > > I will maybe see about doing better here. > > Initializing locals doesn't seem like such a bad change though. > > I like the code to be "obviously correct" by a quick read by a human. > > > > - Jay > > > > ---------------------------------------- > >> From: hosking at cs.purdue.edu > >> Date: Mon, 5 Jul 2010 14:31:01 -0400 > >> To: jkrell at elego.de > >> CC: m3commit at elegosoft.com > >> Subject: Re: [M3commit] CVS Update: cm3 > >> > >> Jay, I am perplexed that we are adding things to Modula-3 source because of compiler backend brokenness just to avoid back-end warnings. Better to fix the backend so that RAISE is noreturn. This should not be difficult to do. > >> > >> On 5 Jul 2010, at 15:22, Jay Krell wrote: > >> > >>> CVSROOT: /usr/cvs > >>> Changes by: jkrell at birch. 10/07/05 15:22:28 > >>> > >>> Modified files: > >>> cm3/m3-tools/cvsup/suplib/src/text_cm3/: SupMiscText.m3 > >>> > >>> Log message: > >>> ../src/text_cm3/SupMiscText.m3: In function 'SupMisc__DecodeWS': > >>> ../src/text_cm3/SupMiscText.m3:211: warning: 'M3_Bkn9rd_ch' may be used uninitialized in this function > >>> ../src/text_cm3/SupMiscText.m3:211: note: 'M3_Bkn9rd_ch' was declared here > >>> > >>> because raising an exception isn't currently "noreturn" > >>> so initialize it to 0 > >> > > > From jkrell at elego.de Mon Jul 5 23:25:58 2010 From: jkrell at elego.de (Jay Krell) Date: Mon, 5 Jul 2010 23:25:58 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100705212558.2BCD72474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/05 23:25:58 Modified files: cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c Log message: rename "volatize" to "make_volatile" move existing code to function m3cg_make_volatile which will work for being called from front end, if we decide to do that (not done here) no real change here, just some renaming Note that the terminology is a bit off perhaps, in that I believe "volatile function" to gcc backend means "noreturn function". Here it means "all the locals, parameters, temporaries are volatile". ie. function calls setjmp/vfork. (This is actually overkill of course: it should only make volatile stuff used after the second return; this could actually still be defeating a fair amount of volatile removal -- any function with a "try".) From jay.krell at cornell.edu Mon Jul 5 23:26:58 2010 From: jay.krell at cornell.edu (Jay K) Date: Mon, 5 Jul 2010 21:26:58 +0000 Subject: [M3commit] CVS Update: cm3 In-Reply-To: <20100705212558.2BCD72474003@birch.elegosoft.com> References: <20100705212558.2BCD72474003@birch.elegosoft.com> Message-ID: attached ---------------------------------------- > Date: Mon, 5 Jul 2010 23: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/07/05 23:25:58 > > Modified files: > cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c > > Log message: > rename "volatize" to "make_volatile" > move existing code to function m3cg_make_volatile which > will work for being called from front end, if we decide to do that > (not done here) > no real change here, just some renaming > > Note that the terminology is a bit off perhaps, in that > I believe "volatile function" to gcc backend means > "noreturn function". Here it means "all the locals, parameters, > temporaries are volatile". ie. function calls setjmp/vfork. > (This is actually overkill of course: it should only make > volatile stuff used after the second return; this could actually > still be defeating a fair amount of volatile removal -- any > function with a "try".) > -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: rename_volatize.txt URL: From hosking at cs.purdue.edu Mon Jul 5 23:34:51 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 5 Jul 2010 17:34:51 -0400 Subject: [M3commit] CVS Update: cm3 In-Reply-To: References: <20100705132228.0E6D52474003@birch.elegosoft.com>, , <759A98E1-3098-49B8-BC68-B9B3F54D4230@cs.purdue.edu>, , <3B74FBBA-DEE1-43E8-AB9D-631AA959D6B4@cs.purdue.edu> Message-ID: <08FF7A56-401D-49FD-A943-155B94BE41C4@cs.purdue.edu> Huh? On 5 Jul 2010, at 17:15, Jay K wrote: > > At least some of these were Word.T. "valid" is still "random" and the code is unpredictable, at least by a quick read, even if type safe. > Type safe is just a minimum bar, one that should always be exceeded, even if the compiler is completely unable to validate it. > > That is, the compiler guarantees are from sufficient relative to correctness. > > - Jay > > ---------------------------------------- >> From: hosking at cs.purdue.edu >> Date: Mon, 5 Jul 2010 16:50:00 -0400 >> To: jay.krell at cornell.edu >> CC: m3commit at elegosoft.com >> Subject: Re: [M3commit] CVS Update: cm3 >> >> But we've been this route before. Modula-3 ensures every variable is initialised with a valid value. I don't see how your adding an initialiser makes it more obviously correct. >> >> On 5 Jul 2010, at 16:45, Jay K wrote: >> >>> >>> I will maybe see about doing better here. >>> Initializing locals doesn't seem like such a bad change though. >>> I like the code to be "obviously correct" by a quick read by a human. >>> >>> - Jay >>> >>> ---------------------------------------- >>>> From: hosking at cs.purdue.edu >>>> Date: Mon, 5 Jul 2010 14:31:01 -0400 >>>> To: jkrell at elego.de >>>> CC: m3commit at elegosoft.com >>>> Subject: Re: [M3commit] CVS Update: cm3 >>>> >>>> Jay, I am perplexed that we are adding things to Modula-3 source because of compiler backend brokenness just to avoid back-end warnings. Better to fix the backend so that RAISE is noreturn. This should not be difficult to do. >>>> >>>> On 5 Jul 2010, at 15:22, Jay Krell wrote: >>>> >>>>> CVSROOT: /usr/cvs >>>>> Changes by: jkrell at birch. 10/07/05 15:22:28 >>>>> >>>>> Modified files: >>>>> cm3/m3-tools/cvsup/suplib/src/text_cm3/: SupMiscText.m3 >>>>> >>>>> Log message: >>>>> ../src/text_cm3/SupMiscText.m3: In function 'SupMisc__DecodeWS': >>>>> ../src/text_cm3/SupMiscText.m3:211: warning: 'M3_Bkn9rd_ch' may be used uninitialized in this function >>>>> ../src/text_cm3/SupMiscText.m3:211: note: 'M3_Bkn9rd_ch' was declared here >>>>> >>>>> because raising an exception isn't currently "noreturn" >>>>> so initialize it to 0 >>>> >>> >> > From hosking at cs.purdue.edu Mon Jul 5 23:35:38 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 5 Jul 2010 17:35:38 -0400 Subject: [M3commit] CVS Update: cm3 In-Reply-To: <20100705212558.2BCD72474003@birch.elegosoft.com> References: <20100705212558.2BCD72474003@birch.elegosoft.com> Message-ID: volatize is terminology from the gcc backend. It is used only for exception frames. I don't think you should make this change. On 5 Jul 2010, at 23:25, Jay Krell wrote: > CVSROOT: /usr/cvs > Changes by: jkrell at birch. 10/07/05 23:25:58 > > Modified files: > cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c > > Log message: > rename "volatize" to "make_volatile" > move existing code to function m3cg_make_volatile which > will work for being called from front end, if we decide to do that > (not done here) > no real change here, just some renaming > > Note that the terminology is a bit off perhaps, in that > I believe "volatile function" to gcc backend means > "noreturn function". Here it means "all the locals, parameters, > temporaries are volatile". ie. function calls setjmp/vfork. > (This is actually overkill of course: it should only make > volatile stuff used after the second return; this could actually > still be defeating a fair amount of volatile removal -- any > function with a "try".) From hosking at cs.purdue.edu Mon Jul 5 23:37:00 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 5 Jul 2010 17:37:00 -0400 Subject: [M3commit] CVS Update: cm3 In-Reply-To: References: <20100705212558.2BCD72474003@birch.elegosoft.com> Message-ID: You are conflating two distinct issues here. volatize is there for a different reason, and should retain its name. On 5 Jul 2010, at 17:26, Jay K wrote: > > > attached > > > ---------------------------------------- >> Date: Mon, 5 Jul 2010 23: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/07/05 23:25:58 >> >> Modified files: >> cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c >> >> Log message: >> rename "volatize" to "make_volatile" >> move existing code to function m3cg_make_volatile which >> will work for being called from front end, if we decide to do that >> (not done here) >> no real change here, just some renaming >> >> Note that the terminology is a bit off perhaps, in that >> I believe "volatile function" to gcc backend means >> "noreturn function". Here it means "all the locals, parameters, >> temporaries are volatile". ie. function calls setjmp/vfork. >> (This is actually overkill of course: it should only make >> volatile stuff used after the second return; this could actually >> still be defeating a fair amount of volatile removal -- any >> function with a "try".) >> > From jkrell at elego.de Mon Jul 5 23:39:19 2010 From: jkrell at elego.de (Jay Krell) Date: Mon, 5 Jul 2010 23:39:19 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100705213919.43D2E2474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/05 23:39:19 Modified files: cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c Log message: go back a version to 215, restoring 'volatilize'/'volatize' names From jay.krell at cornell.edu Mon Jul 5 23:39:23 2010 From: jay.krell at cornell.edu (Jay K) Date: Mon, 5 Jul 2010 21:39:23 +0000 Subject: [M3commit] CVS Update: cm3 In-Reply-To: References: <20100705212558.2BCD72474003@birch.elegosoft.com>, , Message-ID: ok ---------------------------------------- > From: hosking at cs.purdue.edu > Date: Mon, 5 Jul 2010 17:37:00 -0400 > To: jay.krell at cornell.edu > CC: m3commit at elegosoft.com > Subject: Re: [M3commit] CVS Update: cm3 > > You are conflating two distinct issues here. volatize is there for a different reason, and should retain its name. > > On 5 Jul 2010, at 17:26, Jay K wrote: > > > > > > > attached > > > > > > ---------------------------------------- > >> Date: Mon, 5 Jul 2010 23: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/07/05 23:25:58 > >> > >> Modified files: > >> cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c > >> > >> Log message: > >> rename "volatize" to "make_volatile" > >> move existing code to function m3cg_make_volatile which > >> will work for being called from front end, if we decide to do that > >> (not done here) > >> no real change here, just some renaming > >> > >> Note that the terminology is a bit off perhaps, in that > >> I believe "volatile function" to gcc backend means > >> "noreturn function". Here it means "all the locals, parameters, > >> temporaries are volatile". ie. function calls setjmp/vfork. > >> (This is actually overkill of course: it should only make > >> volatile stuff used after the second return; this could actually > >> still be defeating a fair amount of volatile removal -- any > >> function with a "try".) > >> > > > From hosking at cs.purdue.edu Mon Jul 5 23:40:50 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 5 Jul 2010 17:40:50 -0400 Subject: [M3commit] CVS Update: cm3 In-Reply-To: References: <20100705132228.0E6D52474003@birch.elegosoft.com>, , <759A98E1-3098-49B8-BC68-B9B3F54D4230@cs.purdue.edu>, , <3B74FBBA-DEE1-43E8-AB9D-631AA959D6B4@cs.purdue.edu> , <08FF7A56-401D-49FD-A943-155B94BE41C4@cs.purdue.edu> Message-ID: <5BDC54D6-DB79-4E9E-928A-CD802B274B7B@cs.purdue.edu> But the front-end should be OK with the first. It is "correct" because whatever value is in a when F1 is called is legal for a. Why should the backend give a warning? The semantics of Modula-3 allow any legal bit-value for a variable as its initial value. You will force an initialising assignment when none is required by the language spec. On 5 Jul 2010, at 17:36, Jay K wrote: > > unsigned F1() > { > unsigned a; > return a; > } > > should generate a warning. > > unsigned F1() > > { > > unsigned a = 0; > > return a; > > } > > > is much preferred. > > Just because the front end is ok with the first, doesn't make it correct. > > - Jay > > ---------------------------------------- >> Subject: Re: [M3commit] CVS Update: cm3 >> From: hosking at cs.purdue.edu >> Date: Mon, 5 Jul 2010 17:34:51 -0400 >> CC: m3commit at elegosoft.com >> To: jay.krell at cornell.edu >> >> Huh? >> >> On 5 Jul 2010, at 17:15, Jay K wrote: >> >>> >>> At least some of these were Word.T. "valid" is still "random" and the code is unpredictable, at least by a quick read, even if type safe. >>> Type safe is just a minimum bar, one that should always be exceeded, even if the compiler is completely unable to validate it. >>> >>> That is, the compiler guarantees are from sufficient relative to correctness. >>> >>> - Jay >>> >>> ---------------------------------------- >>>> From: hosking at cs.purdue.edu >>>> Date: Mon, 5 Jul 2010 16:50:00 -0400 >>>> To: jay.krell at cornell.edu >>>> CC: m3commit at elegosoft.com >>>> Subject: Re: [M3commit] CVS Update: cm3 >>>> >>>> But we've been this route before. Modula-3 ensures every variable is initialised with a valid value. I don't see how your adding an initialiser makes it more obviously correct. >>>> >>>> On 5 Jul 2010, at 16:45, Jay K wrote: >>>> >>>>> >>>>> I will maybe see about doing better here. >>>>> Initializing locals doesn't seem like such a bad change though. >>>>> I like the code to be "obviously correct" by a quick read by a human. >>>>> >>>>> - Jay >>>>> >>>>> ---------------------------------------- >>>>>> From: hosking at cs.purdue.edu >>>>>> Date: Mon, 5 Jul 2010 14:31:01 -0400 >>>>>> To: jkrell at elego.de >>>>>> CC: m3commit at elegosoft.com >>>>>> Subject: Re: [M3commit] CVS Update: cm3 >>>>>> >>>>>> Jay, I am perplexed that we are adding things to Modula-3 source because of compiler backend brokenness just to avoid back-end warnings. Better to fix the backend so that RAISE is noreturn. This should not be difficult to do. >>>>>> >>>>>> On 5 Jul 2010, at 15:22, Jay Krell wrote: >>>>>> >>>>>>> CVSROOT: /usr/cvs >>>>>>> Changes by: jkrell at birch. 10/07/05 15:22:28 >>>>>>> >>>>>>> Modified files: >>>>>>> cm3/m3-tools/cvsup/suplib/src/text_cm3/: SupMiscText.m3 >>>>>>> >>>>>>> Log message: >>>>>>> ../src/text_cm3/SupMiscText.m3: In function 'SupMisc__DecodeWS': >>>>>>> ../src/text_cm3/SupMiscText.m3:211: warning: 'M3_Bkn9rd_ch' may be used uninitialized in this function >>>>>>> ../src/text_cm3/SupMiscText.m3:211: note: 'M3_Bkn9rd_ch' was declared here >>>>>>> >>>>>>> because raising an exception isn't currently "noreturn" >>>>>>> so initialize it to 0 >>>>>> >>>>> >>>> >>> >> > From jay.krell at cornell.edu Mon Jul 5 23:36:52 2010 From: jay.krell at cornell.edu (Jay K) Date: Mon, 5 Jul 2010 21:36:52 +0000 Subject: [M3commit] CVS Update: cm3 In-Reply-To: <08FF7A56-401D-49FD-A943-155B94BE41C4@cs.purdue.edu> References: <20100705132228.0E6D52474003@birch.elegosoft.com>, , <759A98E1-3098-49B8-BC68-B9B3F54D4230@cs.purdue.edu>, , <3B74FBBA-DEE1-43E8-AB9D-631AA959D6B4@cs.purdue.edu> , <08FF7A56-401D-49FD-A943-155B94BE41C4@cs.purdue.edu> Message-ID: unsigned F1() { ?unsigned a; return a; } should generate a warning. unsigned F1() { ?unsigned a = 0; return a; } is much preferred. Just because the front end is ok with the first, doesn't make it correct. ?- Jay ---------------------------------------- > Subject: Re: [M3commit] CVS Update: cm3 > From: hosking at cs.purdue.edu > Date: Mon, 5 Jul 2010 17:34:51 -0400 > CC: m3commit at elegosoft.com > To: jay.krell at cornell.edu > > Huh? > > On 5 Jul 2010, at 17:15, Jay K wrote: > > > > > At least some of these were Word.T. "valid" is still "random" and the code is unpredictable, at least by a quick read, even if type safe. > > Type safe is just a minimum bar, one that should always be exceeded, even if the compiler is completely unable to validate it. > > > > That is, the compiler guarantees are from sufficient relative to correctness. > > > > - Jay > > > > ---------------------------------------- > >> From: hosking at cs.purdue.edu > >> Date: Mon, 5 Jul 2010 16:50:00 -0400 > >> To: jay.krell at cornell.edu > >> CC: m3commit at elegosoft.com > >> Subject: Re: [M3commit] CVS Update: cm3 > >> > >> But we've been this route before. Modula-3 ensures every variable is initialised with a valid value. I don't see how your adding an initialiser makes it more obviously correct. > >> > >> On 5 Jul 2010, at 16:45, Jay K wrote: > >> > >>> > >>> I will maybe see about doing better here. > >>> Initializing locals doesn't seem like such a bad change though. > >>> I like the code to be "obviously correct" by a quick read by a human. > >>> > >>> - Jay > >>> > >>> ---------------------------------------- > >>>> From: hosking at cs.purdue.edu > >>>> Date: Mon, 5 Jul 2010 14:31:01 -0400 > >>>> To: jkrell at elego.de > >>>> CC: m3commit at elegosoft.com > >>>> Subject: Re: [M3commit] CVS Update: cm3 > >>>> > >>>> Jay, I am perplexed that we are adding things to Modula-3 source because of compiler backend brokenness just to avoid back-end warnings. Better to fix the backend so that RAISE is noreturn. This should not be difficult to do. > >>>> > >>>> On 5 Jul 2010, at 15:22, Jay Krell wrote: > >>>> > >>>>> CVSROOT: /usr/cvs > >>>>> Changes by: jkrell at birch. 10/07/05 15:22:28 > >>>>> > >>>>> Modified files: > >>>>> cm3/m3-tools/cvsup/suplib/src/text_cm3/: SupMiscText.m3 > >>>>> > >>>>> Log message: > >>>>> ../src/text_cm3/SupMiscText.m3: In function 'SupMisc__DecodeWS': > >>>>> ../src/text_cm3/SupMiscText.m3:211: warning: 'M3_Bkn9rd_ch' may be used uninitialized in this function > >>>>> ../src/text_cm3/SupMiscText.m3:211: note: 'M3_Bkn9rd_ch' was declared here > >>>>> > >>>>> because raising an exception isn't currently "noreturn" > >>>>> so initialize it to 0 > >>>> > >>> > >> > > > From jay.krell at cornell.edu Mon Jul 5 23:46:49 2010 From: jay.krell at cornell.edu (Jay K) Date: Mon, 5 Jul 2010 21:46:49 +0000 Subject: [M3commit] CVS Update: cm3 In-Reply-To: <5BDC54D6-DB79-4E9E-928A-CD802B274B7B@cs.purdue.edu> References: <20100705132228.0E6D52474003@birch.elegosoft.com>, , , <759A98E1-3098-49B8-BC68-B9B3F54D4230@cs.purdue.edu>, , , , <3B74FBBA-DEE1-43E8-AB9D-631AA959D6B4@cs.purdue.edu>, , , <08FF7A56-401D-49FD-A943-155B94BE41C4@cs.purdue.edu>, , <5BDC54D6-DB79-4E9E-928A-CD802B274B7B@cs.purdue.edu> Message-ID: Meeting the language spec is inadequate. It is a "quality of implementation" thing. Do you want your C compiler to be silent about this code? No. Or do you want it to try a little harder and point out bugs in your code? Even where it meets the language spec? Yes. ?? Maybe meeting the language spec is more meaningful for Modula-3 than for C, but still inadequate. Now, compiler can't in general be a "correct program proofer", but it can and does catch a few things and that is a good thing not to be avoided. - Jay ---------------------------------------- > From: hosking at cs.purdue.edu > Date: Mon, 5 Jul 2010 17:40:50 -0400 > To: jay.krell at cornell.edu > CC: m3commit at elegosoft.com > Subject: Re: [M3commit] CVS Update: cm3 > > But the front-end should be OK with the first. It is "correct" because whatever value is in a when F1 is called is legal for a. Why should the backend give a warning? The semantics of Modula-3 allow any legal bit-value for a variable as its initial value. You will force an initialising assignment when none is required by the language spec. > > On 5 Jul 2010, at 17:36, Jay K wrote: > > > > > unsigned F1() > > { > > unsigned a; > > return a; > > } > > > > should generate a warning. > > > > unsigned F1() > > > > { > > > > unsigned a = 0; > > > > return a; > > > > } > > > > > > is much preferred. > > > > Just because the front end is ok with the first, doesn't make it correct. > > > > - Jay > > > > ---------------------------------------- > >> Subject: Re: [M3commit] CVS Update: cm3 > >> From: hosking at cs.purdue.edu > >> Date: Mon, 5 Jul 2010 17:34:51 -0400 > >> CC: m3commit at elegosoft.com > >> To: jay.krell at cornell.edu > >> > >> Huh? > >> > >> On 5 Jul 2010, at 17:15, Jay K wrote: > >> > >>> > >>> At least some of these were Word.T. "valid" is still "random" and the code is unpredictable, at least by a quick read, even if type safe. > >>> Type safe is just a minimum bar, one that should always be exceeded, even if the compiler is completely unable to validate it. > >>> > >>> That is, the compiler guarantees are from sufficient relative to correctness. > >>> > >>> - Jay > >>> > >>> ---------------------------------------- > >>>> From: hosking at cs.purdue.edu > >>>> Date: Mon, 5 Jul 2010 16:50:00 -0400 > >>>> To: jay.krell at cornell.edu > >>>> CC: m3commit at elegosoft.com > >>>> Subject: Re: [M3commit] CVS Update: cm3 > >>>> > >>>> But we've been this route before. Modula-3 ensures every variable is initialised with a valid value. I don't see how your adding an initialiser makes it more obviously correct. > >>>> > >>>> On 5 Jul 2010, at 16:45, Jay K wrote: > >>>> > >>>>> > >>>>> I will maybe see about doing better here. > >>>>> Initializing locals doesn't seem like such a bad change though. > >>>>> I like the code to be "obviously correct" by a quick read by a human. > >>>>> > >>>>> - Jay > >>>>> > >>>>> ---------------------------------------- > >>>>>> From: hosking at cs.purdue.edu > >>>>>> Date: Mon, 5 Jul 2010 14:31:01 -0400 > >>>>>> To: jkrell at elego.de > >>>>>> CC: m3commit at elegosoft.com > >>>>>> Subject: Re: [M3commit] CVS Update: cm3 > >>>>>> > >>>>>> Jay, I am perplexed that we are adding things to Modula-3 source because of compiler backend brokenness just to avoid back-end warnings. Better to fix the backend so that RAISE is noreturn. This should not be difficult to do. > >>>>>> > >>>>>> On 5 Jul 2010, at 15:22, Jay Krell wrote: > >>>>>> > >>>>>>> CVSROOT: /usr/cvs > >>>>>>> Changes by: jkrell at birch. 10/07/05 15:22:28 > >>>>>>> > >>>>>>> Modified files: > >>>>>>> cm3/m3-tools/cvsup/suplib/src/text_cm3/: SupMiscText.m3 > >>>>>>> > >>>>>>> Log message: > >>>>>>> ../src/text_cm3/SupMiscText.m3: In function 'SupMisc__DecodeWS': > >>>>>>> ../src/text_cm3/SupMiscText.m3:211: warning: 'M3_Bkn9rd_ch' may be used uninitialized in this function > >>>>>>> ../src/text_cm3/SupMiscText.m3:211: note: 'M3_Bkn9rd_ch' was declared here > >>>>>>> > >>>>>>> because raising an exception isn't currently "noreturn" > >>>>>>> so initialize it to 0 > >>>>>> > >>>>> > >>>> > >>> > >> > > > From jay.krell at cornell.edu Mon Jul 5 23:51:27 2010 From: jay.krell at cornell.edu (Jay K) Date: Mon, 5 Jul 2010 21:51:27 +0000 Subject: [M3commit] CVS Update: cm3 In-Reply-To: <08FF7A56-401D-49FD-A943-155B94BE41C4@cs.purdue.edu> References: <20100705132228.0E6D52474003@birch.elegosoft.com>, , <759A98E1-3098-49B8-BC68-B9B3F54D4230@cs.purdue.edu>, , <3B74FBBA-DEE1-43E8-AB9D-631AA959D6B4@cs.purdue.edu> , <08FF7A56-401D-49FD-A943-155B94BE41C4@cs.purdue.edu> Message-ID: As a human reading code (very finite cycles), I don't like to see: VAR a: type; BEGIN ... END no matter the contents of "...". I'd much rather see: VAR a: type := 0; and know very quickly and without a doubt that a is never used uninitialized. I've been bitten too much by microoptimizations around not initializing locals. Some large fraction of the time the compiler will optimize away the initialization. ? (ie. depending on the contents of "...") Some other large fraction of the time the performance difference will be unmeasurable. ?? So much code is I/O bound already, let alone compute bound by more significant "algorithmic" factors. And then some small fraction of the time, maybe, it will be a bad pessimization. I just don't think it is worth the risk. ?- Jay ---------------------------------------- > Subject: Re: [M3commit] CVS Update: cm3 > From: hosking at cs.purdue.edu > Date: Mon, 5 Jul 2010 17:34:51 -0400 > CC: m3commit at elegosoft.com > To: jay.krell at cornell.edu > > Huh? > > On 5 Jul 2010, at 17:15, Jay K wrote: > > > > > At least some of these were Word.T. "valid" is still "random" and the code is unpredictable, at least by a quick read, even if type safe. > > Type safe is just a minimum bar, one that should always be exceeded, even if the compiler is completely unable to validate it. > > > > That is, the compiler guarantees are from sufficient relative to correctness. > > > > - Jay > > > > ---------------------------------------- > >> From: hosking at cs.purdue.edu > >> Date: Mon, 5 Jul 2010 16:50:00 -0400 > >> To: jay.krell at cornell.edu > >> CC: m3commit at elegosoft.com > >> Subject: Re: [M3commit] CVS Update: cm3 > >> > >> But we've been this route before. Modula-3 ensures every variable is initialised with a valid value. I don't see how your adding an initialiser makes it more obviously correct. > >> > >> On 5 Jul 2010, at 16:45, Jay K wrote: > >> > >>> > >>> I will maybe see about doing better here. > >>> Initializing locals doesn't seem like such a bad change though. > >>> I like the code to be "obviously correct" by a quick read by a human. > >>> > >>> - Jay > >>> > >>> ---------------------------------------- > >>>> From: hosking at cs.purdue.edu > >>>> Date: Mon, 5 Jul 2010 14:31:01 -0400 > >>>> To: jkrell at elego.de > >>>> CC: m3commit at elegosoft.com > >>>> Subject: Re: [M3commit] CVS Update: cm3 > >>>> > >>>> Jay, I am perplexed that we are adding things to Modula-3 source because of compiler backend brokenness just to avoid back-end warnings. Better to fix the backend so that RAISE is noreturn. This should not be difficult to do. > >>>> > >>>> On 5 Jul 2010, at 15:22, Jay Krell wrote: > >>>> > >>>>> CVSROOT: /usr/cvs > >>>>> Changes by: jkrell at birch. 10/07/05 15:22:28 > >>>>> > >>>>> Modified files: > >>>>> cm3/m3-tools/cvsup/suplib/src/text_cm3/: SupMiscText.m3 > >>>>> > >>>>> Log message: > >>>>> ../src/text_cm3/SupMiscText.m3: In function 'SupMisc__DecodeWS': > >>>>> ../src/text_cm3/SupMiscText.m3:211: warning: 'M3_Bkn9rd_ch' may be used uninitialized in this function > >>>>> ../src/text_cm3/SupMiscText.m3:211: note: 'M3_Bkn9rd_ch' was declared here > >>>>> > >>>>> because raising an exception isn't currently "noreturn" > >>>>> so initialize it to 0 > >>>> > >>> > >> > > > From jkrell at elego.de Tue Jul 6 00:16:43 2010 From: jkrell at elego.de (Jay Krell) Date: Tue, 6 Jul 2010 0:16:43 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100705221643.6A4042474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/06 00:16:43 Modified files: cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c Log message: add some asserts around bit field offsets and sizes, that they are all <= 64 and <= TYPE_PRECISION, as well their sums are (which is redundant but ok) one small branch of insert looks pointless, assert(false) From jay.krell at cornell.edu Tue Jul 6 00:18:24 2010 From: jay.krell at cornell.edu (Jay K) Date: Mon, 5 Jul 2010 22:18:24 +0000 Subject: [M3commit] CVS Update: cm3 In-Reply-To: <20100705221643.6A4042474003@birch.elegosoft.com> References: <20100705221643.6A4042474003@birch.elegosoft.com> Message-ID: ---------------------------------------- > Date: Tue, 6 Jul 2010 00:16:43 +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/07/06 00:16:43 > > Modified files: > cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c > > Log message: > add some asserts around bit field offsets and sizes, > that they are all <= 64 and <= TYPE_PRECISION, as well > their sums are (which is redundant but ok) > one small branch of insert looks pointless, assert(false) -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: bitfield_asserts.txt URL: From jay.krell at cornell.edu Tue Jul 6 00:22:53 2010 From: jay.krell at cornell.edu (Jay K) Date: Mon, 5 Jul 2010 22:22:53 +0000 Subject: [M3commit] CVS Update: cm3 In-Reply-To: References: <20100705132228.0E6D52474003@birch.elegosoft.com>, , , <759A98E1-3098-49B8-BC68-B9B3F54D4230@cs.purdue.edu>, , , , <3B74FBBA-DEE1-43E8-AB9D-631AA959D6B4@cs.purdue.edu>, Message-ID: > That is, the compiler guarantees are from sufficient relative to correctness. Was supposed to say *far* from sufficient.. - Jay From hosking at cs.purdue.edu Tue Jul 6 00:42:20 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 5 Jul 2010 18:42:20 -0400 Subject: [M3commit] CVS Update: cm3 In-Reply-To: References: <20100705132228.0E6D52474003@birch.elegosoft.com>, , , <759A98E1-3098-49B8-BC68-B9B3F54D4230@cs.purdue.edu>, , , , <3B74FBBA-DEE1-43E8-AB9D-631AA959D6B4@cs.purdue.edu>, , , <08FF7A56-401D-49FD-A943-155B94BE41C4@cs.purdue.edu>, , <5BDC54D6-DB79-4E9E-928A-CD802B274B7B@cs.purdue.edu> Message-ID: <5C74B751-B423-4919-A990-130C384D2CA9@cs.purdue.edu> Your C compiler will be silent about this code unless you ask it to warn you. On 5 Jul 2010, at 17:46, Jay K wrote: > Meeting the language spec is inadequate. What? > It is a "quality of implementation" thing. > Do you want your C compiler to be silent about this code? No. Why not? > Or do you want it to try a little harder and point out bugs in your code? Those are C bugs because C says nothing about variable initialisation. > Even where it meets the language spec? Yes. > Maybe meeting the language spec is more meaningful for Modula-3 than for C, but still inadequate. > Now, compiler can't in general be a "correct program proofer", but it can and does catch a few things and that is a good thing not to be avoided. > > > - Jay > > ---------------------------------------- >> From: hosking at cs.purdue.edu >> Date: Mon, 5 Jul 2010 17:40:50 -0400 >> To: jay.krell at cornell.edu >> CC: m3commit at elegosoft.com >> Subject: Re: [M3commit] CVS Update: cm3 >> >> But the front-end should be OK with the first. It is "correct" because whatever value is in a when F1 is called is legal for a. Why should the backend give a warning? The semantics of Modula-3 allow any legal bit-value for a variable as its initial value. You will force an initialising assignment when none is required by the language spec. >> >> On 5 Jul 2010, at 17:36, Jay K wrote: >> >>> >>> unsigned F1() >>> { >>> unsigned a; >>> return a; >>> } >>> >>> should generate a warning. >>> >>> unsigned F1() >>> >>> { >>> >>> unsigned a = 0; >>> >>> return a; >>> >>> } >>> >>> >>> is much preferred. >>> >>> Just because the front end is ok with the first, doesn't make it correct. >>> >>> - Jay >>> >>> ---------------------------------------- >>>> Subject: Re: [M3commit] CVS Update: cm3 >>>> From: hosking at cs.purdue.edu >>>> Date: Mon, 5 Jul 2010 17:34:51 -0400 >>>> CC: m3commit at elegosoft.com >>>> To: jay.krell at cornell.edu >>>> >>>> Huh? >>>> >>>> On 5 Jul 2010, at 17:15, Jay K wrote: >>>> >>>>> >>>>> At least some of these were Word.T. "valid" is still "random" and the code is unpredictable, at least by a quick read, even if type safe. >>>>> Type safe is just a minimum bar, one that should always be exceeded, even if the compiler is completely unable to validate it. >>>>> >>>>> That is, the compiler guarantees are from sufficient relative to correctness. >>>>> >>>>> - Jay >>>>> >>>>> ---------------------------------------- >>>>>> From: hosking at cs.purdue.edu >>>>>> Date: Mon, 5 Jul 2010 16:50:00 -0400 >>>>>> To: jay.krell at cornell.edu >>>>>> CC: m3commit at elegosoft.com >>>>>> Subject: Re: [M3commit] CVS Update: cm3 >>>>>> >>>>>> But we've been this route before. Modula-3 ensures every variable is initialised with a valid value. I don't see how your adding an initialiser makes it more obviously correct. >>>>>> >>>>>> On 5 Jul 2010, at 16:45, Jay K wrote: >>>>>> >>>>>>> >>>>>>> I will maybe see about doing better here. >>>>>>> Initializing locals doesn't seem like such a bad change though. >>>>>>> I like the code to be "obviously correct" by a quick read by a human. >>>>>>> >>>>>>> - Jay >>>>>>> >>>>>>> ---------------------------------------- >>>>>>>> From: hosking at cs.purdue.edu >>>>>>>> Date: Mon, 5 Jul 2010 14:31:01 -0400 >>>>>>>> To: jkrell at elego.de >>>>>>>> CC: m3commit at elegosoft.com >>>>>>>> Subject: Re: [M3commit] CVS Update: cm3 >>>>>>>> >>>>>>>> Jay, I am perplexed that we are adding things to Modula-3 source because of compiler backend brokenness just to avoid back-end warnings. Better to fix the backend so that RAISE is noreturn. This should not be difficult to do. >>>>>>>> >>>>>>>> On 5 Jul 2010, at 15:22, Jay Krell wrote: >>>>>>>> >>>>>>>>> CVSROOT: /usr/cvs >>>>>>>>> Changes by: jkrell at birch. 10/07/05 15:22:28 >>>>>>>>> >>>>>>>>> Modified files: >>>>>>>>> cm3/m3-tools/cvsup/suplib/src/text_cm3/: SupMiscText.m3 >>>>>>>>> >>>>>>>>> Log message: >>>>>>>>> ../src/text_cm3/SupMiscText.m3: In function 'SupMisc__DecodeWS': >>>>>>>>> ../src/text_cm3/SupMiscText.m3:211: warning: 'M3_Bkn9rd_ch' may be used uninitialized in this function >>>>>>>>> ../src/text_cm3/SupMiscText.m3:211: note: 'M3_Bkn9rd_ch' was declared here >>>>>>>>> >>>>>>>>> because raising an exception isn't currently "noreturn" >>>>>>>>> so initialize it to 0 >>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >> > From hosking at cs.purdue.edu Tue Jul 6 00:44:16 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 5 Jul 2010 18:44:16 -0400 Subject: [M3commit] CVS Update: cm3 In-Reply-To: References: <20100705132228.0E6D52474003@birch.elegosoft.com>, , <759A98E1-3098-49B8-BC68-B9B3F54D4230@cs.purdue.edu>, , <3B74FBBA-DEE1-43E8-AB9D-631AA959D6B4@cs.purdue.edu> , <08FF7A56-401D-49FD-A943-155B94BE41C4@cs.purdue.edu> Message-ID: <6331F39C-AA28-4AC1-8C87-3D47D52D0C55@cs.purdue.edu> That is you view, but at odds with why Modula-3 was designed the way it was. I think we've already had this conversation before. The point is that even when a variable is initialised to 0 as you prefer there may still be bugs in the program. You are seeing Modula-3 through C spectacles, where so much of the language is undefined. On 5 Jul 2010, at 17:51, Jay K wrote: > > As a human reading code (very finite cycles), I don't like to see: > > > VAR a: type; > BEGIN > ... > END > > > no matter the contents of "...". > > > I'd much rather see: > > > VAR a: type := 0; > > > > and know very quickly and without a doubt that a is never used uninitialized. > I've been bitten too much by microoptimizations around not initializing locals. > Some large fraction of the time the compiler will optimize away the initialization. > (ie. depending on the contents of "...") > Some other large fraction of the time the performance difference will be unmeasurable. > So much code is I/O bound already, let alone compute bound by more significant "algorithmic" factors. > And then some small fraction of the time, maybe, it will be a bad pessimization. > > > I just don't think it is worth the risk. > > > - Jay > > > > ---------------------------------------- >> Subject: Re: [M3commit] CVS Update: cm3 >> From: hosking at cs.purdue.edu >> Date: Mon, 5 Jul 2010 17:34:51 -0400 >> CC: m3commit at elegosoft.com >> To: jay.krell at cornell.edu >> >> Huh? >> >> On 5 Jul 2010, at 17:15, Jay K wrote: >> >>> >>> At least some of these were Word.T. "valid" is still "random" and the code is unpredictable, at least by a quick read, even if type safe. >>> Type safe is just a minimum bar, one that should always be exceeded, even if the compiler is completely unable to validate it. >>> >>> That is, the compiler guarantees are from sufficient relative to correctness. >>> >>> - Jay >>> >>> ---------------------------------------- >>>> From: hosking at cs.purdue.edu >>>> Date: Mon, 5 Jul 2010 16:50:00 -0400 >>>> To: jay.krell at cornell.edu >>>> CC: m3commit at elegosoft.com >>>> Subject: Re: [M3commit] CVS Update: cm3 >>>> >>>> But we've been this route before. Modula-3 ensures every variable is initialised with a valid value. I don't see how your adding an initialiser makes it more obviously correct. >>>> >>>> On 5 Jul 2010, at 16:45, Jay K wrote: >>>> >>>>> >>>>> I will maybe see about doing better here. >>>>> Initializing locals doesn't seem like such a bad change though. >>>>> I like the code to be "obviously correct" by a quick read by a human. >>>>> >>>>> - Jay >>>>> >>>>> ---------------------------------------- >>>>>> From: hosking at cs.purdue.edu >>>>>> Date: Mon, 5 Jul 2010 14:31:01 -0400 >>>>>> To: jkrell at elego.de >>>>>> CC: m3commit at elegosoft.com >>>>>> Subject: Re: [M3commit] CVS Update: cm3 >>>>>> >>>>>> Jay, I am perplexed that we are adding things to Modula-3 source because of compiler backend brokenness just to avoid back-end warnings. Better to fix the backend so that RAISE is noreturn. This should not be difficult to do. >>>>>> >>>>>> On 5 Jul 2010, at 15:22, Jay Krell wrote: >>>>>> >>>>>>> CVSROOT: /usr/cvs >>>>>>> Changes by: jkrell at birch. 10/07/05 15:22:28 >>>>>>> >>>>>>> Modified files: >>>>>>> cm3/m3-tools/cvsup/suplib/src/text_cm3/: SupMiscText.m3 >>>>>>> >>>>>>> Log message: >>>>>>> ../src/text_cm3/SupMiscText.m3: In function 'SupMisc__DecodeWS': >>>>>>> ../src/text_cm3/SupMiscText.m3:211: warning: 'M3_Bkn9rd_ch' may be used uninitialized in this function >>>>>>> ../src/text_cm3/SupMiscText.m3:211: note: 'M3_Bkn9rd_ch' was declared here >>>>>>> >>>>>>> because raising an exception isn't currently "noreturn" >>>>>>> so initialize it to 0 >>>>>> >>>>> >>>> >>> >> > From jay.krell at cornell.edu Tue Jul 6 00:54:38 2010 From: jay.krell at cornell.edu (Jay K) Date: Mon, 5 Jul 2010 22:54:38 +0000 Subject: [M3commit] CVS Update: cm3 In-Reply-To: <5C74B751-B423-4919-A990-130C384D2CA9@cs.purdue.edu> References: <20100705132228.0E6D52474003@birch.elegosoft.com>, , ,,<759A98E1-3098-49B8-BC68-B9B3F54D4230@cs.purdue.edu>, ,,, , , <3B74FBBA-DEE1-43E8-AB9D-631AA959D6B4@cs.purdue.edu>, , , , , <08FF7A56-401D-49FD-A943-155B94BE41C4@cs.purdue.edu>, , , , <5BDC54D6-DB79-4E9E-928A-CD802B274B7B@cs.purdue.edu>, , <5C74B751-B423-4919-A990-130C384D2CA9@cs.purdue.edu> Message-ID: ?> Your C compiler will be silent about this code unless you ask it to warn you. ?These days, most people know to ask for these warnings. ?The warnings are fairly accurate and more often find real bugs than complain about correct code. ?> > Do you want your C compiler to be silent about this code? No. ?> Why not. The compiler, at least when optimizing (doing data/control flow analysis), can easily find bugs in code. Asking it not to is just the wrong thing to do. ?- Jay ---------------------------------------- > From: hosking at cs.purdue.edu > Date: Mon, 5 Jul 2010 18:42:20 -0400 > To: jay.krell at cornell.edu > CC: m3commit at elegosoft.com > Subject: Re: [M3commit] CVS Update: cm3 > > Your C compiler will be silent about this code unless you ask it to warn you. > > On 5 Jul 2010, at 17:46, Jay K wrote: > > > Meeting the language spec is inadequate. > > What? > > > It is a "quality of implementation" thing. > > Do you want your C compiler to be silent about this code? No. > > Why not? > > > Or do you want it to try a little harder and point out bugs in your code? > > Those are C bugs because C says nothing about variable initialisation. > > > Even where it meets the language spec? Yes. > > Maybe meeting the language spec is more meaningful for Modula-3 than for C, but still inadequate. > > Now, compiler can't in general be a "correct program proofer", but it can and does catch a few things and that is a good thing not to be avoided. > > > > > > - Jay > > > > ---------------------------------------- > >> From: hosking at cs.purdue.edu > >> Date: Mon, 5 Jul 2010 17:40:50 -0400 > >> To: jay.krell at cornell.edu > >> CC: m3commit at elegosoft.com > >> Subject: Re: [M3commit] CVS Update: cm3 > >> > >> But the front-end should be OK with the first. It is "correct" because whatever value is in a when F1 is called is legal for a. Why should the backend give a warning? The semantics of Modula-3 allow any legal bit-value for a variable as its initial value. You will force an initialising assignment when none is required by the language spec. > >> > >> On 5 Jul 2010, at 17:36, Jay K wrote: > >> > >>> > >>> unsigned F1() > >>> { > >>> unsigned a; > >>> return a; > >>> } > >>> > >>> should generate a warning. > >>> > >>> unsigned F1() > >>> > >>> { > >>> > >>> unsigned a = 0; > >>> > >>> return a; > >>> > >>> } > >>> > >>> > >>> is much preferred. > >>> > >>> Just because the front end is ok with the first, doesn't make it correct. > >>> > >>> - Jay > >>> > >>> ---------------------------------------- > >>>> Subject: Re: [M3commit] CVS Update: cm3 > >>>> From: hosking at cs.purdue.edu > >>>> Date: Mon, 5 Jul 2010 17:34:51 -0400 > >>>> CC: m3commit at elegosoft.com > >>>> To: jay.krell at cornell.edu > >>>> > >>>> Huh? > >>>> > >>>> On 5 Jul 2010, at 17:15, Jay K wrote: > >>>> > >>>>> > >>>>> At least some of these were Word.T. "valid" is still "random" and the code is unpredictable, at least by a quick read, even if type safe. > >>>>> Type safe is just a minimum bar, one that should always be exceeded, even if the compiler is completely unable to validate it. > >>>>> > >>>>> That is, the compiler guarantees are from sufficient relative to correctness. > >>>>> > >>>>> - Jay > >>>>> > >>>>> ---------------------------------------- > >>>>>> From: hosking at cs.purdue.edu > >>>>>> Date: Mon, 5 Jul 2010 16:50:00 -0400 > >>>>>> To: jay.krell at cornell.edu > >>>>>> CC: m3commit at elegosoft.com > >>>>>> Subject: Re: [M3commit] CVS Update: cm3 > >>>>>> > >>>>>> But we've been this route before. Modula-3 ensures every variable is initialised with a valid value. I don't see how your adding an initialiser makes it more obviously correct. > >>>>>> > >>>>>> On 5 Jul 2010, at 16:45, Jay K wrote: > >>>>>> > >>>>>>> > >>>>>>> I will maybe see about doing better here. > >>>>>>> Initializing locals doesn't seem like such a bad change though. > >>>>>>> I like the code to be "obviously correct" by a quick read by a human. > >>>>>>> > >>>>>>> - Jay > >>>>>>> > >>>>>>> ---------------------------------------- > >>>>>>>> From: hosking at cs.purdue.edu > >>>>>>>> Date: Mon, 5 Jul 2010 14:31:01 -0400 > >>>>>>>> To: jkrell at elego.de > >>>>>>>> CC: m3commit at elegosoft.com > >>>>>>>> Subject: Re: [M3commit] CVS Update: cm3 > >>>>>>>> > >>>>>>>> Jay, I am perplexed that we are adding things to Modula-3 source because of compiler backend brokenness just to avoid back-end warnings. Better to fix the backend so that RAISE is noreturn. This should not be difficult to do. > >>>>>>>> > >>>>>>>> On 5 Jul 2010, at 15:22, Jay Krell wrote: > >>>>>>>> > >>>>>>>>> CVSROOT: /usr/cvs > >>>>>>>>> Changes by: jkrell at birch. 10/07/05 15:22:28 > >>>>>>>>> > >>>>>>>>> Modified files: > >>>>>>>>> cm3/m3-tools/cvsup/suplib/src/text_cm3/: SupMiscText.m3 > >>>>>>>>> > >>>>>>>>> Log message: > >>>>>>>>> ../src/text_cm3/SupMiscText.m3: In function 'SupMisc__DecodeWS': > >>>>>>>>> ../src/text_cm3/SupMiscText.m3:211: warning: 'M3_Bkn9rd_ch' may be used uninitialized in this function > >>>>>>>>> ../src/text_cm3/SupMiscText.m3:211: note: 'M3_Bkn9rd_ch' was declared here > >>>>>>>>> > >>>>>>>>> because raising an exception isn't currently "noreturn" > >>>>>>>>> so initialize it to 0 > >>>>>>>> > >>>>>>> > >>>>>> > >>>>> > >>>> > >>> > >> > > > From jay.krell at cornell.edu Tue Jul 6 00:59:37 2010 From: jay.krell at cornell.edu (Jay K) Date: Mon, 5 Jul 2010 22:59:37 +0000 Subject: [M3commit] CVS Update: cm3 In-Reply-To: <6331F39C-AA28-4AC1-8C87-3D47D52D0C55@cs.purdue.edu> References: <20100705132228.0E6D52474003@birch.elegosoft.com>, , <759A98E1-3098-49B8-BC68-B9B3F54D4230@cs.purdue.edu>, , <3B74FBBA-DEE1-43E8-AB9D-631AA959D6B4@cs.purdue.edu> , <08FF7A56-401D-49FD-A943-155B94BE41C4@cs.purdue.edu> , <6331F39C-AA28-4AC1-8C87-3D47D52D0C55@cs.purdue.edu> Message-ID: There will *always* be bugs, in every program. Even in the CPU (really, I've seen it, some are easy to run afoul of.) ? As I said, the compiler cannot be a "general program proofer". Since that is impossible, cannot exist. But we can take some small easy steps to find some of them early. We do type checking after all. Should we not bother with that? Some simple data/control flow analysis is some of the steps to take beyond that and all compilers do it, both to optimize and to find bugs. ?Just because we can't be perfect, doesn't mean we shouldn't do what is at least "easy". ?- Jay ---------------------------------------- > Subject: Re: [M3commit] CVS Update: cm3 > From: hosking at cs.purdue.edu > Date: Mon, 5 Jul 2010 18:44:16 -0400 > CC: m3commit at elegosoft.com > To: jay.krell at cornell.edu > > That is you view, but at odds with why Modula-3 was designed the way it was. I think we've already had this conversation before. The point is that even when a variable is initialised to 0 as you prefer there may still be bugs in the program. > > You are seeing Modula-3 through C spectacles, where so much of the language is undefined. > > On 5 Jul 2010, at 17:51, Jay K wrote: > > > > > As a human reading code (very finite cycles), I don't like to see: > > > > > > VAR a: type; > > BEGIN > > ... > > END > > > > > > no matter the contents of "...". > > > > > > I'd much rather see: > > > > > > VAR a: type := 0; > > > > > > > > and know very quickly and without a doubt that a is never used uninitialized. > > I've been bitten too much by microoptimizations around not initializing locals. > > Some large fraction of the time the compiler will optimize away the initialization. > > (ie. depending on the contents of "...") > > Some other large fraction of the time the performance difference will be unmeasurable. > > So much code is I/O bound already, let alone compute bound by more significant "algorithmic" factors. > > And then some small fraction of the time, maybe, it will be a bad pessimization. > > > > > > I just don't think it is worth the risk. > > > > > > - Jay > > > > > > > > ---------------------------------------- > >> Subject: Re: [M3commit] CVS Update: cm3 > >> From: hosking at cs.purdue.edu > >> Date: Mon, 5 Jul 2010 17:34:51 -0400 > >> CC: m3commit at elegosoft.com > >> To: jay.krell at cornell.edu > >> > >> Huh? > >> > >> On 5 Jul 2010, at 17:15, Jay K wrote: > >> > >>> > >>> At least some of these were Word.T. "valid" is still "random" and the code is unpredictable, at least by a quick read, even if type safe. > >>> Type safe is just a minimum bar, one that should always be exceeded, even if the compiler is completely unable to validate it. > >>> > >>> That is, the compiler guarantees are from sufficient relative to correctness. > >>> > >>> - Jay > >>> > >>> ---------------------------------------- > >>>> From: hosking at cs.purdue.edu > >>>> Date: Mon, 5 Jul 2010 16:50:00 -0400 > >>>> To: jay.krell at cornell.edu > >>>> CC: m3commit at elegosoft.com > >>>> Subject: Re: [M3commit] CVS Update: cm3 > >>>> > >>>> But we've been this route before. Modula-3 ensures every variable is initialised with a valid value. I don't see how your adding an initialiser makes it more obviously correct. > >>>> > >>>> On 5 Jul 2010, at 16:45, Jay K wrote: > >>>> > >>>>> > >>>>> I will maybe see about doing better here. > >>>>> Initializing locals doesn't seem like such a bad change though. > >>>>> I like the code to be "obviously correct" by a quick read by a human. > >>>>> > >>>>> - Jay > >>>>> > >>>>> ---------------------------------------- > >>>>>> From: hosking at cs.purdue.edu > >>>>>> Date: Mon, 5 Jul 2010 14:31:01 -0400 > >>>>>> To: jkrell at elego.de > >>>>>> CC: m3commit at elegosoft.com > >>>>>> Subject: Re: [M3commit] CVS Update: cm3 > >>>>>> > >>>>>> Jay, I am perplexed that we are adding things to Modula-3 source because of compiler backend brokenness just to avoid back-end warnings. Better to fix the backend so that RAISE is noreturn. This should not be difficult to do. > >>>>>> > >>>>>> On 5 Jul 2010, at 15:22, Jay Krell wrote: > >>>>>> > >>>>>>> CVSROOT: /usr/cvs > >>>>>>> Changes by: jkrell at birch. 10/07/05 15:22:28 > >>>>>>> > >>>>>>> Modified files: > >>>>>>> cm3/m3-tools/cvsup/suplib/src/text_cm3/: SupMiscText.m3 > >>>>>>> > >>>>>>> Log message: > >>>>>>> ../src/text_cm3/SupMiscText.m3: In function 'SupMisc__DecodeWS': > >>>>>>> ../src/text_cm3/SupMiscText.m3:211: warning: 'M3_Bkn9rd_ch' may be used uninitialized in this function > >>>>>>> ../src/text_cm3/SupMiscText.m3:211: note: 'M3_Bkn9rd_ch' was declared here > >>>>>>> > >>>>>>> because raising an exception isn't currently "noreturn" > >>>>>>> so initialize it to 0 > >>>>>> > >>>>> > >>>> > >>> > >> > > > From hosking at cs.purdue.edu Tue Jul 6 04:36:29 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 5 Jul 2010 22:36:29 -0400 Subject: [M3commit] CVS Update: cm3 In-Reply-To: References: <20100705132228.0E6D52474003@birch.elegosoft.com> <759A98E1-3098-49B8-BC68-B9B3F54D4230@cs.purdue.edu> <3B74FBBA-DEE1-43E8-AB9D-631AA959D6B4@cs.purdue.edu> <08FF7A56-401D-49FD-A943-155B94BE41C4@cs.purdue.edu> <6331F39C-AA28-4AC1-8C87-3D47D52D0C55@cs.purdue.edu> Message-ID: <02F12035-7271-4004-BE67-3DAB17C37B3B@cs.purdue.edu> But the compiler frontend has already proved the variable has a valid initial value. Sent from my iPhone On Jul 5, 2010, at 6:59 PM, Jay K wrote: > > There will *always* be bugs, in every program. Even in the CPU (really, I've seen it, some are easy to run afoul of.) > As I said, the compiler cannot be a "general program proofer". Since that is impossible, cannot exist. > But we can take some small easy steps to find some of them early. > We do type checking after all. Should we not bother with that? > Some simple data/control flow analysis is some of the steps to take beyond that and all compilers do it, both to optimize and to find bugs. > Just because we can't be perfect, doesn't mean we shouldn't do what is at least "easy". > > > - Jay > > ---------------------------------------- >> Subject: Re: [M3commit] CVS Update: cm3 >> From: hosking at cs.purdue.edu >> Date: Mon, 5 Jul 2010 18:44:16 -0400 >> CC: m3commit at elegosoft.com >> To: jay.krell at cornell.edu >> >> That is you view, but at odds with why Modula-3 was designed the way it was. I think we've already had this conversation before. The point is that even when a variable is initialised to 0 as you prefer there may still be bugs in the program. >> >> You are seeing Modula-3 through C spectacles, where so much of the language is undefined. >> >> On 5 Jul 2010, at 17:51, Jay K wrote: >> >>> >>> As a human reading code (very finite cycles), I don't like to see: >>> >>> >>> VAR a: type; >>> BEGIN >>> ... >>> END >>> >>> >>> no matter the contents of "...". >>> >>> >>> I'd much rather see: >>> >>> >>> VAR a: type := 0; >>> >>> >>> >>> and know very quickly and without a doubt that a is never used uninitialized. >>> I've been bitten too much by microoptimizations around not initializing locals. >>> Some large fraction of the time the compiler will optimize away the initialization. >>> (ie. depending on the contents of "...") >>> Some other large fraction of the time the performance difference will be unmeasurable. >>> So much code is I/O bound already, let alone compute bound by more significant "algorithmic" factors. >>> And then some small fraction of the time, maybe, it will be a bad pessimization. >>> >>> >>> I just don't think it is worth the risk. >>> >>> >>> - Jay >>> >>> >>> >>> ---------------------------------------- >>>> Subject: Re: [M3commit] CVS Update: cm3 >>>> From: hosking at cs.purdue.edu >>>> Date: Mon, 5 Jul 2010 17:34:51 -0400 >>>> CC: m3commit at elegosoft.com >>>> To: jay.krell at cornell.edu >>>> >>>> Huh? >>>> >>>> On 5 Jul 2010, at 17:15, Jay K wrote: >>>> >>>>> >>>>> At least some of these were Word.T. "valid" is still "random" and the code is unpredictable, at least by a quick read, even if type safe. >>>>> Type safe is just a minimum bar, one that should always be exceeded, even if the compiler is completely unable to validate it. >>>>> >>>>> That is, the compiler guarantees are from sufficient relative to correctness. >>>>> >>>>> - Jay >>>>> >>>>> ---------------------------------------- >>>>>> From: hosking at cs.purdue.edu >>>>>> Date: Mon, 5 Jul 2010 16:50:00 -0400 >>>>>> To: jay.krell at cornell.edu >>>>>> CC: m3commit at elegosoft.com >>>>>> Subject: Re: [M3commit] CVS Update: cm3 >>>>>> >>>>>> But we've been this route before. Modula-3 ensures every variable is initialised with a valid value. I don't see how your adding an initialiser makes it more obviously correct. >>>>>> >>>>>> On 5 Jul 2010, at 16:45, Jay K wrote: >>>>>> >>>>>>> >>>>>>> I will maybe see about doing better here. >>>>>>> Initializing locals doesn't seem like such a bad change though. >>>>>>> I like the code to be "obviously correct" by a quick read by a human. >>>>>>> >>>>>>> - Jay >>>>>>> >>>>>>> ---------------------------------------- >>>>>>>> From: hosking at cs.purdue.edu >>>>>>>> Date: Mon, 5 Jul 2010 14:31:01 -0400 >>>>>>>> To: jkrell at elego.de >>>>>>>> CC: m3commit at elegosoft.com >>>>>>>> Subject: Re: [M3commit] CVS Update: cm3 >>>>>>>> >>>>>>>> Jay, I am perplexed that we are adding things to Modula-3 source because of compiler backend brokenness just to avoid back-end warnings. Better to fix the backend so that RAISE is noreturn. This should not be difficult to do. >>>>>>>> >>>>>>>> On 5 Jul 2010, at 15:22, Jay Krell wrote: >>>>>>>> >>>>>>>>> CVSROOT: /usr/cvs >>>>>>>>> Changes by: jkrell at birch. 10/07/05 15:22:28 >>>>>>>>> >>>>>>>>> Modified files: >>>>>>>>> cm3/m3-tools/cvsup/suplib/src/text_cm3/: SupMiscText.m3 >>>>>>>>> >>>>>>>>> Log message: >>>>>>>>> ../src/text_cm3/SupMiscText.m3: In function 'SupMisc__DecodeWS': >>>>>>>>> ../src/text_cm3/SupMiscText.m3:211: warning: 'M3_Bkn9rd_ch' may be used uninitialized in this function >>>>>>>>> ../src/text_cm3/SupMiscText.m3:211: note: 'M3_Bkn9rd_ch' was declared here >>>>>>>>> >>>>>>>>> because raising an exception isn't currently "noreturn" >>>>>>>>> so initialize it to 0 >>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >> > From jay.krell at cornell.edu Tue Jul 6 04:45:23 2010 From: jay.krell at cornell.edu (Jay K) Date: Tue, 6 Jul 2010 02:45:23 +0000 Subject: [M3commit] CVS Update: cm3 In-Reply-To: <02F12035-7271-4004-BE67-3DAB17C37B3B@cs.purdue.edu> References: <20100705132228.0E6D52474003@birch.elegosoft.com>, <759A98E1-3098-49B8-BC68-B9B3F54D4230@cs.purdue.edu>, , <3B74FBBA-DEE1-43E8-AB9D-631AA959D6B4@cs.purdue.edu>, , <08FF7A56-401D-49FD-A943-155B94BE41C4@cs.purdue.edu>, , <6331F39C-AA28-4AC1-8C87-3D47D52D0C55@cs.purdue.edu>, , <02F12035-7271-4004-BE67-3DAB17C37B3B@cs.purdue.edu> Message-ID: We are going in circles. You have a lower bar for the level of correctness you would like the compiler to try to help the programmer to attain. "valid" doesn't mean much sometimes, given that any value is "valid". Knowingly letting uninitialized data creep in is not good. You can't always help it, and you can't analyze away all bugs, but some you can. Perhaps I don't realize the extent that Modula-3's safety guarantee restrict what can happen when an uninitialized variable gets used. But, really? I mean, let's say it ends up as an array index. It might be "small and valid", and arbitrary data will be operated on, or "large an invalid" and you'll get a nice exception upon indexing. The second case is ok but the first is pretty bad. I understand zero is similar to "small and valid and wrong" but at least it is consistent, repeatable, and perhaps more likely to be found therefore. I will try making the exception raising be noreturn and maybe we can then analyze away the use of uninitialized data. But really I think these are not changes. Even if the compiler can tell the data is used uninitialized, as a programmer, maybe I don't trust the compiler's analysis there -- for example the NT386 backend doesn't do the analysis, nor does gcc when not optimizing. As a programmer I want code to be as clear and clearly correct as possible. Throwing in "unnecesssary" initialization is an easy cheap step there I think. Some large fraction of the time the compiler will optimize away such initialization anyway. Other fraction, the performance difference will not be noticable. And maybe some small fraction of the time it will be a noticable slow down, maybe. - Jay > From: hosking at cs.purdue.edu > Date: Mon, 5 Jul 2010 22:36:29 -0400 > To: jay.krell at cornell.edu > CC: m3commit at elegosoft.com > Subject: Re: [M3commit] CVS Update: cm3 > > But the compiler frontend has already proved the variable has a valid initial value. > > Sent from my iPhone > > On Jul 5, 2010, at 6:59 PM, Jay K wrote: > > > > > There will *always* be bugs, in every program. Even in the CPU (really, I've seen it, some are easy to run afoul of.) > > As I said, the compiler cannot be a "general program proofer". Since that is impossible, cannot exist. > > But we can take some small easy steps to find some of them early. > > We do type checking after all. Should we not bother with that? > > Some simple data/control flow analysis is some of the steps to take beyond that and all compilers do it, both to optimize and to find bugs. > > Just because we can't be perfect, doesn't mean we shouldn't do what is at least "easy". > > > > > > - Jay > > > > ---------------------------------------- > >> Subject: Re: [M3commit] CVS Update: cm3 > >> From: hosking at cs.purdue.edu > >> Date: Mon, 5 Jul 2010 18:44:16 -0400 > >> CC: m3commit at elegosoft.com > >> To: jay.krell at cornell.edu > >> > >> That is you view, but at odds with why Modula-3 was designed the way it was. I think we've already had this conversation before. The point is that even when a variable is initialised to 0 as you prefer there may still be bugs in the program. > >> > >> You are seeing Modula-3 through C spectacles, where so much of the language is undefined. > >> > >> On 5 Jul 2010, at 17:51, Jay K wrote: > >> > >>> > >>> As a human reading code (very finite cycles), I don't like to see: > >>> > >>> > >>> VAR a: type; > >>> BEGIN > >>> ... > >>> END > >>> > >>> > >>> no matter the contents of "...". > >>> > >>> > >>> I'd much rather see: > >>> > >>> > >>> VAR a: type := 0; > >>> > >>> > >>> > >>> and know very quickly and without a doubt that a is never used uninitialized. > >>> I've been bitten too much by microoptimizations around not initializing locals. > >>> Some large fraction of the time the compiler will optimize away the initialization. > >>> (ie. depending on the contents of "...") > >>> Some other large fraction of the time the performance difference will be unmeasurable. > >>> So much code is I/O bound already, let alone compute bound by more significant "algorithmic" factors. > >>> And then some small fraction of the time, maybe, it will be a bad pessimization. > >>> > >>> > >>> I just don't think it is worth the risk. > >>> > >>> > >>> - Jay > >>> > >>> > >>> > >>> ---------------------------------------- > >>>> Subject: Re: [M3commit] CVS Update: cm3 > >>>> From: hosking at cs.purdue.edu > >>>> Date: Mon, 5 Jul 2010 17:34:51 -0400 > >>>> CC: m3commit at elegosoft.com > >>>> To: jay.krell at cornell.edu > >>>> > >>>> Huh? > >>>> > >>>> On 5 Jul 2010, at 17:15, Jay K wrote: > >>>> > >>>>> > >>>>> At least some of these were Word.T. "valid" is still "random" and the code is unpredictable, at least by a quick read, even if type safe. > >>>>> Type safe is just a minimum bar, one that should always be exceeded, even if the compiler is completely unable to validate it. > >>>>> > >>>>> That is, the compiler guarantees are from sufficient relative to correctness. > >>>>> > >>>>> - Jay > >>>>> > >>>>> ---------------------------------------- > >>>>>> From: hosking at cs.purdue.edu > >>>>>> Date: Mon, 5 Jul 2010 16:50:00 -0400 > >>>>>> To: jay.krell at cornell.edu > >>>>>> CC: m3commit at elegosoft.com > >>>>>> Subject: Re: [M3commit] CVS Update: cm3 > >>>>>> > >>>>>> But we've been this route before. Modula-3 ensures every variable is initialised with a valid value. I don't see how your adding an initialiser makes it more obviously correct. > >>>>>> > >>>>>> On 5 Jul 2010, at 16:45, Jay K wrote: > >>>>>> > >>>>>>> > >>>>>>> I will maybe see about doing better here. > >>>>>>> Initializing locals doesn't seem like such a bad change though. > >>>>>>> I like the code to be "obviously correct" by a quick read by a human. > >>>>>>> > >>>>>>> - Jay > >>>>>>> > >>>>>>> ---------------------------------------- > >>>>>>>> From: hosking at cs.purdue.edu > >>>>>>>> Date: Mon, 5 Jul 2010 14:31:01 -0400 > >>>>>>>> To: jkrell at elego.de > >>>>>>>> CC: m3commit at elegosoft.com > >>>>>>>> Subject: Re: [M3commit] CVS Update: cm3 > >>>>>>>> > >>>>>>>> Jay, I am perplexed that we are adding things to Modula-3 source because of compiler backend brokenness just to avoid back-end warnings. Better to fix the backend so that RAISE is noreturn. This should not be difficult to do. > >>>>>>>> > >>>>>>>> On 5 Jul 2010, at 15:22, Jay Krell wrote: > >>>>>>>> > >>>>>>>>> CVSROOT: /usr/cvs > >>>>>>>>> Changes by: jkrell at birch. 10/07/05 15:22:28 > >>>>>>>>> > >>>>>>>>> Modified files: > >>>>>>>>> cm3/m3-tools/cvsup/suplib/src/text_cm3/: SupMiscText.m3 > >>>>>>>>> > >>>>>>>>> Log message: > >>>>>>>>> ../src/text_cm3/SupMiscText.m3: In function 'SupMisc__DecodeWS': > >>>>>>>>> ../src/text_cm3/SupMiscText.m3:211: warning: 'M3_Bkn9rd_ch' may be used uninitialized in this function > >>>>>>>>> ../src/text_cm3/SupMiscText.m3:211: note: 'M3_Bkn9rd_ch' was declared here > >>>>>>>>> > >>>>>>>>> because raising an exception isn't currently "noreturn" > >>>>>>>>> so initialize it to 0 > >>>>>>>> > >>>>>>> > >>>>>> > >>>>> > >>>> > >>> > >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Tue Jul 6 05:15:14 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 5 Jul 2010 23:15:14 -0400 Subject: [M3commit] CVS Update: cm3 In-Reply-To: References: <20100705132228.0E6D52474003@birch.elegosoft.com>, <759A98E1-3098-49B8-BC68-B9B3F54D4230@cs.purdue.edu>, , <3B74FBBA-DEE1-43E8-AB9D-631AA959D6B4@cs.purdue.edu>, , <08FF7A56-401D-49FD-A943-155B94BE41C4@cs.purdue.edu>, , <6331F39C-AA28-4AC1-8C87-3D47D52D0C55@cs.purdue.edu>, , <02F12035-7271-4004-BE67-3DAB17C37B3B@cs.purdue.edu> Message-ID: <26F9F2BE-6D6E-4F33-A9BE-D69A6E355EA5@cs.purdue.edu> Sigh... You are tilting at windmills. On 5 Jul 2010, at 22:45, Jay K wrote: > We are going in circles. > > > You have a lower bar for the level of correctness you would like the compiler to try to help the programmer to attain. > "valid" doesn't mean much sometimes, given that any value is "valid". > > Knowingly letting uninitialized data creep in is not good. > You can't always help it, and you can't analyze away all bugs, but some you can. > > > Perhaps I don't realize the extent that Modula-3's safety guarantee restrict what can happen when an uninitialized variable gets used. > But, really? I mean, let's say it ends up as an array index. It might be "small and valid", and arbitrary data will be operated on, or "large an invalid" and you'll get a nice exception upon indexing. The second case is ok but the first is pretty bad. I understand zero is similar to "small and valid and wrong" but at least it is consistent, repeatable, and perhaps more likely to be found therefore. > > I will try making the exception raising be noreturn and maybe we can then analyze away the use of uninitialized data. > But really I think these are not changes. > Even if the compiler can tell the data is used uninitialized, as a programmer, maybe I don't trust the compiler's analysis there -- for example the NT386 backend doesn't do the analysis, nor does gcc when not optimizing. > As a programmer I want code to be as clear and clearly correct as possible. Throwing in "unnecesssary" initialization is an easy cheap step there I think. > > > Some large fraction of the time the compiler will optimize away such initialization anyway. > Other fraction, the performance difference will not be noticable. > And maybe some small fraction of the time it will be a noticable slow down, maybe. > > > - Jay > > > From: hosking at cs.purdue.edu > > Date: Mon, 5 Jul 2010 22:36:29 -0400 > > To: jay.krell at cornell.edu > > CC: m3commit at elegosoft.com > > Subject: Re: [M3commit] CVS Update: cm3 > > > > But the compiler frontend has already proved the variable has a valid initial value. > > > > Sent from my iPhone > > > > On Jul 5, 2010, at 6:59 PM, Jay K wrote: > > > > > > > > There will *always* be bugs, in every program. Even in the CPU (really, I've seen it, some are easy to run afoul of.) > > > As I said, the compiler cannot be a "general program proofer". Since that is impossible, cannot exist. > > > But we can take some small easy steps to find some of them early. > > > We do type checking after all. Should we not bother with that? > > > Some simple data/control flow analysis is some of the steps to take beyond that and all compilers do it, both to optimize and to find bugs. > > > Just because we can't be perfect, doesn't mean we shouldn't do what is at least "easy". > > > > > > > > > - Jay > > > > > > ---------------------------------------- > > >> Subject: Re: [M3commit] CVS Update: cm3 > > >> From: hosking at cs.purdue.edu > > >> Date: Mon, 5 Jul 2010 18:44:16 -0400 > > >> CC: m3commit at elegosoft.com > > >> To: jay.krell at cornell.edu > > >> > > >> That is you view, but at odds with why Modula-3 was designed the way it was. I think we've already had this conversation before. The point is that even when a variable is initialised to 0 as you prefer there may still be bugs in the program. > > >> > > >> You are seeing Modula-3 through C spectacles, where so much of the language is undefined. > > >> > > >> On 5 Jul 2010, at 17:51, Jay K wrote: > > >> > > >>> > > >>> As a human reading code (very finite cycles), I don't like to see: > > >>> > > >>> > > >>> VAR a: type; > > >>> BEGIN > > >>> ... > > >>> END > > >>> > > >>> > > >>> no matter the contents of "...". > > >>> > > >>> > > >>> I'd much rather see: > > >>> > > >>> > > >>> VAR a: type := 0; > > >>> > > >>> > > >>> > > >>> and know very quickly and without a doubt that a is never used uninitialized. > > >>> I've been bitten too much by microoptimizations around not initializing locals. > > >>> Some large fraction of the time the compiler will optimize away the initialization. > > >>> (ie. depending on the contents of "...") > > >>> Some other large fraction of the time the performance difference will be unmeasurable. > > >>> So much code is I/O bound already, let alone compute bound by more significant "algorithmic" factors. > > >>> And then some small fraction of the time, maybe, it will be a bad pessimization. > > >>> > > >>> > > >>> I just don't think it is worth the risk. > > >>> > > >>> > > >>> - Jay > > >>> > > >>> > > >>> > > >>> ---------------------------------------- > > >>>> Subject: Re: [M3commit] CVS Update: cm3 > > >>>> From: hosking at cs.purdue.edu > > >>>> Date: Mon, 5 Jul 2010 17:34:51 -0400 > > >>>> CC: m3commit at elegosoft.com > > >>>> To: jay.krell at cornell.edu > > >>>> > > >>>> Huh? > > >>>> > > >>>> On 5 Jul 2010, at 17:15, Jay K wrote: > > >>>> > > >>>>> > > >>>>> At least some of these were Word.T. "valid" is still "random" and the code is unpredictable, at least by a quick read, even if type safe. > > >>>>> Type safe is just a minimum bar, one that should always be exceeded, even if the compiler is completely unable to validate it. > > >>>>> > > >>>>> That is, the compiler guarantees are from sufficient relative to correctness. > > >>>>> > > >>>>> - Jay > > >>>>> > > >>>>> ---------------------------------------- > > >>>>>> From: hosking at cs.purdue.edu > > >>>>>> Date: Mon, 5 Jul 2010 16:50:00 -0400 > > >>>>>> To: jay.krell at cornell.edu > > >>>>>> CC: m3commit at elegosoft.com > > >>>>>> Subject: Re: [M3commit] CVS Update: cm3 > > >>>>>> > > >>>>>> But we've been this route before. Modula-3 ensures every variable is initialised with a valid value. I don't see how your adding an initialiser makes it more obviously correct. > > >>>>>> > > >>>>>> On 5 Jul 2010, at 16:45, Jay K wrote: > > >>>>>> > > >>>>>>> > > >>>>>>> I will maybe see about doing better here. > > >>>>>>> Initializing locals doesn't seem like such a bad change though. > > >>>>>>> I like the code to be "obviously correct" by a quick read by a human. > > >>>>>>> > > >>>>>>> - Jay > > >>>>>>> > > >>>>>>> ---------------------------------------- > > >>>>>>>> From: hosking at cs.purdue.edu > > >>>>>>>> Date: Mon, 5 Jul 2010 14:31:01 -0400 > > >>>>>>>> To: jkrell at elego.de > > >>>>>>>> CC: m3commit at elegosoft.com > > >>>>>>>> Subject: Re: [M3commit] CVS Update: cm3 > > >>>>>>>> > > >>>>>>>> Jay, I am perplexed that we are adding things to Modula-3 source because of compiler backend brokenness just to avoid back-end warnings. Better to fix the backend so that RAISE is noreturn. This should not be difficult to do. > > >>>>>>>> > > >>>>>>>> On 5 Jul 2010, at 15:22, Jay Krell wrote: > > >>>>>>>> > > >>>>>>>>> CVSROOT: /usr/cvs > > >>>>>>>>> Changes by: jkrell at birch. 10/07/05 15:22:28 > > >>>>>>>>> > > >>>>>>>>> Modified files: > > >>>>>>>>> cm3/m3-tools/cvsup/suplib/src/text_cm3/: SupMiscText.m3 > > >>>>>>>>> > > >>>>>>>>> Log message: > > >>>>>>>>> ../src/text_cm3/SupMiscText.m3: In function 'SupMisc__DecodeWS': > > >>>>>>>>> ../src/text_cm3/SupMiscText.m3:211: warning: 'M3_Bkn9rd_ch' may be used uninitialized in this function > > >>>>>>>>> ../src/text_cm3/SupMiscText.m3:211: note: 'M3_Bkn9rd_ch' was declared here > > >>>>>>>>> > > >>>>>>>>> because raising an exception isn't currently "noreturn" > > >>>>>>>>> so initialize it to 0 > > >>>>>>>> > > >>>>>>> > > >>>>>> > > >>>>> > > >>>> > > >>> > > >> > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jkrell at elego.de Tue Jul 6 21:36:58 2010 From: jkrell at elego.de (Jay Krell) Date: Tue, 6 Jul 2010 21:36:58 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100706193658.53C752474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/06 21:36:58 Modified files: cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c cm3/m3-sys/m3front/src/exprs/: CastExpr.m3 Log message: allow "ter"/-O3, but without causing compiling CopySign in m3core/src/float/IEEE/RealFloat.m3 to fail to compile: internal compiler error: in convert_move, at expr.c This change might not go far enough though. We might want to call Force() more often. The theory here is, I don't completely know, but that Force() inhibits optimizations done by m3front/src/misc/CG.m3, such as that might remove "taking the address of", which would then inhibit optimizations by the backend. Optimizations are being inhibited here specifically for unsafe code that is casting floats to structures, surely an acceptable small amount of code. In fact, again, consider doing this more. From hosking at elego.de Tue Jul 6 21:40:43 2010 From: hosking at elego.de (Antony Hosking) Date: Tue, 6 Jul 2010 21:40:43 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100706194043.5B9552474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: hosking at birch. 10/07/06 21:40:43 Modified files: cm3/m3-sys/m3front/src/exprs/: CastExpr.m3 Log message: Cleaner. From jay.krell at cornell.edu Tue Jul 6 21:48:44 2010 From: jay.krell at cornell.edu (Jay K) Date: Tue, 6 Jul 2010 19:48:44 +0000 Subject: [M3commit] CVS Update: cm3 In-Reply-To: <20100706194043.5B9552474003@birch.elegosoft.com> References: <20100706194043.5B9552474003@birch.elegosoft.com> Message-ID: Debatable, but ok either way. I don't like the other lines to be duplicated. Granted, only two lines. Er, let's not debate it actually. I'll have the last word, you have the last code. I'll leave it alone. :) If anyone has a solid understanding of what is going on, the comment could be better. The comment is ugly but honest, from my ignorant point of view. ?- Jay ---------------------------------------- > Date: Tue, 6 Jul 2010 21:40:43 +0000 > To: m3commit at elegosoft.com > From: hosking at elego.de > Subject: [M3commit] CVS Update: cm3 > > CVSROOT: /usr/cvs > Changes by: hosking at birch. 10/07/06 21:40:43 > > Modified files: > cm3/m3-sys/m3front/src/exprs/: CastExpr.m3 > > Log message: > Cleaner. > From jay.krell at cornell.edu Tue Jul 6 21:39:20 2010 From: jay.krell at cornell.edu (Jay K) Date: Tue, 6 Jul 2010 19:39:20 +0000 Subject: [M3commit] CVS Update: cm3 In-Reply-To: <20100706193658.53C752474003@birch.elegosoft.com> References: <20100706193658.53C752474003@birch.elegosoft.com> Message-ID: attachments don't seem to be working, we'll see if this is readable.. Index: m3cc/gcc/gcc/m3cg/parse.c =================================================================== RCS file: /usr/cvs/cm3/m3-sys/m3cc/gcc/gcc/m3cg/parse.c,v retrieving revision 1.218 diff -u -r1.218 parse.c --- m3cc/gcc/gcc/m3cg/parse.c??? 5 Jul 2010 22:16:43 -0000??? 1.218 +++ m3cc/gcc/gcc/m3cg/parse.c??? 6 Jul 2010 19:32:16 -0000 @@ -5715,7 +5715,7 @@ ?#endif ???? /*flag_strict_aliasing = 0;*/ /* consider? */ ???? /*flag_strict_overflow = 0;*/ /* consider? */ -??? flag_tree_ter = 0; /* fails to compile m3core CopySign */ +??? /*flag_tree_ter = 0;*/ /* used to break m3core CopySign, see m3front/CastExpr */ ???? /*flag_delete_null_pointer_checks = 0;*/ /* consider? */ ???? /*flag_reorder_functions = 0;*/ /* consider? */ ?? } Index: m3front/src/exprs/CastExpr.m3 =================================================================== RCS file: /usr/cvs/cm3/m3-sys/m3front/src/exprs/CastExpr.m3,v retrieving revision 1.9 diff -u -r1.9 CastExpr.m3 --- m3front/src/exprs/CastExpr.m3??? 5 Jul 2010 11:28:32 -0000??? 1.9 +++ m3front/src/exprs/CastExpr.m3??? 6 Jul 2010 19:32:16 -0000 @@ -10,6 +10,7 @@ ? ?IMPORT M3Buf, CG, Expr, ExprRep, Type, Error, OpenArrayType; ?IMPORT M3, M3ID, M3RT, Target, TInt; +FROM Target IMPORT FloatType; ? ?TYPE ?? Kind = { @@ -394,7 +395,7 @@ ???? u? := Expr.TypeOf (e); ???? t? := p.tipe; ???? sz, t_align, u_align, z_align: INTEGER; -??? u_cg: CG.Type; +??? t_cg, u_cg: CG.Type; ???? u_info, t_info: Type.Info; ?? BEGIN ???? u := Type.CheckInfo (u, u_info); @@ -402,6 +403,7 @@ ???? t_align := t_info.alignment; ???? u_align := u_info.alignment; ???? z_align := MAX (t_align, u_align); +??? t_cg := t_info.stk_type; ???? u_cg := u_info.stk_type; ???? sz := u_info.size; ???? Type.Compile (t); @@ -417,6 +419,21 @@ ???????? Expr.CompileLValue (p.expr, traced); ???????? CG.Boost_alignment (t_align); ? +??????? (* Inhibit some optimization that causes compilation to fail. e.g.: +???????? * m3core/src/float/IEEE/RealFloat.m3: +???????? * In function 'RealFloat__CopySign': +???????? * internal compiler error: in convert_move, at expr.c:371 +???????? * +???????? * ?Force() inhibits optimizations done by m3front/src/misc/CG.m3? +???????? * ?The particular optimizations are removal of address taken and +???????? * pointer indirections? ?Leaving the address taken inhibits +???????? * gcc optimization? ?Given that this is LOOPHOLE and floating point, +???????? * inhibiting optimization is very ok? +???????? *) +??????? IF p.kind = Kind.D_to_S AND (FloatType[t_cg] # FloatType[u_cg]) THEN +????????? CG.Force (); +??????? END; + ???? | Kind.D_to_A, ?????? Kind.S_to_A, ?????? Kind.V_to_A => ---------------------------------------- > Date: Tue, 6 Jul 2010 21:36: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/07/06 21:36:58 > > Modified files: > cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c > cm3/m3-sys/m3front/src/exprs/: CastExpr.m3 > > Log message: > allow "ter"/-O3, but without causing compiling CopySign in > m3core/src/float/IEEE/RealFloat.m3 to fail to compile: > internal compiler error: in convert_move, at expr.c > > This change might not go far enough though. > We might want to call Force() more often. > > The theory here is, I don't completely know, but that Force() > inhibits optimizations done by m3front/src/misc/CG.m3, such > as that might remove "taking the address of", which would > then inhibit optimizations by the backend. > > Optimizations are being inhibited here specifically for > unsafe code that is casting floats to structures, surely > an acceptable small amount of code. In fact, again, consider > doing this more. > From jkrell at elego.de Tue Jul 6 22:58:47 2010 From: jkrell at elego.de (Jay Krell) Date: Tue, 6 Jul 2010 22:58:47 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100706205847.29CA72474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/06 22:58:47 Modified files: cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c cm3/m3-sys/m3back/src/: M3x86.m3 cm3/m3-libs/m3core/src/runtime/common/: RTHooks.i3 RTHooks.m3 RuntimeError.i3 cm3/m3-sys/m3middle/src/: M3CG.i3 Log message: replace a "FIXME" comment with other comments and assertions The code was ok. Line numbers beyond around 100 million are silently truncated, same as it ever was (though the range probably used to be double) From jay.krell at cornell.edu Tue Jul 6 23:00:10 2010 From: jay.krell at cornell.edu (Jay K) Date: Tue, 6 Jul 2010 21:00:10 +0000 Subject: [M3commit] CVS Update: cm3 In-Reply-To: <20100706205847.29CA72474003@birch.elegosoft.com> References: <20100706205847.29CA72474003@birch.elegosoft.com> Message-ID: attached > Date: Tue, 6 Jul 2010 22:58:47 +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/07/06 22:58:47 > > Modified files: > cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c > cm3/m3-sys/m3back/src/: M3x86.m3 > cm3/m3-libs/m3core/src/runtime/common/: RTHooks.i3 RTHooks.m3 > RuntimeError.i3 > cm3/m3-sys/m3middle/src/: M3CG.i3 > > Log message: > replace a "FIXME" comment with other comments and assertions > The code was ok. > Line numbers beyond around 100 million are silently truncated, same as > it ever was (though the range probably used to be double) > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: 32.txt URL: From jkrell at elego.de Wed Jul 7 08:09:47 2010 From: jkrell at elego.de (Jay Krell) Date: Wed, 7 Jul 2010 8:09:47 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100707060947.ECE392474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/07 08:09:47 Modified files: cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c Log message: Allow "all" optimizations now, except flag_unit_at_a_time which fails for a "different" reason, and flag_tree_pre (partial redundancy elmination) only because I missed it since it is a few lines away, will try that shortly. From jkrell at elego.de Wed Jul 7 08:20:57 2010 From: jkrell at elego.de (Jay Krell) Date: Wed, 7 Jul 2010 8:20:57 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100707062057.34A3B2474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/07 08:20:57 Modified files: cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c Log message: partial redundancy elimination ('pre') also crashes compiling libm3/Formatter, add comment; remove all the other stuff about disabling optimizations From jkrell at elego.de Wed Jul 7 13:01:26 2010 From: jkrell at elego.de (Jay Krell) Date: Wed, 7 Jul 2010 13:01:26 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100707110126.C7F0D2474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/07 13:01:26 Modified files: cm3/m3-sys/m3tests/src/: m3makefile Added files: cm3/m3-sys/m3tests/src/p2/p241/: Main.m3 m3makefile Log message: cut down (38 lines) form of libm3/Formatter.m3 that crashes gcc backend if -O3, no volatile, 'ter' From hosking at cs.purdue.edu Wed Jul 7 17:56:30 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Wed, 7 Jul 2010 11:56:30 -0400 Subject: [M3commit] CVS Update: cm3 In-Reply-To: <20100707062057.34A3B2474003@birch.elegosoft.com> References: <20100707062057.34A3B2474003@birch.elegosoft.com> Message-ID: This is new. It used to work! On 7 Jul 2010, at 08:20, Jay Krell wrote: > CVSROOT: /usr/cvs > Changes by: jkrell at birch. 10/07/07 08:20:57 > > Modified files: > cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c > > Log message: > partial redundancy elimination ('pre') also crashes compiling libm3/Formatter, add comment; remove all the other stuff about disabling optimizations From wagner at elego.de Wed Jul 7 19:00:50 2010 From: wagner at elego.de (Olaf Wagner) Date: Wed, 7 Jul 2010 19:00:50 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100707170050.4E8342474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: wagner at birch. 10/07/07 19:00:50 Modified files: cm3/scripts/: Tag: release_branch_cm3_5_8 make-dist.sh Log message: prepare for final release build From jay.krell at cornell.edu Wed Jul 7 21:13:02 2010 From: jay.krell at cornell.edu (Jay K) Date: Wed, 7 Jul 2010 19:13:02 +0000 Subject: [M3commit] CVS Update: cm3 In-Reply-To: References: <20100707062057.34A3B2474003@birch.elegosoft.com>, Message-ID: Back when all loads and stores were volatile! And the optimizer was severely hampered. Any optimized code I looked at was full of unnecessary code. Which do you prefer? ?- Jay ---------------------------------------- > From: hosking at cs.purdue.edu > Date: Wed, 7 Jul 2010 11:56:30 -0400 > To: jkrell at elego.de > CC: m3commit at elegosoft.com > Subject: Re: [M3commit] CVS Update: cm3 > > This is new. It used to work! > > > On 7 Jul 2010, at 08:20, Jay Krell wrote: > > > CVSROOT: /usr/cvs > > Changes by: jkrell at birch. 10/07/07 08:20:57 > > > > Modified files: > > cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c > > > > Log message: > > partial redundancy elimination ('pre') also crashes compiling libm3/Formatter, add comment; remove all the other stuff about disabling optimizations > From hosking at cs.purdue.edu Wed Jul 7 21:59:08 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Wed, 7 Jul 2010 15:59:08 -0400 Subject: [M3commit] CVS Update: cm3 In-Reply-To: References: <20100707062057.34A3B2474003@birch.elegosoft.com>, , , Message-ID: <2E37CD56-4440-4927-936A-8E40B174F488@cs.purdue.edu> We already volatilise as necessary for setjmp/longjmp (at least we did when last I looked, because I remember putting it in). I would prefer to avoid volatile in all other situations where possible. On 7 Jul 2010, at 15:54, Jay K wrote: > > But I admit I'm nervous about removing all the volatile, esp. on stores. > We should have a bunch of tests using exceptions that access locals/parameters in except and finally blocks. > I'm willing to put back volatile on all stores. > Or even loads if there is justification. > > I thought there'd be a setjmp in all functions with try/except/finally, and therefore the same > pessimization, but now I'm not sure of that. > > - Jay > > ---------------------------------------- >> From: jay.krell at cornell.edu >> To: hosking at cs.purdue.edu; jkrell at elego.de >> Date: Wed, 7 Jul 2010 19:13:02 +0000 >> CC: m3commit at elegosoft.com >> Subject: Re: [M3commit] CVS Update: cm3 >> >> >> Back when all loads and stores were volatile! >> And the optimizer was severely hampered. Any optimized code I looked at was full of unnecessary code. >> Which do you prefer? >> >> - Jay >> >> ---------------------------------------- >>> From: hosking at cs.purdue.edu >>> Date: Wed, 7 Jul 2010 11:56:30 -0400 >>> To: jkrell at elego.de >>> CC: m3commit at elegosoft.com >>> Subject: Re: [M3commit] CVS Update: cm3 >>> >>> This is new. It used to work! >>> >>> >>> On 7 Jul 2010, at 08:20, Jay Krell wrote: >>> >>>> CVSROOT: /usr/cvs >>>> Changes by: jkrell at birch. 10/07/07 08:20:57 >>>> >>>> Modified files: >>>> cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c >>>> >>>> Log message: >>>> partial redundancy elimination ('pre') also crashes compiling libm3/Formatter, add comment; remove all the other stuff about disabling optimizations >>> >> > From jay.krell at cornell.edu Wed Jul 7 21:54:53 2010 From: jay.krell at cornell.edu (Jay K) Date: Wed, 7 Jul 2010 19:54:53 +0000 Subject: [M3commit] CVS Update: cm3 In-Reply-To: References: <20100707062057.34A3B2474003@birch.elegosoft.com>, , , Message-ID: But I admit I'm nervous about removing all the volatile, esp. on stores. We should have a bunch of tests using exceptions that access locals/parameters in except and finally blocks. I'm willing to put back volatile on all stores. Or even loads if there is justification. I thought there'd be a setjmp in all functions with try/except/finally, and therefore the same pessimization, but now I'm not sure of that. ?- Jay ---------------------------------------- > From: jay.krell at cornell.edu > To: hosking at cs.purdue.edu; jkrell at elego.de > Date: Wed, 7 Jul 2010 19:13:02 +0000 > CC: m3commit at elegosoft.com > Subject: Re: [M3commit] CVS Update: cm3 > > > Back when all loads and stores were volatile! > And the optimizer was severely hampered. Any optimized code I looked at was full of unnecessary code. > Which do you prefer? > > - Jay > > ---------------------------------------- > > From: hosking at cs.purdue.edu > > Date: Wed, 7 Jul 2010 11:56:30 -0400 > > To: jkrell at elego.de > > CC: m3commit at elegosoft.com > > Subject: Re: [M3commit] CVS Update: cm3 > > > > This is new. It used to work! > > > > > > On 7 Jul 2010, at 08:20, Jay Krell wrote: > > > > > CVSROOT: /usr/cvs > > > Changes by: jkrell at birch. 10/07/07 08:20:57 > > > > > > Modified files: > > > cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c > > > > > > Log message: > > > partial redundancy elimination ('pre') also crashes compiling libm3/Formatter, add comment; remove all the other stuff about disabling optimizations > > > From jay.krell at cornell.edu Wed Jul 7 22:14:49 2010 From: jay.krell at cornell.edu (Jay K) Date: Wed, 7 Jul 2010 20:14:49 +0000 Subject: [M3commit] CVS Update: cm3 In-Reply-To: <2E37CD56-4440-4927-936A-8E40B174F488@cs.purdue.edu> References: <20100707062057.34A3B2474003@birch.elegosoft.com>, , , , , , , <2E37CD56-4440-4927-936A-8E40B174F488@cs.purdue.edu> Message-ID: That's still there, for "returns twice", like setjmp, fork and/or vfork. Not sure about longjmp. Not sure if it is adequate. ?? I saw PushFrame in the crashing example but I don't think I saw setjmp. Not sure about a few things. ?- Jay ---------------------------------------- > From: hosking at cs.purdue.edu > Date: Wed, 7 Jul 2010 15:59:08 -0400 > To: jay.krell at cornell.edu > CC: m3commit at elegosoft.com > Subject: Re: [M3commit] CVS Update: cm3 > > We already volatilise as necessary for setjmp/longjmp (at least we did when last I looked, because I remember putting it in). > > I would prefer to avoid volatile in all other situations where possible. > > > On 7 Jul 2010, at 15:54, Jay K wrote: > > > > > But I admit I'm nervous about removing all the volatile, esp. on stores. > > We should have a bunch of tests using exceptions that access locals/parameters in except and finally blocks. > > I'm willing to put back volatile on all stores. > > Or even loads if there is justification. > > > > I thought there'd be a setjmp in all functions with try/except/finally, and therefore the same > > pessimization, but now I'm not sure of that. > > > > - Jay > > > > ---------------------------------------- > >> From: jay.krell at cornell.edu > >> To: hosking at cs.purdue.edu; jkrell at elego.de > >> Date: Wed, 7 Jul 2010 19:13:02 +0000 > >> CC: m3commit at elegosoft.com > >> Subject: Re: [M3commit] CVS Update: cm3 > >> > >> > >> Back when all loads and stores were volatile! > >> And the optimizer was severely hampered. Any optimized code I looked at was full of unnecessary code. > >> Which do you prefer? > >> > >> - Jay > >> > >> ---------------------------------------- > >>> From: hosking at cs.purdue.edu > >>> Date: Wed, 7 Jul 2010 11:56:30 -0400 > >>> To: jkrell at elego.de > >>> CC: m3commit at elegosoft.com > >>> Subject: Re: [M3commit] CVS Update: cm3 > >>> > >>> This is new. It used to work! > >>> > >>> > >>> On 7 Jul 2010, at 08:20, Jay Krell wrote: > >>> > >>>> CVSROOT: /usr/cvs > >>>> Changes by: jkrell at birch. 10/07/07 08:20:57 > >>>> > >>>> Modified files: > >>>> cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c > >>>> > >>>> Log message: > >>>> partial redundancy elimination ('pre') also crashes compiling libm3/Formatter, add comment; remove all the other stuff about disabling optimizations > >>> > >> > > > From jay.krell at cornell.edu Wed Jul 7 22:19:48 2010 From: jay.krell at cornell.edu (Jay K) Date: Wed, 7 Jul 2010 20:19:48 +0000 Subject: [M3commit] CVS Update: cm3 In-Reply-To: References: <20100707062057.34A3B2474003@birch.elegosoft.com>, , , , , , , , <2E37CD56-4440-4927-936A-8E40B174F488@cs.purdue.edu>, Message-ID: ps: obviously the volatization that is there is overkill, but not too far off. We only really need to volatize what is used in the except/finally blocks. It might be a closer approximation to add volatile to anything referenced in the function after we see the setjmp/fork call, instead of going and visiting all current and future locals. Even that is overkill. I assume making the load/stores volatile is the same as making the variables volatile. ?So there are other similar approaches. However I assume one dumb difference, evidenced by what you already did, is that the warnings vary. The compiler doesn't notice, I guess, that if all load/stores to a variable are volatile, then the variable itself is effectively volatile. Anyway, ok for now. Hm, maybe m3cg should offer volatile as a flag on parameters, locals, temporaries? I'm not sure the backend knows where except/finally blocks are, after all. This isn't the "make function volatile" thing I had, this is something narrower and seems like it might fit better...except, well..volatile is maybe an implementation detail. But you could just rename and get the same thing: "variable accessed in except/finally block". Or, "start except block", "start finally block", "end except block", "end finally block". ? ?- Jay ---------------------------------------- > From: jay.krell at cornell.edu > To: hosking at cs.purdue.edu > CC: m3commit at elegosoft.com > Subject: RE: [M3commit] CVS Update: cm3 > Date: Wed, 7 Jul 2010 20:14:49 +0000 > > > That's still there, for "returns twice", like setjmp, fork and/or vfork. > Not sure about longjmp. > Not sure if it is adequate. > I saw PushFrame in the crashing example but I don't think I saw setjmp. > Not sure about a few things. > > - Jay > > > ---------------------------------------- > > From: hosking at cs.purdue.edu > > Date: Wed, 7 Jul 2010 15:59:08 -0400 > > To: jay.krell at cornell.edu > > CC: m3commit at elegosoft.com > > Subject: Re: [M3commit] CVS Update: cm3 > > > > We already volatilise as necessary for setjmp/longjmp (at least we did when last I looked, because I remember putting it in). > > > > I would prefer to avoid volatile in all other situations where possible. > > > > > > On 7 Jul 2010, at 15:54, Jay K wrote: > > > > > > > > But I admit I'm nervous about removing all the volatile, esp. on stores. > > > We should have a bunch of tests using exceptions that access locals/parameters in except and finally blocks. > > > I'm willing to put back volatile on all stores. > > > Or even loads if there is justification. > > > > > > I thought there'd be a setjmp in all functions with try/except/finally, and therefore the same > > > pessimization, but now I'm not sure of that. > > > > > > - Jay > > > > > > ---------------------------------------- > > >> From: jay.krell at cornell.edu > > >> To: hosking at cs.purdue.edu; jkrell at elego.de > > >> Date: Wed, 7 Jul 2010 19:13:02 +0000 > > >> CC: m3commit at elegosoft.com > > >> Subject: Re: [M3commit] CVS Update: cm3 > > >> > > >> > > >> Back when all loads and stores were volatile! > > >> And the optimizer was severely hampered. Any optimized code I looked at was full of unnecessary code. > > >> Which do you prefer? > > >> > > >> - Jay > > >> > > >> ---------------------------------------- > > >>> From: hosking at cs.purdue.edu > > >>> Date: Wed, 7 Jul 2010 11:56:30 -0400 > > >>> To: jkrell at elego.de > > >>> CC: m3commit at elegosoft.com > > >>> Subject: Re: [M3commit] CVS Update: cm3 > > >>> > > >>> This is new. It used to work! > > >>> > > >>> > > >>> On 7 Jul 2010, at 08:20, Jay Krell wrote: > > >>> > > >>>> CVSROOT: /usr/cvs > > >>>> Changes by: jkrell at birch. 10/07/07 08:20:57 > > >>>> > > >>>> Modified files: > > >>>> cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c > > >>>> > > >>>> Log message: > > >>>> partial redundancy elimination ('pre') also crashes compiling libm3/Formatter, add comment; remove all the other stuff about disabling optimizations > > >>> > > >> > > > > > > From jkrell at elego.de Thu Jul 8 12:20:41 2010 From: jkrell at elego.de (Jay Krell) Date: Thu, 8 Jul 2010 12:20:41 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100708102041.CFC6C2474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/08 12:20:41 Modified files: cm3/m3-sys/m3cc/src/: m3makefile Log message: no actual change but commented out or disabled: append -4.3 to build_dir for 4.3 commented out configure -enable-checking=all (we should make this work) disabled switching to 4.5 for AMD64_DARWIN (should make this work, maybe the pointer use in loophole will help?) From jkrell at elego.de Fri Jul 9 10:04:30 2010 From: jkrell at elego.de (Jay Krell) Date: Fri, 9 Jul 2010 10:04:30 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100709080430.AA1DE2474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/09 10:04:30 Modified files: cm3/scripts/python/: pylib.py Log message: add mspdb100.dll to list -- support for Visual C++ 2010 From jkrell at elego.de Fri Jul 9 10:52:20 2010 From: jkrell at elego.de (Jay Krell) Date: Fri, 9 Jul 2010 10:52:20 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100709085220.CFCAF2474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/09 10:52:20 Modified files: cm3/scripts/python/: Tag: release_branch_cm3_5_8 pylib.py Log message: support for Visual Studio 2010 From jkrell at elego.de Fri Jul 9 13:58:39 2010 From: jkrell at elego.de (Jay Krell) Date: Fri, 9 Jul 2010 13:58:39 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100709115841.8F54B2474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/09 13:58:38 Modified files: cm3/m3-sys/m3front/src/misc/: Scanner.m3 Log message: go back a version, to 1.11; 1.12 causes major problems, presumably it confuses 'word' and 'Word' or something From hosking at elego.de Fri Jul 9 17:09:49 2010 From: hosking at elego.de (Antony Hosking) Date: Fri, 9 Jul 2010 17:09:49 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100709150949.B91DA2474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: hosking at birch. 10/07/09 17:09:49 Modified files: cm3/m3-sys/m3front/src/misc/: Scanner.m3 Log message: No need for extra variable. From jkrell at elego.de Sat Jul 10 13:36:41 2010 From: jkrell at elego.de (Jay Krell) Date: Sat, 10 Jul 2010 13:36:41 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100710113641.697742474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/10 13:36:41 Modified files: cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c Log message: DECL_NONLOCAL in gcc 4.5 to try to mimic x_nonlocal_goto_handler_labels causes harm, detailed in the comments in the code here (needs further investigation) From jkrell at elego.de Sat Jul 10 14:27:27 2010 From: jkrell at elego.de (Jay Krell) Date: Sat, 10 Jul 2010 14:27:27 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100710122727.55F712474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/10 14:27:27 Modified files: cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c Log message: use POINTER_PLUS with gcc 4.3 same as with gcc 4.5 volatilize any function that calls RTHooks__PushEFrame Therefore enabling "pre" optimization (partial redundancy elimination?) This would probably be cleaner in a few other ways: investigate further why gcc doesn't like the trees we produce for this case have a direct call in the middle end: volatilize_current_function understand (at least) the two variants of try/finally don't volatilize all variables In my one test case though, the finally block doesn't access anything, so only volatilizing what is needed would set us back to really having to understand. And, really, volatile even of certain variables is overkill. You just want be sure they are "homed" prior to function calls that can throw, not at every single use and not before function calls that can't throw. From jay.krell at cornell.edu Sat Jul 10 14:29:43 2010 From: jay.krell at cornell.edu (Jay K) Date: Sat, 10 Jul 2010 12:29:43 +0000 Subject: [M3commit] CVS Update: cm3 In-Reply-To: <20100710122727.55F712474003@birch.elegosoft.com> References: <20100710122727.55F712474003@birch.elegosoft.com> Message-ID: not great but maybe ok for the time being, for a while.. ---------------------------------------- > Date: Sat, 10 Jul 2010 14:27: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/07/10 14:27:27 > > Modified files: > cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c > > Log message: > use POINTER_PLUS with gcc 4.3 same as with gcc 4.5 > volatilize any function that calls RTHooks__PushEFrame > Therefore enabling "pre" optimization (partial redundancy elimination?) > This would probably be cleaner in a few other ways: > investigate further why gcc doesn't like the trees we produce for this case > have a direct call in the middle end: volatilize_current_function > understand (at least) the two variants of try/finally > don't volatilize all variables > In my one test case though, the finally block doesn't > access anything, so only volatilizing what is needed > would set us back to really having to understand. > > And, really, volatile even of certain variables is overkill. > You just want be sure they are "homed" prior to function > calls that can throw, not at every single use and not > before function calls that can't throw. > -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: pushframe.txt URL: From jkrell at elego.de Sat Jul 10 14:31:54 2010 From: jkrell at elego.de (Jay Krell) Date: Sat, 10 Jul 2010 14:31:54 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100710123154.8F9D8CC37F@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/10 14:31:54 Modified files: cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c Log message: don't check for pushframe if we are making all load/store volatile From jay.krell at cornell.edu Sat Jul 10 14:35:11 2010 From: jay.krell at cornell.edu (Jay K) Date: Sat, 10 Jul 2010 12:35:11 +0000 Subject: [M3commit] CVS Update: cm3 In-Reply-To: References: <20100710122727.55F712474003@birch.elegosoft.com>, Message-ID: Drat, this doesn't let it work across the whole tree.. new source -> compiling m3totex.m3 ../src/m3totex.m3: In function 'm3totex__Undisplay': ../src/m3totex.m3:210: internal compiler error: in remove_phi_node, at tree-phinodes.c:465 Please submit a full bug report, with preprocessed source if appropriate. See for instructions. ? m3_backend => 4 m3cc (aka cm3cg) failed compiling: m3totex.mc compilation failed => not building program "m3totex" Fatal Error: package build failed ?*** execution of [, ] failed *** (normally this would SIGSEGV but I put assertions in) ---------------------------------------- > From: jay.krell at cornell.edu > To: jkrell at elego.de; m3commit at elegosoft.com > Date: Sat, 10 Jul 2010 12:29:43 +0000 > Subject: Re: [M3commit] CVS Update: cm3 > > > not great but maybe ok for the time being, for a while.. > > ---------------------------------------- > > Date: Sat, 10 Jul 2010 14:27: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/07/10 14:27:27 > > > > Modified files: > > cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c > > > > Log message: > > use POINTER_PLUS with gcc 4.3 same as with gcc 4.5 > > volatilize any function that calls RTHooks__PushEFrame > > Therefore enabling "pre" optimization (partial redundancy elimination?) > > This would probably be cleaner in a few other ways: > > investigate further why gcc doesn't like the trees we produce for this case > > have a direct call in the middle end: volatilize_current_function > > understand (at least) the two variants of try/finally > > don't volatilize all variables > > In my one test case though, the finally block doesn't > > access anything, so only volatilizing what is needed > > would set us back to really having to understand. > > > > And, really, volatile even of certain variables is overkill. > > You just want be sure they are "homed" prior to function > > calls that can throw, not at every single use and not > > before function calls that can't throw. > > > From jkrell at elego.de Sat Jul 10 15:37:59 2010 From: jkrell at elego.de (Jay Krell) Date: Sat, 10 Jul 2010 15:37:59 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100710133759.40A32CC37E@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/10 15:37:59 Modified files: cm3/m3-sys/m3cc/gcc/gcc/m3cg/: m3gty43.h m3gty45.h parse.c Log message: Try something similar/different: in functions that call pushframe, turn off flag_tree_pre That is: save flag_tree_pre away in begin_procedure if we see call pushframe, set flag_tree_pre = 0 restore flag_tree_pre in end_procedure This depends on that curently we compile unit at a time.. which is the "last" optimization to deal with..except this dependency makes "pre" being sometimes enabled dependant on it...so..ultimately..this "fix" probably can't stand. If unit at a time can be fixed soon/easily, re-disable pre and investigate further the problem with try/finally.. From jay.krell at cornell.edu Sat Jul 10 15:38:59 2010 From: jay.krell at cornell.edu (Jay K) Date: Sat, 10 Jul 2010 13:38:59 +0000 Subject: [M3commit] CVS Update: cm3 In-Reply-To: <20100710133759.40A32CC37E@birch.elegosoft.com> References: <20100710133759.40A32CC37E@birch.elegosoft.com> Message-ID: really not great...but it'll take a much deeper investigation to fix this... ---------------------------------------- > Date: Sat, 10 Jul 2010 15:37: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/07/10 15:37:59 > > Modified files: > cm3/m3-sys/m3cc/gcc/gcc/m3cg/: m3gty43.h m3gty45.h parse.c > > Log message: > Try something similar/different: > in functions that call pushframe, turn off flag_tree_pre > > That is: > save flag_tree_pre away in begin_procedure > if we see call pushframe, set flag_tree_pre = 0 > restore flag_tree_pre in end_procedure > > This depends on that curently we compile unit at a time.. > which is the "last" optimization to deal with..except > this dependency makes "pre" being sometimes enabled > dependant on it...so..ultimately..this "fix" probably > can't stand. > > If unit at a time can be fixed soon/easily, re-disable > pre and investigate further the problem with try/finally.. > -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: pushframe2.txt URL: From jkrell at elego.de Sun Jul 11 08:36:41 2010 From: jkrell at elego.de (Jay Krell) Date: Sun, 11 Jul 2010 8:36:41 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100711063641.492EF2474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/11 08:36:41 Added files: cm3/m3-sys/m3tests/src/p2/p242/: Main.m3 m3makefile Log message: add test case reduced from m3totex that crashes in gcc backend if 'pre' is enabled (unless maybe if everything is volatile) From jay.krell at cornell.edu Sun Jul 11 08:45:49 2010 From: jay.krell at cornell.edu (Jay K) Date: Sun, 11 Jul 2010 06:45:49 +0000 Subject: [M3commit] CVS Update: cm3 In-Reply-To: <20100711063641.492EF2474003@birch.elegosoft.com> References: <20100711063641.492EF2474003@birch.elegosoft.com> Message-ID: Strange cvs behavior. m3tests/src/m3makefile did get edited too. ?- Jay ---------------------------------------- > Date: Sun, 11 Jul 2010 08:36: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/07/11 08:36:41 > > Added files: > cm3/m3-sys/m3tests/src/p2/p242/: Main.m3 m3makefile > > Log message: > add test case reduced from m3totex that crashes in gcc > backend if 'pre' is enabled (unless maybe if everything > is volatile) > From jkrell at elego.de Sun Jul 11 08:55:30 2010 From: jkrell at elego.de (Jay Krell) Date: Sun, 11 Jul 2010 8:55:30 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100711065530.B35ECCC382@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/11 08:55:30 Modified files: cm3/m3-sys/m3tests/src/: m3makefile Added files: cm3/m3-sys/m3tests/src/p2/p243/: Main.m3 m3makefile Log message: add test case that fails to compile when gcc backend compiles "unit at a time" because nested functions aren't preserved From jkrell at elego.de Sun Jul 11 09:37:21 2010 From: jkrell at elego.de (Jay Krell) Date: Sun, 11 Jul 2010 9:37:21 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100711073722.3335C2474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/11 09:37:21 Modified files: cm3/m3-sys/m3cc/gcc/gcc/m3cg/: m3gty43.h m3gty45.h parse.c Log message: more tracing: quoted_string just leave 'pre' off all the time, for now What i had was sort of better, pre on sometimes, but also kind of yucky. From jkrell at elego.de Sun Jul 11 10:13:08 2010 From: jkrell at elego.de (Jay Krell) Date: Sun, 11 Jul 2010 10:13:08 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100711081308.F189CCC389@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/11 10:13:08 Modified files: cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c Log message: mark nested functions as "public", so that unit at a time doesn't remove them Still, "public" isn't so bad, they are still "hidden" on platforms that support that. (That is, they are accessible from within the .so but not exported to outside it.) From jkrell at elego.de Sun Jul 11 10:15:24 2010 From: jkrell at elego.de (Jay Krell) Date: Sun, 11 Jul 2010 10:15:24 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100711081524.E688A2474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/11 10:15:24 Modified files: cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c Log message: edit the comment about making all functions 'public' From jay.krell at cornell.edu Sun Jul 11 10:31:47 2010 From: jay.krell at cornell.edu (Jay K) Date: Sun, 11 Jul 2010 08:31:47 +0000 Subject: [M3commit] CVS Update: cm3 In-Reply-To: <20100711073722.3335C2474003@birch.elegosoft.com> References: <20100711073722.3335C2474003@birch.elegosoft.com> Message-ID: In 4.5 (or 4.4) we can selectively deoptimize functions using underlying infrastructure. ?- Jay ---------------------------------------- > Date: Sun, 11 Jul 2010 09:37:21 +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/07/11 09:37:21 > > Modified files: > cm3/m3-sys/m3cc/gcc/gcc/m3cg/: m3gty43.h m3gty45.h parse.c > > Log message: > more tracing: quoted_string > just leave 'pre' off all the time, for now > What i had was sort of better, pre on sometimes, but also > kind of yucky. > From jkrell at elego.de Sun Jul 11 10:53:01 2010 From: jkrell at elego.de (Jay Krell) Date: Sun, 11 Jul 2010 10:53:01 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100711085301.8CE27CC389@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/11 10:53:01 Modified files: cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c Log message: TREE_PUBLIC (p) = ((lev == 0) || flag_unit_at_a_time); instead of just 1 From jkrell at elego.de Sun Jul 11 11:05:50 2010 From: jkrell at elego.de (Jay Krell) Date: Sun, 11 Jul 2010 11:05:50 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100711090550.6E1B92474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/11 11:05:50 Modified files: cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c Log message: in the gcc 4.2 (and maybe 4.5) don't bother with the add if adding zero From jkrell at elego.de Sun Jul 11 11:19:09 2010 From: jkrell at elego.de (Jay Krell) Date: Sun, 11 Jul 2010 11:19:09 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100711091909.312D4CC37F@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/11 11:19:09 Modified files: cm3/m3-sys/m3tests/src/p2/p240/expected/AMD64_DARWIN/: A.ms divmod_pow2.ms Log message: update (esp. with removal of div/mod functions, the the result at least when not optimized is much larger) From jkrell at elego.de Sun Jul 11 11:23:29 2010 From: jkrell at elego.de (Jay Krell) Date: Sun, 11 Jul 2010 11:23:29 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100711092329.C25BF2474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/11 11:23:29 Modified files: cm3/m3-sys/m3tests/src/p2/p240/: m3makefile Log message: whitespace From jkrell at elego.de Sun Jul 11 11:50:59 2010 From: jkrell at elego.de (Jay Krell) Date: Sun, 11 Jul 2010 11:50:59 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100711095100.276A22474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/11 11:50:59 Modified files: cm3/m3-sys/m3tests/src/p2/p240/: m3makefile cm3/m3-sys/m3tests/src/p2/p240/expected/AMD64_DARWIN/: bitfield.ms extract.ms insert.ms Added files: cm3/m3-sys/m3tests/src/p2/p240/expected/AMD64_DARWIN/: And.ms Divide.ms EQ.ms GE.ms GT.ms LE.ms LT.ms LeftRotate.ms LeftShift.ms Minus.ms Mod.ms NE.ms Not.ms Or.ms Plus.ms RightRotate.ms RightShift.ms Rotate.ms Shift.ms Times.ms Xor.ms div_pow2.ms extract_constant_both.ms extract_constant_count.ms extract_constant_offset.ms insert_constant_both.ms insert_constant_count.ms insert_constant_offset.ms mod_pow2.ms return_constant.ms return_parameter.ms return_parameter_convert.ms return_variable.ms Log message: split up into more files (too many?) From jkrell at elego.de Sun Jul 11 12:51:00 2010 From: jkrell at elego.de (Jay Krell) Date: Sun, 11 Jul 2010 12:51:00 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100711105100.D1AB9CC37F@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/11 12:51:00 Modified files: cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c Log message: disable 'fre' for gcc 4.5, it crashes From jkrell at elego.de Sun Jul 11 12:52:59 2010 From: jkrell at elego.de (Jay Krell) Date: Sun, 11 Jul 2010 12:52:59 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100711105300.09B6D2474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/11 12:52:59 Modified files: cm3/m3-sys/m3tests/src/: m3makefile Added files: cm3/m3-sys/m3tests/src/p2/p244/: Main.m3 m3makefile Log message: add a case that crashes gcc 4.5 backend if 'fre' enabled (this reduced from something in p240 I was looking at; p240 always disables optimizations, until such time as we expand the test framework to iterate through various optimization options..) From jkrell at elego.de Sun Jul 11 12:55:21 2010 From: jkrell at elego.de (Jay Krell) Date: Sun, 11 Jul 2010 12:55:21 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100711105521.ECB9D2474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/11 12:55:21 Modified files: cm3/m3-sys/m3tests/src/p2/p244/: m3makefile Log message: make sure optimization is enabled From jkrell at elego.de Sun Jul 11 13:06:03 2010 From: jkrell at elego.de (Jay Krell) Date: Sun, 11 Jul 2010 13:06:03 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100711110603.B28A12474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/11 13:06:03 Modified files: cm3/m3-sys/m3tests/src/p2/p240/expected/AMD64_DARWIN/: And.ms Divide.ms EQ.ms GE.ms GT.ms LE.ms LT.ms LeftRotate.ms LeftShift.ms Minus.ms Mod.ms NE.ms Not.ms Or.ms Plus.ms RightRotate.ms RightShift.ms Rotate.ms Shift.ms Times.ms Xor.ms bitfield.ms div_pow2.ms extract.ms extract_constant_both.ms extract_constant_count.ms extract_constant_offset.ms insert.ms insert_constant_both.ms insert_constant_count.ms insert_constant_offset.ms mod_pow2.ms return_constant.ms return_parameter.ms return_parameter_convert.ms return_variable.ms Log message: update: I don't know why, but maybe I commited out of date versions before? Here the main change seems just reordering functions. From jkrell at elego.de Sun Jul 11 13:19:35 2010 From: jkrell at elego.de (Jay Krell) Date: Sun, 11 Jul 2010 13:19:35 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100711111935.6C3B8CC37F@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/11 13:19:35 Modified files: cm3/m3-sys/m3cc/gcc-4.5/gcc/: gimplify.c Log message: put the #if 1 back to #ifdef ENABLE_TYPES_CHECKING, though this area still needs work From jkrell at elego.de Sun Jul 11 13:58:02 2010 From: jkrell at elego.de (Jay Krell) Date: Sun, 11 Jul 2010 13:58:02 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100711115802.927FE2474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/11 13:58:02 Modified files: cm3/m3-sys/m3tests/src/p2/p244/: Main.m3 Log message: fix comment: the original problem I was looking at was due to functions being out of order and I was comparin them wrong, but this test case remains useful as a crasher for gcc 4.5 'fre' From jkrell at elego.de Sun Jul 11 14:39:59 2010 From: jkrell at elego.de (Jay Krell) Date: Sun, 11 Jul 2010 14:39:59 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100711123959.955122474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/11 14:39:59 Modified files: cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c Log message: gcc 4.5 -O1 and -O2 seem ok but some of the -O3 passes fail: flag_predictive_commoning flag_ipa_cp_clone flag_inline_functions is not optimizing for size Failures generally seen compiling m3-libs/sysutils/System.m3. As well 'pre' which has problems in 4.3 also has problems in 4.5, problems seen compiling m3front. And 'fre' already disabled (see test p244). From jkrell at elego.de Sun Jul 11 15:14:53 2010 From: jkrell at elego.de (Jay Krell) Date: Sun, 11 Jul 2010 15:14:53 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100711131453.72F102474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/11 15:14:53 Modified files: cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c Log message: fix the -Wc++-compat warnings/errors you see if using newer gcc class => clas int => enum and the "poison" thing, not sure why it appears on some machines and not others, could again be different gcc version From jkrell at elego.de Mon Jul 12 00:32:00 2010 From: jkrell at elego.de (Jay Krell) Date: Mon, 12 Jul 2010 0:32:00 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100711223201.000432474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/12 00:32:00 Modified files: cm3/m3-sys/m3cc/gcc-4.5/gcc/: targhooks.c Log message: allow NULL fndecl in default_static_chain (I already did this in the x86-specific hook, need to check for others, this was SIGSEVing on SOLgnu) From jkrell at elego.de Mon Jul 12 00:34:59 2010 From: jkrell at elego.de (Jay Krell) Date: Mon, 12 Jul 2010 0:34:59 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100711223459.F01262474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/12 00:34:59 Modified files: cm3/m3-sys/m3cc/gcc-4.5/gcc/config/moxie/: moxie.c Log message: allow NULL fndecl in moxie_static_chain From jkrell at elego.de Mon Jul 12 00:50:34 2010 From: jkrell at elego.de (Jay Krell) Date: Mon, 12 Jul 2010 0:50:34 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100711225035.15E2E2474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/12 00:50:34 Modified files: cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c Log message: gcc 4.5: mark barrier labels rtx with LABEL_REF_NONLOCAL_P, does it help/matter? From jkrell at elego.de Mon Jul 12 01:39:14 2010 From: jkrell at elego.de (Jay Krell) Date: Mon, 12 Jul 2010 1:39:14 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100711233914.8CBA02474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/12 01:39:14 Modified files: cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c Log message: hm LABEL_REF_NONLOCAL_P I thought had helped maybe on I386_LINUX and SOLgnu but it clearly hurts on AMD64_DARWIN From jkrell at elego.de Mon Jul 12 04:25:25 2010 From: jkrell at elego.de (Jay Krell) Date: Mon, 12 Jul 2010 4:25:25 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100712022526.767D12474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/12 04:25:25 Modified files: cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c Log message: gcc 4.5: turn off all inlining: m3-sys/m3cc/AMD64_DARWIN-SOLgnu/cm3cg -quiet -O3 m3core/SOLgnu/Poly.mc fingerprint/Poly.m3: In function 'Poly__FromBytes': fingerprint/Poly.m3:379:0: internal compiler error: in referenced_var_lookup, at tree-dfa.c:519 From jay.krell at cornell.edu Mon Jul 12 04:40:37 2010 From: jay.krell at cornell.edu (Jay K) Date: Mon, 12 Jul 2010 02:40:37 +0000 Subject: [M3commit] CVS Update: cm3 In-Reply-To: <20100712022526.767D12474003@birch.elegosoft.com> References: <20100712022526.767D12474003@birch.elegosoft.com> Message-ID: This is unfortunate. ---------------------------------------- > Date: Mon, 12 Jul 2010 04:25:25 +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/07/12 04:25:25 > > Modified files: > cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c > > Log message: > gcc 4.5: turn off all inlining: > m3-sys/m3cc/AMD64_DARWIN-SOLgnu/cm3cg -quiet -O3 m3core/SOLgnu/Poly.mc > fingerprint/Poly.m3: In function 'Poly__FromBytes': > fingerprint/Poly.m3:379:0: internal compiler error: > in referenced_var_lookup, at tree-dfa.c:519 > From jkrell at elego.de Mon Jul 12 11:08:00 2010 From: jkrell at elego.de (Jay Krell) Date: Mon, 12 Jul 2010 11:08:00 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100712090800.443892474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/12 11:08:00 Modified files: cm3/m3-sys/m3tests/src/: m3makefile Added files: cm3/m3-sys/m3tests/src/p2/p245/: Main.m3 m3makefile Log message: test case reduced from m3core/TextConv.m3 that gives: internal compiler error: in estimate_move_cost, at tree-inline.c:3016 when gcc 4.5 does inlining The assertion is that the type isn't void. The problem seems related to the set of char, but we'll see. From jkrell at elego.de Mon Jul 12 11:14:40 2010 From: jkrell at elego.de (Jay Krell) Date: Mon, 12 Jul 2010 11:14:40 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100712091440.4BFA92474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/12 11:14:40 Modified files: cm3/m3-sys/m3tests/src/p2/p245/: Main.m3 Log message: slightly different/smaller From jkrell at elego.de Mon Jul 12 11:46:41 2010 From: jkrell at elego.de (Jay Krell) Date: Mon, 12 Jul 2010 11:46:41 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100712094641.5886E2474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/12 11:46:41 Modified files: cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c Log message: represent sets as a pointer to a word, not an untyped pointer This seems fixes inlining on AMD64_DARWIN (more testing being done, including of SOLgnu). This was my fault: the old code to call functions didn't have to worry about the types of sets, because it didn't dereference them.. From jkrell at elego.de Mon Jul 12 12:14:13 2010 From: jkrell at elego.de (Jay Krell) Date: Mon, 12 Jul 2010 12:14:13 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100712101413.8FD042474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/12 12:14:13 Modified files: cm3/m3-sys/m3tests/src/: m3makefile Added files: cm3/m3-sys/m3tests/src/p2/p246/: Main.m3 m3makefile Log message: gcc 4.5 assertion failure inlining in Poly.m3 for SOLgnu From jkrell at elego.de Mon Jul 12 13:14:02 2010 From: jkrell at elego.de (Jay Krell) Date: Mon, 12 Jul 2010 13:14:02 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100712111402.DA96E2474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/12 13:14:02 Modified files: cm3/m3-sys/cminstall/src/config-no-install/: I386.common Log message: don't mess with preferred-stack-boundary, it makes me nervouse From jkrell at elego.de Mon Jul 12 13:16:13 2010 From: jkrell at elego.de (Jay Krell) Date: Mon, 12 Jul 2010 13:16:13 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100712111613.7C0802474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/12 13:16:13 Modified files: cm3/m3-sys/cminstall/src/config-no-install/: cm3cfg.common Log message: move comment that seemed misplaced From jkrell at elego.de Mon Jul 12 13:17:33 2010 From: jkrell at elego.de (Jay Krell) Date: Mon, 12 Jul 2010 13:17:33 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100712111733.B9E2B2474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/12 13:17:33 Modified files: cm3/m3-sys/cminstall/src/config-no-install/: VMS.common Log message: [] to [ ] so the characters don't run together, depending on font From jkrell at elego.de Mon Jul 12 13:21:45 2010 From: jkrell at elego.de (Jay Krell) Date: Mon, 12 Jul 2010 13:21:45 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100712112145.C54702474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/12 13:21:45 Modified files: cm3/m3-sys/cminstall/src/config-no-install/: PPC_LINUX Log message: fix typo in comment From jkrell at elego.de Mon Jul 12 13:28:00 2010 From: jkrell at elego.de (Jay Krell) Date: Mon, 12 Jul 2010 13:28:00 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100712112800.C1E5C2474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/12 13:28:00 Modified files: cm3/m3-sys/cminstall/src/config-no-install/: Interix.common Log message: no change, just commit so I take ownership on CVS server so I can clear the execute attribute, which is often present on files I added from Windows From jkrell at elego.de Mon Jul 12 13:37:49 2010 From: jkrell at elego.de (Jay Krell) Date: Mon, 12 Jul 2010 13:37:49 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100712113749.80AD62474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/12 13:37:49 Modified files: cm3/m3-sys/m3tests/src/: m3makefile cm3/m3-sys/m3tests/src/p2/p246/: Main.m3 Log message: update comments to indicate it also occurs on I386_DARWIN which is fortunate because at least I have a fractionally decent editor there (vs. zero everywhere else, except NT) and my SOLgnu machine is very slow probably all 32bit platforms? There is another problem though that might be SOLgnu specific, not yet reduced to a small case. From jkrell at elego.de Mon Jul 12 14:23:53 2010 From: jkrell at elego.de (Jay Krell) Date: Mon, 12 Jul 2010 14:23:53 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100712122353.4C06C2474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/12 14:23:53 Modified files: cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c Log message: update add_stmt function in minor way to match gcc 4.3/4.5 function of same name in c-decl.c (much of the Modula-3 backend is clearly a clone of the C frontend) From wagner at elego.de Mon Jul 12 21:35:06 2010 From: wagner at elego.de (Olaf Wagner) Date: Mon, 12 Jul 2010 21:35:06 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100712193506.C5BCF2474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: wagner at birch. 10/07/12 21:35:06 Modified files: cm3/www/releng/: Tag: release_branch_cm3_5_8 index.html update-releng-index.sh Log message: final release updates From wagner at elego.de Mon Jul 12 21:38:21 2010 From: wagner at elego.de (Olaf Wagner) Date: Mon, 12 Jul 2010 21:38:21 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100712193821.4740C2474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: wagner at birch. 10/07/12 21:38:21 Modified files: cm3/www/releng/: Tag: release_branch_cm3_5_8 update-releng-index.sh Added files: cm3/www/releng/: Tag: release_branch_cm3_5_8 relnotes-5.8.6.html Log message: final release updates From wagner at elego.de Mon Jul 12 21:42:41 2010 From: wagner at elego.de (Olaf Wagner) Date: Mon, 12 Jul 2010 21:42:41 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100712194241.620C32474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: wagner at birch. 10/07/12 21:42:41 Modified files: cm3/www/releng/: Tag: release_branch_cm3_5_8 update-releng-index.sh Log message: final release updates From wagner at elego.de Mon Jul 12 21:43:48 2010 From: wagner at elego.de (Olaf Wagner) Date: Mon, 12 Jul 2010 21:43:48 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100712194348.E5C672474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: wagner at birch. 10/07/12 21:43:48 Modified files: cm3/www/: Tag: release_branch_cm3_5_8 download.html news.html Log message: final release updates From jkrell at elego.de Tue Jul 13 14:34:28 2010 From: jkrell at elego.de (Jay Krell) Date: Tue, 13 Jul 2010 14:34:28 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100713123428.678CF2474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/13 14:34:28 Modified files: cm3/m3-sys/m3cc/gcc/: configure.ac Log message: experimental: remove freebsd/gmp special case; this is deliberately two separate commits to perhaps manage the timestamps From jkrell at elego.de Tue Jul 13 14:34:44 2010 From: jkrell at elego.de (Jay Krell) Date: Tue, 13 Jul 2010 14:34:44 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100713123444.166542474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/13 14:34:44 Modified files: cm3/m3-sys/m3cc/gcc/: configure Log message: experimental: remove freebsd/gmp special case; this is deliberately two separate commits to perhaps manage the timestamps From jkrell at elego.de Tue Jul 13 15:14:33 2010 From: jkrell at elego.de (Jay Krell) Date: Tue, 13 Jul 2010 15:14:33 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100713131433.579482474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/13 15:14:33 Modified files: cm3/m3-libs/m3core/src/runtime/common/: RTProcessC.c Log message: no pthread_atfork on FreeBSD <= 4 From jkrell at elego.de Tue Jul 13 15:18:23 2010 From: jkrell at elego.de (Jay Krell) Date: Tue, 13 Jul 2010 15:18:23 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100713131825.2D9EA2474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/13 15:18:23 Modified files: cm3/m3-libs/m3core/src/thread/POSIX/: ThreadPosixC.c Log message: try sigaltstack instead of make/get/set/swapcontext on FreeBSD <= 4 From jkrell at elego.de Tue Jul 13 15:22:28 2010 From: jkrell at elego.de (Jay Krell) Date: Tue, 13 Jul 2010 15:22:28 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100713132228.137FC2474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/13 15:22:28 Modified files: cm3/m3-libs/m3core/src/runtime/common/: RTProcessC.c Log message: parens and word-wrap From jkrell at elego.de Tue Jul 13 15:30:13 2010 From: jkrell at elego.de (Jay Krell) Date: Tue, 13 Jul 2010 15:30:13 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100713133013.6A2F6CC37E@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/13 15:30:13 Modified files: cm3/m3-libs/m3core/src/runtime/common/: RTProcessC.c Log message: pthread_atfork added in FreeBSD 5 (this would be a good use of autoconf) From jkrell at elego.de Tue Jul 13 15:30:55 2010 From: jkrell at elego.de (Jay Krell) Date: Tue, 13 Jul 2010 15:30:55 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100713133055.13D592474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/13 15:30:55 Modified files: cm3/m3-libs/m3core/src/runtime/common/: RTProcessC.c Log message: really no diff here, but I meant: pthread_atfork added in FreeBSD 6 (this would be a good use of autoconf) From jkrell at elego.de Wed Jul 14 10:03:05 2010 From: jkrell at elego.de (Jay Krell) Date: Wed, 14 Jul 2010 10:03:05 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100714080306.136922474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/14 10:03:05 Modified files: cm3/m3-sys/m3cc/gcc-4.5/: configure.ac Log message: remove freebsd/gmp special case here toof From jkrell at elego.de Wed Jul 14 10:03:22 2010 From: jkrell at elego.de (Jay Krell) Date: Wed, 14 Jul 2010 10:03:22 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100714080322.3EEC02474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/14 10:03:22 Modified files: cm3/m3-sys/m3cc/gcc-4.5/: configure Log message: remove freebsd/gmp special case here too From jkrell at elego.de Wed Jul 14 10:06:01 2010 From: jkrell at elego.de (Jay Krell) Date: Wed, 14 Jul 2010 10:06:01 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100714080601.642F4CC110@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/14 10:06:01 Modified files: cm3/m3-sys/m3cc/gcc-apple/: configure.in Log message: remove freebsd/gmp special case here too From jkrell at elego.de Wed Jul 14 10:06:25 2010 From: jkrell at elego.de (Jay Krell) Date: Wed, 14 Jul 2010 10:06:25 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100714080625.D655D2474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/14 10:06:25 Modified files: cm3/m3-sys/m3cc/gcc-apple/: configure Log message: remove freebsd/gmp special case here too From jkrell at elego.de Wed Jul 14 10:44:35 2010 From: jkrell at elego.de (Jay Krell) Date: Wed, 14 Jul 2010 10:44:35 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100714084435.3B3272474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/14 10:44:35 Modified files: cm3/m3-libs/m3core/src/unix/Common/: Uin.c Log message: fixes for FreeBSD 4: need to include ntohl might be macros, so can't use M3WRAP1 From jkrell at elego.de Wed Jul 14 10:53:29 2010 From: jkrell at elego.de (Jay Krell) Date: Wed, 14 Jul 2010 10:53:29 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100714085329.8BBDECC110@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/14 10:53:29 Modified files: cm3/scripts/python/: pylib.py cm3/m3-sys/cminstall/src/config-no-install/: FreeBSD.common Log message: somewhat experimental: -pthread instead of -lpthread Really I'd like to try this across the board, but just FreeBSD for now. -lpthread failed on FreeBSD 4 where -pthread worked, hopefully -pthread works on all future FreeBSD also. (probably, at least, it is a gcc thing, and usable on all Linux, *BSD) From jkrell at elego.de Wed Jul 14 11:07:35 2010 From: jkrell at elego.de (Jay Krell) Date: Wed, 14 Jul 2010 11:07:35 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100714090735.7BF902474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/14 11:07:35 Modified files: cm3/m3-sys/cminstall/src/config-no-install/: FreeBSD.common Linux.common OpenBSD.common NetBSD.common Log message: -lpthread => -pthread tested quickly minimally on Linux, OpenBSD, not tested on NetBSD FreeBSD.common is just a comment change The LIBC line in Unix.common is probably dead now..could be changed to -pthread. From jkrell at elego.de Wed Jul 14 11:37:25 2010 From: jkrell at elego.de (Jay Krell) Date: Wed, 14 Jul 2010 11:37:25 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100714093726.1AA0F2474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/14 11:37:25 Modified files: cm3/m3-sys/cminstall/src/config-no-install/: FreeBSD.common HPUX.common Linux.common NetBSD.common OpenBSD.common Solaris.common Unix.common VMS.common Log message: some -lpthread, -pthread, SYSTEM_LIBS cleanup Mainly just to reduce some duplication. This area needs more thought, design, work, testing, but this is probably ok. Some of the flaws include: - Unix.common isn't really common to 'Unix', but Linux and *BSD, at least regards to SYSTEM_LIBS - There remains some need for user-editing/configuration/autoconf/install. - Perhaps by moving some of the "less meant to be configured" parts into Modula-3 code. From jkrell at elego.de Wed Jul 14 11:45:58 2010 From: jkrell at elego.de (Jay Krell) Date: Wed, 14 Jul 2010 11:45:58 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100714094559.152572474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/14 11:45:58 Modified files: cm3/m3-sys/cminstall/src/config-no-install/: Darwin.common Log message: shorten line that was over 240 characters long From jkrell at elego.de Wed Jul 14 11:59:29 2010 From: jkrell at elego.de (Jay Krell) Date: Wed, 14 Jul 2010 11:59:29 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100714095929.C5E8FCC110@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/14 11:59:29 Modified files: cm3/m3-libs/m3core/src/thread/POSIX/: ThreadPosixC.c Log message: allow for 2GB page size perhaps and > 2GB stack, on 64 bit, user threads From jkrell at elego.de Wed Jul 14 12:03:28 2010 From: jkrell at elego.de (Jay Krell) Date: Wed, 14 Jul 2010 12:03:28 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100714100328.451C02474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/14 12:03:28 Modified files: cm3/m3-libs/m3core/src/thread/POSIX/: ThreadPosixC.c Log message: stack size in words is CARDINAL, not int: make it match the Modula-3 declaration, and thereby allow even larger stacks on 64bit, user threads From jkrell at elego.de Wed Jul 14 12:05:36 2010 From: jkrell at elego.de (Jay Krell) Date: Wed, 14 Jul 2010 12:05:36 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100714100536.5195F2474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/14 12:05:36 Modified files: cm3/m3-libs/m3core/src/thread/POSIX/: ThreadPosixC.c Log message: let's use INTEGER instead of WORD_T, the point wasn't so much to reclaim one bit, but 30 or so From jkrell at elego.de Wed Jul 14 12:06:37 2010 From: jkrell at elego.de (Jay Krell) Date: Wed, 14 Jul 2010 12:06:37 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100714100637.DB4B72474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/14 12:06:37 Modified files: cm3/m3-libs/m3core/src/thread/POSIX/: ThreadPosixC.c Log message: partial check for integer overflow, should do better in general ('integer overflow is the new buffer overflow?') From jkrell at elego.de Wed Jul 14 12:43:21 2010 From: jkrell at elego.de (Jay Krell) Date: Wed, 14 Jul 2010 12:43:21 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100714104321.D45A42474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/14 12:43:21 Modified files: cm3/scripts/python/: pylib.py Log message: some -pthread vs. -lpthread stuff (autoconf??) From jkrell at elego.de Wed Jul 14 12:44:44 2010 From: jkrell at elego.de (Jay Krell) Date: Wed, 14 Jul 2010 12:44:44 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100714104444.E24EC2474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/14 12:44:44 Modified files: cm3/scripts/python/: pylib.py Log message: add a url (or search the web) From jkrell at elego.de Wed Jul 14 12:46:04 2010 From: jkrell at elego.de (Jay Krell) Date: Wed, 14 Jul 2010 12:46:04 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100714104605.090F12474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/14 12:46:04 Modified files: cm3/scripts/python/: pylib.py Log message: better: there is an autoconf macro From jkrell at elego.de Wed Jul 14 13:22:20 2010 From: jkrell at elego.de (Jay Krell) Date: Wed, 14 Jul 2010 13:22:20 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100714112220.20C51CC37E@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/14 13:22:20 Modified files: cm3/m3-libs/libm3/src/: m3makefile Added files: cm3/m3-libs/libm3/src/types/: LongrealType.i3 RealType.i3 m3makefile Log message: restore some source compability for Mika? From jkrell at elego.de Wed Jul 14 14:34:29 2010 From: jkrell at elego.de (Jay Krell) Date: Wed, 14 Jul 2010 14:34:29 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100714123429.8E30FCC37E@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/14 14:34:29 Modified files: cm3/m3-sys/cminstall/src/config-no-install/: FreeBSD.common FreeBSD4 I386_FREEBSD gnuld.common Log message: FreeBSD4: configure compiler/linker to adjust to older versions: older gcc doesn't like -m32, keep -m32 out if -m32 gives expected error Safe to always omit -m32? older gcc misinterprets -Bsymbolic, use -Wl,-Bsymbolic -Bsymbolic inhibits -lc, add -lc only upon expected link error Safe to always add -lc? Safe to omit -Bsymbolic, but it is a nice optimization. On the other hand, this optimization is costing a lot, extra compile/link for every link of a shared library. Alternatives include: gcc -v | fgrep 2.95 uname -r | grep ^4 do nothing, let users (Mika) edit the config files do similar to what we have, but less often From jkrell at elego.de Wed Jul 14 14:43:33 2010 From: jkrell at elego.de (Jay Krell) Date: Wed, 14 Jul 2010 14:43:33 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100714124333.CEAC22474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/14 14:43:33 Modified files: cm3/m3-sys/cminstall/src/config-no-install/: Unix.common Log message: missing call to configure_linker From jkrell at elego.de Wed Jul 14 15:06:50 2010 From: jkrell at elego.de (Jay Krell) Date: Wed, 14 Jul 2010 15:06:50 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100714130650.9AE3F2474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/14 15:06:50 Modified files: cm3/m3-sys/cminstall/src/config-no-install/: I386_FREEBSD cm3cfg.common Log message: switch to a uname-based approach This is probably much faster, but also in particular, I want to make the pthread/userthread choice based on it, and remove -pthread from LIBC based on it, since that causes a bunch of link errors From jkrell at elego.de Wed Jul 14 15:14:55 2010 From: jkrell at elego.de (Jay Krell) Date: Wed, 14 Jul 2010 15:14:55 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100714131455.8A54D2474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/14 15:14:55 Modified files: cm3/m3-libs/m3core/src/: thread.quake cm3/m3-sys/cminstall/src/config-no-install/: I386_FREEBSD Log message: Always use user threads on FreeBSD4 and remove -pthread from SYSTEM_LIBC{"LIBC"} Note that this detection only works for native builds. Cross builds still require manual edits. Perhaps environments should be supported, or I should fix my Python scripts to pass along extra parameters. From jkrell at elego.de Wed Jul 14 15:23:04 2010 From: jkrell at elego.de (Jay Krell) Date: Wed, 14 Jul 2010 15:23:04 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100714132304.DB6512474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/14 15:23:04 Modified files: cm3/m3-libs/m3core/src/: thread.quake Log message: really now, use user threads on native FreeBSD4 builds (really, FreeBSD version 4, not 'FreeBSD4' meaning 'I386_FREEBSD') From jkrell at elego.de Wed Jul 14 15:50:52 2010 From: jkrell at elego.de (Jay Krell) Date: Wed, 14 Jul 2010 15:50:52 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100714135052.1950C2474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/14 15:50:52 Modified files: cm3/m3-sys/cminstall/src/config-no-install/: cm3cfg.common Log message: target equivalence, though this didn't solve the problem I was looking at, I think system_libs{libc} is read before I change it From jkrell at elego.de Wed Jul 14 15:54:37 2010 From: jkrell at elego.de (Jay Krell) Date: Wed, 14 Jul 2010 15:54:37 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100714135437.BD2A12474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/14 15:54:37 Modified files: cm3/m3-sys/cminstall/src/config-no-install/: I386_FREEBSD Log message: I386_FREEBSD From jkrell at elego.de Wed Jul 14 15:55:53 2010 From: jkrell at elego.de (Jay Krell) Date: Wed, 14 Jul 2010 15:55:53 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100714135553.8DF042474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/14 15:55:53 Modified files: cm3/m3-sys/cminstall/src/config-no-install/: I386_FREEBSD Log message: previous comment flubbed: really, don't use -pthread on FreeBSD4 It seems SYSTEM_LIBS{"LIBC"} is read before configure_linker runs, so instead of changing it there, we set it to just -lm much earlier, and then if we wanted -pthread, add it to SYSTEM_LD. From jkrell at elego.de Wed Jul 14 16:16:19 2010 From: jkrell at elego.de (Jay Krell) Date: Wed, 14 Jul 2010 16:16:19 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100714141619.26FE12474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/14 16:16:19 Modified files: cm3/m3-libs/m3core/src/thread/POSIX/: ThreadPosixC.c Log message: oops, the initial thread is already allocated, that's what words == 0 indicates: don't allocate a stack From jkrell at elego.de Wed Jul 14 16:39:40 2010 From: jkrell at elego.de (Jay Krell) Date: Wed, 14 Jul 2010 16:39:40 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100714143940.3C47A2474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/14 16:39:40 Modified files: cm3/scripts/python/: pylib.py Log message: put back -lpthread on Solaris, at least while looking for problem From jkrell at elego.de Wed Jul 14 16:41:29 2010 From: jkrell at elego.de (Jay Krell) Date: Wed, 14 Jul 2010 16:41:29 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100714144129.241162474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/14 16:41:29 Modified files: cm3/m3-sys/cminstall/src/config-no-install/: Solaris.common Log message: put back -lpthread, but I don't think this is the problem From wagner at elego.de Thu Jul 15 08:02:07 2010 From: wagner at elego.de (Olaf Wagner) Date: Thu, 15 Jul 2010 8:02:07 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100715060207.8164D2474006@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: wagner at birch. 10/07/15 08:02:07 Modified files: cm3/www/: Tag: release_branch_cm3_5_8 news.html cm3/www/releng/: Tag: release_branch_cm3_5_8 update-releng-index.sh Log message: more release additions From jkrell at elego.de Thu Jul 15 10:52:38 2010 From: jkrell at elego.de (Jay Krell) Date: Thu, 15 Jul 2010 10:52:38 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100715085238.F0D6C2474006@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/15 10:52:38 Modified files: cm3/m3-sys/cminstall/src/config-no-install/: ALPHA_OSF Log message: add -std to cc From jkrell at elego.de Thu Jul 15 11:20:40 2010 From: jkrell at elego.de (Jay Krell) Date: Thu, 15 Jul 2010 11:20:40 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100715092040.A98552474006@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/15 11:20:40 Modified files: cm3/m3-libs/m3core/src/: m3core.h Log message: whitespace change for old compiler: bash-3.2$ cc -g -c -o CerrnoC.o CerrnoC.c cc: Warning: m3core.h, line 31: # not in column 1 is ignored, skipping to end of line. (ignoretokens) #define M3_DLL_IMPORT --^ From jkrell at elego.de Thu Jul 15 13:03:51 2010 From: jkrell at elego.de (Jay Krell) Date: Thu, 15 Jul 2010 13:03:51 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100715110351.4FFB92474006@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/15 13:03:51 Modified files: cm3/m3-sys/cminstall/src/config-no-install/: cm3cfg.common Log message: add IsHostOSF1v4 to be used shortly, uname -sr based OSF1 v4 has something funny with #define _POSIX_SOURCE and such, I can get it to compile, but I don't know if it breaks v5. OSF1 doesn't have 64bit time_t available native + IsHostOSF1v4 will => #define M3_OSF1_V4 and m3core.h will check that refine uname-based IsHostFreeBSD4 just one uname and one fgrep add InternalTargetCanRunOnHost that's been bugging me lots can run lots, though missing here is if potentially biarch systems are actually biarch From jkrell at elego.de Thu Jul 15 13:06:38 2010 From: jkrell at elego.de (Jay Krell) Date: Thu, 15 Jul 2010 13:06:38 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100715110638.E30DC2474006@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/15 13:06:38 Modified files: cm3/m3-sys/cminstall/src/config-no-install/: cm3cfg.common Log message: I forgot to add IsTargetOSF1v4 function (which is only approx, i.e. works for native builds only) From jkrell at elego.de Thu Jul 15 13:07:09 2010 From: jkrell at elego.de (Jay Krell) Date: Thu, 15 Jul 2010 13:07:09 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100715110709.4F9612474006@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/15 13:07:09 Modified files: cm3/m3-sys/cminstall/src/config-no-install/: cm3cfg.common Log message: comments explaining why knowing precise target doesn't work From jkrell at elego.de Thu Jul 15 13:08:15 2010 From: jkrell at elego.de (Jay Krell) Date: Thu, 15 Jul 2010 13:08:15 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100715110815.D944B2474006@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/15 13:08:15 Modified files: cm3/m3-sys/cminstall/src/config-no-install/: cm3cfg.common Log message: fix copy/pasto (but still worked ok for all normal systems) From jkrell at elego.de Thu Jul 15 13:12:32 2010 From: jkrell at elego.de (Jay Krell) Date: Thu, 15 Jul 2010 13:12:32 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100715111232.6D1E62474006@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/15 13:12:32 Modified files: cm3/m3-sys/cminstall/src/config-no-install/: ALPHA_OSF Log message: add -DM3_OSF1_V4 to SYSTEM_CC if it seems we are targeting OSF/1 v4 (yeah yeah, what about versions 1-3?; get me access to such a machine and I'll deal with it) From jkrell at elego.de Thu Jul 15 13:14:48 2010 From: jkrell at elego.de (Jay Krell) Date: Thu, 15 Jul 2010 13:14:48 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100715111448.EB9BC2474006@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/15 13:14:48 Modified files: cm3/m3-libs/m3core/src/: m3core.h Log message: don't define _XOPEN_SOURCE or _TIME64_T if M3_OSF1_V4 is defined; _XOPEN_SOURCE breaks pthread.h, even though the comments in pthread.h say it shouldn't; I don't remember why I added _XOPEN_SOURCE in the first place, would have to investigate on v5; _TIME64_T is not available on v4; on the hypothetical world where OSF/1 v4 and v5 mattered, we'd want to do builds on each, rename the archives, but not likely invent two different targets, since they match plenty close enough as far as I know (I should double check jmpbuf) From jkrell at elego.de Thu Jul 15 13:26:42 2010 From: jkrell at elego.de (Jay Krell) Date: Thu, 15 Jul 2010 13:26:42 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100715112642.241F32474006@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/15 13:26:42 Modified files: cm3/m3-libs/m3core/src/thread/PTHREAD/: ThreadPThreadC.c Log message: cc: Warning: ThreadPThreadC.c, line 170: In this statement, & before array "jb" is ignored. (addrarray) p(&jb, ((char *)&jb) + sizeof(jb)); ------^ cc: Warning: ThreadPThreadC.c, line 170: In this statement, & before array "jb" is ignored. (addrarray) p(&jb, ((char *)&jb) + sizeof(jb)); --------------------^ jb may or may not be an array, & is necessary, wrap it in struct. From jkrell at elego.de Thu Jul 15 13:29:49 2010 From: jkrell at elego.de (Jay Krell) Date: Thu, 15 Jul 2010 13:29:49 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100715112949.AC3E62474006@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/15 13:29:49 Modified files: cm3/m3-libs/libm3/src/os/POSIX/: FSPosixC.c Log message: cc: Warning: FSPosixC.c, line 35: In this statement, & before array "t" is ignored. (addrarray) ZeroMemory(&t, sizeof(t)); ----^ says the OSF1v4 compiler; in this case the array-ness is plain to see so we can safely portably remove the ampersand, and it makes no difference. Thank you compiler.. From jkrell at elego.de Thu Jul 15 13:35:51 2010 From: jkrell at elego.de (Jay Krell) Date: Thu, 15 Jul 2010 13:35:51 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100715113551.662702474006@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/15 13:35:51 Modified files: cm3/m3-sys/cminstall/src/config-no-install/: ALPHA_OSF Log message: didn't actually need -std here, the problem was #define _XOPEN_SOURCE From jkrell at elego.de Thu Jul 15 13:44:21 2010 From: jkrell at elego.de (Jay Krell) Date: Thu, 15 Jul 2010 13:44:21 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100715114421.AE7962474006@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/15 13:44:21 Modified files: cm3/m3-libs/m3core/src/: m3core.h Log message: define _POSIX_PII_SOCKET on OSF1v4 to get soclen_t typedef (that's probablly why I added #define _XOPEN_SOURCE 500; add some other comments From jkrell at elego.de Thu Jul 15 13:50:13 2010 From: jkrell at elego.de (Jay Krell) Date: Thu, 15 Jul 2010 13:50:13 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100715115013.3E5D92474006@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/15 13:50:13 Modified files: cm3/scripts/python/: pylib.py Log message: -lrt -lm -pthread for ALPHA_OSF, similar to the config file (the config file does more) From jkrell at elego.de Thu Jul 15 13:52:53 2010 From: jkrell at elego.de (Jay Krell) Date: Thu, 15 Jul 2010 13:52:53 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100715115253.33EE9CC110@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/15 13:52:53 Modified files: cm3/scripts/python/: pylib.py Log message: comment about OSF1v4, actually maybe it is worth having I386_FREEBSD4, I386_FREEBSD5 (6?), ALPHA_OSF4, ALPHA_OSF5, that does kind of mimic GNU configuration and would make some stuff work better, including for example, cross building boot packages From jkrell at elego.de Thu Jul 15 15:26:42 2010 From: jkrell at elego.de (Jay Krell) Date: Thu, 15 Jul 2010 15:26:42 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100715132642.F13EBCC37E@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/15 15:26:42 Modified files: cm3/scripts/: sysinfo.sh Added files: cm3/scripts/: boot2.sh Log message: OSF/1 support, and Python failed to build here so far (minor sounding problem) so port to sh From jkrell at elego.de Thu Jul 15 15:28:14 2010 From: jkrell at elego.de (Jay Krell) Date: Thu, 15 Jul 2010 15:28:14 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100715132814.EEAD32474006@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/15 15:28:14 Modified files: cm3/scripts/: sysinfo.sh Log message: I doubt the stars are needed at the ends of plain parameterless uname output (checked at least FreeBSD 4.11) From jkrell at elego.de Thu Jul 15 15:58:47 2010 From: jkrell at elego.de (Jay Krell) Date: Thu, 15 Jul 2010 15:58:47 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100715135847.A1491CC37E@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/15 15:58:47 Modified files: cm3/m3-sys/cminstall/src/config-no-install/: Solaris.common Log message: use fgrep instead of grep From jkrell at elego.de Thu Jul 15 16:45:43 2010 From: jkrell at elego.de (Jay Krell) Date: Thu, 15 Jul 2010 16:45:43 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100715144543.B25742474006@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/15 16:45:43 Modified files: cm3/m3-sys/cminstall/src/config-no-install/: FreeBSD.common I386_FREEBSD Log message: more conservative linking options on FreeBSD4: no -z now no -B symbolic and then no -pthread or -lc: shared libraries I guess aren't supposed to choose libc or libc_r but maybe leave it to the executable? And we don't need libc_r because we are using user threads? This fixes the crash I was seeing. FreeBSD >4 should be unaffected. From jkrell at elego.de Fri Jul 16 14:01:27 2010 From: jkrell at elego.de (Jay Krell) Date: Fri, 16 Jul 2010 14:01:27 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100716120128.1FC822474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/16 14:01:27 Modified files: cm3/scripts/: boot2.sh Log message: move action to start, as the sh scripts require? From jkrell at elego.de Fri Jul 16 14:11:16 2010 From: jkrell at elego.de (Jay Krell) Date: Fri, 16 Jul 2010 14:11:16 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100716121116.B35312474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/16 14:11:16 Added files: cm3/scripts/: install-config.sh Log message: more sh for Tru64 4.0 work, while I wait for Python to compile Note this is different than install-config.py. It is based on make-bin-dist.sh. It makes config for ship, not development. ie. actual copies of the files, not the stub that tries to get back to the source tree. From jkrell at elego.de Fri Jul 16 14:18:36 2010 From: jkrell at elego.de (Jay Krell) Date: Fri, 16 Jul 2010 14:18:36 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100716121836.662752474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/16 14:18:36 Modified files: cm3/m3-sys/cminstall/src/config-no-install/: ALPHA_OSF Log message: delay setting SYSTEM_CC until configure_c_compiler(), so that we can call IsTargetOSF1v4; another solution would be to move the two lines to the end of the file From jkrell at elego.de Fri Jul 16 14:30:00 2010 From: jkrell at elego.de (Jay Krell) Date: Fri, 16 Jul 2010 14:30:00 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100716123000.E22572474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/16 14:30:00 Modified files: cm3/m3-sys/m3cc/src/: platforms.quake Log message: let's trye alpha-dec-osf instead of alpha-dec-osf5.1, see how that goes From jkrell at elego.de Fri Jul 16 15:01:44 2010 From: jkrell at elego.de (Jay Krell) Date: Fri, 16 Jul 2010 15:01:44 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100716130144.5A413CC37E@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/16 15:01:44 Modified files: cm3/scripts/: make-dist.sh Log message: comment only, about runpath From jkrell at elego.de Fri Jul 16 15:02:39 2010 From: jkrell at elego.de (Jay Krell) Date: Fri, 16 Jul 2010 15:02:39 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100716130239.68DDD2474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/16 15:02:39 Modified files: cm3/scripts/python/: make-dist.py Log message: keep out hardcoded runpaths, like make-dist.sh, this is setting and environment variable that config/gnuld.common checks From jkrell at elego.de Fri Jul 16 15:04:12 2010 From: jkrell at elego.de (Jay Krell) Date: Fri, 16 Jul 2010 15:04:12 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100716130413.04699CC37F@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/16 15:04:12 Modified files: cm3/scripts/python/: pylib.py make-dist.py Log message: more support for Visual C++ 10.0 From jkrell at elego.de Fri Jul 16 15:17:18 2010 From: jkrell at elego.de (Jay Krell) Date: Fri, 16 Jul 2010 15:17:18 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100716131718.49F572474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/16 15:17:18 Modified files: cm3/scripts/python/: pylib.py Log message: somewhat experimental: insert `uname -sr` in archive names, with some transforms to make it shorter: Linux 2.6.1231313 => Linux2.6 FreeBSD 1.23-release => FreeBSD1.23 -.+$ => empty actually spaces removed only investigated recently uname -sr on OSF, Darwin, FreeBSD, OpenBSD Darwin should probably be translated to MacOSX version From jkrell at elego.de Fri Jul 16 15:18:12 2010 From: jkrell at elego.de (Jay Krell) Date: Fri, 16 Jul 2010 15:18:12 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100716131812.E4F1E2474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/16 15:18:12 Modified files: cm3/scripts/python/: pylib.py Log message: 'SunOS' => 'Solaris' in archive names, though SunOS is shorter From jkrell at elego.de Fri Jul 16 15:20:11 2010 From: jkrell at elego.de (Jay Krell) Date: Fri, 16 Jul 2010 15:20:11 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100716132011.155EBCC37E@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/16 15:20:11 Modified files: cm3/scripts/python/: pylib.py Log message: Linux2.4.xxx => Linux2.4 Linux2.6.xxx => empty Linux 2.6 is I believe overwhelmingly in use 2.4 remains for small embedded systems like my router, and notably lacks NPTL (good pthreads) From jkrell at elego.de Fri Jul 16 15:22:28 2010 From: jkrell at elego.de (Jay Krell) Date: Fri, 16 Jul 2010 15:22:28 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100716132228.46EB62474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/16 15:22:28 Modified files: cm3/scripts/python/: make-dist.py Log message: environment variables must be strings From jkrell at elego.de Fri Jul 16 15:23:03 2010 From: jkrell at elego.de (Jay Krell) Date: Fri, 16 Jul 2010 15:23:03 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100716132303.CD6F42474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/16 15:23:03 Modified files: cm3/scripts/python/: pylib.py Log message: fix regexp around archive name having uname -sr From jkrell at elego.de Fri Jul 16 15:24:25 2010 From: jkrell at elego.de (Jay Krell) Date: Fri, 16 Jul 2010 15:24:25 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100716132425.2473C2474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/16 15:24:25 Modified files: cm3/scripts/python/: pylib.py Log message: fix regexp around archive name having uname -sr From jkrell at elego.de Fri Jul 16 15:28:12 2010 From: jkrell at elego.de (Jay Krell) Date: Fri, 16 Jul 2010 15:28:12 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100716132812.1D3112474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/16 15:28:12 Modified files: cm3/scripts/python/: pylib.py Log message: remove newlines from uname output From jkrell at elego.de Fri Jul 16 16:03:51 2010 From: jkrell at elego.de (Jay Krell) Date: Fri, 16 Jul 2010 16:03:51 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100716140351.9FD322474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/16 16:03:51 Modified files: cm3/m3-sys/cminstall/src/config-no-install/: ALPHA_OSF Log message: oops: ALPHA_OSF doesn't share as much code (though neither do Solaris.common or Darwin.common): forgot to call configure_c_compiler From jkrell at elego.de Fri Jul 16 16:34:49 2010 From: jkrell at elego.de (Jay Krell) Date: Fri, 16 Jul 2010 16:34:49 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100716143449.A79592474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/16 16:34:49 Modified files: cm3/m3-sys/m3cc/src/: platforms.quake Log message: need to say osf4 From jkrell at elego.de Sat Jul 17 14:37:17 2010 From: jkrell at elego.de (Jay Krell) Date: Sat, 17 Jul 2010 14:37:17 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100717123717.BB6C42474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/17 14:37:17 Modified files: cm3/m3-sys/m3cc/src/: gnucc.common Log message: acceptable hack for OSF1v4: omit -g because then the files are so large such as to exhaust virtual memory/swap linking cm3cg From jkrell at elego.de Sat Jul 17 15:09:08 2010 From: jkrell at elego.de (Jay Krell) Date: Sat, 17 Jul 2010 15:09:08 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100717130908.E32AF2474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/17 15:09:08 Modified files: cm3/m3-sys/cminstall/src/config-no-install/: ALPHA_OSF Log message: on OSF1v4, use -Wl,-B,symbolic instead of -B symbolic; it should work, but oh well From jkrell at elego.de Sat Jul 17 15:35:42 2010 From: jkrell at elego.de (Jay Krell) Date: Sat, 17 Jul 2010 15:35:42 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100717133542.69AD92474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/17 15:35:42 Modified files: cm3/m3-sys/cminstall/src/config-no-install/: ALPHA_OSF Log message: Honor $M3_PORTABLE_RUN_PATH like gnuld.common: if it is set, don't use LIB_USE, since that is specific to the machine building the files. Instead, use nothing at all, consumer will need to set LD_LIBRARY_PATH. Note that ALPHA_OSF does support -rpath ${ENVVAR}, so a good solution would be to rename foo to foo.exe (or something) and drop in a constant shell script foo. The shell script foo "finds itself", like configure: if $0 is a full path, that is it, if it is relative, that is it relative to current working directory, else search $PATH then shell script should set $ORIGIN to its own directory or and we'd use $ORIGIN/../lib and shell script would exec foo.exe. Todo later. Maybe. Probably not. From jkrell at elego.de Sat Jul 17 17:49:51 2010 From: jkrell at elego.de (Jay Krell) Date: Sat, 17 Jul 2010 17:49:51 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100717154951.4C753CC37E@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/17 17:49:51 Modified files: cm3/m3-sys/cminstall/src/config-no-install/: ALPHA_OSF Log message: non_shared doesn't work with pthread (failure to link); call_shared is default, so not needed; cleanup From jkrell at elego.de Sat Jul 17 17:50:11 2010 From: jkrell at elego.de (Jay Krell) Date: Sat, 17 Jul 2010 17:50:11 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100717155011.3892ECC37F@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/17 17:50:11 Modified files: cm3/m3-sys/cminstall/src/config-no-install/: ALPHA_OSF Log message: fix the 'cleanup' part From jkrell at elego.de Sat Jul 17 17:51:32 2010 From: jkrell at elego.de (Jay Krell) Date: Sat, 17 Jul 2010 17:51:32 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100717155132.83CFC2474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/17 17:51:32 Modified files: cm3/m3-sys/cminstall/src/config-no-install/: ALPHA_OSF Log message: fix/invert M3_PORTABLE_RUN_PATH From jkrell at elego.de Sun Jul 18 06:34:59 2010 From: jkrell at elego.de (Jay Krell) Date: Sun, 18 Jul 2010 6:34:59 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100718043459.D8CB42474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/18 06:34:59 Modified files: cm3/m3-tools/pp/src/: Parse.yacc cm3/m3-tools/pp/src/flex-bison/: lex.yy.c y.tab.c cm3/m3-tools/pp/src/lex-yacc/: lex.yy.c y.tab.c cm3/m3-tools/pp/src/lex-yacc-HPPA/: lex.yy.c y.tab.c Log message: cleanup: always #include stdlib.h stdio.h stddef.h unistd.h always use size_t don't redefine NULL This should fix a problem on OSF1v4 (incompatible declarations of malloc/free) and is fine on all systems for some years now. Strongly consider running lex/flex/yacc/bison and not checking in the output! From jay.krell at cornell.edu Sun Jul 18 06:41:46 2010 From: jay.krell at cornell.edu (Jay K) Date: Sun, 18 Jul 2010 04:41:46 +0000 Subject: [M3commit] CVS Update: cm3 In-Reply-To: <20100718043459.D8CB42474003@birch.elegosoft.com> References: <20100718043459.D8CB42474003@birch.elegosoft.com> Message-ID: diff attached Though I think better to delete these *.c files and run the tools to generate them. Agreed? I understand the idea that users that compile this directory might not have them, but they probably will. ?- Jay ---------------------------------------- > Date: Sun, 18 Jul 2010 06:34: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/07/18 06:34:59 > > Modified files: > cm3/m3-tools/pp/src/: Parse.yacc > cm3/m3-tools/pp/src/flex-bison/: lex.yy.c y.tab.c > cm3/m3-tools/pp/src/lex-yacc/: lex.yy.c y.tab.c > cm3/m3-tools/pp/src/lex-yacc-HPPA/: lex.yy.c y.tab.c > > Log message: > cleanup: > always #include stdlib.h stdio.h stddef.h unistd.h > always use size_t > don't redefine NULL > This should fix a problem on OSF1v4 (incompatible declarations > of malloc/free) and is fine on all systems for some years now. > Strongly consider running lex/flex/yacc/bison and not checking in the output! > -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: lex.txt URL: From jkrell at elego.de Sun Jul 18 06:44:19 2010 From: jkrell at elego.de (Jay Krell) Date: Sun, 18 Jul 2010 6:44:19 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100718044419.26A152474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/18 06:44:19 Modified files: cm3/m3-tools/pp/src/flex-bison/: lex.yy.c cm3/m3-tools/pp/src/lex-yacc/: lex.yy.c cm3/m3-tools/pp/src/lex-yacc-HPPA/: lex.yy.c Log message: remove $Header and $Revision From jkrell at elego.de Sun Jul 18 06:56:41 2010 From: jkrell at elego.de (Jay Krell) Date: Sun, 18 Jul 2010 6:56:41 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100718045642.0555B2474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/18 06:56:41 Modified files: cm3/m3-tools/pp/src/: m3makefile Log message: on systems that have both lex/yacc and flex/bison, favor flex/bison instead of lex/yacc, instead of the opposite From jkrell at elego.de Sun Jul 18 06:58:24 2010 From: jkrell at elego.de (Jay Krell) Date: Sun, 18 Jul 2010 6:58:24 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100718045824.9123A2474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/18 06:58:24 Modified files: cm3/m3-tools/pp/src/lex-yacc/: Makefile Log message: actually use yacc, not merely bison -y From jkrell at elego.de Sun Jul 18 07:04:40 2010 From: jkrell at elego.de (Jay Krell) Date: Sun, 18 Jul 2010 7:04:40 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100718050440.72F282474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/18 07:04:40 Modified files: cm3/m3-tools/pp/src/: m3makefile Log message: fix From jkrell at elego.de Sun Jul 18 07:44:00 2010 From: jkrell at elego.de (Jay Krell) Date: Sun, 18 Jul 2010 7:44:00 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100718054401.4DFF02474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/18 07:44:00 Modified files: cm3/scripts/python/: pylib.py make-dist.py Log message: mips-tfile for make-dist ALPHA_OSF support, and consolidate mklib support, not all tested as file copy to Alpha/OSF difficult From jkrell at elego.de Sun Jul 18 10:11:16 2010 From: jkrell at elego.de (Jay Krell) Date: Sun, 18 Jul 2010 10:11:16 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100718081117.005AD2474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/18 10:11:16 Modified files: cm3/m3-sys/m3cc/gcc-4.5/gcc/: gimple.h Log message: add asserts that helped me track down problem (later assertion failure) with sets being void* instead of size_t* I suspect these are correct but if they are wrong, ok, remove them. From jkrell at elego.de Sun Jul 18 10:20:20 2010 From: jkrell at elego.de (Jay Krell) Date: Sun, 18 Jul 2010 10:20:20 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100718082020.E9A0ACC37E@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/18 10:20:20 Modified files: cm3/m3-sys/m3cc/gcc/gcc/: config.host config.gcc cm3/m3-sys/m3cc/gcc/gcc/config/: openbsd.h t-openbsd cm3/m3-sys/m3cc/gcc/gcc/config/i386/: openbsd.h openbsdelf.h cm3/m3-sys/m3cc/gcc/gcc/config/m68k/: openbsd.h cm3/m3-sys/m3cc/gcc/gcc/config/mips/: openbsd.h cm3/m3-sys/m3cc/gcc/gcc/config/vax/: openbsd.h cm3/m3-sys/m3cc/src/: m3makefile Log message: Commit the OpenBSD patches instead of applying them in the build. Note that I doubt change to gcc/gcc/config/openbsd.h is needed, it looks specific to using the C front ends (cc1, etc.) or the "driver" (gcc). From jkrell at elego.de Sun Jul 18 10:40:52 2010 From: jkrell at elego.de (Jay Krell) Date: Sun, 18 Jul 2010 10:40:52 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100718084052.5C3012474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/18 10:40:52 Added files: cm3/m3-sys/m3cc/gcc/gcc/config/: exec-stack.h host-openbsd.c openbsd-libpthread.h x-openbsd cm3/m3-sys/m3cc/gcc/gcc/config/i386/: openbsd64.h cm3/m3-sys/m3cc/gcc/gcc/config/rs6000/: openbsd.h Log message: oops: also add the new files needed for OpenBSD, that we were previously copying from the patches directory From jkrell at elego.de Sun Jul 18 11:47:42 2010 From: jkrell at elego.de (Jay Krell) Date: Sun, 18 Jul 2010 11:47:42 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100718094742.9BDF9CC37E@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/18 11:47:42 Modified files: cm3/m3-sys/m3cc/gcc/gcc/: tree-chrec.h Log message: initialize with generic { 0 } instead of 0 (this is a line that we changed anyway From jkrell at elego.de Sun Jul 18 11:49:48 2010 From: jkrell at elego.de (Jay Krell) Date: Sun, 18 Jul 2010 11:49:48 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100718094948.4AD92CC37E@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/18 11:49:48 Modified files: cm3/m3-sys/m3cc/gcc/gcc/: tree.c Log message: change copyright comment back to match 4.3.0 and 4.3.5 From jkrell at elego.de Sun Jul 18 11:56:25 2010 From: jkrell at elego.de (Jay Krell) Date: Sun, 18 Jul 2010 11:56:25 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100718095625.5ADB22474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/18 11:56:25 Modified files: cm3/m3-sys/m3cc/gcc/gcc/: dbxout.c Log message: remove code that was #if 0'ed out September 2008 From jkrell at elego.de Sun Jul 18 13:13:45 2010 From: jkrell at elego.de (Jay Krell) Date: Sun, 18 Jul 2010 13:13:45 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100718111345.7E9632474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/18 13:13:45 Modified files: cm3/m3-sys/m3cc/gcc/: ChangeLog LAST_UPDATED MD5SUMS Makefile.def Makefile.in Makefile.tpl NEWS config-ml.in configure configure.ac cm3/m3-sys/m3cc/gcc/INSTALL/: binaries.html build.html configure.html download.html finalinstall.html gfdl.html index.html old.html prerequisites.html specific.html test.html cm3/m3-sys/m3cc/gcc/config/: ChangeLog cm3/m3-sys/m3cc/gcc/contrib/: ChangeLog texi2pod.pl cm3/m3-sys/m3cc/gcc/contrib/reghunt/: ChangeLog cm3/m3-sys/m3cc/gcc/contrib/regression/: ChangeLog cm3/m3-sys/m3cc/gcc/fixincludes/: ChangeLog fixincl.x inclhack.def cm3/m3-sys/m3cc/gcc/fixincludes/tests/base/iso/: math_c99.h cm3/m3-sys/m3cc/gcc/gcc/: BASE-VER ChangeLog ChangeLog-2007 DATESTAMP Makefile.in aclocal.m4 alias.c alias.h attribs.c builtin-types.def builtins.c builtins.def c-common.c c-cppbuiltin.c c-decl.c c-format.c c-lex.c c-parser.c c-pch.c c-pretty-print.c c-typeck.c calls.c cfgrtl.c cgraph.c cgraph.h cgraphunit.c collect2.c combine-stack-adj.c combine.c config.gcc configure configure.ac convert.c cse.c dbxout.c df-scan.c dfp.c dojump.c dse.c dwarf2.h dwarf2out.c emit-rtl.c emutls.c except.c exec-tool.in explow.c expmed.c expr.c final.c flags.h fold-const.c function.c fwprop.c gcov-io.h gcse.c gengtype-lex.c gengtype.c gimplify.c global.c gthr-posix.h gthr-posix95.h haifa-sched.c ifcvt.c ipa-inline.c ipa-utils.h jump.c langhooks-def.h langhooks.c langhooks.h libgcc2.c longlong.h loop-invariant.c mips-tfile.c omp-low.c optc-gen.awk opts.c params.def passes.c predict.c pretty-print.c real.c real.h recog.c recog.h regmove.c regrename.c reload.c resource.c rtl.h rtlanal.c sched-deps.c sched-int.h sched-rgn.c simplify-rtx.c stmt.c stor-layout.c target-def.h target.h targhooks.c targhooks.h toplev.c tree-cfg.c tree-chrec.c tree-chrec.h tree-complex.c tree-dfa.c tree-flow-inline.h tree-flow.h tree-inline.c tree-loop-linear.c tree-nested.c tree-nrv.c tree-outof-ssa.c tree-parloops.c tree-predcom.c tree-scalar-evolution.c tree-scalar-evolution.h tree-sra.c tree-ssa-address.c tree-ssa-alias-warnings.c tree-ssa-alias.c tree-ssa-ccp.c tree-ssa-dse.c tree-ssa-forwprop.c tree-ssa-loop-im.c tree-ssa-loop-ivopts.c tree-ssa-loop-niter.c tree-ssa-loop-prefetch.c tree-ssa-operands.c tree-ssa-phiopt.c tree-ssa-pre.c tree-ssa-sccvn.c tree-ssa-structalias.c tree-ssa.c tree-tailcall.c tree-vect-analyze.c tree-vect-generic.c tree-vect-transform.c tree-vn.c tree-vrp.c tree.c tree.h unwind-dw2.c unwind-generic.h unwind-pe.h varasm.c vec.h cm3/m3-sys/m3cc/gcc/gcc/config/: dfp-bit.c freebsd.h cm3/m3-sys/m3cc/gcc/gcc/config/alpha/: alpha.c alpha.md elf.h predicates.md sync.md cm3/m3-sys/m3cc/gcc/gcc/config/arm/: arm.c arm.md iwmmxt.md cm3/m3-sys/m3cc/gcc/gcc/config/avr/: avr-protos.h avr.c avr.h avr.md cm3/m3-sys/m3cc/gcc/gcc/config/cris/: cris.c cris.h cris.md cm3/m3-sys/m3cc/gcc/gcc/config/i386/: ammintrin.h bmmintrin.h driver-i386.c emmintrin.h i386.c i386.h i386.md i386.opt linux.h mm3dnow.h mmintrin-common.h mmintrin.h mmx.md pmmintrin.h predicates.md smmintrin.h sse.md sync.md tmmintrin.h winnt-cxx.c winnt.c x86-64.h xmmintrin.h cm3/m3-sys/m3cc/gcc/gcc/config/ia64/: div.md ia64.c ia64.md cm3/m3-sys/m3cc/gcc/gcc/config/m68k/: t-rtems cm3/m3-sys/m3cc/gcc/gcc/config/mips/: constraints.md iris6.h irix-crti.asm mips.c mips.md mips.opt sde.h cm3/m3-sys/m3cc/gcc/gcc/config/mn10300/: mn10300.c cm3/m3-sys/m3cc/gcc/gcc/config/pa/: fptr.c hpux-unwind.h linux-unwind.h milli64.S pa-hpux11.h pa.c pa.md pa64-hpux.h t-hpux-shlib cm3/m3-sys/m3cc/gcc/gcc/config/pdp11/: pdp11.c cm3/m3-sys/m3cc/gcc/gcc/config/rs6000/: altivec.md driver-rs6000.c predicates.md rs6000-c.c rs6000-protos.h rs6000.c rs6000.md cm3/m3-sys/m3cc/gcc/gcc/config/s390/: s390.c s390.h tpf.h cm3/m3-sys/m3cc/gcc/gcc/config/sh/: predicates.md sh.c sh.h sh.md t-sh cm3/m3-sys/m3cc/gcc/gcc/config/soft-fp/: double.h fixdfti.c floatuntisf.c cm3/m3-sys/m3cc/gcc/gcc/config/sparc/: linux.h linux64.h predicates.md sparc-protos.h sparc.c sparc.h sparc.md sysv4.h cm3/m3-sys/m3cc/gcc/gcc/config/spu/: spu-c.c spu-elf.h spu-protos.h spu.c spu.h spu.md spu.opt spu_mfcio.h t-spu-elf cm3/m3-sys/m3cc/gcc/gcc/config/stormy16/: stormy16.c cm3/m3-sys/m3cc/gcc/gcc/config/xtensa/: t-linux xtensa.md cm3/m3-sys/m3cc/gcc/gcc/doc/: cpp.1 cpp.info cppinternals.info extend.texi fsf-funding.7 g++.1 gc-analyze.1 gcc.1 gcc.info gcc.texi gccinstall.info gccint.info gccint.texi gcj-dbtool.1 gcj.1 gcj.info gcov.1 gfdl.7 gfortran.1 gij.1 gpl.7 grmic.1 gty.texi implement-c.texi install.texi install.texi2html invoke.texi jcf-dump.1 jv-convert.1 md.texi passes.texi rtl.texi sourcebuild.texi cm3/m3-sys/m3cc/gcc/gcc/doc/include/: gpl_v3.texi texinfo.tex cm3/m3-sys/m3cc/gcc/gcc/treelang/: ChangeLog cm3/m3-sys/m3cc/gcc/include/: ChangeLog cm3/m3-sys/m3cc/gcc/libcpp/: ChangeLog files.c cm3/m3-sys/m3cc/gcc/libdecnumber/: ChangeLog Makefile.in decBasic.c decCommon.c decContext.c decDouble.h decExcept.c decExcept.h decLibrary.c decNumber.c decNumberLocal.h decQuad.h decRound.c decSingle.h cm3/m3-sys/m3cc/gcc/libdecnumber/bid/: host-ieee128.c cm3/m3-sys/m3cc/gcc/libdecnumber/dpd/: decimal128.c decimal128Local.h decimal32.c decimal64.c cm3/m3-sys/m3cc/gcc/libgcc/: ChangeLog Makefile.in config.host configure configure.ac cm3/m3-sys/m3cc/gcc/libgcc/config/libbid/: ChangeLog cm3/m3-sys/m3cc/gcc/libiberty/: ChangeLog configure configure.ac cm3/m3-sys/m3cc/gcc/maintainer-scripts/: ChangeLog gcc_release Log message: merge with gcc 4.3.5 From jkrell at elego.de Sun Jul 18 13:20:04 2010 From: jkrell at elego.de (Jay Krell) Date: Sun, 18 Jul 2010 13:20:04 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100718112004.C0EAF2474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/18 13:20:04 Added files: cm3/m3-sys/m3cc/gcc/contrib/: dg-extract-results.sh cm3/m3-sys/m3cc/gcc/gcc/config/sparc/: gas.h cm3/m3-sys/m3cc/gcc/gcc/config/spu/: divmodti4.c float_disf.c float_unsdisf.c multi3.c cm3/m3-sys/m3cc/gcc/gcc/config/xtensa/: libgcc-xtensa.ver cm3/m3-sys/m3cc/gcc/libdecnumber/: dconfig.h cm3/m3-sys/m3cc/gcc/libgcc/: gstdint.h cm3/m3-sys/m3cc/gcc/libgcc/config/i386/: t-sol2 Log message: merge with gcc 4.3.5 From jkrell at elego.de Sun Jul 18 14:11:25 2010 From: jkrell at elego.de (Jay Krell) Date: Sun, 18 Jul 2010 14:11:25 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100718121125.A19C72474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/18 14:11:25 Modified files: cm3/m3-libs/m3core/src/Csupport/Common/: hand.c Log message: add back set_singleton, set_member, set_ne, set_eq for my convenience attempting bootstrap with old compiler and new mecore From jkrell at elego.de Sun Jul 18 14:37:32 2010 From: jkrell at elego.de (Jay Krell) Date: Sun, 18 Jul 2010 14:37:32 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100718123732.99A582474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/18 14:37:32 Modified files: cm3/m3-libs/m3core/src/Csupport/Common/: hand.c Added files: cm3/m3-libs/m3core/src/Csupport/Common/: old_divmod.c Log message: move old code out, add comments to it about its "problems" From jkrell at elego.de Sun Jul 18 16:05:50 2010 From: jkrell at elego.de (Jay Krell) Date: Sun, 18 Jul 2010 16:05:50 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100718140550.A12532474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/18 16:05:50 Added files: cm3/www/releng/: relnotes-5.9.html Log message: new file for the next release, first copy the old file From jkrell at elego.de Sun Jul 18 16:12:53 2010 From: jkrell at elego.de (Jay Krell) Date: Sun, 18 Jul 2010 16:12:53 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100718141255.7C4AD2474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/18 16:12:53 Modified files: cm3/www/releng/: relnotes-5.9.html Log message: update it with some stuff post 5.8 From jkrell at elego.de Sun Jul 18 16:14:20 2010 From: jkrell at elego.de (Jay Krell) Date: Sun, 18 Jul 2010 16:14:20 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100718141420.D97032474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/18 16:14:20 Modified files: cm3/www/releng/: relnotes-5.9.html Log message: ALPHA_OSF target restored (4.0g, 5.1) From jkrell at elego.de Sun Jul 18 16:44:38 2010 From: jkrell at elego.de (Jay Krell) Date: Sun, 18 Jul 2010 16:44:38 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100718144438.7E3602474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/18 16:44:38 Modified files: cm3/m3-sys/cminstall/src/config-no-install/: Solaris.common Log message: remove -lpthread again; fix flex/bison to be -L/usr/sfw/bin/lib -lfl instead of empty, but comment it out in favor of I think the more 'standard' (not optional) lex/yacc From jkrell at elego.de Sun Jul 18 16:53:14 2010 From: jkrell at elego.de (Jay Krell) Date: Sun, 18 Jul 2010 16:53:14 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100718145315.166AE2474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/18 16:53:14 Modified files: cm3/www/releng/: relnotes-5.9.html Log message: relnotes-5.9.html From jkrell at elego.de Sun Jul 18 16:53:35 2010 From: jkrell at elego.de (Jay Krell) Date: Sun, 18 Jul 2010 16:53:35 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100718145335.DC5602474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/18 16:53:35 Modified files: cm3/www/releng/: relnotes-5.9.html Log message: flubbed checkin comment: new targets: SPARC64_SOLARIS, I386_SOLARIS, AMD64_SOLARIS (2.9?) From jkrell at elego.de Sun Jul 18 17:23:55 2010 From: jkrell at elego.de (Jay Krell) Date: Sun, 18 Jul 2010 17:23:55 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100718152355.EBF422474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/18 17:23:55 Modified files: cm3/www/releng/: relnotes-5.9.html Log message: note some more changes since release; of course, the release notes will need review, proofing for style and correctness, etc. and this is very very very far from urgent From jkrell at elego.de Sun Jul 18 17:52:41 2010 From: jkrell at elego.de (Jay Krell) Date: Sun, 18 Jul 2010 17:52:41 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100718155242.142A02474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/18 17:52:41 Modified files: cm3/m3-sys/m3cc/src/: gnucc.common Log message: compat with previous release config files, could maybe just delete this OSF1v4 hack also now that Mark has added swap From jkrell at elego.de Sun Jul 18 18:00:56 2010 From: jkrell at elego.de (Jay Krell) Date: Sun, 18 Jul 2010 18:00:56 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100718160056.A9AA72474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/18 18:00:56 Modified files: cm3/m3-libs/m3core/src/win32/: m3makefile Log message: copy code from cm3cfg.common for compatibility I would prefer if the config files were updated fairly early in the build and my burden was to maintain compatiblity through them, not in m3makefiles otherwise. From jkrell at elego.de Sun Jul 18 18:03:00 2010 From: jkrell at elego.de (Jay Krell) Date: Sun, 18 Jul 2010 18:03:00 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100718160300.239C22474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/18 18:03:00 Modified files: cm3/m3-sys/cminstall/src/config-no-install/: cm3cfg.common Log message: require TARGET_OS to be defined; either bootstrap from 5.8.6 release or update older config files; we'll see if this flies, hopefully, but I might not like it myself, we'll see From jkrell at elego.de Mon Jul 19 03:23:16 2010 From: jkrell at elego.de (Jay Krell) Date: Mon, 19 Jul 2010 3:23:16 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100719012318.ABC2E2474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/19 03:23:16 Modified files: cm3/m3-sys/m3cc/src/: m3makefile cm3/m3-sys/m3cc/gcc/gcc/config/: darwin.h Log message: m3makefile, basically undo: Revision 1.162 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. Revision 1.161 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. darwin.h, undo Revision 1.2 always support hidden aka private extern aka don't export every function This should fix PPC_DARWIN and maybe maybe others (SPARC32_LINUX). Possibly relatd, I've noticed SOLsun using sparc-sun-solaris2.10-gcc to build cm3cg, when I was hoping it'd use Sun cc. This will at least change it to plain gcc, but same thing. From jkrell at elego.de Mon Jul 19 04:48:20 2010 From: jkrell at elego.de (Jay Krell) Date: Mon, 19 Jul 2010 4:48:20 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100719024822.CE20E2474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/19 04:48:20 Added files: cm3/www/uploaded-archives/: readme.txt Log message: Some notes I just made as to what "all", "min", and "boot" are. They should be reviewed, tested, edited, worked into the web page at: http://modula3.elegosoft.com/cm3/uploaded-archives/ From jkrell at elego.de Mon Jul 19 04:49:12 2010 From: jkrell at elego.de (Jay Krell) Date: Mon, 19 Jul 2010 4:49:12 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100719024913.4FBC82474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/19 04:49:12 Modified files: cm3/www/uploaded-archives/: readme.txt Log message: typo From jkrell at elego.de Mon Jul 19 04:50:00 2010 From: jkrell at elego.de (Jay Krell) Date: Mon, 19 Jul 2010 4:50:00 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100719025003.099082474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/19 04:50:00 Modified files: cm3/www/uploaded-archives/: readme.txt Log message: typos From jkrell at elego.de Mon Jul 19 04:55:54 2010 From: jkrell at elego.de (Jay Krell) Date: Mon, 19 Jul 2010 4:55:54 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100719025555.8ED6C2474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/19 04:55:54 Modified files: cm3/www/uploaded-archives/: readme.txt Log message: document problem with 'boot' that prevents its wider use e.g. in Hudson: it provides just cm3, but that cm3 is tied somewhat to a particular m3core and cm3cg, not as much as in the past, but still (e.g. if RTHooks.i3 or M3CG.i3 change); the dependency on m3core is easy to fix, by making a library from .o files produced here anyway, the dependency on cm3cg not so much From jkrell at elego.de Mon Jul 19 05:41:41 2010 From: jkrell at elego.de (Jay Krell) Date: Mon, 19 Jul 2010 5:41:41 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100719034141.C68F32474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/19 05:41:41 Modified files: cm3/m3-libs/m3core/src/: m3core.h Log message: should fix OpenBSD builds From jkrell at elego.de Mon Jul 19 05:46:00 2010 From: jkrell at elego.de (Jay Krell) Date: Mon, 19 Jul 2010 5:46:00 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100719034600.7A3C0CC37E@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/19 05:46:00 Modified files: cm3/scripts/python/: pylib.py Log message: put comment in Makefile for OSF1v4 users to act on From jkrell at elego.de Mon Jul 19 08:05:45 2010 From: jkrell at elego.de (Jay Krell) Date: Mon, 19 Jul 2010 8:05:45 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100719060546.261CE2474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/19 08:05:45 Modified files: cm3/m3-sys/m3cc/src/: m3makefile Added files: cm3/m3-sys/m3cc/src/: clean_marker.txt Log message: mechanism to let a checkin force subsequent builds to be clean: edit this clean_marker.txt file also cleanup the clean logic to just rm -rf build_dir/* From jkrell at elego.de Mon Jul 19 08:16:35 2010 From: jkrell at elego.de (Jay Krell) Date: Mon, 19 Jul 2010 8:16:35 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100719061636.0600B2474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/19 08:16:35 Modified files: cm3/m3-sys/m3cc/src/: clean_marker.txt m3makefile Log message: use the "new" quake builtins fs_lsfiles, fs_lsdirs, fs_rmrec and the old delete_file From jkrell at elego.de Mon Jul 19 08:19:19 2010 From: jkrell at elego.de (Jay Krell) Date: Mon, 19 Jul 2010 8:19:19 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100719061919.5D4882474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/19 08:19:19 Modified files: cm3/m3-sys/m3cc/src/: m3makefile Log message: remove use of if defined -- these are in the previous release now; we'll see how this goes -- requiring previous release From jkrell at elego.de Mon Jul 19 08:25:14 2010 From: jkrell at elego.de (Jay Krell) Date: Mon, 19 Jul 2010 8:25:14 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100719062515.0843F2474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/19 08:25:14 Modified files: cm3/m3-sys/m3cc/src/: m3makefile Log message: use TRUE and FALSE for boolean NOACTION instead of obscure "" and "T" From jkrell at elego.de Mon Jul 19 08:27:20 2010 From: jkrell at elego.de (Jay Krell) Date: Mon, 19 Jul 2010 8:27:20 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100719062720.98D112474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/19 08:27:20 Modified files: cm3/m3-sys/m3cc/gcc/gcc/: value-prof.c Log message: ../../gcc/gcc/value-prof.c: In function `tree_mod_subtract': ../../gcc/gcc/value-prof.c:831: warning: `bb3' might be used uninitialized in this function From jkrell at elego.de Mon Jul 19 09:05:15 2010 From: jkrell at elego.de (Jay Krell) Date: Mon, 19 Jul 2010 9:05:15 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100719070516.29BE42474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/19 09:05:15 Modified files: cm3/m3-sys/m3cc/gcc/gcc/: varasm.c Log message: ../../gcc/gcc/varasm.c: In function `const_rtx_hash_1': ../../gcc/gcc/varasm.c:3387: warning: right shift count >= width of type From jkrell at elego.de Tue Jul 20 12:49:45 2010 From: jkrell at elego.de (Jay Krell) Date: Tue, 20 Jul 2010 12:49:45 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100720104945.7428D2474005@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/20 12:49:45 Modified files: cm3/m3-db/odbc/src/: m3makefile Log message: check if configure_system_libs is defined before calling it From jkrell at elego.de Tue Jul 20 13:24:04 2010 From: jkrell at elego.de (Jay Krell) Date: Tue, 20 Jul 2010 13:24:04 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100720112404.81C642474005@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/20 13:24:04 Modified files: cm3/scripts/: sysinfo.sh Log message: This should fix the NT386/m3cc problem. Note however that I've churned sysinfo.sh a lot in head -- not with this commit, but earlier. From jkrell at elego.de Tue Jul 20 14:19:03 2010 From: jkrell at elego.de (Jay Krell) Date: Tue, 20 Jul 2010 14:19:03 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100720121903.5281D2474005@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/20 14:19:03 Modified files: cm3/m3-sys/cminstall/src/config-no-install/: OpenBSD.common cm3/m3-libs/m3core/src/runtime/common/: RTProcessC.c Log message: This should fix the hang on I386_OPENBSD. That only I'm seeing. (Hudson doesn't build enough, nobody else has reported it). It doesn't affect 5.8.6 release as that uses jmpbuf hacking for userthreads. The rewrite to use sigaltstack is new since then. RTProcessC.c: INTEGER __cdecl RTProcess__RegisterForkHandlers( ForkHandler prepare, ForkHandler parent, ForkHandler child) { >> big comment added /* FreeBSD < 6 lacks pthread_atfork. Would be good to use autoconf. * VMS lacks pthread_atfork? Would be good to use autoconf. * Win32 lacks pthread_atfork and fork. OK. * OpenBSD pthread_atfork causes us to need libpthread, and then * sigsuspend on 4.6/x86 hangs in the userthread code. * * I expect therefore cvsup is broken with user threads on these systems. * * OpenBSD we could fix by going back to jmpbuf hacking (see 5.8.6 release), * but it is nice to have portable code, and cvsup maybe is expendable (again, * only on OpenBSD). * * As well, for all Posix systems, we could implement * atfork ourselves, as long as we provide a fork() * wrapper that code uses. */ #if defined(_WIN32) \ || defined(__vms) \ || defined(__OpenBSD__) \ << this added || (defined(__FreeBSD__) && (__FreeBSD__ < 6)) return 0; #else >> add % LIBC: No pthreads, to avoid its sigsuspend that hangs. % See also RTProcess__RegisterForkHandlers. SYSTEM_LIBS{"LIBC"} = ["-lm"] From jkrell at elego.de Tue Jul 20 14:30:40 2010 From: jkrell at elego.de (Jay Krell) Date: Tue, 20 Jul 2010 14:30:40 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100720123040.B54572474005@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/20 14:30:40 Modified files: cm3/scripts/python/: upgrade.py Log message: I just introduced incompatibility between current openbsd config and older m3core -- the reference to pthread_atfork won't result, so, let's consider *not* updating config files so early -- this matches I believe what Hudson/Tinderbox do and *definitely* has good arguments in favor of it. From jkrell at elego.de Tue Jul 20 16:13:30 2010 From: jkrell at elego.de (Jay Krell) Date: Tue, 20 Jul 2010 16:13:30 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100720141330.E4B162474005@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/20 16:13:30 Modified files: cm3/m3-sys/cminstall/src/config-no-install/: OpenBSD.common Log message: add more X libraries so that solitaire builds (it is standalone) From jkrell at elego.de Wed Jul 21 12:27:11 2010 From: jkrell at elego.de (Jay Krell) Date: Wed, 21 Jul 2010 12:27:11 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100721102711.E2A8E2474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/21 12:27:11 Modified files: cm3/m3-sys/cminstall/src/config-no-install/: ALPHA_OSF Log message: set TARGET_OS=OSF (other names re reasonable) From jkrell at elego.de Wed Jul 21 12:28:29 2010 From: jkrell at elego.de (Jay Krell) Date: Wed, 21 Jul 2010 12:28:29 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100721102829.CE6742474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/21 12:28:29 Modified files: cm3/m3-sys/m3cc/src/: m3makefile Log message: building mips-tfile seems to fail on cross builds, like maybe the headers describing the object/symbol format aren't available? So only build it for native builds From jkrell at elego.de Wed Jul 21 12:48:29 2010 From: jkrell at elego.de (Jay Krell) Date: Wed, 21 Jul 2010 12:48:29 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100721104830.129C2CC389@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/21 12:48:29 Added files: cm3/m3-libs/m3core/src/unix/osf-1.ALPHA_OSF/: m3makefile Usignal.i3 Log message: bring back files, to try to get back setjmp-less exception handling From jkrell at elego.de Wed Jul 21 12:48:57 2010 From: jkrell at elego.de (Jay Krell) Date: Wed, 21 Jul 2010 12:48:57 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100721104857.4FE532474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/21 12:48:57 Modified files: cm3/m3-libs/m3core/src/unix/osf-1.ALPHA_OSF/: m3makefile Log message: edit it down From jkrell at elego.de Wed Jul 21 13:15:07 2010 From: jkrell at elego.de (Jay Krell) Date: Wed, 21 Jul 2010 13:15:07 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100721111507.2AE542474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/21 13:15:07 Modified files: cm3/scripts/python/: pylib.py Log message: fix typo on ALPHA_OSF From jkrell at elego.de Wed Jul 21 13:18:15 2010 From: jkrell at elego.de (Jay Krell) Date: Wed, 21 Jul 2010 13:18:15 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100721111815.8B16A2474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/21 13:18:15 Modified files: cm3/m3-libs/m3core/src/unix/: m3makefile cm3/m3-libs/m3core/src/unix/Common/: m3makefile cm3/m3-libs/m3core/src/unix/osf-1.ALPHA_OSF/: Usignal.i3 Log message: trim ALPHA_OSF/Usignal.i3 down to just an exact copy of Common/Usignal.i3 plus struct_sigcontext, enough, maybe more than enough, to compile the stack walking code (do we really need such an accurate Frame exposed to the Modula-3?) From jkrell at elego.de Wed Jul 21 14:33:38 2010 From: jkrell at elego.de (Jay Krell) Date: Wed, 21 Jul 2010 14:33:38 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100721123338.4B8992474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/21 14:33:38 Modified files: cm3/m3-libs/m3core/src/: m3core.h cm3/m3-libs/m3core/src/time/POSIX/: DatePosixC.c cm3/m3-libs/m3core/src/unix/: m3makefile Log message: Better perhaps for OSF/1. In particular, no longer need #ifdef M3_OSF1_V4. I #define _TIME64_T, and then I can tell if this system supports it by checking for defined(TIMEVAL64TO32) & TIMEVAL32TO64 From jkrell at elego.de Wed Jul 21 14:38:41 2010 From: jkrell at elego.de (Jay Krell) Date: Wed, 21 Jul 2010 14:38:41 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100721123841.903222474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/21 14:38:41 Modified files: cm3/m3-libs/m3core/src/unix/: m3makefile Log message: oops: fix ALPHA_OSF breakage From jkrell at elego.de Wed Jul 21 14:47:28 2010 From: jkrell at elego.de (Jay Krell) Date: Wed, 21 Jul 2010 14:47:28 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100721124728.3726F2474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/21 14:47:28 Modified files: cm3/m3-libs/m3core/src/unix/: m3makefile Log message: use TARGET_OS to shrink tables -- requires config file change from release 5.8.6 From jkrell at elego.de Wed Jul 21 14:48:38 2010 From: jkrell at elego.de (Jay Krell) Date: Wed, 21 Jul 2010 14:48:38 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100721124838.8BF0C2474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/21 14:48:38 Modified files: cm3/m3-libs/m3core/src/unix/: m3makefile Log message: whitespace From jkrell at elego.de Wed Jul 21 14:55:12 2010 From: jkrell at elego.de (Jay Krell) Date: Wed, 21 Jul 2010 14:55:12 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100721125512.609A92474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/21 14:55:12 Modified files: cm3/m3-libs/libm3/src/: m3makefile Removed files: cm3/m3-libs/libm3/src/: platforms.quake Log message: Eliminate extra platform lists now that 5.8.6 has shipped and its config files are the baseline. From jkrell at elego.de Wed Jul 21 17:26:52 2010 From: jkrell at elego.de (Jay Krell) Date: Wed, 21 Jul 2010 17:26:52 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100721152652.1C8712474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/21 17:26:52 Modified files: cm3/m3-sys/cminstall/src/config-no-install/: SPARC.common Log message: add -m32 to try to fix SPARC32_LINUX, add -funwind-tables in anticipation of libunwind, comment that -gstabs+ is only missing because we are chronically out of diskspace on the Hudson node (lame) From jkrell at elego.de Wed Jul 21 17:29:18 2010 From: jkrell at elego.de (Jay Krell) Date: Wed, 21 Jul 2010 17:29:18 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100721152918.8A6EB2474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/21 17:29:18 Modified files: cm3/m3-ui/PEX/src/: m3makefile Log message: only call configure_system_libs if it is defined (This is showing up in Hudson: e.g. http://hudson.modula3.com:8080/job/cm3-current-test-all-pkgs-SOLgnu From jkrell at elego.de Wed Jul 21 17:30:16 2010 From: jkrell at elego.de (Jay Krell) Date: Wed, 21 Jul 2010 17:30:16 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100721153016.48C6A2474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/21 17:30:16 Modified files: cm3/m3-ui/ui/src/xvbt/: m3makefile Log message: only call configure_system_libs if it is defined (This is showing up in Hudson: e.g. http://hudson.modula3.com:8080/job/cm3-current-test-all-pkgs-SOLgnu From jay.krell at cornell.edu Wed Jul 21 17:32:01 2010 From: jay.krell at cornell.edu (Jay K) Date: Wed, 21 Jul 2010 15:32:01 +0000 Subject: [M3commit] CVS Update: cm3 In-Reply-To: <20100721153016.48C6A2474003@birch.elegosoft.com> References: <20100721153016.48C6A2474003@birch.elegosoft.com> Message-ID: Hm, odd, this in cm3cfg.common if nowhere else. Something seems off. ?- Jay ---------------------------------------- > Date: Wed, 21 Jul 2010 17:30: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/07/21 17:30:16 > > Modified files: > cm3/m3-ui/ui/src/xvbt/: m3makefile > > Log message: > only call configure_system_libs if it is defined (This is showing up in Hudson: e.g. http://hudson.modula3.com:8080/job/cm3-current-test-all-pkgs-SOLgnu > From jkrell at elego.de Wed Jul 21 17:35:10 2010 From: jkrell at elego.de (Jay Krell) Date: Wed, 21 Jul 2010 17:35:10 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100721153510.982222474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/21 17:35:10 Modified files: cm3/m3-ui/PEX/src/: m3makefile Log message: undo: call configure_system_libs unconditionally, fix should be central, and code is already written correct-seeming From jkrell at elego.de Wed Jul 21 17:35:47 2010 From: jkrell at elego.de (Jay Krell) Date: Wed, 21 Jul 2010 17:35:47 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100721153547.670052474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/21 17:35:47 Modified files: cm3/m3-ui/ui/src/xvbt/: m3makefile Log message: undo: call configure_system_libs unconditionally, fix should be central, and code is already written correct-seeming From jkrell at elego.de Wed Jul 21 17:53:14 2010 From: jkrell at elego.de (Jay Krell) Date: Wed, 21 Jul 2010 17:53:14 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100721155314.E1BC6CC389@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/21 17:53:14 Modified files: cm3/scripts/: install-cm3-compiler.sh Log message: upgrade config files when upgrading compiler From jkrell at elego.de Wed Jul 21 17:54:15 2010 From: jkrell at elego.de (Jay Krell) Date: Wed, 21 Jul 2010 17:54:15 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100721155415.CAD312474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/21 17:54:15 Modified files: cm3/scripts/: install-cm3-compiler.sh Log message: mkdir more From jkrell at elego.de Wed Jul 21 17:58:10 2010 From: jkrell at elego.de (Jay Krell) Date: Wed, 21 Jul 2010 17:58:10 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100721155810.335512474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/21 17:58:10 Modified files: cm3/m3-sys/cminstall/src/config-no-install/: ALPHA_OSF cm3/scripts/python/: pylib.py Log message: remove -DM3_OSF1_V4 now that m3core.h figures it out From jay.krell at cornell.edu Wed Jul 21 18:30:56 2010 From: jay.krell at cornell.edu (Jay K) Date: Wed, 21 Jul 2010 16:30:56 +0000 Subject: [M3commit] CVS Update: cm3 In-Reply-To: <20100721155314.E1BC6CC389@birch.elegosoft.com> References: <20100721155314.E1BC6CC389@birch.elegosoft.com> Message-ID: I've manually updated the config files on SPARC32_LINUX Hudson node to try to fix this. ?- Jay ---------------------------------------- > Date: Wed, 21 Jul 2010 17:53: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/07/21 17:53:14 > > Modified files: > cm3/scripts/: install-cm3-compiler.sh > > Log message: > upgrade config files when upgrading compiler > From wagner at elego.de Wed Jul 21 22:39:32 2010 From: wagner at elego.de (Olaf Wagner) Date: Wed, 21 Jul 2010 22:39:32 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100721203932.B5C9D2474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: wagner at birch. 10/07/21 22:39:32 Modified files: cm3/scripts/: version version.quake Log message: fix version number on trunk for 5.9 development From wagner at elegosoft.com Thu Jul 22 08:53:23 2010 From: wagner at elegosoft.com (Olaf Wagner) Date: Thu, 22 Jul 2010 08:53:23 +0200 Subject: [M3commit] CVS Update: cm3 In-Reply-To: References: <20100721155314.E1BC6CC389@birch.elegosoft.com> Message-ID: <20100722085323.0nmmjnom94osso88@mail.elegosoft.com> Quoting Jay K : > I've manually updated the config files on SPARC32_LINUX Hudson node > to try to fix this. That should be done by the upgrade script (and it already was AFAIR). I wouldn't like the script shipping a newly built compiler to unconditionally overwrite all my local configuration. Olaf > > ?- Jay > > ---------------------------------------- >> Date: Wed, 21 Jul 2010 17:53: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/07/21 17:53:14 >> >> Modified files: >> cm3/scripts/: install-cm3-compiler.sh >> >> Log message: >> upgrade config files when upgrading compiler >> > -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From jay.krell at cornell.edu Thu Jul 22 09:08:45 2010 From: jay.krell at cornell.edu (Jay K) Date: Thu, 22 Jul 2010 07:08:45 +0000 Subject: [M3commit] CVS Update: cm3 In-Reply-To: <20100722085323.0nmmjnom94osso88@mail.elegosoft.com> References: <20100721155314.E1BC6CC389@birch.elegosoft.com>, , <20100722085323.0nmmjnom94osso88@mail.elegosoft.com> Message-ID: I thought it was too, before I looked at it. Could be that head and release are very divergent. I didn't look at release, oops. ? I probably will "soon". The config files are "partly part of the compiler", and partly system-specific. ?So they might have to be updated with the compiler. Perhaps we can have cm3.cfg.user or cm3.cfg.local, that we never edit, and maybe we should constrain it, like very line must have an equals sign, and if it has a percent, percent must follow equals. e.g. m3back_flags = "-custom" SYSTEM_CC = "custom" % comment blah blah SYSTEM_LIBS{"LIBC"} = "custom" SYSTEM_LIBORDER += [custom] But that might not be flexible enough. Another option is that cm3.cfg file do like: if exists("cm3.cfg.user.first") ? include("cm3.cfg.user.first") end ... if exists("cm3.cfg.user.last") ? include("cm3.cfg.user.last end which is infinitely flexible and not well defined. ?Even limiting to assignments is not well defined. ?You know, there's an interface somewhere in there, but it isn't well specified. My fault. ? I let things evolve and get discovered gradually, sometimes hard to know ahead of time what the result will be. ? I've made changes since 5.8.6 released such that config files from prior to 5.8.6 will not suffice. I can undo that, but there is an important policy and architecture question. ?- Jay ---------------------------------------- > Date: Thu, 22 Jul 2010 08:53:23 +0200 > From: wagner at elegosoft.com > To: m3commit at elegosoft.com > Subject: Re: [M3commit] CVS Update: cm3 > > Quoting Jay K : > > > I've manually updated the config files on SPARC32_LINUX Hudson node > > to try to fix this. > > That should be done by the upgrade script (and it already was AFAIR). > I wouldn't like the script shipping a newly built compiler to > unconditionally overwrite all my local configuration. > > Olaf > > > > > - Jay > > > > ---------------------------------------- > >> Date: Wed, 21 Jul 2010 17:53: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/07/21 17:53:14 > >> > >> Modified files: > >> cm3/scripts/: install-cm3-compiler.sh > >> > >> Log message: > >> upgrade config files when upgrading compiler > >> > > > > > > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 > From wagner at elegosoft.com Thu Jul 22 09:19:12 2010 From: wagner at elegosoft.com (Olaf Wagner) Date: Thu, 22 Jul 2010 09:19:12 +0200 Subject: [M3commit] CVS Update: cm3 In-Reply-To: References: <20100721155314.E1BC6CC389@birch.elegosoft.com>, , <20100722085323.0nmmjnom94osso88@mail.elegosoft.com> Message-ID: <20100722091912.bibr9p0z1q88wog4@mail.elegosoft.com> I can live with a cm3-local.cfg file which gets included when it exists, contains local overrides and is never touched by he installation. We have to be careful to backup existing configs and informing the users before the installation though. I think upgrade did backups of the config, too. Can you check the scripts in the release branch if anything needs to be merged back? I won't be able to do that today. Olaf Quoting Jay K : > I thought it was too, before I looked at it. > Could be that head and release are very divergent. > I didn't look at release, oops. > ? I probably will "soon". > > > The config files are "partly part of the compiler", and partly > system-specific. > ?So they might have to be updated with the compiler. > > > Perhaps we can have cm3.cfg.user or cm3.cfg.local, that we never edit, > and maybe we should constrain it, like very line > must have an equals sign, and if it has a percent, percent must > follow equals. > > > e.g. > m3back_flags = "-custom" > SYSTEM_CC = "custom" % comment blah blah > SYSTEM_LIBS{"LIBC"} = "custom" > SYSTEM_LIBORDER += [custom] > > But that might not be flexible enough. > > Another option is that cm3.cfg file do like: > if exists("cm3.cfg.user.first") > ? include("cm3.cfg.user.first") > end > ... > if exists("cm3.cfg.user.last") > > ? include("cm3.cfg.user.last > > end > > > > which is infinitely flexible and not well defined. > ?Even limiting to assignments is not well defined. > ?You know, there's an interface somewhere in there, but it isn't > well specified. My fault. > ? I let things evolve and get discovered gradually, sometimes hard > to know ahead of time what the result will be. > ? > > I've made changes since 5.8.6 released such that config files from > prior to 5.8.6 will not suffice. > I can undo that, but there is an important policy and architecture question. > > > ?- Jay > > ---------------------------------------- >> Date: Thu, 22 Jul 2010 08:53:23 +0200 >> From: wagner at elegosoft.com >> To: m3commit at elegosoft.com >> Subject: Re: [M3commit] CVS Update: cm3 >> >> Quoting Jay K : >> >> > I've manually updated the config files on SPARC32_LINUX Hudson node >> > to try to fix this. >> >> That should be done by the upgrade script (and it already was AFAIR). >> I wouldn't like the script shipping a newly built compiler to >> unconditionally overwrite all my local configuration. >> >> Olaf >> >> > >> > - Jay >> > >> > ---------------------------------------- >> >> Date: Wed, 21 Jul 2010 17:53: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/07/21 17:53:14 >> >> >> >> Modified files: >> >> cm3/scripts/: install-cm3-compiler.sh >> >> >> >> Log message: >> >> upgrade config files when upgrading compiler >> >> >> > >> >> >> >> -- >> Olaf Wagner -- elego Software Solutions GmbH >> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany >> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 >> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin >> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 >> > -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From jay.krell at cornell.edu Thu Jul 22 09:21:33 2010 From: jay.krell at cornell.edu (Jay K) Date: Thu, 22 Jul 2010 07:21:33 +0000 Subject: [M3commit] CVS Update: cm3 In-Reply-To: <20100722091912.bibr9p0z1q88wog4@mail.elegosoft.com> References: <20100721155314.E1BC6CC389@birch.elegosoft.com>, , , , <20100722085323.0nmmjnom94osso88@mail.elegosoft.com>, , <20100722091912.bibr9p0z1q88wog4@mail.elegosoft.com> Message-ID: (ps: the change I made does do the backup foo-date thing, parallel to cm3 and cm3cg yes I'll compare the branches, can't promise a full merge though) ---------------------------------------- > Date: Thu, 22 Jul 2010 09:19:12 +0200 > From: wagner at elegosoft.com > To: jay.krell at cornell.edu > CC: m3commit at elegosoft.com > Subject: Re: [M3commit] CVS Update: cm3 > > I can live with a cm3-local.cfg file which gets included when it exists, > contains local overrides and is never touched by he installation. > > We have to be careful to backup existing configs and informing the > users before the installation though. > > I think upgrade did backups of the config, too. > > Can you check the scripts in the release branch if anything needs > to be merged back? I won't be able to do that today. > > Olaf > > Quoting Jay K : > > > I thought it was too, before I looked at it. > > Could be that head and release are very divergent. > > I didn't look at release, oops. > > I probably will "soon". > > > > > > The config files are "partly part of the compiler", and partly > > system-specific. > > So they might have to be updated with the compiler. > > > > > > Perhaps we can have cm3.cfg.user or cm3.cfg.local, that we never edit, > > and maybe we should constrain it, like very line > > must have an equals sign, and if it has a percent, percent must > > follow equals. > > > > > > e.g. > > m3back_flags = "-custom" > > SYSTEM_CC = "custom" % comment blah blah > > SYSTEM_LIBS{"LIBC"} = "custom" > > SYSTEM_LIBORDER += [custom] > > > > But that might not be flexible enough. > > > > Another option is that cm3.cfg file do like: > > if exists("cm3.cfg.user.first") > > include("cm3.cfg.user.first") > > end > > ... > > if exists("cm3.cfg.user.last") > > > > include("cm3.cfg.user.last > > > > end > > > > > > > > which is infinitely flexible and not well defined. > > Even limiting to assignments is not well defined. > > You know, there's an interface somewhere in there, but it isn't > > well specified. My fault. > > I let things evolve and get discovered gradually, sometimes hard > > to know ahead of time what the result will be. > > > > > > I've made changes since 5.8.6 released such that config files from > > prior to 5.8.6 will not suffice. > > I can undo that, but there is an important policy and architecture question. > > > > > > - Jay > > > > ---------------------------------------- > >> Date: Thu, 22 Jul 2010 08:53:23 +0200 > >> From: wagner at elegosoft.com > >> To: m3commit at elegosoft.com > >> Subject: Re: [M3commit] CVS Update: cm3 > >> > >> Quoting Jay K : > >> > >> > I've manually updated the config files on SPARC32_LINUX Hudson node > >> > to try to fix this. > >> > >> That should be done by the upgrade script (and it already was AFAIR). > >> I wouldn't like the script shipping a newly built compiler to > >> unconditionally overwrite all my local configuration. > >> > >> Olaf > >> > >> > > >> > - Jay > >> > > >> > ---------------------------------------- > >> >> Date: Wed, 21 Jul 2010 17:53: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/07/21 17:53:14 > >> >> > >> >> Modified files: > >> >> cm3/scripts/: install-cm3-compiler.sh > >> >> > >> >> Log message: > >> >> upgrade config files when upgrading compiler > >> >> > >> > > >> > >> > >> > >> -- > >> Olaf Wagner -- elego Software Solutions GmbH > >> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > >> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 > >> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin > >> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 > >> > > > > > > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 > From jkrell at elego.de Thu Jul 22 15:51:06 2010 From: jkrell at elego.de (Jay Krell) Date: Thu, 22 Jul 2010 15:51:06 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100722135106.AF4EC2474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/22 15:51:06 Modified files: cm3/scripts/: install-cm3-compiler.sh Log message: fix insalling of config files, will require manual repair of Hudson nodes..but not, I should instead copy this code elsewhere to where Hudson will run it From jkrell at elego.de Thu Jul 22 16:01:26 2010 From: jkrell at elego.de (Jay Krell) Date: Thu, 22 Jul 2010 16:01:26 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100722140126.47A482474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/22 16:01:26 Modified files: cm3/scripts/regression/: defs.sh Log message: try repair missing config files From jkrell at elego.de Thu Jul 22 16:01:54 2010 From: jkrell at elego.de (Jay Krell) Date: Thu, 22 Jul 2010 16:01:54 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100722140154.41F972474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/22 16:01:54 Modified files: cm3/scripts/regression/: defs.sh Log message: try repair missing config files From jkrell at elego.de Thu Jul 22 16:59:48 2010 From: jkrell at elego.de (Jay Krell) Date: Thu, 22 Jul 2010 16:59:48 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100722145949.08E632474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/22 16:59:48 Modified files: cm3/m3-libs/m3core/src/time/POSIX/: TimePosixC.c Log message: Grain computation seems like a poorly implemented thing. I'm hoping we can replace it with something sysconf(?) or clock_getres. Experiments with clock_getres suggest no. It is often much larger than grain. Though it was close on Alpha/OSF I think. In the meantime: Historically we just computed grain once and accepted that value. Per the historical comment, that seemed not great. I changed it to loop until 2 or 3 grains were computed identically. I see this hang sometimes. Though seemingly only in slightly unusual situations like a cross build or Alpha/OSF or in a debugger. Anyway, let's try a different variation: Compute it a few times, and take the smallest value we find. I've tried up to 5 and it still varies from run to run on Alpha/OSF. So go down to just 3 since I can't win, and every computation takes time -- waiting for the time to progress. This still seems better than the historical behavior of one computation that might go very awry, and has the advantage over the replacement I had put in, which potentially could loop forever -- if grain was larger than scheduling interval, though nobody has reported that. From jkrell at elego.de Thu Jul 22 17:47:20 2010 From: jkrell at elego.de (Jay Krell) Date: Thu, 22 Jul 2010 17:47:20 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100722154721.92CABCC37E@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/22 17:47:20 Modified files: cm3/m3-sys/m3cc/gcc/gcc/: dse.c Log message: http://hudson.modula3.com:8080/job/cm3-current-m3cc-I386_DARWIN/2/consoleFull ../../gcc/gcc/dse.c:2766: warning: 'i' may be used uninitialized in this function From jkrell at elego.de Thu Jul 22 17:50:12 2010 From: jkrell at elego.de (Jay Krell) Date: Thu, 22 Jul 2010 17:50:12 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100722155013.5743F2474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/22 17:50:12 Modified files: cm3/m3-sys/m3cc/gcc/gcc/: ebitmap.c Log message: http://hudson.modula3.com:8080/job/cm3-current-m3cc-I386_DARWIN/2/consoleFull ebitmap.c: In function 'ebitmap_last_set_bit': ebitmap.c:89: warning: 'ebi.ptr' may be used uninitialized in this function ebitmap.c:89: warning: 'ebi.bit_num' may be used uninitialized in this function ebitmap.c:89: warning: 'ebi.eltnum' may be used uninitialized in this function ebitmap.c:89: warning: 'ebi.word' may be used uninitialized in this function ebitmap.h:124: warning: 'ourn' may be used uninitialized in this function ebitmap.c: In function 'ebitmap_ior_into': ebitmap.c:549: warning: 'i' may be used uninitialized in this function ebitmap.c: In function 'ebitmap_ior': ebitmap.c:673: warning: 'i' may be used uninitialized in this function ebitmap.c: In function 'ebitmap_and_compl': ebitmap.c:871: warning: 'i' may be used uninitialized in this function ebitmap.c: In function 'ebitmap_and_into': ebitmap.c:420: warning: 'i' may be used uninitialized in this function ebitmap.c: In function 'ebitmap_and': ebitmap.c:474: warning: 'i' may be used uninitialized in this function ebitmap.c: In function 'ebitmap_and_compl_into': ebitmap.c:791: warning: 'i' may be used uninitialized in this function From jkrell at elego.de Thu Jul 22 17:52:14 2010 From: jkrell at elego.de (Jay Krell) Date: Thu, 22 Jul 2010 17:52:14 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100722155214.B2DCF2474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/22 17:52:14 Modified files: cm3/m3-sys/m3cc/gcc/gcc/: tree-ssa-structalias.c Log message: http://hudson.modula3.com:8080/job/cm3-current-m3cc-I386_DARWIN/2/consoleFull tree-ssa-structalias.c:4811: warning: 'j' may be used uninitialized in this function From jkrell at elego.de Thu Jul 22 17:54:25 2010 From: jkrell at elego.de (Jay Krell) Date: Thu, 22 Jul 2010 17:54:25 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100722155425.C625C2474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/22 17:54:25 Modified files: cm3/m3-sys/m3cc/gcc/gcc/: ipa-struct-reorg.c Log message: http://hudson.modula3.com:8080/job/cm3-current-m3cc-I386_DARWIN/2/consoleFull ipa-struct-reorg.c:3540: warning: 'i' may be used uninitialized in this function From jkrell at elego.de Thu Jul 22 23:24:35 2010 From: jkrell at elego.de (Jay Krell) Date: Thu, 22 Jul 2010 23:24:35 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100722212435.F2CDB2474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/22 23:24:35 Modified files: cm3/m3-sys/m3cc/src/: m3makefile Log message: experiment that only affects SPARC32_LINUX From jkrell at elego.de Fri Jul 23 09:04:07 2010 From: jkrell at elego.de (Jay Krell) Date: Fri, 23 Jul 2010 9:04:07 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100723070407.9F30BCC37F@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/23 09:04:07 Modified files: cm3/m3-sys/cm3/test/src/: t.m3 Log message: Backward slashes confuse the test harness, so print them as tildes instead. From jkrell at elego.de Fri Jul 23 09:10:43 2010 From: jkrell at elego.de (Jay Krell) Date: Fri, 23 Jul 2010 9:10:43 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100723071044.C06E42474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/23 09:10:43 Modified files: cm3/m3-sys/cm3/test/src/: m3makefile Log message: build standalone From jkrell at elego.de Fri Jul 23 09:15:59 2010 From: jkrell at elego.de (Jay Krell) Date: Fri, 23 Jul 2010 9:15:59 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100723071600.83EA62474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/23 09:15:59 Modified files: cm3/m3-libs/patternmatching/tests/src/: m3makefile Log message: standalone From jkrell at elego.de Fri Jul 23 09:28:10 2010 From: jkrell at elego.de (Jay Krell) Date: Fri, 23 Jul 2010 9:28:10 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100723072847.8D8982474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/23 09:28:10 Modified files: cm3/m3-libs/patternmatching/tests/: tests.input Log message: Double backslash causing \x8 to appear in output. Comment out this case. (It works fine at the console, but not within Hudson.) From wagner at elego.de Fri Jul 23 18:08:12 2010 From: wagner at elego.de (Olaf Wagner) Date: Fri, 23 Jul 2010 18:08:12 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100723160815.7FCAA2474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: wagner at birch. 10/07/23 18:08:12 Modified files: cm3/scripts/: pkgmap.sh Log message: disabling non-working quote_xml for a while as in the release branch From wagner at elego.de Fri Jul 23 20:13:21 2010 From: wagner at elego.de (Olaf Wagner) Date: Fri, 23 Jul 2010 20:13:21 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100723181321.B2C082474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: wagner at birch. 10/07/23 20:13:21 Modified files: cm3/m3-sys/m3tests/: PkgTags cm3/m3-sys/m3tests/src/e0/e026/: stdout.build cm3/m3-sys/m3tests/src/r0/r004/: stderr.pgm Log message: merge some fixes from release branch From wagner at elego.de Fri Jul 23 20:14:24 2010 From: wagner at elego.de (Olaf Wagner) Date: Fri, 23 Jul 2010 20:14:24 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100723181424.636112474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: wagner at birch. 10/07/23 20:14:24 Modified files: cm3/m3-libs/sysutils/src/: FSUtils.m3 Log message: add OSError arguments to exception text From jkrell at elego.de Fri Jul 23 21:39:35 2010 From: jkrell at elego.de (Jay Krell) Date: Fri, 23 Jul 2010 21:39:35 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100723193935.59B3C2474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/23 21:39:35 Modified files: cm3/m3-libs/patternmatching/tests/: tests.input Log message: put back since Olaf removed broken xml quoting From jkrell at elego.de Fri Jul 23 21:41:34 2010 From: jkrell at elego.de (Jay Krell) Date: Fri, 23 Jul 2010 21:41:34 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100723194134.C48722474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/23 21:41:34 Modified files: cm3/m3-sys/cm3/test/src/: t.m3 Log message: put back since Olaf disabled the xml quoting From jkrell at elego.de Sat Jul 24 16:16:26 2010 From: jkrell at elego.de (Jay Krell) Date: Sat, 24 Jul 2010 16:16:26 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100724141626.49E402474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/24 16:16:26 Modified files: cm3/m3-libs/m3core/src/: m3core.h cm3/m3-libs/m3core/src/runtime/POSIX/: RTSignalC.c cm3/m3-libs/m3core/src/runtime/common/: RTProcessC.c cm3/m3-libs/m3core/src/thread/POSIX/: ThreadPosixC.c cm3/m3-libs/m3core/src/unix/Common/: m3makefile cm3/m3-sys/cminstall/src/config-no-install/: OpenBSD.common Added files: cm3/m3-libs/m3core/src/unix/Common/context/: m3makefile cm3/m3-libs/m3core/src/unix/Common/context/setjmp/: m3makefile context.h context.c Log message: restore jmpbuf munging for OpenBSD/i386, from 5.8.6 release There is code here for other platforms but it isn't used. There is code here for other OpenBSD platforms, but isn't used currectly. It might be good to smush the unix/setjmp directory into thread/POSIX/openbsd_context.[ch]. It *is* in a sense "unix", because it adheres to the Posix make/get/set/swapcontext functions, except I rename them and the header. From jkrell at elego.de Sat Jul 24 16:26:06 2010 From: jkrell at elego.de (Jay Krell) Date: Sat, 24 Jul 2010 16:26:06 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100724142606.D11742474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/24 16:26:06 Modified files: cm3/m3-sys/m3tests/src/p2/p240/: m3makefile Log message: maybe fix flags on this file? (no diff) From jkrell at elego.de Sat Jul 24 16:27:17 2010 From: jkrell at elego.de (Jay Krell) Date: Sat, 24 Jul 2010 16:27:17 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100724142717.DADCC2474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/24 16:27:17 Modified files: cm3/m3-sys/m3tests/src/p2/p230/: m3makefile Log message: maybe fix flags on this file? (no diff, I had an at sign in ls -l)) From jkrell at elego.de Sat Jul 24 16:27:55 2010 From: jkrell at elego.de (Jay Krell) Date: Sat, 24 Jul 2010 16:27:55 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100724142755.1EDC22474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/24 16:27:55 Modified files: cm3/m3-sys/m3tests/src/: m3makefile Log message: maybe fix flags on this file? (no diff, I had an at sign in ls -l)) From jkrell at elego.de Sat Jul 24 16:28:32 2010 From: jkrell at elego.de (Jay Krell) Date: Sat, 24 Jul 2010 16:28:32 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100724142832.49A302474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/24 16:28:32 Modified files: cm3/m3-sys/m3tests/src/p2/p242/: m3makefile Main.m3 Log message: maybe fix flags on this file? (no diff, I had an at sign in ls -l)) From jkrell at elego.de Sat Jul 24 16:29:15 2010 From: jkrell at elego.de (Jay Krell) Date: Sat, 24 Jul 2010 16:29:15 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100724142915.5EF7F2474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/24 16:29:15 Modified files: cm3/m3-sys/m3tests/src/p2/p243/: m3makefile Main.m3 Log message: maybe fix flags on this file? (no diff, I had an at sign in ls -l)) From jkrell at elego.de Sat Jul 24 16:29:55 2010 From: jkrell at elego.de (Jay Krell) Date: Sat, 24 Jul 2010 16:29:55 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100724142957.9CC1F2474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/24 16:29:55 Modified files: cm3/m3-sys/m3tests/src/p2/p244/: m3makefile Main.m3 Log message: maybe fix flags on this file? (no diff, I had an at sign in ls -l)) From jkrell at elego.de Sat Jul 24 16:30:25 2010 From: jkrell at elego.de (Jay Krell) Date: Sat, 24 Jul 2010 16:30:25 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100724143025.DDFFA2474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/24 16:30:25 Modified files: cm3/m3-sys/m3tests/src/p2/p246/: m3makefile Main.m3 Log message: maybe fix flags on this file? (no diff, I had an at sign in ls -l)) From jkrell at elego.de Sat Jul 24 16:33:16 2010 From: jkrell at elego.de (Jay Krell) Date: Sat, 24 Jul 2010 16:33:16 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100724143316.86F3B2474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/24 16:33:16 Modified files: cm3/m3-sys/m3cc/gcc/gcc/: tree-ssa-forwprop.c Log message: tree-ssa-forwprop.c: In function `forward_propagate_into_cond': tree-ssa-forwprop.c:362: warning: `name' might be used uninitialized in this function From hosking at cs.purdue.edu Sat Jul 24 19:42:06 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sat, 24 Jul 2010 13:42:06 -0400 Subject: [M3commit] CVS Update: cm3 In-Reply-To: <20100724143316.86F3B2474003@birch.elegosoft.com> References: <20100724143316.86F3B2474003@birch.elegosoft.com> Message-ID: <10A6AF46-03F8-4FE5-9833-BC22FE161758@cs.purdue.edu> Do we really want to dirty the gcc diffs from the original sources in this way. It will make sifting the diffs a nightmare for future ports. 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 24 Jul 2010, at 16:33, Jay Krell wrote: > CVSROOT: /usr/cvs > Changes by: jkrell at birch. 10/07/24 16:33:16 > > Modified files: > cm3/m3-sys/m3cc/gcc/gcc/: tree-ssa-forwprop.c > > Log message: > tree-ssa-forwprop.c: In function `forward_propagate_into_cond': > tree-ssa-forwprop.c:362: warning: `name' might be used uninitialized in this function -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sun Jul 25 03:57:55 2010 From: jay.krell at cornell.edu (Jay K) Date: Sun, 25 Jul 2010 01:57:55 +0000 Subject: [M3commit] CVS Update: cm3 In-Reply-To: <10A6AF46-03F8-4FE5-9833-BC22FE161758@cs.purdue.edu> References: <20100724143316.86F3B2474003@birch.elegosoft.com>, <10A6AF46-03F8-4FE5-9833-BC22FE161758@cs.purdue.edu> Message-ID: I'm pretty sure the three way merge I did will tolerate it ok. A human should tolerate it easily too. I don't look through the CVS history to find the diffs, I diff against baseline gcc 4.3.0, 4.3.5, etc. ? (btw, in doing so, I found another label thing we did, have to come back to 4.5.0 work soon..) But if you insist, ok. ?- Jay ________________________________ > From: hosking at cs.purdue.edu > Date: Sat, 24 Jul 2010 13:42:06 -0400 > To: jkrell at elego.de > CC: m3commit at elegosoft.com > Subject: Re: [M3commit] CVS Update: cm3 > > Do we really want to dirty the gcc diffs from the original sources in > this way. It will make sifting the diffs a nightmare for future ports. > > 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 24 Jul 2010, at 16:33, Jay Krell wrote: > > CVSROOT: /usr/cvs > Changes by: jkrell at birch. 10/07/24 16:33:16 > > Modified files: > cm3/m3-sys/m3cc/gcc/gcc/: tree-ssa-forwprop.c > > Log message: > tree-ssa-forwprop.c: In function `forward_propagate_into_cond': > tree-ssa-forwprop.c:362: warning: `name' might be used uninitialized in > this function > From jkrell at elego.de Sun Jul 25 13:52:25 2010 From: jkrell at elego.de (Jay Krell) Date: Sun, 25 Jul 2010 13:52:25 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100725115225.ED7532474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/25 13:52:25 Added files: cm3/m3-libs/m3core/src/unix/Common/context/setjmp/: config.c tcontext.c Makefile Log message: bring back deleted files From jkrell at elego.de Mon Jul 26 08:40:22 2010 From: jkrell at elego.de (Jay Krell) Date: Mon, 26 Jul 2010 8:40:22 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100726064022.4A981CC397@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/26 08:40:22 Modified files: cm3/m3-libs/m3core/src/unix/Common/context/setjmp/: Makefile config.c context.c context.h tcontext.c Added files: cm3/m3-libs/m3core/src/unix/Common/context/setjmp/: context_mips64.s Log message: adapt to MIPS64EL_OPENBSD (Gdium laptop, Loongson processor) From jkrell at elego.de Mon Jul 26 10:24:47 2010 From: jkrell at elego.de (Jay Krell) Date: Mon, 26 Jul 2010 10:24:47 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100726082447.B356DCC37E@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/26 10:24:47 Added files: cm3/m3-libs/m3core/src/thread/PTHREAD/: ThreadOpenBSD.c Log message: let's revisit pthreads on OpenBSD From jkrell at elego.de Mon Jul 26 10:34:08 2010 From: jkrell at elego.de (Jay Krell) Date: Mon, 26 Jul 2010 10:34:08 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100726083409.02B7F2474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/26 10:34:08 Modified files: cm3/m3-libs/m3core/src/: m3makefile Removed files: cm3/m3-libs/m3core/src/: platforms.quake Log message: remove platforms lists -- the data comes from each platform's config file now From jkrell at elego.de Mon Jul 26 13:50:14 2010 From: jkrell at elego.de (Jay Krell) Date: Mon, 26 Jul 2010 13:50:14 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100726115014.D2D432474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/26 13:50:14 Modified files: cm3/m3-libs/m3core/src/thread/PTHREAD/: ThreadOpenBSD.c ThreadPThreadC.c m3makefile Log message: Hypothetical fixes for OpenBSD to use pthreads. It compiles and links, but then I get assertion failures in RTCollector.m3. Not going to debug it for now, for a while. From jkrell at elego.de Mon Jul 26 13:51:52 2010 From: jkrell at elego.de (Jay Krell) Date: Mon, 26 Jul 2010 13:51:52 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100726115152.C1ABB2474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/26 13:51:52 Modified files: cm3/m3-libs/m3core/src/thread/PTHREAD/: test_interix.c Log message: add comment to the top explaining the file From jkrell at elego.de Mon Jul 26 13:53:40 2010 From: jkrell at elego.de (Jay Krell) Date: Mon, 26 Jul 2010 13:53:40 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100726115340.D84082474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/26 13:53:40 Modified files: cm3/m3-libs/m3core/src/thread/PTHREAD/: ThreadFreeBSD.c Log message: add a comment explaining what I believe is a true deficiency of this code: it scans the entire stack, not just the part starting at the current stack pointer From jkrell at elego.de Mon Jul 26 13:55:17 2010 From: jkrell at elego.de (Jay Krell) Date: Mon, 26 Jul 2010 13:55:17 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100726115517.D6C8CCC37E@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/26 13:55:17 Modified files: cm3/m3-sys/cminstall/src/config-no-install/: OpenBSD.common Log message: Stop using -static. It breaks pthreads. Pthreads appear to have other (not debugged) problems so I'm not using them anyway, but what I found just makes me more nervous about -static. The reason -static was used here is that OpenBSD is apparently aggressive about breaking things from release to release. In particular, like, libc.so gets renamed every time From jkrell at elego.de Mon Jul 26 14:12:32 2010 From: jkrell at elego.de (Jay Krell) Date: Mon, 26 Jul 2010 14:12:32 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100726121232.87690CC37E@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/26 14:12:32 Modified files: cm3/m3-libs/m3core/src/unix/Common/context/setjmp/: Makefile context.c Log message: restore OpenBSD/powerpc to working From jkrell at elego.de Mon Jul 26 14:31:09 2010 From: jkrell at elego.de (Jay Krell) Date: Mon, 26 Jul 2010 14:31:09 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100726123109.8168BCC37E@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/26 14:31:09 Modified files: cm3/m3-libs/m3core/src/thread/PTHREAD/: ThreadPThreadC.c Log message: tweak the OpenBSD fix (resolving diffs across my machines) From jkrell at elego.de Mon Jul 26 14:34:22 2010 From: jkrell at elego.de (Jay Krell) Date: Mon, 26 Jul 2010 14:34:22 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100726123422.A3B93CC37E@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/26 14:34:22 Modified files: cm3/m3-libs/m3core/src/: m3makefile cm3/m3-libs/m3core/src/thread/: m3makefile Removed files: cm3/m3-libs/m3core/src/: thread.quake Log message: Tweak the determination of user threads vs. pthreads. The logic is: NT, Win32, Mingw, Cygwin => Win32 FreeBSD4 (really, 4, not I386_FREEBSD), OpenBSD => user threads -DNOPTHREAD => user threads else => pthreads There is no longer a list of platforms, but one can easily add it here, using ({"plat1", "plat2"} contains TARGET) or such. As well, the config files should probably say, e.g.: ThreadLibrary = "user" or PosixUserThreads = TRUE Really, in the config files. Though src/m3makefile might warn/error for known not to work things like user threads on NT for example. From jkrell at elego.de Mon Jul 26 15:03:55 2010 From: jkrell at elego.de (Jay Krell) Date: Mon, 26 Jul 2010 15:03:55 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100726130355.48D2A2474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/26 15:03:55 Modified files: cm3/m3-sys/m3cc/src/: platforms.quake Log message: remove duplicate PPC64_DARWIN, and add version '6' to the end of it From jkrell at elego.de Mon Jul 26 15:14:40 2010 From: jkrell at elego.de (Jay Krell) Date: Mon, 26 Jul 2010 15:14:40 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100726131441.006C92474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/26 15:14:40 Modified files: cm3/m3-sys/cminstall/src/config-no-install/: MIPS64_OPENBSD Log message: just comments/whitespace From jkrell at elego.de Mon Jul 26 15:15:41 2010 From: jkrell at elego.de (Jay Krell) Date: Mon, 26 Jul 2010 15:15:41 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100726131541.814CECC37F@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/26 15:15:41 Modified files: cm3/m3-sys/cminstall/src/config-no-install/: MIPS64_OPENBSD Log message: actually previous had an important typo fix as well: 'table' vs. 'tables', to actually disable the tables, which the generation of leads to assertion failures in the backend, for this target (and its little endian sibling) From jkrell at elego.de Mon Jul 26 15:30:09 2010 From: jkrell at elego.de (Jay Krell) Date: Mon, 26 Jul 2010 15:30:09 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100726133009.A4B652474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/26 15:30:09 Modified files: cm3/m3-libs/m3core/src/unix/Common/context/setjmp/: m3makefile Log message: compile this for all OpenBSD platforms (granted, sparc64 not tested in a while, amd64 maybe never finished? but mips64, powerpc, x86 appear good; need to try sigaltstack again though) From jkrell at elego.de Mon Jul 26 15:40:14 2010 From: jkrell at elego.de (Jay Krell) Date: Mon, 26 Jul 2010 15:40:14 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100726134014.5D94F2474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/26 15:40:14 Modified files: cm3/m3-sys/cminstall/src/config-no-install/: OpenBSD.common Log message: remove X11 libraries that I think were only needed if using -static From jkrell at elego.de Mon Jul 26 15:42:31 2010 From: jkrell at elego.de (Jay Krell) Date: Mon, 26 Jul 2010 15:42:31 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100726134231.6E0832474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/26 15:42:31 Modified files: cm3/m3-sys/cminstall/src/config-no-install/: Interix.common PPC32_OPENBSD Unix.common Log message: disable shared on PPC32_OPENBSD, it has problems move the disabling of shared on Interix to Interix.common instead of having Unix.common know about it, by making there be another function interfacing among the config files: proc AdjustShared(shared) takes a boolean as to if shared was requested and returns a boolean as to if should really be shared. e.g.: false on Interix and PPC32_OPENBSD the default is false if using an older cm3 else whatever is input on curent cm3 ("older" is defined by probing for a symbol added in 5.8.6); this is more relevant if mixing current config files with older cm3, which historically I have often done, though it can be problematic From jkrell at elego.de Mon Jul 26 15:44:59 2010 From: jkrell at elego.de (Jay Krell) Date: Mon, 26 Jul 2010 15:44:59 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100726134459.CD4E32474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/26 15:44:59 Modified files: cm3/m3-libs/m3core/src/atomic/: m3makefile cm3/m3-libs/m3core/src/runtime/common/: Compiler.tmpl cm3/m3-libs/m3core/src/unix/Common/context/setjmp/: m3makefile cm3/m3-sys/m3cc/src/: platforms.quake cm3/m3-sys/m3middle/src/: Target.i3 Target.m3 cm3/scripts/: sysinfo.sh cm3/scripts/python/: pylib.py Added files: cm3/m3-libs/m3core/src/C/MIPS64EL_OPENBSD/: Csetjmp.i3 m3makefile cm3/m3-sys/cminstall/src/config-no-install/: MIPS64EL_OPENBSD Log message: add MIPS64EL_OPENBSD (e.g. Loongon/Gdium/Lemote) complete with: no atomics for 1 byte or 2 bytes no unwind tables (internal compiler error) These are for hypothetical future better exception handling, so ok. no debug symbols (there was a problem?) Should try again. user mode threads and worse, jmpbuf hacking need to try again the sigaltstack approach no Java => no Hudson Enough to build a cm3 that reports the expected "unable to find cm3.cfg". see: http://www.openbsd.org/loongson.html search web for: "Amazon gdium" etc. Presumably MIPS64EL_LINUX will fair a bit better. From jay.krell at cornell.edu Mon Jul 26 15:48:06 2010 From: jay.krell at cornell.edu (Jay K) Date: Mon, 26 Jul 2010 13:48:06 +0000 Subject: [M3commit] CVS Update: cm3 In-Reply-To: <20100726134459.CD4E32474003@birch.elegosoft.com> References: <20100726134459.CD4E32474003@birch.elegosoft.com> Message-ID: attached ---------------------------------------- > Date: Mon, 26 Jul 2010 15:44: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/07/26 15:44:59 > > Modified files: > cm3/m3-libs/m3core/src/atomic/: m3makefile > cm3/m3-libs/m3core/src/runtime/common/: Compiler.tmpl > cm3/m3-libs/m3core/src/unix/Common/context/setjmp/: m3makefile > cm3/m3-sys/m3cc/src/: platforms.quake > cm3/m3-sys/m3middle/src/: Target.i3 Target.m3 > cm3/scripts/: sysinfo.sh > cm3/scripts/python/: pylib.py > Added files: > cm3/m3-libs/m3core/src/C/MIPS64EL_OPENBSD/: Csetjmp.i3 > m3makefile > cm3/m3-sys/cminstall/src/config-no-install/: MIPS64EL_OPENBSD > > Log message: > add MIPS64EL_OPENBSD (e.g. Loongon/Gdium/Lemote) > complete with: > no atomics for 1 byte or 2 bytes > no unwind tables (internal compiler error) > These are for hypothetical future better exception handling, so ok. > no debug symbols (there was a problem?) > Should try again. > user mode threads > and worse, jmpbuf hacking > need to try again the sigaltstack approach > no Java => no Hudson > > Enough to build a cm3 that reports the expected "unable to find cm3.cfg". > > see: > http://www.openbsd.org/loongson.html > search web for: "Amazon gdium" > etc. > > Presumably MIPS64EL_LINUX will fair a bit better. > -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: mips64el_openbsd.txt URL: From wagner at elego.de Tue Jul 27 07:21:20 2010 From: wagner at elego.de (Olaf Wagner) Date: Tue, 27 Jul 2010 7:21:20 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100727052120.50A7D2474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: wagner at birch. 10/07/27 07:21:20 Modified files: cm3/m3-sys/m3tests/src/: m3makefile Log message: list build dir before removal From jkrell at elego.de Tue Jul 27 08:51:53 2010 From: jkrell at elego.de (Jay Krell) Date: Tue, 27 Jul 2010 8:51:53 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100727065153.C7D342474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/27 08:51:53 Added files: cm3/m3-libs/m3core/src/thread/POSIX/: test_thread_sigaltstack.c Log message: add test case, it only hangs on OpenBSD with -pthread!" From jkrell at elego.de Tue Jul 27 08:58:56 2010 From: jkrell at elego.de (Jay Krell) Date: Tue, 27 Jul 2010 8:58:56 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100727065856.8BA362474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/27 08:58:56 Modified files: cm3/m3-libs/m3core/src/thread/POSIX/: test_thread_sigaltstack.c Log message: reduce From jkrell at elego.de Wed Jul 28 12:32:51 2010 From: jkrell at elego.de (Jay Krell) Date: Wed, 28 Jul 2010 12:32:51 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100728103310.D81982474006@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/28 12:32:51 Modified files: cm3/m3-libs/m3core/src/thread/: m3makefile Log message: copy in stuff from cm3cfg.common, until it is updated From jkrell at elego.de Wed Jul 28 13:01:29 2010 From: jkrell at elego.de (Jay Krell) Date: Wed, 28 Jul 2010 13:01:29 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100728110129.D9C8CCC37E@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/28 13:01:29 Modified files: cm3/m3-libs/sysutils/src/: FSUtils.m3 Log message: add some debugprint From jkrell at elego.de Wed Jul 28 13:03:15 2010 From: jkrell at elego.de (Jay Krell) Date: Wed, 28 Jul 2010 13:03:15 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100728110315.9C8F6CC37F@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/28 13:03:15 Modified files: cm3/m3-libs/sysutils/src/: FSUtils.m3 Log message: add more debugprint From jkrell at elego.de Wed Jul 28 13:10:22 2010 From: jkrell at elego.de (Jay Krell) Date: Wed, 28 Jul 2010 13:10:22 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100728111022.9AB6A2474006@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/28 13:10:22 Modified files: cm3/m3-sys/m3cc/src/: m3makefile Log message: just because it is what other code did, get just the leaf name and form the full path ourselves (this is related to rmrec failures) From jkrell at elego.de Wed Jul 28 13:22:40 2010 From: jkrell at elego.de (Jay Krell) Date: Wed, 28 Jul 2010 13:22:40 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100728112240.735B32474006@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/28 13:22:40 Modified files: cm3/m3-sys/m3cc/src/: m3makefile Log message: manually delete gmp with exec(rm -rf) From jkrell at elego.de Wed Jul 28 13:23:09 2010 From: jkrell at elego.de (Jay Krell) Date: Wed, 28 Jul 2010 13:23:09 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100728112309.71F972474006@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/28 13:23:09 Modified files: cm3/m3-sys/m3cc/src/: m3makefile Log message: add comment to the exec(rm -rf gmp) From jkrell at elego.de Wed Jul 28 14:02:56 2010 From: jkrell at elego.de (Jay Krell) Date: Wed, 28 Jul 2010 14:02:56 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100728120258.5A3F62474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/28 14:02:56 Modified files: cm3/m3-sys/m3cc/src/: m3makefile Log message: m3makefile From jkrell at elego.de Wed Jul 28 14:04:02 2010 From: jkrell at elego.de (Jay Krell) Date: Wed, 28 Jul 2010 14:04:02 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100728120441.BC29A2474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/28 14:04:02 Modified files: cm3/m3-sys/m3cc/src/: m3makefile Log message: flubbed previous commit, comment was to be: sparc32_linux: remove the configure -with-cpu=v8 put back -target=sparc-linux config file will and needs to say -mcpu=v9 (tested via gcc -mcpu=v8 and -mcpu=v9 and using an atomic function) My Debian gcc 4.3 was configured as: --with-cpu=v8 --with-long-double-128 --build=sparc-linux-gnu --host=sparc-linux-gnu --target=sparc-linux-gnu among others. (notice: -with-long-double-128 -- something we want for Modula-3 also..) From jkrell at elego.de Wed Jul 28 14:10:49 2010 From: jkrell at elego.de (Jay Krell) Date: Wed, 28 Jul 2010 14:10:49 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100728121049.9A5572474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/28 14:10:49 Modified files: cm3/m3-sys/m3cc/src/: m3makefile Log message: go back to full paths from fs_lsdirs/files From jkrell at elego.de Wed Jul 28 14:14:42 2010 From: jkrell at elego.de (Jay Krell) Date: Wed, 28 Jul 2010 14:14:42 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100728121447.ED8DF2474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/28 14:14:42 Modified files: cm3/scripts/: install-cm3-compiler.sh Log message: try set -e; set -x here, so we can see e.g. upgrading the compiler upgrade the config files From jay.krell at cornell.edu Wed Jul 28 14:20:43 2010 From: jay.krell at cornell.edu (Jay K) Date: Wed, 28 Jul 2010 12:20:43 +0000 Subject: [M3commit] CVS Update: cm3 In-Reply-To: <20100728120441.BC29A2474003@birch.elegosoft.com> References: <20100728120441.BC29A2474003@birch.elegosoft.com> Message-ID: And even this comment was wrong: it had said -with-cpu=v9 not v8. ?- Jay ---------------------------------------- > Date: Wed, 28 Jul 2010 14:04:02 +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/07/28 14:04:02 > > Modified files: > cm3/m3-sys/m3cc/src/: m3makefile > > Log message: > flubbed previous commit, comment was to be: > sparc32_linux: remove the configure -with-cpu=v8 > put back -target=sparc-linux > > config file will and needs to say -mcpu=v9 > (tested via gcc -mcpu=v8 and -mcpu=v9 and using an atomic function) > > My Debian gcc 4.3 was configured as: > --with-cpu=v8 --with-long-double-128 --build=sparc-linux-gnu --host=sparc-linux-gnu --target=sparc-linux-gnu > > among others. (notice: -with-long-double-128 -- something we want for Modula-3 also..) > From jkrell at elego.de Wed Jul 28 14:28:37 2010 From: jkrell at elego.de (Jay Krell) Date: Wed, 28 Jul 2010 14:28:37 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100728122848.8145F2474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/28 14:28:37 Modified files: cm3/doc/notes/: todo.txt Log message: some updates From jkrell at elego.de Wed Jul 28 14:31:15 2010 From: jkrell at elego.de (Jay Krell) Date: Wed, 28 Jul 2010 14:31:15 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100728123122.2871ECC110@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/28 14:31:15 Modified files: cm3/doc/notes/: todo.txt Log message: some updates From jkrell at elego.de Wed Jul 28 14:32:14 2010 From: jkrell at elego.de (Jay Krell) Date: Wed, 28 Jul 2010 14:32:14 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100728123224.51325CC110@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/28 14:32:14 Modified files: cm3/doc/notes/: todo.txt Log message: mention android and iphone From jkrell at elego.de Wed Jul 28 14:33:23 2010 From: jkrell at elego.de (Jay Krell) Date: Wed, 28 Jul 2010 14:33:23 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100728123348.A112FCC110@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/28 14:33:23 Modified files: cm3/doc/notes/: todo.txt Log message: mention AIX: ppc32, ppc64 From jkrell at elego.de Wed Jul 28 16:07:27 2010 From: jkrell at elego.de (Jay Krell) Date: Wed, 28 Jul 2010 16:07:27 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100728140727.C071E2474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/28 16:07:27 Modified files: cm3/scripts/: install-cm3-compiler.sh Log message: don't set -e/x, use echo instead, cp fails, I think, because of the CVS directory From jkrell at elego.de Wed Jul 28 16:19:46 2010 From: jkrell at elego.de (Jay Krell) Date: Wed, 28 Jul 2010 16:19:46 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100728142007.313242474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/28 16:19:46 Modified files: cm3/m3-sys/cm3/src/: M3Build.m3 Log message: remove the "ignoring override" print out, I think few people know it means and fewer (nobody) finds it useful From jkrell at elego.de Wed Jul 28 16:22:03 2010 From: jkrell at elego.de (Jay Krell) Date: Wed, 28 Jul 2010 16:22:03 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100728142204.996F52474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/28 16:22:03 Modified files: cm3/m3-sys/cm3/src/: M3Build.m3 Log message: remove more of the code for: remove the "ignoring override" print out, I think few people know it means and fewer (nobody) finds it useful From jkrell at elego.de Wed Jul 28 16:47:12 2010 From: jkrell at elego.de (Jay Krell) Date: Wed, 28 Jul 2010 16:47:12 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100728144713.27FD82474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/28 16:47:12 Modified files: cm3/m3-sys/m3cc/src/: m3makefile Log message: sparc32_linux: fixed, now an experiment, specific to it, I kind of want to *not* specific host, so that a cross build isn't detected, so that autoconf will do its usual stuff From jkrell at elego.de Wed Jul 28 18:08:17 2010 From: jkrell at elego.de (Jay Krell) Date: Wed, 28 Jul 2010 18:08:17 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100728160817.9B0EA2474006@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/28 18:08:17 Modified files: cm3/caltech-parser/drawcontext/test/: .cvsignore cm3/caltech-parser/parserlib/parserlib/test/: .cvsignore cm3/m3-db/db/test/: .cvsignore cm3/m3-db/odbc/test/: .cvsignore cm3/m3-db/postgres95/test/: .cvsignore cm3/m3-db/stable/test/: .cvsignore cm3/m3-libs/arithmetic/test/: .cvsignore cm3/m3-libs/bitvector/test/: .cvsignore cm3/m3-libs/patternmatching/tests/: .cvsignore cm3/m3-libs/slisp/tests/: .cvsignore Added files: cm3/m3-comm/udp/test/: .cvsignore cm3/m3-libs/binIO/test/: .cvsignore cm3/m3-libs/libm3/tests/: .cvsignore cm3/m3-sys/cm3/test/: .cvsignore cm3/m3-sys/m3quake/test/: .cvsignore Log message: .cvsignore files From jkrell at elego.de Wed Jul 28 18:09:14 2010 From: jkrell at elego.de (Jay Krell) Date: Wed, 28 Jul 2010 18:09:14 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100728160914.8754FCC110@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/28 18:09:14 Modified files: cm3/scripts/: .cvsignore Log message: add PKGS to .cvsignore From jkrell at elego.de Wed Jul 28 18:10:50 2010 From: jkrell at elego.de (Jay Krell) Date: Wed, 28 Jul 2010 18:10:50 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100728161050.332242474006@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/28 18:10:50 Added files: cm3/: .cvsignore Log message: we drop date.c and m3date in the root: .cvsignore From jkrell at elego.de Wed Jul 28 19:29:45 2010 From: jkrell at elego.de (Jay Krell) Date: Wed, 28 Jul 2010 19:29:45 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100728172945.24401CC38A@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/28 19:29:45 Modified files: cm3/m3-sys/cminstall/src/config-no-install/: MIPS64EL_OPENBSD Unix.common Log message: There seems to be no odbc for MIPS64EL_OPENBSD. So, new interface among the config files: proc HasOdbc() return boolean Default is true. MIPS64EL_OPENBSD provides implementation that always returns false. Guides creation of default SYSTEM_LIBS and SYSTEM_LIBORDER. If we could remove elements from an array and table, that would be a better mechanism perhaps. From jkrell at elego.de Wed Jul 28 19:47:45 2010 From: jkrell at elego.de (Jay Krell) Date: Wed, 28 Jul 2010 19:47:45 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100728174745.563F22474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/28 19:47:45 Modified files: cm3/m3-sys/cminstall/src/config-no-install/: Unix.common Log message: huh? fix SYSTEM_LIBORDER From jkrell at elego.de Wed Jul 28 20:05:08 2010 From: jkrell at elego.de (Jay Krell) Date: Wed, 28 Jul 2010 20:05:08 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100728180508.64AA8CC37F@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/28 20:05:08 Modified files: cm3/m3-libs/m3core/src/unix/Common/context/setjmp/: context.c Log message: remove OpenBSD/powerpc hack that no longer seems necessary From jkrell at elego.de Wed Jul 28 21:00:30 2010 From: jkrell at elego.de (Jay Krell) Date: Wed, 28 Jul 2010 21:00:30 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100728190030.8DE142474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/28 21:00:30 Modified files: cm3/doc/notes/: todo.txt Log message: add new_adr, reliable stacks for assertion failure From jkrell at elego.de Wed Jul 28 21:02:45 2010 From: jkrell at elego.de (Jay Krell) Date: Wed, 28 Jul 2010 21:02:45 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100728190246.01B9E2474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/28 21:02:45 Modified files: cm3/m3-sys/cminstall/src/config-no-install/: PPC32_OPENBSD Log message: enable sharing on OpenBSD/powerpc -- using -fpic instead of -fPIC was the key, though that doesn't make sense to me and I didn't debug it From jkrell at elego.de Wed Jul 28 21:09:46 2010 From: jkrell at elego.de (Jay Krell) Date: Wed, 28 Jul 2010 21:09:46 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100728190947.3C2DACC37F@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/28 21:09:46 Modified files: cm3/m3-games/tetris/src/: m3makefile Log message: disable on MIPS64EL_OPENBSD due to: /usr/bin/ld: not enough GOT space for local GOT entries /usr/bin/ld: BFD 2.15 internal error, aborting at /usr/src/gnu/usr.bin/binutils/bfd/elfxx-mips.c line 6483 in _bfd_mips_elf_relocate_section /usr/bin/ld: Please report this bug. F From jkrell at elego.de Wed Jul 28 22:40:09 2010 From: jkrell at elego.de (Jay Krell) Date: Wed, 28 Jul 2010 22:40:09 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100728204010.1CF84CC38A@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/28 22:40:09 Modified files: cm3/m3-libs/m3core/src/unix/Common/context/setjmp/: context.c Removed files: cm3/m3-libs/m3core/src/unix/Common/context/setjmp/: context_mips64.s Log message: much better fix for mips don't access any globals (including functions) in internal_setcontext only access parameters (we can pass anything we need) This way, the code is correctly position independent and works in shared libraries. Before, anything shared would crash. As a bonus, though we have to write slightly unusual C, we don't need any assembly. Now, Juno works! From jkrell at elego.de Wed Jul 28 22:47:52 2010 From: jkrell at elego.de (Jay Krell) Date: Wed, 28 Jul 2010 22:47:52 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100728204753.1EFA2CC38A@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/28 22:47:52 Modified files: cm3/m3-libs/m3core/src/unix/Common/context/setjmp/: m3makefile Log message: forgot m3makefile, I had edited on the actual mips machine From jkrell at elego.de Wed Jul 28 23:02:08 2010 From: jkrell at elego.de (Jay Krell) Date: Wed, 28 Jul 2010 23:02:08 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100728210212.30F98CC37E@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/28 23:02:08 Modified files: cm3/m3-sys/m3cc/src/: m3makefile Log message: go back to being explicit about sparc32_linux target (see http://hudson.modula3.com:8080/job/cm3-current-build-SPARC32_LINUX/38/console; one would think -m32 would make this not matter) From jkrell at elego.de Wed Jul 28 23:15:23 2010 From: jkrell at elego.de (Jay Krell) Date: Wed, 28 Jul 2010 23:15:23 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100728211523.AEAFF2474008@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/28 23:15:23 Modified files: cm3/m3-sys/m3quake/src/: QMachine.m3 Log message: more diagnostics for rmrec problem From jkrell at elego.de Wed Jul 28 23:17:32 2010 From: jkrell at elego.de (Jay Krell) Date: Wed, 28 Jul 2010 23:17:32 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100728211732.28E232474008@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/28 23:17:32 Modified files: cm3/m3-sys/m3cc/src/: m3makefile Log message: more bogosity because rmrec fails From jkrell at elego.de Wed Jul 28 23:19:27 2010 From: jkrell at elego.de (Jay Krell) Date: Wed, 28 Jul 2010 23:19:27 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100728211927.E751C2474008@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/28 23:19:27 Modified files: cm3/m3-libs/sysutils/src/: FSUtils.m3 Log message: more diagnostics From jkrell at elego.de Thu Jul 29 14:42:13 2010 From: jkrell at elego.de (Jay Krell) Date: Thu, 29 Jul 2010 14:42:13 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100729124213.D9FD52474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/29 14:42:13 Modified files: cm3/m3-sys/cminstall/src/config-no-install/: OpenBSD.common Log message: Oops: OpenBSD up to and including 4.7 seems to have no $ORIGIN support. It has ld -z origin, but that's it. OpenBSD users should either set LD_LIBRARY_PATH or rebuild themselves. Under consideration, given time, is a new distribution form where users will configure (autoconf), assemble, compile C, link, install. And probably build m3cc themselves too. From jkrell at elego.de Thu Jul 29 15:10:33 2010 From: jkrell at elego.de (Jay Krell) Date: Thu, 29 Jul 2010 15:10:33 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100729131033.0E9EC2474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/29 15:10:33 Modified files: cm3/doc/notes/: todo.txt Log message: describe new sourcey distribution format From jkrell at elego.de Thu Jul 29 15:23:04 2010 From: jkrell at elego.de (Jay Krell) Date: Thu, 29 Jul 2010 15:23:04 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100729132304.8F8A42474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/29 15:23:04 Modified files: cm3/m3-sys/m3tests/src/p2/p240/: m3makefile Math.quake Log message: try doing less for cm3 -clean, maybe that is the rmrec problem (needs some Win32 portability, /dev/null vs. nul) From jkrell at elego.de Thu Jul 29 15:42:34 2010 From: jkrell at elego.de (Jay Krell) Date: Thu, 29 Jul 2010 15:42:34 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100729134234.B83652474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/29 15:42:34 Modified files: cm3/m3-sys/cminstall/src/config-no-install/: SPARC32_LINUX Log message: no symbols, just to conserve diskspace From jkrell at elego.de Thu Jul 29 15:44:44 2010 From: jkrell at elego.de (Jay Krell) Date: Thu, 29 Jul 2010 15:44:44 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100729134444.894572474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/29 15:44:44 Modified files: cm3/m3-sys/m3cc/src/: gnucc.common Log message: no symbols on SPARC32_LINUX to conserve diskspace From jkrell at elego.de Sat Jul 31 10:46:02 2010 From: jkrell at elego.de (Jay Krell) Date: Sat, 31 Jul 2010 10:46:02 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100731084606.EE088CC3B8@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/31 10:46:02 Modified files: cm3/: m3overrides Log message: adjust m3overrides file to avoid the useless warning from the frontend From jkrell at elego.de Sat Jul 31 10:48:48 2010 From: jkrell at elego.de (Jay Krell) Date: Sat, 31 Jul 2010 10:48:48 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100731084849.04D30CC3B8@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/31 10:48:48 Modified files: cm3/m3-sys/cm3/src/: M3Build.m3 Log message: Put back warning that we now avoid. I still don't see any point to this warning. From jkrell at elego.de Sat Jul 31 11:53:56 2010 From: jkrell at elego.de (Jay Krell) Date: Sat, 31 Jul 2010 11:53:56 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100731095356.AABEC2474019@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/31 11:53:56 Added files: cm3/m3-sys/m3tests/src/p2/p247/: Main.m3 m3makefile Log message: a larger test of just fs_rmrec From jkrell at elego.de Sat Jul 31 12:38:13 2010 From: jkrell at elego.de (Jay Krell) Date: Sat, 31 Jul 2010 12:38:13 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100731103814.0DCB6CC392@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/31 12:38:13 Modified files: cm3/m3-sys/m3tests/src/: m3makefile Log message: add test p248 for fs_rmrec From jkrell at elego.de Sat Jul 31 13:12:54 2010 From: jkrell at elego.de (Jay Krell) Date: Sat, 31 Jul 2010 13:12:54 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100731111308.34AD1CC3BE@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/31 13:12:54 Modified files: cm3/m3-libs/sysutils/src/: FSUtils.m3 Log message: replace RmRec with in implementation that only keeps one DIR*/Iterator open at a time. This is an experiment. The code is somewhat less efficient, producing more garbage, but also kind of small and nice to read. If this works, which I'm giving 50% odds, it still doesn't make sense. The opendir/readdir code I've seen is in fact reentrant. You can recurse while holding open the parent. They don't use a global or thread local, the use a buffer that is in the DIR*. Old version left for now under OldRmRec. With the debug printing removed. Both versions I believe are fairly racy, in that competing RmRecs will cause the other to fail. "Preflight" for existance doesn't cut and is in fact a significant deoptimization, This version is more efficient in that regard: don't call stat on children already determined to be file or directory. Still a wasted call at toplevel for existance. From jkrell at elego.de Sat Jul 31 13:35:48 2010 From: jkrell at elego.de (Jay Krell) Date: Sat, 31 Jul 2010 13:35:48 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100731113548.A0EAC2474019@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/31 13:35:48 Modified files: cm3/m3-libs/sysutils/src/: FSUtils.m3 Log message: Don't call stat so many extra times. Once is enough to determine exists vs. file vs. directory, and if we just enumerated it, we don't need to check again. Perhaps the three booleans should be an enum. From jkrell at elego.de Sat Jul 31 13:40:01 2010 From: jkrell at elego.de (Jay Krell) Date: Sat, 31 Jul 2010 13:40:01 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100731114001.A42472474019@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/31 13:40:01 Modified files: cm3/m3-libs/sysutils/src/: FSUtils.m3 Log message: Add more comments. This file has functions: Rm and RemoveFile Rmdir and RemoveDir They do the same things in the success paths and vary in that some raise exceptions and others call Process.Crash in the error paths. From jkrell at elego.de Sat Jul 31 13:47:22 2010 From: jkrell at elego.de (Jay Krell) Date: Sat, 31 Jul 2010 13:47:22 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100731114722.DE3D42474019@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/31 13:47:22 Modified files: cm3/m3-sys/m3cc/src/: m3makefile clean_marker.txt Log message: experiment: remove rm -rf hack and tickle clean marker From jkrell at elego.de Thu Jul 1 09:56:00 2010 From: jkrell at elego.de (Jay Krell) Date: Thu, 1 Jul 2010 9:56:00 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100701075600.3D2092474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/01 09:56:00 Added files: cm3/m3-sys/m3tests/src/c1/c135/: Main.m3 m3makefile cm3/m3-sys/m3tests/src/c1/c135/expected/AMD64_DARWIN/: Main.ms Log message: moving and slightly restructing test p239 From jkrell at elego.de Thu Jul 1 10:57:05 2010 From: jkrell at elego.de (Jay Krell) Date: Thu, 1 Jul 2010 10:57:05 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100701085705.757622474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/01 10:57:05 Modified files: cm3/m3-sys/m3cc/gcc/gcc/config/: darwin.h Log message: always support hidden aka private extern aka don't export every function from shared libraries, preferably only one - listed in an .i3 file - an .i3 file that is Interface and not merely interface I believe currently I've only achieved the first condition. I suspect this regressed because I put in specifying -target explicitly for consistency with cross builds, and so maybe that doesn't use autoconf as much? I'm not sure. From jkrell at elego.de Thu Jul 1 12:54:39 2010 From: jkrell at elego.de (Jay Krell) Date: Thu, 1 Jul 2010 12:54:39 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100701105439.9A92E2474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/01 12:54:39 Modified files: cm3/m3-sys/m3tests/src/: m3makefile Removed files: cm3/m3-sys/m3tests/src/p2/p239/: Main.m3 Main.ms-AMD64_DARWIN m3makefile Log message: flesh out infrastructure for checking in known/suspected correct assembly and then comparing to current assembly the intent, if not the code, is: in any directory m3-sys/m3tests/src/c1/c123 create m3-sys/m3tests/src/c1/c123/expected/I386_LINUX/Main.ms m3-sys/m3tests/src/c1/c123/expected/I386_LINUX/Foo.ms m3-sys/m3tests/src/c1/c123/expected/AMD64_LINUX/Main.ms m3-sys/m3tests/src/c1/c123/expected/AMD64_LINUX/Foo.ms etc. The name "expected" is a hardcoded part of the interface. I'm open to making it something else or additional flexibility, but this seems adequate or better to me. Any file in expected/TARGET is compared against TARGET. Missing/extra files are just ignored. Note that this probably works for stdout.pgm and such. Future: We should probably allow for: m3-sys/m3tests/src/c1/c123/expected/I386/Foo.ms m3-sys/m3tests/src/c1/c123/expected/AMD64/Main.ms once we confirm that they are often the same. e.g. I wouldn't be surprised if they are the same across all Solaris, *BSD, Linux, though probably not Darwin. Heck, we might even make up something called I386_ELF or I386_SYSV. Cross that bridge later. If the code does not agree with this description, well, this description was my intent. Whether or not creating a directory was worthwhile, it still not clear. The previous implementation allowed for just: m3-sys/m3tests/src/c1/c123/Main.ms-AMD64_LINUX and then you could either glom everything into Main.m3, or use multiple test cases. At the moment I'm thinking of having multiple files but just one large test case. We'll see. It's not a big deal either way. From jkrell at elego.de Thu Jul 1 14:41:08 2010 From: jkrell at elego.de (Jay Krell) Date: Thu, 1 Jul 2010 14:41:08 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100701124109.184902474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/01 14:41:08 Modified files: cm3/m3-sys/m3tests/src/c1/c135/: Main.m3 m3makefile cm3/m3-sys/m3tests/src/c1/c135/expected/AMD64_DARWIN/: Main.ms Added files: cm3/m3-sys/m3tests/src/c1/c135/expected/AMD64_DARWIN/: A.is A.ms Log message: generate code, what we had and a fair amount more we now generate add, subtract, mult, div, mod, or, and, xor for every integer type pair, for either two global variables or two parameters as well as returning each type as a constant or from a global variable or a parameter of any integer type 1104 total little functions, so far I still need to add bit field uses before I can go back and resume configure -enable-checking fixes, as the straightforward type fix there regressed code equality, so I want to try bit field refs again for constant bit insert/extract From jkrell at elego.de Thu Jul 1 15:43:32 2010 From: jkrell at elego.de (Jay Krell) Date: Thu, 1 Jul 2010 15:43:32 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100701134333.2C56E2474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/01 15:43:32 Modified files: cm3/m3-sys/m3tests/src/c1/c135/: m3makefile cm3/m3-sys/m3tests/src/c1/c135/expected/AMD64_DARWIN/: A.ms Log message: start adding float support (and seemingly quite nice generalizations in support of this) From wagner at elego.de Fri Jul 2 08:07:07 2010 From: wagner at elego.de (Olaf Wagner) Date: Fri, 2 Jul 2010 8:07:07 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100702060707.71F422474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: wagner at birch. 10/07/02 08:07:07 Modified files: cm3/scripts/: Tag: release_branch_cm3_5_8 make-dist.sh version version.quake Log message: prepare for final release build From jkrell at elego.de Fri Jul 2 14:41:25 2010 From: jkrell at elego.de (Jay Krell) Date: Fri, 2 Jul 2010 14:41:25 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100702124125.6DAC22474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/02 14:41:25 Added files: cm3/m3-sys/m3tests/src/c1/c135/: Math.quake Log message: addition (Add) and subtraction (Sub) of positive and negative numbers (!) at least in the fixed range [-9999, 9999] Also provide Range(0, n) which creates the array [0, .., n - 1] which you can use with foreach. All built out of hash tables! From jkrell at elego.de Fri Jul 2 14:42:10 2010 From: jkrell at elego.de (Jay Krell) Date: Fri, 2 Jul 2010 14:42:10 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100702124210.7E1082474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/02 14:42:10 Modified files: cm3/m3-sys/m3tests/src/c1/c135/: Math.quake Log message: turn off the test code From jkrell at elego.de Fri Jul 2 14:42:51 2010 From: jkrell at elego.de (Jay Krell) Date: Fri, 2 Jul 2010 14:42:51 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100702124251.3C1662474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/02 14:42:51 Modified files: cm3/m3-sys/m3tests/src/c1/c135/: Math.quake Log message: fix formating error that crept in From jkrell at elego.de Sat Jul 3 08:38:14 2010 From: jkrell at elego.de (Jay Krell) Date: Sat, 3 Jul 2010 8:38:14 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100703063814.C6D342474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/03 08:38:14 Modified files: cm3/m3-sys/m3tests/src/c1/c135/: Math.quake Log message: change Range to InclusiveRange and ExclusiveRange From jkrell at elego.de Sat Jul 3 09:08:54 2010 From: jkrell at elego.de (Jay Krell) Date: Sat, 3 Jul 2010 9:08:54 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100703070854.ADDD12474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/03 09:08:54 Modified files: cm3/m3-sys/m3tests/src/c1/c135/: Math.quake Log message: add Mult, Less, LessOrEqual, Greater, GreaterOrEqual From jkrell at elego.de Sat Jul 3 09:48:07 2010 From: jkrell at elego.de (Jay Krell) Date: Sat, 3 Jul 2010 9:48:07 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100703074807.7BB162474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/03 09:48:07 Modified files: cm3/m3-sys/m3tests/src/c1/c135/: Math.quake Log message: add Div and Mod, and fix a bug in previous From jkrell at elego.de Sat Jul 3 10:27:46 2010 From: jkrell at elego.de (Jay Krell) Date: Sat, 3 Jul 2010 10:27:46 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100703082746.6FA912474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/03 10:27:46 Modified files: cm3/m3-sys/m3tests/src/c1/c135/: Math.quake Log message: provide PowerOf2 and DecToHex PowerOf2 I want as part of testing extract_mn DecToHex is just to make that prettier Though I think extract_mn is more than just about exact powers of 2, need to look into it. I don't see how to provide HexToDec without major duplication/factoring. In particular, I think you'd need a whole other set of tables, and the functions would all have to be given the set of tables to use. Not likely to happen. If we could index strings, that'd help. Maybe we can? Anyway, for now, no matter. I have what I need and slightly more. From jkrell at elego.de Sat Jul 3 10:43:34 2010 From: jkrell at elego.de (Jay Krell) Date: Sat, 3 Jul 2010 10:43:34 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100703084334.A09252474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/03 10:43:34 Modified files: cm3/m3-sys/m3tests/src/c1/c135/: Math.quake Log message: rename DecToHex to just Hex, provide HexPowerOf2 that can deal with large numbers From jkrell at elego.de Sat Jul 3 11:17:54 2010 From: jkrell at elego.de (Jay Krell) Date: Sat, 3 Jul 2010 11:17:54 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100703091755.22F8F2474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/03 11:17:54 Modified files: cm3/m3-sys/m3tests/src/c1/c135/: m3makefile Log message: add a lot more coverage: reads and writes of bitfields division and mod by powers of 2 (I need to check though, it might be not just precise powers of 2 that matter) testing of INTEGER, LONGINT, CARDINAL, LONGCARD (and not just the precisely sized types) some float stuff (maybe that was there already) From jkrell at elego.de Sat Jul 3 11:50:00 2010 From: jkrell at elego.de (Jay Krell) Date: Sat, 3 Jul 2010 11:50:00 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100703095000.D5EDE2474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/03 11:50:00 Modified files: cm3/m3-sys/m3tests/src/c1/c135/: m3makefile Log message: more coverage, esp. div/mod of integer/cardinal/longint/longcard From jkrell at elego.de Sat Jul 3 11:50:46 2010 From: jkrell at elego.de (Jay Krell) Date: Sat, 3 Jul 2010 11:50:46 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100703095046.CEF9D2474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/03 11:50:46 Modified files: cm3/m3-sys/m3cc/gcc/gcc/config/rs6000/: rs6000-protos.h Log message: add #include alias.h to fix compilation break From jkrell at elego.de Sat Jul 3 12:03:50 2010 From: jkrell at elego.de (Jay Krell) Date: Sat, 3 Jul 2010 12:03:50 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100703100350.3158A2474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/03 12:03:50 Modified files: cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c Log message: a little more tracing, of insert/extract From jkrell at elego.de Sat Jul 3 12:05:06 2010 From: jkrell at elego.de (Jay Krell) Date: Sat, 3 Jul 2010 12:05:06 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100703100506.32D642474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/03 12:05:06 Modified files: cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c Log message: fix typo From jkrell at elego.de Sat Jul 3 12:08:17 2010 From: jkrell at elego.de (Jay Krell) Date: Sat, 3 Jul 2010 12:08:17 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100703100817.B35F02474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/03 12:08:17 Modified files: cm3/m3-libs/m3core/src/C/Common/: Cstdint.i3 Log message: remove BITS FOR From jkrell at elego.de Sat Jul 3 12:23:12 2010 From: jkrell at elego.de (Jay Krell) Date: Sat, 3 Jul 2010 12:23:12 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100703102315.47E2C2474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/03 12:23:12 Modified files: cm3/m3-sys/m3tests/src/: m3makefile Log message: port from release: the use of bc causes a problem on Solaris also fix up perhaps the optional use of Cygwin date.exe on NT need some sort of time support in quake? From jkrell at elego.de Sat Jul 3 12:47:11 2010 From: jkrell at elego.de (Jay Krell) Date: Sat, 3 Jul 2010 12:47:11 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100703104711.C99FC2474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/03 12:47:11 Modified files: cm3/m3-sys/cminstall/src/config-no-install/: PPC_LINUX Log message: Don't make executable position independent. It is a nice security feature, but this is the only platform we use it on so far and it breaks debugging (even for C code). From jkrell at elego.de Sat Jul 3 12:48:56 2010 From: jkrell at elego.de (Jay Krell) Date: Sat, 3 Jul 2010 12:48:56 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100703104856.A32A72474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/03 12:48:56 Modified files: cm3/m3-sys/cminstall/src/config-no-install/: Tag: release_branch_cm3_5_8 PPC_LINUX Log message: port from head: don't make PPC_LINUX executables position independent, as it breaks debugging (we do use this on Solaris actually, but the odds of such a bug being portable aren't high) From jkrell at elego.de Sat Jul 3 12:57:09 2010 From: jkrell at elego.de (Jay Krell) Date: Sat, 3 Jul 2010 12:57:09 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100703105709.DBD2E2474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/03 12:57:09 Modified files: cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c Log message: restore volatile for powerpc and powerpc64 platforms This seems to fix PPC_LINUX hanging. This needs further debugging, but I'm not eager. This will also affect PPC_DARWIN, PPC64_DARWIN, PPC32_OPENBSD, PPC32_NETBSD, PPC32_FREEBSD, etc., but these platforms are little used or nonexistant. Having volatile like has been the very long standing situation though. The result is that the optimizer does basically nothing. From jkrell at elego.de Sat Jul 3 12:58:34 2010 From: jkrell at elego.de (Jay Krell) Date: Sat, 3 Jul 2010 12:58:34 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100703105834.337FF2474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/03 12:58:34 Modified files: cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c Log message: fix typo regarding powerpc64 From jkrell at elego.de Sat Jul 3 14:42:37 2010 From: jkrell at elego.de (Jay Krell) Date: Sat, 3 Jul 2010 14:42:37 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100703124239.DA0E02474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/03 14:42:37 Modified files: cm3/m3-sys/m3tests/src/c1/c135/: m3makefile Log message: more coverage cleaner output preparation for still more coverage From jkrell at elego.de Sat Jul 3 15:14:59 2010 From: jkrell at elego.de (Jay Krell) Date: Sat, 3 Jul 2010 15:14:59 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100703131459.438062474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/03 15:14:59 Modified files: cm3/m3-sys/m3tests/src/c1/c135/: m3makefile Log message: add unary negation and unary Word.Not From jkrell at elego.de Sat Jul 3 15:27:41 2010 From: jkrell at elego.de (Jay Krell) Date: Sat, 3 Jul 2010 15:27:41 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100703132741.F037E2474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/03 15:27:41 Modified files: cm3/m3-sys/m3tests/src/c1/c135/: m3makefile Log message: add left/right/other shift/rotate, by non constants limiting second parameter to INTEGER, though other types should have differing / interesting codegen, e.g. CARDINAL would have few range changes hopefully and small ranges would too From jkrell at elego.de Sat Jul 3 15:29:05 2010 From: jkrell at elego.de (Jay Krell) Date: Sat, 3 Jul 2010 15:29:05 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100703132905.381A32474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/03 15:29:05 Modified files: cm3/m3-sys/m3tests/src/c1/c135/: m3makefile Log message: add shift/rotate by cardinal as well From jkrell at elego.de Sat Jul 3 15:31:09 2010 From: jkrell at elego.de (Jay Krell) Date: Sat, 3 Jul 2010 15:31:09 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100703133110.0278B2474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/03 15:31:09 Modified files: cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c Log message: reremove volatile on powerpc, it doesn't seem to hang now..wierd... (should still test it optimized as well) From jkrell at elego.de Sat Jul 3 15:44:42 2010 From: jkrell at elego.de (Jay Krell) Date: Sat, 3 Jul 2010 15:44:42 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100703134442.6254E2474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/03 15:44:42 Modified files: cm3/m3-sys/m3tests/src/c1/c135/: m3makefile Log message: add Word/Long.Insert/Extract coverage, for non-constants and with some of the combinatorics reduced (but constant converage coming shortly) From jkrell at elego.de Sat Jul 3 15:57:20 2010 From: jkrell at elego.de (Jay Krell) Date: Sat, 3 Jul 2010 15:57:20 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100703135720.8D8742474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/03 15:57:20 Modified files: cm3/m3-sys/m3tests/src/c1/c135/: Math.quake Log message: fix direct uses of ExclusiveRange, which I don't use but it had been bugging me From jkrell at elego.de Sat Jul 3 15:58:09 2010 From: jkrell at elego.de (Jay Krell) Date: Sat, 3 Jul 2010 15:58:09 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100703135809.E1A9B2474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/03 15:58:09 Modified files: cm3/m3-sys/m3tests/src/c1/c135/: Math.quake Log message: maybe fix other cases that don't affect me From jkrell at elego.de Sat Jul 3 16:30:25 2010 From: jkrell at elego.de (Jay Krell) Date: Sat, 3 Jul 2010 16:30:25 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100703143028.3F19D2474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/03 16:30:25 Modified files: cm3/m3-sys/m3tests/src/c1/c135/: m3makefile Log message: add insert/extract with one and two constants From jkrell at elego.de Sat Jul 3 17:00:34 2010 From: jkrell at elego.de (Jay Krell) Date: Sat, 3 Jul 2010 17:00:34 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100703150034.F33932474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/03 17:00:34 Modified files: cm3/m3-sys/m3tests/src/c1/c135/: m3makefile Log message: split up some into separate files: bitfield.m3, divmod_pow2.m3, insert.m3, extract.m3, A.m3 From jkrell at elego.de Sat Jul 3 17:01:31 2010 From: jkrell at elego.de (Jay Krell) Date: Sat, 3 Jul 2010 17:01:31 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100703150132.2AA5E2474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/03 17:01:31 Modified files: cm3/m3-sys/m3tests/src/c1/c135/: m3makefile Log message: minor cleanup From jkrell at elego.de Sat Jul 3 17:06:59 2010 From: jkrell at elego.de (Jay Krell) Date: Sat, 3 Jul 2010 17:06:59 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100703150700.057802474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/03 17:06:59 Modified files: cm3/m3-sys/m3tests/src/c1/c135/expected/AMD64_DARWIN/: A.ms Added files: cm3/m3-sys/m3tests/src/c1/c135/expected/AMD64_DARWIN/: bitfield.ms divmod_pow2.ms extract.ms insert.ms Removed files: cm3/m3-sys/m3tests/src/c1/c135/expected/AMD64_DARWIN/: A.is Main.ms Log message: add expected outputs now that maybe maybe this has reached a fairly good state for a while Some of the files are still quite large though and should maybe be broken down more. From jkrell at elego.de Sat Jul 3 17:28:20 2010 From: jkrell at elego.de (Jay Krell) Date: Sat, 3 Jul 2010 17:28:20 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100703152820.CE4B02474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/03 17:28:20 Modified files: cm3/m3-sys/m3tests/src/c1/c135/: m3makefile cm3/m3-sys/m3tests/src/c1/c135/expected/AMD64_DARWIN/: bitfield.ms Log message: keep bitfields to INTEGER, not LONGINT don't have 0 or word-size bitfields, just 1 .. wordsize - 1 From jkrell at elego.de Sat Jul 3 17:38:18 2010 From: jkrell at elego.de (Jay Krell) Date: Sat, 3 Jul 2010 17:38:18 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100703153818.A01FA2474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/03 17:38:18 Added files: cm3/m3-sys/m3tests/src/c1/c135/expected/I386_LINUX/: A.ms bitfield.ms divmod_pow2.ms extract.ms insert.ms Log message: add current outputs From jkrell at elego.de Sat Jul 3 17:41:09 2010 From: jkrell at elego.de (Jay Krell) Date: Sat, 3 Jul 2010 17:41:09 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100703154109.5A7362474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/03 17:41:09 Added files: cm3/m3-sys/m3tests/src/c1/c135/expected/SOLgnu/: A.ms bitfield.ms divmod_pow2.ms extract.ms insert.ms Log message: add current outputs From jkrell at elego.de Sun Jul 4 02:17:19 2010 From: jkrell at elego.de (Jay Krell) Date: Sun, 4 Jul 2010 2:17:19 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100704001720.7BD4B2474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/04 02:17:19 Modified files: cm3/m3-sys/m3tests/src/: m3makefile Added files: cm3/m3-sys/m3tests/src/p2/p240/: Main.m3 Math.quake m3makefile cm3/m3-sys/m3tests/src/p2/p240/expected/AMD64_DARWIN/: A.ms bitfield.ms divmod_pow2.ms extract.ms insert.ms cm3/m3-sys/m3tests/src/p2/p240/expected/I386_LINUX/: A.ms bitfield.ms divmod_pow2.ms extract.ms insert.ms cm3/m3-sys/m3tests/src/p2/p240/expected/SOLgnu/: A.ms bitfield.ms divmod_pow2.ms extract.ms insert.ms Removed files: cm3/m3-sys/m3tests/src/c1/c135/: Main.m3 Math.quake m3makefile cm3/m3-sys/m3tests/src/c1/c135/expected/AMD64_DARWIN/: A.ms bitfield.ms divmod_pow2.ms extract.ms insert.ms cm3/m3-sys/m3tests/src/c1/c135/expected/I386_LINUX/: A.ms bitfield.ms divmod_pow2.ms extract.ms insert.ms cm3/m3-sys/m3tests/src/c1/c135/expected/SOLgnu/: A.ms bitfield.ms divmod_pow2.ms extract.ms insert.ms Log message: restore "c" tests to not running (at least one of them knowingly contains an infinite loop) change c135 to p240 From jkrell at elego.de Sun Jul 4 02:22:35 2010 From: jkrell at elego.de (Jay Krell) Date: Sun, 4 Jul 2010 2:22:35 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100704002241.9F9C72474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/04 02:22:35 Modified files: cm3/m3-sys/cminstall/src/config-no-install/: PPC_LINUX Log message: add comment that gdb 7.1 needed for PIE debugging, keep it disabled at least for now (was it causing other problems??) From hosking at cs.purdue.edu Sun Jul 4 02:36:20 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sat, 3 Jul 2010 20:36:20 -0400 Subject: [M3commit] CVS Update: cm3 In-Reply-To: <20100703105709.DBD2E2474003@birch.elegosoft.com> References: <20100703105709.DBD2E2474003@birch.elegosoft.com> Message-ID: I am very disturbed that volatile is needed here. Can we selectively turn it on for thread-critical files like ThreadPThread and see if it fixes the problem. I wonder if the double-checked locking is broken for PPC memory model. Is this on a multi-processor? On 3 Jul 2010, at 12:57, Jay Krell wrote: > CVSROOT: /usr/cvs > Changes by: jkrell at birch. 10/07/03 12:57:09 > > Modified files: > cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c > > Log message: > restore volatile for powerpc and powerpc64 platforms > This seems to fix PPC_LINUX hanging. > This needs further debugging, but I'm not eager. > This will also affect PPC_DARWIN, PPC64_DARWIN, PPC32_OPENBSD, > PPC32_NETBSD, PPC32_FREEBSD, etc., but these platforms are little used or > nonexistant. > > Having volatile like has been the very long standing situation though. > The result is that the optimizer does basically nothing. From jay.krell at cornell.edu Sun Jul 4 02:42:20 2010 From: jay.krell at cornell.edu (Jay K) Date: Sun, 4 Jul 2010 00:42:20 +0000 Subject: [M3commit] CVS Update: cm3 In-Reply-To: References: <20100703105709.DBD2E2474003@birch.elegosoft.com>, Message-ID: Not a multiprocessor. ? Still interested in selective volatile? This all bothers me too. I don't want volatile. It makes the optimized code terrible. But I don't want to debug any problem from removing it, beyond compilation failure. I can try a few things. This is all wierd. I swear I saw it hang several times. I swear I'm trying to to change "too many" variables at a time. Yes, I know, 2 is too many. Once I started getting version stamp mismatch, I resorted to using a cross built cm3. ?Out of necessity sort of, but that causes more flucuation of variables. Let me try again with volatile and see if it is solid. ?Then I'll try with only volatile stores. I've been trying optimized and unoptimized, and not kept good track of which when. ?- Jay ---------------------------------------- > From: hosking at cs.purdue.edu > Date: Sat, 3 Jul 2010 20:36:20 -0400 > To: jkrell at elego.de > CC: m3commit at elegosoft.com > Subject: Re: [M3commit] CVS Update: cm3 > > I am very disturbed that volatile is needed here. Can we selectively turn it on for thread-critical files like ThreadPThread and see if it fixes the problem. I wonder if the double-checked locking is broken for PPC memory model. Is this on a multi-processor? > > On 3 Jul 2010, at 12:57, Jay Krell wrote: > > > CVSROOT: /usr/cvs > > Changes by: jkrell at birch. 10/07/03 12:57:09 > > > > Modified files: > > cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c > > > > Log message: > > restore volatile for powerpc and powerpc64 platforms > > This seems to fix PPC_LINUX hanging. > > This needs further debugging, but I'm not eager. > > This will also affect PPC_DARWIN, PPC64_DARWIN, PPC32_OPENBSD, > > PPC32_NETBSD, PPC32_FREEBSD, etc., but these platforms are little used or > > nonexistant. > > > > Having volatile like has been the very long standing situation though. > > The result is that the optimizer does basically nothing. > From jay.krell at cornell.edu Sun Jul 4 02:44:37 2010 From: jay.krell at cornell.edu (Jay K) Date: Sun, 4 Jul 2010 00:44:37 +0000 Subject: [M3commit] CVS Update: cm3 In-Reply-To: References: <20100703105709.DBD2E2474003@birch.elegosoft.com>, , Message-ID: Tony, just to be clear..you/I are disturbed by volatile, but it has also, I believe, like always been there. It has been gone only very briefly, and its non-use is probably limited for other reasons (how many people are using it, on how many platforms?). ?- Jay ---------------------------------------- > From: jay.krell at cornell.edu > To: hosking at cs.purdue.edu; jkrell at elego.de > CC: m3commit at elegosoft.com > Subject: RE: [M3commit] CVS Update: cm3 > Date: Sun, 4 Jul 2010 00:42:20 +0000 > > > Not a multiprocessor. > Still interested in selective volatile? > > > This all bothers me too. > I don't want volatile. It makes the optimized code terrible. > But I don't want to debug any problem from removing it, beyond compilation failure. > > > I can try a few things. > This is all wierd. I swear I saw it hang several times. > I swear I'm trying to to change "too many" variables at a time. Yes, I know, 2 is too many. > > > Once I started getting version stamp mismatch, I resorted to using a cross built cm3. > Out of necessity sort of, but that causes more flucuation of variables. > > Let me try again with volatile and see if it is solid. > Then I'll try with only volatile stores. > > I've been trying optimized and unoptimized, and not kept good track of which when. > > > - Jay > > > ---------------------------------------- > > From: hosking at cs.purdue.edu > > Date: Sat, 3 Jul 2010 20:36:20 -0400 > > To: jkrell at elego.de > > CC: m3commit at elegosoft.com > > Subject: Re: [M3commit] CVS Update: cm3 > > > > I am very disturbed that volatile is needed here. Can we selectively turn it on for thread-critical files like ThreadPThread and see if it fixes the problem. I wonder if the double-checked locking is broken for PPC memory model. Is this on a multi-processor? > > > > On 3 Jul 2010, at 12:57, Jay Krell wrote: > > > > > CVSROOT: /usr/cvs > > > Changes by: jkrell at birch. 10/07/03 12:57:09 > > > > > > Modified files: > > > cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c > > > > > > Log message: > > > restore volatile for powerpc and powerpc64 platforms > > > This seems to fix PPC_LINUX hanging. > > > This needs further debugging, but I'm not eager. > > > This will also affect PPC_DARWIN, PPC64_DARWIN, PPC32_OPENBSD, > > > PPC32_NETBSD, PPC32_FREEBSD, etc., but these platforms are little used or > > > nonexistant. > > > > > > Having volatile like has been the very long standing situation though. > > > The result is that the optimizer does basically nothing. > > > From hosking at cs.purdue.edu Sun Jul 4 02:49:11 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sat, 3 Jul 2010 20:49:11 -0400 Subject: [M3commit] CVS Update: cm3 In-Reply-To: References: <20100703105709.DBD2E2474003@birch.elegosoft.com>, Message-ID: <131D2ADF-5AB5-4DFA-B819-1A7F117C94C1@cs.purdue.edu> On 3 Jul 2010, at 20:42, Jay K wrote: > Not a multiprocessor. > Still interested in selective volatile? Not really. This says its something even more troubling unless it happens with the optimiser. > This all bothers me too. > I don't want volatile. It makes the optimized code terrible. Agreed. > But I don't want to debug any problem from removing it, beyond compilation failure. > > > I can try a few things. > This is all wierd. I swear I saw it hang several times. > I swear I'm trying to to change "too many" variables at a time. Yes, I know, 2 is too many. > > > Once I started getting version stamp mismatch, I resorted to using a cross built cm3. > Out of necessity sort of, but that causes more flucuation of variables. > > Let me try again with volatile and see if it is solid. > Then I'll try with only volatile stores. > > I've been trying optimized and unoptimized, and not kept good track of which when. > > > - Jay > > > ---------------------------------------- >> From: hosking at cs.purdue.edu >> Date: Sat, 3 Jul 2010 20:36:20 -0400 >> To: jkrell at elego.de >> CC: m3commit at elegosoft.com >> Subject: Re: [M3commit] CVS Update: cm3 >> >> I am very disturbed that volatile is needed here. Can we selectively turn it on for thread-critical files like ThreadPThread and see if it fixes the problem. I wonder if the double-checked locking is broken for PPC memory model. Is this on a multi-processor? >> >> On 3 Jul 2010, at 12:57, Jay Krell wrote: >> >>> CVSROOT: /usr/cvs >>> Changes by: jkrell at birch. 10/07/03 12:57:09 >>> >>> Modified files: >>> cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c >>> >>> Log message: >>> restore volatile for powerpc and powerpc64 platforms >>> This seems to fix PPC_LINUX hanging. >>> This needs further debugging, but I'm not eager. >>> This will also affect PPC_DARWIN, PPC64_DARWIN, PPC32_OPENBSD, >>> PPC32_NETBSD, PPC32_FREEBSD, etc., but these platforms are little used or >>> nonexistant. >>> >>> Having volatile like has been the very long standing situation though. >>> The result is that the optimizer does basically nothing. >> > From hosking at cs.purdue.edu Sun Jul 4 02:50:11 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sat, 3 Jul 2010 20:50:11 -0400 Subject: [M3commit] CVS Update: cm3 In-Reply-To: References: <20100703105709.DBD2E2474003@birch.elegosoft.com>, , Message-ID: <00538FB2-00DA-4C0E-82F3-D151B9A85A0E@cs.purdue.edu> I added it a long time back only because I saw failures with optimisation turned on. Something to do with the alias analysis (and lack of proper type information) as far as I recall. On 3 Jul 2010, at 20:44, Jay K wrote: > > Tony, just to be clear..you/I are disturbed by volatile, but it has also, I believe, like always been there. > It has been gone only very briefly, and its non-use is probably limited for other reasons (how many people are > using it, on how many platforms?). > > > - Jay > > ---------------------------------------- >> From: jay.krell at cornell.edu >> To: hosking at cs.purdue.edu; jkrell at elego.de >> CC: m3commit at elegosoft.com >> Subject: RE: [M3commit] CVS Update: cm3 >> Date: Sun, 4 Jul 2010 00:42:20 +0000 >> >> >> Not a multiprocessor. >> Still interested in selective volatile? >> >> >> This all bothers me too. >> I don't want volatile. It makes the optimized code terrible. >> But I don't want to debug any problem from removing it, beyond compilation failure. >> >> >> I can try a few things. >> This is all wierd. I swear I saw it hang several times. >> I swear I'm trying to to change "too many" variables at a time. Yes, I know, 2 is too many. >> >> >> Once I started getting version stamp mismatch, I resorted to using a cross built cm3. >> Out of necessity sort of, but that causes more flucuation of variables. >> >> Let me try again with volatile and see if it is solid. >> Then I'll try with only volatile stores. >> >> I've been trying optimized and unoptimized, and not kept good track of which when. >> >> >> - Jay >> >> >> ---------------------------------------- >>> From: hosking at cs.purdue.edu >>> Date: Sat, 3 Jul 2010 20:36:20 -0400 >>> To: jkrell at elego.de >>> CC: m3commit at elegosoft.com >>> Subject: Re: [M3commit] CVS Update: cm3 >>> >>> I am very disturbed that volatile is needed here. Can we selectively turn it on for thread-critical files like ThreadPThread and see if it fixes the problem. I wonder if the double-checked locking is broken for PPC memory model. Is this on a multi-processor? >>> >>> On 3 Jul 2010, at 12:57, Jay Krell wrote: >>> >>>> CVSROOT: /usr/cvs >>>> Changes by: jkrell at birch. 10/07/03 12:57:09 >>>> >>>> Modified files: >>>> cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c >>>> >>>> Log message: >>>> restore volatile for powerpc and powerpc64 platforms >>>> This seems to fix PPC_LINUX hanging. >>>> This needs further debugging, but I'm not eager. >>>> This will also affect PPC_DARWIN, PPC64_DARWIN, PPC32_OPENBSD, >>>> PPC32_NETBSD, PPC32_FREEBSD, etc., but these platforms are little used or >>>> nonexistant. >>>> >>>> Having volatile like has been the very long standing situation though. >>>> The result is that the optimizer does basically nothing. >>> >> > From jkrell at elego.de Sun Jul 4 09:54:39 2010 From: jkrell at elego.de (Jay Krell) Date: Sun, 4 Jul 2010 9:54:39 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100704075439.F06A62474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/04 09:54:39 Modified files: cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c Log message: having restored the historical div/mod implementation.. ARM backend resumes crashing, because it does even for unsigned 64bit divide with any mode (i.e. even the C mode, if the C compiler more resembled the Modula-3 compiler); it needs a non-null pointer from type_for_mode(TImode) In the meantime I have more trust in the gcc builtins than when I stopped using them. So then restore using the gcc builtins. And then to fix the ARM crash, add some TImode/int128 support. Just one line in type_for_mode. remove some tabs From jay.krell at cornell.edu Sun Jul 4 14:58:49 2010 From: jay.krell at cornell.edu (Jay K) Date: Sun, 4 Jul 2010 12:58:49 +0000 Subject: [M3commit] CVS Update: cm3 In-Reply-To: <00538FB2-00DA-4C0E-82F3-D151B9A85A0E@cs.purdue.edu> References: <20100703105709.DBD2E2474003@birch.elegosoft.com>, , , , , , <00538FB2-00DA-4C0E-82F3-D151B9A85A0E@cs.purdue.edu> Message-ID: Darnit and now those version stamp mispatch problems are gone too. I don't know what the heck is/was going on. ?- Jay ---------------------------------------- > From: hosking at cs.purdue.edu > Date: Sat, 3 Jul 2010 20:50:11 -0400 > To: jay.krell at cornell.edu > CC: m3commit at elegosoft.com > Subject: Re: [M3commit] CVS Update: cm3 > > I added it a long time back only because I saw failures with optimisation turned on. Something to do with the alias analysis (and lack of proper type information) as far as I recall. > > > On 3 Jul 2010, at 20:44, Jay K wrote: > > > > > Tony, just to be clear..you/I are disturbed by volatile, but it has also, I believe, like always been there. > > It has been gone only very briefly, and its non-use is probably limited for other reasons (how many people are > > using it, on how many platforms?). > > > > > > - Jay > > > > ---------------------------------------- > >> From: jay.krell at cornell.edu > >> To: hosking at cs.purdue.edu; jkrell at elego.de > >> CC: m3commit at elegosoft.com > >> Subject: RE: [M3commit] CVS Update: cm3 > >> Date: Sun, 4 Jul 2010 00:42:20 +0000 > >> > >> > >> Not a multiprocessor. > >> Still interested in selective volatile? > >> > >> > >> This all bothers me too. > >> I don't want volatile. It makes the optimized code terrible. > >> But I don't want to debug any problem from removing it, beyond compilation failure. > >> > >> > >> I can try a few things. > >> This is all wierd. I swear I saw it hang several times. > >> I swear I'm trying to to change "too many" variables at a time. Yes, I know, 2 is too many. > >> > >> > >> Once I started getting version stamp mismatch, I resorted to using a cross built cm3. > >> Out of necessity sort of, but that causes more flucuation of variables. > >> > >> Let me try again with volatile and see if it is solid. > >> Then I'll try with only volatile stores. > >> > >> I've been trying optimized and unoptimized, and not kept good track of which when. > >> > >> > >> - Jay > >> > >> > >> ---------------------------------------- > >>> From: hosking at cs.purdue.edu > >>> Date: Sat, 3 Jul 2010 20:36:20 -0400 > >>> To: jkrell at elego.de > >>> CC: m3commit at elegosoft.com > >>> Subject: Re: [M3commit] CVS Update: cm3 > >>> > >>> I am very disturbed that volatile is needed here. Can we selectively turn it on for thread-critical files like ThreadPThread and see if it fixes the problem. I wonder if the double-checked locking is broken for PPC memory model. Is this on a multi-processor? > >>> > >>> On 3 Jul 2010, at 12:57, Jay Krell wrote: > >>> > >>>> CVSROOT: /usr/cvs > >>>> Changes by: jkrell at birch. 10/07/03 12:57:09 > >>>> > >>>> Modified files: > >>>> cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c > >>>> > >>>> Log message: > >>>> restore volatile for powerpc and powerpc64 platforms > >>>> This seems to fix PPC_LINUX hanging. > >>>> This needs further debugging, but I'm not eager. > >>>> This will also affect PPC_DARWIN, PPC64_DARWIN, PPC32_OPENBSD, > >>>> PPC32_NETBSD, PPC32_FREEBSD, etc., but these platforms are little used or > >>>> nonexistant. > >>>> > >>>> Having volatile like has been the very long standing situation though. > >>>> The result is that the optimizer does basically nothing. > >>> > >> > > > From jkrell at elego.de Sun Jul 4 15:10:03 2010 From: jkrell at elego.de (Jay Krell) Date: Sun, 4 Jul 2010 15:10:03 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100704131003.E8CAB2474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/04 15:10:03 Modified files: cm3/m3-obliq/obliqlibm3/src/: ObLibM3.m3 Log message: initialize a few local integers that backend warns might be used uninitialized From jay.krell at cornell.edu Sun Jul 4 15:12:36 2010 From: jay.krell at cornell.edu (Jay K) Date: Sun, 4 Jul 2010 13:12:36 +0000 Subject: [M3commit] CVS Update: cm3 In-Reply-To: <20100704131003.E8CAB2474003@birch.elegosoft.com> References: <20100704131003.E8CAB2474003@birch.elegosoft.com> Message-ID: minor diff attached ---------------------------------------- > Date: Sun, 4 Jul 2010 15:10:03 +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/07/04 15:10:03 > > Modified files: > cm3/m3-obliq/obliqlibm3/src/: ObLibM3.m3 > > Log message: > initialize a few local integers that backend warns might be used uninitialized > -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: 1.txt URL: From jkrell at elego.de Sun Jul 4 17:26:33 2010 From: jkrell at elego.de (Jay Krell) Date: Sun, 4 Jul 2010 17:26:33 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100704152633.E6FEF2474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/04 17:26:33 Added files: cm3/m3-libs/m3core/src/float/: test_copysign.c Log message: CopySign in C From jkrell at elego.de Sun Jul 4 17:31:08 2010 From: jkrell at elego.de (Jay Krell) Date: Sun, 4 Jul 2010 17:31:08 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100704153108.E41552474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/04 17:31:08 Modified files: cm3/m3-libs/m3core/src/float/: test_copysign.c Log message: more true to the Modula-3 From jkrell at elego.de Sun Jul 4 17:37:52 2010 From: jkrell at elego.de (Jay Krell) Date: Sun, 4 Jul 2010 17:37:52 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100704153752.EDFB12474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/04 17:37:52 Modified files: cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c Log message: some steps forward and backward: remove the volatile on float stores, good turn off "ter" optimization, not great Need to investigate more. Tested only so far on AMD64_DARWIN. From jay.krell at cornell.edu Sun Jul 4 17:40:26 2010 From: jay.krell at cornell.edu (Jay K) Date: Sun, 4 Jul 2010 15:40:26 +0000 Subject: [M3commit] CVS Update: cm3 In-Reply-To: <20100704153752.EDFB12474003@birch.elegosoft.com> References: <20100704153752.EDFB12474003@birch.elegosoft.com> Message-ID: Just a little two line change attached... (with presumably major impact on floating point code) ---------------------------------------- > Date: Sun, 4 Jul 2010 17:37:52 +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/07/04 17:37:52 > > Modified files: > cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c > > Log message: > some steps forward and backward: > remove the volatile on float stores, good > turn off "ter" optimization, not great > > Need to investigate more. > > Tested only so far on AMD64_DARWIN. > -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: remove_float_volatile_ter.txt URL: From jkrell at elego.de Mon Jul 5 13:22:07 2010 From: jkrell at elego.de (Jay Krell) Date: Mon, 5 Jul 2010 13:22:07 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100705112207.5CD4E2474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/05 13:22:07 Modified files: cm3/m3-libs/m3core/src/float/IEEE/: LongFloat.m3 Log message: ../src/float/IEEE/LongFloat.m3: In function 'LongFloat__Logb': ../src/float/IEEE/LongFloat.m3:35: warning: 'M3_CtKayy_ans' is used uninitialized in this function ../src/float/IEEE/LongFloat.m3: In function 'LongFloat__NextAfter': ../src/float/IEEE/LongFloat.m3:81: warning: 'M3_CtKayy_z' is used uninitialized in this function Not really. Initialize them to 0. There is probably a better fix here, something like: NextAfter: RETURN LOOPHOLE(Rep.T{sign := yy.sign, exponent := 0, significand0 := 0, significand1 := 1}, T) Logb: RETURN LOOPHOLE (Log_of_zero, T); From jkrell at elego.de Mon Jul 5 13:28:32 2010 From: jkrell at elego.de (Jay Krell) Date: Mon, 5 Jul 2010 13:28:32 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100705112833.07AD72474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/05 13:28:32 Modified files: cm3/m3-sys/m3front/src/exprs/: CastExpr.m3 Log message: fix comments: cause => because 'cause => because From jkrell at elego.de Mon Jul 5 14:12:11 2010 From: jkrell at elego.de (Jay Krell) Date: Mon, 5 Jul 2010 14:12:11 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100705121211.4FC9F2474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/05 14:12:11 Modified files: cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c Log message: remove one tab From jkrell at elego.de Mon Jul 5 15:01:38 2010 From: jkrell at elego.de (Jay Krell) Date: Mon, 5 Jul 2010 15:01:38 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100705130138.6A09A2474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/05 15:01:38 Modified files: cm3/m3-libs/m3core/src/float/IEEE/: LongFloat.m3 Log message: go back a version, compiler change coming instead From jkrell at elego.de Mon Jul 5 15:22:28 2010 From: jkrell at elego.de (Jay Krell) Date: Mon, 5 Jul 2010 15:22:28 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100705132228.0E6D52474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/05 15:22:28 Modified files: cm3/m3-tools/cvsup/suplib/src/text_cm3/: SupMiscText.m3 Log message: ../src/text_cm3/SupMiscText.m3: In function 'SupMisc__DecodeWS': ../src/text_cm3/SupMiscText.m3:211: warning: 'M3_Bkn9rd_ch' may be used uninitialized in this function ../src/text_cm3/SupMiscText.m3:211: note: 'M3_Bkn9rd_ch' was declared here because raising an exception isn't currently "noreturn" so initialize it to 0 From jkrell at elego.de Mon Jul 5 15:25:03 2010 From: jkrell at elego.de (Jay Krell) Date: Mon, 5 Jul 2010 15:25:03 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100705132503.B27A82474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/05 15:25:03 Modified files: cm3/m3-tools/cvsup/suplib/src/: MD5Digest.m3 Log message: ../src/MD5Digest.m3: In function 'MD5Digest__FromText': ../src/MD5Digest.m3:162: warning: 'M3_AcxOUs_val' may be used uninitialized in this function ../src/MD5Digest.m3:162: note: 'M3_AcxOUs_val' was declared here From jkrell at elego.de Mon Jul 5 15:27:52 2010 From: jkrell at elego.de (Jay Krell) Date: Mon, 5 Jul 2010 15:27:52 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100705132752.80A422474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/05 15:27:52 Modified files: cm3/m3-comm/events/src/: EventStubLib.m3 Log message: ../src/EventStubLib.m3: In function 'EventStubLib__InInteger': ../src/EventStubLib.m3:1011: warning: 'M3_AcxOUs_i' may be used uninitialized in this function ../src/EventStubLib.m3:1011: note: 'M3_AcxOUs_i' was declared here ../src/EventStubLib.m3: In function 'EventStubLib__InInt32': ../src/EventStubLib.m3:1011: warning: 'M3_ENQ7Kn_i' may be used uninitialized in this function ../src/EventStubLib.m3:1011: note: 'M3_ENQ7Kn_i' was declared here From jkrell at elego.de Mon Jul 5 15:29:58 2010 From: jkrell at elego.de (Jay Krell) Date: Mon, 5 Jul 2010 15:29:58 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100705132958.480262474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/05 15:29:58 Modified files: cm3/m3-ui/juno-2/juno-machine/src/: JunoDisassem.m3 Log message: ../src/JunoDisassem.m3: In function 'JunoDisassem__P__DoSolve': ../src/JunoDisassem.m3:74: warning: 'M3_BlCZOI_z' may be used uninitialized in this function ../src/JunoDisassem.m3:74: warning: 'M3_BlCZOI_y' may be used uninitialized in this function From jkrell at elego.de Mon Jul 5 15:31:43 2010 From: jkrell at elego.de (Jay Krell) Date: Mon, 5 Jul 2010 15:31:43 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100705133143.467692474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/05 15:31:43 Modified files: cm3/m3-ui/juno-2/juno-machine/src/: JunoRT.m3 Log message: ../src/JunoRT.m3: In function 'JunoRT__DoSolve': ../src/JunoRT.m3:1266: warning: 'M3_DGwZEA_z' may be used uninitialized in this function ../src/JunoRT.m3:1266: warning: 'M3_DGwZEA_y' may be used uninitialized in this function From jkrell at elego.de Mon Jul 5 15:33:57 2010 From: jkrell at elego.de (Jay Krell) Date: Mon, 5 Jul 2010 15:33:57 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100705133357.46DC02474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/05 15:33:57 Modified files: cm3/m3-ui/bicycle/src/: PixmapFromXData.m3 Log message: ../src/PixmapFromXData.m3: In function 'PixmapFromXData__P': ../src/PixmapFromXData.m3:136: warning: 'M3_AcxOUs_mask' may be used uninitialized in this function ../src/PixmapFromXData.m3:136: note: 'M3_AcxOUs_mask' was declared here ../src/PixmapFromXData.m3:136: warning: 'M3_AcxOUs_word' may be used uninitialized in this function ../src/PixmapFromXData.m3:136: note: 'M3_AcxOUs_word' was declared here ../src/PixmapFromXData.m3: In function 'PixmapFromXData__Flip': ../src/PixmapFromXData.m3:136: warning: 'M3_AcxOUs_mask' may be used uninitialized in this function ../src/PixmapFromXData.m3:136: note: 'M3_AcxOUs_mask' was declared here ../src/PixmapFromXData.m3:136: warning: 'M3_AcxOUs_word' may be used uninitialized in this function ../src/PixmapFromXData.m3:136: note: 'M3_AcxOUs_word' was declared here From hosking at cs.purdue.edu Mon Jul 5 20:31:01 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 5 Jul 2010 14:31:01 -0400 Subject: [M3commit] CVS Update: cm3 In-Reply-To: <20100705132228.0E6D52474003@birch.elegosoft.com> References: <20100705132228.0E6D52474003@birch.elegosoft.com> Message-ID: <759A98E1-3098-49B8-BC68-B9B3F54D4230@cs.purdue.edu> Jay, I am perplexed that we are adding things to Modula-3 source because of compiler backend brokenness just to avoid back-end warnings. Better to fix the backend so that RAISE is noreturn. This should not be difficult to do. On 5 Jul 2010, at 15:22, Jay Krell wrote: > CVSROOT: /usr/cvs > Changes by: jkrell at birch. 10/07/05 15:22:28 > > Modified files: > cm3/m3-tools/cvsup/suplib/src/text_cm3/: SupMiscText.m3 > > Log message: > ../src/text_cm3/SupMiscText.m3: In function 'SupMisc__DecodeWS': > ../src/text_cm3/SupMiscText.m3:211: warning: 'M3_Bkn9rd_ch' may be used uninitialized in this function > ../src/text_cm3/SupMiscText.m3:211: note: 'M3_Bkn9rd_ch' was declared here > > because raising an exception isn't currently "noreturn" > so initialize it to 0 From hosking at elego.de Mon Jul 5 21:12:02 2010 From: hosking at elego.de (Antony Hosking) Date: Mon, 5 Jul 2010 21:12:02 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100705191202.754142474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: hosking at birch. 10/07/05 21:12:02 Modified files: cm3/m3-sys/m3front/src/misc/: Scanner.m3 Log message: Canonicalize wide char literals to avoid duplicate M3ID for 'w' and 'W'. From jay.krell at cornell.edu Mon Jul 5 22:45:57 2010 From: jay.krell at cornell.edu (Jay K) Date: Mon, 5 Jul 2010 20:45:57 +0000 Subject: [M3commit] CVS Update: cm3 In-Reply-To: <759A98E1-3098-49B8-BC68-B9B3F54D4230@cs.purdue.edu> References: <20100705132228.0E6D52474003@birch.elegosoft.com>, <759A98E1-3098-49B8-BC68-B9B3F54D4230@cs.purdue.edu> Message-ID: I will maybe see about doing better here. Initializing locals doesn't seem like such a bad change though. I like the code to be "obviously correct" by a quick read by a human. ?- Jay ---------------------------------------- > From: hosking at cs.purdue.edu > Date: Mon, 5 Jul 2010 14:31:01 -0400 > To: jkrell at elego.de > CC: m3commit at elegosoft.com > Subject: Re: [M3commit] CVS Update: cm3 > > Jay, I am perplexed that we are adding things to Modula-3 source because of compiler backend brokenness just to avoid back-end warnings. Better to fix the backend so that RAISE is noreturn. This should not be difficult to do. > > On 5 Jul 2010, at 15:22, Jay Krell wrote: > > > CVSROOT: /usr/cvs > > Changes by: jkrell at birch. 10/07/05 15:22:28 > > > > Modified files: > > cm3/m3-tools/cvsup/suplib/src/text_cm3/: SupMiscText.m3 > > > > Log message: > > ../src/text_cm3/SupMiscText.m3: In function 'SupMisc__DecodeWS': > > ../src/text_cm3/SupMiscText.m3:211: warning: 'M3_Bkn9rd_ch' may be used uninitialized in this function > > ../src/text_cm3/SupMiscText.m3:211: note: 'M3_Bkn9rd_ch' was declared here > > > > because raising an exception isn't currently "noreturn" > > so initialize it to 0 > From hosking at cs.purdue.edu Mon Jul 5 22:50:00 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 5 Jul 2010 16:50:00 -0400 Subject: [M3commit] CVS Update: cm3 In-Reply-To: References: <20100705132228.0E6D52474003@birch.elegosoft.com>, <759A98E1-3098-49B8-BC68-B9B3F54D4230@cs.purdue.edu> Message-ID: <3B74FBBA-DEE1-43E8-AB9D-631AA959D6B4@cs.purdue.edu> But we've been this route before. Modula-3 ensures every variable is initialised with a valid value. I don't see how your adding an initialiser makes it more obviously correct. On 5 Jul 2010, at 16:45, Jay K wrote: > > I will maybe see about doing better here. > Initializing locals doesn't seem like such a bad change though. > I like the code to be "obviously correct" by a quick read by a human. > > - Jay > > ---------------------------------------- >> From: hosking at cs.purdue.edu >> Date: Mon, 5 Jul 2010 14:31:01 -0400 >> To: jkrell at elego.de >> CC: m3commit at elegosoft.com >> Subject: Re: [M3commit] CVS Update: cm3 >> >> Jay, I am perplexed that we are adding things to Modula-3 source because of compiler backend brokenness just to avoid back-end warnings. Better to fix the backend so that RAISE is noreturn. This should not be difficult to do. >> >> On 5 Jul 2010, at 15:22, Jay Krell wrote: >> >>> CVSROOT: /usr/cvs >>> Changes by: jkrell at birch. 10/07/05 15:22:28 >>> >>> Modified files: >>> cm3/m3-tools/cvsup/suplib/src/text_cm3/: SupMiscText.m3 >>> >>> Log message: >>> ../src/text_cm3/SupMiscText.m3: In function 'SupMisc__DecodeWS': >>> ../src/text_cm3/SupMiscText.m3:211: warning: 'M3_Bkn9rd_ch' may be used uninitialized in this function >>> ../src/text_cm3/SupMiscText.m3:211: note: 'M3_Bkn9rd_ch' was declared here >>> >>> because raising an exception isn't currently "noreturn" >>> so initialize it to 0 >> > From jay.krell at cornell.edu Mon Jul 5 23:15:35 2010 From: jay.krell at cornell.edu (Jay K) Date: Mon, 5 Jul 2010 21:15:35 +0000 Subject: [M3commit] CVS Update: cm3 In-Reply-To: <3B74FBBA-DEE1-43E8-AB9D-631AA959D6B4@cs.purdue.edu> References: <20100705132228.0E6D52474003@birch.elegosoft.com>, , <759A98E1-3098-49B8-BC68-B9B3F54D4230@cs.purdue.edu>, , <3B74FBBA-DEE1-43E8-AB9D-631AA959D6B4@cs.purdue.edu> Message-ID: At least some of these were Word.T. "valid" is still "random" and the code is unpredictable, at least by a quick read, even if type safe. Type safe is just a minimum bar, one that should always be exceeded, even if the compiler is completely unable to validate it. That is, the compiler guarantees are from sufficient relative to correctness. ?- Jay ---------------------------------------- > From: hosking at cs.purdue.edu > Date: Mon, 5 Jul 2010 16:50:00 -0400 > To: jay.krell at cornell.edu > CC: m3commit at elegosoft.com > Subject: Re: [M3commit] CVS Update: cm3 > > But we've been this route before. Modula-3 ensures every variable is initialised with a valid value. I don't see how your adding an initialiser makes it more obviously correct. > > On 5 Jul 2010, at 16:45, Jay K wrote: > > > > > I will maybe see about doing better here. > > Initializing locals doesn't seem like such a bad change though. > > I like the code to be "obviously correct" by a quick read by a human. > > > > - Jay > > > > ---------------------------------------- > >> From: hosking at cs.purdue.edu > >> Date: Mon, 5 Jul 2010 14:31:01 -0400 > >> To: jkrell at elego.de > >> CC: m3commit at elegosoft.com > >> Subject: Re: [M3commit] CVS Update: cm3 > >> > >> Jay, I am perplexed that we are adding things to Modula-3 source because of compiler backend brokenness just to avoid back-end warnings. Better to fix the backend so that RAISE is noreturn. This should not be difficult to do. > >> > >> On 5 Jul 2010, at 15:22, Jay Krell wrote: > >> > >>> CVSROOT: /usr/cvs > >>> Changes by: jkrell at birch. 10/07/05 15:22:28 > >>> > >>> Modified files: > >>> cm3/m3-tools/cvsup/suplib/src/text_cm3/: SupMiscText.m3 > >>> > >>> Log message: > >>> ../src/text_cm3/SupMiscText.m3: In function 'SupMisc__DecodeWS': > >>> ../src/text_cm3/SupMiscText.m3:211: warning: 'M3_Bkn9rd_ch' may be used uninitialized in this function > >>> ../src/text_cm3/SupMiscText.m3:211: note: 'M3_Bkn9rd_ch' was declared here > >>> > >>> because raising an exception isn't currently "noreturn" > >>> so initialize it to 0 > >> > > > From jkrell at elego.de Mon Jul 5 23:25:58 2010 From: jkrell at elego.de (Jay Krell) Date: Mon, 5 Jul 2010 23:25:58 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100705212558.2BCD72474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/05 23:25:58 Modified files: cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c Log message: rename "volatize" to "make_volatile" move existing code to function m3cg_make_volatile which will work for being called from front end, if we decide to do that (not done here) no real change here, just some renaming Note that the terminology is a bit off perhaps, in that I believe "volatile function" to gcc backend means "noreturn function". Here it means "all the locals, parameters, temporaries are volatile". ie. function calls setjmp/vfork. (This is actually overkill of course: it should only make volatile stuff used after the second return; this could actually still be defeating a fair amount of volatile removal -- any function with a "try".) From jay.krell at cornell.edu Mon Jul 5 23:26:58 2010 From: jay.krell at cornell.edu (Jay K) Date: Mon, 5 Jul 2010 21:26:58 +0000 Subject: [M3commit] CVS Update: cm3 In-Reply-To: <20100705212558.2BCD72474003@birch.elegosoft.com> References: <20100705212558.2BCD72474003@birch.elegosoft.com> Message-ID: attached ---------------------------------------- > Date: Mon, 5 Jul 2010 23: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/07/05 23:25:58 > > Modified files: > cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c > > Log message: > rename "volatize" to "make_volatile" > move existing code to function m3cg_make_volatile which > will work for being called from front end, if we decide to do that > (not done here) > no real change here, just some renaming > > Note that the terminology is a bit off perhaps, in that > I believe "volatile function" to gcc backend means > "noreturn function". Here it means "all the locals, parameters, > temporaries are volatile". ie. function calls setjmp/vfork. > (This is actually overkill of course: it should only make > volatile stuff used after the second return; this could actually > still be defeating a fair amount of volatile removal -- any > function with a "try".) > -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: rename_volatize.txt URL: From hosking at cs.purdue.edu Mon Jul 5 23:34:51 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 5 Jul 2010 17:34:51 -0400 Subject: [M3commit] CVS Update: cm3 In-Reply-To: References: <20100705132228.0E6D52474003@birch.elegosoft.com>, , <759A98E1-3098-49B8-BC68-B9B3F54D4230@cs.purdue.edu>, , <3B74FBBA-DEE1-43E8-AB9D-631AA959D6B4@cs.purdue.edu> Message-ID: <08FF7A56-401D-49FD-A943-155B94BE41C4@cs.purdue.edu> Huh? On 5 Jul 2010, at 17:15, Jay K wrote: > > At least some of these were Word.T. "valid" is still "random" and the code is unpredictable, at least by a quick read, even if type safe. > Type safe is just a minimum bar, one that should always be exceeded, even if the compiler is completely unable to validate it. > > That is, the compiler guarantees are from sufficient relative to correctness. > > - Jay > > ---------------------------------------- >> From: hosking at cs.purdue.edu >> Date: Mon, 5 Jul 2010 16:50:00 -0400 >> To: jay.krell at cornell.edu >> CC: m3commit at elegosoft.com >> Subject: Re: [M3commit] CVS Update: cm3 >> >> But we've been this route before. Modula-3 ensures every variable is initialised with a valid value. I don't see how your adding an initialiser makes it more obviously correct. >> >> On 5 Jul 2010, at 16:45, Jay K wrote: >> >>> >>> I will maybe see about doing better here. >>> Initializing locals doesn't seem like such a bad change though. >>> I like the code to be "obviously correct" by a quick read by a human. >>> >>> - Jay >>> >>> ---------------------------------------- >>>> From: hosking at cs.purdue.edu >>>> Date: Mon, 5 Jul 2010 14:31:01 -0400 >>>> To: jkrell at elego.de >>>> CC: m3commit at elegosoft.com >>>> Subject: Re: [M3commit] CVS Update: cm3 >>>> >>>> Jay, I am perplexed that we are adding things to Modula-3 source because of compiler backend brokenness just to avoid back-end warnings. Better to fix the backend so that RAISE is noreturn. This should not be difficult to do. >>>> >>>> On 5 Jul 2010, at 15:22, Jay Krell wrote: >>>> >>>>> CVSROOT: /usr/cvs >>>>> Changes by: jkrell at birch. 10/07/05 15:22:28 >>>>> >>>>> Modified files: >>>>> cm3/m3-tools/cvsup/suplib/src/text_cm3/: SupMiscText.m3 >>>>> >>>>> Log message: >>>>> ../src/text_cm3/SupMiscText.m3: In function 'SupMisc__DecodeWS': >>>>> ../src/text_cm3/SupMiscText.m3:211: warning: 'M3_Bkn9rd_ch' may be used uninitialized in this function >>>>> ../src/text_cm3/SupMiscText.m3:211: note: 'M3_Bkn9rd_ch' was declared here >>>>> >>>>> because raising an exception isn't currently "noreturn" >>>>> so initialize it to 0 >>>> >>> >> > From hosking at cs.purdue.edu Mon Jul 5 23:35:38 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 5 Jul 2010 17:35:38 -0400 Subject: [M3commit] CVS Update: cm3 In-Reply-To: <20100705212558.2BCD72474003@birch.elegosoft.com> References: <20100705212558.2BCD72474003@birch.elegosoft.com> Message-ID: volatize is terminology from the gcc backend. It is used only for exception frames. I don't think you should make this change. On 5 Jul 2010, at 23:25, Jay Krell wrote: > CVSROOT: /usr/cvs > Changes by: jkrell at birch. 10/07/05 23:25:58 > > Modified files: > cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c > > Log message: > rename "volatize" to "make_volatile" > move existing code to function m3cg_make_volatile which > will work for being called from front end, if we decide to do that > (not done here) > no real change here, just some renaming > > Note that the terminology is a bit off perhaps, in that > I believe "volatile function" to gcc backend means > "noreturn function". Here it means "all the locals, parameters, > temporaries are volatile". ie. function calls setjmp/vfork. > (This is actually overkill of course: it should only make > volatile stuff used after the second return; this could actually > still be defeating a fair amount of volatile removal -- any > function with a "try".) From hosking at cs.purdue.edu Mon Jul 5 23:37:00 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 5 Jul 2010 17:37:00 -0400 Subject: [M3commit] CVS Update: cm3 In-Reply-To: References: <20100705212558.2BCD72474003@birch.elegosoft.com> Message-ID: You are conflating two distinct issues here. volatize is there for a different reason, and should retain its name. On 5 Jul 2010, at 17:26, Jay K wrote: > > > attached > > > ---------------------------------------- >> Date: Mon, 5 Jul 2010 23: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/07/05 23:25:58 >> >> Modified files: >> cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c >> >> Log message: >> rename "volatize" to "make_volatile" >> move existing code to function m3cg_make_volatile which >> will work for being called from front end, if we decide to do that >> (not done here) >> no real change here, just some renaming >> >> Note that the terminology is a bit off perhaps, in that >> I believe "volatile function" to gcc backend means >> "noreturn function". Here it means "all the locals, parameters, >> temporaries are volatile". ie. function calls setjmp/vfork. >> (This is actually overkill of course: it should only make >> volatile stuff used after the second return; this could actually >> still be defeating a fair amount of volatile removal -- any >> function with a "try".) >> > From jkrell at elego.de Mon Jul 5 23:39:19 2010 From: jkrell at elego.de (Jay Krell) Date: Mon, 5 Jul 2010 23:39:19 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100705213919.43D2E2474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/05 23:39:19 Modified files: cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c Log message: go back a version to 215, restoring 'volatilize'/'volatize' names From jay.krell at cornell.edu Mon Jul 5 23:39:23 2010 From: jay.krell at cornell.edu (Jay K) Date: Mon, 5 Jul 2010 21:39:23 +0000 Subject: [M3commit] CVS Update: cm3 In-Reply-To: References: <20100705212558.2BCD72474003@birch.elegosoft.com>, , Message-ID: ok ---------------------------------------- > From: hosking at cs.purdue.edu > Date: Mon, 5 Jul 2010 17:37:00 -0400 > To: jay.krell at cornell.edu > CC: m3commit at elegosoft.com > Subject: Re: [M3commit] CVS Update: cm3 > > You are conflating two distinct issues here. volatize is there for a different reason, and should retain its name. > > On 5 Jul 2010, at 17:26, Jay K wrote: > > > > > > > attached > > > > > > ---------------------------------------- > >> Date: Mon, 5 Jul 2010 23: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/07/05 23:25:58 > >> > >> Modified files: > >> cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c > >> > >> Log message: > >> rename "volatize" to "make_volatile" > >> move existing code to function m3cg_make_volatile which > >> will work for being called from front end, if we decide to do that > >> (not done here) > >> no real change here, just some renaming > >> > >> Note that the terminology is a bit off perhaps, in that > >> I believe "volatile function" to gcc backend means > >> "noreturn function". Here it means "all the locals, parameters, > >> temporaries are volatile". ie. function calls setjmp/vfork. > >> (This is actually overkill of course: it should only make > >> volatile stuff used after the second return; this could actually > >> still be defeating a fair amount of volatile removal -- any > >> function with a "try".) > >> > > > From hosking at cs.purdue.edu Mon Jul 5 23:40:50 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 5 Jul 2010 17:40:50 -0400 Subject: [M3commit] CVS Update: cm3 In-Reply-To: References: <20100705132228.0E6D52474003@birch.elegosoft.com>, , <759A98E1-3098-49B8-BC68-B9B3F54D4230@cs.purdue.edu>, , <3B74FBBA-DEE1-43E8-AB9D-631AA959D6B4@cs.purdue.edu> , <08FF7A56-401D-49FD-A943-155B94BE41C4@cs.purdue.edu> Message-ID: <5BDC54D6-DB79-4E9E-928A-CD802B274B7B@cs.purdue.edu> But the front-end should be OK with the first. It is "correct" because whatever value is in a when F1 is called is legal for a. Why should the backend give a warning? The semantics of Modula-3 allow any legal bit-value for a variable as its initial value. You will force an initialising assignment when none is required by the language spec. On 5 Jul 2010, at 17:36, Jay K wrote: > > unsigned F1() > { > unsigned a; > return a; > } > > should generate a warning. > > unsigned F1() > > { > > unsigned a = 0; > > return a; > > } > > > is much preferred. > > Just because the front end is ok with the first, doesn't make it correct. > > - Jay > > ---------------------------------------- >> Subject: Re: [M3commit] CVS Update: cm3 >> From: hosking at cs.purdue.edu >> Date: Mon, 5 Jul 2010 17:34:51 -0400 >> CC: m3commit at elegosoft.com >> To: jay.krell at cornell.edu >> >> Huh? >> >> On 5 Jul 2010, at 17:15, Jay K wrote: >> >>> >>> At least some of these were Word.T. "valid" is still "random" and the code is unpredictable, at least by a quick read, even if type safe. >>> Type safe is just a minimum bar, one that should always be exceeded, even if the compiler is completely unable to validate it. >>> >>> That is, the compiler guarantees are from sufficient relative to correctness. >>> >>> - Jay >>> >>> ---------------------------------------- >>>> From: hosking at cs.purdue.edu >>>> Date: Mon, 5 Jul 2010 16:50:00 -0400 >>>> To: jay.krell at cornell.edu >>>> CC: m3commit at elegosoft.com >>>> Subject: Re: [M3commit] CVS Update: cm3 >>>> >>>> But we've been this route before. Modula-3 ensures every variable is initialised with a valid value. I don't see how your adding an initialiser makes it more obviously correct. >>>> >>>> On 5 Jul 2010, at 16:45, Jay K wrote: >>>> >>>>> >>>>> I will maybe see about doing better here. >>>>> Initializing locals doesn't seem like such a bad change though. >>>>> I like the code to be "obviously correct" by a quick read by a human. >>>>> >>>>> - Jay >>>>> >>>>> ---------------------------------------- >>>>>> From: hosking at cs.purdue.edu >>>>>> Date: Mon, 5 Jul 2010 14:31:01 -0400 >>>>>> To: jkrell at elego.de >>>>>> CC: m3commit at elegosoft.com >>>>>> Subject: Re: [M3commit] CVS Update: cm3 >>>>>> >>>>>> Jay, I am perplexed that we are adding things to Modula-3 source because of compiler backend brokenness just to avoid back-end warnings. Better to fix the backend so that RAISE is noreturn. This should not be difficult to do. >>>>>> >>>>>> On 5 Jul 2010, at 15:22, Jay Krell wrote: >>>>>> >>>>>>> CVSROOT: /usr/cvs >>>>>>> Changes by: jkrell at birch. 10/07/05 15:22:28 >>>>>>> >>>>>>> Modified files: >>>>>>> cm3/m3-tools/cvsup/suplib/src/text_cm3/: SupMiscText.m3 >>>>>>> >>>>>>> Log message: >>>>>>> ../src/text_cm3/SupMiscText.m3: In function 'SupMisc__DecodeWS': >>>>>>> ../src/text_cm3/SupMiscText.m3:211: warning: 'M3_Bkn9rd_ch' may be used uninitialized in this function >>>>>>> ../src/text_cm3/SupMiscText.m3:211: note: 'M3_Bkn9rd_ch' was declared here >>>>>>> >>>>>>> because raising an exception isn't currently "noreturn" >>>>>>> so initialize it to 0 >>>>>> >>>>> >>>> >>> >> > From jay.krell at cornell.edu Mon Jul 5 23:36:52 2010 From: jay.krell at cornell.edu (Jay K) Date: Mon, 5 Jul 2010 21:36:52 +0000 Subject: [M3commit] CVS Update: cm3 In-Reply-To: <08FF7A56-401D-49FD-A943-155B94BE41C4@cs.purdue.edu> References: <20100705132228.0E6D52474003@birch.elegosoft.com>, , <759A98E1-3098-49B8-BC68-B9B3F54D4230@cs.purdue.edu>, , <3B74FBBA-DEE1-43E8-AB9D-631AA959D6B4@cs.purdue.edu> , <08FF7A56-401D-49FD-A943-155B94BE41C4@cs.purdue.edu> Message-ID: unsigned F1() { ?unsigned a; return a; } should generate a warning. unsigned F1() { ?unsigned a = 0; return a; } is much preferred. Just because the front end is ok with the first, doesn't make it correct. ?- Jay ---------------------------------------- > Subject: Re: [M3commit] CVS Update: cm3 > From: hosking at cs.purdue.edu > Date: Mon, 5 Jul 2010 17:34:51 -0400 > CC: m3commit at elegosoft.com > To: jay.krell at cornell.edu > > Huh? > > On 5 Jul 2010, at 17:15, Jay K wrote: > > > > > At least some of these were Word.T. "valid" is still "random" and the code is unpredictable, at least by a quick read, even if type safe. > > Type safe is just a minimum bar, one that should always be exceeded, even if the compiler is completely unable to validate it. > > > > That is, the compiler guarantees are from sufficient relative to correctness. > > > > - Jay > > > > ---------------------------------------- > >> From: hosking at cs.purdue.edu > >> Date: Mon, 5 Jul 2010 16:50:00 -0400 > >> To: jay.krell at cornell.edu > >> CC: m3commit at elegosoft.com > >> Subject: Re: [M3commit] CVS Update: cm3 > >> > >> But we've been this route before. Modula-3 ensures every variable is initialised with a valid value. I don't see how your adding an initialiser makes it more obviously correct. > >> > >> On 5 Jul 2010, at 16:45, Jay K wrote: > >> > >>> > >>> I will maybe see about doing better here. > >>> Initializing locals doesn't seem like such a bad change though. > >>> I like the code to be "obviously correct" by a quick read by a human. > >>> > >>> - Jay > >>> > >>> ---------------------------------------- > >>>> From: hosking at cs.purdue.edu > >>>> Date: Mon, 5 Jul 2010 14:31:01 -0400 > >>>> To: jkrell at elego.de > >>>> CC: m3commit at elegosoft.com > >>>> Subject: Re: [M3commit] CVS Update: cm3 > >>>> > >>>> Jay, I am perplexed that we are adding things to Modula-3 source because of compiler backend brokenness just to avoid back-end warnings. Better to fix the backend so that RAISE is noreturn. This should not be difficult to do. > >>>> > >>>> On 5 Jul 2010, at 15:22, Jay Krell wrote: > >>>> > >>>>> CVSROOT: /usr/cvs > >>>>> Changes by: jkrell at birch. 10/07/05 15:22:28 > >>>>> > >>>>> Modified files: > >>>>> cm3/m3-tools/cvsup/suplib/src/text_cm3/: SupMiscText.m3 > >>>>> > >>>>> Log message: > >>>>> ../src/text_cm3/SupMiscText.m3: In function 'SupMisc__DecodeWS': > >>>>> ../src/text_cm3/SupMiscText.m3:211: warning: 'M3_Bkn9rd_ch' may be used uninitialized in this function > >>>>> ../src/text_cm3/SupMiscText.m3:211: note: 'M3_Bkn9rd_ch' was declared here > >>>>> > >>>>> because raising an exception isn't currently "noreturn" > >>>>> so initialize it to 0 > >>>> > >>> > >> > > > From jay.krell at cornell.edu Mon Jul 5 23:46:49 2010 From: jay.krell at cornell.edu (Jay K) Date: Mon, 5 Jul 2010 21:46:49 +0000 Subject: [M3commit] CVS Update: cm3 In-Reply-To: <5BDC54D6-DB79-4E9E-928A-CD802B274B7B@cs.purdue.edu> References: <20100705132228.0E6D52474003@birch.elegosoft.com>, , , <759A98E1-3098-49B8-BC68-B9B3F54D4230@cs.purdue.edu>, , , , <3B74FBBA-DEE1-43E8-AB9D-631AA959D6B4@cs.purdue.edu>, , , <08FF7A56-401D-49FD-A943-155B94BE41C4@cs.purdue.edu>, , <5BDC54D6-DB79-4E9E-928A-CD802B274B7B@cs.purdue.edu> Message-ID: Meeting the language spec is inadequate. It is a "quality of implementation" thing. Do you want your C compiler to be silent about this code? No. Or do you want it to try a little harder and point out bugs in your code? Even where it meets the language spec? Yes. ?? Maybe meeting the language spec is more meaningful for Modula-3 than for C, but still inadequate. Now, compiler can't in general be a "correct program proofer", but it can and does catch a few things and that is a good thing not to be avoided. - Jay ---------------------------------------- > From: hosking at cs.purdue.edu > Date: Mon, 5 Jul 2010 17:40:50 -0400 > To: jay.krell at cornell.edu > CC: m3commit at elegosoft.com > Subject: Re: [M3commit] CVS Update: cm3 > > But the front-end should be OK with the first. It is "correct" because whatever value is in a when F1 is called is legal for a. Why should the backend give a warning? The semantics of Modula-3 allow any legal bit-value for a variable as its initial value. You will force an initialising assignment when none is required by the language spec. > > On 5 Jul 2010, at 17:36, Jay K wrote: > > > > > unsigned F1() > > { > > unsigned a; > > return a; > > } > > > > should generate a warning. > > > > unsigned F1() > > > > { > > > > unsigned a = 0; > > > > return a; > > > > } > > > > > > is much preferred. > > > > Just because the front end is ok with the first, doesn't make it correct. > > > > - Jay > > > > ---------------------------------------- > >> Subject: Re: [M3commit] CVS Update: cm3 > >> From: hosking at cs.purdue.edu > >> Date: Mon, 5 Jul 2010 17:34:51 -0400 > >> CC: m3commit at elegosoft.com > >> To: jay.krell at cornell.edu > >> > >> Huh? > >> > >> On 5 Jul 2010, at 17:15, Jay K wrote: > >> > >>> > >>> At least some of these were Word.T. "valid" is still "random" and the code is unpredictable, at least by a quick read, even if type safe. > >>> Type safe is just a minimum bar, one that should always be exceeded, even if the compiler is completely unable to validate it. > >>> > >>> That is, the compiler guarantees are from sufficient relative to correctness. > >>> > >>> - Jay > >>> > >>> ---------------------------------------- > >>>> From: hosking at cs.purdue.edu > >>>> Date: Mon, 5 Jul 2010 16:50:00 -0400 > >>>> To: jay.krell at cornell.edu > >>>> CC: m3commit at elegosoft.com > >>>> Subject: Re: [M3commit] CVS Update: cm3 > >>>> > >>>> But we've been this route before. Modula-3 ensures every variable is initialised with a valid value. I don't see how your adding an initialiser makes it more obviously correct. > >>>> > >>>> On 5 Jul 2010, at 16:45, Jay K wrote: > >>>> > >>>>> > >>>>> I will maybe see about doing better here. > >>>>> Initializing locals doesn't seem like such a bad change though. > >>>>> I like the code to be "obviously correct" by a quick read by a human. > >>>>> > >>>>> - Jay > >>>>> > >>>>> ---------------------------------------- > >>>>>> From: hosking at cs.purdue.edu > >>>>>> Date: Mon, 5 Jul 2010 14:31:01 -0400 > >>>>>> To: jkrell at elego.de > >>>>>> CC: m3commit at elegosoft.com > >>>>>> Subject: Re: [M3commit] CVS Update: cm3 > >>>>>> > >>>>>> Jay, I am perplexed that we are adding things to Modula-3 source because of compiler backend brokenness just to avoid back-end warnings. Better to fix the backend so that RAISE is noreturn. This should not be difficult to do. > >>>>>> > >>>>>> On 5 Jul 2010, at 15:22, Jay Krell wrote: > >>>>>> > >>>>>>> CVSROOT: /usr/cvs > >>>>>>> Changes by: jkrell at birch. 10/07/05 15:22:28 > >>>>>>> > >>>>>>> Modified files: > >>>>>>> cm3/m3-tools/cvsup/suplib/src/text_cm3/: SupMiscText.m3 > >>>>>>> > >>>>>>> Log message: > >>>>>>> ../src/text_cm3/SupMiscText.m3: In function 'SupMisc__DecodeWS': > >>>>>>> ../src/text_cm3/SupMiscText.m3:211: warning: 'M3_Bkn9rd_ch' may be used uninitialized in this function > >>>>>>> ../src/text_cm3/SupMiscText.m3:211: note: 'M3_Bkn9rd_ch' was declared here > >>>>>>> > >>>>>>> because raising an exception isn't currently "noreturn" > >>>>>>> so initialize it to 0 > >>>>>> > >>>>> > >>>> > >>> > >> > > > From jay.krell at cornell.edu Mon Jul 5 23:51:27 2010 From: jay.krell at cornell.edu (Jay K) Date: Mon, 5 Jul 2010 21:51:27 +0000 Subject: [M3commit] CVS Update: cm3 In-Reply-To: <08FF7A56-401D-49FD-A943-155B94BE41C4@cs.purdue.edu> References: <20100705132228.0E6D52474003@birch.elegosoft.com>, , <759A98E1-3098-49B8-BC68-B9B3F54D4230@cs.purdue.edu>, , <3B74FBBA-DEE1-43E8-AB9D-631AA959D6B4@cs.purdue.edu> , <08FF7A56-401D-49FD-A943-155B94BE41C4@cs.purdue.edu> Message-ID: As a human reading code (very finite cycles), I don't like to see: VAR a: type; BEGIN ... END no matter the contents of "...". I'd much rather see: VAR a: type := 0; and know very quickly and without a doubt that a is never used uninitialized. I've been bitten too much by microoptimizations around not initializing locals. Some large fraction of the time the compiler will optimize away the initialization. ? (ie. depending on the contents of "...") Some other large fraction of the time the performance difference will be unmeasurable. ?? So much code is I/O bound already, let alone compute bound by more significant "algorithmic" factors. And then some small fraction of the time, maybe, it will be a bad pessimization. I just don't think it is worth the risk. ?- Jay ---------------------------------------- > Subject: Re: [M3commit] CVS Update: cm3 > From: hosking at cs.purdue.edu > Date: Mon, 5 Jul 2010 17:34:51 -0400 > CC: m3commit at elegosoft.com > To: jay.krell at cornell.edu > > Huh? > > On 5 Jul 2010, at 17:15, Jay K wrote: > > > > > At least some of these were Word.T. "valid" is still "random" and the code is unpredictable, at least by a quick read, even if type safe. > > Type safe is just a minimum bar, one that should always be exceeded, even if the compiler is completely unable to validate it. > > > > That is, the compiler guarantees are from sufficient relative to correctness. > > > > - Jay > > > > ---------------------------------------- > >> From: hosking at cs.purdue.edu > >> Date: Mon, 5 Jul 2010 16:50:00 -0400 > >> To: jay.krell at cornell.edu > >> CC: m3commit at elegosoft.com > >> Subject: Re: [M3commit] CVS Update: cm3 > >> > >> But we've been this route before. Modula-3 ensures every variable is initialised with a valid value. I don't see how your adding an initialiser makes it more obviously correct. > >> > >> On 5 Jul 2010, at 16:45, Jay K wrote: > >> > >>> > >>> I will maybe see about doing better here. > >>> Initializing locals doesn't seem like such a bad change though. > >>> I like the code to be "obviously correct" by a quick read by a human. > >>> > >>> - Jay > >>> > >>> ---------------------------------------- > >>>> From: hosking at cs.purdue.edu > >>>> Date: Mon, 5 Jul 2010 14:31:01 -0400 > >>>> To: jkrell at elego.de > >>>> CC: m3commit at elegosoft.com > >>>> Subject: Re: [M3commit] CVS Update: cm3 > >>>> > >>>> Jay, I am perplexed that we are adding things to Modula-3 source because of compiler backend brokenness just to avoid back-end warnings. Better to fix the backend so that RAISE is noreturn. This should not be difficult to do. > >>>> > >>>> On 5 Jul 2010, at 15:22, Jay Krell wrote: > >>>> > >>>>> CVSROOT: /usr/cvs > >>>>> Changes by: jkrell at birch. 10/07/05 15:22:28 > >>>>> > >>>>> Modified files: > >>>>> cm3/m3-tools/cvsup/suplib/src/text_cm3/: SupMiscText.m3 > >>>>> > >>>>> Log message: > >>>>> ../src/text_cm3/SupMiscText.m3: In function 'SupMisc__DecodeWS': > >>>>> ../src/text_cm3/SupMiscText.m3:211: warning: 'M3_Bkn9rd_ch' may be used uninitialized in this function > >>>>> ../src/text_cm3/SupMiscText.m3:211: note: 'M3_Bkn9rd_ch' was declared here > >>>>> > >>>>> because raising an exception isn't currently "noreturn" > >>>>> so initialize it to 0 > >>>> > >>> > >> > > > From jkrell at elego.de Tue Jul 6 00:16:43 2010 From: jkrell at elego.de (Jay Krell) Date: Tue, 6 Jul 2010 0:16:43 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100705221643.6A4042474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/06 00:16:43 Modified files: cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c Log message: add some asserts around bit field offsets and sizes, that they are all <= 64 and <= TYPE_PRECISION, as well their sums are (which is redundant but ok) one small branch of insert looks pointless, assert(false) From jay.krell at cornell.edu Tue Jul 6 00:18:24 2010 From: jay.krell at cornell.edu (Jay K) Date: Mon, 5 Jul 2010 22:18:24 +0000 Subject: [M3commit] CVS Update: cm3 In-Reply-To: <20100705221643.6A4042474003@birch.elegosoft.com> References: <20100705221643.6A4042474003@birch.elegosoft.com> Message-ID: ---------------------------------------- > Date: Tue, 6 Jul 2010 00:16:43 +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/07/06 00:16:43 > > Modified files: > cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c > > Log message: > add some asserts around bit field offsets and sizes, > that they are all <= 64 and <= TYPE_PRECISION, as well > their sums are (which is redundant but ok) > one small branch of insert looks pointless, assert(false) -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: bitfield_asserts.txt URL: From jay.krell at cornell.edu Tue Jul 6 00:22:53 2010 From: jay.krell at cornell.edu (Jay K) Date: Mon, 5 Jul 2010 22:22:53 +0000 Subject: [M3commit] CVS Update: cm3 In-Reply-To: References: <20100705132228.0E6D52474003@birch.elegosoft.com>, , , <759A98E1-3098-49B8-BC68-B9B3F54D4230@cs.purdue.edu>, , , , <3B74FBBA-DEE1-43E8-AB9D-631AA959D6B4@cs.purdue.edu>, Message-ID: > That is, the compiler guarantees are from sufficient relative to correctness. Was supposed to say *far* from sufficient.. - Jay From hosking at cs.purdue.edu Tue Jul 6 00:42:20 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 5 Jul 2010 18:42:20 -0400 Subject: [M3commit] CVS Update: cm3 In-Reply-To: References: <20100705132228.0E6D52474003@birch.elegosoft.com>, , , <759A98E1-3098-49B8-BC68-B9B3F54D4230@cs.purdue.edu>, , , , <3B74FBBA-DEE1-43E8-AB9D-631AA959D6B4@cs.purdue.edu>, , , <08FF7A56-401D-49FD-A943-155B94BE41C4@cs.purdue.edu>, , <5BDC54D6-DB79-4E9E-928A-CD802B274B7B@cs.purdue.edu> Message-ID: <5C74B751-B423-4919-A990-130C384D2CA9@cs.purdue.edu> Your C compiler will be silent about this code unless you ask it to warn you. On 5 Jul 2010, at 17:46, Jay K wrote: > Meeting the language spec is inadequate. What? > It is a "quality of implementation" thing. > Do you want your C compiler to be silent about this code? No. Why not? > Or do you want it to try a little harder and point out bugs in your code? Those are C bugs because C says nothing about variable initialisation. > Even where it meets the language spec? Yes. > Maybe meeting the language spec is more meaningful for Modula-3 than for C, but still inadequate. > Now, compiler can't in general be a "correct program proofer", but it can and does catch a few things and that is a good thing not to be avoided. > > > - Jay > > ---------------------------------------- >> From: hosking at cs.purdue.edu >> Date: Mon, 5 Jul 2010 17:40:50 -0400 >> To: jay.krell at cornell.edu >> CC: m3commit at elegosoft.com >> Subject: Re: [M3commit] CVS Update: cm3 >> >> But the front-end should be OK with the first. It is "correct" because whatever value is in a when F1 is called is legal for a. Why should the backend give a warning? The semantics of Modula-3 allow any legal bit-value for a variable as its initial value. You will force an initialising assignment when none is required by the language spec. >> >> On 5 Jul 2010, at 17:36, Jay K wrote: >> >>> >>> unsigned F1() >>> { >>> unsigned a; >>> return a; >>> } >>> >>> should generate a warning. >>> >>> unsigned F1() >>> >>> { >>> >>> unsigned a = 0; >>> >>> return a; >>> >>> } >>> >>> >>> is much preferred. >>> >>> Just because the front end is ok with the first, doesn't make it correct. >>> >>> - Jay >>> >>> ---------------------------------------- >>>> Subject: Re: [M3commit] CVS Update: cm3 >>>> From: hosking at cs.purdue.edu >>>> Date: Mon, 5 Jul 2010 17:34:51 -0400 >>>> CC: m3commit at elegosoft.com >>>> To: jay.krell at cornell.edu >>>> >>>> Huh? >>>> >>>> On 5 Jul 2010, at 17:15, Jay K wrote: >>>> >>>>> >>>>> At least some of these were Word.T. "valid" is still "random" and the code is unpredictable, at least by a quick read, even if type safe. >>>>> Type safe is just a minimum bar, one that should always be exceeded, even if the compiler is completely unable to validate it. >>>>> >>>>> That is, the compiler guarantees are from sufficient relative to correctness. >>>>> >>>>> - Jay >>>>> >>>>> ---------------------------------------- >>>>>> From: hosking at cs.purdue.edu >>>>>> Date: Mon, 5 Jul 2010 16:50:00 -0400 >>>>>> To: jay.krell at cornell.edu >>>>>> CC: m3commit at elegosoft.com >>>>>> Subject: Re: [M3commit] CVS Update: cm3 >>>>>> >>>>>> But we've been this route before. Modula-3 ensures every variable is initialised with a valid value. I don't see how your adding an initialiser makes it more obviously correct. >>>>>> >>>>>> On 5 Jul 2010, at 16:45, Jay K wrote: >>>>>> >>>>>>> >>>>>>> I will maybe see about doing better here. >>>>>>> Initializing locals doesn't seem like such a bad change though. >>>>>>> I like the code to be "obviously correct" by a quick read by a human. >>>>>>> >>>>>>> - Jay >>>>>>> >>>>>>> ---------------------------------------- >>>>>>>> From: hosking at cs.purdue.edu >>>>>>>> Date: Mon, 5 Jul 2010 14:31:01 -0400 >>>>>>>> To: jkrell at elego.de >>>>>>>> CC: m3commit at elegosoft.com >>>>>>>> Subject: Re: [M3commit] CVS Update: cm3 >>>>>>>> >>>>>>>> Jay, I am perplexed that we are adding things to Modula-3 source because of compiler backend brokenness just to avoid back-end warnings. Better to fix the backend so that RAISE is noreturn. This should not be difficult to do. >>>>>>>> >>>>>>>> On 5 Jul 2010, at 15:22, Jay Krell wrote: >>>>>>>> >>>>>>>>> CVSROOT: /usr/cvs >>>>>>>>> Changes by: jkrell at birch. 10/07/05 15:22:28 >>>>>>>>> >>>>>>>>> Modified files: >>>>>>>>> cm3/m3-tools/cvsup/suplib/src/text_cm3/: SupMiscText.m3 >>>>>>>>> >>>>>>>>> Log message: >>>>>>>>> ../src/text_cm3/SupMiscText.m3: In function 'SupMisc__DecodeWS': >>>>>>>>> ../src/text_cm3/SupMiscText.m3:211: warning: 'M3_Bkn9rd_ch' may be used uninitialized in this function >>>>>>>>> ../src/text_cm3/SupMiscText.m3:211: note: 'M3_Bkn9rd_ch' was declared here >>>>>>>>> >>>>>>>>> because raising an exception isn't currently "noreturn" >>>>>>>>> so initialize it to 0 >>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >> > From hosking at cs.purdue.edu Tue Jul 6 00:44:16 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 5 Jul 2010 18:44:16 -0400 Subject: [M3commit] CVS Update: cm3 In-Reply-To: References: <20100705132228.0E6D52474003@birch.elegosoft.com>, , <759A98E1-3098-49B8-BC68-B9B3F54D4230@cs.purdue.edu>, , <3B74FBBA-DEE1-43E8-AB9D-631AA959D6B4@cs.purdue.edu> , <08FF7A56-401D-49FD-A943-155B94BE41C4@cs.purdue.edu> Message-ID: <6331F39C-AA28-4AC1-8C87-3D47D52D0C55@cs.purdue.edu> That is you view, but at odds with why Modula-3 was designed the way it was. I think we've already had this conversation before. The point is that even when a variable is initialised to 0 as you prefer there may still be bugs in the program. You are seeing Modula-3 through C spectacles, where so much of the language is undefined. On 5 Jul 2010, at 17:51, Jay K wrote: > > As a human reading code (very finite cycles), I don't like to see: > > > VAR a: type; > BEGIN > ... > END > > > no matter the contents of "...". > > > I'd much rather see: > > > VAR a: type := 0; > > > > and know very quickly and without a doubt that a is never used uninitialized. > I've been bitten too much by microoptimizations around not initializing locals. > Some large fraction of the time the compiler will optimize away the initialization. > (ie. depending on the contents of "...") > Some other large fraction of the time the performance difference will be unmeasurable. > So much code is I/O bound already, let alone compute bound by more significant "algorithmic" factors. > And then some small fraction of the time, maybe, it will be a bad pessimization. > > > I just don't think it is worth the risk. > > > - Jay > > > > ---------------------------------------- >> Subject: Re: [M3commit] CVS Update: cm3 >> From: hosking at cs.purdue.edu >> Date: Mon, 5 Jul 2010 17:34:51 -0400 >> CC: m3commit at elegosoft.com >> To: jay.krell at cornell.edu >> >> Huh? >> >> On 5 Jul 2010, at 17:15, Jay K wrote: >> >>> >>> At least some of these were Word.T. "valid" is still "random" and the code is unpredictable, at least by a quick read, even if type safe. >>> Type safe is just a minimum bar, one that should always be exceeded, even if the compiler is completely unable to validate it. >>> >>> That is, the compiler guarantees are from sufficient relative to correctness. >>> >>> - Jay >>> >>> ---------------------------------------- >>>> From: hosking at cs.purdue.edu >>>> Date: Mon, 5 Jul 2010 16:50:00 -0400 >>>> To: jay.krell at cornell.edu >>>> CC: m3commit at elegosoft.com >>>> Subject: Re: [M3commit] CVS Update: cm3 >>>> >>>> But we've been this route before. Modula-3 ensures every variable is initialised with a valid value. I don't see how your adding an initialiser makes it more obviously correct. >>>> >>>> On 5 Jul 2010, at 16:45, Jay K wrote: >>>> >>>>> >>>>> I will maybe see about doing better here. >>>>> Initializing locals doesn't seem like such a bad change though. >>>>> I like the code to be "obviously correct" by a quick read by a human. >>>>> >>>>> - Jay >>>>> >>>>> ---------------------------------------- >>>>>> From: hosking at cs.purdue.edu >>>>>> Date: Mon, 5 Jul 2010 14:31:01 -0400 >>>>>> To: jkrell at elego.de >>>>>> CC: m3commit at elegosoft.com >>>>>> Subject: Re: [M3commit] CVS Update: cm3 >>>>>> >>>>>> Jay, I am perplexed that we are adding things to Modula-3 source because of compiler backend brokenness just to avoid back-end warnings. Better to fix the backend so that RAISE is noreturn. This should not be difficult to do. >>>>>> >>>>>> On 5 Jul 2010, at 15:22, Jay Krell wrote: >>>>>> >>>>>>> CVSROOT: /usr/cvs >>>>>>> Changes by: jkrell at birch. 10/07/05 15:22:28 >>>>>>> >>>>>>> Modified files: >>>>>>> cm3/m3-tools/cvsup/suplib/src/text_cm3/: SupMiscText.m3 >>>>>>> >>>>>>> Log message: >>>>>>> ../src/text_cm3/SupMiscText.m3: In function 'SupMisc__DecodeWS': >>>>>>> ../src/text_cm3/SupMiscText.m3:211: warning: 'M3_Bkn9rd_ch' may be used uninitialized in this function >>>>>>> ../src/text_cm3/SupMiscText.m3:211: note: 'M3_Bkn9rd_ch' was declared here >>>>>>> >>>>>>> because raising an exception isn't currently "noreturn" >>>>>>> so initialize it to 0 >>>>>> >>>>> >>>> >>> >> > From jay.krell at cornell.edu Tue Jul 6 00:54:38 2010 From: jay.krell at cornell.edu (Jay K) Date: Mon, 5 Jul 2010 22:54:38 +0000 Subject: [M3commit] CVS Update: cm3 In-Reply-To: <5C74B751-B423-4919-A990-130C384D2CA9@cs.purdue.edu> References: <20100705132228.0E6D52474003@birch.elegosoft.com>, , ,,<759A98E1-3098-49B8-BC68-B9B3F54D4230@cs.purdue.edu>, ,,, , , <3B74FBBA-DEE1-43E8-AB9D-631AA959D6B4@cs.purdue.edu>, , , , , <08FF7A56-401D-49FD-A943-155B94BE41C4@cs.purdue.edu>, , , , <5BDC54D6-DB79-4E9E-928A-CD802B274B7B@cs.purdue.edu>, , <5C74B751-B423-4919-A990-130C384D2CA9@cs.purdue.edu> Message-ID: ?> Your C compiler will be silent about this code unless you ask it to warn you. ?These days, most people know to ask for these warnings. ?The warnings are fairly accurate and more often find real bugs than complain about correct code. ?> > Do you want your C compiler to be silent about this code? No. ?> Why not. The compiler, at least when optimizing (doing data/control flow analysis), can easily find bugs in code. Asking it not to is just the wrong thing to do. ?- Jay ---------------------------------------- > From: hosking at cs.purdue.edu > Date: Mon, 5 Jul 2010 18:42:20 -0400 > To: jay.krell at cornell.edu > CC: m3commit at elegosoft.com > Subject: Re: [M3commit] CVS Update: cm3 > > Your C compiler will be silent about this code unless you ask it to warn you. > > On 5 Jul 2010, at 17:46, Jay K wrote: > > > Meeting the language spec is inadequate. > > What? > > > It is a "quality of implementation" thing. > > Do you want your C compiler to be silent about this code? No. > > Why not? > > > Or do you want it to try a little harder and point out bugs in your code? > > Those are C bugs because C says nothing about variable initialisation. > > > Even where it meets the language spec? Yes. > > Maybe meeting the language spec is more meaningful for Modula-3 than for C, but still inadequate. > > Now, compiler can't in general be a "correct program proofer", but it can and does catch a few things and that is a good thing not to be avoided. > > > > > > - Jay > > > > ---------------------------------------- > >> From: hosking at cs.purdue.edu > >> Date: Mon, 5 Jul 2010 17:40:50 -0400 > >> To: jay.krell at cornell.edu > >> CC: m3commit at elegosoft.com > >> Subject: Re: [M3commit] CVS Update: cm3 > >> > >> But the front-end should be OK with the first. It is "correct" because whatever value is in a when F1 is called is legal for a. Why should the backend give a warning? The semantics of Modula-3 allow any legal bit-value for a variable as its initial value. You will force an initialising assignment when none is required by the language spec. > >> > >> On 5 Jul 2010, at 17:36, Jay K wrote: > >> > >>> > >>> unsigned F1() > >>> { > >>> unsigned a; > >>> return a; > >>> } > >>> > >>> should generate a warning. > >>> > >>> unsigned F1() > >>> > >>> { > >>> > >>> unsigned a = 0; > >>> > >>> return a; > >>> > >>> } > >>> > >>> > >>> is much preferred. > >>> > >>> Just because the front end is ok with the first, doesn't make it correct. > >>> > >>> - Jay > >>> > >>> ---------------------------------------- > >>>> Subject: Re: [M3commit] CVS Update: cm3 > >>>> From: hosking at cs.purdue.edu > >>>> Date: Mon, 5 Jul 2010 17:34:51 -0400 > >>>> CC: m3commit at elegosoft.com > >>>> To: jay.krell at cornell.edu > >>>> > >>>> Huh? > >>>> > >>>> On 5 Jul 2010, at 17:15, Jay K wrote: > >>>> > >>>>> > >>>>> At least some of these were Word.T. "valid" is still "random" and the code is unpredictable, at least by a quick read, even if type safe. > >>>>> Type safe is just a minimum bar, one that should always be exceeded, even if the compiler is completely unable to validate it. > >>>>> > >>>>> That is, the compiler guarantees are from sufficient relative to correctness. > >>>>> > >>>>> - Jay > >>>>> > >>>>> ---------------------------------------- > >>>>>> From: hosking at cs.purdue.edu > >>>>>> Date: Mon, 5 Jul 2010 16:50:00 -0400 > >>>>>> To: jay.krell at cornell.edu > >>>>>> CC: m3commit at elegosoft.com > >>>>>> Subject: Re: [M3commit] CVS Update: cm3 > >>>>>> > >>>>>> But we've been this route before. Modula-3 ensures every variable is initialised with a valid value. I don't see how your adding an initialiser makes it more obviously correct. > >>>>>> > >>>>>> On 5 Jul 2010, at 16:45, Jay K wrote: > >>>>>> > >>>>>>> > >>>>>>> I will maybe see about doing better here. > >>>>>>> Initializing locals doesn't seem like such a bad change though. > >>>>>>> I like the code to be "obviously correct" by a quick read by a human. > >>>>>>> > >>>>>>> - Jay > >>>>>>> > >>>>>>> ---------------------------------------- > >>>>>>>> From: hosking at cs.purdue.edu > >>>>>>>> Date: Mon, 5 Jul 2010 14:31:01 -0400 > >>>>>>>> To: jkrell at elego.de > >>>>>>>> CC: m3commit at elegosoft.com > >>>>>>>> Subject: Re: [M3commit] CVS Update: cm3 > >>>>>>>> > >>>>>>>> Jay, I am perplexed that we are adding things to Modula-3 source because of compiler backend brokenness just to avoid back-end warnings. Better to fix the backend so that RAISE is noreturn. This should not be difficult to do. > >>>>>>>> > >>>>>>>> On 5 Jul 2010, at 15:22, Jay Krell wrote: > >>>>>>>> > >>>>>>>>> CVSROOT: /usr/cvs > >>>>>>>>> Changes by: jkrell at birch. 10/07/05 15:22:28 > >>>>>>>>> > >>>>>>>>> Modified files: > >>>>>>>>> cm3/m3-tools/cvsup/suplib/src/text_cm3/: SupMiscText.m3 > >>>>>>>>> > >>>>>>>>> Log message: > >>>>>>>>> ../src/text_cm3/SupMiscText.m3: In function 'SupMisc__DecodeWS': > >>>>>>>>> ../src/text_cm3/SupMiscText.m3:211: warning: 'M3_Bkn9rd_ch' may be used uninitialized in this function > >>>>>>>>> ../src/text_cm3/SupMiscText.m3:211: note: 'M3_Bkn9rd_ch' was declared here > >>>>>>>>> > >>>>>>>>> because raising an exception isn't currently "noreturn" > >>>>>>>>> so initialize it to 0 > >>>>>>>> > >>>>>>> > >>>>>> > >>>>> > >>>> > >>> > >> > > > From jay.krell at cornell.edu Tue Jul 6 00:59:37 2010 From: jay.krell at cornell.edu (Jay K) Date: Mon, 5 Jul 2010 22:59:37 +0000 Subject: [M3commit] CVS Update: cm3 In-Reply-To: <6331F39C-AA28-4AC1-8C87-3D47D52D0C55@cs.purdue.edu> References: <20100705132228.0E6D52474003@birch.elegosoft.com>, , <759A98E1-3098-49B8-BC68-B9B3F54D4230@cs.purdue.edu>, , <3B74FBBA-DEE1-43E8-AB9D-631AA959D6B4@cs.purdue.edu> , <08FF7A56-401D-49FD-A943-155B94BE41C4@cs.purdue.edu> , <6331F39C-AA28-4AC1-8C87-3D47D52D0C55@cs.purdue.edu> Message-ID: There will *always* be bugs, in every program. Even in the CPU (really, I've seen it, some are easy to run afoul of.) ? As I said, the compiler cannot be a "general program proofer". Since that is impossible, cannot exist. But we can take some small easy steps to find some of them early. We do type checking after all. Should we not bother with that? Some simple data/control flow analysis is some of the steps to take beyond that and all compilers do it, both to optimize and to find bugs. ?Just because we can't be perfect, doesn't mean we shouldn't do what is at least "easy". ?- Jay ---------------------------------------- > Subject: Re: [M3commit] CVS Update: cm3 > From: hosking at cs.purdue.edu > Date: Mon, 5 Jul 2010 18:44:16 -0400 > CC: m3commit at elegosoft.com > To: jay.krell at cornell.edu > > That is you view, but at odds with why Modula-3 was designed the way it was. I think we've already had this conversation before. The point is that even when a variable is initialised to 0 as you prefer there may still be bugs in the program. > > You are seeing Modula-3 through C spectacles, where so much of the language is undefined. > > On 5 Jul 2010, at 17:51, Jay K wrote: > > > > > As a human reading code (very finite cycles), I don't like to see: > > > > > > VAR a: type; > > BEGIN > > ... > > END > > > > > > no matter the contents of "...". > > > > > > I'd much rather see: > > > > > > VAR a: type := 0; > > > > > > > > and know very quickly and without a doubt that a is never used uninitialized. > > I've been bitten too much by microoptimizations around not initializing locals. > > Some large fraction of the time the compiler will optimize away the initialization. > > (ie. depending on the contents of "...") > > Some other large fraction of the time the performance difference will be unmeasurable. > > So much code is I/O bound already, let alone compute bound by more significant "algorithmic" factors. > > And then some small fraction of the time, maybe, it will be a bad pessimization. > > > > > > I just don't think it is worth the risk. > > > > > > - Jay > > > > > > > > ---------------------------------------- > >> Subject: Re: [M3commit] CVS Update: cm3 > >> From: hosking at cs.purdue.edu > >> Date: Mon, 5 Jul 2010 17:34:51 -0400 > >> CC: m3commit at elegosoft.com > >> To: jay.krell at cornell.edu > >> > >> Huh? > >> > >> On 5 Jul 2010, at 17:15, Jay K wrote: > >> > >>> > >>> At least some of these were Word.T. "valid" is still "random" and the code is unpredictable, at least by a quick read, even if type safe. > >>> Type safe is just a minimum bar, one that should always be exceeded, even if the compiler is completely unable to validate it. > >>> > >>> That is, the compiler guarantees are from sufficient relative to correctness. > >>> > >>> - Jay > >>> > >>> ---------------------------------------- > >>>> From: hosking at cs.purdue.edu > >>>> Date: Mon, 5 Jul 2010 16:50:00 -0400 > >>>> To: jay.krell at cornell.edu > >>>> CC: m3commit at elegosoft.com > >>>> Subject: Re: [M3commit] CVS Update: cm3 > >>>> > >>>> But we've been this route before. Modula-3 ensures every variable is initialised with a valid value. I don't see how your adding an initialiser makes it more obviously correct. > >>>> > >>>> On 5 Jul 2010, at 16:45, Jay K wrote: > >>>> > >>>>> > >>>>> I will maybe see about doing better here. > >>>>> Initializing locals doesn't seem like such a bad change though. > >>>>> I like the code to be "obviously correct" by a quick read by a human. > >>>>> > >>>>> - Jay > >>>>> > >>>>> ---------------------------------------- > >>>>>> From: hosking at cs.purdue.edu > >>>>>> Date: Mon, 5 Jul 2010 14:31:01 -0400 > >>>>>> To: jkrell at elego.de > >>>>>> CC: m3commit at elegosoft.com > >>>>>> Subject: Re: [M3commit] CVS Update: cm3 > >>>>>> > >>>>>> Jay, I am perplexed that we are adding things to Modula-3 source because of compiler backend brokenness just to avoid back-end warnings. Better to fix the backend so that RAISE is noreturn. This should not be difficult to do. > >>>>>> > >>>>>> On 5 Jul 2010, at 15:22, Jay Krell wrote: > >>>>>> > >>>>>>> CVSROOT: /usr/cvs > >>>>>>> Changes by: jkrell at birch. 10/07/05 15:22:28 > >>>>>>> > >>>>>>> Modified files: > >>>>>>> cm3/m3-tools/cvsup/suplib/src/text_cm3/: SupMiscText.m3 > >>>>>>> > >>>>>>> Log message: > >>>>>>> ../src/text_cm3/SupMiscText.m3: In function 'SupMisc__DecodeWS': > >>>>>>> ../src/text_cm3/SupMiscText.m3:211: warning: 'M3_Bkn9rd_ch' may be used uninitialized in this function > >>>>>>> ../src/text_cm3/SupMiscText.m3:211: note: 'M3_Bkn9rd_ch' was declared here > >>>>>>> > >>>>>>> because raising an exception isn't currently "noreturn" > >>>>>>> so initialize it to 0 > >>>>>> > >>>>> > >>>> > >>> > >> > > > From hosking at cs.purdue.edu Tue Jul 6 04:36:29 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 5 Jul 2010 22:36:29 -0400 Subject: [M3commit] CVS Update: cm3 In-Reply-To: References: <20100705132228.0E6D52474003@birch.elegosoft.com> <759A98E1-3098-49B8-BC68-B9B3F54D4230@cs.purdue.edu> <3B74FBBA-DEE1-43E8-AB9D-631AA959D6B4@cs.purdue.edu> <08FF7A56-401D-49FD-A943-155B94BE41C4@cs.purdue.edu> <6331F39C-AA28-4AC1-8C87-3D47D52D0C55@cs.purdue.edu> Message-ID: <02F12035-7271-4004-BE67-3DAB17C37B3B@cs.purdue.edu> But the compiler frontend has already proved the variable has a valid initial value. Sent from my iPhone On Jul 5, 2010, at 6:59 PM, Jay K wrote: > > There will *always* be bugs, in every program. Even in the CPU (really, I've seen it, some are easy to run afoul of.) > As I said, the compiler cannot be a "general program proofer". Since that is impossible, cannot exist. > But we can take some small easy steps to find some of them early. > We do type checking after all. Should we not bother with that? > Some simple data/control flow analysis is some of the steps to take beyond that and all compilers do it, both to optimize and to find bugs. > Just because we can't be perfect, doesn't mean we shouldn't do what is at least "easy". > > > - Jay > > ---------------------------------------- >> Subject: Re: [M3commit] CVS Update: cm3 >> From: hosking at cs.purdue.edu >> Date: Mon, 5 Jul 2010 18:44:16 -0400 >> CC: m3commit at elegosoft.com >> To: jay.krell at cornell.edu >> >> That is you view, but at odds with why Modula-3 was designed the way it was. I think we've already had this conversation before. The point is that even when a variable is initialised to 0 as you prefer there may still be bugs in the program. >> >> You are seeing Modula-3 through C spectacles, where so much of the language is undefined. >> >> On 5 Jul 2010, at 17:51, Jay K wrote: >> >>> >>> As a human reading code (very finite cycles), I don't like to see: >>> >>> >>> VAR a: type; >>> BEGIN >>> ... >>> END >>> >>> >>> no matter the contents of "...". >>> >>> >>> I'd much rather see: >>> >>> >>> VAR a: type := 0; >>> >>> >>> >>> and know very quickly and without a doubt that a is never used uninitialized. >>> I've been bitten too much by microoptimizations around not initializing locals. >>> Some large fraction of the time the compiler will optimize away the initialization. >>> (ie. depending on the contents of "...") >>> Some other large fraction of the time the performance difference will be unmeasurable. >>> So much code is I/O bound already, let alone compute bound by more significant "algorithmic" factors. >>> And then some small fraction of the time, maybe, it will be a bad pessimization. >>> >>> >>> I just don't think it is worth the risk. >>> >>> >>> - Jay >>> >>> >>> >>> ---------------------------------------- >>>> Subject: Re: [M3commit] CVS Update: cm3 >>>> From: hosking at cs.purdue.edu >>>> Date: Mon, 5 Jul 2010 17:34:51 -0400 >>>> CC: m3commit at elegosoft.com >>>> To: jay.krell at cornell.edu >>>> >>>> Huh? >>>> >>>> On 5 Jul 2010, at 17:15, Jay K wrote: >>>> >>>>> >>>>> At least some of these were Word.T. "valid" is still "random" and the code is unpredictable, at least by a quick read, even if type safe. >>>>> Type safe is just a minimum bar, one that should always be exceeded, even if the compiler is completely unable to validate it. >>>>> >>>>> That is, the compiler guarantees are from sufficient relative to correctness. >>>>> >>>>> - Jay >>>>> >>>>> ---------------------------------------- >>>>>> From: hosking at cs.purdue.edu >>>>>> Date: Mon, 5 Jul 2010 16:50:00 -0400 >>>>>> To: jay.krell at cornell.edu >>>>>> CC: m3commit at elegosoft.com >>>>>> Subject: Re: [M3commit] CVS Update: cm3 >>>>>> >>>>>> But we've been this route before. Modula-3 ensures every variable is initialised with a valid value. I don't see how your adding an initialiser makes it more obviously correct. >>>>>> >>>>>> On 5 Jul 2010, at 16:45, Jay K wrote: >>>>>> >>>>>>> >>>>>>> I will maybe see about doing better here. >>>>>>> Initializing locals doesn't seem like such a bad change though. >>>>>>> I like the code to be "obviously correct" by a quick read by a human. >>>>>>> >>>>>>> - Jay >>>>>>> >>>>>>> ---------------------------------------- >>>>>>>> From: hosking at cs.purdue.edu >>>>>>>> Date: Mon, 5 Jul 2010 14:31:01 -0400 >>>>>>>> To: jkrell at elego.de >>>>>>>> CC: m3commit at elegosoft.com >>>>>>>> Subject: Re: [M3commit] CVS Update: cm3 >>>>>>>> >>>>>>>> Jay, I am perplexed that we are adding things to Modula-3 source because of compiler backend brokenness just to avoid back-end warnings. Better to fix the backend so that RAISE is noreturn. This should not be difficult to do. >>>>>>>> >>>>>>>> On 5 Jul 2010, at 15:22, Jay Krell wrote: >>>>>>>> >>>>>>>>> CVSROOT: /usr/cvs >>>>>>>>> Changes by: jkrell at birch. 10/07/05 15:22:28 >>>>>>>>> >>>>>>>>> Modified files: >>>>>>>>> cm3/m3-tools/cvsup/suplib/src/text_cm3/: SupMiscText.m3 >>>>>>>>> >>>>>>>>> Log message: >>>>>>>>> ../src/text_cm3/SupMiscText.m3: In function 'SupMisc__DecodeWS': >>>>>>>>> ../src/text_cm3/SupMiscText.m3:211: warning: 'M3_Bkn9rd_ch' may be used uninitialized in this function >>>>>>>>> ../src/text_cm3/SupMiscText.m3:211: note: 'M3_Bkn9rd_ch' was declared here >>>>>>>>> >>>>>>>>> because raising an exception isn't currently "noreturn" >>>>>>>>> so initialize it to 0 >>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >> > From jay.krell at cornell.edu Tue Jul 6 04:45:23 2010 From: jay.krell at cornell.edu (Jay K) Date: Tue, 6 Jul 2010 02:45:23 +0000 Subject: [M3commit] CVS Update: cm3 In-Reply-To: <02F12035-7271-4004-BE67-3DAB17C37B3B@cs.purdue.edu> References: <20100705132228.0E6D52474003@birch.elegosoft.com>, <759A98E1-3098-49B8-BC68-B9B3F54D4230@cs.purdue.edu>, , <3B74FBBA-DEE1-43E8-AB9D-631AA959D6B4@cs.purdue.edu>, , <08FF7A56-401D-49FD-A943-155B94BE41C4@cs.purdue.edu>, , <6331F39C-AA28-4AC1-8C87-3D47D52D0C55@cs.purdue.edu>, , <02F12035-7271-4004-BE67-3DAB17C37B3B@cs.purdue.edu> Message-ID: We are going in circles. You have a lower bar for the level of correctness you would like the compiler to try to help the programmer to attain. "valid" doesn't mean much sometimes, given that any value is "valid". Knowingly letting uninitialized data creep in is not good. You can't always help it, and you can't analyze away all bugs, but some you can. Perhaps I don't realize the extent that Modula-3's safety guarantee restrict what can happen when an uninitialized variable gets used. But, really? I mean, let's say it ends up as an array index. It might be "small and valid", and arbitrary data will be operated on, or "large an invalid" and you'll get a nice exception upon indexing. The second case is ok but the first is pretty bad. I understand zero is similar to "small and valid and wrong" but at least it is consistent, repeatable, and perhaps more likely to be found therefore. I will try making the exception raising be noreturn and maybe we can then analyze away the use of uninitialized data. But really I think these are not changes. Even if the compiler can tell the data is used uninitialized, as a programmer, maybe I don't trust the compiler's analysis there -- for example the NT386 backend doesn't do the analysis, nor does gcc when not optimizing. As a programmer I want code to be as clear and clearly correct as possible. Throwing in "unnecesssary" initialization is an easy cheap step there I think. Some large fraction of the time the compiler will optimize away such initialization anyway. Other fraction, the performance difference will not be noticable. And maybe some small fraction of the time it will be a noticable slow down, maybe. - Jay > From: hosking at cs.purdue.edu > Date: Mon, 5 Jul 2010 22:36:29 -0400 > To: jay.krell at cornell.edu > CC: m3commit at elegosoft.com > Subject: Re: [M3commit] CVS Update: cm3 > > But the compiler frontend has already proved the variable has a valid initial value. > > Sent from my iPhone > > On Jul 5, 2010, at 6:59 PM, Jay K wrote: > > > > > There will *always* be bugs, in every program. Even in the CPU (really, I've seen it, some are easy to run afoul of.) > > As I said, the compiler cannot be a "general program proofer". Since that is impossible, cannot exist. > > But we can take some small easy steps to find some of them early. > > We do type checking after all. Should we not bother with that? > > Some simple data/control flow analysis is some of the steps to take beyond that and all compilers do it, both to optimize and to find bugs. > > Just because we can't be perfect, doesn't mean we shouldn't do what is at least "easy". > > > > > > - Jay > > > > ---------------------------------------- > >> Subject: Re: [M3commit] CVS Update: cm3 > >> From: hosking at cs.purdue.edu > >> Date: Mon, 5 Jul 2010 18:44:16 -0400 > >> CC: m3commit at elegosoft.com > >> To: jay.krell at cornell.edu > >> > >> That is you view, but at odds with why Modula-3 was designed the way it was. I think we've already had this conversation before. The point is that even when a variable is initialised to 0 as you prefer there may still be bugs in the program. > >> > >> You are seeing Modula-3 through C spectacles, where so much of the language is undefined. > >> > >> On 5 Jul 2010, at 17:51, Jay K wrote: > >> > >>> > >>> As a human reading code (very finite cycles), I don't like to see: > >>> > >>> > >>> VAR a: type; > >>> BEGIN > >>> ... > >>> END > >>> > >>> > >>> no matter the contents of "...". > >>> > >>> > >>> I'd much rather see: > >>> > >>> > >>> VAR a: type := 0; > >>> > >>> > >>> > >>> and know very quickly and without a doubt that a is never used uninitialized. > >>> I've been bitten too much by microoptimizations around not initializing locals. > >>> Some large fraction of the time the compiler will optimize away the initialization. > >>> (ie. depending on the contents of "...") > >>> Some other large fraction of the time the performance difference will be unmeasurable. > >>> So much code is I/O bound already, let alone compute bound by more significant "algorithmic" factors. > >>> And then some small fraction of the time, maybe, it will be a bad pessimization. > >>> > >>> > >>> I just don't think it is worth the risk. > >>> > >>> > >>> - Jay > >>> > >>> > >>> > >>> ---------------------------------------- > >>>> Subject: Re: [M3commit] CVS Update: cm3 > >>>> From: hosking at cs.purdue.edu > >>>> Date: Mon, 5 Jul 2010 17:34:51 -0400 > >>>> CC: m3commit at elegosoft.com > >>>> To: jay.krell at cornell.edu > >>>> > >>>> Huh? > >>>> > >>>> On 5 Jul 2010, at 17:15, Jay K wrote: > >>>> > >>>>> > >>>>> At least some of these were Word.T. "valid" is still "random" and the code is unpredictable, at least by a quick read, even if type safe. > >>>>> Type safe is just a minimum bar, one that should always be exceeded, even if the compiler is completely unable to validate it. > >>>>> > >>>>> That is, the compiler guarantees are from sufficient relative to correctness. > >>>>> > >>>>> - Jay > >>>>> > >>>>> ---------------------------------------- > >>>>>> From: hosking at cs.purdue.edu > >>>>>> Date: Mon, 5 Jul 2010 16:50:00 -0400 > >>>>>> To: jay.krell at cornell.edu > >>>>>> CC: m3commit at elegosoft.com > >>>>>> Subject: Re: [M3commit] CVS Update: cm3 > >>>>>> > >>>>>> But we've been this route before. Modula-3 ensures every variable is initialised with a valid value. I don't see how your adding an initialiser makes it more obviously correct. > >>>>>> > >>>>>> On 5 Jul 2010, at 16:45, Jay K wrote: > >>>>>> > >>>>>>> > >>>>>>> I will maybe see about doing better here. > >>>>>>> Initializing locals doesn't seem like such a bad change though. > >>>>>>> I like the code to be "obviously correct" by a quick read by a human. > >>>>>>> > >>>>>>> - Jay > >>>>>>> > >>>>>>> ---------------------------------------- > >>>>>>>> From: hosking at cs.purdue.edu > >>>>>>>> Date: Mon, 5 Jul 2010 14:31:01 -0400 > >>>>>>>> To: jkrell at elego.de > >>>>>>>> CC: m3commit at elegosoft.com > >>>>>>>> Subject: Re: [M3commit] CVS Update: cm3 > >>>>>>>> > >>>>>>>> Jay, I am perplexed that we are adding things to Modula-3 source because of compiler backend brokenness just to avoid back-end warnings. Better to fix the backend so that RAISE is noreturn. This should not be difficult to do. > >>>>>>>> > >>>>>>>> On 5 Jul 2010, at 15:22, Jay Krell wrote: > >>>>>>>> > >>>>>>>>> CVSROOT: /usr/cvs > >>>>>>>>> Changes by: jkrell at birch. 10/07/05 15:22:28 > >>>>>>>>> > >>>>>>>>> Modified files: > >>>>>>>>> cm3/m3-tools/cvsup/suplib/src/text_cm3/: SupMiscText.m3 > >>>>>>>>> > >>>>>>>>> Log message: > >>>>>>>>> ../src/text_cm3/SupMiscText.m3: In function 'SupMisc__DecodeWS': > >>>>>>>>> ../src/text_cm3/SupMiscText.m3:211: warning: 'M3_Bkn9rd_ch' may be used uninitialized in this function > >>>>>>>>> ../src/text_cm3/SupMiscText.m3:211: note: 'M3_Bkn9rd_ch' was declared here > >>>>>>>>> > >>>>>>>>> because raising an exception isn't currently "noreturn" > >>>>>>>>> so initialize it to 0 > >>>>>>>> > >>>>>>> > >>>>>> > >>>>> > >>>> > >>> > >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Tue Jul 6 05:15:14 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 5 Jul 2010 23:15:14 -0400 Subject: [M3commit] CVS Update: cm3 In-Reply-To: References: <20100705132228.0E6D52474003@birch.elegosoft.com>, <759A98E1-3098-49B8-BC68-B9B3F54D4230@cs.purdue.edu>, , <3B74FBBA-DEE1-43E8-AB9D-631AA959D6B4@cs.purdue.edu>, , <08FF7A56-401D-49FD-A943-155B94BE41C4@cs.purdue.edu>, , <6331F39C-AA28-4AC1-8C87-3D47D52D0C55@cs.purdue.edu>, , <02F12035-7271-4004-BE67-3DAB17C37B3B@cs.purdue.edu> Message-ID: <26F9F2BE-6D6E-4F33-A9BE-D69A6E355EA5@cs.purdue.edu> Sigh... You are tilting at windmills. On 5 Jul 2010, at 22:45, Jay K wrote: > We are going in circles. > > > You have a lower bar for the level of correctness you would like the compiler to try to help the programmer to attain. > "valid" doesn't mean much sometimes, given that any value is "valid". > > Knowingly letting uninitialized data creep in is not good. > You can't always help it, and you can't analyze away all bugs, but some you can. > > > Perhaps I don't realize the extent that Modula-3's safety guarantee restrict what can happen when an uninitialized variable gets used. > But, really? I mean, let's say it ends up as an array index. It might be "small and valid", and arbitrary data will be operated on, or "large an invalid" and you'll get a nice exception upon indexing. The second case is ok but the first is pretty bad. I understand zero is similar to "small and valid and wrong" but at least it is consistent, repeatable, and perhaps more likely to be found therefore. > > I will try making the exception raising be noreturn and maybe we can then analyze away the use of uninitialized data. > But really I think these are not changes. > Even if the compiler can tell the data is used uninitialized, as a programmer, maybe I don't trust the compiler's analysis there -- for example the NT386 backend doesn't do the analysis, nor does gcc when not optimizing. > As a programmer I want code to be as clear and clearly correct as possible. Throwing in "unnecesssary" initialization is an easy cheap step there I think. > > > Some large fraction of the time the compiler will optimize away such initialization anyway. > Other fraction, the performance difference will not be noticable. > And maybe some small fraction of the time it will be a noticable slow down, maybe. > > > - Jay > > > From: hosking at cs.purdue.edu > > Date: Mon, 5 Jul 2010 22:36:29 -0400 > > To: jay.krell at cornell.edu > > CC: m3commit at elegosoft.com > > Subject: Re: [M3commit] CVS Update: cm3 > > > > But the compiler frontend has already proved the variable has a valid initial value. > > > > Sent from my iPhone > > > > On Jul 5, 2010, at 6:59 PM, Jay K wrote: > > > > > > > > There will *always* be bugs, in every program. Even in the CPU (really, I've seen it, some are easy to run afoul of.) > > > As I said, the compiler cannot be a "general program proofer". Since that is impossible, cannot exist. > > > But we can take some small easy steps to find some of them early. > > > We do type checking after all. Should we not bother with that? > > > Some simple data/control flow analysis is some of the steps to take beyond that and all compilers do it, both to optimize and to find bugs. > > > Just because we can't be perfect, doesn't mean we shouldn't do what is at least "easy". > > > > > > > > > - Jay > > > > > > ---------------------------------------- > > >> Subject: Re: [M3commit] CVS Update: cm3 > > >> From: hosking at cs.purdue.edu > > >> Date: Mon, 5 Jul 2010 18:44:16 -0400 > > >> CC: m3commit at elegosoft.com > > >> To: jay.krell at cornell.edu > > >> > > >> That is you view, but at odds with why Modula-3 was designed the way it was. I think we've already had this conversation before. The point is that even when a variable is initialised to 0 as you prefer there may still be bugs in the program. > > >> > > >> You are seeing Modula-3 through C spectacles, where so much of the language is undefined. > > >> > > >> On 5 Jul 2010, at 17:51, Jay K wrote: > > >> > > >>> > > >>> As a human reading code (very finite cycles), I don't like to see: > > >>> > > >>> > > >>> VAR a: type; > > >>> BEGIN > > >>> ... > > >>> END > > >>> > > >>> > > >>> no matter the contents of "...". > > >>> > > >>> > > >>> I'd much rather see: > > >>> > > >>> > > >>> VAR a: type := 0; > > >>> > > >>> > > >>> > > >>> and know very quickly and without a doubt that a is never used uninitialized. > > >>> I've been bitten too much by microoptimizations around not initializing locals. > > >>> Some large fraction of the time the compiler will optimize away the initialization. > > >>> (ie. depending on the contents of "...") > > >>> Some other large fraction of the time the performance difference will be unmeasurable. > > >>> So much code is I/O bound already, let alone compute bound by more significant "algorithmic" factors. > > >>> And then some small fraction of the time, maybe, it will be a bad pessimization. > > >>> > > >>> > > >>> I just don't think it is worth the risk. > > >>> > > >>> > > >>> - Jay > > >>> > > >>> > > >>> > > >>> ---------------------------------------- > > >>>> Subject: Re: [M3commit] CVS Update: cm3 > > >>>> From: hosking at cs.purdue.edu > > >>>> Date: Mon, 5 Jul 2010 17:34:51 -0400 > > >>>> CC: m3commit at elegosoft.com > > >>>> To: jay.krell at cornell.edu > > >>>> > > >>>> Huh? > > >>>> > > >>>> On 5 Jul 2010, at 17:15, Jay K wrote: > > >>>> > > >>>>> > > >>>>> At least some of these were Word.T. "valid" is still "random" and the code is unpredictable, at least by a quick read, even if type safe. > > >>>>> Type safe is just a minimum bar, one that should always be exceeded, even if the compiler is completely unable to validate it. > > >>>>> > > >>>>> That is, the compiler guarantees are from sufficient relative to correctness. > > >>>>> > > >>>>> - Jay > > >>>>> > > >>>>> ---------------------------------------- > > >>>>>> From: hosking at cs.purdue.edu > > >>>>>> Date: Mon, 5 Jul 2010 16:50:00 -0400 > > >>>>>> To: jay.krell at cornell.edu > > >>>>>> CC: m3commit at elegosoft.com > > >>>>>> Subject: Re: [M3commit] CVS Update: cm3 > > >>>>>> > > >>>>>> But we've been this route before. Modula-3 ensures every variable is initialised with a valid value. I don't see how your adding an initialiser makes it more obviously correct. > > >>>>>> > > >>>>>> On 5 Jul 2010, at 16:45, Jay K wrote: > > >>>>>> > > >>>>>>> > > >>>>>>> I will maybe see about doing better here. > > >>>>>>> Initializing locals doesn't seem like such a bad change though. > > >>>>>>> I like the code to be "obviously correct" by a quick read by a human. > > >>>>>>> > > >>>>>>> - Jay > > >>>>>>> > > >>>>>>> ---------------------------------------- > > >>>>>>>> From: hosking at cs.purdue.edu > > >>>>>>>> Date: Mon, 5 Jul 2010 14:31:01 -0400 > > >>>>>>>> To: jkrell at elego.de > > >>>>>>>> CC: m3commit at elegosoft.com > > >>>>>>>> Subject: Re: [M3commit] CVS Update: cm3 > > >>>>>>>> > > >>>>>>>> Jay, I am perplexed that we are adding things to Modula-3 source because of compiler backend brokenness just to avoid back-end warnings. Better to fix the backend so that RAISE is noreturn. This should not be difficult to do. > > >>>>>>>> > > >>>>>>>> On 5 Jul 2010, at 15:22, Jay Krell wrote: > > >>>>>>>> > > >>>>>>>>> CVSROOT: /usr/cvs > > >>>>>>>>> Changes by: jkrell at birch. 10/07/05 15:22:28 > > >>>>>>>>> > > >>>>>>>>> Modified files: > > >>>>>>>>> cm3/m3-tools/cvsup/suplib/src/text_cm3/: SupMiscText.m3 > > >>>>>>>>> > > >>>>>>>>> Log message: > > >>>>>>>>> ../src/text_cm3/SupMiscText.m3: In function 'SupMisc__DecodeWS': > > >>>>>>>>> ../src/text_cm3/SupMiscText.m3:211: warning: 'M3_Bkn9rd_ch' may be used uninitialized in this function > > >>>>>>>>> ../src/text_cm3/SupMiscText.m3:211: note: 'M3_Bkn9rd_ch' was declared here > > >>>>>>>>> > > >>>>>>>>> because raising an exception isn't currently "noreturn" > > >>>>>>>>> so initialize it to 0 > > >>>>>>>> > > >>>>>>> > > >>>>>> > > >>>>> > > >>>> > > >>> > > >> > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jkrell at elego.de Tue Jul 6 21:36:58 2010 From: jkrell at elego.de (Jay Krell) Date: Tue, 6 Jul 2010 21:36:58 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100706193658.53C752474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/06 21:36:58 Modified files: cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c cm3/m3-sys/m3front/src/exprs/: CastExpr.m3 Log message: allow "ter"/-O3, but without causing compiling CopySign in m3core/src/float/IEEE/RealFloat.m3 to fail to compile: internal compiler error: in convert_move, at expr.c This change might not go far enough though. We might want to call Force() more often. The theory here is, I don't completely know, but that Force() inhibits optimizations done by m3front/src/misc/CG.m3, such as that might remove "taking the address of", which would then inhibit optimizations by the backend. Optimizations are being inhibited here specifically for unsafe code that is casting floats to structures, surely an acceptable small amount of code. In fact, again, consider doing this more. From hosking at elego.de Tue Jul 6 21:40:43 2010 From: hosking at elego.de (Antony Hosking) Date: Tue, 6 Jul 2010 21:40:43 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100706194043.5B9552474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: hosking at birch. 10/07/06 21:40:43 Modified files: cm3/m3-sys/m3front/src/exprs/: CastExpr.m3 Log message: Cleaner. From jay.krell at cornell.edu Tue Jul 6 21:48:44 2010 From: jay.krell at cornell.edu (Jay K) Date: Tue, 6 Jul 2010 19:48:44 +0000 Subject: [M3commit] CVS Update: cm3 In-Reply-To: <20100706194043.5B9552474003@birch.elegosoft.com> References: <20100706194043.5B9552474003@birch.elegosoft.com> Message-ID: Debatable, but ok either way. I don't like the other lines to be duplicated. Granted, only two lines. Er, let's not debate it actually. I'll have the last word, you have the last code. I'll leave it alone. :) If anyone has a solid understanding of what is going on, the comment could be better. The comment is ugly but honest, from my ignorant point of view. ?- Jay ---------------------------------------- > Date: Tue, 6 Jul 2010 21:40:43 +0000 > To: m3commit at elegosoft.com > From: hosking at elego.de > Subject: [M3commit] CVS Update: cm3 > > CVSROOT: /usr/cvs > Changes by: hosking at birch. 10/07/06 21:40:43 > > Modified files: > cm3/m3-sys/m3front/src/exprs/: CastExpr.m3 > > Log message: > Cleaner. > From jay.krell at cornell.edu Tue Jul 6 21:39:20 2010 From: jay.krell at cornell.edu (Jay K) Date: Tue, 6 Jul 2010 19:39:20 +0000 Subject: [M3commit] CVS Update: cm3 In-Reply-To: <20100706193658.53C752474003@birch.elegosoft.com> References: <20100706193658.53C752474003@birch.elegosoft.com> Message-ID: attachments don't seem to be working, we'll see if this is readable.. Index: m3cc/gcc/gcc/m3cg/parse.c =================================================================== RCS file: /usr/cvs/cm3/m3-sys/m3cc/gcc/gcc/m3cg/parse.c,v retrieving revision 1.218 diff -u -r1.218 parse.c --- m3cc/gcc/gcc/m3cg/parse.c??? 5 Jul 2010 22:16:43 -0000??? 1.218 +++ m3cc/gcc/gcc/m3cg/parse.c??? 6 Jul 2010 19:32:16 -0000 @@ -5715,7 +5715,7 @@ ?#endif ???? /*flag_strict_aliasing = 0;*/ /* consider? */ ???? /*flag_strict_overflow = 0;*/ /* consider? */ -??? flag_tree_ter = 0; /* fails to compile m3core CopySign */ +??? /*flag_tree_ter = 0;*/ /* used to break m3core CopySign, see m3front/CastExpr */ ???? /*flag_delete_null_pointer_checks = 0;*/ /* consider? */ ???? /*flag_reorder_functions = 0;*/ /* consider? */ ?? } Index: m3front/src/exprs/CastExpr.m3 =================================================================== RCS file: /usr/cvs/cm3/m3-sys/m3front/src/exprs/CastExpr.m3,v retrieving revision 1.9 diff -u -r1.9 CastExpr.m3 --- m3front/src/exprs/CastExpr.m3??? 5 Jul 2010 11:28:32 -0000??? 1.9 +++ m3front/src/exprs/CastExpr.m3??? 6 Jul 2010 19:32:16 -0000 @@ -10,6 +10,7 @@ ? ?IMPORT M3Buf, CG, Expr, ExprRep, Type, Error, OpenArrayType; ?IMPORT M3, M3ID, M3RT, Target, TInt; +FROM Target IMPORT FloatType; ? ?TYPE ?? Kind = { @@ -394,7 +395,7 @@ ???? u? := Expr.TypeOf (e); ???? t? := p.tipe; ???? sz, t_align, u_align, z_align: INTEGER; -??? u_cg: CG.Type; +??? t_cg, u_cg: CG.Type; ???? u_info, t_info: Type.Info; ?? BEGIN ???? u := Type.CheckInfo (u, u_info); @@ -402,6 +403,7 @@ ???? t_align := t_info.alignment; ???? u_align := u_info.alignment; ???? z_align := MAX (t_align, u_align); +??? t_cg := t_info.stk_type; ???? u_cg := u_info.stk_type; ???? sz := u_info.size; ???? Type.Compile (t); @@ -417,6 +419,21 @@ ???????? Expr.CompileLValue (p.expr, traced); ???????? CG.Boost_alignment (t_align); ? +??????? (* Inhibit some optimization that causes compilation to fail. e.g.: +???????? * m3core/src/float/IEEE/RealFloat.m3: +???????? * In function 'RealFloat__CopySign': +???????? * internal compiler error: in convert_move, at expr.c:371 +???????? * +???????? * ?Force() inhibits optimizations done by m3front/src/misc/CG.m3? +???????? * ?The particular optimizations are removal of address taken and +???????? * pointer indirections? ?Leaving the address taken inhibits +???????? * gcc optimization? ?Given that this is LOOPHOLE and floating point, +???????? * inhibiting optimization is very ok? +???????? *) +??????? IF p.kind = Kind.D_to_S AND (FloatType[t_cg] # FloatType[u_cg]) THEN +????????? CG.Force (); +??????? END; + ???? | Kind.D_to_A, ?????? Kind.S_to_A, ?????? Kind.V_to_A => ---------------------------------------- > Date: Tue, 6 Jul 2010 21:36: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/07/06 21:36:58 > > Modified files: > cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c > cm3/m3-sys/m3front/src/exprs/: CastExpr.m3 > > Log message: > allow "ter"/-O3, but without causing compiling CopySign in > m3core/src/float/IEEE/RealFloat.m3 to fail to compile: > internal compiler error: in convert_move, at expr.c > > This change might not go far enough though. > We might want to call Force() more often. > > The theory here is, I don't completely know, but that Force() > inhibits optimizations done by m3front/src/misc/CG.m3, such > as that might remove "taking the address of", which would > then inhibit optimizations by the backend. > > Optimizations are being inhibited here specifically for > unsafe code that is casting floats to structures, surely > an acceptable small amount of code. In fact, again, consider > doing this more. > From jkrell at elego.de Tue Jul 6 22:58:47 2010 From: jkrell at elego.de (Jay Krell) Date: Tue, 6 Jul 2010 22:58:47 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100706205847.29CA72474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/06 22:58:47 Modified files: cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c cm3/m3-sys/m3back/src/: M3x86.m3 cm3/m3-libs/m3core/src/runtime/common/: RTHooks.i3 RTHooks.m3 RuntimeError.i3 cm3/m3-sys/m3middle/src/: M3CG.i3 Log message: replace a "FIXME" comment with other comments and assertions The code was ok. Line numbers beyond around 100 million are silently truncated, same as it ever was (though the range probably used to be double) From jay.krell at cornell.edu Tue Jul 6 23:00:10 2010 From: jay.krell at cornell.edu (Jay K) Date: Tue, 6 Jul 2010 21:00:10 +0000 Subject: [M3commit] CVS Update: cm3 In-Reply-To: <20100706205847.29CA72474003@birch.elegosoft.com> References: <20100706205847.29CA72474003@birch.elegosoft.com> Message-ID: attached > Date: Tue, 6 Jul 2010 22:58:47 +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/07/06 22:58:47 > > Modified files: > cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c > cm3/m3-sys/m3back/src/: M3x86.m3 > cm3/m3-libs/m3core/src/runtime/common/: RTHooks.i3 RTHooks.m3 > RuntimeError.i3 > cm3/m3-sys/m3middle/src/: M3CG.i3 > > Log message: > replace a "FIXME" comment with other comments and assertions > The code was ok. > Line numbers beyond around 100 million are silently truncated, same as > it ever was (though the range probably used to be double) > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: 32.txt URL: From jkrell at elego.de Wed Jul 7 08:09:47 2010 From: jkrell at elego.de (Jay Krell) Date: Wed, 7 Jul 2010 8:09:47 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100707060947.ECE392474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/07 08:09:47 Modified files: cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c Log message: Allow "all" optimizations now, except flag_unit_at_a_time which fails for a "different" reason, and flag_tree_pre (partial redundancy elmination) only because I missed it since it is a few lines away, will try that shortly. From jkrell at elego.de Wed Jul 7 08:20:57 2010 From: jkrell at elego.de (Jay Krell) Date: Wed, 7 Jul 2010 8:20:57 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100707062057.34A3B2474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/07 08:20:57 Modified files: cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c Log message: partial redundancy elimination ('pre') also crashes compiling libm3/Formatter, add comment; remove all the other stuff about disabling optimizations From jkrell at elego.de Wed Jul 7 13:01:26 2010 From: jkrell at elego.de (Jay Krell) Date: Wed, 7 Jul 2010 13:01:26 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100707110126.C7F0D2474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/07 13:01:26 Modified files: cm3/m3-sys/m3tests/src/: m3makefile Added files: cm3/m3-sys/m3tests/src/p2/p241/: Main.m3 m3makefile Log message: cut down (38 lines) form of libm3/Formatter.m3 that crashes gcc backend if -O3, no volatile, 'ter' From hosking at cs.purdue.edu Wed Jul 7 17:56:30 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Wed, 7 Jul 2010 11:56:30 -0400 Subject: [M3commit] CVS Update: cm3 In-Reply-To: <20100707062057.34A3B2474003@birch.elegosoft.com> References: <20100707062057.34A3B2474003@birch.elegosoft.com> Message-ID: This is new. It used to work! On 7 Jul 2010, at 08:20, Jay Krell wrote: > CVSROOT: /usr/cvs > Changes by: jkrell at birch. 10/07/07 08:20:57 > > Modified files: > cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c > > Log message: > partial redundancy elimination ('pre') also crashes compiling libm3/Formatter, add comment; remove all the other stuff about disabling optimizations From wagner at elego.de Wed Jul 7 19:00:50 2010 From: wagner at elego.de (Olaf Wagner) Date: Wed, 7 Jul 2010 19:00:50 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100707170050.4E8342474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: wagner at birch. 10/07/07 19:00:50 Modified files: cm3/scripts/: Tag: release_branch_cm3_5_8 make-dist.sh Log message: prepare for final release build From jay.krell at cornell.edu Wed Jul 7 21:13:02 2010 From: jay.krell at cornell.edu (Jay K) Date: Wed, 7 Jul 2010 19:13:02 +0000 Subject: [M3commit] CVS Update: cm3 In-Reply-To: References: <20100707062057.34A3B2474003@birch.elegosoft.com>, Message-ID: Back when all loads and stores were volatile! And the optimizer was severely hampered. Any optimized code I looked at was full of unnecessary code. Which do you prefer? ?- Jay ---------------------------------------- > From: hosking at cs.purdue.edu > Date: Wed, 7 Jul 2010 11:56:30 -0400 > To: jkrell at elego.de > CC: m3commit at elegosoft.com > Subject: Re: [M3commit] CVS Update: cm3 > > This is new. It used to work! > > > On 7 Jul 2010, at 08:20, Jay Krell wrote: > > > CVSROOT: /usr/cvs > > Changes by: jkrell at birch. 10/07/07 08:20:57 > > > > Modified files: > > cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c > > > > Log message: > > partial redundancy elimination ('pre') also crashes compiling libm3/Formatter, add comment; remove all the other stuff about disabling optimizations > From hosking at cs.purdue.edu Wed Jul 7 21:59:08 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Wed, 7 Jul 2010 15:59:08 -0400 Subject: [M3commit] CVS Update: cm3 In-Reply-To: References: <20100707062057.34A3B2474003@birch.elegosoft.com>, , , Message-ID: <2E37CD56-4440-4927-936A-8E40B174F488@cs.purdue.edu> We already volatilise as necessary for setjmp/longjmp (at least we did when last I looked, because I remember putting it in). I would prefer to avoid volatile in all other situations where possible. On 7 Jul 2010, at 15:54, Jay K wrote: > > But I admit I'm nervous about removing all the volatile, esp. on stores. > We should have a bunch of tests using exceptions that access locals/parameters in except and finally blocks. > I'm willing to put back volatile on all stores. > Or even loads if there is justification. > > I thought there'd be a setjmp in all functions with try/except/finally, and therefore the same > pessimization, but now I'm not sure of that. > > - Jay > > ---------------------------------------- >> From: jay.krell at cornell.edu >> To: hosking at cs.purdue.edu; jkrell at elego.de >> Date: Wed, 7 Jul 2010 19:13:02 +0000 >> CC: m3commit at elegosoft.com >> Subject: Re: [M3commit] CVS Update: cm3 >> >> >> Back when all loads and stores were volatile! >> And the optimizer was severely hampered. Any optimized code I looked at was full of unnecessary code. >> Which do you prefer? >> >> - Jay >> >> ---------------------------------------- >>> From: hosking at cs.purdue.edu >>> Date: Wed, 7 Jul 2010 11:56:30 -0400 >>> To: jkrell at elego.de >>> CC: m3commit at elegosoft.com >>> Subject: Re: [M3commit] CVS Update: cm3 >>> >>> This is new. It used to work! >>> >>> >>> On 7 Jul 2010, at 08:20, Jay Krell wrote: >>> >>>> CVSROOT: /usr/cvs >>>> Changes by: jkrell at birch. 10/07/07 08:20:57 >>>> >>>> Modified files: >>>> cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c >>>> >>>> Log message: >>>> partial redundancy elimination ('pre') also crashes compiling libm3/Formatter, add comment; remove all the other stuff about disabling optimizations >>> >> > From jay.krell at cornell.edu Wed Jul 7 21:54:53 2010 From: jay.krell at cornell.edu (Jay K) Date: Wed, 7 Jul 2010 19:54:53 +0000 Subject: [M3commit] CVS Update: cm3 In-Reply-To: References: <20100707062057.34A3B2474003@birch.elegosoft.com>, , , Message-ID: But I admit I'm nervous about removing all the volatile, esp. on stores. We should have a bunch of tests using exceptions that access locals/parameters in except and finally blocks. I'm willing to put back volatile on all stores. Or even loads if there is justification. I thought there'd be a setjmp in all functions with try/except/finally, and therefore the same pessimization, but now I'm not sure of that. ?- Jay ---------------------------------------- > From: jay.krell at cornell.edu > To: hosking at cs.purdue.edu; jkrell at elego.de > Date: Wed, 7 Jul 2010 19:13:02 +0000 > CC: m3commit at elegosoft.com > Subject: Re: [M3commit] CVS Update: cm3 > > > Back when all loads and stores were volatile! > And the optimizer was severely hampered. Any optimized code I looked at was full of unnecessary code. > Which do you prefer? > > - Jay > > ---------------------------------------- > > From: hosking at cs.purdue.edu > > Date: Wed, 7 Jul 2010 11:56:30 -0400 > > To: jkrell at elego.de > > CC: m3commit at elegosoft.com > > Subject: Re: [M3commit] CVS Update: cm3 > > > > This is new. It used to work! > > > > > > On 7 Jul 2010, at 08:20, Jay Krell wrote: > > > > > CVSROOT: /usr/cvs > > > Changes by: jkrell at birch. 10/07/07 08:20:57 > > > > > > Modified files: > > > cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c > > > > > > Log message: > > > partial redundancy elimination ('pre') also crashes compiling libm3/Formatter, add comment; remove all the other stuff about disabling optimizations > > > From jay.krell at cornell.edu Wed Jul 7 22:14:49 2010 From: jay.krell at cornell.edu (Jay K) Date: Wed, 7 Jul 2010 20:14:49 +0000 Subject: [M3commit] CVS Update: cm3 In-Reply-To: <2E37CD56-4440-4927-936A-8E40B174F488@cs.purdue.edu> References: <20100707062057.34A3B2474003@birch.elegosoft.com>, , , , , , , <2E37CD56-4440-4927-936A-8E40B174F488@cs.purdue.edu> Message-ID: That's still there, for "returns twice", like setjmp, fork and/or vfork. Not sure about longjmp. Not sure if it is adequate. ?? I saw PushFrame in the crashing example but I don't think I saw setjmp. Not sure about a few things. ?- Jay ---------------------------------------- > From: hosking at cs.purdue.edu > Date: Wed, 7 Jul 2010 15:59:08 -0400 > To: jay.krell at cornell.edu > CC: m3commit at elegosoft.com > Subject: Re: [M3commit] CVS Update: cm3 > > We already volatilise as necessary for setjmp/longjmp (at least we did when last I looked, because I remember putting it in). > > I would prefer to avoid volatile in all other situations where possible. > > > On 7 Jul 2010, at 15:54, Jay K wrote: > > > > > But I admit I'm nervous about removing all the volatile, esp. on stores. > > We should have a bunch of tests using exceptions that access locals/parameters in except and finally blocks. > > I'm willing to put back volatile on all stores. > > Or even loads if there is justification. > > > > I thought there'd be a setjmp in all functions with try/except/finally, and therefore the same > > pessimization, but now I'm not sure of that. > > > > - Jay > > > > ---------------------------------------- > >> From: jay.krell at cornell.edu > >> To: hosking at cs.purdue.edu; jkrell at elego.de > >> Date: Wed, 7 Jul 2010 19:13:02 +0000 > >> CC: m3commit at elegosoft.com > >> Subject: Re: [M3commit] CVS Update: cm3 > >> > >> > >> Back when all loads and stores were volatile! > >> And the optimizer was severely hampered. Any optimized code I looked at was full of unnecessary code. > >> Which do you prefer? > >> > >> - Jay > >> > >> ---------------------------------------- > >>> From: hosking at cs.purdue.edu > >>> Date: Wed, 7 Jul 2010 11:56:30 -0400 > >>> To: jkrell at elego.de > >>> CC: m3commit at elegosoft.com > >>> Subject: Re: [M3commit] CVS Update: cm3 > >>> > >>> This is new. It used to work! > >>> > >>> > >>> On 7 Jul 2010, at 08:20, Jay Krell wrote: > >>> > >>>> CVSROOT: /usr/cvs > >>>> Changes by: jkrell at birch. 10/07/07 08:20:57 > >>>> > >>>> Modified files: > >>>> cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c > >>>> > >>>> Log message: > >>>> partial redundancy elimination ('pre') also crashes compiling libm3/Formatter, add comment; remove all the other stuff about disabling optimizations > >>> > >> > > > From jay.krell at cornell.edu Wed Jul 7 22:19:48 2010 From: jay.krell at cornell.edu (Jay K) Date: Wed, 7 Jul 2010 20:19:48 +0000 Subject: [M3commit] CVS Update: cm3 In-Reply-To: References: <20100707062057.34A3B2474003@birch.elegosoft.com>, , , , , , , , <2E37CD56-4440-4927-936A-8E40B174F488@cs.purdue.edu>, Message-ID: ps: obviously the volatization that is there is overkill, but not too far off. We only really need to volatize what is used in the except/finally blocks. It might be a closer approximation to add volatile to anything referenced in the function after we see the setjmp/fork call, instead of going and visiting all current and future locals. Even that is overkill. I assume making the load/stores volatile is the same as making the variables volatile. ?So there are other similar approaches. However I assume one dumb difference, evidenced by what you already did, is that the warnings vary. The compiler doesn't notice, I guess, that if all load/stores to a variable are volatile, then the variable itself is effectively volatile. Anyway, ok for now. Hm, maybe m3cg should offer volatile as a flag on parameters, locals, temporaries? I'm not sure the backend knows where except/finally blocks are, after all. This isn't the "make function volatile" thing I had, this is something narrower and seems like it might fit better...except, well..volatile is maybe an implementation detail. But you could just rename and get the same thing: "variable accessed in except/finally block". Or, "start except block", "start finally block", "end except block", "end finally block". ? ?- Jay ---------------------------------------- > From: jay.krell at cornell.edu > To: hosking at cs.purdue.edu > CC: m3commit at elegosoft.com > Subject: RE: [M3commit] CVS Update: cm3 > Date: Wed, 7 Jul 2010 20:14:49 +0000 > > > That's still there, for "returns twice", like setjmp, fork and/or vfork. > Not sure about longjmp. > Not sure if it is adequate. > I saw PushFrame in the crashing example but I don't think I saw setjmp. > Not sure about a few things. > > - Jay > > > ---------------------------------------- > > From: hosking at cs.purdue.edu > > Date: Wed, 7 Jul 2010 15:59:08 -0400 > > To: jay.krell at cornell.edu > > CC: m3commit at elegosoft.com > > Subject: Re: [M3commit] CVS Update: cm3 > > > > We already volatilise as necessary for setjmp/longjmp (at least we did when last I looked, because I remember putting it in). > > > > I would prefer to avoid volatile in all other situations where possible. > > > > > > On 7 Jul 2010, at 15:54, Jay K wrote: > > > > > > > > But I admit I'm nervous about removing all the volatile, esp. on stores. > > > We should have a bunch of tests using exceptions that access locals/parameters in except and finally blocks. > > > I'm willing to put back volatile on all stores. > > > Or even loads if there is justification. > > > > > > I thought there'd be a setjmp in all functions with try/except/finally, and therefore the same > > > pessimization, but now I'm not sure of that. > > > > > > - Jay > > > > > > ---------------------------------------- > > >> From: jay.krell at cornell.edu > > >> To: hosking at cs.purdue.edu; jkrell at elego.de > > >> Date: Wed, 7 Jul 2010 19:13:02 +0000 > > >> CC: m3commit at elegosoft.com > > >> Subject: Re: [M3commit] CVS Update: cm3 > > >> > > >> > > >> Back when all loads and stores were volatile! > > >> And the optimizer was severely hampered. Any optimized code I looked at was full of unnecessary code. > > >> Which do you prefer? > > >> > > >> - Jay > > >> > > >> ---------------------------------------- > > >>> From: hosking at cs.purdue.edu > > >>> Date: Wed, 7 Jul 2010 11:56:30 -0400 > > >>> To: jkrell at elego.de > > >>> CC: m3commit at elegosoft.com > > >>> Subject: Re: [M3commit] CVS Update: cm3 > > >>> > > >>> This is new. It used to work! > > >>> > > >>> > > >>> On 7 Jul 2010, at 08:20, Jay Krell wrote: > > >>> > > >>>> CVSROOT: /usr/cvs > > >>>> Changes by: jkrell at birch. 10/07/07 08:20:57 > > >>>> > > >>>> Modified files: > > >>>> cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c > > >>>> > > >>>> Log message: > > >>>> partial redundancy elimination ('pre') also crashes compiling libm3/Formatter, add comment; remove all the other stuff about disabling optimizations > > >>> > > >> > > > > > > From jkrell at elego.de Thu Jul 8 12:20:41 2010 From: jkrell at elego.de (Jay Krell) Date: Thu, 8 Jul 2010 12:20:41 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100708102041.CFC6C2474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/08 12:20:41 Modified files: cm3/m3-sys/m3cc/src/: m3makefile Log message: no actual change but commented out or disabled: append -4.3 to build_dir for 4.3 commented out configure -enable-checking=all (we should make this work) disabled switching to 4.5 for AMD64_DARWIN (should make this work, maybe the pointer use in loophole will help?) From jkrell at elego.de Fri Jul 9 10:04:30 2010 From: jkrell at elego.de (Jay Krell) Date: Fri, 9 Jul 2010 10:04:30 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100709080430.AA1DE2474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/09 10:04:30 Modified files: cm3/scripts/python/: pylib.py Log message: add mspdb100.dll to list -- support for Visual C++ 2010 From jkrell at elego.de Fri Jul 9 10:52:20 2010 From: jkrell at elego.de (Jay Krell) Date: Fri, 9 Jul 2010 10:52:20 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100709085220.CFCAF2474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/09 10:52:20 Modified files: cm3/scripts/python/: Tag: release_branch_cm3_5_8 pylib.py Log message: support for Visual Studio 2010 From jkrell at elego.de Fri Jul 9 13:58:39 2010 From: jkrell at elego.de (Jay Krell) Date: Fri, 9 Jul 2010 13:58:39 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100709115841.8F54B2474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/09 13:58:38 Modified files: cm3/m3-sys/m3front/src/misc/: Scanner.m3 Log message: go back a version, to 1.11; 1.12 causes major problems, presumably it confuses 'word' and 'Word' or something From hosking at elego.de Fri Jul 9 17:09:49 2010 From: hosking at elego.de (Antony Hosking) Date: Fri, 9 Jul 2010 17:09:49 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100709150949.B91DA2474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: hosking at birch. 10/07/09 17:09:49 Modified files: cm3/m3-sys/m3front/src/misc/: Scanner.m3 Log message: No need for extra variable. From jkrell at elego.de Sat Jul 10 13:36:41 2010 From: jkrell at elego.de (Jay Krell) Date: Sat, 10 Jul 2010 13:36:41 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100710113641.697742474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/10 13:36:41 Modified files: cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c Log message: DECL_NONLOCAL in gcc 4.5 to try to mimic x_nonlocal_goto_handler_labels causes harm, detailed in the comments in the code here (needs further investigation) From jkrell at elego.de Sat Jul 10 14:27:27 2010 From: jkrell at elego.de (Jay Krell) Date: Sat, 10 Jul 2010 14:27:27 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100710122727.55F712474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/10 14:27:27 Modified files: cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c Log message: use POINTER_PLUS with gcc 4.3 same as with gcc 4.5 volatilize any function that calls RTHooks__PushEFrame Therefore enabling "pre" optimization (partial redundancy elimination?) This would probably be cleaner in a few other ways: investigate further why gcc doesn't like the trees we produce for this case have a direct call in the middle end: volatilize_current_function understand (at least) the two variants of try/finally don't volatilize all variables In my one test case though, the finally block doesn't access anything, so only volatilizing what is needed would set us back to really having to understand. And, really, volatile even of certain variables is overkill. You just want be sure they are "homed" prior to function calls that can throw, not at every single use and not before function calls that can't throw. From jay.krell at cornell.edu Sat Jul 10 14:29:43 2010 From: jay.krell at cornell.edu (Jay K) Date: Sat, 10 Jul 2010 12:29:43 +0000 Subject: [M3commit] CVS Update: cm3 In-Reply-To: <20100710122727.55F712474003@birch.elegosoft.com> References: <20100710122727.55F712474003@birch.elegosoft.com> Message-ID: not great but maybe ok for the time being, for a while.. ---------------------------------------- > Date: Sat, 10 Jul 2010 14:27: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/07/10 14:27:27 > > Modified files: > cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c > > Log message: > use POINTER_PLUS with gcc 4.3 same as with gcc 4.5 > volatilize any function that calls RTHooks__PushEFrame > Therefore enabling "pre" optimization (partial redundancy elimination?) > This would probably be cleaner in a few other ways: > investigate further why gcc doesn't like the trees we produce for this case > have a direct call in the middle end: volatilize_current_function > understand (at least) the two variants of try/finally > don't volatilize all variables > In my one test case though, the finally block doesn't > access anything, so only volatilizing what is needed > would set us back to really having to understand. > > And, really, volatile even of certain variables is overkill. > You just want be sure they are "homed" prior to function > calls that can throw, not at every single use and not > before function calls that can't throw. > -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: pushframe.txt URL: From jkrell at elego.de Sat Jul 10 14:31:54 2010 From: jkrell at elego.de (Jay Krell) Date: Sat, 10 Jul 2010 14:31:54 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100710123154.8F9D8CC37F@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/10 14:31:54 Modified files: cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c Log message: don't check for pushframe if we are making all load/store volatile From jay.krell at cornell.edu Sat Jul 10 14:35:11 2010 From: jay.krell at cornell.edu (Jay K) Date: Sat, 10 Jul 2010 12:35:11 +0000 Subject: [M3commit] CVS Update: cm3 In-Reply-To: References: <20100710122727.55F712474003@birch.elegosoft.com>, Message-ID: Drat, this doesn't let it work across the whole tree.. new source -> compiling m3totex.m3 ../src/m3totex.m3: In function 'm3totex__Undisplay': ../src/m3totex.m3:210: internal compiler error: in remove_phi_node, at tree-phinodes.c:465 Please submit a full bug report, with preprocessed source if appropriate. See for instructions. ? m3_backend => 4 m3cc (aka cm3cg) failed compiling: m3totex.mc compilation failed => not building program "m3totex" Fatal Error: package build failed ?*** execution of [, ] failed *** (normally this would SIGSEGV but I put assertions in) ---------------------------------------- > From: jay.krell at cornell.edu > To: jkrell at elego.de; m3commit at elegosoft.com > Date: Sat, 10 Jul 2010 12:29:43 +0000 > Subject: Re: [M3commit] CVS Update: cm3 > > > not great but maybe ok for the time being, for a while.. > > ---------------------------------------- > > Date: Sat, 10 Jul 2010 14:27: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/07/10 14:27:27 > > > > Modified files: > > cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c > > > > Log message: > > use POINTER_PLUS with gcc 4.3 same as with gcc 4.5 > > volatilize any function that calls RTHooks__PushEFrame > > Therefore enabling "pre" optimization (partial redundancy elimination?) > > This would probably be cleaner in a few other ways: > > investigate further why gcc doesn't like the trees we produce for this case > > have a direct call in the middle end: volatilize_current_function > > understand (at least) the two variants of try/finally > > don't volatilize all variables > > In my one test case though, the finally block doesn't > > access anything, so only volatilizing what is needed > > would set us back to really having to understand. > > > > And, really, volatile even of certain variables is overkill. > > You just want be sure they are "homed" prior to function > > calls that can throw, not at every single use and not > > before function calls that can't throw. > > > From jkrell at elego.de Sat Jul 10 15:37:59 2010 From: jkrell at elego.de (Jay Krell) Date: Sat, 10 Jul 2010 15:37:59 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100710133759.40A32CC37E@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/10 15:37:59 Modified files: cm3/m3-sys/m3cc/gcc/gcc/m3cg/: m3gty43.h m3gty45.h parse.c Log message: Try something similar/different: in functions that call pushframe, turn off flag_tree_pre That is: save flag_tree_pre away in begin_procedure if we see call pushframe, set flag_tree_pre = 0 restore flag_tree_pre in end_procedure This depends on that curently we compile unit at a time.. which is the "last" optimization to deal with..except this dependency makes "pre" being sometimes enabled dependant on it...so..ultimately..this "fix" probably can't stand. If unit at a time can be fixed soon/easily, re-disable pre and investigate further the problem with try/finally.. From jay.krell at cornell.edu Sat Jul 10 15:38:59 2010 From: jay.krell at cornell.edu (Jay K) Date: Sat, 10 Jul 2010 13:38:59 +0000 Subject: [M3commit] CVS Update: cm3 In-Reply-To: <20100710133759.40A32CC37E@birch.elegosoft.com> References: <20100710133759.40A32CC37E@birch.elegosoft.com> Message-ID: really not great...but it'll take a much deeper investigation to fix this... ---------------------------------------- > Date: Sat, 10 Jul 2010 15:37: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/07/10 15:37:59 > > Modified files: > cm3/m3-sys/m3cc/gcc/gcc/m3cg/: m3gty43.h m3gty45.h parse.c > > Log message: > Try something similar/different: > in functions that call pushframe, turn off flag_tree_pre > > That is: > save flag_tree_pre away in begin_procedure > if we see call pushframe, set flag_tree_pre = 0 > restore flag_tree_pre in end_procedure > > This depends on that curently we compile unit at a time.. > which is the "last" optimization to deal with..except > this dependency makes "pre" being sometimes enabled > dependant on it...so..ultimately..this "fix" probably > can't stand. > > If unit at a time can be fixed soon/easily, re-disable > pre and investigate further the problem with try/finally.. > -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: pushframe2.txt URL: From jkrell at elego.de Sun Jul 11 08:36:41 2010 From: jkrell at elego.de (Jay Krell) Date: Sun, 11 Jul 2010 8:36:41 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100711063641.492EF2474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/11 08:36:41 Added files: cm3/m3-sys/m3tests/src/p2/p242/: Main.m3 m3makefile Log message: add test case reduced from m3totex that crashes in gcc backend if 'pre' is enabled (unless maybe if everything is volatile) From jay.krell at cornell.edu Sun Jul 11 08:45:49 2010 From: jay.krell at cornell.edu (Jay K) Date: Sun, 11 Jul 2010 06:45:49 +0000 Subject: [M3commit] CVS Update: cm3 In-Reply-To: <20100711063641.492EF2474003@birch.elegosoft.com> References: <20100711063641.492EF2474003@birch.elegosoft.com> Message-ID: Strange cvs behavior. m3tests/src/m3makefile did get edited too. ?- Jay ---------------------------------------- > Date: Sun, 11 Jul 2010 08:36: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/07/11 08:36:41 > > Added files: > cm3/m3-sys/m3tests/src/p2/p242/: Main.m3 m3makefile > > Log message: > add test case reduced from m3totex that crashes in gcc > backend if 'pre' is enabled (unless maybe if everything > is volatile) > From jkrell at elego.de Sun Jul 11 08:55:30 2010 From: jkrell at elego.de (Jay Krell) Date: Sun, 11 Jul 2010 8:55:30 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100711065530.B35ECCC382@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/11 08:55:30 Modified files: cm3/m3-sys/m3tests/src/: m3makefile Added files: cm3/m3-sys/m3tests/src/p2/p243/: Main.m3 m3makefile Log message: add test case that fails to compile when gcc backend compiles "unit at a time" because nested functions aren't preserved From jkrell at elego.de Sun Jul 11 09:37:21 2010 From: jkrell at elego.de (Jay Krell) Date: Sun, 11 Jul 2010 9:37:21 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100711073722.3335C2474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/11 09:37:21 Modified files: cm3/m3-sys/m3cc/gcc/gcc/m3cg/: m3gty43.h m3gty45.h parse.c Log message: more tracing: quoted_string just leave 'pre' off all the time, for now What i had was sort of better, pre on sometimes, but also kind of yucky. From jkrell at elego.de Sun Jul 11 10:13:08 2010 From: jkrell at elego.de (Jay Krell) Date: Sun, 11 Jul 2010 10:13:08 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100711081308.F189CCC389@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/11 10:13:08 Modified files: cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c Log message: mark nested functions as "public", so that unit at a time doesn't remove them Still, "public" isn't so bad, they are still "hidden" on platforms that support that. (That is, they are accessible from within the .so but not exported to outside it.) From jkrell at elego.de Sun Jul 11 10:15:24 2010 From: jkrell at elego.de (Jay Krell) Date: Sun, 11 Jul 2010 10:15:24 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100711081524.E688A2474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/11 10:15:24 Modified files: cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c Log message: edit the comment about making all functions 'public' From jay.krell at cornell.edu Sun Jul 11 10:31:47 2010 From: jay.krell at cornell.edu (Jay K) Date: Sun, 11 Jul 2010 08:31:47 +0000 Subject: [M3commit] CVS Update: cm3 In-Reply-To: <20100711073722.3335C2474003@birch.elegosoft.com> References: <20100711073722.3335C2474003@birch.elegosoft.com> Message-ID: In 4.5 (or 4.4) we can selectively deoptimize functions using underlying infrastructure. ?- Jay ---------------------------------------- > Date: Sun, 11 Jul 2010 09:37:21 +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/07/11 09:37:21 > > Modified files: > cm3/m3-sys/m3cc/gcc/gcc/m3cg/: m3gty43.h m3gty45.h parse.c > > Log message: > more tracing: quoted_string > just leave 'pre' off all the time, for now > What i had was sort of better, pre on sometimes, but also > kind of yucky. > From jkrell at elego.de Sun Jul 11 10:53:01 2010 From: jkrell at elego.de (Jay Krell) Date: Sun, 11 Jul 2010 10:53:01 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100711085301.8CE27CC389@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/11 10:53:01 Modified files: cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c Log message: TREE_PUBLIC (p) = ((lev == 0) || flag_unit_at_a_time); instead of just 1 From jkrell at elego.de Sun Jul 11 11:05:50 2010 From: jkrell at elego.de (Jay Krell) Date: Sun, 11 Jul 2010 11:05:50 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100711090550.6E1B92474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/11 11:05:50 Modified files: cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c Log message: in the gcc 4.2 (and maybe 4.5) don't bother with the add if adding zero From jkrell at elego.de Sun Jul 11 11:19:09 2010 From: jkrell at elego.de (Jay Krell) Date: Sun, 11 Jul 2010 11:19:09 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100711091909.312D4CC37F@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/11 11:19:09 Modified files: cm3/m3-sys/m3tests/src/p2/p240/expected/AMD64_DARWIN/: A.ms divmod_pow2.ms Log message: update (esp. with removal of div/mod functions, the the result at least when not optimized is much larger) From jkrell at elego.de Sun Jul 11 11:23:29 2010 From: jkrell at elego.de (Jay Krell) Date: Sun, 11 Jul 2010 11:23:29 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100711092329.C25BF2474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/11 11:23:29 Modified files: cm3/m3-sys/m3tests/src/p2/p240/: m3makefile Log message: whitespace From jkrell at elego.de Sun Jul 11 11:50:59 2010 From: jkrell at elego.de (Jay Krell) Date: Sun, 11 Jul 2010 11:50:59 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100711095100.276A22474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/11 11:50:59 Modified files: cm3/m3-sys/m3tests/src/p2/p240/: m3makefile cm3/m3-sys/m3tests/src/p2/p240/expected/AMD64_DARWIN/: bitfield.ms extract.ms insert.ms Added files: cm3/m3-sys/m3tests/src/p2/p240/expected/AMD64_DARWIN/: And.ms Divide.ms EQ.ms GE.ms GT.ms LE.ms LT.ms LeftRotate.ms LeftShift.ms Minus.ms Mod.ms NE.ms Not.ms Or.ms Plus.ms RightRotate.ms RightShift.ms Rotate.ms Shift.ms Times.ms Xor.ms div_pow2.ms extract_constant_both.ms extract_constant_count.ms extract_constant_offset.ms insert_constant_both.ms insert_constant_count.ms insert_constant_offset.ms mod_pow2.ms return_constant.ms return_parameter.ms return_parameter_convert.ms return_variable.ms Log message: split up into more files (too many?) From jkrell at elego.de Sun Jul 11 12:51:00 2010 From: jkrell at elego.de (Jay Krell) Date: Sun, 11 Jul 2010 12:51:00 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100711105100.D1AB9CC37F@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/11 12:51:00 Modified files: cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c Log message: disable 'fre' for gcc 4.5, it crashes From jkrell at elego.de Sun Jul 11 12:52:59 2010 From: jkrell at elego.de (Jay Krell) Date: Sun, 11 Jul 2010 12:52:59 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100711105300.09B6D2474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/11 12:52:59 Modified files: cm3/m3-sys/m3tests/src/: m3makefile Added files: cm3/m3-sys/m3tests/src/p2/p244/: Main.m3 m3makefile Log message: add a case that crashes gcc 4.5 backend if 'fre' enabled (this reduced from something in p240 I was looking at; p240 always disables optimizations, until such time as we expand the test framework to iterate through various optimization options..) From jkrell at elego.de Sun Jul 11 12:55:21 2010 From: jkrell at elego.de (Jay Krell) Date: Sun, 11 Jul 2010 12:55:21 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100711105521.ECB9D2474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/11 12:55:21 Modified files: cm3/m3-sys/m3tests/src/p2/p244/: m3makefile Log message: make sure optimization is enabled From jkrell at elego.de Sun Jul 11 13:06:03 2010 From: jkrell at elego.de (Jay Krell) Date: Sun, 11 Jul 2010 13:06:03 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100711110603.B28A12474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/11 13:06:03 Modified files: cm3/m3-sys/m3tests/src/p2/p240/expected/AMD64_DARWIN/: And.ms Divide.ms EQ.ms GE.ms GT.ms LE.ms LT.ms LeftRotate.ms LeftShift.ms Minus.ms Mod.ms NE.ms Not.ms Or.ms Plus.ms RightRotate.ms RightShift.ms Rotate.ms Shift.ms Times.ms Xor.ms bitfield.ms div_pow2.ms extract.ms extract_constant_both.ms extract_constant_count.ms extract_constant_offset.ms insert.ms insert_constant_both.ms insert_constant_count.ms insert_constant_offset.ms mod_pow2.ms return_constant.ms return_parameter.ms return_parameter_convert.ms return_variable.ms Log message: update: I don't know why, but maybe I commited out of date versions before? Here the main change seems just reordering functions. From jkrell at elego.de Sun Jul 11 13:19:35 2010 From: jkrell at elego.de (Jay Krell) Date: Sun, 11 Jul 2010 13:19:35 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100711111935.6C3B8CC37F@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/11 13:19:35 Modified files: cm3/m3-sys/m3cc/gcc-4.5/gcc/: gimplify.c Log message: put the #if 1 back to #ifdef ENABLE_TYPES_CHECKING, though this area still needs work From jkrell at elego.de Sun Jul 11 13:58:02 2010 From: jkrell at elego.de (Jay Krell) Date: Sun, 11 Jul 2010 13:58:02 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100711115802.927FE2474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/11 13:58:02 Modified files: cm3/m3-sys/m3tests/src/p2/p244/: Main.m3 Log message: fix comment: the original problem I was looking at was due to functions being out of order and I was comparin them wrong, but this test case remains useful as a crasher for gcc 4.5 'fre' From jkrell at elego.de Sun Jul 11 14:39:59 2010 From: jkrell at elego.de (Jay Krell) Date: Sun, 11 Jul 2010 14:39:59 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100711123959.955122474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/11 14:39:59 Modified files: cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c Log message: gcc 4.5 -O1 and -O2 seem ok but some of the -O3 passes fail: flag_predictive_commoning flag_ipa_cp_clone flag_inline_functions is not optimizing for size Failures generally seen compiling m3-libs/sysutils/System.m3. As well 'pre' which has problems in 4.3 also has problems in 4.5, problems seen compiling m3front. And 'fre' already disabled (see test p244). From jkrell at elego.de Sun Jul 11 15:14:53 2010 From: jkrell at elego.de (Jay Krell) Date: Sun, 11 Jul 2010 15:14:53 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100711131453.72F102474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/11 15:14:53 Modified files: cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c Log message: fix the -Wc++-compat warnings/errors you see if using newer gcc class => clas int => enum and the "poison" thing, not sure why it appears on some machines and not others, could again be different gcc version From jkrell at elego.de Mon Jul 12 00:32:00 2010 From: jkrell at elego.de (Jay Krell) Date: Mon, 12 Jul 2010 0:32:00 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100711223201.000432474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/12 00:32:00 Modified files: cm3/m3-sys/m3cc/gcc-4.5/gcc/: targhooks.c Log message: allow NULL fndecl in default_static_chain (I already did this in the x86-specific hook, need to check for others, this was SIGSEVing on SOLgnu) From jkrell at elego.de Mon Jul 12 00:34:59 2010 From: jkrell at elego.de (Jay Krell) Date: Mon, 12 Jul 2010 0:34:59 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100711223459.F01262474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/12 00:34:59 Modified files: cm3/m3-sys/m3cc/gcc-4.5/gcc/config/moxie/: moxie.c Log message: allow NULL fndecl in moxie_static_chain From jkrell at elego.de Mon Jul 12 00:50:34 2010 From: jkrell at elego.de (Jay Krell) Date: Mon, 12 Jul 2010 0:50:34 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100711225035.15E2E2474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/12 00:50:34 Modified files: cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c Log message: gcc 4.5: mark barrier labels rtx with LABEL_REF_NONLOCAL_P, does it help/matter? From jkrell at elego.de Mon Jul 12 01:39:14 2010 From: jkrell at elego.de (Jay Krell) Date: Mon, 12 Jul 2010 1:39:14 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100711233914.8CBA02474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/12 01:39:14 Modified files: cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c Log message: hm LABEL_REF_NONLOCAL_P I thought had helped maybe on I386_LINUX and SOLgnu but it clearly hurts on AMD64_DARWIN From jkrell at elego.de Mon Jul 12 04:25:25 2010 From: jkrell at elego.de (Jay Krell) Date: Mon, 12 Jul 2010 4:25:25 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100712022526.767D12474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/12 04:25:25 Modified files: cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c Log message: gcc 4.5: turn off all inlining: m3-sys/m3cc/AMD64_DARWIN-SOLgnu/cm3cg -quiet -O3 m3core/SOLgnu/Poly.mc fingerprint/Poly.m3: In function 'Poly__FromBytes': fingerprint/Poly.m3:379:0: internal compiler error: in referenced_var_lookup, at tree-dfa.c:519 From jay.krell at cornell.edu Mon Jul 12 04:40:37 2010 From: jay.krell at cornell.edu (Jay K) Date: Mon, 12 Jul 2010 02:40:37 +0000 Subject: [M3commit] CVS Update: cm3 In-Reply-To: <20100712022526.767D12474003@birch.elegosoft.com> References: <20100712022526.767D12474003@birch.elegosoft.com> Message-ID: This is unfortunate. ---------------------------------------- > Date: Mon, 12 Jul 2010 04:25:25 +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/07/12 04:25:25 > > Modified files: > cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c > > Log message: > gcc 4.5: turn off all inlining: > m3-sys/m3cc/AMD64_DARWIN-SOLgnu/cm3cg -quiet -O3 m3core/SOLgnu/Poly.mc > fingerprint/Poly.m3: In function 'Poly__FromBytes': > fingerprint/Poly.m3:379:0: internal compiler error: > in referenced_var_lookup, at tree-dfa.c:519 > From jkrell at elego.de Mon Jul 12 11:08:00 2010 From: jkrell at elego.de (Jay Krell) Date: Mon, 12 Jul 2010 11:08:00 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100712090800.443892474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/12 11:08:00 Modified files: cm3/m3-sys/m3tests/src/: m3makefile Added files: cm3/m3-sys/m3tests/src/p2/p245/: Main.m3 m3makefile Log message: test case reduced from m3core/TextConv.m3 that gives: internal compiler error: in estimate_move_cost, at tree-inline.c:3016 when gcc 4.5 does inlining The assertion is that the type isn't void. The problem seems related to the set of char, but we'll see. From jkrell at elego.de Mon Jul 12 11:14:40 2010 From: jkrell at elego.de (Jay Krell) Date: Mon, 12 Jul 2010 11:14:40 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100712091440.4BFA92474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/12 11:14:40 Modified files: cm3/m3-sys/m3tests/src/p2/p245/: Main.m3 Log message: slightly different/smaller From jkrell at elego.de Mon Jul 12 11:46:41 2010 From: jkrell at elego.de (Jay Krell) Date: Mon, 12 Jul 2010 11:46:41 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100712094641.5886E2474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/12 11:46:41 Modified files: cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c Log message: represent sets as a pointer to a word, not an untyped pointer This seems fixes inlining on AMD64_DARWIN (more testing being done, including of SOLgnu). This was my fault: the old code to call functions didn't have to worry about the types of sets, because it didn't dereference them.. From jkrell at elego.de Mon Jul 12 12:14:13 2010 From: jkrell at elego.de (Jay Krell) Date: Mon, 12 Jul 2010 12:14:13 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100712101413.8FD042474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/12 12:14:13 Modified files: cm3/m3-sys/m3tests/src/: m3makefile Added files: cm3/m3-sys/m3tests/src/p2/p246/: Main.m3 m3makefile Log message: gcc 4.5 assertion failure inlining in Poly.m3 for SOLgnu From jkrell at elego.de Mon Jul 12 13:14:02 2010 From: jkrell at elego.de (Jay Krell) Date: Mon, 12 Jul 2010 13:14:02 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100712111402.DA96E2474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/12 13:14:02 Modified files: cm3/m3-sys/cminstall/src/config-no-install/: I386.common Log message: don't mess with preferred-stack-boundary, it makes me nervouse From jkrell at elego.de Mon Jul 12 13:16:13 2010 From: jkrell at elego.de (Jay Krell) Date: Mon, 12 Jul 2010 13:16:13 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100712111613.7C0802474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/12 13:16:13 Modified files: cm3/m3-sys/cminstall/src/config-no-install/: cm3cfg.common Log message: move comment that seemed misplaced From jkrell at elego.de Mon Jul 12 13:17:33 2010 From: jkrell at elego.de (Jay Krell) Date: Mon, 12 Jul 2010 13:17:33 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100712111733.B9E2B2474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/12 13:17:33 Modified files: cm3/m3-sys/cminstall/src/config-no-install/: VMS.common Log message: [] to [ ] so the characters don't run together, depending on font From jkrell at elego.de Mon Jul 12 13:21:45 2010 From: jkrell at elego.de (Jay Krell) Date: Mon, 12 Jul 2010 13:21:45 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100712112145.C54702474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/12 13:21:45 Modified files: cm3/m3-sys/cminstall/src/config-no-install/: PPC_LINUX Log message: fix typo in comment From jkrell at elego.de Mon Jul 12 13:28:00 2010 From: jkrell at elego.de (Jay Krell) Date: Mon, 12 Jul 2010 13:28:00 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100712112800.C1E5C2474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/12 13:28:00 Modified files: cm3/m3-sys/cminstall/src/config-no-install/: Interix.common Log message: no change, just commit so I take ownership on CVS server so I can clear the execute attribute, which is often present on files I added from Windows From jkrell at elego.de Mon Jul 12 13:37:49 2010 From: jkrell at elego.de (Jay Krell) Date: Mon, 12 Jul 2010 13:37:49 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100712113749.80AD62474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/12 13:37:49 Modified files: cm3/m3-sys/m3tests/src/: m3makefile cm3/m3-sys/m3tests/src/p2/p246/: Main.m3 Log message: update comments to indicate it also occurs on I386_DARWIN which is fortunate because at least I have a fractionally decent editor there (vs. zero everywhere else, except NT) and my SOLgnu machine is very slow probably all 32bit platforms? There is another problem though that might be SOLgnu specific, not yet reduced to a small case. From jkrell at elego.de Mon Jul 12 14:23:53 2010 From: jkrell at elego.de (Jay Krell) Date: Mon, 12 Jul 2010 14:23:53 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100712122353.4C06C2474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/12 14:23:53 Modified files: cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c Log message: update add_stmt function in minor way to match gcc 4.3/4.5 function of same name in c-decl.c (much of the Modula-3 backend is clearly a clone of the C frontend) From wagner at elego.de Mon Jul 12 21:35:06 2010 From: wagner at elego.de (Olaf Wagner) Date: Mon, 12 Jul 2010 21:35:06 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100712193506.C5BCF2474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: wagner at birch. 10/07/12 21:35:06 Modified files: cm3/www/releng/: Tag: release_branch_cm3_5_8 index.html update-releng-index.sh Log message: final release updates From wagner at elego.de Mon Jul 12 21:38:21 2010 From: wagner at elego.de (Olaf Wagner) Date: Mon, 12 Jul 2010 21:38:21 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100712193821.4740C2474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: wagner at birch. 10/07/12 21:38:21 Modified files: cm3/www/releng/: Tag: release_branch_cm3_5_8 update-releng-index.sh Added files: cm3/www/releng/: Tag: release_branch_cm3_5_8 relnotes-5.8.6.html Log message: final release updates From wagner at elego.de Mon Jul 12 21:42:41 2010 From: wagner at elego.de (Olaf Wagner) Date: Mon, 12 Jul 2010 21:42:41 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100712194241.620C32474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: wagner at birch. 10/07/12 21:42:41 Modified files: cm3/www/releng/: Tag: release_branch_cm3_5_8 update-releng-index.sh Log message: final release updates From wagner at elego.de Mon Jul 12 21:43:48 2010 From: wagner at elego.de (Olaf Wagner) Date: Mon, 12 Jul 2010 21:43:48 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100712194348.E5C672474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: wagner at birch. 10/07/12 21:43:48 Modified files: cm3/www/: Tag: release_branch_cm3_5_8 download.html news.html Log message: final release updates From jkrell at elego.de Tue Jul 13 14:34:28 2010 From: jkrell at elego.de (Jay Krell) Date: Tue, 13 Jul 2010 14:34:28 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100713123428.678CF2474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/13 14:34:28 Modified files: cm3/m3-sys/m3cc/gcc/: configure.ac Log message: experimental: remove freebsd/gmp special case; this is deliberately two separate commits to perhaps manage the timestamps From jkrell at elego.de Tue Jul 13 14:34:44 2010 From: jkrell at elego.de (Jay Krell) Date: Tue, 13 Jul 2010 14:34:44 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100713123444.166542474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/13 14:34:44 Modified files: cm3/m3-sys/m3cc/gcc/: configure Log message: experimental: remove freebsd/gmp special case; this is deliberately two separate commits to perhaps manage the timestamps From jkrell at elego.de Tue Jul 13 15:14:33 2010 From: jkrell at elego.de (Jay Krell) Date: Tue, 13 Jul 2010 15:14:33 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100713131433.579482474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/13 15:14:33 Modified files: cm3/m3-libs/m3core/src/runtime/common/: RTProcessC.c Log message: no pthread_atfork on FreeBSD <= 4 From jkrell at elego.de Tue Jul 13 15:18:23 2010 From: jkrell at elego.de (Jay Krell) Date: Tue, 13 Jul 2010 15:18:23 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100713131825.2D9EA2474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/13 15:18:23 Modified files: cm3/m3-libs/m3core/src/thread/POSIX/: ThreadPosixC.c Log message: try sigaltstack instead of make/get/set/swapcontext on FreeBSD <= 4 From jkrell at elego.de Tue Jul 13 15:22:28 2010 From: jkrell at elego.de (Jay Krell) Date: Tue, 13 Jul 2010 15:22:28 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100713132228.137FC2474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/13 15:22:28 Modified files: cm3/m3-libs/m3core/src/runtime/common/: RTProcessC.c Log message: parens and word-wrap From jkrell at elego.de Tue Jul 13 15:30:13 2010 From: jkrell at elego.de (Jay Krell) Date: Tue, 13 Jul 2010 15:30:13 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100713133013.6A2F6CC37E@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/13 15:30:13 Modified files: cm3/m3-libs/m3core/src/runtime/common/: RTProcessC.c Log message: pthread_atfork added in FreeBSD 5 (this would be a good use of autoconf) From jkrell at elego.de Tue Jul 13 15:30:55 2010 From: jkrell at elego.de (Jay Krell) Date: Tue, 13 Jul 2010 15:30:55 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100713133055.13D592474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/13 15:30:55 Modified files: cm3/m3-libs/m3core/src/runtime/common/: RTProcessC.c Log message: really no diff here, but I meant: pthread_atfork added in FreeBSD 6 (this would be a good use of autoconf) From jkrell at elego.de Wed Jul 14 10:03:05 2010 From: jkrell at elego.de (Jay Krell) Date: Wed, 14 Jul 2010 10:03:05 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100714080306.136922474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/14 10:03:05 Modified files: cm3/m3-sys/m3cc/gcc-4.5/: configure.ac Log message: remove freebsd/gmp special case here toof From jkrell at elego.de Wed Jul 14 10:03:22 2010 From: jkrell at elego.de (Jay Krell) Date: Wed, 14 Jul 2010 10:03:22 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100714080322.3EEC02474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/14 10:03:22 Modified files: cm3/m3-sys/m3cc/gcc-4.5/: configure Log message: remove freebsd/gmp special case here too From jkrell at elego.de Wed Jul 14 10:06:01 2010 From: jkrell at elego.de (Jay Krell) Date: Wed, 14 Jul 2010 10:06:01 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100714080601.642F4CC110@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/14 10:06:01 Modified files: cm3/m3-sys/m3cc/gcc-apple/: configure.in Log message: remove freebsd/gmp special case here too From jkrell at elego.de Wed Jul 14 10:06:25 2010 From: jkrell at elego.de (Jay Krell) Date: Wed, 14 Jul 2010 10:06:25 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100714080625.D655D2474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/14 10:06:25 Modified files: cm3/m3-sys/m3cc/gcc-apple/: configure Log message: remove freebsd/gmp special case here too From jkrell at elego.de Wed Jul 14 10:44:35 2010 From: jkrell at elego.de (Jay Krell) Date: Wed, 14 Jul 2010 10:44:35 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100714084435.3B3272474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/14 10:44:35 Modified files: cm3/m3-libs/m3core/src/unix/Common/: Uin.c Log message: fixes for FreeBSD 4: need to include ntohl might be macros, so can't use M3WRAP1 From jkrell at elego.de Wed Jul 14 10:53:29 2010 From: jkrell at elego.de (Jay Krell) Date: Wed, 14 Jul 2010 10:53:29 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100714085329.8BBDECC110@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/14 10:53:29 Modified files: cm3/scripts/python/: pylib.py cm3/m3-sys/cminstall/src/config-no-install/: FreeBSD.common Log message: somewhat experimental: -pthread instead of -lpthread Really I'd like to try this across the board, but just FreeBSD for now. -lpthread failed on FreeBSD 4 where -pthread worked, hopefully -pthread works on all future FreeBSD also. (probably, at least, it is a gcc thing, and usable on all Linux, *BSD) From jkrell at elego.de Wed Jul 14 11:07:35 2010 From: jkrell at elego.de (Jay Krell) Date: Wed, 14 Jul 2010 11:07:35 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100714090735.7BF902474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/14 11:07:35 Modified files: cm3/m3-sys/cminstall/src/config-no-install/: FreeBSD.common Linux.common OpenBSD.common NetBSD.common Log message: -lpthread => -pthread tested quickly minimally on Linux, OpenBSD, not tested on NetBSD FreeBSD.common is just a comment change The LIBC line in Unix.common is probably dead now..could be changed to -pthread. From jkrell at elego.de Wed Jul 14 11:37:25 2010 From: jkrell at elego.de (Jay Krell) Date: Wed, 14 Jul 2010 11:37:25 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100714093726.1AA0F2474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/14 11:37:25 Modified files: cm3/m3-sys/cminstall/src/config-no-install/: FreeBSD.common HPUX.common Linux.common NetBSD.common OpenBSD.common Solaris.common Unix.common VMS.common Log message: some -lpthread, -pthread, SYSTEM_LIBS cleanup Mainly just to reduce some duplication. This area needs more thought, design, work, testing, but this is probably ok. Some of the flaws include: - Unix.common isn't really common to 'Unix', but Linux and *BSD, at least regards to SYSTEM_LIBS - There remains some need for user-editing/configuration/autoconf/install. - Perhaps by moving some of the "less meant to be configured" parts into Modula-3 code. From jkrell at elego.de Wed Jul 14 11:45:58 2010 From: jkrell at elego.de (Jay Krell) Date: Wed, 14 Jul 2010 11:45:58 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100714094559.152572474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/14 11:45:58 Modified files: cm3/m3-sys/cminstall/src/config-no-install/: Darwin.common Log message: shorten line that was over 240 characters long From jkrell at elego.de Wed Jul 14 11:59:29 2010 From: jkrell at elego.de (Jay Krell) Date: Wed, 14 Jul 2010 11:59:29 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100714095929.C5E8FCC110@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/14 11:59:29 Modified files: cm3/m3-libs/m3core/src/thread/POSIX/: ThreadPosixC.c Log message: allow for 2GB page size perhaps and > 2GB stack, on 64 bit, user threads From jkrell at elego.de Wed Jul 14 12:03:28 2010 From: jkrell at elego.de (Jay Krell) Date: Wed, 14 Jul 2010 12:03:28 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100714100328.451C02474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/14 12:03:28 Modified files: cm3/m3-libs/m3core/src/thread/POSIX/: ThreadPosixC.c Log message: stack size in words is CARDINAL, not int: make it match the Modula-3 declaration, and thereby allow even larger stacks on 64bit, user threads From jkrell at elego.de Wed Jul 14 12:05:36 2010 From: jkrell at elego.de (Jay Krell) Date: Wed, 14 Jul 2010 12:05:36 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100714100536.5195F2474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/14 12:05:36 Modified files: cm3/m3-libs/m3core/src/thread/POSIX/: ThreadPosixC.c Log message: let's use INTEGER instead of WORD_T, the point wasn't so much to reclaim one bit, but 30 or so From jkrell at elego.de Wed Jul 14 12:06:37 2010 From: jkrell at elego.de (Jay Krell) Date: Wed, 14 Jul 2010 12:06:37 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100714100637.DB4B72474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/14 12:06:37 Modified files: cm3/m3-libs/m3core/src/thread/POSIX/: ThreadPosixC.c Log message: partial check for integer overflow, should do better in general ('integer overflow is the new buffer overflow?') From jkrell at elego.de Wed Jul 14 12:43:21 2010 From: jkrell at elego.de (Jay Krell) Date: Wed, 14 Jul 2010 12:43:21 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100714104321.D45A42474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/14 12:43:21 Modified files: cm3/scripts/python/: pylib.py Log message: some -pthread vs. -lpthread stuff (autoconf??) From jkrell at elego.de Wed Jul 14 12:44:44 2010 From: jkrell at elego.de (Jay Krell) Date: Wed, 14 Jul 2010 12:44:44 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100714104444.E24EC2474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/14 12:44:44 Modified files: cm3/scripts/python/: pylib.py Log message: add a url (or search the web) From jkrell at elego.de Wed Jul 14 12:46:04 2010 From: jkrell at elego.de (Jay Krell) Date: Wed, 14 Jul 2010 12:46:04 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100714104605.090F12474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/14 12:46:04 Modified files: cm3/scripts/python/: pylib.py Log message: better: there is an autoconf macro From jkrell at elego.de Wed Jul 14 13:22:20 2010 From: jkrell at elego.de (Jay Krell) Date: Wed, 14 Jul 2010 13:22:20 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100714112220.20C51CC37E@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/14 13:22:20 Modified files: cm3/m3-libs/libm3/src/: m3makefile Added files: cm3/m3-libs/libm3/src/types/: LongrealType.i3 RealType.i3 m3makefile Log message: restore some source compability for Mika? From jkrell at elego.de Wed Jul 14 14:34:29 2010 From: jkrell at elego.de (Jay Krell) Date: Wed, 14 Jul 2010 14:34:29 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100714123429.8E30FCC37E@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/14 14:34:29 Modified files: cm3/m3-sys/cminstall/src/config-no-install/: FreeBSD.common FreeBSD4 I386_FREEBSD gnuld.common Log message: FreeBSD4: configure compiler/linker to adjust to older versions: older gcc doesn't like -m32, keep -m32 out if -m32 gives expected error Safe to always omit -m32? older gcc misinterprets -Bsymbolic, use -Wl,-Bsymbolic -Bsymbolic inhibits -lc, add -lc only upon expected link error Safe to always add -lc? Safe to omit -Bsymbolic, but it is a nice optimization. On the other hand, this optimization is costing a lot, extra compile/link for every link of a shared library. Alternatives include: gcc -v | fgrep 2.95 uname -r | grep ^4 do nothing, let users (Mika) edit the config files do similar to what we have, but less often From jkrell at elego.de Wed Jul 14 14:43:33 2010 From: jkrell at elego.de (Jay Krell) Date: Wed, 14 Jul 2010 14:43:33 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100714124333.CEAC22474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/14 14:43:33 Modified files: cm3/m3-sys/cminstall/src/config-no-install/: Unix.common Log message: missing call to configure_linker From jkrell at elego.de Wed Jul 14 15:06:50 2010 From: jkrell at elego.de (Jay Krell) Date: Wed, 14 Jul 2010 15:06:50 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100714130650.9AE3F2474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/14 15:06:50 Modified files: cm3/m3-sys/cminstall/src/config-no-install/: I386_FREEBSD cm3cfg.common Log message: switch to a uname-based approach This is probably much faster, but also in particular, I want to make the pthread/userthread choice based on it, and remove -pthread from LIBC based on it, since that causes a bunch of link errors From jkrell at elego.de Wed Jul 14 15:14:55 2010 From: jkrell at elego.de (Jay Krell) Date: Wed, 14 Jul 2010 15:14:55 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100714131455.8A54D2474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/14 15:14:55 Modified files: cm3/m3-libs/m3core/src/: thread.quake cm3/m3-sys/cminstall/src/config-no-install/: I386_FREEBSD Log message: Always use user threads on FreeBSD4 and remove -pthread from SYSTEM_LIBC{"LIBC"} Note that this detection only works for native builds. Cross builds still require manual edits. Perhaps environments should be supported, or I should fix my Python scripts to pass along extra parameters. From jkrell at elego.de Wed Jul 14 15:23:04 2010 From: jkrell at elego.de (Jay Krell) Date: Wed, 14 Jul 2010 15:23:04 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100714132304.DB6512474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/14 15:23:04 Modified files: cm3/m3-libs/m3core/src/: thread.quake Log message: really now, use user threads on native FreeBSD4 builds (really, FreeBSD version 4, not 'FreeBSD4' meaning 'I386_FREEBSD') From jkrell at elego.de Wed Jul 14 15:50:52 2010 From: jkrell at elego.de (Jay Krell) Date: Wed, 14 Jul 2010 15:50:52 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100714135052.1950C2474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/14 15:50:52 Modified files: cm3/m3-sys/cminstall/src/config-no-install/: cm3cfg.common Log message: target equivalence, though this didn't solve the problem I was looking at, I think system_libs{libc} is read before I change it From jkrell at elego.de Wed Jul 14 15:54:37 2010 From: jkrell at elego.de (Jay Krell) Date: Wed, 14 Jul 2010 15:54:37 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100714135437.BD2A12474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/14 15:54:37 Modified files: cm3/m3-sys/cminstall/src/config-no-install/: I386_FREEBSD Log message: I386_FREEBSD From jkrell at elego.de Wed Jul 14 15:55:53 2010 From: jkrell at elego.de (Jay Krell) Date: Wed, 14 Jul 2010 15:55:53 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100714135553.8DF042474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/14 15:55:53 Modified files: cm3/m3-sys/cminstall/src/config-no-install/: I386_FREEBSD Log message: previous comment flubbed: really, don't use -pthread on FreeBSD4 It seems SYSTEM_LIBS{"LIBC"} is read before configure_linker runs, so instead of changing it there, we set it to just -lm much earlier, and then if we wanted -pthread, add it to SYSTEM_LD. From jkrell at elego.de Wed Jul 14 16:16:19 2010 From: jkrell at elego.de (Jay Krell) Date: Wed, 14 Jul 2010 16:16:19 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100714141619.26FE12474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/14 16:16:19 Modified files: cm3/m3-libs/m3core/src/thread/POSIX/: ThreadPosixC.c Log message: oops, the initial thread is already allocated, that's what words == 0 indicates: don't allocate a stack From jkrell at elego.de Wed Jul 14 16:39:40 2010 From: jkrell at elego.de (Jay Krell) Date: Wed, 14 Jul 2010 16:39:40 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100714143940.3C47A2474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/14 16:39:40 Modified files: cm3/scripts/python/: pylib.py Log message: put back -lpthread on Solaris, at least while looking for problem From jkrell at elego.de Wed Jul 14 16:41:29 2010 From: jkrell at elego.de (Jay Krell) Date: Wed, 14 Jul 2010 16:41:29 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100714144129.241162474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/14 16:41:29 Modified files: cm3/m3-sys/cminstall/src/config-no-install/: Solaris.common Log message: put back -lpthread, but I don't think this is the problem From wagner at elego.de Thu Jul 15 08:02:07 2010 From: wagner at elego.de (Olaf Wagner) Date: Thu, 15 Jul 2010 8:02:07 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100715060207.8164D2474006@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: wagner at birch. 10/07/15 08:02:07 Modified files: cm3/www/: Tag: release_branch_cm3_5_8 news.html cm3/www/releng/: Tag: release_branch_cm3_5_8 update-releng-index.sh Log message: more release additions From jkrell at elego.de Thu Jul 15 10:52:38 2010 From: jkrell at elego.de (Jay Krell) Date: Thu, 15 Jul 2010 10:52:38 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100715085238.F0D6C2474006@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/15 10:52:38 Modified files: cm3/m3-sys/cminstall/src/config-no-install/: ALPHA_OSF Log message: add -std to cc From jkrell at elego.de Thu Jul 15 11:20:40 2010 From: jkrell at elego.de (Jay Krell) Date: Thu, 15 Jul 2010 11:20:40 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100715092040.A98552474006@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/15 11:20:40 Modified files: cm3/m3-libs/m3core/src/: m3core.h Log message: whitespace change for old compiler: bash-3.2$ cc -g -c -o CerrnoC.o CerrnoC.c cc: Warning: m3core.h, line 31: # not in column 1 is ignored, skipping to end of line. (ignoretokens) #define M3_DLL_IMPORT --^ From jkrell at elego.de Thu Jul 15 13:03:51 2010 From: jkrell at elego.de (Jay Krell) Date: Thu, 15 Jul 2010 13:03:51 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100715110351.4FFB92474006@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/15 13:03:51 Modified files: cm3/m3-sys/cminstall/src/config-no-install/: cm3cfg.common Log message: add IsHostOSF1v4 to be used shortly, uname -sr based OSF1 v4 has something funny with #define _POSIX_SOURCE and such, I can get it to compile, but I don't know if it breaks v5. OSF1 doesn't have 64bit time_t available native + IsHostOSF1v4 will => #define M3_OSF1_V4 and m3core.h will check that refine uname-based IsHostFreeBSD4 just one uname and one fgrep add InternalTargetCanRunOnHost that's been bugging me lots can run lots, though missing here is if potentially biarch systems are actually biarch From jkrell at elego.de Thu Jul 15 13:06:38 2010 From: jkrell at elego.de (Jay Krell) Date: Thu, 15 Jul 2010 13:06:38 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100715110638.E30DC2474006@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/15 13:06:38 Modified files: cm3/m3-sys/cminstall/src/config-no-install/: cm3cfg.common Log message: I forgot to add IsTargetOSF1v4 function (which is only approx, i.e. works for native builds only) From jkrell at elego.de Thu Jul 15 13:07:09 2010 From: jkrell at elego.de (Jay Krell) Date: Thu, 15 Jul 2010 13:07:09 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100715110709.4F9612474006@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/15 13:07:09 Modified files: cm3/m3-sys/cminstall/src/config-no-install/: cm3cfg.common Log message: comments explaining why knowing precise target doesn't work From jkrell at elego.de Thu Jul 15 13:08:15 2010 From: jkrell at elego.de (Jay Krell) Date: Thu, 15 Jul 2010 13:08:15 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100715110815.D944B2474006@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/15 13:08:15 Modified files: cm3/m3-sys/cminstall/src/config-no-install/: cm3cfg.common Log message: fix copy/pasto (but still worked ok for all normal systems) From jkrell at elego.de Thu Jul 15 13:12:32 2010 From: jkrell at elego.de (Jay Krell) Date: Thu, 15 Jul 2010 13:12:32 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100715111232.6D1E62474006@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/15 13:12:32 Modified files: cm3/m3-sys/cminstall/src/config-no-install/: ALPHA_OSF Log message: add -DM3_OSF1_V4 to SYSTEM_CC if it seems we are targeting OSF/1 v4 (yeah yeah, what about versions 1-3?; get me access to such a machine and I'll deal with it) From jkrell at elego.de Thu Jul 15 13:14:48 2010 From: jkrell at elego.de (Jay Krell) Date: Thu, 15 Jul 2010 13:14:48 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100715111448.EB9BC2474006@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/15 13:14:48 Modified files: cm3/m3-libs/m3core/src/: m3core.h Log message: don't define _XOPEN_SOURCE or _TIME64_T if M3_OSF1_V4 is defined; _XOPEN_SOURCE breaks pthread.h, even though the comments in pthread.h say it shouldn't; I don't remember why I added _XOPEN_SOURCE in the first place, would have to investigate on v5; _TIME64_T is not available on v4; on the hypothetical world where OSF/1 v4 and v5 mattered, we'd want to do builds on each, rename the archives, but not likely invent two different targets, since they match plenty close enough as far as I know (I should double check jmpbuf) From jkrell at elego.de Thu Jul 15 13:26:42 2010 From: jkrell at elego.de (Jay Krell) Date: Thu, 15 Jul 2010 13:26:42 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100715112642.241F32474006@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/15 13:26:42 Modified files: cm3/m3-libs/m3core/src/thread/PTHREAD/: ThreadPThreadC.c Log message: cc: Warning: ThreadPThreadC.c, line 170: In this statement, & before array "jb" is ignored. (addrarray) p(&jb, ((char *)&jb) + sizeof(jb)); ------^ cc: Warning: ThreadPThreadC.c, line 170: In this statement, & before array "jb" is ignored. (addrarray) p(&jb, ((char *)&jb) + sizeof(jb)); --------------------^ jb may or may not be an array, & is necessary, wrap it in struct. From jkrell at elego.de Thu Jul 15 13:29:49 2010 From: jkrell at elego.de (Jay Krell) Date: Thu, 15 Jul 2010 13:29:49 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100715112949.AC3E62474006@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/15 13:29:49 Modified files: cm3/m3-libs/libm3/src/os/POSIX/: FSPosixC.c Log message: cc: Warning: FSPosixC.c, line 35: In this statement, & before array "t" is ignored. (addrarray) ZeroMemory(&t, sizeof(t)); ----^ says the OSF1v4 compiler; in this case the array-ness is plain to see so we can safely portably remove the ampersand, and it makes no difference. Thank you compiler.. From jkrell at elego.de Thu Jul 15 13:35:51 2010 From: jkrell at elego.de (Jay Krell) Date: Thu, 15 Jul 2010 13:35:51 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100715113551.662702474006@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/15 13:35:51 Modified files: cm3/m3-sys/cminstall/src/config-no-install/: ALPHA_OSF Log message: didn't actually need -std here, the problem was #define _XOPEN_SOURCE From jkrell at elego.de Thu Jul 15 13:44:21 2010 From: jkrell at elego.de (Jay Krell) Date: Thu, 15 Jul 2010 13:44:21 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100715114421.AE7962474006@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/15 13:44:21 Modified files: cm3/m3-libs/m3core/src/: m3core.h Log message: define _POSIX_PII_SOCKET on OSF1v4 to get soclen_t typedef (that's probablly why I added #define _XOPEN_SOURCE 500; add some other comments From jkrell at elego.de Thu Jul 15 13:50:13 2010 From: jkrell at elego.de (Jay Krell) Date: Thu, 15 Jul 2010 13:50:13 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100715115013.3E5D92474006@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/15 13:50:13 Modified files: cm3/scripts/python/: pylib.py Log message: -lrt -lm -pthread for ALPHA_OSF, similar to the config file (the config file does more) From jkrell at elego.de Thu Jul 15 13:52:53 2010 From: jkrell at elego.de (Jay Krell) Date: Thu, 15 Jul 2010 13:52:53 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100715115253.33EE9CC110@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/15 13:52:53 Modified files: cm3/scripts/python/: pylib.py Log message: comment about OSF1v4, actually maybe it is worth having I386_FREEBSD4, I386_FREEBSD5 (6?), ALPHA_OSF4, ALPHA_OSF5, that does kind of mimic GNU configuration and would make some stuff work better, including for example, cross building boot packages From jkrell at elego.de Thu Jul 15 15:26:42 2010 From: jkrell at elego.de (Jay Krell) Date: Thu, 15 Jul 2010 15:26:42 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100715132642.F13EBCC37E@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/15 15:26:42 Modified files: cm3/scripts/: sysinfo.sh Added files: cm3/scripts/: boot2.sh Log message: OSF/1 support, and Python failed to build here so far (minor sounding problem) so port to sh From jkrell at elego.de Thu Jul 15 15:28:14 2010 From: jkrell at elego.de (Jay Krell) Date: Thu, 15 Jul 2010 15:28:14 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100715132814.EEAD32474006@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/15 15:28:14 Modified files: cm3/scripts/: sysinfo.sh Log message: I doubt the stars are needed at the ends of plain parameterless uname output (checked at least FreeBSD 4.11) From jkrell at elego.de Thu Jul 15 15:58:47 2010 From: jkrell at elego.de (Jay Krell) Date: Thu, 15 Jul 2010 15:58:47 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100715135847.A1491CC37E@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/15 15:58:47 Modified files: cm3/m3-sys/cminstall/src/config-no-install/: Solaris.common Log message: use fgrep instead of grep From jkrell at elego.de Thu Jul 15 16:45:43 2010 From: jkrell at elego.de (Jay Krell) Date: Thu, 15 Jul 2010 16:45:43 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100715144543.B25742474006@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/15 16:45:43 Modified files: cm3/m3-sys/cminstall/src/config-no-install/: FreeBSD.common I386_FREEBSD Log message: more conservative linking options on FreeBSD4: no -z now no -B symbolic and then no -pthread or -lc: shared libraries I guess aren't supposed to choose libc or libc_r but maybe leave it to the executable? And we don't need libc_r because we are using user threads? This fixes the crash I was seeing. FreeBSD >4 should be unaffected. From jkrell at elego.de Fri Jul 16 14:01:27 2010 From: jkrell at elego.de (Jay Krell) Date: Fri, 16 Jul 2010 14:01:27 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100716120128.1FC822474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/16 14:01:27 Modified files: cm3/scripts/: boot2.sh Log message: move action to start, as the sh scripts require? From jkrell at elego.de Fri Jul 16 14:11:16 2010 From: jkrell at elego.de (Jay Krell) Date: Fri, 16 Jul 2010 14:11:16 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100716121116.B35312474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/16 14:11:16 Added files: cm3/scripts/: install-config.sh Log message: more sh for Tru64 4.0 work, while I wait for Python to compile Note this is different than install-config.py. It is based on make-bin-dist.sh. It makes config for ship, not development. ie. actual copies of the files, not the stub that tries to get back to the source tree. From jkrell at elego.de Fri Jul 16 14:18:36 2010 From: jkrell at elego.de (Jay Krell) Date: Fri, 16 Jul 2010 14:18:36 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100716121836.662752474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/16 14:18:36 Modified files: cm3/m3-sys/cminstall/src/config-no-install/: ALPHA_OSF Log message: delay setting SYSTEM_CC until configure_c_compiler(), so that we can call IsTargetOSF1v4; another solution would be to move the two lines to the end of the file From jkrell at elego.de Fri Jul 16 14:30:00 2010 From: jkrell at elego.de (Jay Krell) Date: Fri, 16 Jul 2010 14:30:00 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100716123000.E22572474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/16 14:30:00 Modified files: cm3/m3-sys/m3cc/src/: platforms.quake Log message: let's trye alpha-dec-osf instead of alpha-dec-osf5.1, see how that goes From jkrell at elego.de Fri Jul 16 15:01:44 2010 From: jkrell at elego.de (Jay Krell) Date: Fri, 16 Jul 2010 15:01:44 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100716130144.5A413CC37E@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/16 15:01:44 Modified files: cm3/scripts/: make-dist.sh Log message: comment only, about runpath From jkrell at elego.de Fri Jul 16 15:02:39 2010 From: jkrell at elego.de (Jay Krell) Date: Fri, 16 Jul 2010 15:02:39 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100716130239.68DDD2474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/16 15:02:39 Modified files: cm3/scripts/python/: make-dist.py Log message: keep out hardcoded runpaths, like make-dist.sh, this is setting and environment variable that config/gnuld.common checks From jkrell at elego.de Fri Jul 16 15:04:12 2010 From: jkrell at elego.de (Jay Krell) Date: Fri, 16 Jul 2010 15:04:12 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100716130413.04699CC37F@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/16 15:04:12 Modified files: cm3/scripts/python/: pylib.py make-dist.py Log message: more support for Visual C++ 10.0 From jkrell at elego.de Fri Jul 16 15:17:18 2010 From: jkrell at elego.de (Jay Krell) Date: Fri, 16 Jul 2010 15:17:18 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100716131718.49F572474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/16 15:17:18 Modified files: cm3/scripts/python/: pylib.py Log message: somewhat experimental: insert `uname -sr` in archive names, with some transforms to make it shorter: Linux 2.6.1231313 => Linux2.6 FreeBSD 1.23-release => FreeBSD1.23 -.+$ => empty actually spaces removed only investigated recently uname -sr on OSF, Darwin, FreeBSD, OpenBSD Darwin should probably be translated to MacOSX version From jkrell at elego.de Fri Jul 16 15:18:12 2010 From: jkrell at elego.de (Jay Krell) Date: Fri, 16 Jul 2010 15:18:12 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100716131812.E4F1E2474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/16 15:18:12 Modified files: cm3/scripts/python/: pylib.py Log message: 'SunOS' => 'Solaris' in archive names, though SunOS is shorter From jkrell at elego.de Fri Jul 16 15:20:11 2010 From: jkrell at elego.de (Jay Krell) Date: Fri, 16 Jul 2010 15:20:11 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100716132011.155EBCC37E@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/16 15:20:11 Modified files: cm3/scripts/python/: pylib.py Log message: Linux2.4.xxx => Linux2.4 Linux2.6.xxx => empty Linux 2.6 is I believe overwhelmingly in use 2.4 remains for small embedded systems like my router, and notably lacks NPTL (good pthreads) From jkrell at elego.de Fri Jul 16 15:22:28 2010 From: jkrell at elego.de (Jay Krell) Date: Fri, 16 Jul 2010 15:22:28 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100716132228.46EB62474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/16 15:22:28 Modified files: cm3/scripts/python/: make-dist.py Log message: environment variables must be strings From jkrell at elego.de Fri Jul 16 15:23:03 2010 From: jkrell at elego.de (Jay Krell) Date: Fri, 16 Jul 2010 15:23:03 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100716132303.CD6F42474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/16 15:23:03 Modified files: cm3/scripts/python/: pylib.py Log message: fix regexp around archive name having uname -sr From jkrell at elego.de Fri Jul 16 15:24:25 2010 From: jkrell at elego.de (Jay Krell) Date: Fri, 16 Jul 2010 15:24:25 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100716132425.2473C2474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/16 15:24:25 Modified files: cm3/scripts/python/: pylib.py Log message: fix regexp around archive name having uname -sr From jkrell at elego.de Fri Jul 16 15:28:12 2010 From: jkrell at elego.de (Jay Krell) Date: Fri, 16 Jul 2010 15:28:12 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100716132812.1D3112474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/16 15:28:12 Modified files: cm3/scripts/python/: pylib.py Log message: remove newlines from uname output From jkrell at elego.de Fri Jul 16 16:03:51 2010 From: jkrell at elego.de (Jay Krell) Date: Fri, 16 Jul 2010 16:03:51 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100716140351.9FD322474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/16 16:03:51 Modified files: cm3/m3-sys/cminstall/src/config-no-install/: ALPHA_OSF Log message: oops: ALPHA_OSF doesn't share as much code (though neither do Solaris.common or Darwin.common): forgot to call configure_c_compiler From jkrell at elego.de Fri Jul 16 16:34:49 2010 From: jkrell at elego.de (Jay Krell) Date: Fri, 16 Jul 2010 16:34:49 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100716143449.A79592474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/16 16:34:49 Modified files: cm3/m3-sys/m3cc/src/: platforms.quake Log message: need to say osf4 From jkrell at elego.de Sat Jul 17 14:37:17 2010 From: jkrell at elego.de (Jay Krell) Date: Sat, 17 Jul 2010 14:37:17 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100717123717.BB6C42474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/17 14:37:17 Modified files: cm3/m3-sys/m3cc/src/: gnucc.common Log message: acceptable hack for OSF1v4: omit -g because then the files are so large such as to exhaust virtual memory/swap linking cm3cg From jkrell at elego.de Sat Jul 17 15:09:08 2010 From: jkrell at elego.de (Jay Krell) Date: Sat, 17 Jul 2010 15:09:08 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100717130908.E32AF2474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/17 15:09:08 Modified files: cm3/m3-sys/cminstall/src/config-no-install/: ALPHA_OSF Log message: on OSF1v4, use -Wl,-B,symbolic instead of -B symbolic; it should work, but oh well From jkrell at elego.de Sat Jul 17 15:35:42 2010 From: jkrell at elego.de (Jay Krell) Date: Sat, 17 Jul 2010 15:35:42 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100717133542.69AD92474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/17 15:35:42 Modified files: cm3/m3-sys/cminstall/src/config-no-install/: ALPHA_OSF Log message: Honor $M3_PORTABLE_RUN_PATH like gnuld.common: if it is set, don't use LIB_USE, since that is specific to the machine building the files. Instead, use nothing at all, consumer will need to set LD_LIBRARY_PATH. Note that ALPHA_OSF does support -rpath ${ENVVAR}, so a good solution would be to rename foo to foo.exe (or something) and drop in a constant shell script foo. The shell script foo "finds itself", like configure: if $0 is a full path, that is it, if it is relative, that is it relative to current working directory, else search $PATH then shell script should set $ORIGIN to its own directory or and we'd use $ORIGIN/../lib and shell script would exec foo.exe. Todo later. Maybe. Probably not. From jkrell at elego.de Sat Jul 17 17:49:51 2010 From: jkrell at elego.de (Jay Krell) Date: Sat, 17 Jul 2010 17:49:51 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100717154951.4C753CC37E@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/17 17:49:51 Modified files: cm3/m3-sys/cminstall/src/config-no-install/: ALPHA_OSF Log message: non_shared doesn't work with pthread (failure to link); call_shared is default, so not needed; cleanup From jkrell at elego.de Sat Jul 17 17:50:11 2010 From: jkrell at elego.de (Jay Krell) Date: Sat, 17 Jul 2010 17:50:11 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100717155011.3892ECC37F@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/17 17:50:11 Modified files: cm3/m3-sys/cminstall/src/config-no-install/: ALPHA_OSF Log message: fix the 'cleanup' part From jkrell at elego.de Sat Jul 17 17:51:32 2010 From: jkrell at elego.de (Jay Krell) Date: Sat, 17 Jul 2010 17:51:32 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100717155132.83CFC2474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/17 17:51:32 Modified files: cm3/m3-sys/cminstall/src/config-no-install/: ALPHA_OSF Log message: fix/invert M3_PORTABLE_RUN_PATH From jkrell at elego.de Sun Jul 18 06:34:59 2010 From: jkrell at elego.de (Jay Krell) Date: Sun, 18 Jul 2010 6:34:59 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100718043459.D8CB42474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/18 06:34:59 Modified files: cm3/m3-tools/pp/src/: Parse.yacc cm3/m3-tools/pp/src/flex-bison/: lex.yy.c y.tab.c cm3/m3-tools/pp/src/lex-yacc/: lex.yy.c y.tab.c cm3/m3-tools/pp/src/lex-yacc-HPPA/: lex.yy.c y.tab.c Log message: cleanup: always #include stdlib.h stdio.h stddef.h unistd.h always use size_t don't redefine NULL This should fix a problem on OSF1v4 (incompatible declarations of malloc/free) and is fine on all systems for some years now. Strongly consider running lex/flex/yacc/bison and not checking in the output! From jay.krell at cornell.edu Sun Jul 18 06:41:46 2010 From: jay.krell at cornell.edu (Jay K) Date: Sun, 18 Jul 2010 04:41:46 +0000 Subject: [M3commit] CVS Update: cm3 In-Reply-To: <20100718043459.D8CB42474003@birch.elegosoft.com> References: <20100718043459.D8CB42474003@birch.elegosoft.com> Message-ID: diff attached Though I think better to delete these *.c files and run the tools to generate them. Agreed? I understand the idea that users that compile this directory might not have them, but they probably will. ?- Jay ---------------------------------------- > Date: Sun, 18 Jul 2010 06:34: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/07/18 06:34:59 > > Modified files: > cm3/m3-tools/pp/src/: Parse.yacc > cm3/m3-tools/pp/src/flex-bison/: lex.yy.c y.tab.c > cm3/m3-tools/pp/src/lex-yacc/: lex.yy.c y.tab.c > cm3/m3-tools/pp/src/lex-yacc-HPPA/: lex.yy.c y.tab.c > > Log message: > cleanup: > always #include stdlib.h stdio.h stddef.h unistd.h > always use size_t > don't redefine NULL > This should fix a problem on OSF1v4 (incompatible declarations > of malloc/free) and is fine on all systems for some years now. > Strongly consider running lex/flex/yacc/bison and not checking in the output! > -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: lex.txt URL: From jkrell at elego.de Sun Jul 18 06:44:19 2010 From: jkrell at elego.de (Jay Krell) Date: Sun, 18 Jul 2010 6:44:19 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100718044419.26A152474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/18 06:44:19 Modified files: cm3/m3-tools/pp/src/flex-bison/: lex.yy.c cm3/m3-tools/pp/src/lex-yacc/: lex.yy.c cm3/m3-tools/pp/src/lex-yacc-HPPA/: lex.yy.c Log message: remove $Header and $Revision From jkrell at elego.de Sun Jul 18 06:56:41 2010 From: jkrell at elego.de (Jay Krell) Date: Sun, 18 Jul 2010 6:56:41 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100718045642.0555B2474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/18 06:56:41 Modified files: cm3/m3-tools/pp/src/: m3makefile Log message: on systems that have both lex/yacc and flex/bison, favor flex/bison instead of lex/yacc, instead of the opposite From jkrell at elego.de Sun Jul 18 06:58:24 2010 From: jkrell at elego.de (Jay Krell) Date: Sun, 18 Jul 2010 6:58:24 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100718045824.9123A2474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/18 06:58:24 Modified files: cm3/m3-tools/pp/src/lex-yacc/: Makefile Log message: actually use yacc, not merely bison -y From jkrell at elego.de Sun Jul 18 07:04:40 2010 From: jkrell at elego.de (Jay Krell) Date: Sun, 18 Jul 2010 7:04:40 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100718050440.72F282474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/18 07:04:40 Modified files: cm3/m3-tools/pp/src/: m3makefile Log message: fix From jkrell at elego.de Sun Jul 18 07:44:00 2010 From: jkrell at elego.de (Jay Krell) Date: Sun, 18 Jul 2010 7:44:00 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100718054401.4DFF02474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/18 07:44:00 Modified files: cm3/scripts/python/: pylib.py make-dist.py Log message: mips-tfile for make-dist ALPHA_OSF support, and consolidate mklib support, not all tested as file copy to Alpha/OSF difficult From jkrell at elego.de Sun Jul 18 10:11:16 2010 From: jkrell at elego.de (Jay Krell) Date: Sun, 18 Jul 2010 10:11:16 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100718081117.005AD2474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/18 10:11:16 Modified files: cm3/m3-sys/m3cc/gcc-4.5/gcc/: gimple.h Log message: add asserts that helped me track down problem (later assertion failure) with sets being void* instead of size_t* I suspect these are correct but if they are wrong, ok, remove them. From jkrell at elego.de Sun Jul 18 10:20:20 2010 From: jkrell at elego.de (Jay Krell) Date: Sun, 18 Jul 2010 10:20:20 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100718082020.E9A0ACC37E@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/18 10:20:20 Modified files: cm3/m3-sys/m3cc/gcc/gcc/: config.host config.gcc cm3/m3-sys/m3cc/gcc/gcc/config/: openbsd.h t-openbsd cm3/m3-sys/m3cc/gcc/gcc/config/i386/: openbsd.h openbsdelf.h cm3/m3-sys/m3cc/gcc/gcc/config/m68k/: openbsd.h cm3/m3-sys/m3cc/gcc/gcc/config/mips/: openbsd.h cm3/m3-sys/m3cc/gcc/gcc/config/vax/: openbsd.h cm3/m3-sys/m3cc/src/: m3makefile Log message: Commit the OpenBSD patches instead of applying them in the build. Note that I doubt change to gcc/gcc/config/openbsd.h is needed, it looks specific to using the C front ends (cc1, etc.) or the "driver" (gcc). From jkrell at elego.de Sun Jul 18 10:40:52 2010 From: jkrell at elego.de (Jay Krell) Date: Sun, 18 Jul 2010 10:40:52 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100718084052.5C3012474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/18 10:40:52 Added files: cm3/m3-sys/m3cc/gcc/gcc/config/: exec-stack.h host-openbsd.c openbsd-libpthread.h x-openbsd cm3/m3-sys/m3cc/gcc/gcc/config/i386/: openbsd64.h cm3/m3-sys/m3cc/gcc/gcc/config/rs6000/: openbsd.h Log message: oops: also add the new files needed for OpenBSD, that we were previously copying from the patches directory From jkrell at elego.de Sun Jul 18 11:47:42 2010 From: jkrell at elego.de (Jay Krell) Date: Sun, 18 Jul 2010 11:47:42 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100718094742.9BDF9CC37E@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/18 11:47:42 Modified files: cm3/m3-sys/m3cc/gcc/gcc/: tree-chrec.h Log message: initialize with generic { 0 } instead of 0 (this is a line that we changed anyway From jkrell at elego.de Sun Jul 18 11:49:48 2010 From: jkrell at elego.de (Jay Krell) Date: Sun, 18 Jul 2010 11:49:48 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100718094948.4AD92CC37E@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/18 11:49:48 Modified files: cm3/m3-sys/m3cc/gcc/gcc/: tree.c Log message: change copyright comment back to match 4.3.0 and 4.3.5 From jkrell at elego.de Sun Jul 18 11:56:25 2010 From: jkrell at elego.de (Jay Krell) Date: Sun, 18 Jul 2010 11:56:25 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100718095625.5ADB22474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/18 11:56:25 Modified files: cm3/m3-sys/m3cc/gcc/gcc/: dbxout.c Log message: remove code that was #if 0'ed out September 2008 From jkrell at elego.de Sun Jul 18 13:13:45 2010 From: jkrell at elego.de (Jay Krell) Date: Sun, 18 Jul 2010 13:13:45 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100718111345.7E9632474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/18 13:13:45 Modified files: cm3/m3-sys/m3cc/gcc/: ChangeLog LAST_UPDATED MD5SUMS Makefile.def Makefile.in Makefile.tpl NEWS config-ml.in configure configure.ac cm3/m3-sys/m3cc/gcc/INSTALL/: binaries.html build.html configure.html download.html finalinstall.html gfdl.html index.html old.html prerequisites.html specific.html test.html cm3/m3-sys/m3cc/gcc/config/: ChangeLog cm3/m3-sys/m3cc/gcc/contrib/: ChangeLog texi2pod.pl cm3/m3-sys/m3cc/gcc/contrib/reghunt/: ChangeLog cm3/m3-sys/m3cc/gcc/contrib/regression/: ChangeLog cm3/m3-sys/m3cc/gcc/fixincludes/: ChangeLog fixincl.x inclhack.def cm3/m3-sys/m3cc/gcc/fixincludes/tests/base/iso/: math_c99.h cm3/m3-sys/m3cc/gcc/gcc/: BASE-VER ChangeLog ChangeLog-2007 DATESTAMP Makefile.in aclocal.m4 alias.c alias.h attribs.c builtin-types.def builtins.c builtins.def c-common.c c-cppbuiltin.c c-decl.c c-format.c c-lex.c c-parser.c c-pch.c c-pretty-print.c c-typeck.c calls.c cfgrtl.c cgraph.c cgraph.h cgraphunit.c collect2.c combine-stack-adj.c combine.c config.gcc configure configure.ac convert.c cse.c dbxout.c df-scan.c dfp.c dojump.c dse.c dwarf2.h dwarf2out.c emit-rtl.c emutls.c except.c exec-tool.in explow.c expmed.c expr.c final.c flags.h fold-const.c function.c fwprop.c gcov-io.h gcse.c gengtype-lex.c gengtype.c gimplify.c global.c gthr-posix.h gthr-posix95.h haifa-sched.c ifcvt.c ipa-inline.c ipa-utils.h jump.c langhooks-def.h langhooks.c langhooks.h libgcc2.c longlong.h loop-invariant.c mips-tfile.c omp-low.c optc-gen.awk opts.c params.def passes.c predict.c pretty-print.c real.c real.h recog.c recog.h regmove.c regrename.c reload.c resource.c rtl.h rtlanal.c sched-deps.c sched-int.h sched-rgn.c simplify-rtx.c stmt.c stor-layout.c target-def.h target.h targhooks.c targhooks.h toplev.c tree-cfg.c tree-chrec.c tree-chrec.h tree-complex.c tree-dfa.c tree-flow-inline.h tree-flow.h tree-inline.c tree-loop-linear.c tree-nested.c tree-nrv.c tree-outof-ssa.c tree-parloops.c tree-predcom.c tree-scalar-evolution.c tree-scalar-evolution.h tree-sra.c tree-ssa-address.c tree-ssa-alias-warnings.c tree-ssa-alias.c tree-ssa-ccp.c tree-ssa-dse.c tree-ssa-forwprop.c tree-ssa-loop-im.c tree-ssa-loop-ivopts.c tree-ssa-loop-niter.c tree-ssa-loop-prefetch.c tree-ssa-operands.c tree-ssa-phiopt.c tree-ssa-pre.c tree-ssa-sccvn.c tree-ssa-structalias.c tree-ssa.c tree-tailcall.c tree-vect-analyze.c tree-vect-generic.c tree-vect-transform.c tree-vn.c tree-vrp.c tree.c tree.h unwind-dw2.c unwind-generic.h unwind-pe.h varasm.c vec.h cm3/m3-sys/m3cc/gcc/gcc/config/: dfp-bit.c freebsd.h cm3/m3-sys/m3cc/gcc/gcc/config/alpha/: alpha.c alpha.md elf.h predicates.md sync.md cm3/m3-sys/m3cc/gcc/gcc/config/arm/: arm.c arm.md iwmmxt.md cm3/m3-sys/m3cc/gcc/gcc/config/avr/: avr-protos.h avr.c avr.h avr.md cm3/m3-sys/m3cc/gcc/gcc/config/cris/: cris.c cris.h cris.md cm3/m3-sys/m3cc/gcc/gcc/config/i386/: ammintrin.h bmmintrin.h driver-i386.c emmintrin.h i386.c i386.h i386.md i386.opt linux.h mm3dnow.h mmintrin-common.h mmintrin.h mmx.md pmmintrin.h predicates.md smmintrin.h sse.md sync.md tmmintrin.h winnt-cxx.c winnt.c x86-64.h xmmintrin.h cm3/m3-sys/m3cc/gcc/gcc/config/ia64/: div.md ia64.c ia64.md cm3/m3-sys/m3cc/gcc/gcc/config/m68k/: t-rtems cm3/m3-sys/m3cc/gcc/gcc/config/mips/: constraints.md iris6.h irix-crti.asm mips.c mips.md mips.opt sde.h cm3/m3-sys/m3cc/gcc/gcc/config/mn10300/: mn10300.c cm3/m3-sys/m3cc/gcc/gcc/config/pa/: fptr.c hpux-unwind.h linux-unwind.h milli64.S pa-hpux11.h pa.c pa.md pa64-hpux.h t-hpux-shlib cm3/m3-sys/m3cc/gcc/gcc/config/pdp11/: pdp11.c cm3/m3-sys/m3cc/gcc/gcc/config/rs6000/: altivec.md driver-rs6000.c predicates.md rs6000-c.c rs6000-protos.h rs6000.c rs6000.md cm3/m3-sys/m3cc/gcc/gcc/config/s390/: s390.c s390.h tpf.h cm3/m3-sys/m3cc/gcc/gcc/config/sh/: predicates.md sh.c sh.h sh.md t-sh cm3/m3-sys/m3cc/gcc/gcc/config/soft-fp/: double.h fixdfti.c floatuntisf.c cm3/m3-sys/m3cc/gcc/gcc/config/sparc/: linux.h linux64.h predicates.md sparc-protos.h sparc.c sparc.h sparc.md sysv4.h cm3/m3-sys/m3cc/gcc/gcc/config/spu/: spu-c.c spu-elf.h spu-protos.h spu.c spu.h spu.md spu.opt spu_mfcio.h t-spu-elf cm3/m3-sys/m3cc/gcc/gcc/config/stormy16/: stormy16.c cm3/m3-sys/m3cc/gcc/gcc/config/xtensa/: t-linux xtensa.md cm3/m3-sys/m3cc/gcc/gcc/doc/: cpp.1 cpp.info cppinternals.info extend.texi fsf-funding.7 g++.1 gc-analyze.1 gcc.1 gcc.info gcc.texi gccinstall.info gccint.info gccint.texi gcj-dbtool.1 gcj.1 gcj.info gcov.1 gfdl.7 gfortran.1 gij.1 gpl.7 grmic.1 gty.texi implement-c.texi install.texi install.texi2html invoke.texi jcf-dump.1 jv-convert.1 md.texi passes.texi rtl.texi sourcebuild.texi cm3/m3-sys/m3cc/gcc/gcc/doc/include/: gpl_v3.texi texinfo.tex cm3/m3-sys/m3cc/gcc/gcc/treelang/: ChangeLog cm3/m3-sys/m3cc/gcc/include/: ChangeLog cm3/m3-sys/m3cc/gcc/libcpp/: ChangeLog files.c cm3/m3-sys/m3cc/gcc/libdecnumber/: ChangeLog Makefile.in decBasic.c decCommon.c decContext.c decDouble.h decExcept.c decExcept.h decLibrary.c decNumber.c decNumberLocal.h decQuad.h decRound.c decSingle.h cm3/m3-sys/m3cc/gcc/libdecnumber/bid/: host-ieee128.c cm3/m3-sys/m3cc/gcc/libdecnumber/dpd/: decimal128.c decimal128Local.h decimal32.c decimal64.c cm3/m3-sys/m3cc/gcc/libgcc/: ChangeLog Makefile.in config.host configure configure.ac cm3/m3-sys/m3cc/gcc/libgcc/config/libbid/: ChangeLog cm3/m3-sys/m3cc/gcc/libiberty/: ChangeLog configure configure.ac cm3/m3-sys/m3cc/gcc/maintainer-scripts/: ChangeLog gcc_release Log message: merge with gcc 4.3.5 From jkrell at elego.de Sun Jul 18 13:20:04 2010 From: jkrell at elego.de (Jay Krell) Date: Sun, 18 Jul 2010 13:20:04 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100718112004.C0EAF2474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/18 13:20:04 Added files: cm3/m3-sys/m3cc/gcc/contrib/: dg-extract-results.sh cm3/m3-sys/m3cc/gcc/gcc/config/sparc/: gas.h cm3/m3-sys/m3cc/gcc/gcc/config/spu/: divmodti4.c float_disf.c float_unsdisf.c multi3.c cm3/m3-sys/m3cc/gcc/gcc/config/xtensa/: libgcc-xtensa.ver cm3/m3-sys/m3cc/gcc/libdecnumber/: dconfig.h cm3/m3-sys/m3cc/gcc/libgcc/: gstdint.h cm3/m3-sys/m3cc/gcc/libgcc/config/i386/: t-sol2 Log message: merge with gcc 4.3.5 From jkrell at elego.de Sun Jul 18 14:11:25 2010 From: jkrell at elego.de (Jay Krell) Date: Sun, 18 Jul 2010 14:11:25 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100718121125.A19C72474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/18 14:11:25 Modified files: cm3/m3-libs/m3core/src/Csupport/Common/: hand.c Log message: add back set_singleton, set_member, set_ne, set_eq for my convenience attempting bootstrap with old compiler and new mecore From jkrell at elego.de Sun Jul 18 14:37:32 2010 From: jkrell at elego.de (Jay Krell) Date: Sun, 18 Jul 2010 14:37:32 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100718123732.99A582474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/18 14:37:32 Modified files: cm3/m3-libs/m3core/src/Csupport/Common/: hand.c Added files: cm3/m3-libs/m3core/src/Csupport/Common/: old_divmod.c Log message: move old code out, add comments to it about its "problems" From jkrell at elego.de Sun Jul 18 16:05:50 2010 From: jkrell at elego.de (Jay Krell) Date: Sun, 18 Jul 2010 16:05:50 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100718140550.A12532474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/18 16:05:50 Added files: cm3/www/releng/: relnotes-5.9.html Log message: new file for the next release, first copy the old file From jkrell at elego.de Sun Jul 18 16:12:53 2010 From: jkrell at elego.de (Jay Krell) Date: Sun, 18 Jul 2010 16:12:53 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100718141255.7C4AD2474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/18 16:12:53 Modified files: cm3/www/releng/: relnotes-5.9.html Log message: update it with some stuff post 5.8 From jkrell at elego.de Sun Jul 18 16:14:20 2010 From: jkrell at elego.de (Jay Krell) Date: Sun, 18 Jul 2010 16:14:20 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100718141420.D97032474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/18 16:14:20 Modified files: cm3/www/releng/: relnotes-5.9.html Log message: ALPHA_OSF target restored (4.0g, 5.1) From jkrell at elego.de Sun Jul 18 16:44:38 2010 From: jkrell at elego.de (Jay Krell) Date: Sun, 18 Jul 2010 16:44:38 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100718144438.7E3602474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/18 16:44:38 Modified files: cm3/m3-sys/cminstall/src/config-no-install/: Solaris.common Log message: remove -lpthread again; fix flex/bison to be -L/usr/sfw/bin/lib -lfl instead of empty, but comment it out in favor of I think the more 'standard' (not optional) lex/yacc From jkrell at elego.de Sun Jul 18 16:53:14 2010 From: jkrell at elego.de (Jay Krell) Date: Sun, 18 Jul 2010 16:53:14 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100718145315.166AE2474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/18 16:53:14 Modified files: cm3/www/releng/: relnotes-5.9.html Log message: relnotes-5.9.html From jkrell at elego.de Sun Jul 18 16:53:35 2010 From: jkrell at elego.de (Jay Krell) Date: Sun, 18 Jul 2010 16:53:35 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100718145335.DC5602474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/18 16:53:35 Modified files: cm3/www/releng/: relnotes-5.9.html Log message: flubbed checkin comment: new targets: SPARC64_SOLARIS, I386_SOLARIS, AMD64_SOLARIS (2.9?) From jkrell at elego.de Sun Jul 18 17:23:55 2010 From: jkrell at elego.de (Jay Krell) Date: Sun, 18 Jul 2010 17:23:55 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100718152355.EBF422474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/18 17:23:55 Modified files: cm3/www/releng/: relnotes-5.9.html Log message: note some more changes since release; of course, the release notes will need review, proofing for style and correctness, etc. and this is very very very far from urgent From jkrell at elego.de Sun Jul 18 17:52:41 2010 From: jkrell at elego.de (Jay Krell) Date: Sun, 18 Jul 2010 17:52:41 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100718155242.142A02474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/18 17:52:41 Modified files: cm3/m3-sys/m3cc/src/: gnucc.common Log message: compat with previous release config files, could maybe just delete this OSF1v4 hack also now that Mark has added swap From jkrell at elego.de Sun Jul 18 18:00:56 2010 From: jkrell at elego.de (Jay Krell) Date: Sun, 18 Jul 2010 18:00:56 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100718160056.A9AA72474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/18 18:00:56 Modified files: cm3/m3-libs/m3core/src/win32/: m3makefile Log message: copy code from cm3cfg.common for compatibility I would prefer if the config files were updated fairly early in the build and my burden was to maintain compatiblity through them, not in m3makefiles otherwise. From jkrell at elego.de Sun Jul 18 18:03:00 2010 From: jkrell at elego.de (Jay Krell) Date: Sun, 18 Jul 2010 18:03:00 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100718160300.239C22474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/18 18:03:00 Modified files: cm3/m3-sys/cminstall/src/config-no-install/: cm3cfg.common Log message: require TARGET_OS to be defined; either bootstrap from 5.8.6 release or update older config files; we'll see if this flies, hopefully, but I might not like it myself, we'll see From jkrell at elego.de Mon Jul 19 03:23:16 2010 From: jkrell at elego.de (Jay Krell) Date: Mon, 19 Jul 2010 3:23:16 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100719012318.ABC2E2474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/19 03:23:16 Modified files: cm3/m3-sys/m3cc/src/: m3makefile cm3/m3-sys/m3cc/gcc/gcc/config/: darwin.h Log message: m3makefile, basically undo: Revision 1.162 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. Revision 1.161 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. darwin.h, undo Revision 1.2 always support hidden aka private extern aka don't export every function This should fix PPC_DARWIN and maybe maybe others (SPARC32_LINUX). Possibly relatd, I've noticed SOLsun using sparc-sun-solaris2.10-gcc to build cm3cg, when I was hoping it'd use Sun cc. This will at least change it to plain gcc, but same thing. From jkrell at elego.de Mon Jul 19 04:48:20 2010 From: jkrell at elego.de (Jay Krell) Date: Mon, 19 Jul 2010 4:48:20 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100719024822.CE20E2474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/19 04:48:20 Added files: cm3/www/uploaded-archives/: readme.txt Log message: Some notes I just made as to what "all", "min", and "boot" are. They should be reviewed, tested, edited, worked into the web page at: http://modula3.elegosoft.com/cm3/uploaded-archives/ From jkrell at elego.de Mon Jul 19 04:49:12 2010 From: jkrell at elego.de (Jay Krell) Date: Mon, 19 Jul 2010 4:49:12 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100719024913.4FBC82474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/19 04:49:12 Modified files: cm3/www/uploaded-archives/: readme.txt Log message: typo From jkrell at elego.de Mon Jul 19 04:50:00 2010 From: jkrell at elego.de (Jay Krell) Date: Mon, 19 Jul 2010 4:50:00 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100719025003.099082474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/19 04:50:00 Modified files: cm3/www/uploaded-archives/: readme.txt Log message: typos From jkrell at elego.de Mon Jul 19 04:55:54 2010 From: jkrell at elego.de (Jay Krell) Date: Mon, 19 Jul 2010 4:55:54 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100719025555.8ED6C2474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/19 04:55:54 Modified files: cm3/www/uploaded-archives/: readme.txt Log message: document problem with 'boot' that prevents its wider use e.g. in Hudson: it provides just cm3, but that cm3 is tied somewhat to a particular m3core and cm3cg, not as much as in the past, but still (e.g. if RTHooks.i3 or M3CG.i3 change); the dependency on m3core is easy to fix, by making a library from .o files produced here anyway, the dependency on cm3cg not so much From jkrell at elego.de Mon Jul 19 05:41:41 2010 From: jkrell at elego.de (Jay Krell) Date: Mon, 19 Jul 2010 5:41:41 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100719034141.C68F32474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/19 05:41:41 Modified files: cm3/m3-libs/m3core/src/: m3core.h Log message: should fix OpenBSD builds From jkrell at elego.de Mon Jul 19 05:46:00 2010 From: jkrell at elego.de (Jay Krell) Date: Mon, 19 Jul 2010 5:46:00 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100719034600.7A3C0CC37E@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/19 05:46:00 Modified files: cm3/scripts/python/: pylib.py Log message: put comment in Makefile for OSF1v4 users to act on From jkrell at elego.de Mon Jul 19 08:05:45 2010 From: jkrell at elego.de (Jay Krell) Date: Mon, 19 Jul 2010 8:05:45 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100719060546.261CE2474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/19 08:05:45 Modified files: cm3/m3-sys/m3cc/src/: m3makefile Added files: cm3/m3-sys/m3cc/src/: clean_marker.txt Log message: mechanism to let a checkin force subsequent builds to be clean: edit this clean_marker.txt file also cleanup the clean logic to just rm -rf build_dir/* From jkrell at elego.de Mon Jul 19 08:16:35 2010 From: jkrell at elego.de (Jay Krell) Date: Mon, 19 Jul 2010 8:16:35 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100719061636.0600B2474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/19 08:16:35 Modified files: cm3/m3-sys/m3cc/src/: clean_marker.txt m3makefile Log message: use the "new" quake builtins fs_lsfiles, fs_lsdirs, fs_rmrec and the old delete_file From jkrell at elego.de Mon Jul 19 08:19:19 2010 From: jkrell at elego.de (Jay Krell) Date: Mon, 19 Jul 2010 8:19:19 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100719061919.5D4882474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/19 08:19:19 Modified files: cm3/m3-sys/m3cc/src/: m3makefile Log message: remove use of if defined -- these are in the previous release now; we'll see how this goes -- requiring previous release From jkrell at elego.de Mon Jul 19 08:25:14 2010 From: jkrell at elego.de (Jay Krell) Date: Mon, 19 Jul 2010 8:25:14 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100719062515.0843F2474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/19 08:25:14 Modified files: cm3/m3-sys/m3cc/src/: m3makefile Log message: use TRUE and FALSE for boolean NOACTION instead of obscure "" and "T" From jkrell at elego.de Mon Jul 19 08:27:20 2010 From: jkrell at elego.de (Jay Krell) Date: Mon, 19 Jul 2010 8:27:20 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100719062720.98D112474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/19 08:27:20 Modified files: cm3/m3-sys/m3cc/gcc/gcc/: value-prof.c Log message: ../../gcc/gcc/value-prof.c: In function `tree_mod_subtract': ../../gcc/gcc/value-prof.c:831: warning: `bb3' might be used uninitialized in this function From jkrell at elego.de Mon Jul 19 09:05:15 2010 From: jkrell at elego.de (Jay Krell) Date: Mon, 19 Jul 2010 9:05:15 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100719070516.29BE42474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/19 09:05:15 Modified files: cm3/m3-sys/m3cc/gcc/gcc/: varasm.c Log message: ../../gcc/gcc/varasm.c: In function `const_rtx_hash_1': ../../gcc/gcc/varasm.c:3387: warning: right shift count >= width of type From jkrell at elego.de Tue Jul 20 12:49:45 2010 From: jkrell at elego.de (Jay Krell) Date: Tue, 20 Jul 2010 12:49:45 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100720104945.7428D2474005@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/20 12:49:45 Modified files: cm3/m3-db/odbc/src/: m3makefile Log message: check if configure_system_libs is defined before calling it From jkrell at elego.de Tue Jul 20 13:24:04 2010 From: jkrell at elego.de (Jay Krell) Date: Tue, 20 Jul 2010 13:24:04 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100720112404.81C642474005@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/20 13:24:04 Modified files: cm3/scripts/: sysinfo.sh Log message: This should fix the NT386/m3cc problem. Note however that I've churned sysinfo.sh a lot in head -- not with this commit, but earlier. From jkrell at elego.de Tue Jul 20 14:19:03 2010 From: jkrell at elego.de (Jay Krell) Date: Tue, 20 Jul 2010 14:19:03 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100720121903.5281D2474005@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/20 14:19:03 Modified files: cm3/m3-sys/cminstall/src/config-no-install/: OpenBSD.common cm3/m3-libs/m3core/src/runtime/common/: RTProcessC.c Log message: This should fix the hang on I386_OPENBSD. That only I'm seeing. (Hudson doesn't build enough, nobody else has reported it). It doesn't affect 5.8.6 release as that uses jmpbuf hacking for userthreads. The rewrite to use sigaltstack is new since then. RTProcessC.c: INTEGER __cdecl RTProcess__RegisterForkHandlers( ForkHandler prepare, ForkHandler parent, ForkHandler child) { >> big comment added /* FreeBSD < 6 lacks pthread_atfork. Would be good to use autoconf. * VMS lacks pthread_atfork? Would be good to use autoconf. * Win32 lacks pthread_atfork and fork. OK. * OpenBSD pthread_atfork causes us to need libpthread, and then * sigsuspend on 4.6/x86 hangs in the userthread code. * * I expect therefore cvsup is broken with user threads on these systems. * * OpenBSD we could fix by going back to jmpbuf hacking (see 5.8.6 release), * but it is nice to have portable code, and cvsup maybe is expendable (again, * only on OpenBSD). * * As well, for all Posix systems, we could implement * atfork ourselves, as long as we provide a fork() * wrapper that code uses. */ #if defined(_WIN32) \ || defined(__vms) \ || defined(__OpenBSD__) \ << this added || (defined(__FreeBSD__) && (__FreeBSD__ < 6)) return 0; #else >> add % LIBC: No pthreads, to avoid its sigsuspend that hangs. % See also RTProcess__RegisterForkHandlers. SYSTEM_LIBS{"LIBC"} = ["-lm"] From jkrell at elego.de Tue Jul 20 14:30:40 2010 From: jkrell at elego.de (Jay Krell) Date: Tue, 20 Jul 2010 14:30:40 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100720123040.B54572474005@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/20 14:30:40 Modified files: cm3/scripts/python/: upgrade.py Log message: I just introduced incompatibility between current openbsd config and older m3core -- the reference to pthread_atfork won't result, so, let's consider *not* updating config files so early -- this matches I believe what Hudson/Tinderbox do and *definitely* has good arguments in favor of it. From jkrell at elego.de Tue Jul 20 16:13:30 2010 From: jkrell at elego.de (Jay Krell) Date: Tue, 20 Jul 2010 16:13:30 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100720141330.E4B162474005@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/20 16:13:30 Modified files: cm3/m3-sys/cminstall/src/config-no-install/: OpenBSD.common Log message: add more X libraries so that solitaire builds (it is standalone) From jkrell at elego.de Wed Jul 21 12:27:11 2010 From: jkrell at elego.de (Jay Krell) Date: Wed, 21 Jul 2010 12:27:11 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100721102711.E2A8E2474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/21 12:27:11 Modified files: cm3/m3-sys/cminstall/src/config-no-install/: ALPHA_OSF Log message: set TARGET_OS=OSF (other names re reasonable) From jkrell at elego.de Wed Jul 21 12:28:29 2010 From: jkrell at elego.de (Jay Krell) Date: Wed, 21 Jul 2010 12:28:29 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100721102829.CE6742474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/21 12:28:29 Modified files: cm3/m3-sys/m3cc/src/: m3makefile Log message: building mips-tfile seems to fail on cross builds, like maybe the headers describing the object/symbol format aren't available? So only build it for native builds From jkrell at elego.de Wed Jul 21 12:48:29 2010 From: jkrell at elego.de (Jay Krell) Date: Wed, 21 Jul 2010 12:48:29 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100721104830.129C2CC389@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/21 12:48:29 Added files: cm3/m3-libs/m3core/src/unix/osf-1.ALPHA_OSF/: m3makefile Usignal.i3 Log message: bring back files, to try to get back setjmp-less exception handling From jkrell at elego.de Wed Jul 21 12:48:57 2010 From: jkrell at elego.de (Jay Krell) Date: Wed, 21 Jul 2010 12:48:57 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100721104857.4FE532474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/21 12:48:57 Modified files: cm3/m3-libs/m3core/src/unix/osf-1.ALPHA_OSF/: m3makefile Log message: edit it down From jkrell at elego.de Wed Jul 21 13:15:07 2010 From: jkrell at elego.de (Jay Krell) Date: Wed, 21 Jul 2010 13:15:07 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100721111507.2AE542474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/21 13:15:07 Modified files: cm3/scripts/python/: pylib.py Log message: fix typo on ALPHA_OSF From jkrell at elego.de Wed Jul 21 13:18:15 2010 From: jkrell at elego.de (Jay Krell) Date: Wed, 21 Jul 2010 13:18:15 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100721111815.8B16A2474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/21 13:18:15 Modified files: cm3/m3-libs/m3core/src/unix/: m3makefile cm3/m3-libs/m3core/src/unix/Common/: m3makefile cm3/m3-libs/m3core/src/unix/osf-1.ALPHA_OSF/: Usignal.i3 Log message: trim ALPHA_OSF/Usignal.i3 down to just an exact copy of Common/Usignal.i3 plus struct_sigcontext, enough, maybe more than enough, to compile the stack walking code (do we really need such an accurate Frame exposed to the Modula-3?) From jkrell at elego.de Wed Jul 21 14:33:38 2010 From: jkrell at elego.de (Jay Krell) Date: Wed, 21 Jul 2010 14:33:38 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100721123338.4B8992474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/21 14:33:38 Modified files: cm3/m3-libs/m3core/src/: m3core.h cm3/m3-libs/m3core/src/time/POSIX/: DatePosixC.c cm3/m3-libs/m3core/src/unix/: m3makefile Log message: Better perhaps for OSF/1. In particular, no longer need #ifdef M3_OSF1_V4. I #define _TIME64_T, and then I can tell if this system supports it by checking for defined(TIMEVAL64TO32) & TIMEVAL32TO64 From jkrell at elego.de Wed Jul 21 14:38:41 2010 From: jkrell at elego.de (Jay Krell) Date: Wed, 21 Jul 2010 14:38:41 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100721123841.903222474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/21 14:38:41 Modified files: cm3/m3-libs/m3core/src/unix/: m3makefile Log message: oops: fix ALPHA_OSF breakage From jkrell at elego.de Wed Jul 21 14:47:28 2010 From: jkrell at elego.de (Jay Krell) Date: Wed, 21 Jul 2010 14:47:28 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100721124728.3726F2474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/21 14:47:28 Modified files: cm3/m3-libs/m3core/src/unix/: m3makefile Log message: use TARGET_OS to shrink tables -- requires config file change from release 5.8.6 From jkrell at elego.de Wed Jul 21 14:48:38 2010 From: jkrell at elego.de (Jay Krell) Date: Wed, 21 Jul 2010 14:48:38 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100721124838.8BF0C2474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/21 14:48:38 Modified files: cm3/m3-libs/m3core/src/unix/: m3makefile Log message: whitespace From jkrell at elego.de Wed Jul 21 14:55:12 2010 From: jkrell at elego.de (Jay Krell) Date: Wed, 21 Jul 2010 14:55:12 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100721125512.609A92474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/21 14:55:12 Modified files: cm3/m3-libs/libm3/src/: m3makefile Removed files: cm3/m3-libs/libm3/src/: platforms.quake Log message: Eliminate extra platform lists now that 5.8.6 has shipped and its config files are the baseline. From jkrell at elego.de Wed Jul 21 17:26:52 2010 From: jkrell at elego.de (Jay Krell) Date: Wed, 21 Jul 2010 17:26:52 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100721152652.1C8712474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/21 17:26:52 Modified files: cm3/m3-sys/cminstall/src/config-no-install/: SPARC.common Log message: add -m32 to try to fix SPARC32_LINUX, add -funwind-tables in anticipation of libunwind, comment that -gstabs+ is only missing because we are chronically out of diskspace on the Hudson node (lame) From jkrell at elego.de Wed Jul 21 17:29:18 2010 From: jkrell at elego.de (Jay Krell) Date: Wed, 21 Jul 2010 17:29:18 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100721152918.8A6EB2474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/21 17:29:18 Modified files: cm3/m3-ui/PEX/src/: m3makefile Log message: only call configure_system_libs if it is defined (This is showing up in Hudson: e.g. http://hudson.modula3.com:8080/job/cm3-current-test-all-pkgs-SOLgnu From jkrell at elego.de Wed Jul 21 17:30:16 2010 From: jkrell at elego.de (Jay Krell) Date: Wed, 21 Jul 2010 17:30:16 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100721153016.48C6A2474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/21 17:30:16 Modified files: cm3/m3-ui/ui/src/xvbt/: m3makefile Log message: only call configure_system_libs if it is defined (This is showing up in Hudson: e.g. http://hudson.modula3.com:8080/job/cm3-current-test-all-pkgs-SOLgnu From jay.krell at cornell.edu Wed Jul 21 17:32:01 2010 From: jay.krell at cornell.edu (Jay K) Date: Wed, 21 Jul 2010 15:32:01 +0000 Subject: [M3commit] CVS Update: cm3 In-Reply-To: <20100721153016.48C6A2474003@birch.elegosoft.com> References: <20100721153016.48C6A2474003@birch.elegosoft.com> Message-ID: Hm, odd, this in cm3cfg.common if nowhere else. Something seems off. ?- Jay ---------------------------------------- > Date: Wed, 21 Jul 2010 17:30: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/07/21 17:30:16 > > Modified files: > cm3/m3-ui/ui/src/xvbt/: m3makefile > > Log message: > only call configure_system_libs if it is defined (This is showing up in Hudson: e.g. http://hudson.modula3.com:8080/job/cm3-current-test-all-pkgs-SOLgnu > From jkrell at elego.de Wed Jul 21 17:35:10 2010 From: jkrell at elego.de (Jay Krell) Date: Wed, 21 Jul 2010 17:35:10 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100721153510.982222474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/21 17:35:10 Modified files: cm3/m3-ui/PEX/src/: m3makefile Log message: undo: call configure_system_libs unconditionally, fix should be central, and code is already written correct-seeming From jkrell at elego.de Wed Jul 21 17:35:47 2010 From: jkrell at elego.de (Jay Krell) Date: Wed, 21 Jul 2010 17:35:47 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100721153547.670052474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/21 17:35:47 Modified files: cm3/m3-ui/ui/src/xvbt/: m3makefile Log message: undo: call configure_system_libs unconditionally, fix should be central, and code is already written correct-seeming From jkrell at elego.de Wed Jul 21 17:53:14 2010 From: jkrell at elego.de (Jay Krell) Date: Wed, 21 Jul 2010 17:53:14 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100721155314.E1BC6CC389@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/21 17:53:14 Modified files: cm3/scripts/: install-cm3-compiler.sh Log message: upgrade config files when upgrading compiler From jkrell at elego.de Wed Jul 21 17:54:15 2010 From: jkrell at elego.de (Jay Krell) Date: Wed, 21 Jul 2010 17:54:15 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100721155415.CAD312474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/21 17:54:15 Modified files: cm3/scripts/: install-cm3-compiler.sh Log message: mkdir more From jkrell at elego.de Wed Jul 21 17:58:10 2010 From: jkrell at elego.de (Jay Krell) Date: Wed, 21 Jul 2010 17:58:10 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100721155810.335512474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/21 17:58:10 Modified files: cm3/m3-sys/cminstall/src/config-no-install/: ALPHA_OSF cm3/scripts/python/: pylib.py Log message: remove -DM3_OSF1_V4 now that m3core.h figures it out From jay.krell at cornell.edu Wed Jul 21 18:30:56 2010 From: jay.krell at cornell.edu (Jay K) Date: Wed, 21 Jul 2010 16:30:56 +0000 Subject: [M3commit] CVS Update: cm3 In-Reply-To: <20100721155314.E1BC6CC389@birch.elegosoft.com> References: <20100721155314.E1BC6CC389@birch.elegosoft.com> Message-ID: I've manually updated the config files on SPARC32_LINUX Hudson node to try to fix this. ?- Jay ---------------------------------------- > Date: Wed, 21 Jul 2010 17:53: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/07/21 17:53:14 > > Modified files: > cm3/scripts/: install-cm3-compiler.sh > > Log message: > upgrade config files when upgrading compiler > From wagner at elego.de Wed Jul 21 22:39:32 2010 From: wagner at elego.de (Olaf Wagner) Date: Wed, 21 Jul 2010 22:39:32 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100721203932.B5C9D2474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: wagner at birch. 10/07/21 22:39:32 Modified files: cm3/scripts/: version version.quake Log message: fix version number on trunk for 5.9 development From wagner at elegosoft.com Thu Jul 22 08:53:23 2010 From: wagner at elegosoft.com (Olaf Wagner) Date: Thu, 22 Jul 2010 08:53:23 +0200 Subject: [M3commit] CVS Update: cm3 In-Reply-To: References: <20100721155314.E1BC6CC389@birch.elegosoft.com> Message-ID: <20100722085323.0nmmjnom94osso88@mail.elegosoft.com> Quoting Jay K : > I've manually updated the config files on SPARC32_LINUX Hudson node > to try to fix this. That should be done by the upgrade script (and it already was AFAIR). I wouldn't like the script shipping a newly built compiler to unconditionally overwrite all my local configuration. Olaf > > ?- Jay > > ---------------------------------------- >> Date: Wed, 21 Jul 2010 17:53: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/07/21 17:53:14 >> >> Modified files: >> cm3/scripts/: install-cm3-compiler.sh >> >> Log message: >> upgrade config files when upgrading compiler >> > -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From jay.krell at cornell.edu Thu Jul 22 09:08:45 2010 From: jay.krell at cornell.edu (Jay K) Date: Thu, 22 Jul 2010 07:08:45 +0000 Subject: [M3commit] CVS Update: cm3 In-Reply-To: <20100722085323.0nmmjnom94osso88@mail.elegosoft.com> References: <20100721155314.E1BC6CC389@birch.elegosoft.com>, , <20100722085323.0nmmjnom94osso88@mail.elegosoft.com> Message-ID: I thought it was too, before I looked at it. Could be that head and release are very divergent. I didn't look at release, oops. ? I probably will "soon". The config files are "partly part of the compiler", and partly system-specific. ?So they might have to be updated with the compiler. Perhaps we can have cm3.cfg.user or cm3.cfg.local, that we never edit, and maybe we should constrain it, like very line must have an equals sign, and if it has a percent, percent must follow equals. e.g. m3back_flags = "-custom" SYSTEM_CC = "custom" % comment blah blah SYSTEM_LIBS{"LIBC"} = "custom" SYSTEM_LIBORDER += [custom] But that might not be flexible enough. Another option is that cm3.cfg file do like: if exists("cm3.cfg.user.first") ? include("cm3.cfg.user.first") end ... if exists("cm3.cfg.user.last") ? include("cm3.cfg.user.last end which is infinitely flexible and not well defined. ?Even limiting to assignments is not well defined. ?You know, there's an interface somewhere in there, but it isn't well specified. My fault. ? I let things evolve and get discovered gradually, sometimes hard to know ahead of time what the result will be. ? I've made changes since 5.8.6 released such that config files from prior to 5.8.6 will not suffice. I can undo that, but there is an important policy and architecture question. ?- Jay ---------------------------------------- > Date: Thu, 22 Jul 2010 08:53:23 +0200 > From: wagner at elegosoft.com > To: m3commit at elegosoft.com > Subject: Re: [M3commit] CVS Update: cm3 > > Quoting Jay K : > > > I've manually updated the config files on SPARC32_LINUX Hudson node > > to try to fix this. > > That should be done by the upgrade script (and it already was AFAIR). > I wouldn't like the script shipping a newly built compiler to > unconditionally overwrite all my local configuration. > > Olaf > > > > > - Jay > > > > ---------------------------------------- > >> Date: Wed, 21 Jul 2010 17:53: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/07/21 17:53:14 > >> > >> Modified files: > >> cm3/scripts/: install-cm3-compiler.sh > >> > >> Log message: > >> upgrade config files when upgrading compiler > >> > > > > > > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 > From wagner at elegosoft.com Thu Jul 22 09:19:12 2010 From: wagner at elegosoft.com (Olaf Wagner) Date: Thu, 22 Jul 2010 09:19:12 +0200 Subject: [M3commit] CVS Update: cm3 In-Reply-To: References: <20100721155314.E1BC6CC389@birch.elegosoft.com>, , <20100722085323.0nmmjnom94osso88@mail.elegosoft.com> Message-ID: <20100722091912.bibr9p0z1q88wog4@mail.elegosoft.com> I can live with a cm3-local.cfg file which gets included when it exists, contains local overrides and is never touched by he installation. We have to be careful to backup existing configs and informing the users before the installation though. I think upgrade did backups of the config, too. Can you check the scripts in the release branch if anything needs to be merged back? I won't be able to do that today. Olaf Quoting Jay K : > I thought it was too, before I looked at it. > Could be that head and release are very divergent. > I didn't look at release, oops. > ? I probably will "soon". > > > The config files are "partly part of the compiler", and partly > system-specific. > ?So they might have to be updated with the compiler. > > > Perhaps we can have cm3.cfg.user or cm3.cfg.local, that we never edit, > and maybe we should constrain it, like very line > must have an equals sign, and if it has a percent, percent must > follow equals. > > > e.g. > m3back_flags = "-custom" > SYSTEM_CC = "custom" % comment blah blah > SYSTEM_LIBS{"LIBC"} = "custom" > SYSTEM_LIBORDER += [custom] > > But that might not be flexible enough. > > Another option is that cm3.cfg file do like: > if exists("cm3.cfg.user.first") > ? include("cm3.cfg.user.first") > end > ... > if exists("cm3.cfg.user.last") > > ? include("cm3.cfg.user.last > > end > > > > which is infinitely flexible and not well defined. > ?Even limiting to assignments is not well defined. > ?You know, there's an interface somewhere in there, but it isn't > well specified. My fault. > ? I let things evolve and get discovered gradually, sometimes hard > to know ahead of time what the result will be. > ? > > I've made changes since 5.8.6 released such that config files from > prior to 5.8.6 will not suffice. > I can undo that, but there is an important policy and architecture question. > > > ?- Jay > > ---------------------------------------- >> Date: Thu, 22 Jul 2010 08:53:23 +0200 >> From: wagner at elegosoft.com >> To: m3commit at elegosoft.com >> Subject: Re: [M3commit] CVS Update: cm3 >> >> Quoting Jay K : >> >> > I've manually updated the config files on SPARC32_LINUX Hudson node >> > to try to fix this. >> >> That should be done by the upgrade script (and it already was AFAIR). >> I wouldn't like the script shipping a newly built compiler to >> unconditionally overwrite all my local configuration. >> >> Olaf >> >> > >> > - Jay >> > >> > ---------------------------------------- >> >> Date: Wed, 21 Jul 2010 17:53: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/07/21 17:53:14 >> >> >> >> Modified files: >> >> cm3/scripts/: install-cm3-compiler.sh >> >> >> >> Log message: >> >> upgrade config files when upgrading compiler >> >> >> > >> >> >> >> -- >> Olaf Wagner -- elego Software Solutions GmbH >> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany >> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 >> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin >> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 >> > -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From jay.krell at cornell.edu Thu Jul 22 09:21:33 2010 From: jay.krell at cornell.edu (Jay K) Date: Thu, 22 Jul 2010 07:21:33 +0000 Subject: [M3commit] CVS Update: cm3 In-Reply-To: <20100722091912.bibr9p0z1q88wog4@mail.elegosoft.com> References: <20100721155314.E1BC6CC389@birch.elegosoft.com>, , , , <20100722085323.0nmmjnom94osso88@mail.elegosoft.com>, , <20100722091912.bibr9p0z1q88wog4@mail.elegosoft.com> Message-ID: (ps: the change I made does do the backup foo-date thing, parallel to cm3 and cm3cg yes I'll compare the branches, can't promise a full merge though) ---------------------------------------- > Date: Thu, 22 Jul 2010 09:19:12 +0200 > From: wagner at elegosoft.com > To: jay.krell at cornell.edu > CC: m3commit at elegosoft.com > Subject: Re: [M3commit] CVS Update: cm3 > > I can live with a cm3-local.cfg file which gets included when it exists, > contains local overrides and is never touched by he installation. > > We have to be careful to backup existing configs and informing the > users before the installation though. > > I think upgrade did backups of the config, too. > > Can you check the scripts in the release branch if anything needs > to be merged back? I won't be able to do that today. > > Olaf > > Quoting Jay K : > > > I thought it was too, before I looked at it. > > Could be that head and release are very divergent. > > I didn't look at release, oops. > > I probably will "soon". > > > > > > The config files are "partly part of the compiler", and partly > > system-specific. > > So they might have to be updated with the compiler. > > > > > > Perhaps we can have cm3.cfg.user or cm3.cfg.local, that we never edit, > > and maybe we should constrain it, like very line > > must have an equals sign, and if it has a percent, percent must > > follow equals. > > > > > > e.g. > > m3back_flags = "-custom" > > SYSTEM_CC = "custom" % comment blah blah > > SYSTEM_LIBS{"LIBC"} = "custom" > > SYSTEM_LIBORDER += [custom] > > > > But that might not be flexible enough. > > > > Another option is that cm3.cfg file do like: > > if exists("cm3.cfg.user.first") > > include("cm3.cfg.user.first") > > end > > ... > > if exists("cm3.cfg.user.last") > > > > include("cm3.cfg.user.last > > > > end > > > > > > > > which is infinitely flexible and not well defined. > > Even limiting to assignments is not well defined. > > You know, there's an interface somewhere in there, but it isn't > > well specified. My fault. > > I let things evolve and get discovered gradually, sometimes hard > > to know ahead of time what the result will be. > > > > > > I've made changes since 5.8.6 released such that config files from > > prior to 5.8.6 will not suffice. > > I can undo that, but there is an important policy and architecture question. > > > > > > - Jay > > > > ---------------------------------------- > >> Date: Thu, 22 Jul 2010 08:53:23 +0200 > >> From: wagner at elegosoft.com > >> To: m3commit at elegosoft.com > >> Subject: Re: [M3commit] CVS Update: cm3 > >> > >> Quoting Jay K : > >> > >> > I've manually updated the config files on SPARC32_LINUX Hudson node > >> > to try to fix this. > >> > >> That should be done by the upgrade script (and it already was AFAIR). > >> I wouldn't like the script shipping a newly built compiler to > >> unconditionally overwrite all my local configuration. > >> > >> Olaf > >> > >> > > >> > - Jay > >> > > >> > ---------------------------------------- > >> >> Date: Wed, 21 Jul 2010 17:53: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/07/21 17:53:14 > >> >> > >> >> Modified files: > >> >> cm3/scripts/: install-cm3-compiler.sh > >> >> > >> >> Log message: > >> >> upgrade config files when upgrading compiler > >> >> > >> > > >> > >> > >> > >> -- > >> Olaf Wagner -- elego Software Solutions GmbH > >> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > >> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 > >> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin > >> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 > >> > > > > > > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 > From jkrell at elego.de Thu Jul 22 15:51:06 2010 From: jkrell at elego.de (Jay Krell) Date: Thu, 22 Jul 2010 15:51:06 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100722135106.AF4EC2474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/22 15:51:06 Modified files: cm3/scripts/: install-cm3-compiler.sh Log message: fix insalling of config files, will require manual repair of Hudson nodes..but not, I should instead copy this code elsewhere to where Hudson will run it From jkrell at elego.de Thu Jul 22 16:01:26 2010 From: jkrell at elego.de (Jay Krell) Date: Thu, 22 Jul 2010 16:01:26 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100722140126.47A482474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/22 16:01:26 Modified files: cm3/scripts/regression/: defs.sh Log message: try repair missing config files From jkrell at elego.de Thu Jul 22 16:01:54 2010 From: jkrell at elego.de (Jay Krell) Date: Thu, 22 Jul 2010 16:01:54 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100722140154.41F972474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/22 16:01:54 Modified files: cm3/scripts/regression/: defs.sh Log message: try repair missing config files From jkrell at elego.de Thu Jul 22 16:59:48 2010 From: jkrell at elego.de (Jay Krell) Date: Thu, 22 Jul 2010 16:59:48 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100722145949.08E632474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/22 16:59:48 Modified files: cm3/m3-libs/m3core/src/time/POSIX/: TimePosixC.c Log message: Grain computation seems like a poorly implemented thing. I'm hoping we can replace it with something sysconf(?) or clock_getres. Experiments with clock_getres suggest no. It is often much larger than grain. Though it was close on Alpha/OSF I think. In the meantime: Historically we just computed grain once and accepted that value. Per the historical comment, that seemed not great. I changed it to loop until 2 or 3 grains were computed identically. I see this hang sometimes. Though seemingly only in slightly unusual situations like a cross build or Alpha/OSF or in a debugger. Anyway, let's try a different variation: Compute it a few times, and take the smallest value we find. I've tried up to 5 and it still varies from run to run on Alpha/OSF. So go down to just 3 since I can't win, and every computation takes time -- waiting for the time to progress. This still seems better than the historical behavior of one computation that might go very awry, and has the advantage over the replacement I had put in, which potentially could loop forever -- if grain was larger than scheduling interval, though nobody has reported that. From jkrell at elego.de Thu Jul 22 17:47:20 2010 From: jkrell at elego.de (Jay Krell) Date: Thu, 22 Jul 2010 17:47:20 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100722154721.92CABCC37E@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/22 17:47:20 Modified files: cm3/m3-sys/m3cc/gcc/gcc/: dse.c Log message: http://hudson.modula3.com:8080/job/cm3-current-m3cc-I386_DARWIN/2/consoleFull ../../gcc/gcc/dse.c:2766: warning: 'i' may be used uninitialized in this function From jkrell at elego.de Thu Jul 22 17:50:12 2010 From: jkrell at elego.de (Jay Krell) Date: Thu, 22 Jul 2010 17:50:12 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100722155013.5743F2474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/22 17:50:12 Modified files: cm3/m3-sys/m3cc/gcc/gcc/: ebitmap.c Log message: http://hudson.modula3.com:8080/job/cm3-current-m3cc-I386_DARWIN/2/consoleFull ebitmap.c: In function 'ebitmap_last_set_bit': ebitmap.c:89: warning: 'ebi.ptr' may be used uninitialized in this function ebitmap.c:89: warning: 'ebi.bit_num' may be used uninitialized in this function ebitmap.c:89: warning: 'ebi.eltnum' may be used uninitialized in this function ebitmap.c:89: warning: 'ebi.word' may be used uninitialized in this function ebitmap.h:124: warning: 'ourn' may be used uninitialized in this function ebitmap.c: In function 'ebitmap_ior_into': ebitmap.c:549: warning: 'i' may be used uninitialized in this function ebitmap.c: In function 'ebitmap_ior': ebitmap.c:673: warning: 'i' may be used uninitialized in this function ebitmap.c: In function 'ebitmap_and_compl': ebitmap.c:871: warning: 'i' may be used uninitialized in this function ebitmap.c: In function 'ebitmap_and_into': ebitmap.c:420: warning: 'i' may be used uninitialized in this function ebitmap.c: In function 'ebitmap_and': ebitmap.c:474: warning: 'i' may be used uninitialized in this function ebitmap.c: In function 'ebitmap_and_compl_into': ebitmap.c:791: warning: 'i' may be used uninitialized in this function From jkrell at elego.de Thu Jul 22 17:52:14 2010 From: jkrell at elego.de (Jay Krell) Date: Thu, 22 Jul 2010 17:52:14 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100722155214.B2DCF2474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/22 17:52:14 Modified files: cm3/m3-sys/m3cc/gcc/gcc/: tree-ssa-structalias.c Log message: http://hudson.modula3.com:8080/job/cm3-current-m3cc-I386_DARWIN/2/consoleFull tree-ssa-structalias.c:4811: warning: 'j' may be used uninitialized in this function From jkrell at elego.de Thu Jul 22 17:54:25 2010 From: jkrell at elego.de (Jay Krell) Date: Thu, 22 Jul 2010 17:54:25 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100722155425.C625C2474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/22 17:54:25 Modified files: cm3/m3-sys/m3cc/gcc/gcc/: ipa-struct-reorg.c Log message: http://hudson.modula3.com:8080/job/cm3-current-m3cc-I386_DARWIN/2/consoleFull ipa-struct-reorg.c:3540: warning: 'i' may be used uninitialized in this function From jkrell at elego.de Thu Jul 22 23:24:35 2010 From: jkrell at elego.de (Jay Krell) Date: Thu, 22 Jul 2010 23:24:35 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100722212435.F2CDB2474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/22 23:24:35 Modified files: cm3/m3-sys/m3cc/src/: m3makefile Log message: experiment that only affects SPARC32_LINUX From jkrell at elego.de Fri Jul 23 09:04:07 2010 From: jkrell at elego.de (Jay Krell) Date: Fri, 23 Jul 2010 9:04:07 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100723070407.9F30BCC37F@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/23 09:04:07 Modified files: cm3/m3-sys/cm3/test/src/: t.m3 Log message: Backward slashes confuse the test harness, so print them as tildes instead. From jkrell at elego.de Fri Jul 23 09:10:43 2010 From: jkrell at elego.de (Jay Krell) Date: Fri, 23 Jul 2010 9:10:43 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100723071044.C06E42474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/23 09:10:43 Modified files: cm3/m3-sys/cm3/test/src/: m3makefile Log message: build standalone From jkrell at elego.de Fri Jul 23 09:15:59 2010 From: jkrell at elego.de (Jay Krell) Date: Fri, 23 Jul 2010 9:15:59 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100723071600.83EA62474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/23 09:15:59 Modified files: cm3/m3-libs/patternmatching/tests/src/: m3makefile Log message: standalone From jkrell at elego.de Fri Jul 23 09:28:10 2010 From: jkrell at elego.de (Jay Krell) Date: Fri, 23 Jul 2010 9:28:10 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100723072847.8D8982474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/23 09:28:10 Modified files: cm3/m3-libs/patternmatching/tests/: tests.input Log message: Double backslash causing \x8 to appear in output. Comment out this case. (It works fine at the console, but not within Hudson.) From wagner at elego.de Fri Jul 23 18:08:12 2010 From: wagner at elego.de (Olaf Wagner) Date: Fri, 23 Jul 2010 18:08:12 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100723160815.7FCAA2474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: wagner at birch. 10/07/23 18:08:12 Modified files: cm3/scripts/: pkgmap.sh Log message: disabling non-working quote_xml for a while as in the release branch From wagner at elego.de Fri Jul 23 20:13:21 2010 From: wagner at elego.de (Olaf Wagner) Date: Fri, 23 Jul 2010 20:13:21 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100723181321.B2C082474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: wagner at birch. 10/07/23 20:13:21 Modified files: cm3/m3-sys/m3tests/: PkgTags cm3/m3-sys/m3tests/src/e0/e026/: stdout.build cm3/m3-sys/m3tests/src/r0/r004/: stderr.pgm Log message: merge some fixes from release branch From wagner at elego.de Fri Jul 23 20:14:24 2010 From: wagner at elego.de (Olaf Wagner) Date: Fri, 23 Jul 2010 20:14:24 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100723181424.636112474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: wagner at birch. 10/07/23 20:14:24 Modified files: cm3/m3-libs/sysutils/src/: FSUtils.m3 Log message: add OSError arguments to exception text From jkrell at elego.de Fri Jul 23 21:39:35 2010 From: jkrell at elego.de (Jay Krell) Date: Fri, 23 Jul 2010 21:39:35 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100723193935.59B3C2474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/23 21:39:35 Modified files: cm3/m3-libs/patternmatching/tests/: tests.input Log message: put back since Olaf removed broken xml quoting From jkrell at elego.de Fri Jul 23 21:41:34 2010 From: jkrell at elego.de (Jay Krell) Date: Fri, 23 Jul 2010 21:41:34 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100723194134.C48722474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/23 21:41:34 Modified files: cm3/m3-sys/cm3/test/src/: t.m3 Log message: put back since Olaf disabled the xml quoting From jkrell at elego.de Sat Jul 24 16:16:26 2010 From: jkrell at elego.de (Jay Krell) Date: Sat, 24 Jul 2010 16:16:26 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100724141626.49E402474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/24 16:16:26 Modified files: cm3/m3-libs/m3core/src/: m3core.h cm3/m3-libs/m3core/src/runtime/POSIX/: RTSignalC.c cm3/m3-libs/m3core/src/runtime/common/: RTProcessC.c cm3/m3-libs/m3core/src/thread/POSIX/: ThreadPosixC.c cm3/m3-libs/m3core/src/unix/Common/: m3makefile cm3/m3-sys/cminstall/src/config-no-install/: OpenBSD.common Added files: cm3/m3-libs/m3core/src/unix/Common/context/: m3makefile cm3/m3-libs/m3core/src/unix/Common/context/setjmp/: m3makefile context.h context.c Log message: restore jmpbuf munging for OpenBSD/i386, from 5.8.6 release There is code here for other platforms but it isn't used. There is code here for other OpenBSD platforms, but isn't used currectly. It might be good to smush the unix/setjmp directory into thread/POSIX/openbsd_context.[ch]. It *is* in a sense "unix", because it adheres to the Posix make/get/set/swapcontext functions, except I rename them and the header. From jkrell at elego.de Sat Jul 24 16:26:06 2010 From: jkrell at elego.de (Jay Krell) Date: Sat, 24 Jul 2010 16:26:06 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100724142606.D11742474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/24 16:26:06 Modified files: cm3/m3-sys/m3tests/src/p2/p240/: m3makefile Log message: maybe fix flags on this file? (no diff) From jkrell at elego.de Sat Jul 24 16:27:17 2010 From: jkrell at elego.de (Jay Krell) Date: Sat, 24 Jul 2010 16:27:17 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100724142717.DADCC2474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/24 16:27:17 Modified files: cm3/m3-sys/m3tests/src/p2/p230/: m3makefile Log message: maybe fix flags on this file? (no diff, I had an at sign in ls -l)) From jkrell at elego.de Sat Jul 24 16:27:55 2010 From: jkrell at elego.de (Jay Krell) Date: Sat, 24 Jul 2010 16:27:55 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100724142755.1EDC22474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/24 16:27:55 Modified files: cm3/m3-sys/m3tests/src/: m3makefile Log message: maybe fix flags on this file? (no diff, I had an at sign in ls -l)) From jkrell at elego.de Sat Jul 24 16:28:32 2010 From: jkrell at elego.de (Jay Krell) Date: Sat, 24 Jul 2010 16:28:32 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100724142832.49A302474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/24 16:28:32 Modified files: cm3/m3-sys/m3tests/src/p2/p242/: m3makefile Main.m3 Log message: maybe fix flags on this file? (no diff, I had an at sign in ls -l)) From jkrell at elego.de Sat Jul 24 16:29:15 2010 From: jkrell at elego.de (Jay Krell) Date: Sat, 24 Jul 2010 16:29:15 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100724142915.5EF7F2474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/24 16:29:15 Modified files: cm3/m3-sys/m3tests/src/p2/p243/: m3makefile Main.m3 Log message: maybe fix flags on this file? (no diff, I had an at sign in ls -l)) From jkrell at elego.de Sat Jul 24 16:29:55 2010 From: jkrell at elego.de (Jay Krell) Date: Sat, 24 Jul 2010 16:29:55 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100724142957.9CC1F2474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/24 16:29:55 Modified files: cm3/m3-sys/m3tests/src/p2/p244/: m3makefile Main.m3 Log message: maybe fix flags on this file? (no diff, I had an at sign in ls -l)) From jkrell at elego.de Sat Jul 24 16:30:25 2010 From: jkrell at elego.de (Jay Krell) Date: Sat, 24 Jul 2010 16:30:25 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100724143025.DDFFA2474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/24 16:30:25 Modified files: cm3/m3-sys/m3tests/src/p2/p246/: m3makefile Main.m3 Log message: maybe fix flags on this file? (no diff, I had an at sign in ls -l)) From jkrell at elego.de Sat Jul 24 16:33:16 2010 From: jkrell at elego.de (Jay Krell) Date: Sat, 24 Jul 2010 16:33:16 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100724143316.86F3B2474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/24 16:33:16 Modified files: cm3/m3-sys/m3cc/gcc/gcc/: tree-ssa-forwprop.c Log message: tree-ssa-forwprop.c: In function `forward_propagate_into_cond': tree-ssa-forwprop.c:362: warning: `name' might be used uninitialized in this function From hosking at cs.purdue.edu Sat Jul 24 19:42:06 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sat, 24 Jul 2010 13:42:06 -0400 Subject: [M3commit] CVS Update: cm3 In-Reply-To: <20100724143316.86F3B2474003@birch.elegosoft.com> References: <20100724143316.86F3B2474003@birch.elegosoft.com> Message-ID: <10A6AF46-03F8-4FE5-9833-BC22FE161758@cs.purdue.edu> Do we really want to dirty the gcc diffs from the original sources in this way. It will make sifting the diffs a nightmare for future ports. 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 24 Jul 2010, at 16:33, Jay Krell wrote: > CVSROOT: /usr/cvs > Changes by: jkrell at birch. 10/07/24 16:33:16 > > Modified files: > cm3/m3-sys/m3cc/gcc/gcc/: tree-ssa-forwprop.c > > Log message: > tree-ssa-forwprop.c: In function `forward_propagate_into_cond': > tree-ssa-forwprop.c:362: warning: `name' might be used uninitialized in this function -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sun Jul 25 03:57:55 2010 From: jay.krell at cornell.edu (Jay K) Date: Sun, 25 Jul 2010 01:57:55 +0000 Subject: [M3commit] CVS Update: cm3 In-Reply-To: <10A6AF46-03F8-4FE5-9833-BC22FE161758@cs.purdue.edu> References: <20100724143316.86F3B2474003@birch.elegosoft.com>, <10A6AF46-03F8-4FE5-9833-BC22FE161758@cs.purdue.edu> Message-ID: I'm pretty sure the three way merge I did will tolerate it ok. A human should tolerate it easily too. I don't look through the CVS history to find the diffs, I diff against baseline gcc 4.3.0, 4.3.5, etc. ? (btw, in doing so, I found another label thing we did, have to come back to 4.5.0 work soon..) But if you insist, ok. ?- Jay ________________________________ > From: hosking at cs.purdue.edu > Date: Sat, 24 Jul 2010 13:42:06 -0400 > To: jkrell at elego.de > CC: m3commit at elegosoft.com > Subject: Re: [M3commit] CVS Update: cm3 > > Do we really want to dirty the gcc diffs from the original sources in > this way. It will make sifting the diffs a nightmare for future ports. > > 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 24 Jul 2010, at 16:33, Jay Krell wrote: > > CVSROOT: /usr/cvs > Changes by: jkrell at birch. 10/07/24 16:33:16 > > Modified files: > cm3/m3-sys/m3cc/gcc/gcc/: tree-ssa-forwprop.c > > Log message: > tree-ssa-forwprop.c: In function `forward_propagate_into_cond': > tree-ssa-forwprop.c:362: warning: `name' might be used uninitialized in > this function > From jkrell at elego.de Sun Jul 25 13:52:25 2010 From: jkrell at elego.de (Jay Krell) Date: Sun, 25 Jul 2010 13:52:25 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100725115225.ED7532474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/25 13:52:25 Added files: cm3/m3-libs/m3core/src/unix/Common/context/setjmp/: config.c tcontext.c Makefile Log message: bring back deleted files From jkrell at elego.de Mon Jul 26 08:40:22 2010 From: jkrell at elego.de (Jay Krell) Date: Mon, 26 Jul 2010 8:40:22 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100726064022.4A981CC397@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/26 08:40:22 Modified files: cm3/m3-libs/m3core/src/unix/Common/context/setjmp/: Makefile config.c context.c context.h tcontext.c Added files: cm3/m3-libs/m3core/src/unix/Common/context/setjmp/: context_mips64.s Log message: adapt to MIPS64EL_OPENBSD (Gdium laptop, Loongson processor) From jkrell at elego.de Mon Jul 26 10:24:47 2010 From: jkrell at elego.de (Jay Krell) Date: Mon, 26 Jul 2010 10:24:47 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100726082447.B356DCC37E@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/26 10:24:47 Added files: cm3/m3-libs/m3core/src/thread/PTHREAD/: ThreadOpenBSD.c Log message: let's revisit pthreads on OpenBSD From jkrell at elego.de Mon Jul 26 10:34:08 2010 From: jkrell at elego.de (Jay Krell) Date: Mon, 26 Jul 2010 10:34:08 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100726083409.02B7F2474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/26 10:34:08 Modified files: cm3/m3-libs/m3core/src/: m3makefile Removed files: cm3/m3-libs/m3core/src/: platforms.quake Log message: remove platforms lists -- the data comes from each platform's config file now From jkrell at elego.de Mon Jul 26 13:50:14 2010 From: jkrell at elego.de (Jay Krell) Date: Mon, 26 Jul 2010 13:50:14 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100726115014.D2D432474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/26 13:50:14 Modified files: cm3/m3-libs/m3core/src/thread/PTHREAD/: ThreadOpenBSD.c ThreadPThreadC.c m3makefile Log message: Hypothetical fixes for OpenBSD to use pthreads. It compiles and links, but then I get assertion failures in RTCollector.m3. Not going to debug it for now, for a while. From jkrell at elego.de Mon Jul 26 13:51:52 2010 From: jkrell at elego.de (Jay Krell) Date: Mon, 26 Jul 2010 13:51:52 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100726115152.C1ABB2474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/26 13:51:52 Modified files: cm3/m3-libs/m3core/src/thread/PTHREAD/: test_interix.c Log message: add comment to the top explaining the file From jkrell at elego.de Mon Jul 26 13:53:40 2010 From: jkrell at elego.de (Jay Krell) Date: Mon, 26 Jul 2010 13:53:40 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100726115340.D84082474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/26 13:53:40 Modified files: cm3/m3-libs/m3core/src/thread/PTHREAD/: ThreadFreeBSD.c Log message: add a comment explaining what I believe is a true deficiency of this code: it scans the entire stack, not just the part starting at the current stack pointer From jkrell at elego.de Mon Jul 26 13:55:17 2010 From: jkrell at elego.de (Jay Krell) Date: Mon, 26 Jul 2010 13:55:17 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100726115517.D6C8CCC37E@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/26 13:55:17 Modified files: cm3/m3-sys/cminstall/src/config-no-install/: OpenBSD.common Log message: Stop using -static. It breaks pthreads. Pthreads appear to have other (not debugged) problems so I'm not using them anyway, but what I found just makes me more nervous about -static. The reason -static was used here is that OpenBSD is apparently aggressive about breaking things from release to release. In particular, like, libc.so gets renamed every time From jkrell at elego.de Mon Jul 26 14:12:32 2010 From: jkrell at elego.de (Jay Krell) Date: Mon, 26 Jul 2010 14:12:32 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100726121232.87690CC37E@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/26 14:12:32 Modified files: cm3/m3-libs/m3core/src/unix/Common/context/setjmp/: Makefile context.c Log message: restore OpenBSD/powerpc to working From jkrell at elego.de Mon Jul 26 14:31:09 2010 From: jkrell at elego.de (Jay Krell) Date: Mon, 26 Jul 2010 14:31:09 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100726123109.8168BCC37E@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/26 14:31:09 Modified files: cm3/m3-libs/m3core/src/thread/PTHREAD/: ThreadPThreadC.c Log message: tweak the OpenBSD fix (resolving diffs across my machines) From jkrell at elego.de Mon Jul 26 14:34:22 2010 From: jkrell at elego.de (Jay Krell) Date: Mon, 26 Jul 2010 14:34:22 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100726123422.A3B93CC37E@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/26 14:34:22 Modified files: cm3/m3-libs/m3core/src/: m3makefile cm3/m3-libs/m3core/src/thread/: m3makefile Removed files: cm3/m3-libs/m3core/src/: thread.quake Log message: Tweak the determination of user threads vs. pthreads. The logic is: NT, Win32, Mingw, Cygwin => Win32 FreeBSD4 (really, 4, not I386_FREEBSD), OpenBSD => user threads -DNOPTHREAD => user threads else => pthreads There is no longer a list of platforms, but one can easily add it here, using ({"plat1", "plat2"} contains TARGET) or such. As well, the config files should probably say, e.g.: ThreadLibrary = "user" or PosixUserThreads = TRUE Really, in the config files. Though src/m3makefile might warn/error for known not to work things like user threads on NT for example. From jkrell at elego.de Mon Jul 26 15:03:55 2010 From: jkrell at elego.de (Jay Krell) Date: Mon, 26 Jul 2010 15:03:55 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100726130355.48D2A2474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/26 15:03:55 Modified files: cm3/m3-sys/m3cc/src/: platforms.quake Log message: remove duplicate PPC64_DARWIN, and add version '6' to the end of it From jkrell at elego.de Mon Jul 26 15:14:40 2010 From: jkrell at elego.de (Jay Krell) Date: Mon, 26 Jul 2010 15:14:40 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100726131441.006C92474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/26 15:14:40 Modified files: cm3/m3-sys/cminstall/src/config-no-install/: MIPS64_OPENBSD Log message: just comments/whitespace From jkrell at elego.de Mon Jul 26 15:15:41 2010 From: jkrell at elego.de (Jay Krell) Date: Mon, 26 Jul 2010 15:15:41 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100726131541.814CECC37F@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/26 15:15:41 Modified files: cm3/m3-sys/cminstall/src/config-no-install/: MIPS64_OPENBSD Log message: actually previous had an important typo fix as well: 'table' vs. 'tables', to actually disable the tables, which the generation of leads to assertion failures in the backend, for this target (and its little endian sibling) From jkrell at elego.de Mon Jul 26 15:30:09 2010 From: jkrell at elego.de (Jay Krell) Date: Mon, 26 Jul 2010 15:30:09 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100726133009.A4B652474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/26 15:30:09 Modified files: cm3/m3-libs/m3core/src/unix/Common/context/setjmp/: m3makefile Log message: compile this for all OpenBSD platforms (granted, sparc64 not tested in a while, amd64 maybe never finished? but mips64, powerpc, x86 appear good; need to try sigaltstack again though) From jkrell at elego.de Mon Jul 26 15:40:14 2010 From: jkrell at elego.de (Jay Krell) Date: Mon, 26 Jul 2010 15:40:14 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100726134014.5D94F2474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/26 15:40:14 Modified files: cm3/m3-sys/cminstall/src/config-no-install/: OpenBSD.common Log message: remove X11 libraries that I think were only needed if using -static From jkrell at elego.de Mon Jul 26 15:42:31 2010 From: jkrell at elego.de (Jay Krell) Date: Mon, 26 Jul 2010 15:42:31 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100726134231.6E0832474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/26 15:42:31 Modified files: cm3/m3-sys/cminstall/src/config-no-install/: Interix.common PPC32_OPENBSD Unix.common Log message: disable shared on PPC32_OPENBSD, it has problems move the disabling of shared on Interix to Interix.common instead of having Unix.common know about it, by making there be another function interfacing among the config files: proc AdjustShared(shared) takes a boolean as to if shared was requested and returns a boolean as to if should really be shared. e.g.: false on Interix and PPC32_OPENBSD the default is false if using an older cm3 else whatever is input on curent cm3 ("older" is defined by probing for a symbol added in 5.8.6); this is more relevant if mixing current config files with older cm3, which historically I have often done, though it can be problematic From jkrell at elego.de Mon Jul 26 15:44:59 2010 From: jkrell at elego.de (Jay Krell) Date: Mon, 26 Jul 2010 15:44:59 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100726134459.CD4E32474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/26 15:44:59 Modified files: cm3/m3-libs/m3core/src/atomic/: m3makefile cm3/m3-libs/m3core/src/runtime/common/: Compiler.tmpl cm3/m3-libs/m3core/src/unix/Common/context/setjmp/: m3makefile cm3/m3-sys/m3cc/src/: platforms.quake cm3/m3-sys/m3middle/src/: Target.i3 Target.m3 cm3/scripts/: sysinfo.sh cm3/scripts/python/: pylib.py Added files: cm3/m3-libs/m3core/src/C/MIPS64EL_OPENBSD/: Csetjmp.i3 m3makefile cm3/m3-sys/cminstall/src/config-no-install/: MIPS64EL_OPENBSD Log message: add MIPS64EL_OPENBSD (e.g. Loongon/Gdium/Lemote) complete with: no atomics for 1 byte or 2 bytes no unwind tables (internal compiler error) These are for hypothetical future better exception handling, so ok. no debug symbols (there was a problem?) Should try again. user mode threads and worse, jmpbuf hacking need to try again the sigaltstack approach no Java => no Hudson Enough to build a cm3 that reports the expected "unable to find cm3.cfg". see: http://www.openbsd.org/loongson.html search web for: "Amazon gdium" etc. Presumably MIPS64EL_LINUX will fair a bit better. From jay.krell at cornell.edu Mon Jul 26 15:48:06 2010 From: jay.krell at cornell.edu (Jay K) Date: Mon, 26 Jul 2010 13:48:06 +0000 Subject: [M3commit] CVS Update: cm3 In-Reply-To: <20100726134459.CD4E32474003@birch.elegosoft.com> References: <20100726134459.CD4E32474003@birch.elegosoft.com> Message-ID: attached ---------------------------------------- > Date: Mon, 26 Jul 2010 15:44: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/07/26 15:44:59 > > Modified files: > cm3/m3-libs/m3core/src/atomic/: m3makefile > cm3/m3-libs/m3core/src/runtime/common/: Compiler.tmpl > cm3/m3-libs/m3core/src/unix/Common/context/setjmp/: m3makefile > cm3/m3-sys/m3cc/src/: platforms.quake > cm3/m3-sys/m3middle/src/: Target.i3 Target.m3 > cm3/scripts/: sysinfo.sh > cm3/scripts/python/: pylib.py > Added files: > cm3/m3-libs/m3core/src/C/MIPS64EL_OPENBSD/: Csetjmp.i3 > m3makefile > cm3/m3-sys/cminstall/src/config-no-install/: MIPS64EL_OPENBSD > > Log message: > add MIPS64EL_OPENBSD (e.g. Loongon/Gdium/Lemote) > complete with: > no atomics for 1 byte or 2 bytes > no unwind tables (internal compiler error) > These are for hypothetical future better exception handling, so ok. > no debug symbols (there was a problem?) > Should try again. > user mode threads > and worse, jmpbuf hacking > need to try again the sigaltstack approach > no Java => no Hudson > > Enough to build a cm3 that reports the expected "unable to find cm3.cfg". > > see: > http://www.openbsd.org/loongson.html > search web for: "Amazon gdium" > etc. > > Presumably MIPS64EL_LINUX will fair a bit better. > -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: mips64el_openbsd.txt URL: From wagner at elego.de Tue Jul 27 07:21:20 2010 From: wagner at elego.de (Olaf Wagner) Date: Tue, 27 Jul 2010 7:21:20 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100727052120.50A7D2474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: wagner at birch. 10/07/27 07:21:20 Modified files: cm3/m3-sys/m3tests/src/: m3makefile Log message: list build dir before removal From jkrell at elego.de Tue Jul 27 08:51:53 2010 From: jkrell at elego.de (Jay Krell) Date: Tue, 27 Jul 2010 8:51:53 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100727065153.C7D342474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/27 08:51:53 Added files: cm3/m3-libs/m3core/src/thread/POSIX/: test_thread_sigaltstack.c Log message: add test case, it only hangs on OpenBSD with -pthread!" From jkrell at elego.de Tue Jul 27 08:58:56 2010 From: jkrell at elego.de (Jay Krell) Date: Tue, 27 Jul 2010 8:58:56 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100727065856.8BA362474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/27 08:58:56 Modified files: cm3/m3-libs/m3core/src/thread/POSIX/: test_thread_sigaltstack.c Log message: reduce From jkrell at elego.de Wed Jul 28 12:32:51 2010 From: jkrell at elego.de (Jay Krell) Date: Wed, 28 Jul 2010 12:32:51 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100728103310.D81982474006@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/28 12:32:51 Modified files: cm3/m3-libs/m3core/src/thread/: m3makefile Log message: copy in stuff from cm3cfg.common, until it is updated From jkrell at elego.de Wed Jul 28 13:01:29 2010 From: jkrell at elego.de (Jay Krell) Date: Wed, 28 Jul 2010 13:01:29 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100728110129.D9C8CCC37E@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/28 13:01:29 Modified files: cm3/m3-libs/sysutils/src/: FSUtils.m3 Log message: add some debugprint From jkrell at elego.de Wed Jul 28 13:03:15 2010 From: jkrell at elego.de (Jay Krell) Date: Wed, 28 Jul 2010 13:03:15 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100728110315.9C8F6CC37F@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/28 13:03:15 Modified files: cm3/m3-libs/sysutils/src/: FSUtils.m3 Log message: add more debugprint From jkrell at elego.de Wed Jul 28 13:10:22 2010 From: jkrell at elego.de (Jay Krell) Date: Wed, 28 Jul 2010 13:10:22 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100728111022.9AB6A2474006@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/28 13:10:22 Modified files: cm3/m3-sys/m3cc/src/: m3makefile Log message: just because it is what other code did, get just the leaf name and form the full path ourselves (this is related to rmrec failures) From jkrell at elego.de Wed Jul 28 13:22:40 2010 From: jkrell at elego.de (Jay Krell) Date: Wed, 28 Jul 2010 13:22:40 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100728112240.735B32474006@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/28 13:22:40 Modified files: cm3/m3-sys/m3cc/src/: m3makefile Log message: manually delete gmp with exec(rm -rf) From jkrell at elego.de Wed Jul 28 13:23:09 2010 From: jkrell at elego.de (Jay Krell) Date: Wed, 28 Jul 2010 13:23:09 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100728112309.71F972474006@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/28 13:23:09 Modified files: cm3/m3-sys/m3cc/src/: m3makefile Log message: add comment to the exec(rm -rf gmp) From jkrell at elego.de Wed Jul 28 14:02:56 2010 From: jkrell at elego.de (Jay Krell) Date: Wed, 28 Jul 2010 14:02:56 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100728120258.5A3F62474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/28 14:02:56 Modified files: cm3/m3-sys/m3cc/src/: m3makefile Log message: m3makefile From jkrell at elego.de Wed Jul 28 14:04:02 2010 From: jkrell at elego.de (Jay Krell) Date: Wed, 28 Jul 2010 14:04:02 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100728120441.BC29A2474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/28 14:04:02 Modified files: cm3/m3-sys/m3cc/src/: m3makefile Log message: flubbed previous commit, comment was to be: sparc32_linux: remove the configure -with-cpu=v8 put back -target=sparc-linux config file will and needs to say -mcpu=v9 (tested via gcc -mcpu=v8 and -mcpu=v9 and using an atomic function) My Debian gcc 4.3 was configured as: --with-cpu=v8 --with-long-double-128 --build=sparc-linux-gnu --host=sparc-linux-gnu --target=sparc-linux-gnu among others. (notice: -with-long-double-128 -- something we want for Modula-3 also..) From jkrell at elego.de Wed Jul 28 14:10:49 2010 From: jkrell at elego.de (Jay Krell) Date: Wed, 28 Jul 2010 14:10:49 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100728121049.9A5572474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/28 14:10:49 Modified files: cm3/m3-sys/m3cc/src/: m3makefile Log message: go back to full paths from fs_lsdirs/files From jkrell at elego.de Wed Jul 28 14:14:42 2010 From: jkrell at elego.de (Jay Krell) Date: Wed, 28 Jul 2010 14:14:42 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100728121447.ED8DF2474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/28 14:14:42 Modified files: cm3/scripts/: install-cm3-compiler.sh Log message: try set -e; set -x here, so we can see e.g. upgrading the compiler upgrade the config files From jay.krell at cornell.edu Wed Jul 28 14:20:43 2010 From: jay.krell at cornell.edu (Jay K) Date: Wed, 28 Jul 2010 12:20:43 +0000 Subject: [M3commit] CVS Update: cm3 In-Reply-To: <20100728120441.BC29A2474003@birch.elegosoft.com> References: <20100728120441.BC29A2474003@birch.elegosoft.com> Message-ID: And even this comment was wrong: it had said -with-cpu=v9 not v8. ?- Jay ---------------------------------------- > Date: Wed, 28 Jul 2010 14:04:02 +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/07/28 14:04:02 > > Modified files: > cm3/m3-sys/m3cc/src/: m3makefile > > Log message: > flubbed previous commit, comment was to be: > sparc32_linux: remove the configure -with-cpu=v8 > put back -target=sparc-linux > > config file will and needs to say -mcpu=v9 > (tested via gcc -mcpu=v8 and -mcpu=v9 and using an atomic function) > > My Debian gcc 4.3 was configured as: > --with-cpu=v8 --with-long-double-128 --build=sparc-linux-gnu --host=sparc-linux-gnu --target=sparc-linux-gnu > > among others. (notice: -with-long-double-128 -- something we want for Modula-3 also..) > From jkrell at elego.de Wed Jul 28 14:28:37 2010 From: jkrell at elego.de (Jay Krell) Date: Wed, 28 Jul 2010 14:28:37 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100728122848.8145F2474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/28 14:28:37 Modified files: cm3/doc/notes/: todo.txt Log message: some updates From jkrell at elego.de Wed Jul 28 14:31:15 2010 From: jkrell at elego.de (Jay Krell) Date: Wed, 28 Jul 2010 14:31:15 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100728123122.2871ECC110@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/28 14:31:15 Modified files: cm3/doc/notes/: todo.txt Log message: some updates From jkrell at elego.de Wed Jul 28 14:32:14 2010 From: jkrell at elego.de (Jay Krell) Date: Wed, 28 Jul 2010 14:32:14 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100728123224.51325CC110@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/28 14:32:14 Modified files: cm3/doc/notes/: todo.txt Log message: mention android and iphone From jkrell at elego.de Wed Jul 28 14:33:23 2010 From: jkrell at elego.de (Jay Krell) Date: Wed, 28 Jul 2010 14:33:23 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100728123348.A112FCC110@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/28 14:33:23 Modified files: cm3/doc/notes/: todo.txt Log message: mention AIX: ppc32, ppc64 From jkrell at elego.de Wed Jul 28 16:07:27 2010 From: jkrell at elego.de (Jay Krell) Date: Wed, 28 Jul 2010 16:07:27 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100728140727.C071E2474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/28 16:07:27 Modified files: cm3/scripts/: install-cm3-compiler.sh Log message: don't set -e/x, use echo instead, cp fails, I think, because of the CVS directory From jkrell at elego.de Wed Jul 28 16:19:46 2010 From: jkrell at elego.de (Jay Krell) Date: Wed, 28 Jul 2010 16:19:46 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100728142007.313242474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/28 16:19:46 Modified files: cm3/m3-sys/cm3/src/: M3Build.m3 Log message: remove the "ignoring override" print out, I think few people know it means and fewer (nobody) finds it useful From jkrell at elego.de Wed Jul 28 16:22:03 2010 From: jkrell at elego.de (Jay Krell) Date: Wed, 28 Jul 2010 16:22:03 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100728142204.996F52474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/28 16:22:03 Modified files: cm3/m3-sys/cm3/src/: M3Build.m3 Log message: remove more of the code for: remove the "ignoring override" print out, I think few people know it means and fewer (nobody) finds it useful From jkrell at elego.de Wed Jul 28 16:47:12 2010 From: jkrell at elego.de (Jay Krell) Date: Wed, 28 Jul 2010 16:47:12 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100728144713.27FD82474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/28 16:47:12 Modified files: cm3/m3-sys/m3cc/src/: m3makefile Log message: sparc32_linux: fixed, now an experiment, specific to it, I kind of want to *not* specific host, so that a cross build isn't detected, so that autoconf will do its usual stuff From jkrell at elego.de Wed Jul 28 18:08:17 2010 From: jkrell at elego.de (Jay Krell) Date: Wed, 28 Jul 2010 18:08:17 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100728160817.9B0EA2474006@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/28 18:08:17 Modified files: cm3/caltech-parser/drawcontext/test/: .cvsignore cm3/caltech-parser/parserlib/parserlib/test/: .cvsignore cm3/m3-db/db/test/: .cvsignore cm3/m3-db/odbc/test/: .cvsignore cm3/m3-db/postgres95/test/: .cvsignore cm3/m3-db/stable/test/: .cvsignore cm3/m3-libs/arithmetic/test/: .cvsignore cm3/m3-libs/bitvector/test/: .cvsignore cm3/m3-libs/patternmatching/tests/: .cvsignore cm3/m3-libs/slisp/tests/: .cvsignore Added files: cm3/m3-comm/udp/test/: .cvsignore cm3/m3-libs/binIO/test/: .cvsignore cm3/m3-libs/libm3/tests/: .cvsignore cm3/m3-sys/cm3/test/: .cvsignore cm3/m3-sys/m3quake/test/: .cvsignore Log message: .cvsignore files From jkrell at elego.de Wed Jul 28 18:09:14 2010 From: jkrell at elego.de (Jay Krell) Date: Wed, 28 Jul 2010 18:09:14 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100728160914.8754FCC110@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/28 18:09:14 Modified files: cm3/scripts/: .cvsignore Log message: add PKGS to .cvsignore From jkrell at elego.de Wed Jul 28 18:10:50 2010 From: jkrell at elego.de (Jay Krell) Date: Wed, 28 Jul 2010 18:10:50 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100728161050.332242474006@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/28 18:10:50 Added files: cm3/: .cvsignore Log message: we drop date.c and m3date in the root: .cvsignore From jkrell at elego.de Wed Jul 28 19:29:45 2010 From: jkrell at elego.de (Jay Krell) Date: Wed, 28 Jul 2010 19:29:45 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100728172945.24401CC38A@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/28 19:29:45 Modified files: cm3/m3-sys/cminstall/src/config-no-install/: MIPS64EL_OPENBSD Unix.common Log message: There seems to be no odbc for MIPS64EL_OPENBSD. So, new interface among the config files: proc HasOdbc() return boolean Default is true. MIPS64EL_OPENBSD provides implementation that always returns false. Guides creation of default SYSTEM_LIBS and SYSTEM_LIBORDER. If we could remove elements from an array and table, that would be a better mechanism perhaps. From jkrell at elego.de Wed Jul 28 19:47:45 2010 From: jkrell at elego.de (Jay Krell) Date: Wed, 28 Jul 2010 19:47:45 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100728174745.563F22474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/28 19:47:45 Modified files: cm3/m3-sys/cminstall/src/config-no-install/: Unix.common Log message: huh? fix SYSTEM_LIBORDER From jkrell at elego.de Wed Jul 28 20:05:08 2010 From: jkrell at elego.de (Jay Krell) Date: Wed, 28 Jul 2010 20:05:08 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100728180508.64AA8CC37F@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/28 20:05:08 Modified files: cm3/m3-libs/m3core/src/unix/Common/context/setjmp/: context.c Log message: remove OpenBSD/powerpc hack that no longer seems necessary From jkrell at elego.de Wed Jul 28 21:00:30 2010 From: jkrell at elego.de (Jay Krell) Date: Wed, 28 Jul 2010 21:00:30 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100728190030.8DE142474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/28 21:00:30 Modified files: cm3/doc/notes/: todo.txt Log message: add new_adr, reliable stacks for assertion failure From jkrell at elego.de Wed Jul 28 21:02:45 2010 From: jkrell at elego.de (Jay Krell) Date: Wed, 28 Jul 2010 21:02:45 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100728190246.01B9E2474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/28 21:02:45 Modified files: cm3/m3-sys/cminstall/src/config-no-install/: PPC32_OPENBSD Log message: enable sharing on OpenBSD/powerpc -- using -fpic instead of -fPIC was the key, though that doesn't make sense to me and I didn't debug it From jkrell at elego.de Wed Jul 28 21:09:46 2010 From: jkrell at elego.de (Jay Krell) Date: Wed, 28 Jul 2010 21:09:46 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100728190947.3C2DACC37F@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/28 21:09:46 Modified files: cm3/m3-games/tetris/src/: m3makefile Log message: disable on MIPS64EL_OPENBSD due to: /usr/bin/ld: not enough GOT space for local GOT entries /usr/bin/ld: BFD 2.15 internal error, aborting at /usr/src/gnu/usr.bin/binutils/bfd/elfxx-mips.c line 6483 in _bfd_mips_elf_relocate_section /usr/bin/ld: Please report this bug. F From jkrell at elego.de Wed Jul 28 22:40:09 2010 From: jkrell at elego.de (Jay Krell) Date: Wed, 28 Jul 2010 22:40:09 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100728204010.1CF84CC38A@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/28 22:40:09 Modified files: cm3/m3-libs/m3core/src/unix/Common/context/setjmp/: context.c Removed files: cm3/m3-libs/m3core/src/unix/Common/context/setjmp/: context_mips64.s Log message: much better fix for mips don't access any globals (including functions) in internal_setcontext only access parameters (we can pass anything we need) This way, the code is correctly position independent and works in shared libraries. Before, anything shared would crash. As a bonus, though we have to write slightly unusual C, we don't need any assembly. Now, Juno works! From jkrell at elego.de Wed Jul 28 22:47:52 2010 From: jkrell at elego.de (Jay Krell) Date: Wed, 28 Jul 2010 22:47:52 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100728204753.1EFA2CC38A@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/28 22:47:52 Modified files: cm3/m3-libs/m3core/src/unix/Common/context/setjmp/: m3makefile Log message: forgot m3makefile, I had edited on the actual mips machine From jkrell at elego.de Wed Jul 28 23:02:08 2010 From: jkrell at elego.de (Jay Krell) Date: Wed, 28 Jul 2010 23:02:08 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100728210212.30F98CC37E@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/28 23:02:08 Modified files: cm3/m3-sys/m3cc/src/: m3makefile Log message: go back to being explicit about sparc32_linux target (see http://hudson.modula3.com:8080/job/cm3-current-build-SPARC32_LINUX/38/console; one would think -m32 would make this not matter) From jkrell at elego.de Wed Jul 28 23:15:23 2010 From: jkrell at elego.de (Jay Krell) Date: Wed, 28 Jul 2010 23:15:23 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100728211523.AEAFF2474008@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/28 23:15:23 Modified files: cm3/m3-sys/m3quake/src/: QMachine.m3 Log message: more diagnostics for rmrec problem From jkrell at elego.de Wed Jul 28 23:17:32 2010 From: jkrell at elego.de (Jay Krell) Date: Wed, 28 Jul 2010 23:17:32 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100728211732.28E232474008@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/28 23:17:32 Modified files: cm3/m3-sys/m3cc/src/: m3makefile Log message: more bogosity because rmrec fails From jkrell at elego.de Wed Jul 28 23:19:27 2010 From: jkrell at elego.de (Jay Krell) Date: Wed, 28 Jul 2010 23:19:27 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100728211927.E751C2474008@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/28 23:19:27 Modified files: cm3/m3-libs/sysutils/src/: FSUtils.m3 Log message: more diagnostics From jkrell at elego.de Thu Jul 29 14:42:13 2010 From: jkrell at elego.de (Jay Krell) Date: Thu, 29 Jul 2010 14:42:13 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100729124213.D9FD52474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/29 14:42:13 Modified files: cm3/m3-sys/cminstall/src/config-no-install/: OpenBSD.common Log message: Oops: OpenBSD up to and including 4.7 seems to have no $ORIGIN support. It has ld -z origin, but that's it. OpenBSD users should either set LD_LIBRARY_PATH or rebuild themselves. Under consideration, given time, is a new distribution form where users will configure (autoconf), assemble, compile C, link, install. And probably build m3cc themselves too. From jkrell at elego.de Thu Jul 29 15:10:33 2010 From: jkrell at elego.de (Jay Krell) Date: Thu, 29 Jul 2010 15:10:33 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100729131033.0E9EC2474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/29 15:10:33 Modified files: cm3/doc/notes/: todo.txt Log message: describe new sourcey distribution format From jkrell at elego.de Thu Jul 29 15:23:04 2010 From: jkrell at elego.de (Jay Krell) Date: Thu, 29 Jul 2010 15:23:04 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100729132304.8F8A42474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/29 15:23:04 Modified files: cm3/m3-sys/m3tests/src/p2/p240/: m3makefile Math.quake Log message: try doing less for cm3 -clean, maybe that is the rmrec problem (needs some Win32 portability, /dev/null vs. nul) From jkrell at elego.de Thu Jul 29 15:42:34 2010 From: jkrell at elego.de (Jay Krell) Date: Thu, 29 Jul 2010 15:42:34 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100729134234.B83652474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/29 15:42:34 Modified files: cm3/m3-sys/cminstall/src/config-no-install/: SPARC32_LINUX Log message: no symbols, just to conserve diskspace From jkrell at elego.de Thu Jul 29 15:44:44 2010 From: jkrell at elego.de (Jay Krell) Date: Thu, 29 Jul 2010 15:44:44 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100729134444.894572474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/29 15:44:44 Modified files: cm3/m3-sys/m3cc/src/: gnucc.common Log message: no symbols on SPARC32_LINUX to conserve diskspace From jkrell at elego.de Sat Jul 31 10:46:02 2010 From: jkrell at elego.de (Jay Krell) Date: Sat, 31 Jul 2010 10:46:02 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100731084606.EE088CC3B8@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/31 10:46:02 Modified files: cm3/: m3overrides Log message: adjust m3overrides file to avoid the useless warning from the frontend From jkrell at elego.de Sat Jul 31 10:48:48 2010 From: jkrell at elego.de (Jay Krell) Date: Sat, 31 Jul 2010 10:48:48 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100731084849.04D30CC3B8@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/31 10:48:48 Modified files: cm3/m3-sys/cm3/src/: M3Build.m3 Log message: Put back warning that we now avoid. I still don't see any point to this warning. From jkrell at elego.de Sat Jul 31 11:53:56 2010 From: jkrell at elego.de (Jay Krell) Date: Sat, 31 Jul 2010 11:53:56 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100731095356.AABEC2474019@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/31 11:53:56 Added files: cm3/m3-sys/m3tests/src/p2/p247/: Main.m3 m3makefile Log message: a larger test of just fs_rmrec From jkrell at elego.de Sat Jul 31 12:38:13 2010 From: jkrell at elego.de (Jay Krell) Date: Sat, 31 Jul 2010 12:38:13 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100731103814.0DCB6CC392@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/31 12:38:13 Modified files: cm3/m3-sys/m3tests/src/: m3makefile Log message: add test p248 for fs_rmrec From jkrell at elego.de Sat Jul 31 13:12:54 2010 From: jkrell at elego.de (Jay Krell) Date: Sat, 31 Jul 2010 13:12:54 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100731111308.34AD1CC3BE@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/31 13:12:54 Modified files: cm3/m3-libs/sysutils/src/: FSUtils.m3 Log message: replace RmRec with in implementation that only keeps one DIR*/Iterator open at a time. This is an experiment. The code is somewhat less efficient, producing more garbage, but also kind of small and nice to read. If this works, which I'm giving 50% odds, it still doesn't make sense. The opendir/readdir code I've seen is in fact reentrant. You can recurse while holding open the parent. They don't use a global or thread local, the use a buffer that is in the DIR*. Old version left for now under OldRmRec. With the debug printing removed. Both versions I believe are fairly racy, in that competing RmRecs will cause the other to fail. "Preflight" for existance doesn't cut and is in fact a significant deoptimization, This version is more efficient in that regard: don't call stat on children already determined to be file or directory. Still a wasted call at toplevel for existance. From jkrell at elego.de Sat Jul 31 13:35:48 2010 From: jkrell at elego.de (Jay Krell) Date: Sat, 31 Jul 2010 13:35:48 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100731113548.A0EAC2474019@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/31 13:35:48 Modified files: cm3/m3-libs/sysutils/src/: FSUtils.m3 Log message: Don't call stat so many extra times. Once is enough to determine exists vs. file vs. directory, and if we just enumerated it, we don't need to check again. Perhaps the three booleans should be an enum. From jkrell at elego.de Sat Jul 31 13:40:01 2010 From: jkrell at elego.de (Jay Krell) Date: Sat, 31 Jul 2010 13:40:01 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100731114001.A42472474019@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/31 13:40:01 Modified files: cm3/m3-libs/sysutils/src/: FSUtils.m3 Log message: Add more comments. This file has functions: Rm and RemoveFile Rmdir and RemoveDir They do the same things in the success paths and vary in that some raise exceptions and others call Process.Crash in the error paths. From jkrell at elego.de Sat Jul 31 13:47:22 2010 From: jkrell at elego.de (Jay Krell) Date: Sat, 31 Jul 2010 13:47:22 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100731114722.DE3D42474019@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/31 13:47:22 Modified files: cm3/m3-sys/m3cc/src/: m3makefile clean_marker.txt Log message: experiment: remove rm -rf hack and tickle clean marker From jkrell at elego.de Thu Jul 1 09:56:00 2010 From: jkrell at elego.de (Jay Krell) Date: Thu, 1 Jul 2010 9:56:00 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100701075600.3D2092474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/01 09:56:00 Added files: cm3/m3-sys/m3tests/src/c1/c135/: Main.m3 m3makefile cm3/m3-sys/m3tests/src/c1/c135/expected/AMD64_DARWIN/: Main.ms Log message: moving and slightly restructing test p239 From jkrell at elego.de Thu Jul 1 10:57:05 2010 From: jkrell at elego.de (Jay Krell) Date: Thu, 1 Jul 2010 10:57:05 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100701085705.757622474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/01 10:57:05 Modified files: cm3/m3-sys/m3cc/gcc/gcc/config/: darwin.h Log message: always support hidden aka private extern aka don't export every function from shared libraries, preferably only one - listed in an .i3 file - an .i3 file that is Interface and not merely interface I believe currently I've only achieved the first condition. I suspect this regressed because I put in specifying -target explicitly for consistency with cross builds, and so maybe that doesn't use autoconf as much? I'm not sure. From jkrell at elego.de Thu Jul 1 12:54:39 2010 From: jkrell at elego.de (Jay Krell) Date: Thu, 1 Jul 2010 12:54:39 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100701105439.9A92E2474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/01 12:54:39 Modified files: cm3/m3-sys/m3tests/src/: m3makefile Removed files: cm3/m3-sys/m3tests/src/p2/p239/: Main.m3 Main.ms-AMD64_DARWIN m3makefile Log message: flesh out infrastructure for checking in known/suspected correct assembly and then comparing to current assembly the intent, if not the code, is: in any directory m3-sys/m3tests/src/c1/c123 create m3-sys/m3tests/src/c1/c123/expected/I386_LINUX/Main.ms m3-sys/m3tests/src/c1/c123/expected/I386_LINUX/Foo.ms m3-sys/m3tests/src/c1/c123/expected/AMD64_LINUX/Main.ms m3-sys/m3tests/src/c1/c123/expected/AMD64_LINUX/Foo.ms etc. The name "expected" is a hardcoded part of the interface. I'm open to making it something else or additional flexibility, but this seems adequate or better to me. Any file in expected/TARGET is compared against TARGET. Missing/extra files are just ignored. Note that this probably works for stdout.pgm and such. Future: We should probably allow for: m3-sys/m3tests/src/c1/c123/expected/I386/Foo.ms m3-sys/m3tests/src/c1/c123/expected/AMD64/Main.ms once we confirm that they are often the same. e.g. I wouldn't be surprised if they are the same across all Solaris, *BSD, Linux, though probably not Darwin. Heck, we might even make up something called I386_ELF or I386_SYSV. Cross that bridge later. If the code does not agree with this description, well, this description was my intent. Whether or not creating a directory was worthwhile, it still not clear. The previous implementation allowed for just: m3-sys/m3tests/src/c1/c123/Main.ms-AMD64_LINUX and then you could either glom everything into Main.m3, or use multiple test cases. At the moment I'm thinking of having multiple files but just one large test case. We'll see. It's not a big deal either way. From jkrell at elego.de Thu Jul 1 14:41:08 2010 From: jkrell at elego.de (Jay Krell) Date: Thu, 1 Jul 2010 14:41:08 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100701124109.184902474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/01 14:41:08 Modified files: cm3/m3-sys/m3tests/src/c1/c135/: Main.m3 m3makefile cm3/m3-sys/m3tests/src/c1/c135/expected/AMD64_DARWIN/: Main.ms Added files: cm3/m3-sys/m3tests/src/c1/c135/expected/AMD64_DARWIN/: A.is A.ms Log message: generate code, what we had and a fair amount more we now generate add, subtract, mult, div, mod, or, and, xor for every integer type pair, for either two global variables or two parameters as well as returning each type as a constant or from a global variable or a parameter of any integer type 1104 total little functions, so far I still need to add bit field uses before I can go back and resume configure -enable-checking fixes, as the straightforward type fix there regressed code equality, so I want to try bit field refs again for constant bit insert/extract From jkrell at elego.de Thu Jul 1 15:43:32 2010 From: jkrell at elego.de (Jay Krell) Date: Thu, 1 Jul 2010 15:43:32 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100701134333.2C56E2474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/01 15:43:32 Modified files: cm3/m3-sys/m3tests/src/c1/c135/: m3makefile cm3/m3-sys/m3tests/src/c1/c135/expected/AMD64_DARWIN/: A.ms Log message: start adding float support (and seemingly quite nice generalizations in support of this) From wagner at elego.de Fri Jul 2 08:07:07 2010 From: wagner at elego.de (Olaf Wagner) Date: Fri, 2 Jul 2010 8:07:07 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100702060707.71F422474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: wagner at birch. 10/07/02 08:07:07 Modified files: cm3/scripts/: Tag: release_branch_cm3_5_8 make-dist.sh version version.quake Log message: prepare for final release build From jkrell at elego.de Fri Jul 2 14:41:25 2010 From: jkrell at elego.de (Jay Krell) Date: Fri, 2 Jul 2010 14:41:25 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100702124125.6DAC22474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/02 14:41:25 Added files: cm3/m3-sys/m3tests/src/c1/c135/: Math.quake Log message: addition (Add) and subtraction (Sub) of positive and negative numbers (!) at least in the fixed range [-9999, 9999] Also provide Range(0, n) which creates the array [0, .., n - 1] which you can use with foreach. All built out of hash tables! From jkrell at elego.de Fri Jul 2 14:42:10 2010 From: jkrell at elego.de (Jay Krell) Date: Fri, 2 Jul 2010 14:42:10 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100702124210.7E1082474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/02 14:42:10 Modified files: cm3/m3-sys/m3tests/src/c1/c135/: Math.quake Log message: turn off the test code From jkrell at elego.de Fri Jul 2 14:42:51 2010 From: jkrell at elego.de (Jay Krell) Date: Fri, 2 Jul 2010 14:42:51 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100702124251.3C1662474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/02 14:42:51 Modified files: cm3/m3-sys/m3tests/src/c1/c135/: Math.quake Log message: fix formating error that crept in From jkrell at elego.de Sat Jul 3 08:38:14 2010 From: jkrell at elego.de (Jay Krell) Date: Sat, 3 Jul 2010 8:38:14 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100703063814.C6D342474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/03 08:38:14 Modified files: cm3/m3-sys/m3tests/src/c1/c135/: Math.quake Log message: change Range to InclusiveRange and ExclusiveRange From jkrell at elego.de Sat Jul 3 09:08:54 2010 From: jkrell at elego.de (Jay Krell) Date: Sat, 3 Jul 2010 9:08:54 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100703070854.ADDD12474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/03 09:08:54 Modified files: cm3/m3-sys/m3tests/src/c1/c135/: Math.quake Log message: add Mult, Less, LessOrEqual, Greater, GreaterOrEqual From jkrell at elego.de Sat Jul 3 09:48:07 2010 From: jkrell at elego.de (Jay Krell) Date: Sat, 3 Jul 2010 9:48:07 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100703074807.7BB162474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/03 09:48:07 Modified files: cm3/m3-sys/m3tests/src/c1/c135/: Math.quake Log message: add Div and Mod, and fix a bug in previous From jkrell at elego.de Sat Jul 3 10:27:46 2010 From: jkrell at elego.de (Jay Krell) Date: Sat, 3 Jul 2010 10:27:46 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100703082746.6FA912474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/03 10:27:46 Modified files: cm3/m3-sys/m3tests/src/c1/c135/: Math.quake Log message: provide PowerOf2 and DecToHex PowerOf2 I want as part of testing extract_mn DecToHex is just to make that prettier Though I think extract_mn is more than just about exact powers of 2, need to look into it. I don't see how to provide HexToDec without major duplication/factoring. In particular, I think you'd need a whole other set of tables, and the functions would all have to be given the set of tables to use. Not likely to happen. If we could index strings, that'd help. Maybe we can? Anyway, for now, no matter. I have what I need and slightly more. From jkrell at elego.de Sat Jul 3 10:43:34 2010 From: jkrell at elego.de (Jay Krell) Date: Sat, 3 Jul 2010 10:43:34 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100703084334.A09252474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/03 10:43:34 Modified files: cm3/m3-sys/m3tests/src/c1/c135/: Math.quake Log message: rename DecToHex to just Hex, provide HexPowerOf2 that can deal with large numbers From jkrell at elego.de Sat Jul 3 11:17:54 2010 From: jkrell at elego.de (Jay Krell) Date: Sat, 3 Jul 2010 11:17:54 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100703091755.22F8F2474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/03 11:17:54 Modified files: cm3/m3-sys/m3tests/src/c1/c135/: m3makefile Log message: add a lot more coverage: reads and writes of bitfields division and mod by powers of 2 (I need to check though, it might be not just precise powers of 2 that matter) testing of INTEGER, LONGINT, CARDINAL, LONGCARD (and not just the precisely sized types) some float stuff (maybe that was there already) From jkrell at elego.de Sat Jul 3 11:50:00 2010 From: jkrell at elego.de (Jay Krell) Date: Sat, 3 Jul 2010 11:50:00 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100703095000.D5EDE2474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/03 11:50:00 Modified files: cm3/m3-sys/m3tests/src/c1/c135/: m3makefile Log message: more coverage, esp. div/mod of integer/cardinal/longint/longcard From jkrell at elego.de Sat Jul 3 11:50:46 2010 From: jkrell at elego.de (Jay Krell) Date: Sat, 3 Jul 2010 11:50:46 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100703095046.CEF9D2474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/03 11:50:46 Modified files: cm3/m3-sys/m3cc/gcc/gcc/config/rs6000/: rs6000-protos.h Log message: add #include alias.h to fix compilation break From jkrell at elego.de Sat Jul 3 12:03:50 2010 From: jkrell at elego.de (Jay Krell) Date: Sat, 3 Jul 2010 12:03:50 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100703100350.3158A2474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/03 12:03:50 Modified files: cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c Log message: a little more tracing, of insert/extract From jkrell at elego.de Sat Jul 3 12:05:06 2010 From: jkrell at elego.de (Jay Krell) Date: Sat, 3 Jul 2010 12:05:06 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100703100506.32D642474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/03 12:05:06 Modified files: cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c Log message: fix typo From jkrell at elego.de Sat Jul 3 12:08:17 2010 From: jkrell at elego.de (Jay Krell) Date: Sat, 3 Jul 2010 12:08:17 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100703100817.B35F02474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/03 12:08:17 Modified files: cm3/m3-libs/m3core/src/C/Common/: Cstdint.i3 Log message: remove BITS FOR From jkrell at elego.de Sat Jul 3 12:23:12 2010 From: jkrell at elego.de (Jay Krell) Date: Sat, 3 Jul 2010 12:23:12 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100703102315.47E2C2474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/03 12:23:12 Modified files: cm3/m3-sys/m3tests/src/: m3makefile Log message: port from release: the use of bc causes a problem on Solaris also fix up perhaps the optional use of Cygwin date.exe on NT need some sort of time support in quake? From jkrell at elego.de Sat Jul 3 12:47:11 2010 From: jkrell at elego.de (Jay Krell) Date: Sat, 3 Jul 2010 12:47:11 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100703104711.C99FC2474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/03 12:47:11 Modified files: cm3/m3-sys/cminstall/src/config-no-install/: PPC_LINUX Log message: Don't make executable position independent. It is a nice security feature, but this is the only platform we use it on so far and it breaks debugging (even for C code). From jkrell at elego.de Sat Jul 3 12:48:56 2010 From: jkrell at elego.de (Jay Krell) Date: Sat, 3 Jul 2010 12:48:56 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100703104856.A32A72474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/03 12:48:56 Modified files: cm3/m3-sys/cminstall/src/config-no-install/: Tag: release_branch_cm3_5_8 PPC_LINUX Log message: port from head: don't make PPC_LINUX executables position independent, as it breaks debugging (we do use this on Solaris actually, but the odds of such a bug being portable aren't high) From jkrell at elego.de Sat Jul 3 12:57:09 2010 From: jkrell at elego.de (Jay Krell) Date: Sat, 3 Jul 2010 12:57:09 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100703105709.DBD2E2474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/03 12:57:09 Modified files: cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c Log message: restore volatile for powerpc and powerpc64 platforms This seems to fix PPC_LINUX hanging. This needs further debugging, but I'm not eager. This will also affect PPC_DARWIN, PPC64_DARWIN, PPC32_OPENBSD, PPC32_NETBSD, PPC32_FREEBSD, etc., but these platforms are little used or nonexistant. Having volatile like has been the very long standing situation though. The result is that the optimizer does basically nothing. From jkrell at elego.de Sat Jul 3 12:58:34 2010 From: jkrell at elego.de (Jay Krell) Date: Sat, 3 Jul 2010 12:58:34 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100703105834.337FF2474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/03 12:58:34 Modified files: cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c Log message: fix typo regarding powerpc64 From jkrell at elego.de Sat Jul 3 14:42:37 2010 From: jkrell at elego.de (Jay Krell) Date: Sat, 3 Jul 2010 14:42:37 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100703124239.DA0E02474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/03 14:42:37 Modified files: cm3/m3-sys/m3tests/src/c1/c135/: m3makefile Log message: more coverage cleaner output preparation for still more coverage From jkrell at elego.de Sat Jul 3 15:14:59 2010 From: jkrell at elego.de (Jay Krell) Date: Sat, 3 Jul 2010 15:14:59 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100703131459.438062474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/03 15:14:59 Modified files: cm3/m3-sys/m3tests/src/c1/c135/: m3makefile Log message: add unary negation and unary Word.Not From jkrell at elego.de Sat Jul 3 15:27:41 2010 From: jkrell at elego.de (Jay Krell) Date: Sat, 3 Jul 2010 15:27:41 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100703132741.F037E2474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/03 15:27:41 Modified files: cm3/m3-sys/m3tests/src/c1/c135/: m3makefile Log message: add left/right/other shift/rotate, by non constants limiting second parameter to INTEGER, though other types should have differing / interesting codegen, e.g. CARDINAL would have few range changes hopefully and small ranges would too From jkrell at elego.de Sat Jul 3 15:29:05 2010 From: jkrell at elego.de (Jay Krell) Date: Sat, 3 Jul 2010 15:29:05 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100703132905.381A32474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/03 15:29:05 Modified files: cm3/m3-sys/m3tests/src/c1/c135/: m3makefile Log message: add shift/rotate by cardinal as well From jkrell at elego.de Sat Jul 3 15:31:09 2010 From: jkrell at elego.de (Jay Krell) Date: Sat, 3 Jul 2010 15:31:09 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100703133110.0278B2474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/03 15:31:09 Modified files: cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c Log message: reremove volatile on powerpc, it doesn't seem to hang now..wierd... (should still test it optimized as well) From jkrell at elego.de Sat Jul 3 15:44:42 2010 From: jkrell at elego.de (Jay Krell) Date: Sat, 3 Jul 2010 15:44:42 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100703134442.6254E2474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/03 15:44:42 Modified files: cm3/m3-sys/m3tests/src/c1/c135/: m3makefile Log message: add Word/Long.Insert/Extract coverage, for non-constants and with some of the combinatorics reduced (but constant converage coming shortly) From jkrell at elego.de Sat Jul 3 15:57:20 2010 From: jkrell at elego.de (Jay Krell) Date: Sat, 3 Jul 2010 15:57:20 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100703135720.8D8742474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/03 15:57:20 Modified files: cm3/m3-sys/m3tests/src/c1/c135/: Math.quake Log message: fix direct uses of ExclusiveRange, which I don't use but it had been bugging me From jkrell at elego.de Sat Jul 3 15:58:09 2010 From: jkrell at elego.de (Jay Krell) Date: Sat, 3 Jul 2010 15:58:09 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100703135809.E1A9B2474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/03 15:58:09 Modified files: cm3/m3-sys/m3tests/src/c1/c135/: Math.quake Log message: maybe fix other cases that don't affect me From jkrell at elego.de Sat Jul 3 16:30:25 2010 From: jkrell at elego.de (Jay Krell) Date: Sat, 3 Jul 2010 16:30:25 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100703143028.3F19D2474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/03 16:30:25 Modified files: cm3/m3-sys/m3tests/src/c1/c135/: m3makefile Log message: add insert/extract with one and two constants From jkrell at elego.de Sat Jul 3 17:00:34 2010 From: jkrell at elego.de (Jay Krell) Date: Sat, 3 Jul 2010 17:00:34 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100703150034.F33932474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/03 17:00:34 Modified files: cm3/m3-sys/m3tests/src/c1/c135/: m3makefile Log message: split up some into separate files: bitfield.m3, divmod_pow2.m3, insert.m3, extract.m3, A.m3 From jkrell at elego.de Sat Jul 3 17:01:31 2010 From: jkrell at elego.de (Jay Krell) Date: Sat, 3 Jul 2010 17:01:31 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100703150132.2AA5E2474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/03 17:01:31 Modified files: cm3/m3-sys/m3tests/src/c1/c135/: m3makefile Log message: minor cleanup From jkrell at elego.de Sat Jul 3 17:06:59 2010 From: jkrell at elego.de (Jay Krell) Date: Sat, 3 Jul 2010 17:06:59 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100703150700.057802474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/03 17:06:59 Modified files: cm3/m3-sys/m3tests/src/c1/c135/expected/AMD64_DARWIN/: A.ms Added files: cm3/m3-sys/m3tests/src/c1/c135/expected/AMD64_DARWIN/: bitfield.ms divmod_pow2.ms extract.ms insert.ms Removed files: cm3/m3-sys/m3tests/src/c1/c135/expected/AMD64_DARWIN/: A.is Main.ms Log message: add expected outputs now that maybe maybe this has reached a fairly good state for a while Some of the files are still quite large though and should maybe be broken down more. From jkrell at elego.de Sat Jul 3 17:28:20 2010 From: jkrell at elego.de (Jay Krell) Date: Sat, 3 Jul 2010 17:28:20 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100703152820.CE4B02474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/03 17:28:20 Modified files: cm3/m3-sys/m3tests/src/c1/c135/: m3makefile cm3/m3-sys/m3tests/src/c1/c135/expected/AMD64_DARWIN/: bitfield.ms Log message: keep bitfields to INTEGER, not LONGINT don't have 0 or word-size bitfields, just 1 .. wordsize - 1 From jkrell at elego.de Sat Jul 3 17:38:18 2010 From: jkrell at elego.de (Jay Krell) Date: Sat, 3 Jul 2010 17:38:18 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100703153818.A01FA2474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/03 17:38:18 Added files: cm3/m3-sys/m3tests/src/c1/c135/expected/I386_LINUX/: A.ms bitfield.ms divmod_pow2.ms extract.ms insert.ms Log message: add current outputs From jkrell at elego.de Sat Jul 3 17:41:09 2010 From: jkrell at elego.de (Jay Krell) Date: Sat, 3 Jul 2010 17:41:09 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100703154109.5A7362474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/03 17:41:09 Added files: cm3/m3-sys/m3tests/src/c1/c135/expected/SOLgnu/: A.ms bitfield.ms divmod_pow2.ms extract.ms insert.ms Log message: add current outputs From jkrell at elego.de Sun Jul 4 02:17:19 2010 From: jkrell at elego.de (Jay Krell) Date: Sun, 4 Jul 2010 2:17:19 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100704001720.7BD4B2474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/04 02:17:19 Modified files: cm3/m3-sys/m3tests/src/: m3makefile Added files: cm3/m3-sys/m3tests/src/p2/p240/: Main.m3 Math.quake m3makefile cm3/m3-sys/m3tests/src/p2/p240/expected/AMD64_DARWIN/: A.ms bitfield.ms divmod_pow2.ms extract.ms insert.ms cm3/m3-sys/m3tests/src/p2/p240/expected/I386_LINUX/: A.ms bitfield.ms divmod_pow2.ms extract.ms insert.ms cm3/m3-sys/m3tests/src/p2/p240/expected/SOLgnu/: A.ms bitfield.ms divmod_pow2.ms extract.ms insert.ms Removed files: cm3/m3-sys/m3tests/src/c1/c135/: Main.m3 Math.quake m3makefile cm3/m3-sys/m3tests/src/c1/c135/expected/AMD64_DARWIN/: A.ms bitfield.ms divmod_pow2.ms extract.ms insert.ms cm3/m3-sys/m3tests/src/c1/c135/expected/I386_LINUX/: A.ms bitfield.ms divmod_pow2.ms extract.ms insert.ms cm3/m3-sys/m3tests/src/c1/c135/expected/SOLgnu/: A.ms bitfield.ms divmod_pow2.ms extract.ms insert.ms Log message: restore "c" tests to not running (at least one of them knowingly contains an infinite loop) change c135 to p240 From jkrell at elego.de Sun Jul 4 02:22:35 2010 From: jkrell at elego.de (Jay Krell) Date: Sun, 4 Jul 2010 2:22:35 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100704002241.9F9C72474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/04 02:22:35 Modified files: cm3/m3-sys/cminstall/src/config-no-install/: PPC_LINUX Log message: add comment that gdb 7.1 needed for PIE debugging, keep it disabled at least for now (was it causing other problems??) From hosking at cs.purdue.edu Sun Jul 4 02:36:20 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sat, 3 Jul 2010 20:36:20 -0400 Subject: [M3commit] CVS Update: cm3 In-Reply-To: <20100703105709.DBD2E2474003@birch.elegosoft.com> References: <20100703105709.DBD2E2474003@birch.elegosoft.com> Message-ID: I am very disturbed that volatile is needed here. Can we selectively turn it on for thread-critical files like ThreadPThread and see if it fixes the problem. I wonder if the double-checked locking is broken for PPC memory model. Is this on a multi-processor? On 3 Jul 2010, at 12:57, Jay Krell wrote: > CVSROOT: /usr/cvs > Changes by: jkrell at birch. 10/07/03 12:57:09 > > Modified files: > cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c > > Log message: > restore volatile for powerpc and powerpc64 platforms > This seems to fix PPC_LINUX hanging. > This needs further debugging, but I'm not eager. > This will also affect PPC_DARWIN, PPC64_DARWIN, PPC32_OPENBSD, > PPC32_NETBSD, PPC32_FREEBSD, etc., but these platforms are little used or > nonexistant. > > Having volatile like has been the very long standing situation though. > The result is that the optimizer does basically nothing. From jay.krell at cornell.edu Sun Jul 4 02:42:20 2010 From: jay.krell at cornell.edu (Jay K) Date: Sun, 4 Jul 2010 00:42:20 +0000 Subject: [M3commit] CVS Update: cm3 In-Reply-To: References: <20100703105709.DBD2E2474003@birch.elegosoft.com>, Message-ID: Not a multiprocessor. ? Still interested in selective volatile? This all bothers me too. I don't want volatile. It makes the optimized code terrible. But I don't want to debug any problem from removing it, beyond compilation failure. I can try a few things. This is all wierd. I swear I saw it hang several times. I swear I'm trying to to change "too many" variables at a time. Yes, I know, 2 is too many. Once I started getting version stamp mismatch, I resorted to using a cross built cm3. ?Out of necessity sort of, but that causes more flucuation of variables. Let me try again with volatile and see if it is solid. ?Then I'll try with only volatile stores. I've been trying optimized and unoptimized, and not kept good track of which when. ?- Jay ---------------------------------------- > From: hosking at cs.purdue.edu > Date: Sat, 3 Jul 2010 20:36:20 -0400 > To: jkrell at elego.de > CC: m3commit at elegosoft.com > Subject: Re: [M3commit] CVS Update: cm3 > > I am very disturbed that volatile is needed here. Can we selectively turn it on for thread-critical files like ThreadPThread and see if it fixes the problem. I wonder if the double-checked locking is broken for PPC memory model. Is this on a multi-processor? > > On 3 Jul 2010, at 12:57, Jay Krell wrote: > > > CVSROOT: /usr/cvs > > Changes by: jkrell at birch. 10/07/03 12:57:09 > > > > Modified files: > > cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c > > > > Log message: > > restore volatile for powerpc and powerpc64 platforms > > This seems to fix PPC_LINUX hanging. > > This needs further debugging, but I'm not eager. > > This will also affect PPC_DARWIN, PPC64_DARWIN, PPC32_OPENBSD, > > PPC32_NETBSD, PPC32_FREEBSD, etc., but these platforms are little used or > > nonexistant. > > > > Having volatile like has been the very long standing situation though. > > The result is that the optimizer does basically nothing. > From jay.krell at cornell.edu Sun Jul 4 02:44:37 2010 From: jay.krell at cornell.edu (Jay K) Date: Sun, 4 Jul 2010 00:44:37 +0000 Subject: [M3commit] CVS Update: cm3 In-Reply-To: References: <20100703105709.DBD2E2474003@birch.elegosoft.com>, , Message-ID: Tony, just to be clear..you/I are disturbed by volatile, but it has also, I believe, like always been there. It has been gone only very briefly, and its non-use is probably limited for other reasons (how many people are using it, on how many platforms?). ?- Jay ---------------------------------------- > From: jay.krell at cornell.edu > To: hosking at cs.purdue.edu; jkrell at elego.de > CC: m3commit at elegosoft.com > Subject: RE: [M3commit] CVS Update: cm3 > Date: Sun, 4 Jul 2010 00:42:20 +0000 > > > Not a multiprocessor. > Still interested in selective volatile? > > > This all bothers me too. > I don't want volatile. It makes the optimized code terrible. > But I don't want to debug any problem from removing it, beyond compilation failure. > > > I can try a few things. > This is all wierd. I swear I saw it hang several times. > I swear I'm trying to to change "too many" variables at a time. Yes, I know, 2 is too many. > > > Once I started getting version stamp mismatch, I resorted to using a cross built cm3. > Out of necessity sort of, but that causes more flucuation of variables. > > Let me try again with volatile and see if it is solid. > Then I'll try with only volatile stores. > > I've been trying optimized and unoptimized, and not kept good track of which when. > > > - Jay > > > ---------------------------------------- > > From: hosking at cs.purdue.edu > > Date: Sat, 3 Jul 2010 20:36:20 -0400 > > To: jkrell at elego.de > > CC: m3commit at elegosoft.com > > Subject: Re: [M3commit] CVS Update: cm3 > > > > I am very disturbed that volatile is needed here. Can we selectively turn it on for thread-critical files like ThreadPThread and see if it fixes the problem. I wonder if the double-checked locking is broken for PPC memory model. Is this on a multi-processor? > > > > On 3 Jul 2010, at 12:57, Jay Krell wrote: > > > > > CVSROOT: /usr/cvs > > > Changes by: jkrell at birch. 10/07/03 12:57:09 > > > > > > Modified files: > > > cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c > > > > > > Log message: > > > restore volatile for powerpc and powerpc64 platforms > > > This seems to fix PPC_LINUX hanging. > > > This needs further debugging, but I'm not eager. > > > This will also affect PPC_DARWIN, PPC64_DARWIN, PPC32_OPENBSD, > > > PPC32_NETBSD, PPC32_FREEBSD, etc., but these platforms are little used or > > > nonexistant. > > > > > > Having volatile like has been the very long standing situation though. > > > The result is that the optimizer does basically nothing. > > > From hosking at cs.purdue.edu Sun Jul 4 02:49:11 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sat, 3 Jul 2010 20:49:11 -0400 Subject: [M3commit] CVS Update: cm3 In-Reply-To: References: <20100703105709.DBD2E2474003@birch.elegosoft.com>, Message-ID: <131D2ADF-5AB5-4DFA-B819-1A7F117C94C1@cs.purdue.edu> On 3 Jul 2010, at 20:42, Jay K wrote: > Not a multiprocessor. > Still interested in selective volatile? Not really. This says its something even more troubling unless it happens with the optimiser. > This all bothers me too. > I don't want volatile. It makes the optimized code terrible. Agreed. > But I don't want to debug any problem from removing it, beyond compilation failure. > > > I can try a few things. > This is all wierd. I swear I saw it hang several times. > I swear I'm trying to to change "too many" variables at a time. Yes, I know, 2 is too many. > > > Once I started getting version stamp mismatch, I resorted to using a cross built cm3. > Out of necessity sort of, but that causes more flucuation of variables. > > Let me try again with volatile and see if it is solid. > Then I'll try with only volatile stores. > > I've been trying optimized and unoptimized, and not kept good track of which when. > > > - Jay > > > ---------------------------------------- >> From: hosking at cs.purdue.edu >> Date: Sat, 3 Jul 2010 20:36:20 -0400 >> To: jkrell at elego.de >> CC: m3commit at elegosoft.com >> Subject: Re: [M3commit] CVS Update: cm3 >> >> I am very disturbed that volatile is needed here. Can we selectively turn it on for thread-critical files like ThreadPThread and see if it fixes the problem. I wonder if the double-checked locking is broken for PPC memory model. Is this on a multi-processor? >> >> On 3 Jul 2010, at 12:57, Jay Krell wrote: >> >>> CVSROOT: /usr/cvs >>> Changes by: jkrell at birch. 10/07/03 12:57:09 >>> >>> Modified files: >>> cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c >>> >>> Log message: >>> restore volatile for powerpc and powerpc64 platforms >>> This seems to fix PPC_LINUX hanging. >>> This needs further debugging, but I'm not eager. >>> This will also affect PPC_DARWIN, PPC64_DARWIN, PPC32_OPENBSD, >>> PPC32_NETBSD, PPC32_FREEBSD, etc., but these platforms are little used or >>> nonexistant. >>> >>> Having volatile like has been the very long standing situation though. >>> The result is that the optimizer does basically nothing. >> > From hosking at cs.purdue.edu Sun Jul 4 02:50:11 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sat, 3 Jul 2010 20:50:11 -0400 Subject: [M3commit] CVS Update: cm3 In-Reply-To: References: <20100703105709.DBD2E2474003@birch.elegosoft.com>, , Message-ID: <00538FB2-00DA-4C0E-82F3-D151B9A85A0E@cs.purdue.edu> I added it a long time back only because I saw failures with optimisation turned on. Something to do with the alias analysis (and lack of proper type information) as far as I recall. On 3 Jul 2010, at 20:44, Jay K wrote: > > Tony, just to be clear..you/I are disturbed by volatile, but it has also, I believe, like always been there. > It has been gone only very briefly, and its non-use is probably limited for other reasons (how many people are > using it, on how many platforms?). > > > - Jay > > ---------------------------------------- >> From: jay.krell at cornell.edu >> To: hosking at cs.purdue.edu; jkrell at elego.de >> CC: m3commit at elegosoft.com >> Subject: RE: [M3commit] CVS Update: cm3 >> Date: Sun, 4 Jul 2010 00:42:20 +0000 >> >> >> Not a multiprocessor. >> Still interested in selective volatile? >> >> >> This all bothers me too. >> I don't want volatile. It makes the optimized code terrible. >> But I don't want to debug any problem from removing it, beyond compilation failure. >> >> >> I can try a few things. >> This is all wierd. I swear I saw it hang several times. >> I swear I'm trying to to change "too many" variables at a time. Yes, I know, 2 is too many. >> >> >> Once I started getting version stamp mismatch, I resorted to using a cross built cm3. >> Out of necessity sort of, but that causes more flucuation of variables. >> >> Let me try again with volatile and see if it is solid. >> Then I'll try with only volatile stores. >> >> I've been trying optimized and unoptimized, and not kept good track of which when. >> >> >> - Jay >> >> >> ---------------------------------------- >>> From: hosking at cs.purdue.edu >>> Date: Sat, 3 Jul 2010 20:36:20 -0400 >>> To: jkrell at elego.de >>> CC: m3commit at elegosoft.com >>> Subject: Re: [M3commit] CVS Update: cm3 >>> >>> I am very disturbed that volatile is needed here. Can we selectively turn it on for thread-critical files like ThreadPThread and see if it fixes the problem. I wonder if the double-checked locking is broken for PPC memory model. Is this on a multi-processor? >>> >>> On 3 Jul 2010, at 12:57, Jay Krell wrote: >>> >>>> CVSROOT: /usr/cvs >>>> Changes by: jkrell at birch. 10/07/03 12:57:09 >>>> >>>> Modified files: >>>> cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c >>>> >>>> Log message: >>>> restore volatile for powerpc and powerpc64 platforms >>>> This seems to fix PPC_LINUX hanging. >>>> This needs further debugging, but I'm not eager. >>>> This will also affect PPC_DARWIN, PPC64_DARWIN, PPC32_OPENBSD, >>>> PPC32_NETBSD, PPC32_FREEBSD, etc., but these platforms are little used or >>>> nonexistant. >>>> >>>> Having volatile like has been the very long standing situation though. >>>> The result is that the optimizer does basically nothing. >>> >> > From jkrell at elego.de Sun Jul 4 09:54:39 2010 From: jkrell at elego.de (Jay Krell) Date: Sun, 4 Jul 2010 9:54:39 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100704075439.F06A62474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/04 09:54:39 Modified files: cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c Log message: having restored the historical div/mod implementation.. ARM backend resumes crashing, because it does even for unsigned 64bit divide with any mode (i.e. even the C mode, if the C compiler more resembled the Modula-3 compiler); it needs a non-null pointer from type_for_mode(TImode) In the meantime I have more trust in the gcc builtins than when I stopped using them. So then restore using the gcc builtins. And then to fix the ARM crash, add some TImode/int128 support. Just one line in type_for_mode. remove some tabs From jay.krell at cornell.edu Sun Jul 4 14:58:49 2010 From: jay.krell at cornell.edu (Jay K) Date: Sun, 4 Jul 2010 12:58:49 +0000 Subject: [M3commit] CVS Update: cm3 In-Reply-To: <00538FB2-00DA-4C0E-82F3-D151B9A85A0E@cs.purdue.edu> References: <20100703105709.DBD2E2474003@birch.elegosoft.com>, , , , , , <00538FB2-00DA-4C0E-82F3-D151B9A85A0E@cs.purdue.edu> Message-ID: Darnit and now those version stamp mispatch problems are gone too. I don't know what the heck is/was going on. ?- Jay ---------------------------------------- > From: hosking at cs.purdue.edu > Date: Sat, 3 Jul 2010 20:50:11 -0400 > To: jay.krell at cornell.edu > CC: m3commit at elegosoft.com > Subject: Re: [M3commit] CVS Update: cm3 > > I added it a long time back only because I saw failures with optimisation turned on. Something to do with the alias analysis (and lack of proper type information) as far as I recall. > > > On 3 Jul 2010, at 20:44, Jay K wrote: > > > > > Tony, just to be clear..you/I are disturbed by volatile, but it has also, I believe, like always been there. > > It has been gone only very briefly, and its non-use is probably limited for other reasons (how many people are > > using it, on how many platforms?). > > > > > > - Jay > > > > ---------------------------------------- > >> From: jay.krell at cornell.edu > >> To: hosking at cs.purdue.edu; jkrell at elego.de > >> CC: m3commit at elegosoft.com > >> Subject: RE: [M3commit] CVS Update: cm3 > >> Date: Sun, 4 Jul 2010 00:42:20 +0000 > >> > >> > >> Not a multiprocessor. > >> Still interested in selective volatile? > >> > >> > >> This all bothers me too. > >> I don't want volatile. It makes the optimized code terrible. > >> But I don't want to debug any problem from removing it, beyond compilation failure. > >> > >> > >> I can try a few things. > >> This is all wierd. I swear I saw it hang several times. > >> I swear I'm trying to to change "too many" variables at a time. Yes, I know, 2 is too many. > >> > >> > >> Once I started getting version stamp mismatch, I resorted to using a cross built cm3. > >> Out of necessity sort of, but that causes more flucuation of variables. > >> > >> Let me try again with volatile and see if it is solid. > >> Then I'll try with only volatile stores. > >> > >> I've been trying optimized and unoptimized, and not kept good track of which when. > >> > >> > >> - Jay > >> > >> > >> ---------------------------------------- > >>> From: hosking at cs.purdue.edu > >>> Date: Sat, 3 Jul 2010 20:36:20 -0400 > >>> To: jkrell at elego.de > >>> CC: m3commit at elegosoft.com > >>> Subject: Re: [M3commit] CVS Update: cm3 > >>> > >>> I am very disturbed that volatile is needed here. Can we selectively turn it on for thread-critical files like ThreadPThread and see if it fixes the problem. I wonder if the double-checked locking is broken for PPC memory model. Is this on a multi-processor? > >>> > >>> On 3 Jul 2010, at 12:57, Jay Krell wrote: > >>> > >>>> CVSROOT: /usr/cvs > >>>> Changes by: jkrell at birch. 10/07/03 12:57:09 > >>>> > >>>> Modified files: > >>>> cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c > >>>> > >>>> Log message: > >>>> restore volatile for powerpc and powerpc64 platforms > >>>> This seems to fix PPC_LINUX hanging. > >>>> This needs further debugging, but I'm not eager. > >>>> This will also affect PPC_DARWIN, PPC64_DARWIN, PPC32_OPENBSD, > >>>> PPC32_NETBSD, PPC32_FREEBSD, etc., but these platforms are little used or > >>>> nonexistant. > >>>> > >>>> Having volatile like has been the very long standing situation though. > >>>> The result is that the optimizer does basically nothing. > >>> > >> > > > From jkrell at elego.de Sun Jul 4 15:10:03 2010 From: jkrell at elego.de (Jay Krell) Date: Sun, 4 Jul 2010 15:10:03 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100704131003.E8CAB2474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/04 15:10:03 Modified files: cm3/m3-obliq/obliqlibm3/src/: ObLibM3.m3 Log message: initialize a few local integers that backend warns might be used uninitialized From jay.krell at cornell.edu Sun Jul 4 15:12:36 2010 From: jay.krell at cornell.edu (Jay K) Date: Sun, 4 Jul 2010 13:12:36 +0000 Subject: [M3commit] CVS Update: cm3 In-Reply-To: <20100704131003.E8CAB2474003@birch.elegosoft.com> References: <20100704131003.E8CAB2474003@birch.elegosoft.com> Message-ID: minor diff attached ---------------------------------------- > Date: Sun, 4 Jul 2010 15:10:03 +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/07/04 15:10:03 > > Modified files: > cm3/m3-obliq/obliqlibm3/src/: ObLibM3.m3 > > Log message: > initialize a few local integers that backend warns might be used uninitialized > -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: 1.txt URL: From jkrell at elego.de Sun Jul 4 17:26:33 2010 From: jkrell at elego.de (Jay Krell) Date: Sun, 4 Jul 2010 17:26:33 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100704152633.E6FEF2474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/04 17:26:33 Added files: cm3/m3-libs/m3core/src/float/: test_copysign.c Log message: CopySign in C From jkrell at elego.de Sun Jul 4 17:31:08 2010 From: jkrell at elego.de (Jay Krell) Date: Sun, 4 Jul 2010 17:31:08 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100704153108.E41552474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/04 17:31:08 Modified files: cm3/m3-libs/m3core/src/float/: test_copysign.c Log message: more true to the Modula-3 From jkrell at elego.de Sun Jul 4 17:37:52 2010 From: jkrell at elego.de (Jay Krell) Date: Sun, 4 Jul 2010 17:37:52 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100704153752.EDFB12474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/04 17:37:52 Modified files: cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c Log message: some steps forward and backward: remove the volatile on float stores, good turn off "ter" optimization, not great Need to investigate more. Tested only so far on AMD64_DARWIN. From jay.krell at cornell.edu Sun Jul 4 17:40:26 2010 From: jay.krell at cornell.edu (Jay K) Date: Sun, 4 Jul 2010 15:40:26 +0000 Subject: [M3commit] CVS Update: cm3 In-Reply-To: <20100704153752.EDFB12474003@birch.elegosoft.com> References: <20100704153752.EDFB12474003@birch.elegosoft.com> Message-ID: Just a little two line change attached... (with presumably major impact on floating point code) ---------------------------------------- > Date: Sun, 4 Jul 2010 17:37:52 +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/07/04 17:37:52 > > Modified files: > cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c > > Log message: > some steps forward and backward: > remove the volatile on float stores, good > turn off "ter" optimization, not great > > Need to investigate more. > > Tested only so far on AMD64_DARWIN. > -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: remove_float_volatile_ter.txt URL: From jkrell at elego.de Mon Jul 5 13:22:07 2010 From: jkrell at elego.de (Jay Krell) Date: Mon, 5 Jul 2010 13:22:07 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100705112207.5CD4E2474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/05 13:22:07 Modified files: cm3/m3-libs/m3core/src/float/IEEE/: LongFloat.m3 Log message: ../src/float/IEEE/LongFloat.m3: In function 'LongFloat__Logb': ../src/float/IEEE/LongFloat.m3:35: warning: 'M3_CtKayy_ans' is used uninitialized in this function ../src/float/IEEE/LongFloat.m3: In function 'LongFloat__NextAfter': ../src/float/IEEE/LongFloat.m3:81: warning: 'M3_CtKayy_z' is used uninitialized in this function Not really. Initialize them to 0. There is probably a better fix here, something like: NextAfter: RETURN LOOPHOLE(Rep.T{sign := yy.sign, exponent := 0, significand0 := 0, significand1 := 1}, T) Logb: RETURN LOOPHOLE (Log_of_zero, T); From jkrell at elego.de Mon Jul 5 13:28:32 2010 From: jkrell at elego.de (Jay Krell) Date: Mon, 5 Jul 2010 13:28:32 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100705112833.07AD72474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/05 13:28:32 Modified files: cm3/m3-sys/m3front/src/exprs/: CastExpr.m3 Log message: fix comments: cause => because 'cause => because From jkrell at elego.de Mon Jul 5 14:12:11 2010 From: jkrell at elego.de (Jay Krell) Date: Mon, 5 Jul 2010 14:12:11 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100705121211.4FC9F2474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/05 14:12:11 Modified files: cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c Log message: remove one tab From jkrell at elego.de Mon Jul 5 15:01:38 2010 From: jkrell at elego.de (Jay Krell) Date: Mon, 5 Jul 2010 15:01:38 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100705130138.6A09A2474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/05 15:01:38 Modified files: cm3/m3-libs/m3core/src/float/IEEE/: LongFloat.m3 Log message: go back a version, compiler change coming instead From jkrell at elego.de Mon Jul 5 15:22:28 2010 From: jkrell at elego.de (Jay Krell) Date: Mon, 5 Jul 2010 15:22:28 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100705132228.0E6D52474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/05 15:22:28 Modified files: cm3/m3-tools/cvsup/suplib/src/text_cm3/: SupMiscText.m3 Log message: ../src/text_cm3/SupMiscText.m3: In function 'SupMisc__DecodeWS': ../src/text_cm3/SupMiscText.m3:211: warning: 'M3_Bkn9rd_ch' may be used uninitialized in this function ../src/text_cm3/SupMiscText.m3:211: note: 'M3_Bkn9rd_ch' was declared here because raising an exception isn't currently "noreturn" so initialize it to 0 From jkrell at elego.de Mon Jul 5 15:25:03 2010 From: jkrell at elego.de (Jay Krell) Date: Mon, 5 Jul 2010 15:25:03 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100705132503.B27A82474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/05 15:25:03 Modified files: cm3/m3-tools/cvsup/suplib/src/: MD5Digest.m3 Log message: ../src/MD5Digest.m3: In function 'MD5Digest__FromText': ../src/MD5Digest.m3:162: warning: 'M3_AcxOUs_val' may be used uninitialized in this function ../src/MD5Digest.m3:162: note: 'M3_AcxOUs_val' was declared here From jkrell at elego.de Mon Jul 5 15:27:52 2010 From: jkrell at elego.de (Jay Krell) Date: Mon, 5 Jul 2010 15:27:52 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100705132752.80A422474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/05 15:27:52 Modified files: cm3/m3-comm/events/src/: EventStubLib.m3 Log message: ../src/EventStubLib.m3: In function 'EventStubLib__InInteger': ../src/EventStubLib.m3:1011: warning: 'M3_AcxOUs_i' may be used uninitialized in this function ../src/EventStubLib.m3:1011: note: 'M3_AcxOUs_i' was declared here ../src/EventStubLib.m3: In function 'EventStubLib__InInt32': ../src/EventStubLib.m3:1011: warning: 'M3_ENQ7Kn_i' may be used uninitialized in this function ../src/EventStubLib.m3:1011: note: 'M3_ENQ7Kn_i' was declared here From jkrell at elego.de Mon Jul 5 15:29:58 2010 From: jkrell at elego.de (Jay Krell) Date: Mon, 5 Jul 2010 15:29:58 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100705132958.480262474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/05 15:29:58 Modified files: cm3/m3-ui/juno-2/juno-machine/src/: JunoDisassem.m3 Log message: ../src/JunoDisassem.m3: In function 'JunoDisassem__P__DoSolve': ../src/JunoDisassem.m3:74: warning: 'M3_BlCZOI_z' may be used uninitialized in this function ../src/JunoDisassem.m3:74: warning: 'M3_BlCZOI_y' may be used uninitialized in this function From jkrell at elego.de Mon Jul 5 15:31:43 2010 From: jkrell at elego.de (Jay Krell) Date: Mon, 5 Jul 2010 15:31:43 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100705133143.467692474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/05 15:31:43 Modified files: cm3/m3-ui/juno-2/juno-machine/src/: JunoRT.m3 Log message: ../src/JunoRT.m3: In function 'JunoRT__DoSolve': ../src/JunoRT.m3:1266: warning: 'M3_DGwZEA_z' may be used uninitialized in this function ../src/JunoRT.m3:1266: warning: 'M3_DGwZEA_y' may be used uninitialized in this function From jkrell at elego.de Mon Jul 5 15:33:57 2010 From: jkrell at elego.de (Jay Krell) Date: Mon, 5 Jul 2010 15:33:57 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100705133357.46DC02474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/05 15:33:57 Modified files: cm3/m3-ui/bicycle/src/: PixmapFromXData.m3 Log message: ../src/PixmapFromXData.m3: In function 'PixmapFromXData__P': ../src/PixmapFromXData.m3:136: warning: 'M3_AcxOUs_mask' may be used uninitialized in this function ../src/PixmapFromXData.m3:136: note: 'M3_AcxOUs_mask' was declared here ../src/PixmapFromXData.m3:136: warning: 'M3_AcxOUs_word' may be used uninitialized in this function ../src/PixmapFromXData.m3:136: note: 'M3_AcxOUs_word' was declared here ../src/PixmapFromXData.m3: In function 'PixmapFromXData__Flip': ../src/PixmapFromXData.m3:136: warning: 'M3_AcxOUs_mask' may be used uninitialized in this function ../src/PixmapFromXData.m3:136: note: 'M3_AcxOUs_mask' was declared here ../src/PixmapFromXData.m3:136: warning: 'M3_AcxOUs_word' may be used uninitialized in this function ../src/PixmapFromXData.m3:136: note: 'M3_AcxOUs_word' was declared here From hosking at cs.purdue.edu Mon Jul 5 20:31:01 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 5 Jul 2010 14:31:01 -0400 Subject: [M3commit] CVS Update: cm3 In-Reply-To: <20100705132228.0E6D52474003@birch.elegosoft.com> References: <20100705132228.0E6D52474003@birch.elegosoft.com> Message-ID: <759A98E1-3098-49B8-BC68-B9B3F54D4230@cs.purdue.edu> Jay, I am perplexed that we are adding things to Modula-3 source because of compiler backend brokenness just to avoid back-end warnings. Better to fix the backend so that RAISE is noreturn. This should not be difficult to do. On 5 Jul 2010, at 15:22, Jay Krell wrote: > CVSROOT: /usr/cvs > Changes by: jkrell at birch. 10/07/05 15:22:28 > > Modified files: > cm3/m3-tools/cvsup/suplib/src/text_cm3/: SupMiscText.m3 > > Log message: > ../src/text_cm3/SupMiscText.m3: In function 'SupMisc__DecodeWS': > ../src/text_cm3/SupMiscText.m3:211: warning: 'M3_Bkn9rd_ch' may be used uninitialized in this function > ../src/text_cm3/SupMiscText.m3:211: note: 'M3_Bkn9rd_ch' was declared here > > because raising an exception isn't currently "noreturn" > so initialize it to 0 From hosking at elego.de Mon Jul 5 21:12:02 2010 From: hosking at elego.de (Antony Hosking) Date: Mon, 5 Jul 2010 21:12:02 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100705191202.754142474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: hosking at birch. 10/07/05 21:12:02 Modified files: cm3/m3-sys/m3front/src/misc/: Scanner.m3 Log message: Canonicalize wide char literals to avoid duplicate M3ID for 'w' and 'W'. From jay.krell at cornell.edu Mon Jul 5 22:45:57 2010 From: jay.krell at cornell.edu (Jay K) Date: Mon, 5 Jul 2010 20:45:57 +0000 Subject: [M3commit] CVS Update: cm3 In-Reply-To: <759A98E1-3098-49B8-BC68-B9B3F54D4230@cs.purdue.edu> References: <20100705132228.0E6D52474003@birch.elegosoft.com>, <759A98E1-3098-49B8-BC68-B9B3F54D4230@cs.purdue.edu> Message-ID: I will maybe see about doing better here. Initializing locals doesn't seem like such a bad change though. I like the code to be "obviously correct" by a quick read by a human. ?- Jay ---------------------------------------- > From: hosking at cs.purdue.edu > Date: Mon, 5 Jul 2010 14:31:01 -0400 > To: jkrell at elego.de > CC: m3commit at elegosoft.com > Subject: Re: [M3commit] CVS Update: cm3 > > Jay, I am perplexed that we are adding things to Modula-3 source because of compiler backend brokenness just to avoid back-end warnings. Better to fix the backend so that RAISE is noreturn. This should not be difficult to do. > > On 5 Jul 2010, at 15:22, Jay Krell wrote: > > > CVSROOT: /usr/cvs > > Changes by: jkrell at birch. 10/07/05 15:22:28 > > > > Modified files: > > cm3/m3-tools/cvsup/suplib/src/text_cm3/: SupMiscText.m3 > > > > Log message: > > ../src/text_cm3/SupMiscText.m3: In function 'SupMisc__DecodeWS': > > ../src/text_cm3/SupMiscText.m3:211: warning: 'M3_Bkn9rd_ch' may be used uninitialized in this function > > ../src/text_cm3/SupMiscText.m3:211: note: 'M3_Bkn9rd_ch' was declared here > > > > because raising an exception isn't currently "noreturn" > > so initialize it to 0 > From hosking at cs.purdue.edu Mon Jul 5 22:50:00 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 5 Jul 2010 16:50:00 -0400 Subject: [M3commit] CVS Update: cm3 In-Reply-To: References: <20100705132228.0E6D52474003@birch.elegosoft.com>, <759A98E1-3098-49B8-BC68-B9B3F54D4230@cs.purdue.edu> Message-ID: <3B74FBBA-DEE1-43E8-AB9D-631AA959D6B4@cs.purdue.edu> But we've been this route before. Modula-3 ensures every variable is initialised with a valid value. I don't see how your adding an initialiser makes it more obviously correct. On 5 Jul 2010, at 16:45, Jay K wrote: > > I will maybe see about doing better here. > Initializing locals doesn't seem like such a bad change though. > I like the code to be "obviously correct" by a quick read by a human. > > - Jay > > ---------------------------------------- >> From: hosking at cs.purdue.edu >> Date: Mon, 5 Jul 2010 14:31:01 -0400 >> To: jkrell at elego.de >> CC: m3commit at elegosoft.com >> Subject: Re: [M3commit] CVS Update: cm3 >> >> Jay, I am perplexed that we are adding things to Modula-3 source because of compiler backend brokenness just to avoid back-end warnings. Better to fix the backend so that RAISE is noreturn. This should not be difficult to do. >> >> On 5 Jul 2010, at 15:22, Jay Krell wrote: >> >>> CVSROOT: /usr/cvs >>> Changes by: jkrell at birch. 10/07/05 15:22:28 >>> >>> Modified files: >>> cm3/m3-tools/cvsup/suplib/src/text_cm3/: SupMiscText.m3 >>> >>> Log message: >>> ../src/text_cm3/SupMiscText.m3: In function 'SupMisc__DecodeWS': >>> ../src/text_cm3/SupMiscText.m3:211: warning: 'M3_Bkn9rd_ch' may be used uninitialized in this function >>> ../src/text_cm3/SupMiscText.m3:211: note: 'M3_Bkn9rd_ch' was declared here >>> >>> because raising an exception isn't currently "noreturn" >>> so initialize it to 0 >> > From jay.krell at cornell.edu Mon Jul 5 23:15:35 2010 From: jay.krell at cornell.edu (Jay K) Date: Mon, 5 Jul 2010 21:15:35 +0000 Subject: [M3commit] CVS Update: cm3 In-Reply-To: <3B74FBBA-DEE1-43E8-AB9D-631AA959D6B4@cs.purdue.edu> References: <20100705132228.0E6D52474003@birch.elegosoft.com>, , <759A98E1-3098-49B8-BC68-B9B3F54D4230@cs.purdue.edu>, , <3B74FBBA-DEE1-43E8-AB9D-631AA959D6B4@cs.purdue.edu> Message-ID: At least some of these were Word.T. "valid" is still "random" and the code is unpredictable, at least by a quick read, even if type safe. Type safe is just a minimum bar, one that should always be exceeded, even if the compiler is completely unable to validate it. That is, the compiler guarantees are from sufficient relative to correctness. ?- Jay ---------------------------------------- > From: hosking at cs.purdue.edu > Date: Mon, 5 Jul 2010 16:50:00 -0400 > To: jay.krell at cornell.edu > CC: m3commit at elegosoft.com > Subject: Re: [M3commit] CVS Update: cm3 > > But we've been this route before. Modula-3 ensures every variable is initialised with a valid value. I don't see how your adding an initialiser makes it more obviously correct. > > On 5 Jul 2010, at 16:45, Jay K wrote: > > > > > I will maybe see about doing better here. > > Initializing locals doesn't seem like such a bad change though. > > I like the code to be "obviously correct" by a quick read by a human. > > > > - Jay > > > > ---------------------------------------- > >> From: hosking at cs.purdue.edu > >> Date: Mon, 5 Jul 2010 14:31:01 -0400 > >> To: jkrell at elego.de > >> CC: m3commit at elegosoft.com > >> Subject: Re: [M3commit] CVS Update: cm3 > >> > >> Jay, I am perplexed that we are adding things to Modula-3 source because of compiler backend brokenness just to avoid back-end warnings. Better to fix the backend so that RAISE is noreturn. This should not be difficult to do. > >> > >> On 5 Jul 2010, at 15:22, Jay Krell wrote: > >> > >>> CVSROOT: /usr/cvs > >>> Changes by: jkrell at birch. 10/07/05 15:22:28 > >>> > >>> Modified files: > >>> cm3/m3-tools/cvsup/suplib/src/text_cm3/: SupMiscText.m3 > >>> > >>> Log message: > >>> ../src/text_cm3/SupMiscText.m3: In function 'SupMisc__DecodeWS': > >>> ../src/text_cm3/SupMiscText.m3:211: warning: 'M3_Bkn9rd_ch' may be used uninitialized in this function > >>> ../src/text_cm3/SupMiscText.m3:211: note: 'M3_Bkn9rd_ch' was declared here > >>> > >>> because raising an exception isn't currently "noreturn" > >>> so initialize it to 0 > >> > > > From jkrell at elego.de Mon Jul 5 23:25:58 2010 From: jkrell at elego.de (Jay Krell) Date: Mon, 5 Jul 2010 23:25:58 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100705212558.2BCD72474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/05 23:25:58 Modified files: cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c Log message: rename "volatize" to "make_volatile" move existing code to function m3cg_make_volatile which will work for being called from front end, if we decide to do that (not done here) no real change here, just some renaming Note that the terminology is a bit off perhaps, in that I believe "volatile function" to gcc backend means "noreturn function". Here it means "all the locals, parameters, temporaries are volatile". ie. function calls setjmp/vfork. (This is actually overkill of course: it should only make volatile stuff used after the second return; this could actually still be defeating a fair amount of volatile removal -- any function with a "try".) From jay.krell at cornell.edu Mon Jul 5 23:26:58 2010 From: jay.krell at cornell.edu (Jay K) Date: Mon, 5 Jul 2010 21:26:58 +0000 Subject: [M3commit] CVS Update: cm3 In-Reply-To: <20100705212558.2BCD72474003@birch.elegosoft.com> References: <20100705212558.2BCD72474003@birch.elegosoft.com> Message-ID: attached ---------------------------------------- > Date: Mon, 5 Jul 2010 23: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/07/05 23:25:58 > > Modified files: > cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c > > Log message: > rename "volatize" to "make_volatile" > move existing code to function m3cg_make_volatile which > will work for being called from front end, if we decide to do that > (not done here) > no real change here, just some renaming > > Note that the terminology is a bit off perhaps, in that > I believe "volatile function" to gcc backend means > "noreturn function". Here it means "all the locals, parameters, > temporaries are volatile". ie. function calls setjmp/vfork. > (This is actually overkill of course: it should only make > volatile stuff used after the second return; this could actually > still be defeating a fair amount of volatile removal -- any > function with a "try".) > -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: rename_volatize.txt URL: From hosking at cs.purdue.edu Mon Jul 5 23:34:51 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 5 Jul 2010 17:34:51 -0400 Subject: [M3commit] CVS Update: cm3 In-Reply-To: References: <20100705132228.0E6D52474003@birch.elegosoft.com>, , <759A98E1-3098-49B8-BC68-B9B3F54D4230@cs.purdue.edu>, , <3B74FBBA-DEE1-43E8-AB9D-631AA959D6B4@cs.purdue.edu> Message-ID: <08FF7A56-401D-49FD-A943-155B94BE41C4@cs.purdue.edu> Huh? On 5 Jul 2010, at 17:15, Jay K wrote: > > At least some of these were Word.T. "valid" is still "random" and the code is unpredictable, at least by a quick read, even if type safe. > Type safe is just a minimum bar, one that should always be exceeded, even if the compiler is completely unable to validate it. > > That is, the compiler guarantees are from sufficient relative to correctness. > > - Jay > > ---------------------------------------- >> From: hosking at cs.purdue.edu >> Date: Mon, 5 Jul 2010 16:50:00 -0400 >> To: jay.krell at cornell.edu >> CC: m3commit at elegosoft.com >> Subject: Re: [M3commit] CVS Update: cm3 >> >> But we've been this route before. Modula-3 ensures every variable is initialised with a valid value. I don't see how your adding an initialiser makes it more obviously correct. >> >> On 5 Jul 2010, at 16:45, Jay K wrote: >> >>> >>> I will maybe see about doing better here. >>> Initializing locals doesn't seem like such a bad change though. >>> I like the code to be "obviously correct" by a quick read by a human. >>> >>> - Jay >>> >>> ---------------------------------------- >>>> From: hosking at cs.purdue.edu >>>> Date: Mon, 5 Jul 2010 14:31:01 -0400 >>>> To: jkrell at elego.de >>>> CC: m3commit at elegosoft.com >>>> Subject: Re: [M3commit] CVS Update: cm3 >>>> >>>> Jay, I am perplexed that we are adding things to Modula-3 source because of compiler backend brokenness just to avoid back-end warnings. Better to fix the backend so that RAISE is noreturn. This should not be difficult to do. >>>> >>>> On 5 Jul 2010, at 15:22, Jay Krell wrote: >>>> >>>>> CVSROOT: /usr/cvs >>>>> Changes by: jkrell at birch. 10/07/05 15:22:28 >>>>> >>>>> Modified files: >>>>> cm3/m3-tools/cvsup/suplib/src/text_cm3/: SupMiscText.m3 >>>>> >>>>> Log message: >>>>> ../src/text_cm3/SupMiscText.m3: In function 'SupMisc__DecodeWS': >>>>> ../src/text_cm3/SupMiscText.m3:211: warning: 'M3_Bkn9rd_ch' may be used uninitialized in this function >>>>> ../src/text_cm3/SupMiscText.m3:211: note: 'M3_Bkn9rd_ch' was declared here >>>>> >>>>> because raising an exception isn't currently "noreturn" >>>>> so initialize it to 0 >>>> >>> >> > From hosking at cs.purdue.edu Mon Jul 5 23:35:38 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 5 Jul 2010 17:35:38 -0400 Subject: [M3commit] CVS Update: cm3 In-Reply-To: <20100705212558.2BCD72474003@birch.elegosoft.com> References: <20100705212558.2BCD72474003@birch.elegosoft.com> Message-ID: volatize is terminology from the gcc backend. It is used only for exception frames. I don't think you should make this change. On 5 Jul 2010, at 23:25, Jay Krell wrote: > CVSROOT: /usr/cvs > Changes by: jkrell at birch. 10/07/05 23:25:58 > > Modified files: > cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c > > Log message: > rename "volatize" to "make_volatile" > move existing code to function m3cg_make_volatile which > will work for being called from front end, if we decide to do that > (not done here) > no real change here, just some renaming > > Note that the terminology is a bit off perhaps, in that > I believe "volatile function" to gcc backend means > "noreturn function". Here it means "all the locals, parameters, > temporaries are volatile". ie. function calls setjmp/vfork. > (This is actually overkill of course: it should only make > volatile stuff used after the second return; this could actually > still be defeating a fair amount of volatile removal -- any > function with a "try".) From hosking at cs.purdue.edu Mon Jul 5 23:37:00 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 5 Jul 2010 17:37:00 -0400 Subject: [M3commit] CVS Update: cm3 In-Reply-To: References: <20100705212558.2BCD72474003@birch.elegosoft.com> Message-ID: You are conflating two distinct issues here. volatize is there for a different reason, and should retain its name. On 5 Jul 2010, at 17:26, Jay K wrote: > > > attached > > > ---------------------------------------- >> Date: Mon, 5 Jul 2010 23: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/07/05 23:25:58 >> >> Modified files: >> cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c >> >> Log message: >> rename "volatize" to "make_volatile" >> move existing code to function m3cg_make_volatile which >> will work for being called from front end, if we decide to do that >> (not done here) >> no real change here, just some renaming >> >> Note that the terminology is a bit off perhaps, in that >> I believe "volatile function" to gcc backend means >> "noreturn function". Here it means "all the locals, parameters, >> temporaries are volatile". ie. function calls setjmp/vfork. >> (This is actually overkill of course: it should only make >> volatile stuff used after the second return; this could actually >> still be defeating a fair amount of volatile removal -- any >> function with a "try".) >> > From jkrell at elego.de Mon Jul 5 23:39:19 2010 From: jkrell at elego.de (Jay Krell) Date: Mon, 5 Jul 2010 23:39:19 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100705213919.43D2E2474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/05 23:39:19 Modified files: cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c Log message: go back a version to 215, restoring 'volatilize'/'volatize' names From jay.krell at cornell.edu Mon Jul 5 23:39:23 2010 From: jay.krell at cornell.edu (Jay K) Date: Mon, 5 Jul 2010 21:39:23 +0000 Subject: [M3commit] CVS Update: cm3 In-Reply-To: References: <20100705212558.2BCD72474003@birch.elegosoft.com>, , Message-ID: ok ---------------------------------------- > From: hosking at cs.purdue.edu > Date: Mon, 5 Jul 2010 17:37:00 -0400 > To: jay.krell at cornell.edu > CC: m3commit at elegosoft.com > Subject: Re: [M3commit] CVS Update: cm3 > > You are conflating two distinct issues here. volatize is there for a different reason, and should retain its name. > > On 5 Jul 2010, at 17:26, Jay K wrote: > > > > > > > attached > > > > > > ---------------------------------------- > >> Date: Mon, 5 Jul 2010 23: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/07/05 23:25:58 > >> > >> Modified files: > >> cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c > >> > >> Log message: > >> rename "volatize" to "make_volatile" > >> move existing code to function m3cg_make_volatile which > >> will work for being called from front end, if we decide to do that > >> (not done here) > >> no real change here, just some renaming > >> > >> Note that the terminology is a bit off perhaps, in that > >> I believe "volatile function" to gcc backend means > >> "noreturn function". Here it means "all the locals, parameters, > >> temporaries are volatile". ie. function calls setjmp/vfork. > >> (This is actually overkill of course: it should only make > >> volatile stuff used after the second return; this could actually > >> still be defeating a fair amount of volatile removal -- any > >> function with a "try".) > >> > > > From hosking at cs.purdue.edu Mon Jul 5 23:40:50 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 5 Jul 2010 17:40:50 -0400 Subject: [M3commit] CVS Update: cm3 In-Reply-To: References: <20100705132228.0E6D52474003@birch.elegosoft.com>, , <759A98E1-3098-49B8-BC68-B9B3F54D4230@cs.purdue.edu>, , <3B74FBBA-DEE1-43E8-AB9D-631AA959D6B4@cs.purdue.edu> , <08FF7A56-401D-49FD-A943-155B94BE41C4@cs.purdue.edu> Message-ID: <5BDC54D6-DB79-4E9E-928A-CD802B274B7B@cs.purdue.edu> But the front-end should be OK with the first. It is "correct" because whatever value is in a when F1 is called is legal for a. Why should the backend give a warning? The semantics of Modula-3 allow any legal bit-value for a variable as its initial value. You will force an initialising assignment when none is required by the language spec. On 5 Jul 2010, at 17:36, Jay K wrote: > > unsigned F1() > { > unsigned a; > return a; > } > > should generate a warning. > > unsigned F1() > > { > > unsigned a = 0; > > return a; > > } > > > is much preferred. > > Just because the front end is ok with the first, doesn't make it correct. > > - Jay > > ---------------------------------------- >> Subject: Re: [M3commit] CVS Update: cm3 >> From: hosking at cs.purdue.edu >> Date: Mon, 5 Jul 2010 17:34:51 -0400 >> CC: m3commit at elegosoft.com >> To: jay.krell at cornell.edu >> >> Huh? >> >> On 5 Jul 2010, at 17:15, Jay K wrote: >> >>> >>> At least some of these were Word.T. "valid" is still "random" and the code is unpredictable, at least by a quick read, even if type safe. >>> Type safe is just a minimum bar, one that should always be exceeded, even if the compiler is completely unable to validate it. >>> >>> That is, the compiler guarantees are from sufficient relative to correctness. >>> >>> - Jay >>> >>> ---------------------------------------- >>>> From: hosking at cs.purdue.edu >>>> Date: Mon, 5 Jul 2010 16:50:00 -0400 >>>> To: jay.krell at cornell.edu >>>> CC: m3commit at elegosoft.com >>>> Subject: Re: [M3commit] CVS Update: cm3 >>>> >>>> But we've been this route before. Modula-3 ensures every variable is initialised with a valid value. I don't see how your adding an initialiser makes it more obviously correct. >>>> >>>> On 5 Jul 2010, at 16:45, Jay K wrote: >>>> >>>>> >>>>> I will maybe see about doing better here. >>>>> Initializing locals doesn't seem like such a bad change though. >>>>> I like the code to be "obviously correct" by a quick read by a human. >>>>> >>>>> - Jay >>>>> >>>>> ---------------------------------------- >>>>>> From: hosking at cs.purdue.edu >>>>>> Date: Mon, 5 Jul 2010 14:31:01 -0400 >>>>>> To: jkrell at elego.de >>>>>> CC: m3commit at elegosoft.com >>>>>> Subject: Re: [M3commit] CVS Update: cm3 >>>>>> >>>>>> Jay, I am perplexed that we are adding things to Modula-3 source because of compiler backend brokenness just to avoid back-end warnings. Better to fix the backend so that RAISE is noreturn. This should not be difficult to do. >>>>>> >>>>>> On 5 Jul 2010, at 15:22, Jay Krell wrote: >>>>>> >>>>>>> CVSROOT: /usr/cvs >>>>>>> Changes by: jkrell at birch. 10/07/05 15:22:28 >>>>>>> >>>>>>> Modified files: >>>>>>> cm3/m3-tools/cvsup/suplib/src/text_cm3/: SupMiscText.m3 >>>>>>> >>>>>>> Log message: >>>>>>> ../src/text_cm3/SupMiscText.m3: In function 'SupMisc__DecodeWS': >>>>>>> ../src/text_cm3/SupMiscText.m3:211: warning: 'M3_Bkn9rd_ch' may be used uninitialized in this function >>>>>>> ../src/text_cm3/SupMiscText.m3:211: note: 'M3_Bkn9rd_ch' was declared here >>>>>>> >>>>>>> because raising an exception isn't currently "noreturn" >>>>>>> so initialize it to 0 >>>>>> >>>>> >>>> >>> >> > From jay.krell at cornell.edu Mon Jul 5 23:36:52 2010 From: jay.krell at cornell.edu (Jay K) Date: Mon, 5 Jul 2010 21:36:52 +0000 Subject: [M3commit] CVS Update: cm3 In-Reply-To: <08FF7A56-401D-49FD-A943-155B94BE41C4@cs.purdue.edu> References: <20100705132228.0E6D52474003@birch.elegosoft.com>, , <759A98E1-3098-49B8-BC68-B9B3F54D4230@cs.purdue.edu>, , <3B74FBBA-DEE1-43E8-AB9D-631AA959D6B4@cs.purdue.edu> , <08FF7A56-401D-49FD-A943-155B94BE41C4@cs.purdue.edu> Message-ID: unsigned F1() { ?unsigned a; return a; } should generate a warning. unsigned F1() { ?unsigned a = 0; return a; } is much preferred. Just because the front end is ok with the first, doesn't make it correct. ?- Jay ---------------------------------------- > Subject: Re: [M3commit] CVS Update: cm3 > From: hosking at cs.purdue.edu > Date: Mon, 5 Jul 2010 17:34:51 -0400 > CC: m3commit at elegosoft.com > To: jay.krell at cornell.edu > > Huh? > > On 5 Jul 2010, at 17:15, Jay K wrote: > > > > > At least some of these were Word.T. "valid" is still "random" and the code is unpredictable, at least by a quick read, even if type safe. > > Type safe is just a minimum bar, one that should always be exceeded, even if the compiler is completely unable to validate it. > > > > That is, the compiler guarantees are from sufficient relative to correctness. > > > > - Jay > > > > ---------------------------------------- > >> From: hosking at cs.purdue.edu > >> Date: Mon, 5 Jul 2010 16:50:00 -0400 > >> To: jay.krell at cornell.edu > >> CC: m3commit at elegosoft.com > >> Subject: Re: [M3commit] CVS Update: cm3 > >> > >> But we've been this route before. Modula-3 ensures every variable is initialised with a valid value. I don't see how your adding an initialiser makes it more obviously correct. > >> > >> On 5 Jul 2010, at 16:45, Jay K wrote: > >> > >>> > >>> I will maybe see about doing better here. > >>> Initializing locals doesn't seem like such a bad change though. > >>> I like the code to be "obviously correct" by a quick read by a human. > >>> > >>> - Jay > >>> > >>> ---------------------------------------- > >>>> From: hosking at cs.purdue.edu > >>>> Date: Mon, 5 Jul 2010 14:31:01 -0400 > >>>> To: jkrell at elego.de > >>>> CC: m3commit at elegosoft.com > >>>> Subject: Re: [M3commit] CVS Update: cm3 > >>>> > >>>> Jay, I am perplexed that we are adding things to Modula-3 source because of compiler backend brokenness just to avoid back-end warnings. Better to fix the backend so that RAISE is noreturn. This should not be difficult to do. > >>>> > >>>> On 5 Jul 2010, at 15:22, Jay Krell wrote: > >>>> > >>>>> CVSROOT: /usr/cvs > >>>>> Changes by: jkrell at birch. 10/07/05 15:22:28 > >>>>> > >>>>> Modified files: > >>>>> cm3/m3-tools/cvsup/suplib/src/text_cm3/: SupMiscText.m3 > >>>>> > >>>>> Log message: > >>>>> ../src/text_cm3/SupMiscText.m3: In function 'SupMisc__DecodeWS': > >>>>> ../src/text_cm3/SupMiscText.m3:211: warning: 'M3_Bkn9rd_ch' may be used uninitialized in this function > >>>>> ../src/text_cm3/SupMiscText.m3:211: note: 'M3_Bkn9rd_ch' was declared here > >>>>> > >>>>> because raising an exception isn't currently "noreturn" > >>>>> so initialize it to 0 > >>>> > >>> > >> > > > From jay.krell at cornell.edu Mon Jul 5 23:46:49 2010 From: jay.krell at cornell.edu (Jay K) Date: Mon, 5 Jul 2010 21:46:49 +0000 Subject: [M3commit] CVS Update: cm3 In-Reply-To: <5BDC54D6-DB79-4E9E-928A-CD802B274B7B@cs.purdue.edu> References: <20100705132228.0E6D52474003@birch.elegosoft.com>, , , <759A98E1-3098-49B8-BC68-B9B3F54D4230@cs.purdue.edu>, , , , <3B74FBBA-DEE1-43E8-AB9D-631AA959D6B4@cs.purdue.edu>, , , <08FF7A56-401D-49FD-A943-155B94BE41C4@cs.purdue.edu>, , <5BDC54D6-DB79-4E9E-928A-CD802B274B7B@cs.purdue.edu> Message-ID: Meeting the language spec is inadequate. It is a "quality of implementation" thing. Do you want your C compiler to be silent about this code? No. Or do you want it to try a little harder and point out bugs in your code? Even where it meets the language spec? Yes. ?? Maybe meeting the language spec is more meaningful for Modula-3 than for C, but still inadequate. Now, compiler can't in general be a "correct program proofer", but it can and does catch a few things and that is a good thing not to be avoided. - Jay ---------------------------------------- > From: hosking at cs.purdue.edu > Date: Mon, 5 Jul 2010 17:40:50 -0400 > To: jay.krell at cornell.edu > CC: m3commit at elegosoft.com > Subject: Re: [M3commit] CVS Update: cm3 > > But the front-end should be OK with the first. It is "correct" because whatever value is in a when F1 is called is legal for a. Why should the backend give a warning? The semantics of Modula-3 allow any legal bit-value for a variable as its initial value. You will force an initialising assignment when none is required by the language spec. > > On 5 Jul 2010, at 17:36, Jay K wrote: > > > > > unsigned F1() > > { > > unsigned a; > > return a; > > } > > > > should generate a warning. > > > > unsigned F1() > > > > { > > > > unsigned a = 0; > > > > return a; > > > > } > > > > > > is much preferred. > > > > Just because the front end is ok with the first, doesn't make it correct. > > > > - Jay > > > > ---------------------------------------- > >> Subject: Re: [M3commit] CVS Update: cm3 > >> From: hosking at cs.purdue.edu > >> Date: Mon, 5 Jul 2010 17:34:51 -0400 > >> CC: m3commit at elegosoft.com > >> To: jay.krell at cornell.edu > >> > >> Huh? > >> > >> On 5 Jul 2010, at 17:15, Jay K wrote: > >> > >>> > >>> At least some of these were Word.T. "valid" is still "random" and the code is unpredictable, at least by a quick read, even if type safe. > >>> Type safe is just a minimum bar, one that should always be exceeded, even if the compiler is completely unable to validate it. > >>> > >>> That is, the compiler guarantees are from sufficient relative to correctness. > >>> > >>> - Jay > >>> > >>> ---------------------------------------- > >>>> From: hosking at cs.purdue.edu > >>>> Date: Mon, 5 Jul 2010 16:50:00 -0400 > >>>> To: jay.krell at cornell.edu > >>>> CC: m3commit at elegosoft.com > >>>> Subject: Re: [M3commit] CVS Update: cm3 > >>>> > >>>> But we've been this route before. Modula-3 ensures every variable is initialised with a valid value. I don't see how your adding an initialiser makes it more obviously correct. > >>>> > >>>> On 5 Jul 2010, at 16:45, Jay K wrote: > >>>> > >>>>> > >>>>> I will maybe see about doing better here. > >>>>> Initializing locals doesn't seem like such a bad change though. > >>>>> I like the code to be "obviously correct" by a quick read by a human. > >>>>> > >>>>> - Jay > >>>>> > >>>>> ---------------------------------------- > >>>>>> From: hosking at cs.purdue.edu > >>>>>> Date: Mon, 5 Jul 2010 14:31:01 -0400 > >>>>>> To: jkrell at elego.de > >>>>>> CC: m3commit at elegosoft.com > >>>>>> Subject: Re: [M3commit] CVS Update: cm3 > >>>>>> > >>>>>> Jay, I am perplexed that we are adding things to Modula-3 source because of compiler backend brokenness just to avoid back-end warnings. Better to fix the backend so that RAISE is noreturn. This should not be difficult to do. > >>>>>> > >>>>>> On 5 Jul 2010, at 15:22, Jay Krell wrote: > >>>>>> > >>>>>>> CVSROOT: /usr/cvs > >>>>>>> Changes by: jkrell at birch. 10/07/05 15:22:28 > >>>>>>> > >>>>>>> Modified files: > >>>>>>> cm3/m3-tools/cvsup/suplib/src/text_cm3/: SupMiscText.m3 > >>>>>>> > >>>>>>> Log message: > >>>>>>> ../src/text_cm3/SupMiscText.m3: In function 'SupMisc__DecodeWS': > >>>>>>> ../src/text_cm3/SupMiscText.m3:211: warning: 'M3_Bkn9rd_ch' may be used uninitialized in this function > >>>>>>> ../src/text_cm3/SupMiscText.m3:211: note: 'M3_Bkn9rd_ch' was declared here > >>>>>>> > >>>>>>> because raising an exception isn't currently "noreturn" > >>>>>>> so initialize it to 0 > >>>>>> > >>>>> > >>>> > >>> > >> > > > From jay.krell at cornell.edu Mon Jul 5 23:51:27 2010 From: jay.krell at cornell.edu (Jay K) Date: Mon, 5 Jul 2010 21:51:27 +0000 Subject: [M3commit] CVS Update: cm3 In-Reply-To: <08FF7A56-401D-49FD-A943-155B94BE41C4@cs.purdue.edu> References: <20100705132228.0E6D52474003@birch.elegosoft.com>, , <759A98E1-3098-49B8-BC68-B9B3F54D4230@cs.purdue.edu>, , <3B74FBBA-DEE1-43E8-AB9D-631AA959D6B4@cs.purdue.edu> , <08FF7A56-401D-49FD-A943-155B94BE41C4@cs.purdue.edu> Message-ID: As a human reading code (very finite cycles), I don't like to see: VAR a: type; BEGIN ... END no matter the contents of "...". I'd much rather see: VAR a: type := 0; and know very quickly and without a doubt that a is never used uninitialized. I've been bitten too much by microoptimizations around not initializing locals. Some large fraction of the time the compiler will optimize away the initialization. ? (ie. depending on the contents of "...") Some other large fraction of the time the performance difference will be unmeasurable. ?? So much code is I/O bound already, let alone compute bound by more significant "algorithmic" factors. And then some small fraction of the time, maybe, it will be a bad pessimization. I just don't think it is worth the risk. ?- Jay ---------------------------------------- > Subject: Re: [M3commit] CVS Update: cm3 > From: hosking at cs.purdue.edu > Date: Mon, 5 Jul 2010 17:34:51 -0400 > CC: m3commit at elegosoft.com > To: jay.krell at cornell.edu > > Huh? > > On 5 Jul 2010, at 17:15, Jay K wrote: > > > > > At least some of these were Word.T. "valid" is still "random" and the code is unpredictable, at least by a quick read, even if type safe. > > Type safe is just a minimum bar, one that should always be exceeded, even if the compiler is completely unable to validate it. > > > > That is, the compiler guarantees are from sufficient relative to correctness. > > > > - Jay > > > > ---------------------------------------- > >> From: hosking at cs.purdue.edu > >> Date: Mon, 5 Jul 2010 16:50:00 -0400 > >> To: jay.krell at cornell.edu > >> CC: m3commit at elegosoft.com > >> Subject: Re: [M3commit] CVS Update: cm3 > >> > >> But we've been this route before. Modula-3 ensures every variable is initialised with a valid value. I don't see how your adding an initialiser makes it more obviously correct. > >> > >> On 5 Jul 2010, at 16:45, Jay K wrote: > >> > >>> > >>> I will maybe see about doing better here. > >>> Initializing locals doesn't seem like such a bad change though. > >>> I like the code to be "obviously correct" by a quick read by a human. > >>> > >>> - Jay > >>> > >>> ---------------------------------------- > >>>> From: hosking at cs.purdue.edu > >>>> Date: Mon, 5 Jul 2010 14:31:01 -0400 > >>>> To: jkrell at elego.de > >>>> CC: m3commit at elegosoft.com > >>>> Subject: Re: [M3commit] CVS Update: cm3 > >>>> > >>>> Jay, I am perplexed that we are adding things to Modula-3 source because of compiler backend brokenness just to avoid back-end warnings. Better to fix the backend so that RAISE is noreturn. This should not be difficult to do. > >>>> > >>>> On 5 Jul 2010, at 15:22, Jay Krell wrote: > >>>> > >>>>> CVSROOT: /usr/cvs > >>>>> Changes by: jkrell at birch. 10/07/05 15:22:28 > >>>>> > >>>>> Modified files: > >>>>> cm3/m3-tools/cvsup/suplib/src/text_cm3/: SupMiscText.m3 > >>>>> > >>>>> Log message: > >>>>> ../src/text_cm3/SupMiscText.m3: In function 'SupMisc__DecodeWS': > >>>>> ../src/text_cm3/SupMiscText.m3:211: warning: 'M3_Bkn9rd_ch' may be used uninitialized in this function > >>>>> ../src/text_cm3/SupMiscText.m3:211: note: 'M3_Bkn9rd_ch' was declared here > >>>>> > >>>>> because raising an exception isn't currently "noreturn" > >>>>> so initialize it to 0 > >>>> > >>> > >> > > > From jkrell at elego.de Tue Jul 6 00:16:43 2010 From: jkrell at elego.de (Jay Krell) Date: Tue, 6 Jul 2010 0:16:43 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100705221643.6A4042474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/06 00:16:43 Modified files: cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c Log message: add some asserts around bit field offsets and sizes, that they are all <= 64 and <= TYPE_PRECISION, as well their sums are (which is redundant but ok) one small branch of insert looks pointless, assert(false) From jay.krell at cornell.edu Tue Jul 6 00:18:24 2010 From: jay.krell at cornell.edu (Jay K) Date: Mon, 5 Jul 2010 22:18:24 +0000 Subject: [M3commit] CVS Update: cm3 In-Reply-To: <20100705221643.6A4042474003@birch.elegosoft.com> References: <20100705221643.6A4042474003@birch.elegosoft.com> Message-ID: ---------------------------------------- > Date: Tue, 6 Jul 2010 00:16:43 +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/07/06 00:16:43 > > Modified files: > cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c > > Log message: > add some asserts around bit field offsets and sizes, > that they are all <= 64 and <= TYPE_PRECISION, as well > their sums are (which is redundant but ok) > one small branch of insert looks pointless, assert(false) -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: bitfield_asserts.txt URL: From jay.krell at cornell.edu Tue Jul 6 00:22:53 2010 From: jay.krell at cornell.edu (Jay K) Date: Mon, 5 Jul 2010 22:22:53 +0000 Subject: [M3commit] CVS Update: cm3 In-Reply-To: References: <20100705132228.0E6D52474003@birch.elegosoft.com>, , , <759A98E1-3098-49B8-BC68-B9B3F54D4230@cs.purdue.edu>, , , , <3B74FBBA-DEE1-43E8-AB9D-631AA959D6B4@cs.purdue.edu>, Message-ID: > That is, the compiler guarantees are from sufficient relative to correctness. Was supposed to say *far* from sufficient.. - Jay From hosking at cs.purdue.edu Tue Jul 6 00:42:20 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 5 Jul 2010 18:42:20 -0400 Subject: [M3commit] CVS Update: cm3 In-Reply-To: References: <20100705132228.0E6D52474003@birch.elegosoft.com>, , , <759A98E1-3098-49B8-BC68-B9B3F54D4230@cs.purdue.edu>, , , , <3B74FBBA-DEE1-43E8-AB9D-631AA959D6B4@cs.purdue.edu>, , , <08FF7A56-401D-49FD-A943-155B94BE41C4@cs.purdue.edu>, , <5BDC54D6-DB79-4E9E-928A-CD802B274B7B@cs.purdue.edu> Message-ID: <5C74B751-B423-4919-A990-130C384D2CA9@cs.purdue.edu> Your C compiler will be silent about this code unless you ask it to warn you. On 5 Jul 2010, at 17:46, Jay K wrote: > Meeting the language spec is inadequate. What? > It is a "quality of implementation" thing. > Do you want your C compiler to be silent about this code? No. Why not? > Or do you want it to try a little harder and point out bugs in your code? Those are C bugs because C says nothing about variable initialisation. > Even where it meets the language spec? Yes. > Maybe meeting the language spec is more meaningful for Modula-3 than for C, but still inadequate. > Now, compiler can't in general be a "correct program proofer", but it can and does catch a few things and that is a good thing not to be avoided. > > > - Jay > > ---------------------------------------- >> From: hosking at cs.purdue.edu >> Date: Mon, 5 Jul 2010 17:40:50 -0400 >> To: jay.krell at cornell.edu >> CC: m3commit at elegosoft.com >> Subject: Re: [M3commit] CVS Update: cm3 >> >> But the front-end should be OK with the first. It is "correct" because whatever value is in a when F1 is called is legal for a. Why should the backend give a warning? The semantics of Modula-3 allow any legal bit-value for a variable as its initial value. You will force an initialising assignment when none is required by the language spec. >> >> On 5 Jul 2010, at 17:36, Jay K wrote: >> >>> >>> unsigned F1() >>> { >>> unsigned a; >>> return a; >>> } >>> >>> should generate a warning. >>> >>> unsigned F1() >>> >>> { >>> >>> unsigned a = 0; >>> >>> return a; >>> >>> } >>> >>> >>> is much preferred. >>> >>> Just because the front end is ok with the first, doesn't make it correct. >>> >>> - Jay >>> >>> ---------------------------------------- >>>> Subject: Re: [M3commit] CVS Update: cm3 >>>> From: hosking at cs.purdue.edu >>>> Date: Mon, 5 Jul 2010 17:34:51 -0400 >>>> CC: m3commit at elegosoft.com >>>> To: jay.krell at cornell.edu >>>> >>>> Huh? >>>> >>>> On 5 Jul 2010, at 17:15, Jay K wrote: >>>> >>>>> >>>>> At least some of these were Word.T. "valid" is still "random" and the code is unpredictable, at least by a quick read, even if type safe. >>>>> Type safe is just a minimum bar, one that should always be exceeded, even if the compiler is completely unable to validate it. >>>>> >>>>> That is, the compiler guarantees are from sufficient relative to correctness. >>>>> >>>>> - Jay >>>>> >>>>> ---------------------------------------- >>>>>> From: hosking at cs.purdue.edu >>>>>> Date: Mon, 5 Jul 2010 16:50:00 -0400 >>>>>> To: jay.krell at cornell.edu >>>>>> CC: m3commit at elegosoft.com >>>>>> Subject: Re: [M3commit] CVS Update: cm3 >>>>>> >>>>>> But we've been this route before. Modula-3 ensures every variable is initialised with a valid value. I don't see how your adding an initialiser makes it more obviously correct. >>>>>> >>>>>> On 5 Jul 2010, at 16:45, Jay K wrote: >>>>>> >>>>>>> >>>>>>> I will maybe see about doing better here. >>>>>>> Initializing locals doesn't seem like such a bad change though. >>>>>>> I like the code to be "obviously correct" by a quick read by a human. >>>>>>> >>>>>>> - Jay >>>>>>> >>>>>>> ---------------------------------------- >>>>>>>> From: hosking at cs.purdue.edu >>>>>>>> Date: Mon, 5 Jul 2010 14:31:01 -0400 >>>>>>>> To: jkrell at elego.de >>>>>>>> CC: m3commit at elegosoft.com >>>>>>>> Subject: Re: [M3commit] CVS Update: cm3 >>>>>>>> >>>>>>>> Jay, I am perplexed that we are adding things to Modula-3 source because of compiler backend brokenness just to avoid back-end warnings. Better to fix the backend so that RAISE is noreturn. This should not be difficult to do. >>>>>>>> >>>>>>>> On 5 Jul 2010, at 15:22, Jay Krell wrote: >>>>>>>> >>>>>>>>> CVSROOT: /usr/cvs >>>>>>>>> Changes by: jkrell at birch. 10/07/05 15:22:28 >>>>>>>>> >>>>>>>>> Modified files: >>>>>>>>> cm3/m3-tools/cvsup/suplib/src/text_cm3/: SupMiscText.m3 >>>>>>>>> >>>>>>>>> Log message: >>>>>>>>> ../src/text_cm3/SupMiscText.m3: In function 'SupMisc__DecodeWS': >>>>>>>>> ../src/text_cm3/SupMiscText.m3:211: warning: 'M3_Bkn9rd_ch' may be used uninitialized in this function >>>>>>>>> ../src/text_cm3/SupMiscText.m3:211: note: 'M3_Bkn9rd_ch' was declared here >>>>>>>>> >>>>>>>>> because raising an exception isn't currently "noreturn" >>>>>>>>> so initialize it to 0 >>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >> > From hosking at cs.purdue.edu Tue Jul 6 00:44:16 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 5 Jul 2010 18:44:16 -0400 Subject: [M3commit] CVS Update: cm3 In-Reply-To: References: <20100705132228.0E6D52474003@birch.elegosoft.com>, , <759A98E1-3098-49B8-BC68-B9B3F54D4230@cs.purdue.edu>, , <3B74FBBA-DEE1-43E8-AB9D-631AA959D6B4@cs.purdue.edu> , <08FF7A56-401D-49FD-A943-155B94BE41C4@cs.purdue.edu> Message-ID: <6331F39C-AA28-4AC1-8C87-3D47D52D0C55@cs.purdue.edu> That is you view, but at odds with why Modula-3 was designed the way it was. I think we've already had this conversation before. The point is that even when a variable is initialised to 0 as you prefer there may still be bugs in the program. You are seeing Modula-3 through C spectacles, where so much of the language is undefined. On 5 Jul 2010, at 17:51, Jay K wrote: > > As a human reading code (very finite cycles), I don't like to see: > > > VAR a: type; > BEGIN > ... > END > > > no matter the contents of "...". > > > I'd much rather see: > > > VAR a: type := 0; > > > > and know very quickly and without a doubt that a is never used uninitialized. > I've been bitten too much by microoptimizations around not initializing locals. > Some large fraction of the time the compiler will optimize away the initialization. > (ie. depending on the contents of "...") > Some other large fraction of the time the performance difference will be unmeasurable. > So much code is I/O bound already, let alone compute bound by more significant "algorithmic" factors. > And then some small fraction of the time, maybe, it will be a bad pessimization. > > > I just don't think it is worth the risk. > > > - Jay > > > > ---------------------------------------- >> Subject: Re: [M3commit] CVS Update: cm3 >> From: hosking at cs.purdue.edu >> Date: Mon, 5 Jul 2010 17:34:51 -0400 >> CC: m3commit at elegosoft.com >> To: jay.krell at cornell.edu >> >> Huh? >> >> On 5 Jul 2010, at 17:15, Jay K wrote: >> >>> >>> At least some of these were Word.T. "valid" is still "random" and the code is unpredictable, at least by a quick read, even if type safe. >>> Type safe is just a minimum bar, one that should always be exceeded, even if the compiler is completely unable to validate it. >>> >>> That is, the compiler guarantees are from sufficient relative to correctness. >>> >>> - Jay >>> >>> ---------------------------------------- >>>> From: hosking at cs.purdue.edu >>>> Date: Mon, 5 Jul 2010 16:50:00 -0400 >>>> To: jay.krell at cornell.edu >>>> CC: m3commit at elegosoft.com >>>> Subject: Re: [M3commit] CVS Update: cm3 >>>> >>>> But we've been this route before. Modula-3 ensures every variable is initialised with a valid value. I don't see how your adding an initialiser makes it more obviously correct. >>>> >>>> On 5 Jul 2010, at 16:45, Jay K wrote: >>>> >>>>> >>>>> I will maybe see about doing better here. >>>>> Initializing locals doesn't seem like such a bad change though. >>>>> I like the code to be "obviously correct" by a quick read by a human. >>>>> >>>>> - Jay >>>>> >>>>> ---------------------------------------- >>>>>> From: hosking at cs.purdue.edu >>>>>> Date: Mon, 5 Jul 2010 14:31:01 -0400 >>>>>> To: jkrell at elego.de >>>>>> CC: m3commit at elegosoft.com >>>>>> Subject: Re: [M3commit] CVS Update: cm3 >>>>>> >>>>>> Jay, I am perplexed that we are adding things to Modula-3 source because of compiler backend brokenness just to avoid back-end warnings. Better to fix the backend so that RAISE is noreturn. This should not be difficult to do. >>>>>> >>>>>> On 5 Jul 2010, at 15:22, Jay Krell wrote: >>>>>> >>>>>>> CVSROOT: /usr/cvs >>>>>>> Changes by: jkrell at birch. 10/07/05 15:22:28 >>>>>>> >>>>>>> Modified files: >>>>>>> cm3/m3-tools/cvsup/suplib/src/text_cm3/: SupMiscText.m3 >>>>>>> >>>>>>> Log message: >>>>>>> ../src/text_cm3/SupMiscText.m3: In function 'SupMisc__DecodeWS': >>>>>>> ../src/text_cm3/SupMiscText.m3:211: warning: 'M3_Bkn9rd_ch' may be used uninitialized in this function >>>>>>> ../src/text_cm3/SupMiscText.m3:211: note: 'M3_Bkn9rd_ch' was declared here >>>>>>> >>>>>>> because raising an exception isn't currently "noreturn" >>>>>>> so initialize it to 0 >>>>>> >>>>> >>>> >>> >> > From jay.krell at cornell.edu Tue Jul 6 00:54:38 2010 From: jay.krell at cornell.edu (Jay K) Date: Mon, 5 Jul 2010 22:54:38 +0000 Subject: [M3commit] CVS Update: cm3 In-Reply-To: <5C74B751-B423-4919-A990-130C384D2CA9@cs.purdue.edu> References: <20100705132228.0E6D52474003@birch.elegosoft.com>, , ,,<759A98E1-3098-49B8-BC68-B9B3F54D4230@cs.purdue.edu>, ,,, , , <3B74FBBA-DEE1-43E8-AB9D-631AA959D6B4@cs.purdue.edu>, , , , , <08FF7A56-401D-49FD-A943-155B94BE41C4@cs.purdue.edu>, , , , <5BDC54D6-DB79-4E9E-928A-CD802B274B7B@cs.purdue.edu>, , <5C74B751-B423-4919-A990-130C384D2CA9@cs.purdue.edu> Message-ID: ?> Your C compiler will be silent about this code unless you ask it to warn you. ?These days, most people know to ask for these warnings. ?The warnings are fairly accurate and more often find real bugs than complain about correct code. ?> > Do you want your C compiler to be silent about this code? No. ?> Why not. The compiler, at least when optimizing (doing data/control flow analysis), can easily find bugs in code. Asking it not to is just the wrong thing to do. ?- Jay ---------------------------------------- > From: hosking at cs.purdue.edu > Date: Mon, 5 Jul 2010 18:42:20 -0400 > To: jay.krell at cornell.edu > CC: m3commit at elegosoft.com > Subject: Re: [M3commit] CVS Update: cm3 > > Your C compiler will be silent about this code unless you ask it to warn you. > > On 5 Jul 2010, at 17:46, Jay K wrote: > > > Meeting the language spec is inadequate. > > What? > > > It is a "quality of implementation" thing. > > Do you want your C compiler to be silent about this code? No. > > Why not? > > > Or do you want it to try a little harder and point out bugs in your code? > > Those are C bugs because C says nothing about variable initialisation. > > > Even where it meets the language spec? Yes. > > Maybe meeting the language spec is more meaningful for Modula-3 than for C, but still inadequate. > > Now, compiler can't in general be a "correct program proofer", but it can and does catch a few things and that is a good thing not to be avoided. > > > > > > - Jay > > > > ---------------------------------------- > >> From: hosking at cs.purdue.edu > >> Date: Mon, 5 Jul 2010 17:40:50 -0400 > >> To: jay.krell at cornell.edu > >> CC: m3commit at elegosoft.com > >> Subject: Re: [M3commit] CVS Update: cm3 > >> > >> But the front-end should be OK with the first. It is "correct" because whatever value is in a when F1 is called is legal for a. Why should the backend give a warning? The semantics of Modula-3 allow any legal bit-value for a variable as its initial value. You will force an initialising assignment when none is required by the language spec. > >> > >> On 5 Jul 2010, at 17:36, Jay K wrote: > >> > >>> > >>> unsigned F1() > >>> { > >>> unsigned a; > >>> return a; > >>> } > >>> > >>> should generate a warning. > >>> > >>> unsigned F1() > >>> > >>> { > >>> > >>> unsigned a = 0; > >>> > >>> return a; > >>> > >>> } > >>> > >>> > >>> is much preferred. > >>> > >>> Just because the front end is ok with the first, doesn't make it correct. > >>> > >>> - Jay > >>> > >>> ---------------------------------------- > >>>> Subject: Re: [M3commit] CVS Update: cm3 > >>>> From: hosking at cs.purdue.edu > >>>> Date: Mon, 5 Jul 2010 17:34:51 -0400 > >>>> CC: m3commit at elegosoft.com > >>>> To: jay.krell at cornell.edu > >>>> > >>>> Huh? > >>>> > >>>> On 5 Jul 2010, at 17:15, Jay K wrote: > >>>> > >>>>> > >>>>> At least some of these were Word.T. "valid" is still "random" and the code is unpredictable, at least by a quick read, even if type safe. > >>>>> Type safe is just a minimum bar, one that should always be exceeded, even if the compiler is completely unable to validate it. > >>>>> > >>>>> That is, the compiler guarantees are from sufficient relative to correctness. > >>>>> > >>>>> - Jay > >>>>> > >>>>> ---------------------------------------- > >>>>>> From: hosking at cs.purdue.edu > >>>>>> Date: Mon, 5 Jul 2010 16:50:00 -0400 > >>>>>> To: jay.krell at cornell.edu > >>>>>> CC: m3commit at elegosoft.com > >>>>>> Subject: Re: [M3commit] CVS Update: cm3 > >>>>>> > >>>>>> But we've been this route before. Modula-3 ensures every variable is initialised with a valid value. I don't see how your adding an initialiser makes it more obviously correct. > >>>>>> > >>>>>> On 5 Jul 2010, at 16:45, Jay K wrote: > >>>>>> > >>>>>>> > >>>>>>> I will maybe see about doing better here. > >>>>>>> Initializing locals doesn't seem like such a bad change though. > >>>>>>> I like the code to be "obviously correct" by a quick read by a human. > >>>>>>> > >>>>>>> - Jay > >>>>>>> > >>>>>>> ---------------------------------------- > >>>>>>>> From: hosking at cs.purdue.edu > >>>>>>>> Date: Mon, 5 Jul 2010 14:31:01 -0400 > >>>>>>>> To: jkrell at elego.de > >>>>>>>> CC: m3commit at elegosoft.com > >>>>>>>> Subject: Re: [M3commit] CVS Update: cm3 > >>>>>>>> > >>>>>>>> Jay, I am perplexed that we are adding things to Modula-3 source because of compiler backend brokenness just to avoid back-end warnings. Better to fix the backend so that RAISE is noreturn. This should not be difficult to do. > >>>>>>>> > >>>>>>>> On 5 Jul 2010, at 15:22, Jay Krell wrote: > >>>>>>>> > >>>>>>>>> CVSROOT: /usr/cvs > >>>>>>>>> Changes by: jkrell at birch. 10/07/05 15:22:28 > >>>>>>>>> > >>>>>>>>> Modified files: > >>>>>>>>> cm3/m3-tools/cvsup/suplib/src/text_cm3/: SupMiscText.m3 > >>>>>>>>> > >>>>>>>>> Log message: > >>>>>>>>> ../src/text_cm3/SupMiscText.m3: In function 'SupMisc__DecodeWS': > >>>>>>>>> ../src/text_cm3/SupMiscText.m3:211: warning: 'M3_Bkn9rd_ch' may be used uninitialized in this function > >>>>>>>>> ../src/text_cm3/SupMiscText.m3:211: note: 'M3_Bkn9rd_ch' was declared here > >>>>>>>>> > >>>>>>>>> because raising an exception isn't currently "noreturn" > >>>>>>>>> so initialize it to 0 > >>>>>>>> > >>>>>>> > >>>>>> > >>>>> > >>>> > >>> > >> > > > From jay.krell at cornell.edu Tue Jul 6 00:59:37 2010 From: jay.krell at cornell.edu (Jay K) Date: Mon, 5 Jul 2010 22:59:37 +0000 Subject: [M3commit] CVS Update: cm3 In-Reply-To: <6331F39C-AA28-4AC1-8C87-3D47D52D0C55@cs.purdue.edu> References: <20100705132228.0E6D52474003@birch.elegosoft.com>, , <759A98E1-3098-49B8-BC68-B9B3F54D4230@cs.purdue.edu>, , <3B74FBBA-DEE1-43E8-AB9D-631AA959D6B4@cs.purdue.edu> , <08FF7A56-401D-49FD-A943-155B94BE41C4@cs.purdue.edu> , <6331F39C-AA28-4AC1-8C87-3D47D52D0C55@cs.purdue.edu> Message-ID: There will *always* be bugs, in every program. Even in the CPU (really, I've seen it, some are easy to run afoul of.) ? As I said, the compiler cannot be a "general program proofer". Since that is impossible, cannot exist. But we can take some small easy steps to find some of them early. We do type checking after all. Should we not bother with that? Some simple data/control flow analysis is some of the steps to take beyond that and all compilers do it, both to optimize and to find bugs. ?Just because we can't be perfect, doesn't mean we shouldn't do what is at least "easy". ?- Jay ---------------------------------------- > Subject: Re: [M3commit] CVS Update: cm3 > From: hosking at cs.purdue.edu > Date: Mon, 5 Jul 2010 18:44:16 -0400 > CC: m3commit at elegosoft.com > To: jay.krell at cornell.edu > > That is you view, but at odds with why Modula-3 was designed the way it was. I think we've already had this conversation before. The point is that even when a variable is initialised to 0 as you prefer there may still be bugs in the program. > > You are seeing Modula-3 through C spectacles, where so much of the language is undefined. > > On 5 Jul 2010, at 17:51, Jay K wrote: > > > > > As a human reading code (very finite cycles), I don't like to see: > > > > > > VAR a: type; > > BEGIN > > ... > > END > > > > > > no matter the contents of "...". > > > > > > I'd much rather see: > > > > > > VAR a: type := 0; > > > > > > > > and know very quickly and without a doubt that a is never used uninitialized. > > I've been bitten too much by microoptimizations around not initializing locals. > > Some large fraction of the time the compiler will optimize away the initialization. > > (ie. depending on the contents of "...") > > Some other large fraction of the time the performance difference will be unmeasurable. > > So much code is I/O bound already, let alone compute bound by more significant "algorithmic" factors. > > And then some small fraction of the time, maybe, it will be a bad pessimization. > > > > > > I just don't think it is worth the risk. > > > > > > - Jay > > > > > > > > ---------------------------------------- > >> Subject: Re: [M3commit] CVS Update: cm3 > >> From: hosking at cs.purdue.edu > >> Date: Mon, 5 Jul 2010 17:34:51 -0400 > >> CC: m3commit at elegosoft.com > >> To: jay.krell at cornell.edu > >> > >> Huh? > >> > >> On 5 Jul 2010, at 17:15, Jay K wrote: > >> > >>> > >>> At least some of these were Word.T. "valid" is still "random" and the code is unpredictable, at least by a quick read, even if type safe. > >>> Type safe is just a minimum bar, one that should always be exceeded, even if the compiler is completely unable to validate it. > >>> > >>> That is, the compiler guarantees are from sufficient relative to correctness. > >>> > >>> - Jay > >>> > >>> ---------------------------------------- > >>>> From: hosking at cs.purdue.edu > >>>> Date: Mon, 5 Jul 2010 16:50:00 -0400 > >>>> To: jay.krell at cornell.edu > >>>> CC: m3commit at elegosoft.com > >>>> Subject: Re: [M3commit] CVS Update: cm3 > >>>> > >>>> But we've been this route before. Modula-3 ensures every variable is initialised with a valid value. I don't see how your adding an initialiser makes it more obviously correct. > >>>> > >>>> On 5 Jul 2010, at 16:45, Jay K wrote: > >>>> > >>>>> > >>>>> I will maybe see about doing better here. > >>>>> Initializing locals doesn't seem like such a bad change though. > >>>>> I like the code to be "obviously correct" by a quick read by a human. > >>>>> > >>>>> - Jay > >>>>> > >>>>> ---------------------------------------- > >>>>>> From: hosking at cs.purdue.edu > >>>>>> Date: Mon, 5 Jul 2010 14:31:01 -0400 > >>>>>> To: jkrell at elego.de > >>>>>> CC: m3commit at elegosoft.com > >>>>>> Subject: Re: [M3commit] CVS Update: cm3 > >>>>>> > >>>>>> Jay, I am perplexed that we are adding things to Modula-3 source because of compiler backend brokenness just to avoid back-end warnings. Better to fix the backend so that RAISE is noreturn. This should not be difficult to do. > >>>>>> > >>>>>> On 5 Jul 2010, at 15:22, Jay Krell wrote: > >>>>>> > >>>>>>> CVSROOT: /usr/cvs > >>>>>>> Changes by: jkrell at birch. 10/07/05 15:22:28 > >>>>>>> > >>>>>>> Modified files: > >>>>>>> cm3/m3-tools/cvsup/suplib/src/text_cm3/: SupMiscText.m3 > >>>>>>> > >>>>>>> Log message: > >>>>>>> ../src/text_cm3/SupMiscText.m3: In function 'SupMisc__DecodeWS': > >>>>>>> ../src/text_cm3/SupMiscText.m3:211: warning: 'M3_Bkn9rd_ch' may be used uninitialized in this function > >>>>>>> ../src/text_cm3/SupMiscText.m3:211: note: 'M3_Bkn9rd_ch' was declared here > >>>>>>> > >>>>>>> because raising an exception isn't currently "noreturn" > >>>>>>> so initialize it to 0 > >>>>>> > >>>>> > >>>> > >>> > >> > > > From hosking at cs.purdue.edu Tue Jul 6 04:36:29 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 5 Jul 2010 22:36:29 -0400 Subject: [M3commit] CVS Update: cm3 In-Reply-To: References: <20100705132228.0E6D52474003@birch.elegosoft.com> <759A98E1-3098-49B8-BC68-B9B3F54D4230@cs.purdue.edu> <3B74FBBA-DEE1-43E8-AB9D-631AA959D6B4@cs.purdue.edu> <08FF7A56-401D-49FD-A943-155B94BE41C4@cs.purdue.edu> <6331F39C-AA28-4AC1-8C87-3D47D52D0C55@cs.purdue.edu> Message-ID: <02F12035-7271-4004-BE67-3DAB17C37B3B@cs.purdue.edu> But the compiler frontend has already proved the variable has a valid initial value. Sent from my iPhone On Jul 5, 2010, at 6:59 PM, Jay K wrote: > > There will *always* be bugs, in every program. Even in the CPU (really, I've seen it, some are easy to run afoul of.) > As I said, the compiler cannot be a "general program proofer". Since that is impossible, cannot exist. > But we can take some small easy steps to find some of them early. > We do type checking after all. Should we not bother with that? > Some simple data/control flow analysis is some of the steps to take beyond that and all compilers do it, both to optimize and to find bugs. > Just because we can't be perfect, doesn't mean we shouldn't do what is at least "easy". > > > - Jay > > ---------------------------------------- >> Subject: Re: [M3commit] CVS Update: cm3 >> From: hosking at cs.purdue.edu >> Date: Mon, 5 Jul 2010 18:44:16 -0400 >> CC: m3commit at elegosoft.com >> To: jay.krell at cornell.edu >> >> That is you view, but at odds with why Modula-3 was designed the way it was. I think we've already had this conversation before. The point is that even when a variable is initialised to 0 as you prefer there may still be bugs in the program. >> >> You are seeing Modula-3 through C spectacles, where so much of the language is undefined. >> >> On 5 Jul 2010, at 17:51, Jay K wrote: >> >>> >>> As a human reading code (very finite cycles), I don't like to see: >>> >>> >>> VAR a: type; >>> BEGIN >>> ... >>> END >>> >>> >>> no matter the contents of "...". >>> >>> >>> I'd much rather see: >>> >>> >>> VAR a: type := 0; >>> >>> >>> >>> and know very quickly and without a doubt that a is never used uninitialized. >>> I've been bitten too much by microoptimizations around not initializing locals. >>> Some large fraction of the time the compiler will optimize away the initialization. >>> (ie. depending on the contents of "...") >>> Some other large fraction of the time the performance difference will be unmeasurable. >>> So much code is I/O bound already, let alone compute bound by more significant "algorithmic" factors. >>> And then some small fraction of the time, maybe, it will be a bad pessimization. >>> >>> >>> I just don't think it is worth the risk. >>> >>> >>> - Jay >>> >>> >>> >>> ---------------------------------------- >>>> Subject: Re: [M3commit] CVS Update: cm3 >>>> From: hosking at cs.purdue.edu >>>> Date: Mon, 5 Jul 2010 17:34:51 -0400 >>>> CC: m3commit at elegosoft.com >>>> To: jay.krell at cornell.edu >>>> >>>> Huh? >>>> >>>> On 5 Jul 2010, at 17:15, Jay K wrote: >>>> >>>>> >>>>> At least some of these were Word.T. "valid" is still "random" and the code is unpredictable, at least by a quick read, even if type safe. >>>>> Type safe is just a minimum bar, one that should always be exceeded, even if the compiler is completely unable to validate it. >>>>> >>>>> That is, the compiler guarantees are from sufficient relative to correctness. >>>>> >>>>> - Jay >>>>> >>>>> ---------------------------------------- >>>>>> From: hosking at cs.purdue.edu >>>>>> Date: Mon, 5 Jul 2010 16:50:00 -0400 >>>>>> To: jay.krell at cornell.edu >>>>>> CC: m3commit at elegosoft.com >>>>>> Subject: Re: [M3commit] CVS Update: cm3 >>>>>> >>>>>> But we've been this route before. Modula-3 ensures every variable is initialised with a valid value. I don't see how your adding an initialiser makes it more obviously correct. >>>>>> >>>>>> On 5 Jul 2010, at 16:45, Jay K wrote: >>>>>> >>>>>>> >>>>>>> I will maybe see about doing better here. >>>>>>> Initializing locals doesn't seem like such a bad change though. >>>>>>> I like the code to be "obviously correct" by a quick read by a human. >>>>>>> >>>>>>> - Jay >>>>>>> >>>>>>> ---------------------------------------- >>>>>>>> From: hosking at cs.purdue.edu >>>>>>>> Date: Mon, 5 Jul 2010 14:31:01 -0400 >>>>>>>> To: jkrell at elego.de >>>>>>>> CC: m3commit at elegosoft.com >>>>>>>> Subject: Re: [M3commit] CVS Update: cm3 >>>>>>>> >>>>>>>> Jay, I am perplexed that we are adding things to Modula-3 source because of compiler backend brokenness just to avoid back-end warnings. Better to fix the backend so that RAISE is noreturn. This should not be difficult to do. >>>>>>>> >>>>>>>> On 5 Jul 2010, at 15:22, Jay Krell wrote: >>>>>>>> >>>>>>>>> CVSROOT: /usr/cvs >>>>>>>>> Changes by: jkrell at birch. 10/07/05 15:22:28 >>>>>>>>> >>>>>>>>> Modified files: >>>>>>>>> cm3/m3-tools/cvsup/suplib/src/text_cm3/: SupMiscText.m3 >>>>>>>>> >>>>>>>>> Log message: >>>>>>>>> ../src/text_cm3/SupMiscText.m3: In function 'SupMisc__DecodeWS': >>>>>>>>> ../src/text_cm3/SupMiscText.m3:211: warning: 'M3_Bkn9rd_ch' may be used uninitialized in this function >>>>>>>>> ../src/text_cm3/SupMiscText.m3:211: note: 'M3_Bkn9rd_ch' was declared here >>>>>>>>> >>>>>>>>> because raising an exception isn't currently "noreturn" >>>>>>>>> so initialize it to 0 >>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >> > From jay.krell at cornell.edu Tue Jul 6 04:45:23 2010 From: jay.krell at cornell.edu (Jay K) Date: Tue, 6 Jul 2010 02:45:23 +0000 Subject: [M3commit] CVS Update: cm3 In-Reply-To: <02F12035-7271-4004-BE67-3DAB17C37B3B@cs.purdue.edu> References: <20100705132228.0E6D52474003@birch.elegosoft.com>, <759A98E1-3098-49B8-BC68-B9B3F54D4230@cs.purdue.edu>, , <3B74FBBA-DEE1-43E8-AB9D-631AA959D6B4@cs.purdue.edu>, , <08FF7A56-401D-49FD-A943-155B94BE41C4@cs.purdue.edu>, , <6331F39C-AA28-4AC1-8C87-3D47D52D0C55@cs.purdue.edu>, , <02F12035-7271-4004-BE67-3DAB17C37B3B@cs.purdue.edu> Message-ID: We are going in circles. You have a lower bar for the level of correctness you would like the compiler to try to help the programmer to attain. "valid" doesn't mean much sometimes, given that any value is "valid". Knowingly letting uninitialized data creep in is not good. You can't always help it, and you can't analyze away all bugs, but some you can. Perhaps I don't realize the extent that Modula-3's safety guarantee restrict what can happen when an uninitialized variable gets used. But, really? I mean, let's say it ends up as an array index. It might be "small and valid", and arbitrary data will be operated on, or "large an invalid" and you'll get a nice exception upon indexing. The second case is ok but the first is pretty bad. I understand zero is similar to "small and valid and wrong" but at least it is consistent, repeatable, and perhaps more likely to be found therefore. I will try making the exception raising be noreturn and maybe we can then analyze away the use of uninitialized data. But really I think these are not changes. Even if the compiler can tell the data is used uninitialized, as a programmer, maybe I don't trust the compiler's analysis there -- for example the NT386 backend doesn't do the analysis, nor does gcc when not optimizing. As a programmer I want code to be as clear and clearly correct as possible. Throwing in "unnecesssary" initialization is an easy cheap step there I think. Some large fraction of the time the compiler will optimize away such initialization anyway. Other fraction, the performance difference will not be noticable. And maybe some small fraction of the time it will be a noticable slow down, maybe. - Jay > From: hosking at cs.purdue.edu > Date: Mon, 5 Jul 2010 22:36:29 -0400 > To: jay.krell at cornell.edu > CC: m3commit at elegosoft.com > Subject: Re: [M3commit] CVS Update: cm3 > > But the compiler frontend has already proved the variable has a valid initial value. > > Sent from my iPhone > > On Jul 5, 2010, at 6:59 PM, Jay K wrote: > > > > > There will *always* be bugs, in every program. Even in the CPU (really, I've seen it, some are easy to run afoul of.) > > As I said, the compiler cannot be a "general program proofer". Since that is impossible, cannot exist. > > But we can take some small easy steps to find some of them early. > > We do type checking after all. Should we not bother with that? > > Some simple data/control flow analysis is some of the steps to take beyond that and all compilers do it, both to optimize and to find bugs. > > Just because we can't be perfect, doesn't mean we shouldn't do what is at least "easy". > > > > > > - Jay > > > > ---------------------------------------- > >> Subject: Re: [M3commit] CVS Update: cm3 > >> From: hosking at cs.purdue.edu > >> Date: Mon, 5 Jul 2010 18:44:16 -0400 > >> CC: m3commit at elegosoft.com > >> To: jay.krell at cornell.edu > >> > >> That is you view, but at odds with why Modula-3 was designed the way it was. I think we've already had this conversation before. The point is that even when a variable is initialised to 0 as you prefer there may still be bugs in the program. > >> > >> You are seeing Modula-3 through C spectacles, where so much of the language is undefined. > >> > >> On 5 Jul 2010, at 17:51, Jay K wrote: > >> > >>> > >>> As a human reading code (very finite cycles), I don't like to see: > >>> > >>> > >>> VAR a: type; > >>> BEGIN > >>> ... > >>> END > >>> > >>> > >>> no matter the contents of "...". > >>> > >>> > >>> I'd much rather see: > >>> > >>> > >>> VAR a: type := 0; > >>> > >>> > >>> > >>> and know very quickly and without a doubt that a is never used uninitialized. > >>> I've been bitten too much by microoptimizations around not initializing locals. > >>> Some large fraction of the time the compiler will optimize away the initialization. > >>> (ie. depending on the contents of "...") > >>> Some other large fraction of the time the performance difference will be unmeasurable. > >>> So much code is I/O bound already, let alone compute bound by more significant "algorithmic" factors. > >>> And then some small fraction of the time, maybe, it will be a bad pessimization. > >>> > >>> > >>> I just don't think it is worth the risk. > >>> > >>> > >>> - Jay > >>> > >>> > >>> > >>> ---------------------------------------- > >>>> Subject: Re: [M3commit] CVS Update: cm3 > >>>> From: hosking at cs.purdue.edu > >>>> Date: Mon, 5 Jul 2010 17:34:51 -0400 > >>>> CC: m3commit at elegosoft.com > >>>> To: jay.krell at cornell.edu > >>>> > >>>> Huh? > >>>> > >>>> On 5 Jul 2010, at 17:15, Jay K wrote: > >>>> > >>>>> > >>>>> At least some of these were Word.T. "valid" is still "random" and the code is unpredictable, at least by a quick read, even if type safe. > >>>>> Type safe is just a minimum bar, one that should always be exceeded, even if the compiler is completely unable to validate it. > >>>>> > >>>>> That is, the compiler guarantees are from sufficient relative to correctness. > >>>>> > >>>>> - Jay > >>>>> > >>>>> ---------------------------------------- > >>>>>> From: hosking at cs.purdue.edu > >>>>>> Date: Mon, 5 Jul 2010 16:50:00 -0400 > >>>>>> To: jay.krell at cornell.edu > >>>>>> CC: m3commit at elegosoft.com > >>>>>> Subject: Re: [M3commit] CVS Update: cm3 > >>>>>> > >>>>>> But we've been this route before. Modula-3 ensures every variable is initialised with a valid value. I don't see how your adding an initialiser makes it more obviously correct. > >>>>>> > >>>>>> On 5 Jul 2010, at 16:45, Jay K wrote: > >>>>>> > >>>>>>> > >>>>>>> I will maybe see about doing better here. > >>>>>>> Initializing locals doesn't seem like such a bad change though. > >>>>>>> I like the code to be "obviously correct" by a quick read by a human. > >>>>>>> > >>>>>>> - Jay > >>>>>>> > >>>>>>> ---------------------------------------- > >>>>>>>> From: hosking at cs.purdue.edu > >>>>>>>> Date: Mon, 5 Jul 2010 14:31:01 -0400 > >>>>>>>> To: jkrell at elego.de > >>>>>>>> CC: m3commit at elegosoft.com > >>>>>>>> Subject: Re: [M3commit] CVS Update: cm3 > >>>>>>>> > >>>>>>>> Jay, I am perplexed that we are adding things to Modula-3 source because of compiler backend brokenness just to avoid back-end warnings. Better to fix the backend so that RAISE is noreturn. This should not be difficult to do. > >>>>>>>> > >>>>>>>> On 5 Jul 2010, at 15:22, Jay Krell wrote: > >>>>>>>> > >>>>>>>>> CVSROOT: /usr/cvs > >>>>>>>>> Changes by: jkrell at birch. 10/07/05 15:22:28 > >>>>>>>>> > >>>>>>>>> Modified files: > >>>>>>>>> cm3/m3-tools/cvsup/suplib/src/text_cm3/: SupMiscText.m3 > >>>>>>>>> > >>>>>>>>> Log message: > >>>>>>>>> ../src/text_cm3/SupMiscText.m3: In function 'SupMisc__DecodeWS': > >>>>>>>>> ../src/text_cm3/SupMiscText.m3:211: warning: 'M3_Bkn9rd_ch' may be used uninitialized in this function > >>>>>>>>> ../src/text_cm3/SupMiscText.m3:211: note: 'M3_Bkn9rd_ch' was declared here > >>>>>>>>> > >>>>>>>>> because raising an exception isn't currently "noreturn" > >>>>>>>>> so initialize it to 0 > >>>>>>>> > >>>>>>> > >>>>>> > >>>>> > >>>> > >>> > >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Tue Jul 6 05:15:14 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 5 Jul 2010 23:15:14 -0400 Subject: [M3commit] CVS Update: cm3 In-Reply-To: References: <20100705132228.0E6D52474003@birch.elegosoft.com>, <759A98E1-3098-49B8-BC68-B9B3F54D4230@cs.purdue.edu>, , <3B74FBBA-DEE1-43E8-AB9D-631AA959D6B4@cs.purdue.edu>, , <08FF7A56-401D-49FD-A943-155B94BE41C4@cs.purdue.edu>, , <6331F39C-AA28-4AC1-8C87-3D47D52D0C55@cs.purdue.edu>, , <02F12035-7271-4004-BE67-3DAB17C37B3B@cs.purdue.edu> Message-ID: <26F9F2BE-6D6E-4F33-A9BE-D69A6E355EA5@cs.purdue.edu> Sigh... You are tilting at windmills. On 5 Jul 2010, at 22:45, Jay K wrote: > We are going in circles. > > > You have a lower bar for the level of correctness you would like the compiler to try to help the programmer to attain. > "valid" doesn't mean much sometimes, given that any value is "valid". > > Knowingly letting uninitialized data creep in is not good. > You can't always help it, and you can't analyze away all bugs, but some you can. > > > Perhaps I don't realize the extent that Modula-3's safety guarantee restrict what can happen when an uninitialized variable gets used. > But, really? I mean, let's say it ends up as an array index. It might be "small and valid", and arbitrary data will be operated on, or "large an invalid" and you'll get a nice exception upon indexing. The second case is ok but the first is pretty bad. I understand zero is similar to "small and valid and wrong" but at least it is consistent, repeatable, and perhaps more likely to be found therefore. > > I will try making the exception raising be noreturn and maybe we can then analyze away the use of uninitialized data. > But really I think these are not changes. > Even if the compiler can tell the data is used uninitialized, as a programmer, maybe I don't trust the compiler's analysis there -- for example the NT386 backend doesn't do the analysis, nor does gcc when not optimizing. > As a programmer I want code to be as clear and clearly correct as possible. Throwing in "unnecesssary" initialization is an easy cheap step there I think. > > > Some large fraction of the time the compiler will optimize away such initialization anyway. > Other fraction, the performance difference will not be noticable. > And maybe some small fraction of the time it will be a noticable slow down, maybe. > > > - Jay > > > From: hosking at cs.purdue.edu > > Date: Mon, 5 Jul 2010 22:36:29 -0400 > > To: jay.krell at cornell.edu > > CC: m3commit at elegosoft.com > > Subject: Re: [M3commit] CVS Update: cm3 > > > > But the compiler frontend has already proved the variable has a valid initial value. > > > > Sent from my iPhone > > > > On Jul 5, 2010, at 6:59 PM, Jay K wrote: > > > > > > > > There will *always* be bugs, in every program. Even in the CPU (really, I've seen it, some are easy to run afoul of.) > > > As I said, the compiler cannot be a "general program proofer". Since that is impossible, cannot exist. > > > But we can take some small easy steps to find some of them early. > > > We do type checking after all. Should we not bother with that? > > > Some simple data/control flow analysis is some of the steps to take beyond that and all compilers do it, both to optimize and to find bugs. > > > Just because we can't be perfect, doesn't mean we shouldn't do what is at least "easy". > > > > > > > > > - Jay > > > > > > ---------------------------------------- > > >> Subject: Re: [M3commit] CVS Update: cm3 > > >> From: hosking at cs.purdue.edu > > >> Date: Mon, 5 Jul 2010 18:44:16 -0400 > > >> CC: m3commit at elegosoft.com > > >> To: jay.krell at cornell.edu > > >> > > >> That is you view, but at odds with why Modula-3 was designed the way it was. I think we've already had this conversation before. The point is that even when a variable is initialised to 0 as you prefer there may still be bugs in the program. > > >> > > >> You are seeing Modula-3 through C spectacles, where so much of the language is undefined. > > >> > > >> On 5 Jul 2010, at 17:51, Jay K wrote: > > >> > > >>> > > >>> As a human reading code (very finite cycles), I don't like to see: > > >>> > > >>> > > >>> VAR a: type; > > >>> BEGIN > > >>> ... > > >>> END > > >>> > > >>> > > >>> no matter the contents of "...". > > >>> > > >>> > > >>> I'd much rather see: > > >>> > > >>> > > >>> VAR a: type := 0; > > >>> > > >>> > > >>> > > >>> and know very quickly and without a doubt that a is never used uninitialized. > > >>> I've been bitten too much by microoptimizations around not initializing locals. > > >>> Some large fraction of the time the compiler will optimize away the initialization. > > >>> (ie. depending on the contents of "...") > > >>> Some other large fraction of the time the performance difference will be unmeasurable. > > >>> So much code is I/O bound already, let alone compute bound by more significant "algorithmic" factors. > > >>> And then some small fraction of the time, maybe, it will be a bad pessimization. > > >>> > > >>> > > >>> I just don't think it is worth the risk. > > >>> > > >>> > > >>> - Jay > > >>> > > >>> > > >>> > > >>> ---------------------------------------- > > >>>> Subject: Re: [M3commit] CVS Update: cm3 > > >>>> From: hosking at cs.purdue.edu > > >>>> Date: Mon, 5 Jul 2010 17:34:51 -0400 > > >>>> CC: m3commit at elegosoft.com > > >>>> To: jay.krell at cornell.edu > > >>>> > > >>>> Huh? > > >>>> > > >>>> On 5 Jul 2010, at 17:15, Jay K wrote: > > >>>> > > >>>>> > > >>>>> At least some of these were Word.T. "valid" is still "random" and the code is unpredictable, at least by a quick read, even if type safe. > > >>>>> Type safe is just a minimum bar, one that should always be exceeded, even if the compiler is completely unable to validate it. > > >>>>> > > >>>>> That is, the compiler guarantees are from sufficient relative to correctness. > > >>>>> > > >>>>> - Jay > > >>>>> > > >>>>> ---------------------------------------- > > >>>>>> From: hosking at cs.purdue.edu > > >>>>>> Date: Mon, 5 Jul 2010 16:50:00 -0400 > > >>>>>> To: jay.krell at cornell.edu > > >>>>>> CC: m3commit at elegosoft.com > > >>>>>> Subject: Re: [M3commit] CVS Update: cm3 > > >>>>>> > > >>>>>> But we've been this route before. Modula-3 ensures every variable is initialised with a valid value. I don't see how your adding an initialiser makes it more obviously correct. > > >>>>>> > > >>>>>> On 5 Jul 2010, at 16:45, Jay K wrote: > > >>>>>> > > >>>>>>> > > >>>>>>> I will maybe see about doing better here. > > >>>>>>> Initializing locals doesn't seem like such a bad change though. > > >>>>>>> I like the code to be "obviously correct" by a quick read by a human. > > >>>>>>> > > >>>>>>> - Jay > > >>>>>>> > > >>>>>>> ---------------------------------------- > > >>>>>>>> From: hosking at cs.purdue.edu > > >>>>>>>> Date: Mon, 5 Jul 2010 14:31:01 -0400 > > >>>>>>>> To: jkrell at elego.de > > >>>>>>>> CC: m3commit at elegosoft.com > > >>>>>>>> Subject: Re: [M3commit] CVS Update: cm3 > > >>>>>>>> > > >>>>>>>> Jay, I am perplexed that we are adding things to Modula-3 source because of compiler backend brokenness just to avoid back-end warnings. Better to fix the backend so that RAISE is noreturn. This should not be difficult to do. > > >>>>>>>> > > >>>>>>>> On 5 Jul 2010, at 15:22, Jay Krell wrote: > > >>>>>>>> > > >>>>>>>>> CVSROOT: /usr/cvs > > >>>>>>>>> Changes by: jkrell at birch. 10/07/05 15:22:28 > > >>>>>>>>> > > >>>>>>>>> Modified files: > > >>>>>>>>> cm3/m3-tools/cvsup/suplib/src/text_cm3/: SupMiscText.m3 > > >>>>>>>>> > > >>>>>>>>> Log message: > > >>>>>>>>> ../src/text_cm3/SupMiscText.m3: In function 'SupMisc__DecodeWS': > > >>>>>>>>> ../src/text_cm3/SupMiscText.m3:211: warning: 'M3_Bkn9rd_ch' may be used uninitialized in this function > > >>>>>>>>> ../src/text_cm3/SupMiscText.m3:211: note: 'M3_Bkn9rd_ch' was declared here > > >>>>>>>>> > > >>>>>>>>> because raising an exception isn't currently "noreturn" > > >>>>>>>>> so initialize it to 0 > > >>>>>>>> > > >>>>>>> > > >>>>>> > > >>>>> > > >>>> > > >>> > > >> > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jkrell at elego.de Tue Jul 6 21:36:58 2010 From: jkrell at elego.de (Jay Krell) Date: Tue, 6 Jul 2010 21:36:58 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100706193658.53C752474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/06 21:36:58 Modified files: cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c cm3/m3-sys/m3front/src/exprs/: CastExpr.m3 Log message: allow "ter"/-O3, but without causing compiling CopySign in m3core/src/float/IEEE/RealFloat.m3 to fail to compile: internal compiler error: in convert_move, at expr.c This change might not go far enough though. We might want to call Force() more often. The theory here is, I don't completely know, but that Force() inhibits optimizations done by m3front/src/misc/CG.m3, such as that might remove "taking the address of", which would then inhibit optimizations by the backend. Optimizations are being inhibited here specifically for unsafe code that is casting floats to structures, surely an acceptable small amount of code. In fact, again, consider doing this more. From hosking at elego.de Tue Jul 6 21:40:43 2010 From: hosking at elego.de (Antony Hosking) Date: Tue, 6 Jul 2010 21:40:43 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100706194043.5B9552474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: hosking at birch. 10/07/06 21:40:43 Modified files: cm3/m3-sys/m3front/src/exprs/: CastExpr.m3 Log message: Cleaner. From jay.krell at cornell.edu Tue Jul 6 21:48:44 2010 From: jay.krell at cornell.edu (Jay K) Date: Tue, 6 Jul 2010 19:48:44 +0000 Subject: [M3commit] CVS Update: cm3 In-Reply-To: <20100706194043.5B9552474003@birch.elegosoft.com> References: <20100706194043.5B9552474003@birch.elegosoft.com> Message-ID: Debatable, but ok either way. I don't like the other lines to be duplicated. Granted, only two lines. Er, let's not debate it actually. I'll have the last word, you have the last code. I'll leave it alone. :) If anyone has a solid understanding of what is going on, the comment could be better. The comment is ugly but honest, from my ignorant point of view. ?- Jay ---------------------------------------- > Date: Tue, 6 Jul 2010 21:40:43 +0000 > To: m3commit at elegosoft.com > From: hosking at elego.de > Subject: [M3commit] CVS Update: cm3 > > CVSROOT: /usr/cvs > Changes by: hosking at birch. 10/07/06 21:40:43 > > Modified files: > cm3/m3-sys/m3front/src/exprs/: CastExpr.m3 > > Log message: > Cleaner. > From jay.krell at cornell.edu Tue Jul 6 21:39:20 2010 From: jay.krell at cornell.edu (Jay K) Date: Tue, 6 Jul 2010 19:39:20 +0000 Subject: [M3commit] CVS Update: cm3 In-Reply-To: <20100706193658.53C752474003@birch.elegosoft.com> References: <20100706193658.53C752474003@birch.elegosoft.com> Message-ID: attachments don't seem to be working, we'll see if this is readable.. Index: m3cc/gcc/gcc/m3cg/parse.c =================================================================== RCS file: /usr/cvs/cm3/m3-sys/m3cc/gcc/gcc/m3cg/parse.c,v retrieving revision 1.218 diff -u -r1.218 parse.c --- m3cc/gcc/gcc/m3cg/parse.c??? 5 Jul 2010 22:16:43 -0000??? 1.218 +++ m3cc/gcc/gcc/m3cg/parse.c??? 6 Jul 2010 19:32:16 -0000 @@ -5715,7 +5715,7 @@ ?#endif ???? /*flag_strict_aliasing = 0;*/ /* consider? */ ???? /*flag_strict_overflow = 0;*/ /* consider? */ -??? flag_tree_ter = 0; /* fails to compile m3core CopySign */ +??? /*flag_tree_ter = 0;*/ /* used to break m3core CopySign, see m3front/CastExpr */ ???? /*flag_delete_null_pointer_checks = 0;*/ /* consider? */ ???? /*flag_reorder_functions = 0;*/ /* consider? */ ?? } Index: m3front/src/exprs/CastExpr.m3 =================================================================== RCS file: /usr/cvs/cm3/m3-sys/m3front/src/exprs/CastExpr.m3,v retrieving revision 1.9 diff -u -r1.9 CastExpr.m3 --- m3front/src/exprs/CastExpr.m3??? 5 Jul 2010 11:28:32 -0000??? 1.9 +++ m3front/src/exprs/CastExpr.m3??? 6 Jul 2010 19:32:16 -0000 @@ -10,6 +10,7 @@ ? ?IMPORT M3Buf, CG, Expr, ExprRep, Type, Error, OpenArrayType; ?IMPORT M3, M3ID, M3RT, Target, TInt; +FROM Target IMPORT FloatType; ? ?TYPE ?? Kind = { @@ -394,7 +395,7 @@ ???? u? := Expr.TypeOf (e); ???? t? := p.tipe; ???? sz, t_align, u_align, z_align: INTEGER; -??? u_cg: CG.Type; +??? t_cg, u_cg: CG.Type; ???? u_info, t_info: Type.Info; ?? BEGIN ???? u := Type.CheckInfo (u, u_info); @@ -402,6 +403,7 @@ ???? t_align := t_info.alignment; ???? u_align := u_info.alignment; ???? z_align := MAX (t_align, u_align); +??? t_cg := t_info.stk_type; ???? u_cg := u_info.stk_type; ???? sz := u_info.size; ???? Type.Compile (t); @@ -417,6 +419,21 @@ ???????? Expr.CompileLValue (p.expr, traced); ???????? CG.Boost_alignment (t_align); ? +??????? (* Inhibit some optimization that causes compilation to fail. e.g.: +???????? * m3core/src/float/IEEE/RealFloat.m3: +???????? * In function 'RealFloat__CopySign': +???????? * internal compiler error: in convert_move, at expr.c:371 +???????? * +???????? * ?Force() inhibits optimizations done by m3front/src/misc/CG.m3? +???????? * ?The particular optimizations are removal of address taken and +???????? * pointer indirections? ?Leaving the address taken inhibits +???????? * gcc optimization? ?Given that this is LOOPHOLE and floating point, +???????? * inhibiting optimization is very ok? +???????? *) +??????? IF p.kind = Kind.D_to_S AND (FloatType[t_cg] # FloatType[u_cg]) THEN +????????? CG.Force (); +??????? END; + ???? | Kind.D_to_A, ?????? Kind.S_to_A, ?????? Kind.V_to_A => ---------------------------------------- > Date: Tue, 6 Jul 2010 21:36: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/07/06 21:36:58 > > Modified files: > cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c > cm3/m3-sys/m3front/src/exprs/: CastExpr.m3 > > Log message: > allow "ter"/-O3, but without causing compiling CopySign in > m3core/src/float/IEEE/RealFloat.m3 to fail to compile: > internal compiler error: in convert_move, at expr.c > > This change might not go far enough though. > We might want to call Force() more often. > > The theory here is, I don't completely know, but that Force() > inhibits optimizations done by m3front/src/misc/CG.m3, such > as that might remove "taking the address of", which would > then inhibit optimizations by the backend. > > Optimizations are being inhibited here specifically for > unsafe code that is casting floats to structures, surely > an acceptable small amount of code. In fact, again, consider > doing this more. > From jkrell at elego.de Tue Jul 6 22:58:47 2010 From: jkrell at elego.de (Jay Krell) Date: Tue, 6 Jul 2010 22:58:47 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100706205847.29CA72474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/06 22:58:47 Modified files: cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c cm3/m3-sys/m3back/src/: M3x86.m3 cm3/m3-libs/m3core/src/runtime/common/: RTHooks.i3 RTHooks.m3 RuntimeError.i3 cm3/m3-sys/m3middle/src/: M3CG.i3 Log message: replace a "FIXME" comment with other comments and assertions The code was ok. Line numbers beyond around 100 million are silently truncated, same as it ever was (though the range probably used to be double) From jay.krell at cornell.edu Tue Jul 6 23:00:10 2010 From: jay.krell at cornell.edu (Jay K) Date: Tue, 6 Jul 2010 21:00:10 +0000 Subject: [M3commit] CVS Update: cm3 In-Reply-To: <20100706205847.29CA72474003@birch.elegosoft.com> References: <20100706205847.29CA72474003@birch.elegosoft.com> Message-ID: attached > Date: Tue, 6 Jul 2010 22:58:47 +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/07/06 22:58:47 > > Modified files: > cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c > cm3/m3-sys/m3back/src/: M3x86.m3 > cm3/m3-libs/m3core/src/runtime/common/: RTHooks.i3 RTHooks.m3 > RuntimeError.i3 > cm3/m3-sys/m3middle/src/: M3CG.i3 > > Log message: > replace a "FIXME" comment with other comments and assertions > The code was ok. > Line numbers beyond around 100 million are silently truncated, same as > it ever was (though the range probably used to be double) > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: 32.txt URL: From jkrell at elego.de Wed Jul 7 08:09:47 2010 From: jkrell at elego.de (Jay Krell) Date: Wed, 7 Jul 2010 8:09:47 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100707060947.ECE392474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/07 08:09:47 Modified files: cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c Log message: Allow "all" optimizations now, except flag_unit_at_a_time which fails for a "different" reason, and flag_tree_pre (partial redundancy elmination) only because I missed it since it is a few lines away, will try that shortly. From jkrell at elego.de Wed Jul 7 08:20:57 2010 From: jkrell at elego.de (Jay Krell) Date: Wed, 7 Jul 2010 8:20:57 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100707062057.34A3B2474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/07 08:20:57 Modified files: cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c Log message: partial redundancy elimination ('pre') also crashes compiling libm3/Formatter, add comment; remove all the other stuff about disabling optimizations From jkrell at elego.de Wed Jul 7 13:01:26 2010 From: jkrell at elego.de (Jay Krell) Date: Wed, 7 Jul 2010 13:01:26 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100707110126.C7F0D2474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/07 13:01:26 Modified files: cm3/m3-sys/m3tests/src/: m3makefile Added files: cm3/m3-sys/m3tests/src/p2/p241/: Main.m3 m3makefile Log message: cut down (38 lines) form of libm3/Formatter.m3 that crashes gcc backend if -O3, no volatile, 'ter' From hosking at cs.purdue.edu Wed Jul 7 17:56:30 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Wed, 7 Jul 2010 11:56:30 -0400 Subject: [M3commit] CVS Update: cm3 In-Reply-To: <20100707062057.34A3B2474003@birch.elegosoft.com> References: <20100707062057.34A3B2474003@birch.elegosoft.com> Message-ID: This is new. It used to work! On 7 Jul 2010, at 08:20, Jay Krell wrote: > CVSROOT: /usr/cvs > Changes by: jkrell at birch. 10/07/07 08:20:57 > > Modified files: > cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c > > Log message: > partial redundancy elimination ('pre') also crashes compiling libm3/Formatter, add comment; remove all the other stuff about disabling optimizations From wagner at elego.de Wed Jul 7 19:00:50 2010 From: wagner at elego.de (Olaf Wagner) Date: Wed, 7 Jul 2010 19:00:50 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100707170050.4E8342474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: wagner at birch. 10/07/07 19:00:50 Modified files: cm3/scripts/: Tag: release_branch_cm3_5_8 make-dist.sh Log message: prepare for final release build From jay.krell at cornell.edu Wed Jul 7 21:13:02 2010 From: jay.krell at cornell.edu (Jay K) Date: Wed, 7 Jul 2010 19:13:02 +0000 Subject: [M3commit] CVS Update: cm3 In-Reply-To: References: <20100707062057.34A3B2474003@birch.elegosoft.com>, Message-ID: Back when all loads and stores were volatile! And the optimizer was severely hampered. Any optimized code I looked at was full of unnecessary code. Which do you prefer? ?- Jay ---------------------------------------- > From: hosking at cs.purdue.edu > Date: Wed, 7 Jul 2010 11:56:30 -0400 > To: jkrell at elego.de > CC: m3commit at elegosoft.com > Subject: Re: [M3commit] CVS Update: cm3 > > This is new. It used to work! > > > On 7 Jul 2010, at 08:20, Jay Krell wrote: > > > CVSROOT: /usr/cvs > > Changes by: jkrell at birch. 10/07/07 08:20:57 > > > > Modified files: > > cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c > > > > Log message: > > partial redundancy elimination ('pre') also crashes compiling libm3/Formatter, add comment; remove all the other stuff about disabling optimizations > From hosking at cs.purdue.edu Wed Jul 7 21:59:08 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Wed, 7 Jul 2010 15:59:08 -0400 Subject: [M3commit] CVS Update: cm3 In-Reply-To: References: <20100707062057.34A3B2474003@birch.elegosoft.com>, , , Message-ID: <2E37CD56-4440-4927-936A-8E40B174F488@cs.purdue.edu> We already volatilise as necessary for setjmp/longjmp (at least we did when last I looked, because I remember putting it in). I would prefer to avoid volatile in all other situations where possible. On 7 Jul 2010, at 15:54, Jay K wrote: > > But I admit I'm nervous about removing all the volatile, esp. on stores. > We should have a bunch of tests using exceptions that access locals/parameters in except and finally blocks. > I'm willing to put back volatile on all stores. > Or even loads if there is justification. > > I thought there'd be a setjmp in all functions with try/except/finally, and therefore the same > pessimization, but now I'm not sure of that. > > - Jay > > ---------------------------------------- >> From: jay.krell at cornell.edu >> To: hosking at cs.purdue.edu; jkrell at elego.de >> Date: Wed, 7 Jul 2010 19:13:02 +0000 >> CC: m3commit at elegosoft.com >> Subject: Re: [M3commit] CVS Update: cm3 >> >> >> Back when all loads and stores were volatile! >> And the optimizer was severely hampered. Any optimized code I looked at was full of unnecessary code. >> Which do you prefer? >> >> - Jay >> >> ---------------------------------------- >>> From: hosking at cs.purdue.edu >>> Date: Wed, 7 Jul 2010 11:56:30 -0400 >>> To: jkrell at elego.de >>> CC: m3commit at elegosoft.com >>> Subject: Re: [M3commit] CVS Update: cm3 >>> >>> This is new. It used to work! >>> >>> >>> On 7 Jul 2010, at 08:20, Jay Krell wrote: >>> >>>> CVSROOT: /usr/cvs >>>> Changes by: jkrell at birch. 10/07/07 08:20:57 >>>> >>>> Modified files: >>>> cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c >>>> >>>> Log message: >>>> partial redundancy elimination ('pre') also crashes compiling libm3/Formatter, add comment; remove all the other stuff about disabling optimizations >>> >> > From jay.krell at cornell.edu Wed Jul 7 21:54:53 2010 From: jay.krell at cornell.edu (Jay K) Date: Wed, 7 Jul 2010 19:54:53 +0000 Subject: [M3commit] CVS Update: cm3 In-Reply-To: References: <20100707062057.34A3B2474003@birch.elegosoft.com>, , , Message-ID: But I admit I'm nervous about removing all the volatile, esp. on stores. We should have a bunch of tests using exceptions that access locals/parameters in except and finally blocks. I'm willing to put back volatile on all stores. Or even loads if there is justification. I thought there'd be a setjmp in all functions with try/except/finally, and therefore the same pessimization, but now I'm not sure of that. ?- Jay ---------------------------------------- > From: jay.krell at cornell.edu > To: hosking at cs.purdue.edu; jkrell at elego.de > Date: Wed, 7 Jul 2010 19:13:02 +0000 > CC: m3commit at elegosoft.com > Subject: Re: [M3commit] CVS Update: cm3 > > > Back when all loads and stores were volatile! > And the optimizer was severely hampered. Any optimized code I looked at was full of unnecessary code. > Which do you prefer? > > - Jay > > ---------------------------------------- > > From: hosking at cs.purdue.edu > > Date: Wed, 7 Jul 2010 11:56:30 -0400 > > To: jkrell at elego.de > > CC: m3commit at elegosoft.com > > Subject: Re: [M3commit] CVS Update: cm3 > > > > This is new. It used to work! > > > > > > On 7 Jul 2010, at 08:20, Jay Krell wrote: > > > > > CVSROOT: /usr/cvs > > > Changes by: jkrell at birch. 10/07/07 08:20:57 > > > > > > Modified files: > > > cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c > > > > > > Log message: > > > partial redundancy elimination ('pre') also crashes compiling libm3/Formatter, add comment; remove all the other stuff about disabling optimizations > > > From jay.krell at cornell.edu Wed Jul 7 22:14:49 2010 From: jay.krell at cornell.edu (Jay K) Date: Wed, 7 Jul 2010 20:14:49 +0000 Subject: [M3commit] CVS Update: cm3 In-Reply-To: <2E37CD56-4440-4927-936A-8E40B174F488@cs.purdue.edu> References: <20100707062057.34A3B2474003@birch.elegosoft.com>, , , , , , , <2E37CD56-4440-4927-936A-8E40B174F488@cs.purdue.edu> Message-ID: That's still there, for "returns twice", like setjmp, fork and/or vfork. Not sure about longjmp. Not sure if it is adequate. ?? I saw PushFrame in the crashing example but I don't think I saw setjmp. Not sure about a few things. ?- Jay ---------------------------------------- > From: hosking at cs.purdue.edu > Date: Wed, 7 Jul 2010 15:59:08 -0400 > To: jay.krell at cornell.edu > CC: m3commit at elegosoft.com > Subject: Re: [M3commit] CVS Update: cm3 > > We already volatilise as necessary for setjmp/longjmp (at least we did when last I looked, because I remember putting it in). > > I would prefer to avoid volatile in all other situations where possible. > > > On 7 Jul 2010, at 15:54, Jay K wrote: > > > > > But I admit I'm nervous about removing all the volatile, esp. on stores. > > We should have a bunch of tests using exceptions that access locals/parameters in except and finally blocks. > > I'm willing to put back volatile on all stores. > > Or even loads if there is justification. > > > > I thought there'd be a setjmp in all functions with try/except/finally, and therefore the same > > pessimization, but now I'm not sure of that. > > > > - Jay > > > > ---------------------------------------- > >> From: jay.krell at cornell.edu > >> To: hosking at cs.purdue.edu; jkrell at elego.de > >> Date: Wed, 7 Jul 2010 19:13:02 +0000 > >> CC: m3commit at elegosoft.com > >> Subject: Re: [M3commit] CVS Update: cm3 > >> > >> > >> Back when all loads and stores were volatile! > >> And the optimizer was severely hampered. Any optimized code I looked at was full of unnecessary code. > >> Which do you prefer? > >> > >> - Jay > >> > >> ---------------------------------------- > >>> From: hosking at cs.purdue.edu > >>> Date: Wed, 7 Jul 2010 11:56:30 -0400 > >>> To: jkrell at elego.de > >>> CC: m3commit at elegosoft.com > >>> Subject: Re: [M3commit] CVS Update: cm3 > >>> > >>> This is new. It used to work! > >>> > >>> > >>> On 7 Jul 2010, at 08:20, Jay Krell wrote: > >>> > >>>> CVSROOT: /usr/cvs > >>>> Changes by: jkrell at birch. 10/07/07 08:20:57 > >>>> > >>>> Modified files: > >>>> cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c > >>>> > >>>> Log message: > >>>> partial redundancy elimination ('pre') also crashes compiling libm3/Formatter, add comment; remove all the other stuff about disabling optimizations > >>> > >> > > > From jay.krell at cornell.edu Wed Jul 7 22:19:48 2010 From: jay.krell at cornell.edu (Jay K) Date: Wed, 7 Jul 2010 20:19:48 +0000 Subject: [M3commit] CVS Update: cm3 In-Reply-To: References: <20100707062057.34A3B2474003@birch.elegosoft.com>, , , , , , , , <2E37CD56-4440-4927-936A-8E40B174F488@cs.purdue.edu>, Message-ID: ps: obviously the volatization that is there is overkill, but not too far off. We only really need to volatize what is used in the except/finally blocks. It might be a closer approximation to add volatile to anything referenced in the function after we see the setjmp/fork call, instead of going and visiting all current and future locals. Even that is overkill. I assume making the load/stores volatile is the same as making the variables volatile. ?So there are other similar approaches. However I assume one dumb difference, evidenced by what you already did, is that the warnings vary. The compiler doesn't notice, I guess, that if all load/stores to a variable are volatile, then the variable itself is effectively volatile. Anyway, ok for now. Hm, maybe m3cg should offer volatile as a flag on parameters, locals, temporaries? I'm not sure the backend knows where except/finally blocks are, after all. This isn't the "make function volatile" thing I had, this is something narrower and seems like it might fit better...except, well..volatile is maybe an implementation detail. But you could just rename and get the same thing: "variable accessed in except/finally block". Or, "start except block", "start finally block", "end except block", "end finally block". ? ?- Jay ---------------------------------------- > From: jay.krell at cornell.edu > To: hosking at cs.purdue.edu > CC: m3commit at elegosoft.com > Subject: RE: [M3commit] CVS Update: cm3 > Date: Wed, 7 Jul 2010 20:14:49 +0000 > > > That's still there, for "returns twice", like setjmp, fork and/or vfork. > Not sure about longjmp. > Not sure if it is adequate. > I saw PushFrame in the crashing example but I don't think I saw setjmp. > Not sure about a few things. > > - Jay > > > ---------------------------------------- > > From: hosking at cs.purdue.edu > > Date: Wed, 7 Jul 2010 15:59:08 -0400 > > To: jay.krell at cornell.edu > > CC: m3commit at elegosoft.com > > Subject: Re: [M3commit] CVS Update: cm3 > > > > We already volatilise as necessary for setjmp/longjmp (at least we did when last I looked, because I remember putting it in). > > > > I would prefer to avoid volatile in all other situations where possible. > > > > > > On 7 Jul 2010, at 15:54, Jay K wrote: > > > > > > > > But I admit I'm nervous about removing all the volatile, esp. on stores. > > > We should have a bunch of tests using exceptions that access locals/parameters in except and finally blocks. > > > I'm willing to put back volatile on all stores. > > > Or even loads if there is justification. > > > > > > I thought there'd be a setjmp in all functions with try/except/finally, and therefore the same > > > pessimization, but now I'm not sure of that. > > > > > > - Jay > > > > > > ---------------------------------------- > > >> From: jay.krell at cornell.edu > > >> To: hosking at cs.purdue.edu; jkrell at elego.de > > >> Date: Wed, 7 Jul 2010 19:13:02 +0000 > > >> CC: m3commit at elegosoft.com > > >> Subject: Re: [M3commit] CVS Update: cm3 > > >> > > >> > > >> Back when all loads and stores were volatile! > > >> And the optimizer was severely hampered. Any optimized code I looked at was full of unnecessary code. > > >> Which do you prefer? > > >> > > >> - Jay > > >> > > >> ---------------------------------------- > > >>> From: hosking at cs.purdue.edu > > >>> Date: Wed, 7 Jul 2010 11:56:30 -0400 > > >>> To: jkrell at elego.de > > >>> CC: m3commit at elegosoft.com > > >>> Subject: Re: [M3commit] CVS Update: cm3 > > >>> > > >>> This is new. It used to work! > > >>> > > >>> > > >>> On 7 Jul 2010, at 08:20, Jay Krell wrote: > > >>> > > >>>> CVSROOT: /usr/cvs > > >>>> Changes by: jkrell at birch. 10/07/07 08:20:57 > > >>>> > > >>>> Modified files: > > >>>> cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c > > >>>> > > >>>> Log message: > > >>>> partial redundancy elimination ('pre') also crashes compiling libm3/Formatter, add comment; remove all the other stuff about disabling optimizations > > >>> > > >> > > > > > > From jkrell at elego.de Thu Jul 8 12:20:41 2010 From: jkrell at elego.de (Jay Krell) Date: Thu, 8 Jul 2010 12:20:41 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100708102041.CFC6C2474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/08 12:20:41 Modified files: cm3/m3-sys/m3cc/src/: m3makefile Log message: no actual change but commented out or disabled: append -4.3 to build_dir for 4.3 commented out configure -enable-checking=all (we should make this work) disabled switching to 4.5 for AMD64_DARWIN (should make this work, maybe the pointer use in loophole will help?) From jkrell at elego.de Fri Jul 9 10:04:30 2010 From: jkrell at elego.de (Jay Krell) Date: Fri, 9 Jul 2010 10:04:30 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100709080430.AA1DE2474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/09 10:04:30 Modified files: cm3/scripts/python/: pylib.py Log message: add mspdb100.dll to list -- support for Visual C++ 2010 From jkrell at elego.de Fri Jul 9 10:52:20 2010 From: jkrell at elego.de (Jay Krell) Date: Fri, 9 Jul 2010 10:52:20 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100709085220.CFCAF2474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/09 10:52:20 Modified files: cm3/scripts/python/: Tag: release_branch_cm3_5_8 pylib.py Log message: support for Visual Studio 2010 From jkrell at elego.de Fri Jul 9 13:58:39 2010 From: jkrell at elego.de (Jay Krell) Date: Fri, 9 Jul 2010 13:58:39 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100709115841.8F54B2474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/09 13:58:38 Modified files: cm3/m3-sys/m3front/src/misc/: Scanner.m3 Log message: go back a version, to 1.11; 1.12 causes major problems, presumably it confuses 'word' and 'Word' or something From hosking at elego.de Fri Jul 9 17:09:49 2010 From: hosking at elego.de (Antony Hosking) Date: Fri, 9 Jul 2010 17:09:49 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100709150949.B91DA2474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: hosking at birch. 10/07/09 17:09:49 Modified files: cm3/m3-sys/m3front/src/misc/: Scanner.m3 Log message: No need for extra variable. From jkrell at elego.de Sat Jul 10 13:36:41 2010 From: jkrell at elego.de (Jay Krell) Date: Sat, 10 Jul 2010 13:36:41 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100710113641.697742474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/10 13:36:41 Modified files: cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c Log message: DECL_NONLOCAL in gcc 4.5 to try to mimic x_nonlocal_goto_handler_labels causes harm, detailed in the comments in the code here (needs further investigation) From jkrell at elego.de Sat Jul 10 14:27:27 2010 From: jkrell at elego.de (Jay Krell) Date: Sat, 10 Jul 2010 14:27:27 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100710122727.55F712474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/10 14:27:27 Modified files: cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c Log message: use POINTER_PLUS with gcc 4.3 same as with gcc 4.5 volatilize any function that calls RTHooks__PushEFrame Therefore enabling "pre" optimization (partial redundancy elimination?) This would probably be cleaner in a few other ways: investigate further why gcc doesn't like the trees we produce for this case have a direct call in the middle end: volatilize_current_function understand (at least) the two variants of try/finally don't volatilize all variables In my one test case though, the finally block doesn't access anything, so only volatilizing what is needed would set us back to really having to understand. And, really, volatile even of certain variables is overkill. You just want be sure they are "homed" prior to function calls that can throw, not at every single use and not before function calls that can't throw. From jay.krell at cornell.edu Sat Jul 10 14:29:43 2010 From: jay.krell at cornell.edu (Jay K) Date: Sat, 10 Jul 2010 12:29:43 +0000 Subject: [M3commit] CVS Update: cm3 In-Reply-To: <20100710122727.55F712474003@birch.elegosoft.com> References: <20100710122727.55F712474003@birch.elegosoft.com> Message-ID: not great but maybe ok for the time being, for a while.. ---------------------------------------- > Date: Sat, 10 Jul 2010 14:27: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/07/10 14:27:27 > > Modified files: > cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c > > Log message: > use POINTER_PLUS with gcc 4.3 same as with gcc 4.5 > volatilize any function that calls RTHooks__PushEFrame > Therefore enabling "pre" optimization (partial redundancy elimination?) > This would probably be cleaner in a few other ways: > investigate further why gcc doesn't like the trees we produce for this case > have a direct call in the middle end: volatilize_current_function > understand (at least) the two variants of try/finally > don't volatilize all variables > In my one test case though, the finally block doesn't > access anything, so only volatilizing what is needed > would set us back to really having to understand. > > And, really, volatile even of certain variables is overkill. > You just want be sure they are "homed" prior to function > calls that can throw, not at every single use and not > before function calls that can't throw. > -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: pushframe.txt URL: From jkrell at elego.de Sat Jul 10 14:31:54 2010 From: jkrell at elego.de (Jay Krell) Date: Sat, 10 Jul 2010 14:31:54 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100710123154.8F9D8CC37F@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/10 14:31:54 Modified files: cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c Log message: don't check for pushframe if we are making all load/store volatile From jay.krell at cornell.edu Sat Jul 10 14:35:11 2010 From: jay.krell at cornell.edu (Jay K) Date: Sat, 10 Jul 2010 12:35:11 +0000 Subject: [M3commit] CVS Update: cm3 In-Reply-To: References: <20100710122727.55F712474003@birch.elegosoft.com>, Message-ID: Drat, this doesn't let it work across the whole tree.. new source -> compiling m3totex.m3 ../src/m3totex.m3: In function 'm3totex__Undisplay': ../src/m3totex.m3:210: internal compiler error: in remove_phi_node, at tree-phinodes.c:465 Please submit a full bug report, with preprocessed source if appropriate. See for instructions. ? m3_backend => 4 m3cc (aka cm3cg) failed compiling: m3totex.mc compilation failed => not building program "m3totex" Fatal Error: package build failed ?*** execution of [, ] failed *** (normally this would SIGSEGV but I put assertions in) ---------------------------------------- > From: jay.krell at cornell.edu > To: jkrell at elego.de; m3commit at elegosoft.com > Date: Sat, 10 Jul 2010 12:29:43 +0000 > Subject: Re: [M3commit] CVS Update: cm3 > > > not great but maybe ok for the time being, for a while.. > > ---------------------------------------- > > Date: Sat, 10 Jul 2010 14:27: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/07/10 14:27:27 > > > > Modified files: > > cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c > > > > Log message: > > use POINTER_PLUS with gcc 4.3 same as with gcc 4.5 > > volatilize any function that calls RTHooks__PushEFrame > > Therefore enabling "pre" optimization (partial redundancy elimination?) > > This would probably be cleaner in a few other ways: > > investigate further why gcc doesn't like the trees we produce for this case > > have a direct call in the middle end: volatilize_current_function > > understand (at least) the two variants of try/finally > > don't volatilize all variables > > In my one test case though, the finally block doesn't > > access anything, so only volatilizing what is needed > > would set us back to really having to understand. > > > > And, really, volatile even of certain variables is overkill. > > You just want be sure they are "homed" prior to function > > calls that can throw, not at every single use and not > > before function calls that can't throw. > > > From jkrell at elego.de Sat Jul 10 15:37:59 2010 From: jkrell at elego.de (Jay Krell) Date: Sat, 10 Jul 2010 15:37:59 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100710133759.40A32CC37E@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/10 15:37:59 Modified files: cm3/m3-sys/m3cc/gcc/gcc/m3cg/: m3gty43.h m3gty45.h parse.c Log message: Try something similar/different: in functions that call pushframe, turn off flag_tree_pre That is: save flag_tree_pre away in begin_procedure if we see call pushframe, set flag_tree_pre = 0 restore flag_tree_pre in end_procedure This depends on that curently we compile unit at a time.. which is the "last" optimization to deal with..except this dependency makes "pre" being sometimes enabled dependant on it...so..ultimately..this "fix" probably can't stand. If unit at a time can be fixed soon/easily, re-disable pre and investigate further the problem with try/finally.. From jay.krell at cornell.edu Sat Jul 10 15:38:59 2010 From: jay.krell at cornell.edu (Jay K) Date: Sat, 10 Jul 2010 13:38:59 +0000 Subject: [M3commit] CVS Update: cm3 In-Reply-To: <20100710133759.40A32CC37E@birch.elegosoft.com> References: <20100710133759.40A32CC37E@birch.elegosoft.com> Message-ID: really not great...but it'll take a much deeper investigation to fix this... ---------------------------------------- > Date: Sat, 10 Jul 2010 15:37: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/07/10 15:37:59 > > Modified files: > cm3/m3-sys/m3cc/gcc/gcc/m3cg/: m3gty43.h m3gty45.h parse.c > > Log message: > Try something similar/different: > in functions that call pushframe, turn off flag_tree_pre > > That is: > save flag_tree_pre away in begin_procedure > if we see call pushframe, set flag_tree_pre = 0 > restore flag_tree_pre in end_procedure > > This depends on that curently we compile unit at a time.. > which is the "last" optimization to deal with..except > this dependency makes "pre" being sometimes enabled > dependant on it...so..ultimately..this "fix" probably > can't stand. > > If unit at a time can be fixed soon/easily, re-disable > pre and investigate further the problem with try/finally.. > -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: pushframe2.txt URL: From jkrell at elego.de Sun Jul 11 08:36:41 2010 From: jkrell at elego.de (Jay Krell) Date: Sun, 11 Jul 2010 8:36:41 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100711063641.492EF2474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/11 08:36:41 Added files: cm3/m3-sys/m3tests/src/p2/p242/: Main.m3 m3makefile Log message: add test case reduced from m3totex that crashes in gcc backend if 'pre' is enabled (unless maybe if everything is volatile) From jay.krell at cornell.edu Sun Jul 11 08:45:49 2010 From: jay.krell at cornell.edu (Jay K) Date: Sun, 11 Jul 2010 06:45:49 +0000 Subject: [M3commit] CVS Update: cm3 In-Reply-To: <20100711063641.492EF2474003@birch.elegosoft.com> References: <20100711063641.492EF2474003@birch.elegosoft.com> Message-ID: Strange cvs behavior. m3tests/src/m3makefile did get edited too. ?- Jay ---------------------------------------- > Date: Sun, 11 Jul 2010 08:36: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/07/11 08:36:41 > > Added files: > cm3/m3-sys/m3tests/src/p2/p242/: Main.m3 m3makefile > > Log message: > add test case reduced from m3totex that crashes in gcc > backend if 'pre' is enabled (unless maybe if everything > is volatile) > From jkrell at elego.de Sun Jul 11 08:55:30 2010 From: jkrell at elego.de (Jay Krell) Date: Sun, 11 Jul 2010 8:55:30 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100711065530.B35ECCC382@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/11 08:55:30 Modified files: cm3/m3-sys/m3tests/src/: m3makefile Added files: cm3/m3-sys/m3tests/src/p2/p243/: Main.m3 m3makefile Log message: add test case that fails to compile when gcc backend compiles "unit at a time" because nested functions aren't preserved From jkrell at elego.de Sun Jul 11 09:37:21 2010 From: jkrell at elego.de (Jay Krell) Date: Sun, 11 Jul 2010 9:37:21 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100711073722.3335C2474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/11 09:37:21 Modified files: cm3/m3-sys/m3cc/gcc/gcc/m3cg/: m3gty43.h m3gty45.h parse.c Log message: more tracing: quoted_string just leave 'pre' off all the time, for now What i had was sort of better, pre on sometimes, but also kind of yucky. From jkrell at elego.de Sun Jul 11 10:13:08 2010 From: jkrell at elego.de (Jay Krell) Date: Sun, 11 Jul 2010 10:13:08 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100711081308.F189CCC389@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/11 10:13:08 Modified files: cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c Log message: mark nested functions as "public", so that unit at a time doesn't remove them Still, "public" isn't so bad, they are still "hidden" on platforms that support that. (That is, they are accessible from within the .so but not exported to outside it.) From jkrell at elego.de Sun Jul 11 10:15:24 2010 From: jkrell at elego.de (Jay Krell) Date: Sun, 11 Jul 2010 10:15:24 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100711081524.E688A2474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/11 10:15:24 Modified files: cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c Log message: edit the comment about making all functions 'public' From jay.krell at cornell.edu Sun Jul 11 10:31:47 2010 From: jay.krell at cornell.edu (Jay K) Date: Sun, 11 Jul 2010 08:31:47 +0000 Subject: [M3commit] CVS Update: cm3 In-Reply-To: <20100711073722.3335C2474003@birch.elegosoft.com> References: <20100711073722.3335C2474003@birch.elegosoft.com> Message-ID: In 4.5 (or 4.4) we can selectively deoptimize functions using underlying infrastructure. ?- Jay ---------------------------------------- > Date: Sun, 11 Jul 2010 09:37:21 +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/07/11 09:37:21 > > Modified files: > cm3/m3-sys/m3cc/gcc/gcc/m3cg/: m3gty43.h m3gty45.h parse.c > > Log message: > more tracing: quoted_string > just leave 'pre' off all the time, for now > What i had was sort of better, pre on sometimes, but also > kind of yucky. > From jkrell at elego.de Sun Jul 11 10:53:01 2010 From: jkrell at elego.de (Jay Krell) Date: Sun, 11 Jul 2010 10:53:01 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100711085301.8CE27CC389@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/11 10:53:01 Modified files: cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c Log message: TREE_PUBLIC (p) = ((lev == 0) || flag_unit_at_a_time); instead of just 1 From jkrell at elego.de Sun Jul 11 11:05:50 2010 From: jkrell at elego.de (Jay Krell) Date: Sun, 11 Jul 2010 11:05:50 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100711090550.6E1B92474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/11 11:05:50 Modified files: cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c Log message: in the gcc 4.2 (and maybe 4.5) don't bother with the add if adding zero From jkrell at elego.de Sun Jul 11 11:19:09 2010 From: jkrell at elego.de (Jay Krell) Date: Sun, 11 Jul 2010 11:19:09 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100711091909.312D4CC37F@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/11 11:19:09 Modified files: cm3/m3-sys/m3tests/src/p2/p240/expected/AMD64_DARWIN/: A.ms divmod_pow2.ms Log message: update (esp. with removal of div/mod functions, the the result at least when not optimized is much larger) From jkrell at elego.de Sun Jul 11 11:23:29 2010 From: jkrell at elego.de (Jay Krell) Date: Sun, 11 Jul 2010 11:23:29 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100711092329.C25BF2474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/11 11:23:29 Modified files: cm3/m3-sys/m3tests/src/p2/p240/: m3makefile Log message: whitespace From jkrell at elego.de Sun Jul 11 11:50:59 2010 From: jkrell at elego.de (Jay Krell) Date: Sun, 11 Jul 2010 11:50:59 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100711095100.276A22474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/11 11:50:59 Modified files: cm3/m3-sys/m3tests/src/p2/p240/: m3makefile cm3/m3-sys/m3tests/src/p2/p240/expected/AMD64_DARWIN/: bitfield.ms extract.ms insert.ms Added files: cm3/m3-sys/m3tests/src/p2/p240/expected/AMD64_DARWIN/: And.ms Divide.ms EQ.ms GE.ms GT.ms LE.ms LT.ms LeftRotate.ms LeftShift.ms Minus.ms Mod.ms NE.ms Not.ms Or.ms Plus.ms RightRotate.ms RightShift.ms Rotate.ms Shift.ms Times.ms Xor.ms div_pow2.ms extract_constant_both.ms extract_constant_count.ms extract_constant_offset.ms insert_constant_both.ms insert_constant_count.ms insert_constant_offset.ms mod_pow2.ms return_constant.ms return_parameter.ms return_parameter_convert.ms return_variable.ms Log message: split up into more files (too many?) From jkrell at elego.de Sun Jul 11 12:51:00 2010 From: jkrell at elego.de (Jay Krell) Date: Sun, 11 Jul 2010 12:51:00 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100711105100.D1AB9CC37F@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/11 12:51:00 Modified files: cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c Log message: disable 'fre' for gcc 4.5, it crashes From jkrell at elego.de Sun Jul 11 12:52:59 2010 From: jkrell at elego.de (Jay Krell) Date: Sun, 11 Jul 2010 12:52:59 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100711105300.09B6D2474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/11 12:52:59 Modified files: cm3/m3-sys/m3tests/src/: m3makefile Added files: cm3/m3-sys/m3tests/src/p2/p244/: Main.m3 m3makefile Log message: add a case that crashes gcc 4.5 backend if 'fre' enabled (this reduced from something in p240 I was looking at; p240 always disables optimizations, until such time as we expand the test framework to iterate through various optimization options..) From jkrell at elego.de Sun Jul 11 12:55:21 2010 From: jkrell at elego.de (Jay Krell) Date: Sun, 11 Jul 2010 12:55:21 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100711105521.ECB9D2474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/11 12:55:21 Modified files: cm3/m3-sys/m3tests/src/p2/p244/: m3makefile Log message: make sure optimization is enabled From jkrell at elego.de Sun Jul 11 13:06:03 2010 From: jkrell at elego.de (Jay Krell) Date: Sun, 11 Jul 2010 13:06:03 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100711110603.B28A12474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/11 13:06:03 Modified files: cm3/m3-sys/m3tests/src/p2/p240/expected/AMD64_DARWIN/: And.ms Divide.ms EQ.ms GE.ms GT.ms LE.ms LT.ms LeftRotate.ms LeftShift.ms Minus.ms Mod.ms NE.ms Not.ms Or.ms Plus.ms RightRotate.ms RightShift.ms Rotate.ms Shift.ms Times.ms Xor.ms bitfield.ms div_pow2.ms extract.ms extract_constant_both.ms extract_constant_count.ms extract_constant_offset.ms insert.ms insert_constant_both.ms insert_constant_count.ms insert_constant_offset.ms mod_pow2.ms return_constant.ms return_parameter.ms return_parameter_convert.ms return_variable.ms Log message: update: I don't know why, but maybe I commited out of date versions before? Here the main change seems just reordering functions. From jkrell at elego.de Sun Jul 11 13:19:35 2010 From: jkrell at elego.de (Jay Krell) Date: Sun, 11 Jul 2010 13:19:35 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100711111935.6C3B8CC37F@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/11 13:19:35 Modified files: cm3/m3-sys/m3cc/gcc-4.5/gcc/: gimplify.c Log message: put the #if 1 back to #ifdef ENABLE_TYPES_CHECKING, though this area still needs work From jkrell at elego.de Sun Jul 11 13:58:02 2010 From: jkrell at elego.de (Jay Krell) Date: Sun, 11 Jul 2010 13:58:02 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100711115802.927FE2474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/11 13:58:02 Modified files: cm3/m3-sys/m3tests/src/p2/p244/: Main.m3 Log message: fix comment: the original problem I was looking at was due to functions being out of order and I was comparin them wrong, but this test case remains useful as a crasher for gcc 4.5 'fre' From jkrell at elego.de Sun Jul 11 14:39:59 2010 From: jkrell at elego.de (Jay Krell) Date: Sun, 11 Jul 2010 14:39:59 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100711123959.955122474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/11 14:39:59 Modified files: cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c Log message: gcc 4.5 -O1 and -O2 seem ok but some of the -O3 passes fail: flag_predictive_commoning flag_ipa_cp_clone flag_inline_functions is not optimizing for size Failures generally seen compiling m3-libs/sysutils/System.m3. As well 'pre' which has problems in 4.3 also has problems in 4.5, problems seen compiling m3front. And 'fre' already disabled (see test p244). From jkrell at elego.de Sun Jul 11 15:14:53 2010 From: jkrell at elego.de (Jay Krell) Date: Sun, 11 Jul 2010 15:14:53 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100711131453.72F102474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/11 15:14:53 Modified files: cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c Log message: fix the -Wc++-compat warnings/errors you see if using newer gcc class => clas int => enum and the "poison" thing, not sure why it appears on some machines and not others, could again be different gcc version From jkrell at elego.de Mon Jul 12 00:32:00 2010 From: jkrell at elego.de (Jay Krell) Date: Mon, 12 Jul 2010 0:32:00 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100711223201.000432474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/12 00:32:00 Modified files: cm3/m3-sys/m3cc/gcc-4.5/gcc/: targhooks.c Log message: allow NULL fndecl in default_static_chain (I already did this in the x86-specific hook, need to check for others, this was SIGSEVing on SOLgnu) From jkrell at elego.de Mon Jul 12 00:34:59 2010 From: jkrell at elego.de (Jay Krell) Date: Mon, 12 Jul 2010 0:34:59 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100711223459.F01262474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/12 00:34:59 Modified files: cm3/m3-sys/m3cc/gcc-4.5/gcc/config/moxie/: moxie.c Log message: allow NULL fndecl in moxie_static_chain From jkrell at elego.de Mon Jul 12 00:50:34 2010 From: jkrell at elego.de (Jay Krell) Date: Mon, 12 Jul 2010 0:50:34 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100711225035.15E2E2474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/12 00:50:34 Modified files: cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c Log message: gcc 4.5: mark barrier labels rtx with LABEL_REF_NONLOCAL_P, does it help/matter? From jkrell at elego.de Mon Jul 12 01:39:14 2010 From: jkrell at elego.de (Jay Krell) Date: Mon, 12 Jul 2010 1:39:14 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100711233914.8CBA02474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/12 01:39:14 Modified files: cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c Log message: hm LABEL_REF_NONLOCAL_P I thought had helped maybe on I386_LINUX and SOLgnu but it clearly hurts on AMD64_DARWIN From jkrell at elego.de Mon Jul 12 04:25:25 2010 From: jkrell at elego.de (Jay Krell) Date: Mon, 12 Jul 2010 4:25:25 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100712022526.767D12474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/12 04:25:25 Modified files: cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c Log message: gcc 4.5: turn off all inlining: m3-sys/m3cc/AMD64_DARWIN-SOLgnu/cm3cg -quiet -O3 m3core/SOLgnu/Poly.mc fingerprint/Poly.m3: In function 'Poly__FromBytes': fingerprint/Poly.m3:379:0: internal compiler error: in referenced_var_lookup, at tree-dfa.c:519 From jay.krell at cornell.edu Mon Jul 12 04:40:37 2010 From: jay.krell at cornell.edu (Jay K) Date: Mon, 12 Jul 2010 02:40:37 +0000 Subject: [M3commit] CVS Update: cm3 In-Reply-To: <20100712022526.767D12474003@birch.elegosoft.com> References: <20100712022526.767D12474003@birch.elegosoft.com> Message-ID: This is unfortunate. ---------------------------------------- > Date: Mon, 12 Jul 2010 04:25:25 +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/07/12 04:25:25 > > Modified files: > cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c > > Log message: > gcc 4.5: turn off all inlining: > m3-sys/m3cc/AMD64_DARWIN-SOLgnu/cm3cg -quiet -O3 m3core/SOLgnu/Poly.mc > fingerprint/Poly.m3: In function 'Poly__FromBytes': > fingerprint/Poly.m3:379:0: internal compiler error: > in referenced_var_lookup, at tree-dfa.c:519 > From jkrell at elego.de Mon Jul 12 11:08:00 2010 From: jkrell at elego.de (Jay Krell) Date: Mon, 12 Jul 2010 11:08:00 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100712090800.443892474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/12 11:08:00 Modified files: cm3/m3-sys/m3tests/src/: m3makefile Added files: cm3/m3-sys/m3tests/src/p2/p245/: Main.m3 m3makefile Log message: test case reduced from m3core/TextConv.m3 that gives: internal compiler error: in estimate_move_cost, at tree-inline.c:3016 when gcc 4.5 does inlining The assertion is that the type isn't void. The problem seems related to the set of char, but we'll see. From jkrell at elego.de Mon Jul 12 11:14:40 2010 From: jkrell at elego.de (Jay Krell) Date: Mon, 12 Jul 2010 11:14:40 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100712091440.4BFA92474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/12 11:14:40 Modified files: cm3/m3-sys/m3tests/src/p2/p245/: Main.m3 Log message: slightly different/smaller From jkrell at elego.de Mon Jul 12 11:46:41 2010 From: jkrell at elego.de (Jay Krell) Date: Mon, 12 Jul 2010 11:46:41 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100712094641.5886E2474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/12 11:46:41 Modified files: cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c Log message: represent sets as a pointer to a word, not an untyped pointer This seems fixes inlining on AMD64_DARWIN (more testing being done, including of SOLgnu). This was my fault: the old code to call functions didn't have to worry about the types of sets, because it didn't dereference them.. From jkrell at elego.de Mon Jul 12 12:14:13 2010 From: jkrell at elego.de (Jay Krell) Date: Mon, 12 Jul 2010 12:14:13 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100712101413.8FD042474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/12 12:14:13 Modified files: cm3/m3-sys/m3tests/src/: m3makefile Added files: cm3/m3-sys/m3tests/src/p2/p246/: Main.m3 m3makefile Log message: gcc 4.5 assertion failure inlining in Poly.m3 for SOLgnu From jkrell at elego.de Mon Jul 12 13:14:02 2010 From: jkrell at elego.de (Jay Krell) Date: Mon, 12 Jul 2010 13:14:02 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100712111402.DA96E2474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/12 13:14:02 Modified files: cm3/m3-sys/cminstall/src/config-no-install/: I386.common Log message: don't mess with preferred-stack-boundary, it makes me nervouse From jkrell at elego.de Mon Jul 12 13:16:13 2010 From: jkrell at elego.de (Jay Krell) Date: Mon, 12 Jul 2010 13:16:13 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100712111613.7C0802474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/12 13:16:13 Modified files: cm3/m3-sys/cminstall/src/config-no-install/: cm3cfg.common Log message: move comment that seemed misplaced From jkrell at elego.de Mon Jul 12 13:17:33 2010 From: jkrell at elego.de (Jay Krell) Date: Mon, 12 Jul 2010 13:17:33 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100712111733.B9E2B2474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/12 13:17:33 Modified files: cm3/m3-sys/cminstall/src/config-no-install/: VMS.common Log message: [] to [ ] so the characters don't run together, depending on font From jkrell at elego.de Mon Jul 12 13:21:45 2010 From: jkrell at elego.de (Jay Krell) Date: Mon, 12 Jul 2010 13:21:45 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100712112145.C54702474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/12 13:21:45 Modified files: cm3/m3-sys/cminstall/src/config-no-install/: PPC_LINUX Log message: fix typo in comment From jkrell at elego.de Mon Jul 12 13:28:00 2010 From: jkrell at elego.de (Jay Krell) Date: Mon, 12 Jul 2010 13:28:00 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100712112800.C1E5C2474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/12 13:28:00 Modified files: cm3/m3-sys/cminstall/src/config-no-install/: Interix.common Log message: no change, just commit so I take ownership on CVS server so I can clear the execute attribute, which is often present on files I added from Windows From jkrell at elego.de Mon Jul 12 13:37:49 2010 From: jkrell at elego.de (Jay Krell) Date: Mon, 12 Jul 2010 13:37:49 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100712113749.80AD62474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/12 13:37:49 Modified files: cm3/m3-sys/m3tests/src/: m3makefile cm3/m3-sys/m3tests/src/p2/p246/: Main.m3 Log message: update comments to indicate it also occurs on I386_DARWIN which is fortunate because at least I have a fractionally decent editor there (vs. zero everywhere else, except NT) and my SOLgnu machine is very slow probably all 32bit platforms? There is another problem though that might be SOLgnu specific, not yet reduced to a small case. From jkrell at elego.de Mon Jul 12 14:23:53 2010 From: jkrell at elego.de (Jay Krell) Date: Mon, 12 Jul 2010 14:23:53 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100712122353.4C06C2474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/12 14:23:53 Modified files: cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c Log message: update add_stmt function in minor way to match gcc 4.3/4.5 function of same name in c-decl.c (much of the Modula-3 backend is clearly a clone of the C frontend) From wagner at elego.de Mon Jul 12 21:35:06 2010 From: wagner at elego.de (Olaf Wagner) Date: Mon, 12 Jul 2010 21:35:06 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100712193506.C5BCF2474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: wagner at birch. 10/07/12 21:35:06 Modified files: cm3/www/releng/: Tag: release_branch_cm3_5_8 index.html update-releng-index.sh Log message: final release updates From wagner at elego.de Mon Jul 12 21:38:21 2010 From: wagner at elego.de (Olaf Wagner) Date: Mon, 12 Jul 2010 21:38:21 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100712193821.4740C2474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: wagner at birch. 10/07/12 21:38:21 Modified files: cm3/www/releng/: Tag: release_branch_cm3_5_8 update-releng-index.sh Added files: cm3/www/releng/: Tag: release_branch_cm3_5_8 relnotes-5.8.6.html Log message: final release updates From wagner at elego.de Mon Jul 12 21:42:41 2010 From: wagner at elego.de (Olaf Wagner) Date: Mon, 12 Jul 2010 21:42:41 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100712194241.620C32474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: wagner at birch. 10/07/12 21:42:41 Modified files: cm3/www/releng/: Tag: release_branch_cm3_5_8 update-releng-index.sh Log message: final release updates From wagner at elego.de Mon Jul 12 21:43:48 2010 From: wagner at elego.de (Olaf Wagner) Date: Mon, 12 Jul 2010 21:43:48 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100712194348.E5C672474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: wagner at birch. 10/07/12 21:43:48 Modified files: cm3/www/: Tag: release_branch_cm3_5_8 download.html news.html Log message: final release updates From jkrell at elego.de Tue Jul 13 14:34:28 2010 From: jkrell at elego.de (Jay Krell) Date: Tue, 13 Jul 2010 14:34:28 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100713123428.678CF2474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/13 14:34:28 Modified files: cm3/m3-sys/m3cc/gcc/: configure.ac Log message: experimental: remove freebsd/gmp special case; this is deliberately two separate commits to perhaps manage the timestamps From jkrell at elego.de Tue Jul 13 14:34:44 2010 From: jkrell at elego.de (Jay Krell) Date: Tue, 13 Jul 2010 14:34:44 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100713123444.166542474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/13 14:34:44 Modified files: cm3/m3-sys/m3cc/gcc/: configure Log message: experimental: remove freebsd/gmp special case; this is deliberately two separate commits to perhaps manage the timestamps From jkrell at elego.de Tue Jul 13 15:14:33 2010 From: jkrell at elego.de (Jay Krell) Date: Tue, 13 Jul 2010 15:14:33 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100713131433.579482474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/13 15:14:33 Modified files: cm3/m3-libs/m3core/src/runtime/common/: RTProcessC.c Log message: no pthread_atfork on FreeBSD <= 4 From jkrell at elego.de Tue Jul 13 15:18:23 2010 From: jkrell at elego.de (Jay Krell) Date: Tue, 13 Jul 2010 15:18:23 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100713131825.2D9EA2474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/13 15:18:23 Modified files: cm3/m3-libs/m3core/src/thread/POSIX/: ThreadPosixC.c Log message: try sigaltstack instead of make/get/set/swapcontext on FreeBSD <= 4 From jkrell at elego.de Tue Jul 13 15:22:28 2010 From: jkrell at elego.de (Jay Krell) Date: Tue, 13 Jul 2010 15:22:28 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100713132228.137FC2474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/13 15:22:28 Modified files: cm3/m3-libs/m3core/src/runtime/common/: RTProcessC.c Log message: parens and word-wrap From jkrell at elego.de Tue Jul 13 15:30:13 2010 From: jkrell at elego.de (Jay Krell) Date: Tue, 13 Jul 2010 15:30:13 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100713133013.6A2F6CC37E@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/13 15:30:13 Modified files: cm3/m3-libs/m3core/src/runtime/common/: RTProcessC.c Log message: pthread_atfork added in FreeBSD 5 (this would be a good use of autoconf) From jkrell at elego.de Tue Jul 13 15:30:55 2010 From: jkrell at elego.de (Jay Krell) Date: Tue, 13 Jul 2010 15:30:55 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100713133055.13D592474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/13 15:30:55 Modified files: cm3/m3-libs/m3core/src/runtime/common/: RTProcessC.c Log message: really no diff here, but I meant: pthread_atfork added in FreeBSD 6 (this would be a good use of autoconf) From jkrell at elego.de Wed Jul 14 10:03:05 2010 From: jkrell at elego.de (Jay Krell) Date: Wed, 14 Jul 2010 10:03:05 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100714080306.136922474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/14 10:03:05 Modified files: cm3/m3-sys/m3cc/gcc-4.5/: configure.ac Log message: remove freebsd/gmp special case here toof From jkrell at elego.de Wed Jul 14 10:03:22 2010 From: jkrell at elego.de (Jay Krell) Date: Wed, 14 Jul 2010 10:03:22 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100714080322.3EEC02474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/14 10:03:22 Modified files: cm3/m3-sys/m3cc/gcc-4.5/: configure Log message: remove freebsd/gmp special case here too From jkrell at elego.de Wed Jul 14 10:06:01 2010 From: jkrell at elego.de (Jay Krell) Date: Wed, 14 Jul 2010 10:06:01 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100714080601.642F4CC110@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/14 10:06:01 Modified files: cm3/m3-sys/m3cc/gcc-apple/: configure.in Log message: remove freebsd/gmp special case here too From jkrell at elego.de Wed Jul 14 10:06:25 2010 From: jkrell at elego.de (Jay Krell) Date: Wed, 14 Jul 2010 10:06:25 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100714080625.D655D2474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/14 10:06:25 Modified files: cm3/m3-sys/m3cc/gcc-apple/: configure Log message: remove freebsd/gmp special case here too From jkrell at elego.de Wed Jul 14 10:44:35 2010 From: jkrell at elego.de (Jay Krell) Date: Wed, 14 Jul 2010 10:44:35 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100714084435.3B3272474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/14 10:44:35 Modified files: cm3/m3-libs/m3core/src/unix/Common/: Uin.c Log message: fixes for FreeBSD 4: need to include ntohl might be macros, so can't use M3WRAP1 From jkrell at elego.de Wed Jul 14 10:53:29 2010 From: jkrell at elego.de (Jay Krell) Date: Wed, 14 Jul 2010 10:53:29 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100714085329.8BBDECC110@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/14 10:53:29 Modified files: cm3/scripts/python/: pylib.py cm3/m3-sys/cminstall/src/config-no-install/: FreeBSD.common Log message: somewhat experimental: -pthread instead of -lpthread Really I'd like to try this across the board, but just FreeBSD for now. -lpthread failed on FreeBSD 4 where -pthread worked, hopefully -pthread works on all future FreeBSD also. (probably, at least, it is a gcc thing, and usable on all Linux, *BSD) From jkrell at elego.de Wed Jul 14 11:07:35 2010 From: jkrell at elego.de (Jay Krell) Date: Wed, 14 Jul 2010 11:07:35 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100714090735.7BF902474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/14 11:07:35 Modified files: cm3/m3-sys/cminstall/src/config-no-install/: FreeBSD.common Linux.common OpenBSD.common NetBSD.common Log message: -lpthread => -pthread tested quickly minimally on Linux, OpenBSD, not tested on NetBSD FreeBSD.common is just a comment change The LIBC line in Unix.common is probably dead now..could be changed to -pthread. From jkrell at elego.de Wed Jul 14 11:37:25 2010 From: jkrell at elego.de (Jay Krell) Date: Wed, 14 Jul 2010 11:37:25 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100714093726.1AA0F2474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/14 11:37:25 Modified files: cm3/m3-sys/cminstall/src/config-no-install/: FreeBSD.common HPUX.common Linux.common NetBSD.common OpenBSD.common Solaris.common Unix.common VMS.common Log message: some -lpthread, -pthread, SYSTEM_LIBS cleanup Mainly just to reduce some duplication. This area needs more thought, design, work, testing, but this is probably ok. Some of the flaws include: - Unix.common isn't really common to 'Unix', but Linux and *BSD, at least regards to SYSTEM_LIBS - There remains some need for user-editing/configuration/autoconf/install. - Perhaps by moving some of the "less meant to be configured" parts into Modula-3 code. From jkrell at elego.de Wed Jul 14 11:45:58 2010 From: jkrell at elego.de (Jay Krell) Date: Wed, 14 Jul 2010 11:45:58 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100714094559.152572474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/14 11:45:58 Modified files: cm3/m3-sys/cminstall/src/config-no-install/: Darwin.common Log message: shorten line that was over 240 characters long From jkrell at elego.de Wed Jul 14 11:59:29 2010 From: jkrell at elego.de (Jay Krell) Date: Wed, 14 Jul 2010 11:59:29 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100714095929.C5E8FCC110@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/14 11:59:29 Modified files: cm3/m3-libs/m3core/src/thread/POSIX/: ThreadPosixC.c Log message: allow for 2GB page size perhaps and > 2GB stack, on 64 bit, user threads From jkrell at elego.de Wed Jul 14 12:03:28 2010 From: jkrell at elego.de (Jay Krell) Date: Wed, 14 Jul 2010 12:03:28 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100714100328.451C02474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/14 12:03:28 Modified files: cm3/m3-libs/m3core/src/thread/POSIX/: ThreadPosixC.c Log message: stack size in words is CARDINAL, not int: make it match the Modula-3 declaration, and thereby allow even larger stacks on 64bit, user threads From jkrell at elego.de Wed Jul 14 12:05:36 2010 From: jkrell at elego.de (Jay Krell) Date: Wed, 14 Jul 2010 12:05:36 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100714100536.5195F2474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/14 12:05:36 Modified files: cm3/m3-libs/m3core/src/thread/POSIX/: ThreadPosixC.c Log message: let's use INTEGER instead of WORD_T, the point wasn't so much to reclaim one bit, but 30 or so From jkrell at elego.de Wed Jul 14 12:06:37 2010 From: jkrell at elego.de (Jay Krell) Date: Wed, 14 Jul 2010 12:06:37 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100714100637.DB4B72474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/14 12:06:37 Modified files: cm3/m3-libs/m3core/src/thread/POSIX/: ThreadPosixC.c Log message: partial check for integer overflow, should do better in general ('integer overflow is the new buffer overflow?') From jkrell at elego.de Wed Jul 14 12:43:21 2010 From: jkrell at elego.de (Jay Krell) Date: Wed, 14 Jul 2010 12:43:21 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100714104321.D45A42474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/14 12:43:21 Modified files: cm3/scripts/python/: pylib.py Log message: some -pthread vs. -lpthread stuff (autoconf??) From jkrell at elego.de Wed Jul 14 12:44:44 2010 From: jkrell at elego.de (Jay Krell) Date: Wed, 14 Jul 2010 12:44:44 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100714104444.E24EC2474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/14 12:44:44 Modified files: cm3/scripts/python/: pylib.py Log message: add a url (or search the web) From jkrell at elego.de Wed Jul 14 12:46:04 2010 From: jkrell at elego.de (Jay Krell) Date: Wed, 14 Jul 2010 12:46:04 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100714104605.090F12474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/14 12:46:04 Modified files: cm3/scripts/python/: pylib.py Log message: better: there is an autoconf macro From jkrell at elego.de Wed Jul 14 13:22:20 2010 From: jkrell at elego.de (Jay Krell) Date: Wed, 14 Jul 2010 13:22:20 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100714112220.20C51CC37E@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/14 13:22:20 Modified files: cm3/m3-libs/libm3/src/: m3makefile Added files: cm3/m3-libs/libm3/src/types/: LongrealType.i3 RealType.i3 m3makefile Log message: restore some source compability for Mika? From jkrell at elego.de Wed Jul 14 14:34:29 2010 From: jkrell at elego.de (Jay Krell) Date: Wed, 14 Jul 2010 14:34:29 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100714123429.8E30FCC37E@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/14 14:34:29 Modified files: cm3/m3-sys/cminstall/src/config-no-install/: FreeBSD.common FreeBSD4 I386_FREEBSD gnuld.common Log message: FreeBSD4: configure compiler/linker to adjust to older versions: older gcc doesn't like -m32, keep -m32 out if -m32 gives expected error Safe to always omit -m32? older gcc misinterprets -Bsymbolic, use -Wl,-Bsymbolic -Bsymbolic inhibits -lc, add -lc only upon expected link error Safe to always add -lc? Safe to omit -Bsymbolic, but it is a nice optimization. On the other hand, this optimization is costing a lot, extra compile/link for every link of a shared library. Alternatives include: gcc -v | fgrep 2.95 uname -r | grep ^4 do nothing, let users (Mika) edit the config files do similar to what we have, but less often From jkrell at elego.de Wed Jul 14 14:43:33 2010 From: jkrell at elego.de (Jay Krell) Date: Wed, 14 Jul 2010 14:43:33 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100714124333.CEAC22474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/14 14:43:33 Modified files: cm3/m3-sys/cminstall/src/config-no-install/: Unix.common Log message: missing call to configure_linker From jkrell at elego.de Wed Jul 14 15:06:50 2010 From: jkrell at elego.de (Jay Krell) Date: Wed, 14 Jul 2010 15:06:50 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100714130650.9AE3F2474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/14 15:06:50 Modified files: cm3/m3-sys/cminstall/src/config-no-install/: I386_FREEBSD cm3cfg.common Log message: switch to a uname-based approach This is probably much faster, but also in particular, I want to make the pthread/userthread choice based on it, and remove -pthread from LIBC based on it, since that causes a bunch of link errors From jkrell at elego.de Wed Jul 14 15:14:55 2010 From: jkrell at elego.de (Jay Krell) Date: Wed, 14 Jul 2010 15:14:55 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100714131455.8A54D2474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/14 15:14:55 Modified files: cm3/m3-libs/m3core/src/: thread.quake cm3/m3-sys/cminstall/src/config-no-install/: I386_FREEBSD Log message: Always use user threads on FreeBSD4 and remove -pthread from SYSTEM_LIBC{"LIBC"} Note that this detection only works for native builds. Cross builds still require manual edits. Perhaps environments should be supported, or I should fix my Python scripts to pass along extra parameters. From jkrell at elego.de Wed Jul 14 15:23:04 2010 From: jkrell at elego.de (Jay Krell) Date: Wed, 14 Jul 2010 15:23:04 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100714132304.DB6512474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/14 15:23:04 Modified files: cm3/m3-libs/m3core/src/: thread.quake Log message: really now, use user threads on native FreeBSD4 builds (really, FreeBSD version 4, not 'FreeBSD4' meaning 'I386_FREEBSD') From jkrell at elego.de Wed Jul 14 15:50:52 2010 From: jkrell at elego.de (Jay Krell) Date: Wed, 14 Jul 2010 15:50:52 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100714135052.1950C2474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/14 15:50:52 Modified files: cm3/m3-sys/cminstall/src/config-no-install/: cm3cfg.common Log message: target equivalence, though this didn't solve the problem I was looking at, I think system_libs{libc} is read before I change it From jkrell at elego.de Wed Jul 14 15:54:37 2010 From: jkrell at elego.de (Jay Krell) Date: Wed, 14 Jul 2010 15:54:37 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100714135437.BD2A12474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/14 15:54:37 Modified files: cm3/m3-sys/cminstall/src/config-no-install/: I386_FREEBSD Log message: I386_FREEBSD From jkrell at elego.de Wed Jul 14 15:55:53 2010 From: jkrell at elego.de (Jay Krell) Date: Wed, 14 Jul 2010 15:55:53 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100714135553.8DF042474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/14 15:55:53 Modified files: cm3/m3-sys/cminstall/src/config-no-install/: I386_FREEBSD Log message: previous comment flubbed: really, don't use -pthread on FreeBSD4 It seems SYSTEM_LIBS{"LIBC"} is read before configure_linker runs, so instead of changing it there, we set it to just -lm much earlier, and then if we wanted -pthread, add it to SYSTEM_LD. From jkrell at elego.de Wed Jul 14 16:16:19 2010 From: jkrell at elego.de (Jay Krell) Date: Wed, 14 Jul 2010 16:16:19 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100714141619.26FE12474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/14 16:16:19 Modified files: cm3/m3-libs/m3core/src/thread/POSIX/: ThreadPosixC.c Log message: oops, the initial thread is already allocated, that's what words == 0 indicates: don't allocate a stack From jkrell at elego.de Wed Jul 14 16:39:40 2010 From: jkrell at elego.de (Jay Krell) Date: Wed, 14 Jul 2010 16:39:40 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100714143940.3C47A2474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/14 16:39:40 Modified files: cm3/scripts/python/: pylib.py Log message: put back -lpthread on Solaris, at least while looking for problem From jkrell at elego.de Wed Jul 14 16:41:29 2010 From: jkrell at elego.de (Jay Krell) Date: Wed, 14 Jul 2010 16:41:29 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100714144129.241162474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/14 16:41:29 Modified files: cm3/m3-sys/cminstall/src/config-no-install/: Solaris.common Log message: put back -lpthread, but I don't think this is the problem From wagner at elego.de Thu Jul 15 08:02:07 2010 From: wagner at elego.de (Olaf Wagner) Date: Thu, 15 Jul 2010 8:02:07 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100715060207.8164D2474006@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: wagner at birch. 10/07/15 08:02:07 Modified files: cm3/www/: Tag: release_branch_cm3_5_8 news.html cm3/www/releng/: Tag: release_branch_cm3_5_8 update-releng-index.sh Log message: more release additions From jkrell at elego.de Thu Jul 15 10:52:38 2010 From: jkrell at elego.de (Jay Krell) Date: Thu, 15 Jul 2010 10:52:38 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100715085238.F0D6C2474006@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/15 10:52:38 Modified files: cm3/m3-sys/cminstall/src/config-no-install/: ALPHA_OSF Log message: add -std to cc From jkrell at elego.de Thu Jul 15 11:20:40 2010 From: jkrell at elego.de (Jay Krell) Date: Thu, 15 Jul 2010 11:20:40 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100715092040.A98552474006@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/15 11:20:40 Modified files: cm3/m3-libs/m3core/src/: m3core.h Log message: whitespace change for old compiler: bash-3.2$ cc -g -c -o CerrnoC.o CerrnoC.c cc: Warning: m3core.h, line 31: # not in column 1 is ignored, skipping to end of line. (ignoretokens) #define M3_DLL_IMPORT --^ From jkrell at elego.de Thu Jul 15 13:03:51 2010 From: jkrell at elego.de (Jay Krell) Date: Thu, 15 Jul 2010 13:03:51 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100715110351.4FFB92474006@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/15 13:03:51 Modified files: cm3/m3-sys/cminstall/src/config-no-install/: cm3cfg.common Log message: add IsHostOSF1v4 to be used shortly, uname -sr based OSF1 v4 has something funny with #define _POSIX_SOURCE and such, I can get it to compile, but I don't know if it breaks v5. OSF1 doesn't have 64bit time_t available native + IsHostOSF1v4 will => #define M3_OSF1_V4 and m3core.h will check that refine uname-based IsHostFreeBSD4 just one uname and one fgrep add InternalTargetCanRunOnHost that's been bugging me lots can run lots, though missing here is if potentially biarch systems are actually biarch From jkrell at elego.de Thu Jul 15 13:06:38 2010 From: jkrell at elego.de (Jay Krell) Date: Thu, 15 Jul 2010 13:06:38 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100715110638.E30DC2474006@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/15 13:06:38 Modified files: cm3/m3-sys/cminstall/src/config-no-install/: cm3cfg.common Log message: I forgot to add IsTargetOSF1v4 function (which is only approx, i.e. works for native builds only) From jkrell at elego.de Thu Jul 15 13:07:09 2010 From: jkrell at elego.de (Jay Krell) Date: Thu, 15 Jul 2010 13:07:09 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100715110709.4F9612474006@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/15 13:07:09 Modified files: cm3/m3-sys/cminstall/src/config-no-install/: cm3cfg.common Log message: comments explaining why knowing precise target doesn't work From jkrell at elego.de Thu Jul 15 13:08:15 2010 From: jkrell at elego.de (Jay Krell) Date: Thu, 15 Jul 2010 13:08:15 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100715110815.D944B2474006@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/15 13:08:15 Modified files: cm3/m3-sys/cminstall/src/config-no-install/: cm3cfg.common Log message: fix copy/pasto (but still worked ok for all normal systems) From jkrell at elego.de Thu Jul 15 13:12:32 2010 From: jkrell at elego.de (Jay Krell) Date: Thu, 15 Jul 2010 13:12:32 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100715111232.6D1E62474006@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/15 13:12:32 Modified files: cm3/m3-sys/cminstall/src/config-no-install/: ALPHA_OSF Log message: add -DM3_OSF1_V4 to SYSTEM_CC if it seems we are targeting OSF/1 v4 (yeah yeah, what about versions 1-3?; get me access to such a machine and I'll deal with it) From jkrell at elego.de Thu Jul 15 13:14:48 2010 From: jkrell at elego.de (Jay Krell) Date: Thu, 15 Jul 2010 13:14:48 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100715111448.EB9BC2474006@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/15 13:14:48 Modified files: cm3/m3-libs/m3core/src/: m3core.h Log message: don't define _XOPEN_SOURCE or _TIME64_T if M3_OSF1_V4 is defined; _XOPEN_SOURCE breaks pthread.h, even though the comments in pthread.h say it shouldn't; I don't remember why I added _XOPEN_SOURCE in the first place, would have to investigate on v5; _TIME64_T is not available on v4; on the hypothetical world where OSF/1 v4 and v5 mattered, we'd want to do builds on each, rename the archives, but not likely invent two different targets, since they match plenty close enough as far as I know (I should double check jmpbuf) From jkrell at elego.de Thu Jul 15 13:26:42 2010 From: jkrell at elego.de (Jay Krell) Date: Thu, 15 Jul 2010 13:26:42 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100715112642.241F32474006@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/15 13:26:42 Modified files: cm3/m3-libs/m3core/src/thread/PTHREAD/: ThreadPThreadC.c Log message: cc: Warning: ThreadPThreadC.c, line 170: In this statement, & before array "jb" is ignored. (addrarray) p(&jb, ((char *)&jb) + sizeof(jb)); ------^ cc: Warning: ThreadPThreadC.c, line 170: In this statement, & before array "jb" is ignored. (addrarray) p(&jb, ((char *)&jb) + sizeof(jb)); --------------------^ jb may or may not be an array, & is necessary, wrap it in struct. From jkrell at elego.de Thu Jul 15 13:29:49 2010 From: jkrell at elego.de (Jay Krell) Date: Thu, 15 Jul 2010 13:29:49 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100715112949.AC3E62474006@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/15 13:29:49 Modified files: cm3/m3-libs/libm3/src/os/POSIX/: FSPosixC.c Log message: cc: Warning: FSPosixC.c, line 35: In this statement, & before array "t" is ignored. (addrarray) ZeroMemory(&t, sizeof(t)); ----^ says the OSF1v4 compiler; in this case the array-ness is plain to see so we can safely portably remove the ampersand, and it makes no difference. Thank you compiler.. From jkrell at elego.de Thu Jul 15 13:35:51 2010 From: jkrell at elego.de (Jay Krell) Date: Thu, 15 Jul 2010 13:35:51 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100715113551.662702474006@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/15 13:35:51 Modified files: cm3/m3-sys/cminstall/src/config-no-install/: ALPHA_OSF Log message: didn't actually need -std here, the problem was #define _XOPEN_SOURCE From jkrell at elego.de Thu Jul 15 13:44:21 2010 From: jkrell at elego.de (Jay Krell) Date: Thu, 15 Jul 2010 13:44:21 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100715114421.AE7962474006@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/15 13:44:21 Modified files: cm3/m3-libs/m3core/src/: m3core.h Log message: define _POSIX_PII_SOCKET on OSF1v4 to get soclen_t typedef (that's probablly why I added #define _XOPEN_SOURCE 500; add some other comments From jkrell at elego.de Thu Jul 15 13:50:13 2010 From: jkrell at elego.de (Jay Krell) Date: Thu, 15 Jul 2010 13:50:13 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100715115013.3E5D92474006@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/15 13:50:13 Modified files: cm3/scripts/python/: pylib.py Log message: -lrt -lm -pthread for ALPHA_OSF, similar to the config file (the config file does more) From jkrell at elego.de Thu Jul 15 13:52:53 2010 From: jkrell at elego.de (Jay Krell) Date: Thu, 15 Jul 2010 13:52:53 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100715115253.33EE9CC110@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/15 13:52:53 Modified files: cm3/scripts/python/: pylib.py Log message: comment about OSF1v4, actually maybe it is worth having I386_FREEBSD4, I386_FREEBSD5 (6?), ALPHA_OSF4, ALPHA_OSF5, that does kind of mimic GNU configuration and would make some stuff work better, including for example, cross building boot packages From jkrell at elego.de Thu Jul 15 15:26:42 2010 From: jkrell at elego.de (Jay Krell) Date: Thu, 15 Jul 2010 15:26:42 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100715132642.F13EBCC37E@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/15 15:26:42 Modified files: cm3/scripts/: sysinfo.sh Added files: cm3/scripts/: boot2.sh Log message: OSF/1 support, and Python failed to build here so far (minor sounding problem) so port to sh From jkrell at elego.de Thu Jul 15 15:28:14 2010 From: jkrell at elego.de (Jay Krell) Date: Thu, 15 Jul 2010 15:28:14 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100715132814.EEAD32474006@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/15 15:28:14 Modified files: cm3/scripts/: sysinfo.sh Log message: I doubt the stars are needed at the ends of plain parameterless uname output (checked at least FreeBSD 4.11) From jkrell at elego.de Thu Jul 15 15:58:47 2010 From: jkrell at elego.de (Jay Krell) Date: Thu, 15 Jul 2010 15:58:47 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100715135847.A1491CC37E@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/15 15:58:47 Modified files: cm3/m3-sys/cminstall/src/config-no-install/: Solaris.common Log message: use fgrep instead of grep From jkrell at elego.de Thu Jul 15 16:45:43 2010 From: jkrell at elego.de (Jay Krell) Date: Thu, 15 Jul 2010 16:45:43 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100715144543.B25742474006@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/15 16:45:43 Modified files: cm3/m3-sys/cminstall/src/config-no-install/: FreeBSD.common I386_FREEBSD Log message: more conservative linking options on FreeBSD4: no -z now no -B symbolic and then no -pthread or -lc: shared libraries I guess aren't supposed to choose libc or libc_r but maybe leave it to the executable? And we don't need libc_r because we are using user threads? This fixes the crash I was seeing. FreeBSD >4 should be unaffected. From jkrell at elego.de Fri Jul 16 14:01:27 2010 From: jkrell at elego.de (Jay Krell) Date: Fri, 16 Jul 2010 14:01:27 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100716120128.1FC822474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/16 14:01:27 Modified files: cm3/scripts/: boot2.sh Log message: move action to start, as the sh scripts require? From jkrell at elego.de Fri Jul 16 14:11:16 2010 From: jkrell at elego.de (Jay Krell) Date: Fri, 16 Jul 2010 14:11:16 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100716121116.B35312474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/16 14:11:16 Added files: cm3/scripts/: install-config.sh Log message: more sh for Tru64 4.0 work, while I wait for Python to compile Note this is different than install-config.py. It is based on make-bin-dist.sh. It makes config for ship, not development. ie. actual copies of the files, not the stub that tries to get back to the source tree. From jkrell at elego.de Fri Jul 16 14:18:36 2010 From: jkrell at elego.de (Jay Krell) Date: Fri, 16 Jul 2010 14:18:36 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100716121836.662752474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/16 14:18:36 Modified files: cm3/m3-sys/cminstall/src/config-no-install/: ALPHA_OSF Log message: delay setting SYSTEM_CC until configure_c_compiler(), so that we can call IsTargetOSF1v4; another solution would be to move the two lines to the end of the file From jkrell at elego.de Fri Jul 16 14:30:00 2010 From: jkrell at elego.de (Jay Krell) Date: Fri, 16 Jul 2010 14:30:00 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100716123000.E22572474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/16 14:30:00 Modified files: cm3/m3-sys/m3cc/src/: platforms.quake Log message: let's trye alpha-dec-osf instead of alpha-dec-osf5.1, see how that goes From jkrell at elego.de Fri Jul 16 15:01:44 2010 From: jkrell at elego.de (Jay Krell) Date: Fri, 16 Jul 2010 15:01:44 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100716130144.5A413CC37E@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/16 15:01:44 Modified files: cm3/scripts/: make-dist.sh Log message: comment only, about runpath From jkrell at elego.de Fri Jul 16 15:02:39 2010 From: jkrell at elego.de (Jay Krell) Date: Fri, 16 Jul 2010 15:02:39 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100716130239.68DDD2474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/16 15:02:39 Modified files: cm3/scripts/python/: make-dist.py Log message: keep out hardcoded runpaths, like make-dist.sh, this is setting and environment variable that config/gnuld.common checks From jkrell at elego.de Fri Jul 16 15:04:12 2010 From: jkrell at elego.de (Jay Krell) Date: Fri, 16 Jul 2010 15:04:12 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100716130413.04699CC37F@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/16 15:04:12 Modified files: cm3/scripts/python/: pylib.py make-dist.py Log message: more support for Visual C++ 10.0 From jkrell at elego.de Fri Jul 16 15:17:18 2010 From: jkrell at elego.de (Jay Krell) Date: Fri, 16 Jul 2010 15:17:18 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100716131718.49F572474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/16 15:17:18 Modified files: cm3/scripts/python/: pylib.py Log message: somewhat experimental: insert `uname -sr` in archive names, with some transforms to make it shorter: Linux 2.6.1231313 => Linux2.6 FreeBSD 1.23-release => FreeBSD1.23 -.+$ => empty actually spaces removed only investigated recently uname -sr on OSF, Darwin, FreeBSD, OpenBSD Darwin should probably be translated to MacOSX version From jkrell at elego.de Fri Jul 16 15:18:12 2010 From: jkrell at elego.de (Jay Krell) Date: Fri, 16 Jul 2010 15:18:12 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100716131812.E4F1E2474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/16 15:18:12 Modified files: cm3/scripts/python/: pylib.py Log message: 'SunOS' => 'Solaris' in archive names, though SunOS is shorter From jkrell at elego.de Fri Jul 16 15:20:11 2010 From: jkrell at elego.de (Jay Krell) Date: Fri, 16 Jul 2010 15:20:11 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100716132011.155EBCC37E@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/16 15:20:11 Modified files: cm3/scripts/python/: pylib.py Log message: Linux2.4.xxx => Linux2.4 Linux2.6.xxx => empty Linux 2.6 is I believe overwhelmingly in use 2.4 remains for small embedded systems like my router, and notably lacks NPTL (good pthreads) From jkrell at elego.de Fri Jul 16 15:22:28 2010 From: jkrell at elego.de (Jay Krell) Date: Fri, 16 Jul 2010 15:22:28 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100716132228.46EB62474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/16 15:22:28 Modified files: cm3/scripts/python/: make-dist.py Log message: environment variables must be strings From jkrell at elego.de Fri Jul 16 15:23:03 2010 From: jkrell at elego.de (Jay Krell) Date: Fri, 16 Jul 2010 15:23:03 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100716132303.CD6F42474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/16 15:23:03 Modified files: cm3/scripts/python/: pylib.py Log message: fix regexp around archive name having uname -sr From jkrell at elego.de Fri Jul 16 15:24:25 2010 From: jkrell at elego.de (Jay Krell) Date: Fri, 16 Jul 2010 15:24:25 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100716132425.2473C2474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/16 15:24:25 Modified files: cm3/scripts/python/: pylib.py Log message: fix regexp around archive name having uname -sr From jkrell at elego.de Fri Jul 16 15:28:12 2010 From: jkrell at elego.de (Jay Krell) Date: Fri, 16 Jul 2010 15:28:12 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100716132812.1D3112474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/16 15:28:12 Modified files: cm3/scripts/python/: pylib.py Log message: remove newlines from uname output From jkrell at elego.de Fri Jul 16 16:03:51 2010 From: jkrell at elego.de (Jay Krell) Date: Fri, 16 Jul 2010 16:03:51 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100716140351.9FD322474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/16 16:03:51 Modified files: cm3/m3-sys/cminstall/src/config-no-install/: ALPHA_OSF Log message: oops: ALPHA_OSF doesn't share as much code (though neither do Solaris.common or Darwin.common): forgot to call configure_c_compiler From jkrell at elego.de Fri Jul 16 16:34:49 2010 From: jkrell at elego.de (Jay Krell) Date: Fri, 16 Jul 2010 16:34:49 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100716143449.A79592474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/16 16:34:49 Modified files: cm3/m3-sys/m3cc/src/: platforms.quake Log message: need to say osf4 From jkrell at elego.de Sat Jul 17 14:37:17 2010 From: jkrell at elego.de (Jay Krell) Date: Sat, 17 Jul 2010 14:37:17 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100717123717.BB6C42474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/17 14:37:17 Modified files: cm3/m3-sys/m3cc/src/: gnucc.common Log message: acceptable hack for OSF1v4: omit -g because then the files are so large such as to exhaust virtual memory/swap linking cm3cg From jkrell at elego.de Sat Jul 17 15:09:08 2010 From: jkrell at elego.de (Jay Krell) Date: Sat, 17 Jul 2010 15:09:08 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100717130908.E32AF2474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/17 15:09:08 Modified files: cm3/m3-sys/cminstall/src/config-no-install/: ALPHA_OSF Log message: on OSF1v4, use -Wl,-B,symbolic instead of -B symbolic; it should work, but oh well From jkrell at elego.de Sat Jul 17 15:35:42 2010 From: jkrell at elego.de (Jay Krell) Date: Sat, 17 Jul 2010 15:35:42 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100717133542.69AD92474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/17 15:35:42 Modified files: cm3/m3-sys/cminstall/src/config-no-install/: ALPHA_OSF Log message: Honor $M3_PORTABLE_RUN_PATH like gnuld.common: if it is set, don't use LIB_USE, since that is specific to the machine building the files. Instead, use nothing at all, consumer will need to set LD_LIBRARY_PATH. Note that ALPHA_OSF does support -rpath ${ENVVAR}, so a good solution would be to rename foo to foo.exe (or something) and drop in a constant shell script foo. The shell script foo "finds itself", like configure: if $0 is a full path, that is it, if it is relative, that is it relative to current working directory, else search $PATH then shell script should set $ORIGIN to its own directory or and we'd use $ORIGIN/../lib and shell script would exec foo.exe. Todo later. Maybe. Probably not. From jkrell at elego.de Sat Jul 17 17:49:51 2010 From: jkrell at elego.de (Jay Krell) Date: Sat, 17 Jul 2010 17:49:51 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100717154951.4C753CC37E@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/17 17:49:51 Modified files: cm3/m3-sys/cminstall/src/config-no-install/: ALPHA_OSF Log message: non_shared doesn't work with pthread (failure to link); call_shared is default, so not needed; cleanup From jkrell at elego.de Sat Jul 17 17:50:11 2010 From: jkrell at elego.de (Jay Krell) Date: Sat, 17 Jul 2010 17:50:11 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100717155011.3892ECC37F@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/17 17:50:11 Modified files: cm3/m3-sys/cminstall/src/config-no-install/: ALPHA_OSF Log message: fix the 'cleanup' part From jkrell at elego.de Sat Jul 17 17:51:32 2010 From: jkrell at elego.de (Jay Krell) Date: Sat, 17 Jul 2010 17:51:32 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100717155132.83CFC2474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/17 17:51:32 Modified files: cm3/m3-sys/cminstall/src/config-no-install/: ALPHA_OSF Log message: fix/invert M3_PORTABLE_RUN_PATH From jkrell at elego.de Sun Jul 18 06:34:59 2010 From: jkrell at elego.de (Jay Krell) Date: Sun, 18 Jul 2010 6:34:59 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100718043459.D8CB42474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/18 06:34:59 Modified files: cm3/m3-tools/pp/src/: Parse.yacc cm3/m3-tools/pp/src/flex-bison/: lex.yy.c y.tab.c cm3/m3-tools/pp/src/lex-yacc/: lex.yy.c y.tab.c cm3/m3-tools/pp/src/lex-yacc-HPPA/: lex.yy.c y.tab.c Log message: cleanup: always #include stdlib.h stdio.h stddef.h unistd.h always use size_t don't redefine NULL This should fix a problem on OSF1v4 (incompatible declarations of malloc/free) and is fine on all systems for some years now. Strongly consider running lex/flex/yacc/bison and not checking in the output! From jay.krell at cornell.edu Sun Jul 18 06:41:46 2010 From: jay.krell at cornell.edu (Jay K) Date: Sun, 18 Jul 2010 04:41:46 +0000 Subject: [M3commit] CVS Update: cm3 In-Reply-To: <20100718043459.D8CB42474003@birch.elegosoft.com> References: <20100718043459.D8CB42474003@birch.elegosoft.com> Message-ID: diff attached Though I think better to delete these *.c files and run the tools to generate them. Agreed? I understand the idea that users that compile this directory might not have them, but they probably will. ?- Jay ---------------------------------------- > Date: Sun, 18 Jul 2010 06:34: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/07/18 06:34:59 > > Modified files: > cm3/m3-tools/pp/src/: Parse.yacc > cm3/m3-tools/pp/src/flex-bison/: lex.yy.c y.tab.c > cm3/m3-tools/pp/src/lex-yacc/: lex.yy.c y.tab.c > cm3/m3-tools/pp/src/lex-yacc-HPPA/: lex.yy.c y.tab.c > > Log message: > cleanup: > always #include stdlib.h stdio.h stddef.h unistd.h > always use size_t > don't redefine NULL > This should fix a problem on OSF1v4 (incompatible declarations > of malloc/free) and is fine on all systems for some years now. > Strongly consider running lex/flex/yacc/bison and not checking in the output! > -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: lex.txt URL: From jkrell at elego.de Sun Jul 18 06:44:19 2010 From: jkrell at elego.de (Jay Krell) Date: Sun, 18 Jul 2010 6:44:19 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100718044419.26A152474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/18 06:44:19 Modified files: cm3/m3-tools/pp/src/flex-bison/: lex.yy.c cm3/m3-tools/pp/src/lex-yacc/: lex.yy.c cm3/m3-tools/pp/src/lex-yacc-HPPA/: lex.yy.c Log message: remove $Header and $Revision From jkrell at elego.de Sun Jul 18 06:56:41 2010 From: jkrell at elego.de (Jay Krell) Date: Sun, 18 Jul 2010 6:56:41 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100718045642.0555B2474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/18 06:56:41 Modified files: cm3/m3-tools/pp/src/: m3makefile Log message: on systems that have both lex/yacc and flex/bison, favor flex/bison instead of lex/yacc, instead of the opposite From jkrell at elego.de Sun Jul 18 06:58:24 2010 From: jkrell at elego.de (Jay Krell) Date: Sun, 18 Jul 2010 6:58:24 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100718045824.9123A2474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/18 06:58:24 Modified files: cm3/m3-tools/pp/src/lex-yacc/: Makefile Log message: actually use yacc, not merely bison -y From jkrell at elego.de Sun Jul 18 07:04:40 2010 From: jkrell at elego.de (Jay Krell) Date: Sun, 18 Jul 2010 7:04:40 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100718050440.72F282474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/18 07:04:40 Modified files: cm3/m3-tools/pp/src/: m3makefile Log message: fix From jkrell at elego.de Sun Jul 18 07:44:00 2010 From: jkrell at elego.de (Jay Krell) Date: Sun, 18 Jul 2010 7:44:00 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100718054401.4DFF02474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/18 07:44:00 Modified files: cm3/scripts/python/: pylib.py make-dist.py Log message: mips-tfile for make-dist ALPHA_OSF support, and consolidate mklib support, not all tested as file copy to Alpha/OSF difficult From jkrell at elego.de Sun Jul 18 10:11:16 2010 From: jkrell at elego.de (Jay Krell) Date: Sun, 18 Jul 2010 10:11:16 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100718081117.005AD2474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/18 10:11:16 Modified files: cm3/m3-sys/m3cc/gcc-4.5/gcc/: gimple.h Log message: add asserts that helped me track down problem (later assertion failure) with sets being void* instead of size_t* I suspect these are correct but if they are wrong, ok, remove them. From jkrell at elego.de Sun Jul 18 10:20:20 2010 From: jkrell at elego.de (Jay Krell) Date: Sun, 18 Jul 2010 10:20:20 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100718082020.E9A0ACC37E@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/18 10:20:20 Modified files: cm3/m3-sys/m3cc/gcc/gcc/: config.host config.gcc cm3/m3-sys/m3cc/gcc/gcc/config/: openbsd.h t-openbsd cm3/m3-sys/m3cc/gcc/gcc/config/i386/: openbsd.h openbsdelf.h cm3/m3-sys/m3cc/gcc/gcc/config/m68k/: openbsd.h cm3/m3-sys/m3cc/gcc/gcc/config/mips/: openbsd.h cm3/m3-sys/m3cc/gcc/gcc/config/vax/: openbsd.h cm3/m3-sys/m3cc/src/: m3makefile Log message: Commit the OpenBSD patches instead of applying them in the build. Note that I doubt change to gcc/gcc/config/openbsd.h is needed, it looks specific to using the C front ends (cc1, etc.) or the "driver" (gcc). From jkrell at elego.de Sun Jul 18 10:40:52 2010 From: jkrell at elego.de (Jay Krell) Date: Sun, 18 Jul 2010 10:40:52 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100718084052.5C3012474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/18 10:40:52 Added files: cm3/m3-sys/m3cc/gcc/gcc/config/: exec-stack.h host-openbsd.c openbsd-libpthread.h x-openbsd cm3/m3-sys/m3cc/gcc/gcc/config/i386/: openbsd64.h cm3/m3-sys/m3cc/gcc/gcc/config/rs6000/: openbsd.h Log message: oops: also add the new files needed for OpenBSD, that we were previously copying from the patches directory From jkrell at elego.de Sun Jul 18 11:47:42 2010 From: jkrell at elego.de (Jay Krell) Date: Sun, 18 Jul 2010 11:47:42 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100718094742.9BDF9CC37E@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/18 11:47:42 Modified files: cm3/m3-sys/m3cc/gcc/gcc/: tree-chrec.h Log message: initialize with generic { 0 } instead of 0 (this is a line that we changed anyway From jkrell at elego.de Sun Jul 18 11:49:48 2010 From: jkrell at elego.de (Jay Krell) Date: Sun, 18 Jul 2010 11:49:48 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100718094948.4AD92CC37E@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/18 11:49:48 Modified files: cm3/m3-sys/m3cc/gcc/gcc/: tree.c Log message: change copyright comment back to match 4.3.0 and 4.3.5 From jkrell at elego.de Sun Jul 18 11:56:25 2010 From: jkrell at elego.de (Jay Krell) Date: Sun, 18 Jul 2010 11:56:25 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100718095625.5ADB22474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/18 11:56:25 Modified files: cm3/m3-sys/m3cc/gcc/gcc/: dbxout.c Log message: remove code that was #if 0'ed out September 2008 From jkrell at elego.de Sun Jul 18 13:13:45 2010 From: jkrell at elego.de (Jay Krell) Date: Sun, 18 Jul 2010 13:13:45 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100718111345.7E9632474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/18 13:13:45 Modified files: cm3/m3-sys/m3cc/gcc/: ChangeLog LAST_UPDATED MD5SUMS Makefile.def Makefile.in Makefile.tpl NEWS config-ml.in configure configure.ac cm3/m3-sys/m3cc/gcc/INSTALL/: binaries.html build.html configure.html download.html finalinstall.html gfdl.html index.html old.html prerequisites.html specific.html test.html cm3/m3-sys/m3cc/gcc/config/: ChangeLog cm3/m3-sys/m3cc/gcc/contrib/: ChangeLog texi2pod.pl cm3/m3-sys/m3cc/gcc/contrib/reghunt/: ChangeLog cm3/m3-sys/m3cc/gcc/contrib/regression/: ChangeLog cm3/m3-sys/m3cc/gcc/fixincludes/: ChangeLog fixincl.x inclhack.def cm3/m3-sys/m3cc/gcc/fixincludes/tests/base/iso/: math_c99.h cm3/m3-sys/m3cc/gcc/gcc/: BASE-VER ChangeLog ChangeLog-2007 DATESTAMP Makefile.in aclocal.m4 alias.c alias.h attribs.c builtin-types.def builtins.c builtins.def c-common.c c-cppbuiltin.c c-decl.c c-format.c c-lex.c c-parser.c c-pch.c c-pretty-print.c c-typeck.c calls.c cfgrtl.c cgraph.c cgraph.h cgraphunit.c collect2.c combine-stack-adj.c combine.c config.gcc configure configure.ac convert.c cse.c dbxout.c df-scan.c dfp.c dojump.c dse.c dwarf2.h dwarf2out.c emit-rtl.c emutls.c except.c exec-tool.in explow.c expmed.c expr.c final.c flags.h fold-const.c function.c fwprop.c gcov-io.h gcse.c gengtype-lex.c gengtype.c gimplify.c global.c gthr-posix.h gthr-posix95.h haifa-sched.c ifcvt.c ipa-inline.c ipa-utils.h jump.c langhooks-def.h langhooks.c langhooks.h libgcc2.c longlong.h loop-invariant.c mips-tfile.c omp-low.c optc-gen.awk opts.c params.def passes.c predict.c pretty-print.c real.c real.h recog.c recog.h regmove.c regrename.c reload.c resource.c rtl.h rtlanal.c sched-deps.c sched-int.h sched-rgn.c simplify-rtx.c stmt.c stor-layout.c target-def.h target.h targhooks.c targhooks.h toplev.c tree-cfg.c tree-chrec.c tree-chrec.h tree-complex.c tree-dfa.c tree-flow-inline.h tree-flow.h tree-inline.c tree-loop-linear.c tree-nested.c tree-nrv.c tree-outof-ssa.c tree-parloops.c tree-predcom.c tree-scalar-evolution.c tree-scalar-evolution.h tree-sra.c tree-ssa-address.c tree-ssa-alias-warnings.c tree-ssa-alias.c tree-ssa-ccp.c tree-ssa-dse.c tree-ssa-forwprop.c tree-ssa-loop-im.c tree-ssa-loop-ivopts.c tree-ssa-loop-niter.c tree-ssa-loop-prefetch.c tree-ssa-operands.c tree-ssa-phiopt.c tree-ssa-pre.c tree-ssa-sccvn.c tree-ssa-structalias.c tree-ssa.c tree-tailcall.c tree-vect-analyze.c tree-vect-generic.c tree-vect-transform.c tree-vn.c tree-vrp.c tree.c tree.h unwind-dw2.c unwind-generic.h unwind-pe.h varasm.c vec.h cm3/m3-sys/m3cc/gcc/gcc/config/: dfp-bit.c freebsd.h cm3/m3-sys/m3cc/gcc/gcc/config/alpha/: alpha.c alpha.md elf.h predicates.md sync.md cm3/m3-sys/m3cc/gcc/gcc/config/arm/: arm.c arm.md iwmmxt.md cm3/m3-sys/m3cc/gcc/gcc/config/avr/: avr-protos.h avr.c avr.h avr.md cm3/m3-sys/m3cc/gcc/gcc/config/cris/: cris.c cris.h cris.md cm3/m3-sys/m3cc/gcc/gcc/config/i386/: ammintrin.h bmmintrin.h driver-i386.c emmintrin.h i386.c i386.h i386.md i386.opt linux.h mm3dnow.h mmintrin-common.h mmintrin.h mmx.md pmmintrin.h predicates.md smmintrin.h sse.md sync.md tmmintrin.h winnt-cxx.c winnt.c x86-64.h xmmintrin.h cm3/m3-sys/m3cc/gcc/gcc/config/ia64/: div.md ia64.c ia64.md cm3/m3-sys/m3cc/gcc/gcc/config/m68k/: t-rtems cm3/m3-sys/m3cc/gcc/gcc/config/mips/: constraints.md iris6.h irix-crti.asm mips.c mips.md mips.opt sde.h cm3/m3-sys/m3cc/gcc/gcc/config/mn10300/: mn10300.c cm3/m3-sys/m3cc/gcc/gcc/config/pa/: fptr.c hpux-unwind.h linux-unwind.h milli64.S pa-hpux11.h pa.c pa.md pa64-hpux.h t-hpux-shlib cm3/m3-sys/m3cc/gcc/gcc/config/pdp11/: pdp11.c cm3/m3-sys/m3cc/gcc/gcc/config/rs6000/: altivec.md driver-rs6000.c predicates.md rs6000-c.c rs6000-protos.h rs6000.c rs6000.md cm3/m3-sys/m3cc/gcc/gcc/config/s390/: s390.c s390.h tpf.h cm3/m3-sys/m3cc/gcc/gcc/config/sh/: predicates.md sh.c sh.h sh.md t-sh cm3/m3-sys/m3cc/gcc/gcc/config/soft-fp/: double.h fixdfti.c floatuntisf.c cm3/m3-sys/m3cc/gcc/gcc/config/sparc/: linux.h linux64.h predicates.md sparc-protos.h sparc.c sparc.h sparc.md sysv4.h cm3/m3-sys/m3cc/gcc/gcc/config/spu/: spu-c.c spu-elf.h spu-protos.h spu.c spu.h spu.md spu.opt spu_mfcio.h t-spu-elf cm3/m3-sys/m3cc/gcc/gcc/config/stormy16/: stormy16.c cm3/m3-sys/m3cc/gcc/gcc/config/xtensa/: t-linux xtensa.md cm3/m3-sys/m3cc/gcc/gcc/doc/: cpp.1 cpp.info cppinternals.info extend.texi fsf-funding.7 g++.1 gc-analyze.1 gcc.1 gcc.info gcc.texi gccinstall.info gccint.info gccint.texi gcj-dbtool.1 gcj.1 gcj.info gcov.1 gfdl.7 gfortran.1 gij.1 gpl.7 grmic.1 gty.texi implement-c.texi install.texi install.texi2html invoke.texi jcf-dump.1 jv-convert.1 md.texi passes.texi rtl.texi sourcebuild.texi cm3/m3-sys/m3cc/gcc/gcc/doc/include/: gpl_v3.texi texinfo.tex cm3/m3-sys/m3cc/gcc/gcc/treelang/: ChangeLog cm3/m3-sys/m3cc/gcc/include/: ChangeLog cm3/m3-sys/m3cc/gcc/libcpp/: ChangeLog files.c cm3/m3-sys/m3cc/gcc/libdecnumber/: ChangeLog Makefile.in decBasic.c decCommon.c decContext.c decDouble.h decExcept.c decExcept.h decLibrary.c decNumber.c decNumberLocal.h decQuad.h decRound.c decSingle.h cm3/m3-sys/m3cc/gcc/libdecnumber/bid/: host-ieee128.c cm3/m3-sys/m3cc/gcc/libdecnumber/dpd/: decimal128.c decimal128Local.h decimal32.c decimal64.c cm3/m3-sys/m3cc/gcc/libgcc/: ChangeLog Makefile.in config.host configure configure.ac cm3/m3-sys/m3cc/gcc/libgcc/config/libbid/: ChangeLog cm3/m3-sys/m3cc/gcc/libiberty/: ChangeLog configure configure.ac cm3/m3-sys/m3cc/gcc/maintainer-scripts/: ChangeLog gcc_release Log message: merge with gcc 4.3.5 From jkrell at elego.de Sun Jul 18 13:20:04 2010 From: jkrell at elego.de (Jay Krell) Date: Sun, 18 Jul 2010 13:20:04 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100718112004.C0EAF2474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/18 13:20:04 Added files: cm3/m3-sys/m3cc/gcc/contrib/: dg-extract-results.sh cm3/m3-sys/m3cc/gcc/gcc/config/sparc/: gas.h cm3/m3-sys/m3cc/gcc/gcc/config/spu/: divmodti4.c float_disf.c float_unsdisf.c multi3.c cm3/m3-sys/m3cc/gcc/gcc/config/xtensa/: libgcc-xtensa.ver cm3/m3-sys/m3cc/gcc/libdecnumber/: dconfig.h cm3/m3-sys/m3cc/gcc/libgcc/: gstdint.h cm3/m3-sys/m3cc/gcc/libgcc/config/i386/: t-sol2 Log message: merge with gcc 4.3.5 From jkrell at elego.de Sun Jul 18 14:11:25 2010 From: jkrell at elego.de (Jay Krell) Date: Sun, 18 Jul 2010 14:11:25 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100718121125.A19C72474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/18 14:11:25 Modified files: cm3/m3-libs/m3core/src/Csupport/Common/: hand.c Log message: add back set_singleton, set_member, set_ne, set_eq for my convenience attempting bootstrap with old compiler and new mecore From jkrell at elego.de Sun Jul 18 14:37:32 2010 From: jkrell at elego.de (Jay Krell) Date: Sun, 18 Jul 2010 14:37:32 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100718123732.99A582474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/18 14:37:32 Modified files: cm3/m3-libs/m3core/src/Csupport/Common/: hand.c Added files: cm3/m3-libs/m3core/src/Csupport/Common/: old_divmod.c Log message: move old code out, add comments to it about its "problems" From jkrell at elego.de Sun Jul 18 16:05:50 2010 From: jkrell at elego.de (Jay Krell) Date: Sun, 18 Jul 2010 16:05:50 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100718140550.A12532474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/18 16:05:50 Added files: cm3/www/releng/: relnotes-5.9.html Log message: new file for the next release, first copy the old file From jkrell at elego.de Sun Jul 18 16:12:53 2010 From: jkrell at elego.de (Jay Krell) Date: Sun, 18 Jul 2010 16:12:53 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100718141255.7C4AD2474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/18 16:12:53 Modified files: cm3/www/releng/: relnotes-5.9.html Log message: update it with some stuff post 5.8 From jkrell at elego.de Sun Jul 18 16:14:20 2010 From: jkrell at elego.de (Jay Krell) Date: Sun, 18 Jul 2010 16:14:20 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100718141420.D97032474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/18 16:14:20 Modified files: cm3/www/releng/: relnotes-5.9.html Log message: ALPHA_OSF target restored (4.0g, 5.1) From jkrell at elego.de Sun Jul 18 16:44:38 2010 From: jkrell at elego.de (Jay Krell) Date: Sun, 18 Jul 2010 16:44:38 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100718144438.7E3602474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/18 16:44:38 Modified files: cm3/m3-sys/cminstall/src/config-no-install/: Solaris.common Log message: remove -lpthread again; fix flex/bison to be -L/usr/sfw/bin/lib -lfl instead of empty, but comment it out in favor of I think the more 'standard' (not optional) lex/yacc From jkrell at elego.de Sun Jul 18 16:53:14 2010 From: jkrell at elego.de (Jay Krell) Date: Sun, 18 Jul 2010 16:53:14 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100718145315.166AE2474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/18 16:53:14 Modified files: cm3/www/releng/: relnotes-5.9.html Log message: relnotes-5.9.html From jkrell at elego.de Sun Jul 18 16:53:35 2010 From: jkrell at elego.de (Jay Krell) Date: Sun, 18 Jul 2010 16:53:35 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100718145335.DC5602474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/18 16:53:35 Modified files: cm3/www/releng/: relnotes-5.9.html Log message: flubbed checkin comment: new targets: SPARC64_SOLARIS, I386_SOLARIS, AMD64_SOLARIS (2.9?) From jkrell at elego.de Sun Jul 18 17:23:55 2010 From: jkrell at elego.de (Jay Krell) Date: Sun, 18 Jul 2010 17:23:55 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100718152355.EBF422474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/18 17:23:55 Modified files: cm3/www/releng/: relnotes-5.9.html Log message: note some more changes since release; of course, the release notes will need review, proofing for style and correctness, etc. and this is very very very far from urgent From jkrell at elego.de Sun Jul 18 17:52:41 2010 From: jkrell at elego.de (Jay Krell) Date: Sun, 18 Jul 2010 17:52:41 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100718155242.142A02474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/18 17:52:41 Modified files: cm3/m3-sys/m3cc/src/: gnucc.common Log message: compat with previous release config files, could maybe just delete this OSF1v4 hack also now that Mark has added swap From jkrell at elego.de Sun Jul 18 18:00:56 2010 From: jkrell at elego.de (Jay Krell) Date: Sun, 18 Jul 2010 18:00:56 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100718160056.A9AA72474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/18 18:00:56 Modified files: cm3/m3-libs/m3core/src/win32/: m3makefile Log message: copy code from cm3cfg.common for compatibility I would prefer if the config files were updated fairly early in the build and my burden was to maintain compatiblity through them, not in m3makefiles otherwise. From jkrell at elego.de Sun Jul 18 18:03:00 2010 From: jkrell at elego.de (Jay Krell) Date: Sun, 18 Jul 2010 18:03:00 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100718160300.239C22474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/18 18:03:00 Modified files: cm3/m3-sys/cminstall/src/config-no-install/: cm3cfg.common Log message: require TARGET_OS to be defined; either bootstrap from 5.8.6 release or update older config files; we'll see if this flies, hopefully, but I might not like it myself, we'll see From jkrell at elego.de Mon Jul 19 03:23:16 2010 From: jkrell at elego.de (Jay Krell) Date: Mon, 19 Jul 2010 3:23:16 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100719012318.ABC2E2474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/19 03:23:16 Modified files: cm3/m3-sys/m3cc/src/: m3makefile cm3/m3-sys/m3cc/gcc/gcc/config/: darwin.h Log message: m3makefile, basically undo: Revision 1.162 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. Revision 1.161 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. darwin.h, undo Revision 1.2 always support hidden aka private extern aka don't export every function This should fix PPC_DARWIN and maybe maybe others (SPARC32_LINUX). Possibly relatd, I've noticed SOLsun using sparc-sun-solaris2.10-gcc to build cm3cg, when I was hoping it'd use Sun cc. This will at least change it to plain gcc, but same thing. From jkrell at elego.de Mon Jul 19 04:48:20 2010 From: jkrell at elego.de (Jay Krell) Date: Mon, 19 Jul 2010 4:48:20 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100719024822.CE20E2474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/19 04:48:20 Added files: cm3/www/uploaded-archives/: readme.txt Log message: Some notes I just made as to what "all", "min", and "boot" are. They should be reviewed, tested, edited, worked into the web page at: http://modula3.elegosoft.com/cm3/uploaded-archives/ From jkrell at elego.de Mon Jul 19 04:49:12 2010 From: jkrell at elego.de (Jay Krell) Date: Mon, 19 Jul 2010 4:49:12 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100719024913.4FBC82474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/19 04:49:12 Modified files: cm3/www/uploaded-archives/: readme.txt Log message: typo From jkrell at elego.de Mon Jul 19 04:50:00 2010 From: jkrell at elego.de (Jay Krell) Date: Mon, 19 Jul 2010 4:50:00 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100719025003.099082474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/19 04:50:00 Modified files: cm3/www/uploaded-archives/: readme.txt Log message: typos From jkrell at elego.de Mon Jul 19 04:55:54 2010 From: jkrell at elego.de (Jay Krell) Date: Mon, 19 Jul 2010 4:55:54 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100719025555.8ED6C2474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/19 04:55:54 Modified files: cm3/www/uploaded-archives/: readme.txt Log message: document problem with 'boot' that prevents its wider use e.g. in Hudson: it provides just cm3, but that cm3 is tied somewhat to a particular m3core and cm3cg, not as much as in the past, but still (e.g. if RTHooks.i3 or M3CG.i3 change); the dependency on m3core is easy to fix, by making a library from .o files produced here anyway, the dependency on cm3cg not so much From jkrell at elego.de Mon Jul 19 05:41:41 2010 From: jkrell at elego.de (Jay Krell) Date: Mon, 19 Jul 2010 5:41:41 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100719034141.C68F32474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/19 05:41:41 Modified files: cm3/m3-libs/m3core/src/: m3core.h Log message: should fix OpenBSD builds From jkrell at elego.de Mon Jul 19 05:46:00 2010 From: jkrell at elego.de (Jay Krell) Date: Mon, 19 Jul 2010 5:46:00 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100719034600.7A3C0CC37E@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/19 05:46:00 Modified files: cm3/scripts/python/: pylib.py Log message: put comment in Makefile for OSF1v4 users to act on From jkrell at elego.de Mon Jul 19 08:05:45 2010 From: jkrell at elego.de (Jay Krell) Date: Mon, 19 Jul 2010 8:05:45 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100719060546.261CE2474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/19 08:05:45 Modified files: cm3/m3-sys/m3cc/src/: m3makefile Added files: cm3/m3-sys/m3cc/src/: clean_marker.txt Log message: mechanism to let a checkin force subsequent builds to be clean: edit this clean_marker.txt file also cleanup the clean logic to just rm -rf build_dir/* From jkrell at elego.de Mon Jul 19 08:16:35 2010 From: jkrell at elego.de (Jay Krell) Date: Mon, 19 Jul 2010 8:16:35 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100719061636.0600B2474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/19 08:16:35 Modified files: cm3/m3-sys/m3cc/src/: clean_marker.txt m3makefile Log message: use the "new" quake builtins fs_lsfiles, fs_lsdirs, fs_rmrec and the old delete_file From jkrell at elego.de Mon Jul 19 08:19:19 2010 From: jkrell at elego.de (Jay Krell) Date: Mon, 19 Jul 2010 8:19:19 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100719061919.5D4882474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/19 08:19:19 Modified files: cm3/m3-sys/m3cc/src/: m3makefile Log message: remove use of if defined -- these are in the previous release now; we'll see how this goes -- requiring previous release From jkrell at elego.de Mon Jul 19 08:25:14 2010 From: jkrell at elego.de (Jay Krell) Date: Mon, 19 Jul 2010 8:25:14 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100719062515.0843F2474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/19 08:25:14 Modified files: cm3/m3-sys/m3cc/src/: m3makefile Log message: use TRUE and FALSE for boolean NOACTION instead of obscure "" and "T" From jkrell at elego.de Mon Jul 19 08:27:20 2010 From: jkrell at elego.de (Jay Krell) Date: Mon, 19 Jul 2010 8:27:20 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100719062720.98D112474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/19 08:27:20 Modified files: cm3/m3-sys/m3cc/gcc/gcc/: value-prof.c Log message: ../../gcc/gcc/value-prof.c: In function `tree_mod_subtract': ../../gcc/gcc/value-prof.c:831: warning: `bb3' might be used uninitialized in this function From jkrell at elego.de Mon Jul 19 09:05:15 2010 From: jkrell at elego.de (Jay Krell) Date: Mon, 19 Jul 2010 9:05:15 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100719070516.29BE42474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/19 09:05:15 Modified files: cm3/m3-sys/m3cc/gcc/gcc/: varasm.c Log message: ../../gcc/gcc/varasm.c: In function `const_rtx_hash_1': ../../gcc/gcc/varasm.c:3387: warning: right shift count >= width of type From jkrell at elego.de Tue Jul 20 12:49:45 2010 From: jkrell at elego.de (Jay Krell) Date: Tue, 20 Jul 2010 12:49:45 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100720104945.7428D2474005@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/20 12:49:45 Modified files: cm3/m3-db/odbc/src/: m3makefile Log message: check if configure_system_libs is defined before calling it From jkrell at elego.de Tue Jul 20 13:24:04 2010 From: jkrell at elego.de (Jay Krell) Date: Tue, 20 Jul 2010 13:24:04 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100720112404.81C642474005@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/20 13:24:04 Modified files: cm3/scripts/: sysinfo.sh Log message: This should fix the NT386/m3cc problem. Note however that I've churned sysinfo.sh a lot in head -- not with this commit, but earlier. From jkrell at elego.de Tue Jul 20 14:19:03 2010 From: jkrell at elego.de (Jay Krell) Date: Tue, 20 Jul 2010 14:19:03 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100720121903.5281D2474005@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/20 14:19:03 Modified files: cm3/m3-sys/cminstall/src/config-no-install/: OpenBSD.common cm3/m3-libs/m3core/src/runtime/common/: RTProcessC.c Log message: This should fix the hang on I386_OPENBSD. That only I'm seeing. (Hudson doesn't build enough, nobody else has reported it). It doesn't affect 5.8.6 release as that uses jmpbuf hacking for userthreads. The rewrite to use sigaltstack is new since then. RTProcessC.c: INTEGER __cdecl RTProcess__RegisterForkHandlers( ForkHandler prepare, ForkHandler parent, ForkHandler child) { >> big comment added /* FreeBSD < 6 lacks pthread_atfork. Would be good to use autoconf. * VMS lacks pthread_atfork? Would be good to use autoconf. * Win32 lacks pthread_atfork and fork. OK. * OpenBSD pthread_atfork causes us to need libpthread, and then * sigsuspend on 4.6/x86 hangs in the userthread code. * * I expect therefore cvsup is broken with user threads on these systems. * * OpenBSD we could fix by going back to jmpbuf hacking (see 5.8.6 release), * but it is nice to have portable code, and cvsup maybe is expendable (again, * only on OpenBSD). * * As well, for all Posix systems, we could implement * atfork ourselves, as long as we provide a fork() * wrapper that code uses. */ #if defined(_WIN32) \ || defined(__vms) \ || defined(__OpenBSD__) \ << this added || (defined(__FreeBSD__) && (__FreeBSD__ < 6)) return 0; #else >> add % LIBC: No pthreads, to avoid its sigsuspend that hangs. % See also RTProcess__RegisterForkHandlers. SYSTEM_LIBS{"LIBC"} = ["-lm"] From jkrell at elego.de Tue Jul 20 14:30:40 2010 From: jkrell at elego.de (Jay Krell) Date: Tue, 20 Jul 2010 14:30:40 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100720123040.B54572474005@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/20 14:30:40 Modified files: cm3/scripts/python/: upgrade.py Log message: I just introduced incompatibility between current openbsd config and older m3core -- the reference to pthread_atfork won't result, so, let's consider *not* updating config files so early -- this matches I believe what Hudson/Tinderbox do and *definitely* has good arguments in favor of it. From jkrell at elego.de Tue Jul 20 16:13:30 2010 From: jkrell at elego.de (Jay Krell) Date: Tue, 20 Jul 2010 16:13:30 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100720141330.E4B162474005@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/20 16:13:30 Modified files: cm3/m3-sys/cminstall/src/config-no-install/: OpenBSD.common Log message: add more X libraries so that solitaire builds (it is standalone) From jkrell at elego.de Wed Jul 21 12:27:11 2010 From: jkrell at elego.de (Jay Krell) Date: Wed, 21 Jul 2010 12:27:11 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100721102711.E2A8E2474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/21 12:27:11 Modified files: cm3/m3-sys/cminstall/src/config-no-install/: ALPHA_OSF Log message: set TARGET_OS=OSF (other names re reasonable) From jkrell at elego.de Wed Jul 21 12:28:29 2010 From: jkrell at elego.de (Jay Krell) Date: Wed, 21 Jul 2010 12:28:29 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100721102829.CE6742474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/21 12:28:29 Modified files: cm3/m3-sys/m3cc/src/: m3makefile Log message: building mips-tfile seems to fail on cross builds, like maybe the headers describing the object/symbol format aren't available? So only build it for native builds From jkrell at elego.de Wed Jul 21 12:48:29 2010 From: jkrell at elego.de (Jay Krell) Date: Wed, 21 Jul 2010 12:48:29 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100721104830.129C2CC389@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/21 12:48:29 Added files: cm3/m3-libs/m3core/src/unix/osf-1.ALPHA_OSF/: m3makefile Usignal.i3 Log message: bring back files, to try to get back setjmp-less exception handling From jkrell at elego.de Wed Jul 21 12:48:57 2010 From: jkrell at elego.de (Jay Krell) Date: Wed, 21 Jul 2010 12:48:57 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100721104857.4FE532474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/21 12:48:57 Modified files: cm3/m3-libs/m3core/src/unix/osf-1.ALPHA_OSF/: m3makefile Log message: edit it down From jkrell at elego.de Wed Jul 21 13:15:07 2010 From: jkrell at elego.de (Jay Krell) Date: Wed, 21 Jul 2010 13:15:07 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100721111507.2AE542474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/21 13:15:07 Modified files: cm3/scripts/python/: pylib.py Log message: fix typo on ALPHA_OSF From jkrell at elego.de Wed Jul 21 13:18:15 2010 From: jkrell at elego.de (Jay Krell) Date: Wed, 21 Jul 2010 13:18:15 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100721111815.8B16A2474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/21 13:18:15 Modified files: cm3/m3-libs/m3core/src/unix/: m3makefile cm3/m3-libs/m3core/src/unix/Common/: m3makefile cm3/m3-libs/m3core/src/unix/osf-1.ALPHA_OSF/: Usignal.i3 Log message: trim ALPHA_OSF/Usignal.i3 down to just an exact copy of Common/Usignal.i3 plus struct_sigcontext, enough, maybe more than enough, to compile the stack walking code (do we really need such an accurate Frame exposed to the Modula-3?) From jkrell at elego.de Wed Jul 21 14:33:38 2010 From: jkrell at elego.de (Jay Krell) Date: Wed, 21 Jul 2010 14:33:38 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100721123338.4B8992474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/21 14:33:38 Modified files: cm3/m3-libs/m3core/src/: m3core.h cm3/m3-libs/m3core/src/time/POSIX/: DatePosixC.c cm3/m3-libs/m3core/src/unix/: m3makefile Log message: Better perhaps for OSF/1. In particular, no longer need #ifdef M3_OSF1_V4. I #define _TIME64_T, and then I can tell if this system supports it by checking for defined(TIMEVAL64TO32) & TIMEVAL32TO64 From jkrell at elego.de Wed Jul 21 14:38:41 2010 From: jkrell at elego.de (Jay Krell) Date: Wed, 21 Jul 2010 14:38:41 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100721123841.903222474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/21 14:38:41 Modified files: cm3/m3-libs/m3core/src/unix/: m3makefile Log message: oops: fix ALPHA_OSF breakage From jkrell at elego.de Wed Jul 21 14:47:28 2010 From: jkrell at elego.de (Jay Krell) Date: Wed, 21 Jul 2010 14:47:28 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100721124728.3726F2474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/21 14:47:28 Modified files: cm3/m3-libs/m3core/src/unix/: m3makefile Log message: use TARGET_OS to shrink tables -- requires config file change from release 5.8.6 From jkrell at elego.de Wed Jul 21 14:48:38 2010 From: jkrell at elego.de (Jay Krell) Date: Wed, 21 Jul 2010 14:48:38 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100721124838.8BF0C2474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/21 14:48:38 Modified files: cm3/m3-libs/m3core/src/unix/: m3makefile Log message: whitespace From jkrell at elego.de Wed Jul 21 14:55:12 2010 From: jkrell at elego.de (Jay Krell) Date: Wed, 21 Jul 2010 14:55:12 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100721125512.609A92474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/21 14:55:12 Modified files: cm3/m3-libs/libm3/src/: m3makefile Removed files: cm3/m3-libs/libm3/src/: platforms.quake Log message: Eliminate extra platform lists now that 5.8.6 has shipped and its config files are the baseline. From jkrell at elego.de Wed Jul 21 17:26:52 2010 From: jkrell at elego.de (Jay Krell) Date: Wed, 21 Jul 2010 17:26:52 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100721152652.1C8712474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/21 17:26:52 Modified files: cm3/m3-sys/cminstall/src/config-no-install/: SPARC.common Log message: add -m32 to try to fix SPARC32_LINUX, add -funwind-tables in anticipation of libunwind, comment that -gstabs+ is only missing because we are chronically out of diskspace on the Hudson node (lame) From jkrell at elego.de Wed Jul 21 17:29:18 2010 From: jkrell at elego.de (Jay Krell) Date: Wed, 21 Jul 2010 17:29:18 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100721152918.8A6EB2474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/21 17:29:18 Modified files: cm3/m3-ui/PEX/src/: m3makefile Log message: only call configure_system_libs if it is defined (This is showing up in Hudson: e.g. http://hudson.modula3.com:8080/job/cm3-current-test-all-pkgs-SOLgnu From jkrell at elego.de Wed Jul 21 17:30:16 2010 From: jkrell at elego.de (Jay Krell) Date: Wed, 21 Jul 2010 17:30:16 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100721153016.48C6A2474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/21 17:30:16 Modified files: cm3/m3-ui/ui/src/xvbt/: m3makefile Log message: only call configure_system_libs if it is defined (This is showing up in Hudson: e.g. http://hudson.modula3.com:8080/job/cm3-current-test-all-pkgs-SOLgnu From jay.krell at cornell.edu Wed Jul 21 17:32:01 2010 From: jay.krell at cornell.edu (Jay K) Date: Wed, 21 Jul 2010 15:32:01 +0000 Subject: [M3commit] CVS Update: cm3 In-Reply-To: <20100721153016.48C6A2474003@birch.elegosoft.com> References: <20100721153016.48C6A2474003@birch.elegosoft.com> Message-ID: Hm, odd, this in cm3cfg.common if nowhere else. Something seems off. ?- Jay ---------------------------------------- > Date: Wed, 21 Jul 2010 17:30: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/07/21 17:30:16 > > Modified files: > cm3/m3-ui/ui/src/xvbt/: m3makefile > > Log message: > only call configure_system_libs if it is defined (This is showing up in Hudson: e.g. http://hudson.modula3.com:8080/job/cm3-current-test-all-pkgs-SOLgnu > From jkrell at elego.de Wed Jul 21 17:35:10 2010 From: jkrell at elego.de (Jay Krell) Date: Wed, 21 Jul 2010 17:35:10 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100721153510.982222474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/21 17:35:10 Modified files: cm3/m3-ui/PEX/src/: m3makefile Log message: undo: call configure_system_libs unconditionally, fix should be central, and code is already written correct-seeming From jkrell at elego.de Wed Jul 21 17:35:47 2010 From: jkrell at elego.de (Jay Krell) Date: Wed, 21 Jul 2010 17:35:47 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100721153547.670052474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/21 17:35:47 Modified files: cm3/m3-ui/ui/src/xvbt/: m3makefile Log message: undo: call configure_system_libs unconditionally, fix should be central, and code is already written correct-seeming From jkrell at elego.de Wed Jul 21 17:53:14 2010 From: jkrell at elego.de (Jay Krell) Date: Wed, 21 Jul 2010 17:53:14 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100721155314.E1BC6CC389@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/21 17:53:14 Modified files: cm3/scripts/: install-cm3-compiler.sh Log message: upgrade config files when upgrading compiler From jkrell at elego.de Wed Jul 21 17:54:15 2010 From: jkrell at elego.de (Jay Krell) Date: Wed, 21 Jul 2010 17:54:15 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100721155415.CAD312474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/21 17:54:15 Modified files: cm3/scripts/: install-cm3-compiler.sh Log message: mkdir more From jkrell at elego.de Wed Jul 21 17:58:10 2010 From: jkrell at elego.de (Jay Krell) Date: Wed, 21 Jul 2010 17:58:10 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100721155810.335512474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/21 17:58:10 Modified files: cm3/m3-sys/cminstall/src/config-no-install/: ALPHA_OSF cm3/scripts/python/: pylib.py Log message: remove -DM3_OSF1_V4 now that m3core.h figures it out From jay.krell at cornell.edu Wed Jul 21 18:30:56 2010 From: jay.krell at cornell.edu (Jay K) Date: Wed, 21 Jul 2010 16:30:56 +0000 Subject: [M3commit] CVS Update: cm3 In-Reply-To: <20100721155314.E1BC6CC389@birch.elegosoft.com> References: <20100721155314.E1BC6CC389@birch.elegosoft.com> Message-ID: I've manually updated the config files on SPARC32_LINUX Hudson node to try to fix this. ?- Jay ---------------------------------------- > Date: Wed, 21 Jul 2010 17:53: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/07/21 17:53:14 > > Modified files: > cm3/scripts/: install-cm3-compiler.sh > > Log message: > upgrade config files when upgrading compiler > From wagner at elego.de Wed Jul 21 22:39:32 2010 From: wagner at elego.de (Olaf Wagner) Date: Wed, 21 Jul 2010 22:39:32 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100721203932.B5C9D2474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: wagner at birch. 10/07/21 22:39:32 Modified files: cm3/scripts/: version version.quake Log message: fix version number on trunk for 5.9 development From wagner at elegosoft.com Thu Jul 22 08:53:23 2010 From: wagner at elegosoft.com (Olaf Wagner) Date: Thu, 22 Jul 2010 08:53:23 +0200 Subject: [M3commit] CVS Update: cm3 In-Reply-To: References: <20100721155314.E1BC6CC389@birch.elegosoft.com> Message-ID: <20100722085323.0nmmjnom94osso88@mail.elegosoft.com> Quoting Jay K : > I've manually updated the config files on SPARC32_LINUX Hudson node > to try to fix this. That should be done by the upgrade script (and it already was AFAIR). I wouldn't like the script shipping a newly built compiler to unconditionally overwrite all my local configuration. Olaf > > ?- Jay > > ---------------------------------------- >> Date: Wed, 21 Jul 2010 17:53: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/07/21 17:53:14 >> >> Modified files: >> cm3/scripts/: install-cm3-compiler.sh >> >> Log message: >> upgrade config files when upgrading compiler >> > -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From jay.krell at cornell.edu Thu Jul 22 09:08:45 2010 From: jay.krell at cornell.edu (Jay K) Date: Thu, 22 Jul 2010 07:08:45 +0000 Subject: [M3commit] CVS Update: cm3 In-Reply-To: <20100722085323.0nmmjnom94osso88@mail.elegosoft.com> References: <20100721155314.E1BC6CC389@birch.elegosoft.com>, , <20100722085323.0nmmjnom94osso88@mail.elegosoft.com> Message-ID: I thought it was too, before I looked at it. Could be that head and release are very divergent. I didn't look at release, oops. ? I probably will "soon". The config files are "partly part of the compiler", and partly system-specific. ?So they might have to be updated with the compiler. Perhaps we can have cm3.cfg.user or cm3.cfg.local, that we never edit, and maybe we should constrain it, like very line must have an equals sign, and if it has a percent, percent must follow equals. e.g. m3back_flags = "-custom" SYSTEM_CC = "custom" % comment blah blah SYSTEM_LIBS{"LIBC"} = "custom" SYSTEM_LIBORDER += [custom] But that might not be flexible enough. Another option is that cm3.cfg file do like: if exists("cm3.cfg.user.first") ? include("cm3.cfg.user.first") end ... if exists("cm3.cfg.user.last") ? include("cm3.cfg.user.last end which is infinitely flexible and not well defined. ?Even limiting to assignments is not well defined. ?You know, there's an interface somewhere in there, but it isn't well specified. My fault. ? I let things evolve and get discovered gradually, sometimes hard to know ahead of time what the result will be. ? I've made changes since 5.8.6 released such that config files from prior to 5.8.6 will not suffice. I can undo that, but there is an important policy and architecture question. ?- Jay ---------------------------------------- > Date: Thu, 22 Jul 2010 08:53:23 +0200 > From: wagner at elegosoft.com > To: m3commit at elegosoft.com > Subject: Re: [M3commit] CVS Update: cm3 > > Quoting Jay K : > > > I've manually updated the config files on SPARC32_LINUX Hudson node > > to try to fix this. > > That should be done by the upgrade script (and it already was AFAIR). > I wouldn't like the script shipping a newly built compiler to > unconditionally overwrite all my local configuration. > > Olaf > > > > > - Jay > > > > ---------------------------------------- > >> Date: Wed, 21 Jul 2010 17:53: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/07/21 17:53:14 > >> > >> Modified files: > >> cm3/scripts/: install-cm3-compiler.sh > >> > >> Log message: > >> upgrade config files when upgrading compiler > >> > > > > > > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 > From wagner at elegosoft.com Thu Jul 22 09:19:12 2010 From: wagner at elegosoft.com (Olaf Wagner) Date: Thu, 22 Jul 2010 09:19:12 +0200 Subject: [M3commit] CVS Update: cm3 In-Reply-To: References: <20100721155314.E1BC6CC389@birch.elegosoft.com>, , <20100722085323.0nmmjnom94osso88@mail.elegosoft.com> Message-ID: <20100722091912.bibr9p0z1q88wog4@mail.elegosoft.com> I can live with a cm3-local.cfg file which gets included when it exists, contains local overrides and is never touched by he installation. We have to be careful to backup existing configs and informing the users before the installation though. I think upgrade did backups of the config, too. Can you check the scripts in the release branch if anything needs to be merged back? I won't be able to do that today. Olaf Quoting Jay K : > I thought it was too, before I looked at it. > Could be that head and release are very divergent. > I didn't look at release, oops. > ? I probably will "soon". > > > The config files are "partly part of the compiler", and partly > system-specific. > ?So they might have to be updated with the compiler. > > > Perhaps we can have cm3.cfg.user or cm3.cfg.local, that we never edit, > and maybe we should constrain it, like very line > must have an equals sign, and if it has a percent, percent must > follow equals. > > > e.g. > m3back_flags = "-custom" > SYSTEM_CC = "custom" % comment blah blah > SYSTEM_LIBS{"LIBC"} = "custom" > SYSTEM_LIBORDER += [custom] > > But that might not be flexible enough. > > Another option is that cm3.cfg file do like: > if exists("cm3.cfg.user.first") > ? include("cm3.cfg.user.first") > end > ... > if exists("cm3.cfg.user.last") > > ? include("cm3.cfg.user.last > > end > > > > which is infinitely flexible and not well defined. > ?Even limiting to assignments is not well defined. > ?You know, there's an interface somewhere in there, but it isn't > well specified. My fault. > ? I let things evolve and get discovered gradually, sometimes hard > to know ahead of time what the result will be. > ? > > I've made changes since 5.8.6 released such that config files from > prior to 5.8.6 will not suffice. > I can undo that, but there is an important policy and architecture question. > > > ?- Jay > > ---------------------------------------- >> Date: Thu, 22 Jul 2010 08:53:23 +0200 >> From: wagner at elegosoft.com >> To: m3commit at elegosoft.com >> Subject: Re: [M3commit] CVS Update: cm3 >> >> Quoting Jay K : >> >> > I've manually updated the config files on SPARC32_LINUX Hudson node >> > to try to fix this. >> >> That should be done by the upgrade script (and it already was AFAIR). >> I wouldn't like the script shipping a newly built compiler to >> unconditionally overwrite all my local configuration. >> >> Olaf >> >> > >> > - Jay >> > >> > ---------------------------------------- >> >> Date: Wed, 21 Jul 2010 17:53: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/07/21 17:53:14 >> >> >> >> Modified files: >> >> cm3/scripts/: install-cm3-compiler.sh >> >> >> >> Log message: >> >> upgrade config files when upgrading compiler >> >> >> > >> >> >> >> -- >> Olaf Wagner -- elego Software Solutions GmbH >> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany >> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 >> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin >> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 >> > -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From jay.krell at cornell.edu Thu Jul 22 09:21:33 2010 From: jay.krell at cornell.edu (Jay K) Date: Thu, 22 Jul 2010 07:21:33 +0000 Subject: [M3commit] CVS Update: cm3 In-Reply-To: <20100722091912.bibr9p0z1q88wog4@mail.elegosoft.com> References: <20100721155314.E1BC6CC389@birch.elegosoft.com>, , , , <20100722085323.0nmmjnom94osso88@mail.elegosoft.com>, , <20100722091912.bibr9p0z1q88wog4@mail.elegosoft.com> Message-ID: (ps: the change I made does do the backup foo-date thing, parallel to cm3 and cm3cg yes I'll compare the branches, can't promise a full merge though) ---------------------------------------- > Date: Thu, 22 Jul 2010 09:19:12 +0200 > From: wagner at elegosoft.com > To: jay.krell at cornell.edu > CC: m3commit at elegosoft.com > Subject: Re: [M3commit] CVS Update: cm3 > > I can live with a cm3-local.cfg file which gets included when it exists, > contains local overrides and is never touched by he installation. > > We have to be careful to backup existing configs and informing the > users before the installation though. > > I think upgrade did backups of the config, too. > > Can you check the scripts in the release branch if anything needs > to be merged back? I won't be able to do that today. > > Olaf > > Quoting Jay K : > > > I thought it was too, before I looked at it. > > Could be that head and release are very divergent. > > I didn't look at release, oops. > > I probably will "soon". > > > > > > The config files are "partly part of the compiler", and partly > > system-specific. > > So they might have to be updated with the compiler. > > > > > > Perhaps we can have cm3.cfg.user or cm3.cfg.local, that we never edit, > > and maybe we should constrain it, like very line > > must have an equals sign, and if it has a percent, percent must > > follow equals. > > > > > > e.g. > > m3back_flags = "-custom" > > SYSTEM_CC = "custom" % comment blah blah > > SYSTEM_LIBS{"LIBC"} = "custom" > > SYSTEM_LIBORDER += [custom] > > > > But that might not be flexible enough. > > > > Another option is that cm3.cfg file do like: > > if exists("cm3.cfg.user.first") > > include("cm3.cfg.user.first") > > end > > ... > > if exists("cm3.cfg.user.last") > > > > include("cm3.cfg.user.last > > > > end > > > > > > > > which is infinitely flexible and not well defined. > > Even limiting to assignments is not well defined. > > You know, there's an interface somewhere in there, but it isn't > > well specified. My fault. > > I let things evolve and get discovered gradually, sometimes hard > > to know ahead of time what the result will be. > > > > > > I've made changes since 5.8.6 released such that config files from > > prior to 5.8.6 will not suffice. > > I can undo that, but there is an important policy and architecture question. > > > > > > - Jay > > > > ---------------------------------------- > >> Date: Thu, 22 Jul 2010 08:53:23 +0200 > >> From: wagner at elegosoft.com > >> To: m3commit at elegosoft.com > >> Subject: Re: [M3commit] CVS Update: cm3 > >> > >> Quoting Jay K : > >> > >> > I've manually updated the config files on SPARC32_LINUX Hudson node > >> > to try to fix this. > >> > >> That should be done by the upgrade script (and it already was AFAIR). > >> I wouldn't like the script shipping a newly built compiler to > >> unconditionally overwrite all my local configuration. > >> > >> Olaf > >> > >> > > >> > - Jay > >> > > >> > ---------------------------------------- > >> >> Date: Wed, 21 Jul 2010 17:53: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/07/21 17:53:14 > >> >> > >> >> Modified files: > >> >> cm3/scripts/: install-cm3-compiler.sh > >> >> > >> >> Log message: > >> >> upgrade config files when upgrading compiler > >> >> > >> > > >> > >> > >> > >> -- > >> Olaf Wagner -- elego Software Solutions GmbH > >> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > >> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 > >> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin > >> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 > >> > > > > > > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 > From jkrell at elego.de Thu Jul 22 15:51:06 2010 From: jkrell at elego.de (Jay Krell) Date: Thu, 22 Jul 2010 15:51:06 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100722135106.AF4EC2474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/22 15:51:06 Modified files: cm3/scripts/: install-cm3-compiler.sh Log message: fix insalling of config files, will require manual repair of Hudson nodes..but not, I should instead copy this code elsewhere to where Hudson will run it From jkrell at elego.de Thu Jul 22 16:01:26 2010 From: jkrell at elego.de (Jay Krell) Date: Thu, 22 Jul 2010 16:01:26 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100722140126.47A482474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/22 16:01:26 Modified files: cm3/scripts/regression/: defs.sh Log message: try repair missing config files From jkrell at elego.de Thu Jul 22 16:01:54 2010 From: jkrell at elego.de (Jay Krell) Date: Thu, 22 Jul 2010 16:01:54 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100722140154.41F972474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/22 16:01:54 Modified files: cm3/scripts/regression/: defs.sh Log message: try repair missing config files From jkrell at elego.de Thu Jul 22 16:59:48 2010 From: jkrell at elego.de (Jay Krell) Date: Thu, 22 Jul 2010 16:59:48 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100722145949.08E632474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/22 16:59:48 Modified files: cm3/m3-libs/m3core/src/time/POSIX/: TimePosixC.c Log message: Grain computation seems like a poorly implemented thing. I'm hoping we can replace it with something sysconf(?) or clock_getres. Experiments with clock_getres suggest no. It is often much larger than grain. Though it was close on Alpha/OSF I think. In the meantime: Historically we just computed grain once and accepted that value. Per the historical comment, that seemed not great. I changed it to loop until 2 or 3 grains were computed identically. I see this hang sometimes. Though seemingly only in slightly unusual situations like a cross build or Alpha/OSF or in a debugger. Anyway, let's try a different variation: Compute it a few times, and take the smallest value we find. I've tried up to 5 and it still varies from run to run on Alpha/OSF. So go down to just 3 since I can't win, and every computation takes time -- waiting for the time to progress. This still seems better than the historical behavior of one computation that might go very awry, and has the advantage over the replacement I had put in, which potentially could loop forever -- if grain was larger than scheduling interval, though nobody has reported that. From jkrell at elego.de Thu Jul 22 17:47:20 2010 From: jkrell at elego.de (Jay Krell) Date: Thu, 22 Jul 2010 17:47:20 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100722154721.92CABCC37E@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/22 17:47:20 Modified files: cm3/m3-sys/m3cc/gcc/gcc/: dse.c Log message: http://hudson.modula3.com:8080/job/cm3-current-m3cc-I386_DARWIN/2/consoleFull ../../gcc/gcc/dse.c:2766: warning: 'i' may be used uninitialized in this function From jkrell at elego.de Thu Jul 22 17:50:12 2010 From: jkrell at elego.de (Jay Krell) Date: Thu, 22 Jul 2010 17:50:12 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100722155013.5743F2474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/22 17:50:12 Modified files: cm3/m3-sys/m3cc/gcc/gcc/: ebitmap.c Log message: http://hudson.modula3.com:8080/job/cm3-current-m3cc-I386_DARWIN/2/consoleFull ebitmap.c: In function 'ebitmap_last_set_bit': ebitmap.c:89: warning: 'ebi.ptr' may be used uninitialized in this function ebitmap.c:89: warning: 'ebi.bit_num' may be used uninitialized in this function ebitmap.c:89: warning: 'ebi.eltnum' may be used uninitialized in this function ebitmap.c:89: warning: 'ebi.word' may be used uninitialized in this function ebitmap.h:124: warning: 'ourn' may be used uninitialized in this function ebitmap.c: In function 'ebitmap_ior_into': ebitmap.c:549: warning: 'i' may be used uninitialized in this function ebitmap.c: In function 'ebitmap_ior': ebitmap.c:673: warning: 'i' may be used uninitialized in this function ebitmap.c: In function 'ebitmap_and_compl': ebitmap.c:871: warning: 'i' may be used uninitialized in this function ebitmap.c: In function 'ebitmap_and_into': ebitmap.c:420: warning: 'i' may be used uninitialized in this function ebitmap.c: In function 'ebitmap_and': ebitmap.c:474: warning: 'i' may be used uninitialized in this function ebitmap.c: In function 'ebitmap_and_compl_into': ebitmap.c:791: warning: 'i' may be used uninitialized in this function From jkrell at elego.de Thu Jul 22 17:52:14 2010 From: jkrell at elego.de (Jay Krell) Date: Thu, 22 Jul 2010 17:52:14 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100722155214.B2DCF2474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/22 17:52:14 Modified files: cm3/m3-sys/m3cc/gcc/gcc/: tree-ssa-structalias.c Log message: http://hudson.modula3.com:8080/job/cm3-current-m3cc-I386_DARWIN/2/consoleFull tree-ssa-structalias.c:4811: warning: 'j' may be used uninitialized in this function From jkrell at elego.de Thu Jul 22 17:54:25 2010 From: jkrell at elego.de (Jay Krell) Date: Thu, 22 Jul 2010 17:54:25 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100722155425.C625C2474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/22 17:54:25 Modified files: cm3/m3-sys/m3cc/gcc/gcc/: ipa-struct-reorg.c Log message: http://hudson.modula3.com:8080/job/cm3-current-m3cc-I386_DARWIN/2/consoleFull ipa-struct-reorg.c:3540: warning: 'i' may be used uninitialized in this function From jkrell at elego.de Thu Jul 22 23:24:35 2010 From: jkrell at elego.de (Jay Krell) Date: Thu, 22 Jul 2010 23:24:35 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100722212435.F2CDB2474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/22 23:24:35 Modified files: cm3/m3-sys/m3cc/src/: m3makefile Log message: experiment that only affects SPARC32_LINUX From jkrell at elego.de Fri Jul 23 09:04:07 2010 From: jkrell at elego.de (Jay Krell) Date: Fri, 23 Jul 2010 9:04:07 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100723070407.9F30BCC37F@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/23 09:04:07 Modified files: cm3/m3-sys/cm3/test/src/: t.m3 Log message: Backward slashes confuse the test harness, so print them as tildes instead. From jkrell at elego.de Fri Jul 23 09:10:43 2010 From: jkrell at elego.de (Jay Krell) Date: Fri, 23 Jul 2010 9:10:43 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100723071044.C06E42474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/23 09:10:43 Modified files: cm3/m3-sys/cm3/test/src/: m3makefile Log message: build standalone From jkrell at elego.de Fri Jul 23 09:15:59 2010 From: jkrell at elego.de (Jay Krell) Date: Fri, 23 Jul 2010 9:15:59 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100723071600.83EA62474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/23 09:15:59 Modified files: cm3/m3-libs/patternmatching/tests/src/: m3makefile Log message: standalone From jkrell at elego.de Fri Jul 23 09:28:10 2010 From: jkrell at elego.de (Jay Krell) Date: Fri, 23 Jul 2010 9:28:10 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100723072847.8D8982474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/23 09:28:10 Modified files: cm3/m3-libs/patternmatching/tests/: tests.input Log message: Double backslash causing \x8 to appear in output. Comment out this case. (It works fine at the console, but not within Hudson.) From wagner at elego.de Fri Jul 23 18:08:12 2010 From: wagner at elego.de (Olaf Wagner) Date: Fri, 23 Jul 2010 18:08:12 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100723160815.7FCAA2474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: wagner at birch. 10/07/23 18:08:12 Modified files: cm3/scripts/: pkgmap.sh Log message: disabling non-working quote_xml for a while as in the release branch From wagner at elego.de Fri Jul 23 20:13:21 2010 From: wagner at elego.de (Olaf Wagner) Date: Fri, 23 Jul 2010 20:13:21 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100723181321.B2C082474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: wagner at birch. 10/07/23 20:13:21 Modified files: cm3/m3-sys/m3tests/: PkgTags cm3/m3-sys/m3tests/src/e0/e026/: stdout.build cm3/m3-sys/m3tests/src/r0/r004/: stderr.pgm Log message: merge some fixes from release branch From wagner at elego.de Fri Jul 23 20:14:24 2010 From: wagner at elego.de (Olaf Wagner) Date: Fri, 23 Jul 2010 20:14:24 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100723181424.636112474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: wagner at birch. 10/07/23 20:14:24 Modified files: cm3/m3-libs/sysutils/src/: FSUtils.m3 Log message: add OSError arguments to exception text From jkrell at elego.de Fri Jul 23 21:39:35 2010 From: jkrell at elego.de (Jay Krell) Date: Fri, 23 Jul 2010 21:39:35 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100723193935.59B3C2474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/23 21:39:35 Modified files: cm3/m3-libs/patternmatching/tests/: tests.input Log message: put back since Olaf removed broken xml quoting From jkrell at elego.de Fri Jul 23 21:41:34 2010 From: jkrell at elego.de (Jay Krell) Date: Fri, 23 Jul 2010 21:41:34 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100723194134.C48722474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/23 21:41:34 Modified files: cm3/m3-sys/cm3/test/src/: t.m3 Log message: put back since Olaf disabled the xml quoting From jkrell at elego.de Sat Jul 24 16:16:26 2010 From: jkrell at elego.de (Jay Krell) Date: Sat, 24 Jul 2010 16:16:26 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100724141626.49E402474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/24 16:16:26 Modified files: cm3/m3-libs/m3core/src/: m3core.h cm3/m3-libs/m3core/src/runtime/POSIX/: RTSignalC.c cm3/m3-libs/m3core/src/runtime/common/: RTProcessC.c cm3/m3-libs/m3core/src/thread/POSIX/: ThreadPosixC.c cm3/m3-libs/m3core/src/unix/Common/: m3makefile cm3/m3-sys/cminstall/src/config-no-install/: OpenBSD.common Added files: cm3/m3-libs/m3core/src/unix/Common/context/: m3makefile cm3/m3-libs/m3core/src/unix/Common/context/setjmp/: m3makefile context.h context.c Log message: restore jmpbuf munging for OpenBSD/i386, from 5.8.6 release There is code here for other platforms but it isn't used. There is code here for other OpenBSD platforms, but isn't used currectly. It might be good to smush the unix/setjmp directory into thread/POSIX/openbsd_context.[ch]. It *is* in a sense "unix", because it adheres to the Posix make/get/set/swapcontext functions, except I rename them and the header. From jkrell at elego.de Sat Jul 24 16:26:06 2010 From: jkrell at elego.de (Jay Krell) Date: Sat, 24 Jul 2010 16:26:06 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100724142606.D11742474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/24 16:26:06 Modified files: cm3/m3-sys/m3tests/src/p2/p240/: m3makefile Log message: maybe fix flags on this file? (no diff) From jkrell at elego.de Sat Jul 24 16:27:17 2010 From: jkrell at elego.de (Jay Krell) Date: Sat, 24 Jul 2010 16:27:17 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100724142717.DADCC2474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/24 16:27:17 Modified files: cm3/m3-sys/m3tests/src/p2/p230/: m3makefile Log message: maybe fix flags on this file? (no diff, I had an at sign in ls -l)) From jkrell at elego.de Sat Jul 24 16:27:55 2010 From: jkrell at elego.de (Jay Krell) Date: Sat, 24 Jul 2010 16:27:55 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100724142755.1EDC22474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/24 16:27:55 Modified files: cm3/m3-sys/m3tests/src/: m3makefile Log message: maybe fix flags on this file? (no diff, I had an at sign in ls -l)) From jkrell at elego.de Sat Jul 24 16:28:32 2010 From: jkrell at elego.de (Jay Krell) Date: Sat, 24 Jul 2010 16:28:32 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100724142832.49A302474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/24 16:28:32 Modified files: cm3/m3-sys/m3tests/src/p2/p242/: m3makefile Main.m3 Log message: maybe fix flags on this file? (no diff, I had an at sign in ls -l)) From jkrell at elego.de Sat Jul 24 16:29:15 2010 From: jkrell at elego.de (Jay Krell) Date: Sat, 24 Jul 2010 16:29:15 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100724142915.5EF7F2474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/24 16:29:15 Modified files: cm3/m3-sys/m3tests/src/p2/p243/: m3makefile Main.m3 Log message: maybe fix flags on this file? (no diff, I had an at sign in ls -l)) From jkrell at elego.de Sat Jul 24 16:29:55 2010 From: jkrell at elego.de (Jay Krell) Date: Sat, 24 Jul 2010 16:29:55 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100724142957.9CC1F2474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/24 16:29:55 Modified files: cm3/m3-sys/m3tests/src/p2/p244/: m3makefile Main.m3 Log message: maybe fix flags on this file? (no diff, I had an at sign in ls -l)) From jkrell at elego.de Sat Jul 24 16:30:25 2010 From: jkrell at elego.de (Jay Krell) Date: Sat, 24 Jul 2010 16:30:25 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100724143025.DDFFA2474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/24 16:30:25 Modified files: cm3/m3-sys/m3tests/src/p2/p246/: m3makefile Main.m3 Log message: maybe fix flags on this file? (no diff, I had an at sign in ls -l)) From jkrell at elego.de Sat Jul 24 16:33:16 2010 From: jkrell at elego.de (Jay Krell) Date: Sat, 24 Jul 2010 16:33:16 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100724143316.86F3B2474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/24 16:33:16 Modified files: cm3/m3-sys/m3cc/gcc/gcc/: tree-ssa-forwprop.c Log message: tree-ssa-forwprop.c: In function `forward_propagate_into_cond': tree-ssa-forwprop.c:362: warning: `name' might be used uninitialized in this function From hosking at cs.purdue.edu Sat Jul 24 19:42:06 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sat, 24 Jul 2010 13:42:06 -0400 Subject: [M3commit] CVS Update: cm3 In-Reply-To: <20100724143316.86F3B2474003@birch.elegosoft.com> References: <20100724143316.86F3B2474003@birch.elegosoft.com> Message-ID: <10A6AF46-03F8-4FE5-9833-BC22FE161758@cs.purdue.edu> Do we really want to dirty the gcc diffs from the original sources in this way. It will make sifting the diffs a nightmare for future ports. 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 24 Jul 2010, at 16:33, Jay Krell wrote: > CVSROOT: /usr/cvs > Changes by: jkrell at birch. 10/07/24 16:33:16 > > Modified files: > cm3/m3-sys/m3cc/gcc/gcc/: tree-ssa-forwprop.c > > Log message: > tree-ssa-forwprop.c: In function `forward_propagate_into_cond': > tree-ssa-forwprop.c:362: warning: `name' might be used uninitialized in this function -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sun Jul 25 03:57:55 2010 From: jay.krell at cornell.edu (Jay K) Date: Sun, 25 Jul 2010 01:57:55 +0000 Subject: [M3commit] CVS Update: cm3 In-Reply-To: <10A6AF46-03F8-4FE5-9833-BC22FE161758@cs.purdue.edu> References: <20100724143316.86F3B2474003@birch.elegosoft.com>, <10A6AF46-03F8-4FE5-9833-BC22FE161758@cs.purdue.edu> Message-ID: I'm pretty sure the three way merge I did will tolerate it ok. A human should tolerate it easily too. I don't look through the CVS history to find the diffs, I diff against baseline gcc 4.3.0, 4.3.5, etc. ? (btw, in doing so, I found another label thing we did, have to come back to 4.5.0 work soon..) But if you insist, ok. ?- Jay ________________________________ > From: hosking at cs.purdue.edu > Date: Sat, 24 Jul 2010 13:42:06 -0400 > To: jkrell at elego.de > CC: m3commit at elegosoft.com > Subject: Re: [M3commit] CVS Update: cm3 > > Do we really want to dirty the gcc diffs from the original sources in > this way. It will make sifting the diffs a nightmare for future ports. > > 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 24 Jul 2010, at 16:33, Jay Krell wrote: > > CVSROOT: /usr/cvs > Changes by: jkrell at birch. 10/07/24 16:33:16 > > Modified files: > cm3/m3-sys/m3cc/gcc/gcc/: tree-ssa-forwprop.c > > Log message: > tree-ssa-forwprop.c: In function `forward_propagate_into_cond': > tree-ssa-forwprop.c:362: warning: `name' might be used uninitialized in > this function > From jkrell at elego.de Sun Jul 25 13:52:25 2010 From: jkrell at elego.de (Jay Krell) Date: Sun, 25 Jul 2010 13:52:25 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100725115225.ED7532474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/25 13:52:25 Added files: cm3/m3-libs/m3core/src/unix/Common/context/setjmp/: config.c tcontext.c Makefile Log message: bring back deleted files From jkrell at elego.de Mon Jul 26 08:40:22 2010 From: jkrell at elego.de (Jay Krell) Date: Mon, 26 Jul 2010 8:40:22 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100726064022.4A981CC397@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/26 08:40:22 Modified files: cm3/m3-libs/m3core/src/unix/Common/context/setjmp/: Makefile config.c context.c context.h tcontext.c Added files: cm3/m3-libs/m3core/src/unix/Common/context/setjmp/: context_mips64.s Log message: adapt to MIPS64EL_OPENBSD (Gdium laptop, Loongson processor) From jkrell at elego.de Mon Jul 26 10:24:47 2010 From: jkrell at elego.de (Jay Krell) Date: Mon, 26 Jul 2010 10:24:47 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100726082447.B356DCC37E@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/26 10:24:47 Added files: cm3/m3-libs/m3core/src/thread/PTHREAD/: ThreadOpenBSD.c Log message: let's revisit pthreads on OpenBSD From jkrell at elego.de Mon Jul 26 10:34:08 2010 From: jkrell at elego.de (Jay Krell) Date: Mon, 26 Jul 2010 10:34:08 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100726083409.02B7F2474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/26 10:34:08 Modified files: cm3/m3-libs/m3core/src/: m3makefile Removed files: cm3/m3-libs/m3core/src/: platforms.quake Log message: remove platforms lists -- the data comes from each platform's config file now From jkrell at elego.de Mon Jul 26 13:50:14 2010 From: jkrell at elego.de (Jay Krell) Date: Mon, 26 Jul 2010 13:50:14 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100726115014.D2D432474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/26 13:50:14 Modified files: cm3/m3-libs/m3core/src/thread/PTHREAD/: ThreadOpenBSD.c ThreadPThreadC.c m3makefile Log message: Hypothetical fixes for OpenBSD to use pthreads. It compiles and links, but then I get assertion failures in RTCollector.m3. Not going to debug it for now, for a while. From jkrell at elego.de Mon Jul 26 13:51:52 2010 From: jkrell at elego.de (Jay Krell) Date: Mon, 26 Jul 2010 13:51:52 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100726115152.C1ABB2474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/26 13:51:52 Modified files: cm3/m3-libs/m3core/src/thread/PTHREAD/: test_interix.c Log message: add comment to the top explaining the file From jkrell at elego.de Mon Jul 26 13:53:40 2010 From: jkrell at elego.de (Jay Krell) Date: Mon, 26 Jul 2010 13:53:40 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100726115340.D84082474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/26 13:53:40 Modified files: cm3/m3-libs/m3core/src/thread/PTHREAD/: ThreadFreeBSD.c Log message: add a comment explaining what I believe is a true deficiency of this code: it scans the entire stack, not just the part starting at the current stack pointer From jkrell at elego.de Mon Jul 26 13:55:17 2010 From: jkrell at elego.de (Jay Krell) Date: Mon, 26 Jul 2010 13:55:17 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100726115517.D6C8CCC37E@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/26 13:55:17 Modified files: cm3/m3-sys/cminstall/src/config-no-install/: OpenBSD.common Log message: Stop using -static. It breaks pthreads. Pthreads appear to have other (not debugged) problems so I'm not using them anyway, but what I found just makes me more nervous about -static. The reason -static was used here is that OpenBSD is apparently aggressive about breaking things from release to release. In particular, like, libc.so gets renamed every time From jkrell at elego.de Mon Jul 26 14:12:32 2010 From: jkrell at elego.de (Jay Krell) Date: Mon, 26 Jul 2010 14:12:32 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100726121232.87690CC37E@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/26 14:12:32 Modified files: cm3/m3-libs/m3core/src/unix/Common/context/setjmp/: Makefile context.c Log message: restore OpenBSD/powerpc to working From jkrell at elego.de Mon Jul 26 14:31:09 2010 From: jkrell at elego.de (Jay Krell) Date: Mon, 26 Jul 2010 14:31:09 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100726123109.8168BCC37E@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/26 14:31:09 Modified files: cm3/m3-libs/m3core/src/thread/PTHREAD/: ThreadPThreadC.c Log message: tweak the OpenBSD fix (resolving diffs across my machines) From jkrell at elego.de Mon Jul 26 14:34:22 2010 From: jkrell at elego.de (Jay Krell) Date: Mon, 26 Jul 2010 14:34:22 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100726123422.A3B93CC37E@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/26 14:34:22 Modified files: cm3/m3-libs/m3core/src/: m3makefile cm3/m3-libs/m3core/src/thread/: m3makefile Removed files: cm3/m3-libs/m3core/src/: thread.quake Log message: Tweak the determination of user threads vs. pthreads. The logic is: NT, Win32, Mingw, Cygwin => Win32 FreeBSD4 (really, 4, not I386_FREEBSD), OpenBSD => user threads -DNOPTHREAD => user threads else => pthreads There is no longer a list of platforms, but one can easily add it here, using ({"plat1", "plat2"} contains TARGET) or such. As well, the config files should probably say, e.g.: ThreadLibrary = "user" or PosixUserThreads = TRUE Really, in the config files. Though src/m3makefile might warn/error for known not to work things like user threads on NT for example. From jkrell at elego.de Mon Jul 26 15:03:55 2010 From: jkrell at elego.de (Jay Krell) Date: Mon, 26 Jul 2010 15:03:55 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100726130355.48D2A2474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/26 15:03:55 Modified files: cm3/m3-sys/m3cc/src/: platforms.quake Log message: remove duplicate PPC64_DARWIN, and add version '6' to the end of it From jkrell at elego.de Mon Jul 26 15:14:40 2010 From: jkrell at elego.de (Jay Krell) Date: Mon, 26 Jul 2010 15:14:40 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100726131441.006C92474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/26 15:14:40 Modified files: cm3/m3-sys/cminstall/src/config-no-install/: MIPS64_OPENBSD Log message: just comments/whitespace From jkrell at elego.de Mon Jul 26 15:15:41 2010 From: jkrell at elego.de (Jay Krell) Date: Mon, 26 Jul 2010 15:15:41 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100726131541.814CECC37F@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/26 15:15:41 Modified files: cm3/m3-sys/cminstall/src/config-no-install/: MIPS64_OPENBSD Log message: actually previous had an important typo fix as well: 'table' vs. 'tables', to actually disable the tables, which the generation of leads to assertion failures in the backend, for this target (and its little endian sibling) From jkrell at elego.de Mon Jul 26 15:30:09 2010 From: jkrell at elego.de (Jay Krell) Date: Mon, 26 Jul 2010 15:30:09 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100726133009.A4B652474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/26 15:30:09 Modified files: cm3/m3-libs/m3core/src/unix/Common/context/setjmp/: m3makefile Log message: compile this for all OpenBSD platforms (granted, sparc64 not tested in a while, amd64 maybe never finished? but mips64, powerpc, x86 appear good; need to try sigaltstack again though) From jkrell at elego.de Mon Jul 26 15:40:14 2010 From: jkrell at elego.de (Jay Krell) Date: Mon, 26 Jul 2010 15:40:14 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100726134014.5D94F2474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/26 15:40:14 Modified files: cm3/m3-sys/cminstall/src/config-no-install/: OpenBSD.common Log message: remove X11 libraries that I think were only needed if using -static From jkrell at elego.de Mon Jul 26 15:42:31 2010 From: jkrell at elego.de (Jay Krell) Date: Mon, 26 Jul 2010 15:42:31 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100726134231.6E0832474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/26 15:42:31 Modified files: cm3/m3-sys/cminstall/src/config-no-install/: Interix.common PPC32_OPENBSD Unix.common Log message: disable shared on PPC32_OPENBSD, it has problems move the disabling of shared on Interix to Interix.common instead of having Unix.common know about it, by making there be another function interfacing among the config files: proc AdjustShared(shared) takes a boolean as to if shared was requested and returns a boolean as to if should really be shared. e.g.: false on Interix and PPC32_OPENBSD the default is false if using an older cm3 else whatever is input on curent cm3 ("older" is defined by probing for a symbol added in 5.8.6); this is more relevant if mixing current config files with older cm3, which historically I have often done, though it can be problematic From jkrell at elego.de Mon Jul 26 15:44:59 2010 From: jkrell at elego.de (Jay Krell) Date: Mon, 26 Jul 2010 15:44:59 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100726134459.CD4E32474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/26 15:44:59 Modified files: cm3/m3-libs/m3core/src/atomic/: m3makefile cm3/m3-libs/m3core/src/runtime/common/: Compiler.tmpl cm3/m3-libs/m3core/src/unix/Common/context/setjmp/: m3makefile cm3/m3-sys/m3cc/src/: platforms.quake cm3/m3-sys/m3middle/src/: Target.i3 Target.m3 cm3/scripts/: sysinfo.sh cm3/scripts/python/: pylib.py Added files: cm3/m3-libs/m3core/src/C/MIPS64EL_OPENBSD/: Csetjmp.i3 m3makefile cm3/m3-sys/cminstall/src/config-no-install/: MIPS64EL_OPENBSD Log message: add MIPS64EL_OPENBSD (e.g. Loongon/Gdium/Lemote) complete with: no atomics for 1 byte or 2 bytes no unwind tables (internal compiler error) These are for hypothetical future better exception handling, so ok. no debug symbols (there was a problem?) Should try again. user mode threads and worse, jmpbuf hacking need to try again the sigaltstack approach no Java => no Hudson Enough to build a cm3 that reports the expected "unable to find cm3.cfg". see: http://www.openbsd.org/loongson.html search web for: "Amazon gdium" etc. Presumably MIPS64EL_LINUX will fair a bit better. From jay.krell at cornell.edu Mon Jul 26 15:48:06 2010 From: jay.krell at cornell.edu (Jay K) Date: Mon, 26 Jul 2010 13:48:06 +0000 Subject: [M3commit] CVS Update: cm3 In-Reply-To: <20100726134459.CD4E32474003@birch.elegosoft.com> References: <20100726134459.CD4E32474003@birch.elegosoft.com> Message-ID: attached ---------------------------------------- > Date: Mon, 26 Jul 2010 15:44: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/07/26 15:44:59 > > Modified files: > cm3/m3-libs/m3core/src/atomic/: m3makefile > cm3/m3-libs/m3core/src/runtime/common/: Compiler.tmpl > cm3/m3-libs/m3core/src/unix/Common/context/setjmp/: m3makefile > cm3/m3-sys/m3cc/src/: platforms.quake > cm3/m3-sys/m3middle/src/: Target.i3 Target.m3 > cm3/scripts/: sysinfo.sh > cm3/scripts/python/: pylib.py > Added files: > cm3/m3-libs/m3core/src/C/MIPS64EL_OPENBSD/: Csetjmp.i3 > m3makefile > cm3/m3-sys/cminstall/src/config-no-install/: MIPS64EL_OPENBSD > > Log message: > add MIPS64EL_OPENBSD (e.g. Loongon/Gdium/Lemote) > complete with: > no atomics for 1 byte or 2 bytes > no unwind tables (internal compiler error) > These are for hypothetical future better exception handling, so ok. > no debug symbols (there was a problem?) > Should try again. > user mode threads > and worse, jmpbuf hacking > need to try again the sigaltstack approach > no Java => no Hudson > > Enough to build a cm3 that reports the expected "unable to find cm3.cfg". > > see: > http://www.openbsd.org/loongson.html > search web for: "Amazon gdium" > etc. > > Presumably MIPS64EL_LINUX will fair a bit better. > -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: mips64el_openbsd.txt URL: From wagner at elego.de Tue Jul 27 07:21:20 2010 From: wagner at elego.de (Olaf Wagner) Date: Tue, 27 Jul 2010 7:21:20 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100727052120.50A7D2474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: wagner at birch. 10/07/27 07:21:20 Modified files: cm3/m3-sys/m3tests/src/: m3makefile Log message: list build dir before removal From jkrell at elego.de Tue Jul 27 08:51:53 2010 From: jkrell at elego.de (Jay Krell) Date: Tue, 27 Jul 2010 8:51:53 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100727065153.C7D342474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/27 08:51:53 Added files: cm3/m3-libs/m3core/src/thread/POSIX/: test_thread_sigaltstack.c Log message: add test case, it only hangs on OpenBSD with -pthread!" From jkrell at elego.de Tue Jul 27 08:58:56 2010 From: jkrell at elego.de (Jay Krell) Date: Tue, 27 Jul 2010 8:58:56 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100727065856.8BA362474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/27 08:58:56 Modified files: cm3/m3-libs/m3core/src/thread/POSIX/: test_thread_sigaltstack.c Log message: reduce From jkrell at elego.de Wed Jul 28 12:32:51 2010 From: jkrell at elego.de (Jay Krell) Date: Wed, 28 Jul 2010 12:32:51 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100728103310.D81982474006@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/28 12:32:51 Modified files: cm3/m3-libs/m3core/src/thread/: m3makefile Log message: copy in stuff from cm3cfg.common, until it is updated From jkrell at elego.de Wed Jul 28 13:01:29 2010 From: jkrell at elego.de (Jay Krell) Date: Wed, 28 Jul 2010 13:01:29 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100728110129.D9C8CCC37E@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/28 13:01:29 Modified files: cm3/m3-libs/sysutils/src/: FSUtils.m3 Log message: add some debugprint From jkrell at elego.de Wed Jul 28 13:03:15 2010 From: jkrell at elego.de (Jay Krell) Date: Wed, 28 Jul 2010 13:03:15 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100728110315.9C8F6CC37F@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/28 13:03:15 Modified files: cm3/m3-libs/sysutils/src/: FSUtils.m3 Log message: add more debugprint From jkrell at elego.de Wed Jul 28 13:10:22 2010 From: jkrell at elego.de (Jay Krell) Date: Wed, 28 Jul 2010 13:10:22 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100728111022.9AB6A2474006@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/28 13:10:22 Modified files: cm3/m3-sys/m3cc/src/: m3makefile Log message: just because it is what other code did, get just the leaf name and form the full path ourselves (this is related to rmrec failures) From jkrell at elego.de Wed Jul 28 13:22:40 2010 From: jkrell at elego.de (Jay Krell) Date: Wed, 28 Jul 2010 13:22:40 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100728112240.735B32474006@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/28 13:22:40 Modified files: cm3/m3-sys/m3cc/src/: m3makefile Log message: manually delete gmp with exec(rm -rf) From jkrell at elego.de Wed Jul 28 13:23:09 2010 From: jkrell at elego.de (Jay Krell) Date: Wed, 28 Jul 2010 13:23:09 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100728112309.71F972474006@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/28 13:23:09 Modified files: cm3/m3-sys/m3cc/src/: m3makefile Log message: add comment to the exec(rm -rf gmp) From jkrell at elego.de Wed Jul 28 14:02:56 2010 From: jkrell at elego.de (Jay Krell) Date: Wed, 28 Jul 2010 14:02:56 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100728120258.5A3F62474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/28 14:02:56 Modified files: cm3/m3-sys/m3cc/src/: m3makefile Log message: m3makefile From jkrell at elego.de Wed Jul 28 14:04:02 2010 From: jkrell at elego.de (Jay Krell) Date: Wed, 28 Jul 2010 14:04:02 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100728120441.BC29A2474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/28 14:04:02 Modified files: cm3/m3-sys/m3cc/src/: m3makefile Log message: flubbed previous commit, comment was to be: sparc32_linux: remove the configure -with-cpu=v8 put back -target=sparc-linux config file will and needs to say -mcpu=v9 (tested via gcc -mcpu=v8 and -mcpu=v9 and using an atomic function) My Debian gcc 4.3 was configured as: --with-cpu=v8 --with-long-double-128 --build=sparc-linux-gnu --host=sparc-linux-gnu --target=sparc-linux-gnu among others. (notice: -with-long-double-128 -- something we want for Modula-3 also..) From jkrell at elego.de Wed Jul 28 14:10:49 2010 From: jkrell at elego.de (Jay Krell) Date: Wed, 28 Jul 2010 14:10:49 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100728121049.9A5572474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/28 14:10:49 Modified files: cm3/m3-sys/m3cc/src/: m3makefile Log message: go back to full paths from fs_lsdirs/files From jkrell at elego.de Wed Jul 28 14:14:42 2010 From: jkrell at elego.de (Jay Krell) Date: Wed, 28 Jul 2010 14:14:42 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100728121447.ED8DF2474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/28 14:14:42 Modified files: cm3/scripts/: install-cm3-compiler.sh Log message: try set -e; set -x here, so we can see e.g. upgrading the compiler upgrade the config files From jay.krell at cornell.edu Wed Jul 28 14:20:43 2010 From: jay.krell at cornell.edu (Jay K) Date: Wed, 28 Jul 2010 12:20:43 +0000 Subject: [M3commit] CVS Update: cm3 In-Reply-To: <20100728120441.BC29A2474003@birch.elegosoft.com> References: <20100728120441.BC29A2474003@birch.elegosoft.com> Message-ID: And even this comment was wrong: it had said -with-cpu=v9 not v8. ?- Jay ---------------------------------------- > Date: Wed, 28 Jul 2010 14:04:02 +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/07/28 14:04:02 > > Modified files: > cm3/m3-sys/m3cc/src/: m3makefile > > Log message: > flubbed previous commit, comment was to be: > sparc32_linux: remove the configure -with-cpu=v8 > put back -target=sparc-linux > > config file will and needs to say -mcpu=v9 > (tested via gcc -mcpu=v8 and -mcpu=v9 and using an atomic function) > > My Debian gcc 4.3 was configured as: > --with-cpu=v8 --with-long-double-128 --build=sparc-linux-gnu --host=sparc-linux-gnu --target=sparc-linux-gnu > > among others. (notice: -with-long-double-128 -- something we want for Modula-3 also..) > From jkrell at elego.de Wed Jul 28 14:28:37 2010 From: jkrell at elego.de (Jay Krell) Date: Wed, 28 Jul 2010 14:28:37 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100728122848.8145F2474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/28 14:28:37 Modified files: cm3/doc/notes/: todo.txt Log message: some updates From jkrell at elego.de Wed Jul 28 14:31:15 2010 From: jkrell at elego.de (Jay Krell) Date: Wed, 28 Jul 2010 14:31:15 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100728123122.2871ECC110@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/28 14:31:15 Modified files: cm3/doc/notes/: todo.txt Log message: some updates From jkrell at elego.de Wed Jul 28 14:32:14 2010 From: jkrell at elego.de (Jay Krell) Date: Wed, 28 Jul 2010 14:32:14 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100728123224.51325CC110@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/28 14:32:14 Modified files: cm3/doc/notes/: todo.txt Log message: mention android and iphone From jkrell at elego.de Wed Jul 28 14:33:23 2010 From: jkrell at elego.de (Jay Krell) Date: Wed, 28 Jul 2010 14:33:23 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100728123348.A112FCC110@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/28 14:33:23 Modified files: cm3/doc/notes/: todo.txt Log message: mention AIX: ppc32, ppc64 From jkrell at elego.de Wed Jul 28 16:07:27 2010 From: jkrell at elego.de (Jay Krell) Date: Wed, 28 Jul 2010 16:07:27 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100728140727.C071E2474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/28 16:07:27 Modified files: cm3/scripts/: install-cm3-compiler.sh Log message: don't set -e/x, use echo instead, cp fails, I think, because of the CVS directory From jkrell at elego.de Wed Jul 28 16:19:46 2010 From: jkrell at elego.de (Jay Krell) Date: Wed, 28 Jul 2010 16:19:46 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100728142007.313242474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/28 16:19:46 Modified files: cm3/m3-sys/cm3/src/: M3Build.m3 Log message: remove the "ignoring override" print out, I think few people know it means and fewer (nobody) finds it useful From jkrell at elego.de Wed Jul 28 16:22:03 2010 From: jkrell at elego.de (Jay Krell) Date: Wed, 28 Jul 2010 16:22:03 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100728142204.996F52474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/28 16:22:03 Modified files: cm3/m3-sys/cm3/src/: M3Build.m3 Log message: remove more of the code for: remove the "ignoring override" print out, I think few people know it means and fewer (nobody) finds it useful From jkrell at elego.de Wed Jul 28 16:47:12 2010 From: jkrell at elego.de (Jay Krell) Date: Wed, 28 Jul 2010 16:47:12 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100728144713.27FD82474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/28 16:47:12 Modified files: cm3/m3-sys/m3cc/src/: m3makefile Log message: sparc32_linux: fixed, now an experiment, specific to it, I kind of want to *not* specific host, so that a cross build isn't detected, so that autoconf will do its usual stuff From jkrell at elego.de Wed Jul 28 18:08:17 2010 From: jkrell at elego.de (Jay Krell) Date: Wed, 28 Jul 2010 18:08:17 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100728160817.9B0EA2474006@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/28 18:08:17 Modified files: cm3/caltech-parser/drawcontext/test/: .cvsignore cm3/caltech-parser/parserlib/parserlib/test/: .cvsignore cm3/m3-db/db/test/: .cvsignore cm3/m3-db/odbc/test/: .cvsignore cm3/m3-db/postgres95/test/: .cvsignore cm3/m3-db/stable/test/: .cvsignore cm3/m3-libs/arithmetic/test/: .cvsignore cm3/m3-libs/bitvector/test/: .cvsignore cm3/m3-libs/patternmatching/tests/: .cvsignore cm3/m3-libs/slisp/tests/: .cvsignore Added files: cm3/m3-comm/udp/test/: .cvsignore cm3/m3-libs/binIO/test/: .cvsignore cm3/m3-libs/libm3/tests/: .cvsignore cm3/m3-sys/cm3/test/: .cvsignore cm3/m3-sys/m3quake/test/: .cvsignore Log message: .cvsignore files From jkrell at elego.de Wed Jul 28 18:09:14 2010 From: jkrell at elego.de (Jay Krell) Date: Wed, 28 Jul 2010 18:09:14 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100728160914.8754FCC110@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/28 18:09:14 Modified files: cm3/scripts/: .cvsignore Log message: add PKGS to .cvsignore From jkrell at elego.de Wed Jul 28 18:10:50 2010 From: jkrell at elego.de (Jay Krell) Date: Wed, 28 Jul 2010 18:10:50 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100728161050.332242474006@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/28 18:10:50 Added files: cm3/: .cvsignore Log message: we drop date.c and m3date in the root: .cvsignore From jkrell at elego.de Wed Jul 28 19:29:45 2010 From: jkrell at elego.de (Jay Krell) Date: Wed, 28 Jul 2010 19:29:45 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100728172945.24401CC38A@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/28 19:29:45 Modified files: cm3/m3-sys/cminstall/src/config-no-install/: MIPS64EL_OPENBSD Unix.common Log message: There seems to be no odbc for MIPS64EL_OPENBSD. So, new interface among the config files: proc HasOdbc() return boolean Default is true. MIPS64EL_OPENBSD provides implementation that always returns false. Guides creation of default SYSTEM_LIBS and SYSTEM_LIBORDER. If we could remove elements from an array and table, that would be a better mechanism perhaps. From jkrell at elego.de Wed Jul 28 19:47:45 2010 From: jkrell at elego.de (Jay Krell) Date: Wed, 28 Jul 2010 19:47:45 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100728174745.563F22474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/28 19:47:45 Modified files: cm3/m3-sys/cminstall/src/config-no-install/: Unix.common Log message: huh? fix SYSTEM_LIBORDER From jkrell at elego.de Wed Jul 28 20:05:08 2010 From: jkrell at elego.de (Jay Krell) Date: Wed, 28 Jul 2010 20:05:08 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100728180508.64AA8CC37F@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/28 20:05:08 Modified files: cm3/m3-libs/m3core/src/unix/Common/context/setjmp/: context.c Log message: remove OpenBSD/powerpc hack that no longer seems necessary From jkrell at elego.de Wed Jul 28 21:00:30 2010 From: jkrell at elego.de (Jay Krell) Date: Wed, 28 Jul 2010 21:00:30 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100728190030.8DE142474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/28 21:00:30 Modified files: cm3/doc/notes/: todo.txt Log message: add new_adr, reliable stacks for assertion failure From jkrell at elego.de Wed Jul 28 21:02:45 2010 From: jkrell at elego.de (Jay Krell) Date: Wed, 28 Jul 2010 21:02:45 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100728190246.01B9E2474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/28 21:02:45 Modified files: cm3/m3-sys/cminstall/src/config-no-install/: PPC32_OPENBSD Log message: enable sharing on OpenBSD/powerpc -- using -fpic instead of -fPIC was the key, though that doesn't make sense to me and I didn't debug it From jkrell at elego.de Wed Jul 28 21:09:46 2010 From: jkrell at elego.de (Jay Krell) Date: Wed, 28 Jul 2010 21:09:46 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100728190947.3C2DACC37F@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/28 21:09:46 Modified files: cm3/m3-games/tetris/src/: m3makefile Log message: disable on MIPS64EL_OPENBSD due to: /usr/bin/ld: not enough GOT space for local GOT entries /usr/bin/ld: BFD 2.15 internal error, aborting at /usr/src/gnu/usr.bin/binutils/bfd/elfxx-mips.c line 6483 in _bfd_mips_elf_relocate_section /usr/bin/ld: Please report this bug. F From jkrell at elego.de Wed Jul 28 22:40:09 2010 From: jkrell at elego.de (Jay Krell) Date: Wed, 28 Jul 2010 22:40:09 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100728204010.1CF84CC38A@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/28 22:40:09 Modified files: cm3/m3-libs/m3core/src/unix/Common/context/setjmp/: context.c Removed files: cm3/m3-libs/m3core/src/unix/Common/context/setjmp/: context_mips64.s Log message: much better fix for mips don't access any globals (including functions) in internal_setcontext only access parameters (we can pass anything we need) This way, the code is correctly position independent and works in shared libraries. Before, anything shared would crash. As a bonus, though we have to write slightly unusual C, we don't need any assembly. Now, Juno works! From jkrell at elego.de Wed Jul 28 22:47:52 2010 From: jkrell at elego.de (Jay Krell) Date: Wed, 28 Jul 2010 22:47:52 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100728204753.1EFA2CC38A@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/28 22:47:52 Modified files: cm3/m3-libs/m3core/src/unix/Common/context/setjmp/: m3makefile Log message: forgot m3makefile, I had edited on the actual mips machine From jkrell at elego.de Wed Jul 28 23:02:08 2010 From: jkrell at elego.de (Jay Krell) Date: Wed, 28 Jul 2010 23:02:08 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100728210212.30F98CC37E@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/28 23:02:08 Modified files: cm3/m3-sys/m3cc/src/: m3makefile Log message: go back to being explicit about sparc32_linux target (see http://hudson.modula3.com:8080/job/cm3-current-build-SPARC32_LINUX/38/console; one would think -m32 would make this not matter) From jkrell at elego.de Wed Jul 28 23:15:23 2010 From: jkrell at elego.de (Jay Krell) Date: Wed, 28 Jul 2010 23:15:23 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100728211523.AEAFF2474008@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/28 23:15:23 Modified files: cm3/m3-sys/m3quake/src/: QMachine.m3 Log message: more diagnostics for rmrec problem From jkrell at elego.de Wed Jul 28 23:17:32 2010 From: jkrell at elego.de (Jay Krell) Date: Wed, 28 Jul 2010 23:17:32 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100728211732.28E232474008@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/28 23:17:32 Modified files: cm3/m3-sys/m3cc/src/: m3makefile Log message: more bogosity because rmrec fails From jkrell at elego.de Wed Jul 28 23:19:27 2010 From: jkrell at elego.de (Jay Krell) Date: Wed, 28 Jul 2010 23:19:27 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100728211927.E751C2474008@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/28 23:19:27 Modified files: cm3/m3-libs/sysutils/src/: FSUtils.m3 Log message: more diagnostics From jkrell at elego.de Thu Jul 29 14:42:13 2010 From: jkrell at elego.de (Jay Krell) Date: Thu, 29 Jul 2010 14:42:13 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100729124213.D9FD52474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/29 14:42:13 Modified files: cm3/m3-sys/cminstall/src/config-no-install/: OpenBSD.common Log message: Oops: OpenBSD up to and including 4.7 seems to have no $ORIGIN support. It has ld -z origin, but that's it. OpenBSD users should either set LD_LIBRARY_PATH or rebuild themselves. Under consideration, given time, is a new distribution form where users will configure (autoconf), assemble, compile C, link, install. And probably build m3cc themselves too. From jkrell at elego.de Thu Jul 29 15:10:33 2010 From: jkrell at elego.de (Jay Krell) Date: Thu, 29 Jul 2010 15:10:33 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100729131033.0E9EC2474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/29 15:10:33 Modified files: cm3/doc/notes/: todo.txt Log message: describe new sourcey distribution format From jkrell at elego.de Thu Jul 29 15:23:04 2010 From: jkrell at elego.de (Jay Krell) Date: Thu, 29 Jul 2010 15:23:04 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100729132304.8F8A42474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/29 15:23:04 Modified files: cm3/m3-sys/m3tests/src/p2/p240/: m3makefile Math.quake Log message: try doing less for cm3 -clean, maybe that is the rmrec problem (needs some Win32 portability, /dev/null vs. nul) From jkrell at elego.de Thu Jul 29 15:42:34 2010 From: jkrell at elego.de (Jay Krell) Date: Thu, 29 Jul 2010 15:42:34 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100729134234.B83652474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/29 15:42:34 Modified files: cm3/m3-sys/cminstall/src/config-no-install/: SPARC32_LINUX Log message: no symbols, just to conserve diskspace From jkrell at elego.de Thu Jul 29 15:44:44 2010 From: jkrell at elego.de (Jay Krell) Date: Thu, 29 Jul 2010 15:44:44 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100729134444.894572474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/29 15:44:44 Modified files: cm3/m3-sys/m3cc/src/: gnucc.common Log message: no symbols on SPARC32_LINUX to conserve diskspace From jkrell at elego.de Sat Jul 31 10:46:02 2010 From: jkrell at elego.de (Jay Krell) Date: Sat, 31 Jul 2010 10:46:02 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100731084606.EE088CC3B8@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/31 10:46:02 Modified files: cm3/: m3overrides Log message: adjust m3overrides file to avoid the useless warning from the frontend From jkrell at elego.de Sat Jul 31 10:48:48 2010 From: jkrell at elego.de (Jay Krell) Date: Sat, 31 Jul 2010 10:48:48 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100731084849.04D30CC3B8@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/31 10:48:48 Modified files: cm3/m3-sys/cm3/src/: M3Build.m3 Log message: Put back warning that we now avoid. I still don't see any point to this warning. From jkrell at elego.de Sat Jul 31 11:53:56 2010 From: jkrell at elego.de (Jay Krell) Date: Sat, 31 Jul 2010 11:53:56 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100731095356.AABEC2474019@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/31 11:53:56 Added files: cm3/m3-sys/m3tests/src/p2/p247/: Main.m3 m3makefile Log message: a larger test of just fs_rmrec From jkrell at elego.de Sat Jul 31 12:38:13 2010 From: jkrell at elego.de (Jay Krell) Date: Sat, 31 Jul 2010 12:38:13 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100731103814.0DCB6CC392@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/31 12:38:13 Modified files: cm3/m3-sys/m3tests/src/: m3makefile Log message: add test p248 for fs_rmrec From jkrell at elego.de Sat Jul 31 13:12:54 2010 From: jkrell at elego.de (Jay Krell) Date: Sat, 31 Jul 2010 13:12:54 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100731111308.34AD1CC3BE@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/31 13:12:54 Modified files: cm3/m3-libs/sysutils/src/: FSUtils.m3 Log message: replace RmRec with in implementation that only keeps one DIR*/Iterator open at a time. This is an experiment. The code is somewhat less efficient, producing more garbage, but also kind of small and nice to read. If this works, which I'm giving 50% odds, it still doesn't make sense. The opendir/readdir code I've seen is in fact reentrant. You can recurse while holding open the parent. They don't use a global or thread local, the use a buffer that is in the DIR*. Old version left for now under OldRmRec. With the debug printing removed. Both versions I believe are fairly racy, in that competing RmRecs will cause the other to fail. "Preflight" for existance doesn't cut and is in fact a significant deoptimization, This version is more efficient in that regard: don't call stat on children already determined to be file or directory. Still a wasted call at toplevel for existance. From jkrell at elego.de Sat Jul 31 13:35:48 2010 From: jkrell at elego.de (Jay Krell) Date: Sat, 31 Jul 2010 13:35:48 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100731113548.A0EAC2474019@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/31 13:35:48 Modified files: cm3/m3-libs/sysutils/src/: FSUtils.m3 Log message: Don't call stat so many extra times. Once is enough to determine exists vs. file vs. directory, and if we just enumerated it, we don't need to check again. Perhaps the three booleans should be an enum. From jkrell at elego.de Sat Jul 31 13:40:01 2010 From: jkrell at elego.de (Jay Krell) Date: Sat, 31 Jul 2010 13:40:01 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100731114001.A42472474019@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/31 13:40:01 Modified files: cm3/m3-libs/sysutils/src/: FSUtils.m3 Log message: Add more comments. This file has functions: Rm and RemoveFile Rmdir and RemoveDir They do the same things in the success paths and vary in that some raise exceptions and others call Process.Crash in the error paths. From jkrell at elego.de Sat Jul 31 13:47:22 2010 From: jkrell at elego.de (Jay Krell) Date: Sat, 31 Jul 2010 13:47:22 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100731114722.DE3D42474019@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/31 13:47:22 Modified files: cm3/m3-sys/m3cc/src/: m3makefile clean_marker.txt Log message: experiment: remove rm -rf hack and tickle clean marker