From jay.krell at cornell.edu Fri Jan 1 07:21:27 2016 From: jay.krell at cornell.edu (Jay K) Date: Fri, 1 Jan 2016 06:21:27 +0000 Subject: [M3devel] alloca/jmpbuf Message-ID: NT386 has some failure in the caltech-parser/parserlib/parserlib/test directory. I propose the following: Bring back the jmpbuf-size-known-by-frontend code, but with some "sprinkled conditions": Target.Alloca_jmpbuf: BOOLEAN in the compiler and something in the runtime, like RTExFrame.Alloca_jmpbuf:BOOLEAN. If this is/was/meant to be an option that lasted a while, then it'd also be a bit in RT0, so the runtime would make a runtime decision "informed by" the compiler. However this is really just hopefully just an experiment, and anyone switching the value would switch it in both places. It really can't be in only one place, though one could communicate it to the other -- such is the dependency/independency between the compiler and runtime. I tried to do a "git revert" and then edit, but git continues to elude me, so I'm going to do something more manual. Ok? Alternatives: 1) Just debug the current state. Esp. comparing MacOSX (which works) with NT386 2) Construct all I've said but don't commit it. ?- Jay From jay.krell at cornell.edu Sat Jan 2 02:04:22 2016 From: jay.krell at cornell.edu (Jay K) Date: Sat, 2 Jan 2016 01:04:22 +0000 Subject: [M3devel] alloca/jmpbuf In-Reply-To: References: Message-ID: ok -- putting back the old jmpbuf allocation does fix the problem on caltech-parser/parserlib/parserlib/test NT386. I had to do the undo very manually because git was confusing. Anyone have any idea of the exact problem? Otherwise I'll try to figure it out but it'll take a while. Maybe we have really good focused exception handling tests? I"ll look in m3tests. Thank you, ?- Jay ---------------------------------------- > From: jay.krell at cornell.edu > To: m3devel at elegosoft.com > Subject: alloca/jmpbuf > Date: Fri, 1 Jan 2016 06:21:27 +0000 > > NT386 has some failure in the caltech-parser/parserlib/parserlib/test directory. > > > I propose the following: > Bring back the jmpbuf-size-known-by-frontend code, but with some "sprinkled conditions": > > > Target.Alloca_jmpbuf: BOOLEAN in the compiler > and something in the runtime, like RTExFrame.Alloca_jmpbuf:BOOLEAN. > > > If this is/was/meant to be an option that lasted a while, then it'd also be a bit in RT0, so the runtime would make a runtime decision "informed by" the compiler. > > However this is really just hopefully just an experiment, and anyone switching the value would switch it in both places. > > > It really can't be in only one place, though one could communicate it to the other -- such is the dependency/independency between the compiler and runtime. > > > I tried to do a "git revert" and then edit, but git continues to elude me, so I'm going to do something more manual. > > Ok? > > Alternatives: > 1) Just debug the current state. > Esp. comparing MacOSX (which works) with NT386 > > 2) Construct all I've said but don't commit it. > > > - Jay From rodney_bates at lcwb.coop Sat Jan 2 22:03:27 2016 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Sat, 02 Jan 2016 15:03:27 -0600 Subject: [M3devel] M3CG loophole operator is not LOOPHOLE (but what?) In-Reply-To: <5671A6F7.6040805@lcwb.coop> References: <5669C154.90603@lcwb.coop> <1615931268.1036686.1450060846633.JavaMail.yahoo@mail.yahoo.com> <5671A6F7.6040805@lcwb.coop> Message-ID: <56883B1F.5050301@lcwb.coop> The further I get into this, the more worms crawl out. The only cm3 IR operators that change an operand size (without storing/refetching in memory) are widen and chop. The inserts and extracts work entirely within the same- sized word. But widen and chop are never produced by the front end, and the integrated and C back ends assert they don't happen. m3cc has code for them, but this will be entirely untested, and vetting it involves tracing through lots of gcc code. So I plan to redefine the misdocumented loophole operator to allow size changes among Int32/Word32/Int64/Word64, with shortening changes doing a chop and widening doing either zero-extend or sign-extend, consistent with the signedness of the result type. I think this will cover all the cases required by current places where loophole is emitted, which further implies the backends are all doing at least these, assuming there are sufficient test cases. This amounts only to correcting the documentation in M3CG_Ops.i3 m3llvm will then need to add these behaviors, and things should at least work as well as always. The many loophole-emitting places still need thorough review and documentation of their requirements. Some of them assume address is same size as native integer. Implementing chop and widen, using them for size changes, and changing loophole back to the same as LOOPHOLE is the right way, but involves a lot of work and testing, for small code changes. On 12/16/2015 12:01 PM, Rodney M. Bates wrote: > The issue I raised is not with the M3 LOOPHOLE builtin function. The compiler > currently implements it correctly, according to the language definition, as > Tony quoted. The front end verifies the size equality, as required by the > language, then emits an intermediate "loophole" operator, which will be same > size, and thus well-defined as equivalent to LOOPHOLE. (And also llvm bitcast, > which is now being used to translate the loophole operator in this case.) > > My issue is that there are 13 other places the front-end emits an internally > generated "loophole", and these (almost?) all can do so with unequal sizes. > Moreover, what should be done with the unequal sizes varies from place to place. > > It is possible that the "loophole" operator can be defined to do what is > correct in every case by a conditional rule based on the two types. I > need to do another pass through them to be sure. This may be the quickest > way to get the llvm backend working, but I think it is not good design. > It would be carefully tailored to just a specific set of uses of "loophole", > instead of making a reasonable abstraction out of" loophole". It would be > rather fragile and involve a lot of analysis on the full Cartesian product > of both supplier and client side cases of "loophole" to define and verify. > > The best way, IMO, is to fix each "loophole"-generating site to use other > operators, as appropriate. It is at these sites that it is known what > should be done in each case. I suspect existing intermediate operators > "widen", "insert_mn" and "extract_mn" are sufficient. Again, another pass > through the cases is indicated. The only pragmatic drawback to this is > that this requires considerable care and retesting to avoid breakage of > existing behavior. At worst, it risks inability to bootstrap the compiler. > I would prefer one change at a time, each tested by reboostrapping twice. > > > > On 12/13/2015 08:40 PM, Daniel Alejandro Benavides D. wrote: >> Hello: >> Excuse me if is wrong to say, but doesn't the specification of Modula-3 explicit about how the UNSAFE stuff is implementation-dependent, that is to say; "it's your decision how to implement it". >> Thanks in advance >> >> >> >> El Domingo 13 de diciembre de 2015 21:20, Jay escribi?: >> >> >> I know, but this pattern is pretty rare. >> >> - Jay >> >> On Dec 13, 2015, at 1:46 AM, Antony Hosking > wrote: >> >>> Excepting that in some cases taking the address may force the value into memory, when it could have stayed in a register. >>> The intent is to allow the backend to avoid that. >>> >>>> On 11 Dec 2015, at 5:53 PM, Jay K > wrote: >>>> >>>> The right thing to do, really, is take the address of a float, loophole >>>> that into an address of another type, and dereference that. >>>> Not in the backend, but in the Modula-3 code. >>>> >>> >> >> _______________________________________________ >> M3devel mailing list >> M3devel at elegosoft.com >> https://mail.elegosoft.com/cgi-bin/mailman/listinfo/m3devel >> >> >> >> >> _______________________________________________ >> M3devel mailing list >> M3devel at elegosoft.com >> https://mail.elegosoft.com/cgi-bin/mailman/listinfo/m3devel >> > -- Rodney Bates rodney.m.bates at acm.org From jay.krell at cornell.edu Sun Jan 3 01:11:41 2016 From: jay.krell at cornell.edu (Jay K) Date: Sun, 3 Jan 2016 00:11:41 +0000 Subject: [M3devel] M3CG loophole operator is not LOOPHOLE (but what?) In-Reply-To: <56883B1F.5050301@lcwb.coop> References: <5669C154.90603@lcwb.coop>, , , , <1615931268.1036686.1450060846633.JavaMail.yahoo@mail.yahoo.com>, <5671A6F7.6040805@lcwb.coop>, <56883B1F.5050301@lcwb.coop> Message-ID: > Some of them assume address is same size as native integer. This is correct and by-design. BYTESIZE(INTEGER) = BYTESIZE(REFANY) etc. (all pointers are the same size) In C and C++, for the vast majority of systems sizeof(size_t) = sizeof(char*) etc. (again, all pointers are the same size) VMS64 might be an exception. Might. However modern C and C++ offer intptr_t/uintptr_t for this: sizeof(intptr_t) == sizeof(char*) etc. (again, all pointers are the same size) It is popular to think sizeof(long) == sizeof(char*) but that is frequently incorrect, maybe half the time. (i.e. on Win64 and maybe VMS64) I'd still like to check/test what happens in the C and NT386 backends here, for loophole changing sizes, but not right now, sorry. The asserts about widen/chop not occurring are from me. You know, I fairly recently went through much/most/all of what you are doing (I hope all, but I fear much/most) -- implementing a new backend from scratch, and having to figure out precise meanings of things > > I would prefer one change at a time, each tested by reboostrapping twice. upgrade.py does the "twice" part builtin. - Jay > Date: Sat, 2 Jan 2016 15:03:27 -0600 > From: rodney_bates at lcwb.coop > To: m3devel at elegosoft.com > Subject: Re: [M3devel] M3CG loophole operator is not LOOPHOLE (but what?) > > The further I get into this, the more worms crawl out. The only cm3 IR > operators that change an operand size (without storing/refetching in memory) > are widen and chop. The inserts and extracts work entirely within the same- > sized word. But widen and chop are never produced by the front end, and > the integrated and C back ends assert they don't happen. m3cc has code > for them, but this will be entirely untested, and vetting it involves > tracing through lots of gcc code. > > So I plan to redefine the misdocumented loophole operator to allow size > changes among Int32/Word32/Int64/Word64, with shortening changes doing a > chop and widening doing either zero-extend or sign-extend, consistent with > the signedness of the result type. I think this will cover all the cases > required by current places where loophole is emitted, which further implies > the backends are all doing at least these, assuming there are sufficient > test cases. This amounts only to correcting the documentation in M3CG_Ops.i3 > > m3llvm will then need to add these behaviors, and things should at least work > as well as always. > > The many loophole-emitting places still need thorough review and documentation > of their requirements. Some of them assume address is same size as native > integer. > > Implementing chop and widen, using them for size changes, and changing loophole > back to the same as LOOPHOLE is the right way, but involves a lot of work and > testing, for small code changes. > > On 12/16/2015 12:01 PM, Rodney M. Bates wrote: > > The issue I raised is not with the M3 LOOPHOLE builtin function. The compiler > > currently implements it correctly, according to the language definition, as > > Tony quoted. The front end verifies the size equality, as required by the > > language, then emits an intermediate "loophole" operator, which will be same > > size, and thus well-defined as equivalent to LOOPHOLE. (And also llvm bitcast, > > which is now being used to translate the loophole operator in this case.) > > > > My issue is that there are 13 other places the front-end emits an internally > > generated "loophole", and these (almost?) all can do so with unequal sizes. > > Moreover, what should be done with the unequal sizes varies from place to place. > > > > It is possible that the "loophole" operator can be defined to do what is > > correct in every case by a conditional rule based on the two types. I > > need to do another pass through them to be sure. This may be the quickest > > way to get the llvm backend working, but I think it is not good design. > > It would be carefully tailored to just a specific set of uses of "loophole", > > instead of making a reasonable abstraction out of" loophole". It would be > > rather fragile and involve a lot of analysis on the full Cartesian product > > of both supplier and client side cases of "loophole" to define and verify. > > > > The best way, IMO, is to fix each "loophole"-generating site to use other > > operators, as appropriate. It is at these sites that it is known what > > should be done in each case. I suspect existing intermediate operators > > "widen", "insert_mn" and "extract_mn" are sufficient. Again, another pass > > through the cases is indicated. The only pragmatic drawback to this is > > that this requires considerable care and retesting to avoid breakage of > > existing behavior. At worst, it risks inability to bootstrap the compiler. > > I would prefer one change at a time, each tested by reboostrapping twice. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Tue Jan 5 11:44:22 2016 From: jay.krell at cornell.edu (Jay K) Date: Tue, 5 Jan 2016 10:44:22 +0000 Subject: [M3devel] install and C code Message-ID: I finally had a minor epiphany. Ignoring the C backend, to the extent that the system contains C code, "install" should actually recompile all the C code, using the user's intended compilation environment. This would clear up various incompatibilities that exist. i.e. with m3core.lib.sa and m3.lib.sa and the bootstrapping procedure. The 3.6 distribution did this. It actually distributed assembly source and C source and then did assembly/compilation/linking on the user machine. assembly is close to "binary", but this had advantages. It also solved the "origin" problem, back in the time before origin was widely supported -- i.e. link with full paths on Unix systems. I don't have the energy now, but we really could use a bit of a rewrite here. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Tue Jan 5 20:57:12 2016 From: jay.krell at cornell.edu (Jay K) Date: Tue, 5 Jan 2016 19:57:12 +0000 Subject: [M3devel] install and C code In-Reply-To: References: Message-ID: We do have the bootstrap archives, but they onlybuild cm3/mklib. We need to extend them to buildeverything, and either carry all of the Modula-3source, or carry everything as assembly source. I was thinking about that a while ago for a whileand couldn't decide, like, among cmake or automakeor makefiles for each directory. - Jay From: jay.krell at cornell.edu To: m3devel at elegosoft.com Date: Tue, 5 Jan 2016 10:44:22 +0000 Subject: [M3devel] install and C code I finally had a minor epiphany. Ignoring the C backend, to the extent that the system contains C code, "install" should actually recompile all the C code, using the user's intended compilation environment. This would clear up various incompatibilities that exist. i.e. with m3core.lib.sa and m3.lib.sa and the bootstrapping procedure. The 3.6 distribution did this. It actually distributed assembly source and C source and then did assembly/compilation/linking on the user machine. assembly is close to "binary", but this had advantages. It also solved the "origin" problem, back in the time before origin was widely supported -- i.e. link with full paths on Unix systems. I don't have the energy now, but we really could use a bit of a rewrite here. - Jay _______________________________________________ M3devel mailing list M3devel at elegosoft.com https://mail.elegosoft.com/cgi-bin/mailman/listinfo/m3devel -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Fri Jan 8 21:45:45 2016 From: jay.krell at cornell.edu (Jay K) Date: Fri, 8 Jan 2016 20:45:45 +0000 Subject: [M3devel] alloca/jmpbuf In-Reply-To: References: , Message-ID: I am no longer able to reproduce the problem.There have been some changes since but they don't seem relevant. Unless there are objections I'll put this back shortly -- just changingthe two booleans in Target.m3 and RTExFrame, and retaining the option to easily move back. Thank you, - Jay > From: jay.krell at cornell.edu > To: m3devel at elegosoft.com > Subject: RE: alloca/jmpbuf > Date: Sat, 2 Jan 2016 01:04:22 +0000 > > ok -- putting back the old jmpbuf allocation does fix the problem on caltech-parser/parserlib/parserlib/test NT386. > I had to do the undo very manually because git was confusing. > > Anyone have any idea of the exact problem? > > Otherwise I'll try to figure it out but it'll take a while. > > Maybe we have really good focused exception handling tests? I"ll look in m3tests. > > Thank you, > - Jay > > > ---------------------------------------- > > From: jay.krell at cornell.edu > > To: m3devel at elegosoft.com > > Subject: alloca/jmpbuf > > Date: Fri, 1 Jan 2016 06:21:27 +0000 > > > > NT386 has some failure in the caltech-parser/parserlib/parserlib/test directory. > > > > > > I propose the following: > > Bring back the jmpbuf-size-known-by-frontend code, but with some "sprinkled conditions": > > > > > > Target.Alloca_jmpbuf: BOOLEAN in the compiler > > and something in the runtime, like RTExFrame.Alloca_jmpbuf:BOOLEAN. > > > > > > If this is/was/meant to be an option that lasted a while, then it'd also be a bit in RT0, so the runtime would make a runtime decision "informed by" the compiler. > > > > However this is really just hopefully just an experiment, and anyone switching the value would switch it in both places. > > > > > > It really can't be in only one place, though one could communicate it to the other -- such is the dependency/independency between the compiler and runtime. > > > > > > I tried to do a "git revert" and then edit, but git continues to elude me, so I'm going to do something more manual. > > > > Ok? > > > > Alternatives: > > 1) Just debug the current state. > > Esp. comparing MacOSX (which works) with NT386 > > > > 2) Construct all I've said but don't commit it. > > > > > > - Jay > -------------- next part -------------- An HTML attachment was scrubbed... URL: From peter.mckinna at gmail.com Mon Jan 18 05:01:30 2016 From: peter.mckinna at gmail.com (Peter McKinna) Date: Mon, 18 Jan 2016 15:01:30 +1100 Subject: [M3devel] compiler bug Message-ID: This is unusual. PROCEDURE Test() = VAR x,m := 1; BEGIN x := Word.Extract(x,m,n); END Test; induces new source -> compiling test.m3 "../src/test.m3", line 190: undefined (n) *** *** runtime error: *** An enumeration or subrange value was out of range. *** file "../AMD64_LINUX/WordExtract.m3 => ../src/builtinWord/Extract.mg", l ine 120 *** Aborted (core dumped) fix the undefined n and it compiles ok. Any takers to fix this? Should have a bug tracking system really. Peter -------------- next part -------------- An HTML attachment was scrubbed... URL: From rodney_bates at lcwb.coop Tue Jan 19 19:09:38 2016 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Tue, 19 Jan 2016 12:09:38 -0600 Subject: [M3devel] compiler bug In-Reply-To: References: Message-ID: <569E7BE2.3000603@lcwb.coop> I have a simple fix that made this RT crash go away, but now I can't rebuild the libraries/compiler from all source, with different symptoms for different methods. On 01/17/2016 10:01 PM, Peter McKinna wrote: > This is unusual. > > PROCEDURE Test() = > VAR x,m := 1; > BEGIN > x := Word.Extract(x,m,n); > END Test; > > induces > > new source -> compiling test.m3 > "../src/test.m3", line 190: undefined (n) > > > *** > *** runtime error: > *** An enumeration or subrange value was out of range. > *** file "../AMD64_LINUX/WordExtract.m3 => ../src/builtinWord/Extract.mg", l > ine 120 > *** > > Aborted (core dumped) > > > fix the undefined n and it compiles ok. > > Any takers to fix this? > > Should have a bug tracking system really. > > Peter > > > > _______________________________________________ > M3devel mailing list > M3devel at elegosoft.com > https://mail.elegosoft.com/cgi-bin/mailman/listinfo/m3devel > -- Rodney Bates rodney.m.bates at acm.org From rodney_bates at lcwb.coop Tue Jan 19 21:13:40 2016 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Tue, 19 Jan 2016 14:13:40 -0600 Subject: [M3devel] compiler bug In-Reply-To: <90215E6A-DD51-4671-81DC-120422B83B8F@purdue.edu> References: <569E7BE2.3000603@lcwb.coop> <90215E6A-DD51-4671-81DC-120422B83B8F@purdue.edu> Message-ID: <569E98F4.7070709@lcwb.coop> That's almost what I did, except as below. Since i is passed to a CARDINAL in the line below, the i=zero case would not suffer the RT fault. It would give 0,0 as bounds of the being-compiled Extract, which seems right to me. On 01/19/2016 12:36 PM, Hosking, Antony L wrote: > Can you try this version of Extract.GetBounds? > > PROCEDURE GetBounds (ce: CallExpr.T; VAR min, max: Target.Int) = > VAR min_bits, max_bits: Target.Int; i: INTEGER; > BEGIN > Expr.GetBounds (ce.args[2], min_bits, max_bits); > IF TInt.ToInt (max_bits, i) AND i > 0 AND i < Word_types[rep].size THEN ..............................AND 0 <= i ................................. > IF NOT TWord.Extract (TInt.MOne, 0, i, max) THEN > EVAL Type.GetBounds (T, min, max); > END; > min := TInt.Zero; > ELSE > (* possible that we'll preserve all bits *) > Expr.GetBounds (ce.args[0], min, max); > END; > END GetBounds; > >> On 19 Jan 2016, at 1:09 PM, Rodney M. Bates wrote: >> >> I have a simple fix that made this RT crash go away, but now I can't rebuild >> the libraries/compiler from all source, with different symptoms for different >> methods. >> >> On 01/17/2016 10:01 PM, Peter McKinna wrote: >>> This is unusual. >>> >>> PROCEDURE Test() = >>> VAR x,m := 1; >>> BEGIN >>> x := Word.Extract(x,m,n); >>> END Test; >>> >>> induces >>> >>> new source -> compiling test.m3 >>> "../src/test.m3", line 190: undefined (n) >>> >>> >>> *** >>> *** runtime error: >>> *** An enumeration or subrange value was out of range. >>> *** file "../AMD64_LINUX/WordExtract.m3 => ../src/builtinWord/Extract.mg", l >>> ine 120 >>> *** >>> >>> Aborted (core dumped) >>> >>> >>> fix the undefined n and it compiles ok. >>> >>> Any takers to fix this? >>> >>> Should have a bug tracking system really. >>> >>> Peter >>> >>> >>> >>> _______________________________________________ >>> M3devel mailing list >>> M3devel at elegosoft.com >>> https://mail.elegosoft.com/cgi-bin/mailman/listinfo/m3devel >>> >> >> -- >> Rodney Bates >> rodney.m.bates at acm.org >> _______________________________________________ >> M3devel mailing list >> M3devel at elegosoft.com >> https://mail.elegosoft.com/cgi-bin/mailman/listinfo/m3devel > > -- Rodney Bates rodney.m.bates at acm.org From rodney_bates at lcwb.coop Tue Jan 19 22:32:49 2016 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Tue, 19 Jan 2016 15:32:49 -0600 Subject: [M3devel] compiler bug In-Reply-To: <6F7EC87B-E386-433F-8D73-429097CBC802@purdue.edu> References: <569E7BE2.3000603@lcwb.coop> <90215E6A-DD51-4671-81DC-120422B83B8F@purdue.edu> <569E98F4.7070709@lcwb.coop> <6F7EC87B-E386-433F-8D73-429097CBC802@purdue.edu> Message-ID: <569EAB81.5000001@lcwb.coop> On 01/19/2016 02:21 PM, Hosking, Antony L wrote: > That should work. What errors do you see with that change? > The out of range compiler crash goes away. The "undefined (n)" error messages remains, as it should. The problem I am having now, probably unrelated to this change, is, when I try to rebuild everything to test that it didn't break something elsewhere, I got other build failures. I plan to post these, but there are so many different build procedures I have tried, it will take some work to distill it enough for a comprehensible post. >> On 19 Jan 2016, at 3:13 PM, Rodney M. Bates > wrote: >> >> That's almost what I did, except as below. Since i is passed to a >> CARDINAL in the line below, the i=zero case would not suffer the RT >> fault. It would give 0,0 as bounds of the being-compiled Extract, >> which seems right to me. >> >> On 01/19/2016 12:36 PM, Hosking, Antony L wrote: >>> Can you try this version of Extract.GetBounds? >>> >>> PROCEDURE GetBounds (ce: CallExpr.T; VAR min, max: Target.Int) = >>> VAR min_bits, max_bits: Target.Int; i: INTEGER; >>> BEGIN >>> Expr.GetBounds (ce.args[2], min_bits, max_bits); >>> IF TInt.ToInt (max_bits, i) AND i > 0 AND i < Word_types[rep].size THEN >> ..............................AND 0 <= i ................................. >>> IF NOT TWord.Extract (TInt.MOne, 0, i, max) THEN >>> EVAL Type.GetBounds (T, min, max); >>> END; >>> min := TInt.Zero; >>> ELSE >>> (* possible that we'll preserve all bits *) >>> Expr.GetBounds (ce.args[0], min, max); >>> END; >>> END GetBounds; >>> >>>> On 19 Jan 2016, at 1:09 PM, Rodney M. Bates > wrote: >>>> >>>> I have a simple fix that made this RT crash go away, but now I can't rebuild >>>> the libraries/compiler from all source, with different symptoms for different >>>> methods. >>>> >>>> On 01/17/2016 10:01 PM, Peter McKinna wrote: >>>>> This is unusual. >>>>> >>>>> PROCEDURE Test() = >>>>> VAR x,m := 1; >>>>> BEGIN >>>>> x := Word.Extract(x,m,n); >>>>> END Test; >>>>> >>>>> induces >>>>> >>>>> new source -> compiling test.m3 >>>>> "../src/test.m3", line 190: undefined (n) >>>>> >>>>> >>>>> *** >>>>> *** runtime error: >>>>> *** An enumeration or subrange value was out of range. >>>>> *** file "../AMD64_LINUX/WordExtract.m3 => ../src/builtinWord/Extract.mg", l >>>>> ine 120 >>>>> *** >>>>> >>>>> Aborted (core dumped) >>>>> >>>>> >>>>> fix the undefined n and it compiles ok. >>>>> >>>>> Any takers to fix this? >>>>> >>>>> Should have a bug tracking system really. >>>>> >>>>> Peter >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> M3devel mailing list >>>>> M3devel at elegosoft.com >>>>> https://mail.elegosoft.com/cgi-bin/mailman/listinfo/m3devel >>>>> >>>> >>>> -- >>>> Rodney Bates >>>> rodney.m.bates at acm.org >>>> _______________________________________________ >>>> M3devel mailing list >>>> M3devel at elegosoft.com >>>> https://mail.elegosoft.com/cgi-bin/mailman/listinfo/m3devel >>> >>> >> >> -- >> Rodney Bates >> rodney.m.bates at acm.org > -- Rodney Bates rodney.m.bates at acm.org From rodney_bates at lcwb.coop Wed Jan 20 23:45:02 2016 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Wed, 20 Jan 2016 16:45:02 -0600 Subject: [M3devel] compiler bug In-Reply-To: <569E7BE2.3000603@lcwb.coop> References: <569E7BE2.3000603@lcwb.coop> Message-ID: <56A00DEE.1060804@lcwb.coop> If I try to compile with an old cm3 executable named cm3-5.8.6, I get these errors trying to compile the cm3 executable (and others too, e.g. mklib): ------------------------------------------------------------------------------ -> linking cm3 _m3main.c:7:11: error: ?argc? was not declared in this scope int main (argc, argv, envp) ^ _m3main.c:7:17: error: ?argv? was not declared in this scope int main (argc, argv, envp) ^ _m3main.c:7:23: error: ?envp? was not declared in this scope int main (argc, argv, envp) ^ _m3main.c:7:27: error: expression list treated as compound expression in initializer [-fpermissive] int main (argc, argv, envp) ^ _m3main.c:8:1: error: expected ?,? or ?;? before ?int? int argc; ^ _m3main.c:11:1: error: expected unqualified-id before ?{? token { ^ ------------------------------------------------------------------------------ This happens regardless of whether I use upgrade.py, upgrade.sh, do-cm3-front.sh, or cm3 directly in the cm3 package. If I use a cm3 executable compiled on 2015-8-28, compiling sysutils, I can compile the libraries and compiler, but when I try to use them to recompile, I get: -------------------------------------------------------------------------------- - -> archiving libsysutils.a *** *** runtime error: *** An array subscript was out of range. *** file "../src/M3Build.m3", line 1719 *** Aborted (core dumped) *** execution of [, ] failed *** ------------------------------------------------------------------------------- This also happens when I use a saved executable dated 2015-10-18 On 01/19/2016 12:09 PM, Rodney M. Bates wrote: > I have a simple fix that made this RT crash go away, but now I can't rebuild > the libraries/compiler from all source, with different symptoms for different > methods. > > On 01/17/2016 10:01 PM, Peter McKinna wrote: >> This is unusual. >> >> PROCEDURE Test() = >> VAR x,m := 1; >> BEGIN >> x := Word.Extract(x,m,n); >> END Test; >> >> induces >> >> new source -> compiling test.m3 >> "../src/test.m3", line 190: undefined (n) >> >> >> *** >> *** runtime error: >> *** An enumeration or subrange value was out of range. >> *** file "../AMD64_LINUX/WordExtract.m3 => ../src/builtinWord/Extract.mg", l >> ine 120 >> *** >> >> Aborted (core dumped) >> >> >> fix the undefined n and it compiles ok. >> >> Any takers to fix this? >> >> Should have a bug tracking system really. >> >> Peter >> >> >> >> _______________________________________________ >> M3devel mailing list >> M3devel at elegosoft.com >> https://mail.elegosoft.com/cgi-bin/mailman/listinfo/m3devel >> > -- Rodney Bates rodney.m.bates at acm.org From rodney_bates at lcwb.coop Thu Jan 21 17:19:39 2016 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Thu, 21 Jan 2016 10:19:39 -0600 Subject: [M3devel] compiler bug In-Reply-To: <56A00DEE.1060804@lcwb.coop> References: <569E7BE2.3000603@lcwb.coop> <56A00DEE.1060804@lcwb.coop> Message-ID: <56A1051B.2080201@lcwb.coop> On 01/20/2016 04:45 PM, Rodney M. Bates wrote: > If I try to compile with an old cm3 executable named cm3-5.8.6, I get these > errors trying to compile the cm3 executable (and others too, e.g. mklib): > ------------------------------------------------------------------------------ > -> linking cm3 > _m3main.c:7:11: error: ?argc? was not declared in this scope > int main (argc, argv, envp) > ^ > _m3main.c:7:17: error: ?argv? was not declared in this scope > int main (argc, argv, envp) > ^ > _m3main.c:7:23: error: ?envp? was not declared in this scope > int main (argc, argv, envp) > ^ > _m3main.c:7:27: error: expression list treated as compound expression in initializer [-fpermissive] > int main (argc, argv, envp) > ^ > _m3main.c:8:1: error: expected ?,? or ?;? before ?int? > int argc; > ^ > _m3main.c:11:1: error: expected unqualified-id before ?{? token > { > ^ > > ------------------------------------------------------------------------------ > > This happens regardless of whether I use upgrade.py, upgrade.sh, do-cm3-front.sh, > or cm3 directly in the cm3 package. > > If I use a cm3 executable compiled on 2015-8-28, compiling sysutils, I can compile > the libraries and compiler, but when I try to use them to recompile, I get: > > -------------------------------------------------------------------------------- > - -> archiving libsysutils.a > > > *** > *** runtime error: > *** An array subscript was out of range. > *** file "../src/M3Build.m3", line 1719 > *** > > Aborted (core dumped) > *** execution of [, ] failed *** > > ------------------------------------------------------------------------------- > > This also happens when I use a saved executable dated 2015-10-18 Attempting to diagnose this problem, I find it has gone away. Don't know what changed. I used the same cm3 and cm3cg executables, same source code, and did realcleans both times, but I suppose there must be places for local state to hide. Anyway, now it rebuilds itself and converges to identical-sized cm3 executables after 3 rebuild cycles. > > > > > On 01/19/2016 12:09 PM, Rodney M. Bates wrote: >> I have a simple fix that made this RT crash go away, but now I can't rebuild >> the libraries/compiler from all source, with different symptoms for different >> methods. >> >> On 01/17/2016 10:01 PM, Peter McKinna wrote: >>> This is unusual. >>> >>> PROCEDURE Test() = >>> VAR x,m := 1; >>> BEGIN >>> x := Word.Extract(x,m,n); >>> END Test; >>> >>> induces >>> >>> new source -> compiling test.m3 >>> "../src/test.m3", line 190: undefined (n) >>> >>> >>> *** >>> *** runtime error: >>> *** An enumeration or subrange value was out of range. >>> *** file "../AMD64_LINUX/WordExtract.m3 => ../src/builtinWord/Extract.mg", l >>> ine 120 >>> *** >>> >>> Aborted (core dumped) >>> >>> >>> fix the undefined n and it compiles ok. >>> >>> Any takers to fix this? >>> >>> Should have a bug tracking system really. >>> >>> Peter >>> >>> >>> >>> _______________________________________________ >>> M3devel mailing list >>> M3devel at elegosoft.com >>> https://mail.elegosoft.com/cgi-bin/mailman/listinfo/m3devel >>> >> > -- Rodney Bates rodney.m.bates at acm.org From jay.krell at cornell.edu Fri Jan 1 07:21:27 2016 From: jay.krell at cornell.edu (Jay K) Date: Fri, 1 Jan 2016 06:21:27 +0000 Subject: [M3devel] alloca/jmpbuf Message-ID: NT386 has some failure in the caltech-parser/parserlib/parserlib/test directory. I propose the following: Bring back the jmpbuf-size-known-by-frontend code, but with some "sprinkled conditions": Target.Alloca_jmpbuf: BOOLEAN in the compiler and something in the runtime, like RTExFrame.Alloca_jmpbuf:BOOLEAN. If this is/was/meant to be an option that lasted a while, then it'd also be a bit in RT0, so the runtime would make a runtime decision "informed by" the compiler. However this is really just hopefully just an experiment, and anyone switching the value would switch it in both places. It really can't be in only one place, though one could communicate it to the other -- such is the dependency/independency between the compiler and runtime. I tried to do a "git revert" and then edit, but git continues to elude me, so I'm going to do something more manual. Ok? Alternatives: 1) Just debug the current state. Esp. comparing MacOSX (which works) with NT386 2) Construct all I've said but don't commit it. ?- Jay From jay.krell at cornell.edu Sat Jan 2 02:04:22 2016 From: jay.krell at cornell.edu (Jay K) Date: Sat, 2 Jan 2016 01:04:22 +0000 Subject: [M3devel] alloca/jmpbuf In-Reply-To: References: Message-ID: ok -- putting back the old jmpbuf allocation does fix the problem on caltech-parser/parserlib/parserlib/test NT386. I had to do the undo very manually because git was confusing. Anyone have any idea of the exact problem? Otherwise I'll try to figure it out but it'll take a while. Maybe we have really good focused exception handling tests? I"ll look in m3tests. Thank you, ?- Jay ---------------------------------------- > From: jay.krell at cornell.edu > To: m3devel at elegosoft.com > Subject: alloca/jmpbuf > Date: Fri, 1 Jan 2016 06:21:27 +0000 > > NT386 has some failure in the caltech-parser/parserlib/parserlib/test directory. > > > I propose the following: > Bring back the jmpbuf-size-known-by-frontend code, but with some "sprinkled conditions": > > > Target.Alloca_jmpbuf: BOOLEAN in the compiler > and something in the runtime, like RTExFrame.Alloca_jmpbuf:BOOLEAN. > > > If this is/was/meant to be an option that lasted a while, then it'd also be a bit in RT0, so the runtime would make a runtime decision "informed by" the compiler. > > However this is really just hopefully just an experiment, and anyone switching the value would switch it in both places. > > > It really can't be in only one place, though one could communicate it to the other -- such is the dependency/independency between the compiler and runtime. > > > I tried to do a "git revert" and then edit, but git continues to elude me, so I'm going to do something more manual. > > Ok? > > Alternatives: > 1) Just debug the current state. > Esp. comparing MacOSX (which works) with NT386 > > 2) Construct all I've said but don't commit it. > > > - Jay From rodney_bates at lcwb.coop Sat Jan 2 22:03:27 2016 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Sat, 02 Jan 2016 15:03:27 -0600 Subject: [M3devel] M3CG loophole operator is not LOOPHOLE (but what?) In-Reply-To: <5671A6F7.6040805@lcwb.coop> References: <5669C154.90603@lcwb.coop> <1615931268.1036686.1450060846633.JavaMail.yahoo@mail.yahoo.com> <5671A6F7.6040805@lcwb.coop> Message-ID: <56883B1F.5050301@lcwb.coop> The further I get into this, the more worms crawl out. The only cm3 IR operators that change an operand size (without storing/refetching in memory) are widen and chop. The inserts and extracts work entirely within the same- sized word. But widen and chop are never produced by the front end, and the integrated and C back ends assert they don't happen. m3cc has code for them, but this will be entirely untested, and vetting it involves tracing through lots of gcc code. So I plan to redefine the misdocumented loophole operator to allow size changes among Int32/Word32/Int64/Word64, with shortening changes doing a chop and widening doing either zero-extend or sign-extend, consistent with the signedness of the result type. I think this will cover all the cases required by current places where loophole is emitted, which further implies the backends are all doing at least these, assuming there are sufficient test cases. This amounts only to correcting the documentation in M3CG_Ops.i3 m3llvm will then need to add these behaviors, and things should at least work as well as always. The many loophole-emitting places still need thorough review and documentation of their requirements. Some of them assume address is same size as native integer. Implementing chop and widen, using them for size changes, and changing loophole back to the same as LOOPHOLE is the right way, but involves a lot of work and testing, for small code changes. On 12/16/2015 12:01 PM, Rodney M. Bates wrote: > The issue I raised is not with the M3 LOOPHOLE builtin function. The compiler > currently implements it correctly, according to the language definition, as > Tony quoted. The front end verifies the size equality, as required by the > language, then emits an intermediate "loophole" operator, which will be same > size, and thus well-defined as equivalent to LOOPHOLE. (And also llvm bitcast, > which is now being used to translate the loophole operator in this case.) > > My issue is that there are 13 other places the front-end emits an internally > generated "loophole", and these (almost?) all can do so with unequal sizes. > Moreover, what should be done with the unequal sizes varies from place to place. > > It is possible that the "loophole" operator can be defined to do what is > correct in every case by a conditional rule based on the two types. I > need to do another pass through them to be sure. This may be the quickest > way to get the llvm backend working, but I think it is not good design. > It would be carefully tailored to just a specific set of uses of "loophole", > instead of making a reasonable abstraction out of" loophole". It would be > rather fragile and involve a lot of analysis on the full Cartesian product > of both supplier and client side cases of "loophole" to define and verify. > > The best way, IMO, is to fix each "loophole"-generating site to use other > operators, as appropriate. It is at these sites that it is known what > should be done in each case. I suspect existing intermediate operators > "widen", "insert_mn" and "extract_mn" are sufficient. Again, another pass > through the cases is indicated. The only pragmatic drawback to this is > that this requires considerable care and retesting to avoid breakage of > existing behavior. At worst, it risks inability to bootstrap the compiler. > I would prefer one change at a time, each tested by reboostrapping twice. > > > > On 12/13/2015 08:40 PM, Daniel Alejandro Benavides D. wrote: >> Hello: >> Excuse me if is wrong to say, but doesn't the specification of Modula-3 explicit about how the UNSAFE stuff is implementation-dependent, that is to say; "it's your decision how to implement it". >> Thanks in advance >> >> >> >> El Domingo 13 de diciembre de 2015 21:20, Jay escribi?: >> >> >> I know, but this pattern is pretty rare. >> >> - Jay >> >> On Dec 13, 2015, at 1:46 AM, Antony Hosking > wrote: >> >>> Excepting that in some cases taking the address may force the value into memory, when it could have stayed in a register. >>> The intent is to allow the backend to avoid that. >>> >>>> On 11 Dec 2015, at 5:53 PM, Jay K > wrote: >>>> >>>> The right thing to do, really, is take the address of a float, loophole >>>> that into an address of another type, and dereference that. >>>> Not in the backend, but in the Modula-3 code. >>>> >>> >> >> _______________________________________________ >> M3devel mailing list >> M3devel at elegosoft.com >> https://mail.elegosoft.com/cgi-bin/mailman/listinfo/m3devel >> >> >> >> >> _______________________________________________ >> M3devel mailing list >> M3devel at elegosoft.com >> https://mail.elegosoft.com/cgi-bin/mailman/listinfo/m3devel >> > -- Rodney Bates rodney.m.bates at acm.org From jay.krell at cornell.edu Sun Jan 3 01:11:41 2016 From: jay.krell at cornell.edu (Jay K) Date: Sun, 3 Jan 2016 00:11:41 +0000 Subject: [M3devel] M3CG loophole operator is not LOOPHOLE (but what?) In-Reply-To: <56883B1F.5050301@lcwb.coop> References: <5669C154.90603@lcwb.coop>, , , , <1615931268.1036686.1450060846633.JavaMail.yahoo@mail.yahoo.com>, <5671A6F7.6040805@lcwb.coop>, <56883B1F.5050301@lcwb.coop> Message-ID: > Some of them assume address is same size as native integer. This is correct and by-design. BYTESIZE(INTEGER) = BYTESIZE(REFANY) etc. (all pointers are the same size) In C and C++, for the vast majority of systems sizeof(size_t) = sizeof(char*) etc. (again, all pointers are the same size) VMS64 might be an exception. Might. However modern C and C++ offer intptr_t/uintptr_t for this: sizeof(intptr_t) == sizeof(char*) etc. (again, all pointers are the same size) It is popular to think sizeof(long) == sizeof(char*) but that is frequently incorrect, maybe half the time. (i.e. on Win64 and maybe VMS64) I'd still like to check/test what happens in the C and NT386 backends here, for loophole changing sizes, but not right now, sorry. The asserts about widen/chop not occurring are from me. You know, I fairly recently went through much/most/all of what you are doing (I hope all, but I fear much/most) -- implementing a new backend from scratch, and having to figure out precise meanings of things > > I would prefer one change at a time, each tested by reboostrapping twice. upgrade.py does the "twice" part builtin. - Jay > Date: Sat, 2 Jan 2016 15:03:27 -0600 > From: rodney_bates at lcwb.coop > To: m3devel at elegosoft.com > Subject: Re: [M3devel] M3CG loophole operator is not LOOPHOLE (but what?) > > The further I get into this, the more worms crawl out. The only cm3 IR > operators that change an operand size (without storing/refetching in memory) > are widen and chop. The inserts and extracts work entirely within the same- > sized word. But widen and chop are never produced by the front end, and > the integrated and C back ends assert they don't happen. m3cc has code > for them, but this will be entirely untested, and vetting it involves > tracing through lots of gcc code. > > So I plan to redefine the misdocumented loophole operator to allow size > changes among Int32/Word32/Int64/Word64, with shortening changes doing a > chop and widening doing either zero-extend or sign-extend, consistent with > the signedness of the result type. I think this will cover all the cases > required by current places where loophole is emitted, which further implies > the backends are all doing at least these, assuming there are sufficient > test cases. This amounts only to correcting the documentation in M3CG_Ops.i3 > > m3llvm will then need to add these behaviors, and things should at least work > as well as always. > > The many loophole-emitting places still need thorough review and documentation > of their requirements. Some of them assume address is same size as native > integer. > > Implementing chop and widen, using them for size changes, and changing loophole > back to the same as LOOPHOLE is the right way, but involves a lot of work and > testing, for small code changes. > > On 12/16/2015 12:01 PM, Rodney M. Bates wrote: > > The issue I raised is not with the M3 LOOPHOLE builtin function. The compiler > > currently implements it correctly, according to the language definition, as > > Tony quoted. The front end verifies the size equality, as required by the > > language, then emits an intermediate "loophole" operator, which will be same > > size, and thus well-defined as equivalent to LOOPHOLE. (And also llvm bitcast, > > which is now being used to translate the loophole operator in this case.) > > > > My issue is that there are 13 other places the front-end emits an internally > > generated "loophole", and these (almost?) all can do so with unequal sizes. > > Moreover, what should be done with the unequal sizes varies from place to place. > > > > It is possible that the "loophole" operator can be defined to do what is > > correct in every case by a conditional rule based on the two types. I > > need to do another pass through them to be sure. This may be the quickest > > way to get the llvm backend working, but I think it is not good design. > > It would be carefully tailored to just a specific set of uses of "loophole", > > instead of making a reasonable abstraction out of" loophole". It would be > > rather fragile and involve a lot of analysis on the full Cartesian product > > of both supplier and client side cases of "loophole" to define and verify. > > > > The best way, IMO, is to fix each "loophole"-generating site to use other > > operators, as appropriate. It is at these sites that it is known what > > should be done in each case. I suspect existing intermediate operators > > "widen", "insert_mn" and "extract_mn" are sufficient. Again, another pass > > through the cases is indicated. The only pragmatic drawback to this is > > that this requires considerable care and retesting to avoid breakage of > > existing behavior. At worst, it risks inability to bootstrap the compiler. > > I would prefer one change at a time, each tested by reboostrapping twice. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Tue Jan 5 11:44:22 2016 From: jay.krell at cornell.edu (Jay K) Date: Tue, 5 Jan 2016 10:44:22 +0000 Subject: [M3devel] install and C code Message-ID: I finally had a minor epiphany. Ignoring the C backend, to the extent that the system contains C code, "install" should actually recompile all the C code, using the user's intended compilation environment. This would clear up various incompatibilities that exist. i.e. with m3core.lib.sa and m3.lib.sa and the bootstrapping procedure. The 3.6 distribution did this. It actually distributed assembly source and C source and then did assembly/compilation/linking on the user machine. assembly is close to "binary", but this had advantages. It also solved the "origin" problem, back in the time before origin was widely supported -- i.e. link with full paths on Unix systems. I don't have the energy now, but we really could use a bit of a rewrite here. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Tue Jan 5 20:57:12 2016 From: jay.krell at cornell.edu (Jay K) Date: Tue, 5 Jan 2016 19:57:12 +0000 Subject: [M3devel] install and C code In-Reply-To: References: Message-ID: We do have the bootstrap archives, but they onlybuild cm3/mklib. We need to extend them to buildeverything, and either carry all of the Modula-3source, or carry everything as assembly source. I was thinking about that a while ago for a whileand couldn't decide, like, among cmake or automakeor makefiles for each directory. - Jay From: jay.krell at cornell.edu To: m3devel at elegosoft.com Date: Tue, 5 Jan 2016 10:44:22 +0000 Subject: [M3devel] install and C code I finally had a minor epiphany. Ignoring the C backend, to the extent that the system contains C code, "install" should actually recompile all the C code, using the user's intended compilation environment. This would clear up various incompatibilities that exist. i.e. with m3core.lib.sa and m3.lib.sa and the bootstrapping procedure. The 3.6 distribution did this. It actually distributed assembly source and C source and then did assembly/compilation/linking on the user machine. assembly is close to "binary", but this had advantages. It also solved the "origin" problem, back in the time before origin was widely supported -- i.e. link with full paths on Unix systems. I don't have the energy now, but we really could use a bit of a rewrite here. - Jay _______________________________________________ M3devel mailing list M3devel at elegosoft.com https://mail.elegosoft.com/cgi-bin/mailman/listinfo/m3devel -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Fri Jan 8 21:45:45 2016 From: jay.krell at cornell.edu (Jay K) Date: Fri, 8 Jan 2016 20:45:45 +0000 Subject: [M3devel] alloca/jmpbuf In-Reply-To: References: , Message-ID: I am no longer able to reproduce the problem.There have been some changes since but they don't seem relevant. Unless there are objections I'll put this back shortly -- just changingthe two booleans in Target.m3 and RTExFrame, and retaining the option to easily move back. Thank you, - Jay > From: jay.krell at cornell.edu > To: m3devel at elegosoft.com > Subject: RE: alloca/jmpbuf > Date: Sat, 2 Jan 2016 01:04:22 +0000 > > ok -- putting back the old jmpbuf allocation does fix the problem on caltech-parser/parserlib/parserlib/test NT386. > I had to do the undo very manually because git was confusing. > > Anyone have any idea of the exact problem? > > Otherwise I'll try to figure it out but it'll take a while. > > Maybe we have really good focused exception handling tests? I"ll look in m3tests. > > Thank you, > - Jay > > > ---------------------------------------- > > From: jay.krell at cornell.edu > > To: m3devel at elegosoft.com > > Subject: alloca/jmpbuf > > Date: Fri, 1 Jan 2016 06:21:27 +0000 > > > > NT386 has some failure in the caltech-parser/parserlib/parserlib/test directory. > > > > > > I propose the following: > > Bring back the jmpbuf-size-known-by-frontend code, but with some "sprinkled conditions": > > > > > > Target.Alloca_jmpbuf: BOOLEAN in the compiler > > and something in the runtime, like RTExFrame.Alloca_jmpbuf:BOOLEAN. > > > > > > If this is/was/meant to be an option that lasted a while, then it'd also be a bit in RT0, so the runtime would make a runtime decision "informed by" the compiler. > > > > However this is really just hopefully just an experiment, and anyone switching the value would switch it in both places. > > > > > > It really can't be in only one place, though one could communicate it to the other -- such is the dependency/independency between the compiler and runtime. > > > > > > I tried to do a "git revert" and then edit, but git continues to elude me, so I'm going to do something more manual. > > > > Ok? > > > > Alternatives: > > 1) Just debug the current state. > > Esp. comparing MacOSX (which works) with NT386 > > > > 2) Construct all I've said but don't commit it. > > > > > > - Jay > -------------- next part -------------- An HTML attachment was scrubbed... URL: From peter.mckinna at gmail.com Mon Jan 18 05:01:30 2016 From: peter.mckinna at gmail.com (Peter McKinna) Date: Mon, 18 Jan 2016 15:01:30 +1100 Subject: [M3devel] compiler bug Message-ID: This is unusual. PROCEDURE Test() = VAR x,m := 1; BEGIN x := Word.Extract(x,m,n); END Test; induces new source -> compiling test.m3 "../src/test.m3", line 190: undefined (n) *** *** runtime error: *** An enumeration or subrange value was out of range. *** file "../AMD64_LINUX/WordExtract.m3 => ../src/builtinWord/Extract.mg", l ine 120 *** Aborted (core dumped) fix the undefined n and it compiles ok. Any takers to fix this? Should have a bug tracking system really. Peter -------------- next part -------------- An HTML attachment was scrubbed... URL: From rodney_bates at lcwb.coop Tue Jan 19 19:09:38 2016 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Tue, 19 Jan 2016 12:09:38 -0600 Subject: [M3devel] compiler bug In-Reply-To: References: Message-ID: <569E7BE2.3000603@lcwb.coop> I have a simple fix that made this RT crash go away, but now I can't rebuild the libraries/compiler from all source, with different symptoms for different methods. On 01/17/2016 10:01 PM, Peter McKinna wrote: > This is unusual. > > PROCEDURE Test() = > VAR x,m := 1; > BEGIN > x := Word.Extract(x,m,n); > END Test; > > induces > > new source -> compiling test.m3 > "../src/test.m3", line 190: undefined (n) > > > *** > *** runtime error: > *** An enumeration or subrange value was out of range. > *** file "../AMD64_LINUX/WordExtract.m3 => ../src/builtinWord/Extract.mg", l > ine 120 > *** > > Aborted (core dumped) > > > fix the undefined n and it compiles ok. > > Any takers to fix this? > > Should have a bug tracking system really. > > Peter > > > > _______________________________________________ > M3devel mailing list > M3devel at elegosoft.com > https://mail.elegosoft.com/cgi-bin/mailman/listinfo/m3devel > -- Rodney Bates rodney.m.bates at acm.org From rodney_bates at lcwb.coop Tue Jan 19 21:13:40 2016 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Tue, 19 Jan 2016 14:13:40 -0600 Subject: [M3devel] compiler bug In-Reply-To: <90215E6A-DD51-4671-81DC-120422B83B8F@purdue.edu> References: <569E7BE2.3000603@lcwb.coop> <90215E6A-DD51-4671-81DC-120422B83B8F@purdue.edu> Message-ID: <569E98F4.7070709@lcwb.coop> That's almost what I did, except as below. Since i is passed to a CARDINAL in the line below, the i=zero case would not suffer the RT fault. It would give 0,0 as bounds of the being-compiled Extract, which seems right to me. On 01/19/2016 12:36 PM, Hosking, Antony L wrote: > Can you try this version of Extract.GetBounds? > > PROCEDURE GetBounds (ce: CallExpr.T; VAR min, max: Target.Int) = > VAR min_bits, max_bits: Target.Int; i: INTEGER; > BEGIN > Expr.GetBounds (ce.args[2], min_bits, max_bits); > IF TInt.ToInt (max_bits, i) AND i > 0 AND i < Word_types[rep].size THEN ..............................AND 0 <= i ................................. > IF NOT TWord.Extract (TInt.MOne, 0, i, max) THEN > EVAL Type.GetBounds (T, min, max); > END; > min := TInt.Zero; > ELSE > (* possible that we'll preserve all bits *) > Expr.GetBounds (ce.args[0], min, max); > END; > END GetBounds; > >> On 19 Jan 2016, at 1:09 PM, Rodney M. Bates wrote: >> >> I have a simple fix that made this RT crash go away, but now I can't rebuild >> the libraries/compiler from all source, with different symptoms for different >> methods. >> >> On 01/17/2016 10:01 PM, Peter McKinna wrote: >>> This is unusual. >>> >>> PROCEDURE Test() = >>> VAR x,m := 1; >>> BEGIN >>> x := Word.Extract(x,m,n); >>> END Test; >>> >>> induces >>> >>> new source -> compiling test.m3 >>> "../src/test.m3", line 190: undefined (n) >>> >>> >>> *** >>> *** runtime error: >>> *** An enumeration or subrange value was out of range. >>> *** file "../AMD64_LINUX/WordExtract.m3 => ../src/builtinWord/Extract.mg", l >>> ine 120 >>> *** >>> >>> Aborted (core dumped) >>> >>> >>> fix the undefined n and it compiles ok. >>> >>> Any takers to fix this? >>> >>> Should have a bug tracking system really. >>> >>> Peter >>> >>> >>> >>> _______________________________________________ >>> M3devel mailing list >>> M3devel at elegosoft.com >>> https://mail.elegosoft.com/cgi-bin/mailman/listinfo/m3devel >>> >> >> -- >> Rodney Bates >> rodney.m.bates at acm.org >> _______________________________________________ >> M3devel mailing list >> M3devel at elegosoft.com >> https://mail.elegosoft.com/cgi-bin/mailman/listinfo/m3devel > > -- Rodney Bates rodney.m.bates at acm.org From rodney_bates at lcwb.coop Tue Jan 19 22:32:49 2016 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Tue, 19 Jan 2016 15:32:49 -0600 Subject: [M3devel] compiler bug In-Reply-To: <6F7EC87B-E386-433F-8D73-429097CBC802@purdue.edu> References: <569E7BE2.3000603@lcwb.coop> <90215E6A-DD51-4671-81DC-120422B83B8F@purdue.edu> <569E98F4.7070709@lcwb.coop> <6F7EC87B-E386-433F-8D73-429097CBC802@purdue.edu> Message-ID: <569EAB81.5000001@lcwb.coop> On 01/19/2016 02:21 PM, Hosking, Antony L wrote: > That should work. What errors do you see with that change? > The out of range compiler crash goes away. The "undefined (n)" error messages remains, as it should. The problem I am having now, probably unrelated to this change, is, when I try to rebuild everything to test that it didn't break something elsewhere, I got other build failures. I plan to post these, but there are so many different build procedures I have tried, it will take some work to distill it enough for a comprehensible post. >> On 19 Jan 2016, at 3:13 PM, Rodney M. Bates > wrote: >> >> That's almost what I did, except as below. Since i is passed to a >> CARDINAL in the line below, the i=zero case would not suffer the RT >> fault. It would give 0,0 as bounds of the being-compiled Extract, >> which seems right to me. >> >> On 01/19/2016 12:36 PM, Hosking, Antony L wrote: >>> Can you try this version of Extract.GetBounds? >>> >>> PROCEDURE GetBounds (ce: CallExpr.T; VAR min, max: Target.Int) = >>> VAR min_bits, max_bits: Target.Int; i: INTEGER; >>> BEGIN >>> Expr.GetBounds (ce.args[2], min_bits, max_bits); >>> IF TInt.ToInt (max_bits, i) AND i > 0 AND i < Word_types[rep].size THEN >> ..............................AND 0 <= i ................................. >>> IF NOT TWord.Extract (TInt.MOne, 0, i, max) THEN >>> EVAL Type.GetBounds (T, min, max); >>> END; >>> min := TInt.Zero; >>> ELSE >>> (* possible that we'll preserve all bits *) >>> Expr.GetBounds (ce.args[0], min, max); >>> END; >>> END GetBounds; >>> >>>> On 19 Jan 2016, at 1:09 PM, Rodney M. Bates > wrote: >>>> >>>> I have a simple fix that made this RT crash go away, but now I can't rebuild >>>> the libraries/compiler from all source, with different symptoms for different >>>> methods. >>>> >>>> On 01/17/2016 10:01 PM, Peter McKinna wrote: >>>>> This is unusual. >>>>> >>>>> PROCEDURE Test() = >>>>> VAR x,m := 1; >>>>> BEGIN >>>>> x := Word.Extract(x,m,n); >>>>> END Test; >>>>> >>>>> induces >>>>> >>>>> new source -> compiling test.m3 >>>>> "../src/test.m3", line 190: undefined (n) >>>>> >>>>> >>>>> *** >>>>> *** runtime error: >>>>> *** An enumeration or subrange value was out of range. >>>>> *** file "../AMD64_LINUX/WordExtract.m3 => ../src/builtinWord/Extract.mg", l >>>>> ine 120 >>>>> *** >>>>> >>>>> Aborted (core dumped) >>>>> >>>>> >>>>> fix the undefined n and it compiles ok. >>>>> >>>>> Any takers to fix this? >>>>> >>>>> Should have a bug tracking system really. >>>>> >>>>> Peter >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> M3devel mailing list >>>>> M3devel at elegosoft.com >>>>> https://mail.elegosoft.com/cgi-bin/mailman/listinfo/m3devel >>>>> >>>> >>>> -- >>>> Rodney Bates >>>> rodney.m.bates at acm.org >>>> _______________________________________________ >>>> M3devel mailing list >>>> M3devel at elegosoft.com >>>> https://mail.elegosoft.com/cgi-bin/mailman/listinfo/m3devel >>> >>> >> >> -- >> Rodney Bates >> rodney.m.bates at acm.org > -- Rodney Bates rodney.m.bates at acm.org From rodney_bates at lcwb.coop Wed Jan 20 23:45:02 2016 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Wed, 20 Jan 2016 16:45:02 -0600 Subject: [M3devel] compiler bug In-Reply-To: <569E7BE2.3000603@lcwb.coop> References: <569E7BE2.3000603@lcwb.coop> Message-ID: <56A00DEE.1060804@lcwb.coop> If I try to compile with an old cm3 executable named cm3-5.8.6, I get these errors trying to compile the cm3 executable (and others too, e.g. mklib): ------------------------------------------------------------------------------ -> linking cm3 _m3main.c:7:11: error: ?argc? was not declared in this scope int main (argc, argv, envp) ^ _m3main.c:7:17: error: ?argv? was not declared in this scope int main (argc, argv, envp) ^ _m3main.c:7:23: error: ?envp? was not declared in this scope int main (argc, argv, envp) ^ _m3main.c:7:27: error: expression list treated as compound expression in initializer [-fpermissive] int main (argc, argv, envp) ^ _m3main.c:8:1: error: expected ?,? or ?;? before ?int? int argc; ^ _m3main.c:11:1: error: expected unqualified-id before ?{? token { ^ ------------------------------------------------------------------------------ This happens regardless of whether I use upgrade.py, upgrade.sh, do-cm3-front.sh, or cm3 directly in the cm3 package. If I use a cm3 executable compiled on 2015-8-28, compiling sysutils, I can compile the libraries and compiler, but when I try to use them to recompile, I get: -------------------------------------------------------------------------------- - -> archiving libsysutils.a *** *** runtime error: *** An array subscript was out of range. *** file "../src/M3Build.m3", line 1719 *** Aborted (core dumped) *** execution of [, ] failed *** ------------------------------------------------------------------------------- This also happens when I use a saved executable dated 2015-10-18 On 01/19/2016 12:09 PM, Rodney M. Bates wrote: > I have a simple fix that made this RT crash go away, but now I can't rebuild > the libraries/compiler from all source, with different symptoms for different > methods. > > On 01/17/2016 10:01 PM, Peter McKinna wrote: >> This is unusual. >> >> PROCEDURE Test() = >> VAR x,m := 1; >> BEGIN >> x := Word.Extract(x,m,n); >> END Test; >> >> induces >> >> new source -> compiling test.m3 >> "../src/test.m3", line 190: undefined (n) >> >> >> *** >> *** runtime error: >> *** An enumeration or subrange value was out of range. >> *** file "../AMD64_LINUX/WordExtract.m3 => ../src/builtinWord/Extract.mg", l >> ine 120 >> *** >> >> Aborted (core dumped) >> >> >> fix the undefined n and it compiles ok. >> >> Any takers to fix this? >> >> Should have a bug tracking system really. >> >> Peter >> >> >> >> _______________________________________________ >> M3devel mailing list >> M3devel at elegosoft.com >> https://mail.elegosoft.com/cgi-bin/mailman/listinfo/m3devel >> > -- Rodney Bates rodney.m.bates at acm.org From rodney_bates at lcwb.coop Thu Jan 21 17:19:39 2016 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Thu, 21 Jan 2016 10:19:39 -0600 Subject: [M3devel] compiler bug In-Reply-To: <56A00DEE.1060804@lcwb.coop> References: <569E7BE2.3000603@lcwb.coop> <56A00DEE.1060804@lcwb.coop> Message-ID: <56A1051B.2080201@lcwb.coop> On 01/20/2016 04:45 PM, Rodney M. Bates wrote: > If I try to compile with an old cm3 executable named cm3-5.8.6, I get these > errors trying to compile the cm3 executable (and others too, e.g. mklib): > ------------------------------------------------------------------------------ > -> linking cm3 > _m3main.c:7:11: error: ?argc? was not declared in this scope > int main (argc, argv, envp) > ^ > _m3main.c:7:17: error: ?argv? was not declared in this scope > int main (argc, argv, envp) > ^ > _m3main.c:7:23: error: ?envp? was not declared in this scope > int main (argc, argv, envp) > ^ > _m3main.c:7:27: error: expression list treated as compound expression in initializer [-fpermissive] > int main (argc, argv, envp) > ^ > _m3main.c:8:1: error: expected ?,? or ?;? before ?int? > int argc; > ^ > _m3main.c:11:1: error: expected unqualified-id before ?{? token > { > ^ > > ------------------------------------------------------------------------------ > > This happens regardless of whether I use upgrade.py, upgrade.sh, do-cm3-front.sh, > or cm3 directly in the cm3 package. > > If I use a cm3 executable compiled on 2015-8-28, compiling sysutils, I can compile > the libraries and compiler, but when I try to use them to recompile, I get: > > -------------------------------------------------------------------------------- > - -> archiving libsysutils.a > > > *** > *** runtime error: > *** An array subscript was out of range. > *** file "../src/M3Build.m3", line 1719 > *** > > Aborted (core dumped) > *** execution of [, ] failed *** > > ------------------------------------------------------------------------------- > > This also happens when I use a saved executable dated 2015-10-18 Attempting to diagnose this problem, I find it has gone away. Don't know what changed. I used the same cm3 and cm3cg executables, same source code, and did realcleans both times, but I suppose there must be places for local state to hide. Anyway, now it rebuilds itself and converges to identical-sized cm3 executables after 3 rebuild cycles. > > > > > On 01/19/2016 12:09 PM, Rodney M. Bates wrote: >> I have a simple fix that made this RT crash go away, but now I can't rebuild >> the libraries/compiler from all source, with different symptoms for different >> methods. >> >> On 01/17/2016 10:01 PM, Peter McKinna wrote: >>> This is unusual. >>> >>> PROCEDURE Test() = >>> VAR x,m := 1; >>> BEGIN >>> x := Word.Extract(x,m,n); >>> END Test; >>> >>> induces >>> >>> new source -> compiling test.m3 >>> "../src/test.m3", line 190: undefined (n) >>> >>> >>> *** >>> *** runtime error: >>> *** An enumeration or subrange value was out of range. >>> *** file "../AMD64_LINUX/WordExtract.m3 => ../src/builtinWord/Extract.mg", l >>> ine 120 >>> *** >>> >>> Aborted (core dumped) >>> >>> >>> fix the undefined n and it compiles ok. >>> >>> Any takers to fix this? >>> >>> Should have a bug tracking system really. >>> >>> Peter >>> >>> >>> >>> _______________________________________________ >>> M3devel mailing list >>> M3devel at elegosoft.com >>> https://mail.elegosoft.com/cgi-bin/mailman/listinfo/m3devel >>> >> > -- Rodney Bates rodney.m.bates at acm.org From jay.krell at cornell.edu Fri Jan 1 07:21:27 2016 From: jay.krell at cornell.edu (Jay K) Date: Fri, 1 Jan 2016 06:21:27 +0000 Subject: [M3devel] alloca/jmpbuf Message-ID: NT386 has some failure in the caltech-parser/parserlib/parserlib/test directory. I propose the following: Bring back the jmpbuf-size-known-by-frontend code, but with some "sprinkled conditions": Target.Alloca_jmpbuf: BOOLEAN in the compiler and something in the runtime, like RTExFrame.Alloca_jmpbuf:BOOLEAN. If this is/was/meant to be an option that lasted a while, then it'd also be a bit in RT0, so the runtime would make a runtime decision "informed by" the compiler. However this is really just hopefully just an experiment, and anyone switching the value would switch it in both places. It really can't be in only one place, though one could communicate it to the other -- such is the dependency/independency between the compiler and runtime. I tried to do a "git revert" and then edit, but git continues to elude me, so I'm going to do something more manual. Ok? Alternatives: 1) Just debug the current state. Esp. comparing MacOSX (which works) with NT386 2) Construct all I've said but don't commit it. ?- Jay From jay.krell at cornell.edu Sat Jan 2 02:04:22 2016 From: jay.krell at cornell.edu (Jay K) Date: Sat, 2 Jan 2016 01:04:22 +0000 Subject: [M3devel] alloca/jmpbuf In-Reply-To: References: Message-ID: ok -- putting back the old jmpbuf allocation does fix the problem on caltech-parser/parserlib/parserlib/test NT386. I had to do the undo very manually because git was confusing. Anyone have any idea of the exact problem? Otherwise I'll try to figure it out but it'll take a while. Maybe we have really good focused exception handling tests? I"ll look in m3tests. Thank you, ?- Jay ---------------------------------------- > From: jay.krell at cornell.edu > To: m3devel at elegosoft.com > Subject: alloca/jmpbuf > Date: Fri, 1 Jan 2016 06:21:27 +0000 > > NT386 has some failure in the caltech-parser/parserlib/parserlib/test directory. > > > I propose the following: > Bring back the jmpbuf-size-known-by-frontend code, but with some "sprinkled conditions": > > > Target.Alloca_jmpbuf: BOOLEAN in the compiler > and something in the runtime, like RTExFrame.Alloca_jmpbuf:BOOLEAN. > > > If this is/was/meant to be an option that lasted a while, then it'd also be a bit in RT0, so the runtime would make a runtime decision "informed by" the compiler. > > However this is really just hopefully just an experiment, and anyone switching the value would switch it in both places. > > > It really can't be in only one place, though one could communicate it to the other -- such is the dependency/independency between the compiler and runtime. > > > I tried to do a "git revert" and then edit, but git continues to elude me, so I'm going to do something more manual. > > Ok? > > Alternatives: > 1) Just debug the current state. > Esp. comparing MacOSX (which works) with NT386 > > 2) Construct all I've said but don't commit it. > > > - Jay From rodney_bates at lcwb.coop Sat Jan 2 22:03:27 2016 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Sat, 02 Jan 2016 15:03:27 -0600 Subject: [M3devel] M3CG loophole operator is not LOOPHOLE (but what?) In-Reply-To: <5671A6F7.6040805@lcwb.coop> References: <5669C154.90603@lcwb.coop> <1615931268.1036686.1450060846633.JavaMail.yahoo@mail.yahoo.com> <5671A6F7.6040805@lcwb.coop> Message-ID: <56883B1F.5050301@lcwb.coop> The further I get into this, the more worms crawl out. The only cm3 IR operators that change an operand size (without storing/refetching in memory) are widen and chop. The inserts and extracts work entirely within the same- sized word. But widen and chop are never produced by the front end, and the integrated and C back ends assert they don't happen. m3cc has code for them, but this will be entirely untested, and vetting it involves tracing through lots of gcc code. So I plan to redefine the misdocumented loophole operator to allow size changes among Int32/Word32/Int64/Word64, with shortening changes doing a chop and widening doing either zero-extend or sign-extend, consistent with the signedness of the result type. I think this will cover all the cases required by current places where loophole is emitted, which further implies the backends are all doing at least these, assuming there are sufficient test cases. This amounts only to correcting the documentation in M3CG_Ops.i3 m3llvm will then need to add these behaviors, and things should at least work as well as always. The many loophole-emitting places still need thorough review and documentation of their requirements. Some of them assume address is same size as native integer. Implementing chop and widen, using them for size changes, and changing loophole back to the same as LOOPHOLE is the right way, but involves a lot of work and testing, for small code changes. On 12/16/2015 12:01 PM, Rodney M. Bates wrote: > The issue I raised is not with the M3 LOOPHOLE builtin function. The compiler > currently implements it correctly, according to the language definition, as > Tony quoted. The front end verifies the size equality, as required by the > language, then emits an intermediate "loophole" operator, which will be same > size, and thus well-defined as equivalent to LOOPHOLE. (And also llvm bitcast, > which is now being used to translate the loophole operator in this case.) > > My issue is that there are 13 other places the front-end emits an internally > generated "loophole", and these (almost?) all can do so with unequal sizes. > Moreover, what should be done with the unequal sizes varies from place to place. > > It is possible that the "loophole" operator can be defined to do what is > correct in every case by a conditional rule based on the two types. I > need to do another pass through them to be sure. This may be the quickest > way to get the llvm backend working, but I think it is not good design. > It would be carefully tailored to just a specific set of uses of "loophole", > instead of making a reasonable abstraction out of" loophole". It would be > rather fragile and involve a lot of analysis on the full Cartesian product > of both supplier and client side cases of "loophole" to define and verify. > > The best way, IMO, is to fix each "loophole"-generating site to use other > operators, as appropriate. It is at these sites that it is known what > should be done in each case. I suspect existing intermediate operators > "widen", "insert_mn" and "extract_mn" are sufficient. Again, another pass > through the cases is indicated. The only pragmatic drawback to this is > that this requires considerable care and retesting to avoid breakage of > existing behavior. At worst, it risks inability to bootstrap the compiler. > I would prefer one change at a time, each tested by reboostrapping twice. > > > > On 12/13/2015 08:40 PM, Daniel Alejandro Benavides D. wrote: >> Hello: >> Excuse me if is wrong to say, but doesn't the specification of Modula-3 explicit about how the UNSAFE stuff is implementation-dependent, that is to say; "it's your decision how to implement it". >> Thanks in advance >> >> >> >> El Domingo 13 de diciembre de 2015 21:20, Jay escribi?: >> >> >> I know, but this pattern is pretty rare. >> >> - Jay >> >> On Dec 13, 2015, at 1:46 AM, Antony Hosking > wrote: >> >>> Excepting that in some cases taking the address may force the value into memory, when it could have stayed in a register. >>> The intent is to allow the backend to avoid that. >>> >>>> On 11 Dec 2015, at 5:53 PM, Jay K > wrote: >>>> >>>> The right thing to do, really, is take the address of a float, loophole >>>> that into an address of another type, and dereference that. >>>> Not in the backend, but in the Modula-3 code. >>>> >>> >> >> _______________________________________________ >> M3devel mailing list >> M3devel at elegosoft.com >> https://mail.elegosoft.com/cgi-bin/mailman/listinfo/m3devel >> >> >> >> >> _______________________________________________ >> M3devel mailing list >> M3devel at elegosoft.com >> https://mail.elegosoft.com/cgi-bin/mailman/listinfo/m3devel >> > -- Rodney Bates rodney.m.bates at acm.org From jay.krell at cornell.edu Sun Jan 3 01:11:41 2016 From: jay.krell at cornell.edu (Jay K) Date: Sun, 3 Jan 2016 00:11:41 +0000 Subject: [M3devel] M3CG loophole operator is not LOOPHOLE (but what?) In-Reply-To: <56883B1F.5050301@lcwb.coop> References: <5669C154.90603@lcwb.coop>, , , , <1615931268.1036686.1450060846633.JavaMail.yahoo@mail.yahoo.com>, <5671A6F7.6040805@lcwb.coop>, <56883B1F.5050301@lcwb.coop> Message-ID: > Some of them assume address is same size as native integer. This is correct and by-design. BYTESIZE(INTEGER) = BYTESIZE(REFANY) etc. (all pointers are the same size) In C and C++, for the vast majority of systems sizeof(size_t) = sizeof(char*) etc. (again, all pointers are the same size) VMS64 might be an exception. Might. However modern C and C++ offer intptr_t/uintptr_t for this: sizeof(intptr_t) == sizeof(char*) etc. (again, all pointers are the same size) It is popular to think sizeof(long) == sizeof(char*) but that is frequently incorrect, maybe half the time. (i.e. on Win64 and maybe VMS64) I'd still like to check/test what happens in the C and NT386 backends here, for loophole changing sizes, but not right now, sorry. The asserts about widen/chop not occurring are from me. You know, I fairly recently went through much/most/all of what you are doing (I hope all, but I fear much/most) -- implementing a new backend from scratch, and having to figure out precise meanings of things > > I would prefer one change at a time, each tested by reboostrapping twice. upgrade.py does the "twice" part builtin. - Jay > Date: Sat, 2 Jan 2016 15:03:27 -0600 > From: rodney_bates at lcwb.coop > To: m3devel at elegosoft.com > Subject: Re: [M3devel] M3CG loophole operator is not LOOPHOLE (but what?) > > The further I get into this, the more worms crawl out. The only cm3 IR > operators that change an operand size (without storing/refetching in memory) > are widen and chop. The inserts and extracts work entirely within the same- > sized word. But widen and chop are never produced by the front end, and > the integrated and C back ends assert they don't happen. m3cc has code > for them, but this will be entirely untested, and vetting it involves > tracing through lots of gcc code. > > So I plan to redefine the misdocumented loophole operator to allow size > changes among Int32/Word32/Int64/Word64, with shortening changes doing a > chop and widening doing either zero-extend or sign-extend, consistent with > the signedness of the result type. I think this will cover all the cases > required by current places where loophole is emitted, which further implies > the backends are all doing at least these, assuming there are sufficient > test cases. This amounts only to correcting the documentation in M3CG_Ops.i3 > > m3llvm will then need to add these behaviors, and things should at least work > as well as always. > > The many loophole-emitting places still need thorough review and documentation > of their requirements. Some of them assume address is same size as native > integer. > > Implementing chop and widen, using them for size changes, and changing loophole > back to the same as LOOPHOLE is the right way, but involves a lot of work and > testing, for small code changes. > > On 12/16/2015 12:01 PM, Rodney M. Bates wrote: > > The issue I raised is not with the M3 LOOPHOLE builtin function. The compiler > > currently implements it correctly, according to the language definition, as > > Tony quoted. The front end verifies the size equality, as required by the > > language, then emits an intermediate "loophole" operator, which will be same > > size, and thus well-defined as equivalent to LOOPHOLE. (And also llvm bitcast, > > which is now being used to translate the loophole operator in this case.) > > > > My issue is that there are 13 other places the front-end emits an internally > > generated "loophole", and these (almost?) all can do so with unequal sizes. > > Moreover, what should be done with the unequal sizes varies from place to place. > > > > It is possible that the "loophole" operator can be defined to do what is > > correct in every case by a conditional rule based on the two types. I > > need to do another pass through them to be sure. This may be the quickest > > way to get the llvm backend working, but I think it is not good design. > > It would be carefully tailored to just a specific set of uses of "loophole", > > instead of making a reasonable abstraction out of" loophole". It would be > > rather fragile and involve a lot of analysis on the full Cartesian product > > of both supplier and client side cases of "loophole" to define and verify. > > > > The best way, IMO, is to fix each "loophole"-generating site to use other > > operators, as appropriate. It is at these sites that it is known what > > should be done in each case. I suspect existing intermediate operators > > "widen", "insert_mn" and "extract_mn" are sufficient. Again, another pass > > through the cases is indicated. The only pragmatic drawback to this is > > that this requires considerable care and retesting to avoid breakage of > > existing behavior. At worst, it risks inability to bootstrap the compiler. > > I would prefer one change at a time, each tested by reboostrapping twice. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Tue Jan 5 11:44:22 2016 From: jay.krell at cornell.edu (Jay K) Date: Tue, 5 Jan 2016 10:44:22 +0000 Subject: [M3devel] install and C code Message-ID: I finally had a minor epiphany. Ignoring the C backend, to the extent that the system contains C code, "install" should actually recompile all the C code, using the user's intended compilation environment. This would clear up various incompatibilities that exist. i.e. with m3core.lib.sa and m3.lib.sa and the bootstrapping procedure. The 3.6 distribution did this. It actually distributed assembly source and C source and then did assembly/compilation/linking on the user machine. assembly is close to "binary", but this had advantages. It also solved the "origin" problem, back in the time before origin was widely supported -- i.e. link with full paths on Unix systems. I don't have the energy now, but we really could use a bit of a rewrite here. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Tue Jan 5 20:57:12 2016 From: jay.krell at cornell.edu (Jay K) Date: Tue, 5 Jan 2016 19:57:12 +0000 Subject: [M3devel] install and C code In-Reply-To: References: Message-ID: We do have the bootstrap archives, but they onlybuild cm3/mklib. We need to extend them to buildeverything, and either carry all of the Modula-3source, or carry everything as assembly source. I was thinking about that a while ago for a whileand couldn't decide, like, among cmake or automakeor makefiles for each directory. - Jay From: jay.krell at cornell.edu To: m3devel at elegosoft.com Date: Tue, 5 Jan 2016 10:44:22 +0000 Subject: [M3devel] install and C code I finally had a minor epiphany. Ignoring the C backend, to the extent that the system contains C code, "install" should actually recompile all the C code, using the user's intended compilation environment. This would clear up various incompatibilities that exist. i.e. with m3core.lib.sa and m3.lib.sa and the bootstrapping procedure. The 3.6 distribution did this. It actually distributed assembly source and C source and then did assembly/compilation/linking on the user machine. assembly is close to "binary", but this had advantages. It also solved the "origin" problem, back in the time before origin was widely supported -- i.e. link with full paths on Unix systems. I don't have the energy now, but we really could use a bit of a rewrite here. - Jay _______________________________________________ M3devel mailing list M3devel at elegosoft.com https://mail.elegosoft.com/cgi-bin/mailman/listinfo/m3devel -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Fri Jan 8 21:45:45 2016 From: jay.krell at cornell.edu (Jay K) Date: Fri, 8 Jan 2016 20:45:45 +0000 Subject: [M3devel] alloca/jmpbuf In-Reply-To: References: , Message-ID: I am no longer able to reproduce the problem.There have been some changes since but they don't seem relevant. Unless there are objections I'll put this back shortly -- just changingthe two booleans in Target.m3 and RTExFrame, and retaining the option to easily move back. Thank you, - Jay > From: jay.krell at cornell.edu > To: m3devel at elegosoft.com > Subject: RE: alloca/jmpbuf > Date: Sat, 2 Jan 2016 01:04:22 +0000 > > ok -- putting back the old jmpbuf allocation does fix the problem on caltech-parser/parserlib/parserlib/test NT386. > I had to do the undo very manually because git was confusing. > > Anyone have any idea of the exact problem? > > Otherwise I'll try to figure it out but it'll take a while. > > Maybe we have really good focused exception handling tests? I"ll look in m3tests. > > Thank you, > - Jay > > > ---------------------------------------- > > From: jay.krell at cornell.edu > > To: m3devel at elegosoft.com > > Subject: alloca/jmpbuf > > Date: Fri, 1 Jan 2016 06:21:27 +0000 > > > > NT386 has some failure in the caltech-parser/parserlib/parserlib/test directory. > > > > > > I propose the following: > > Bring back the jmpbuf-size-known-by-frontend code, but with some "sprinkled conditions": > > > > > > Target.Alloca_jmpbuf: BOOLEAN in the compiler > > and something in the runtime, like RTExFrame.Alloca_jmpbuf:BOOLEAN. > > > > > > If this is/was/meant to be an option that lasted a while, then it'd also be a bit in RT0, so the runtime would make a runtime decision "informed by" the compiler. > > > > However this is really just hopefully just an experiment, and anyone switching the value would switch it in both places. > > > > > > It really can't be in only one place, though one could communicate it to the other -- such is the dependency/independency between the compiler and runtime. > > > > > > I tried to do a "git revert" and then edit, but git continues to elude me, so I'm going to do something more manual. > > > > Ok? > > > > Alternatives: > > 1) Just debug the current state. > > Esp. comparing MacOSX (which works) with NT386 > > > > 2) Construct all I've said but don't commit it. > > > > > > - Jay > -------------- next part -------------- An HTML attachment was scrubbed... URL: From peter.mckinna at gmail.com Mon Jan 18 05:01:30 2016 From: peter.mckinna at gmail.com (Peter McKinna) Date: Mon, 18 Jan 2016 15:01:30 +1100 Subject: [M3devel] compiler bug Message-ID: This is unusual. PROCEDURE Test() = VAR x,m := 1; BEGIN x := Word.Extract(x,m,n); END Test; induces new source -> compiling test.m3 "../src/test.m3", line 190: undefined (n) *** *** runtime error: *** An enumeration or subrange value was out of range. *** file "../AMD64_LINUX/WordExtract.m3 => ../src/builtinWord/Extract.mg", l ine 120 *** Aborted (core dumped) fix the undefined n and it compiles ok. Any takers to fix this? Should have a bug tracking system really. Peter -------------- next part -------------- An HTML attachment was scrubbed... URL: From rodney_bates at lcwb.coop Tue Jan 19 19:09:38 2016 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Tue, 19 Jan 2016 12:09:38 -0600 Subject: [M3devel] compiler bug In-Reply-To: References: Message-ID: <569E7BE2.3000603@lcwb.coop> I have a simple fix that made this RT crash go away, but now I can't rebuild the libraries/compiler from all source, with different symptoms for different methods. On 01/17/2016 10:01 PM, Peter McKinna wrote: > This is unusual. > > PROCEDURE Test() = > VAR x,m := 1; > BEGIN > x := Word.Extract(x,m,n); > END Test; > > induces > > new source -> compiling test.m3 > "../src/test.m3", line 190: undefined (n) > > > *** > *** runtime error: > *** An enumeration or subrange value was out of range. > *** file "../AMD64_LINUX/WordExtract.m3 => ../src/builtinWord/Extract.mg", l > ine 120 > *** > > Aborted (core dumped) > > > fix the undefined n and it compiles ok. > > Any takers to fix this? > > Should have a bug tracking system really. > > Peter > > > > _______________________________________________ > M3devel mailing list > M3devel at elegosoft.com > https://mail.elegosoft.com/cgi-bin/mailman/listinfo/m3devel > -- Rodney Bates rodney.m.bates at acm.org From rodney_bates at lcwb.coop Tue Jan 19 21:13:40 2016 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Tue, 19 Jan 2016 14:13:40 -0600 Subject: [M3devel] compiler bug In-Reply-To: <90215E6A-DD51-4671-81DC-120422B83B8F@purdue.edu> References: <569E7BE2.3000603@lcwb.coop> <90215E6A-DD51-4671-81DC-120422B83B8F@purdue.edu> Message-ID: <569E98F4.7070709@lcwb.coop> That's almost what I did, except as below. Since i is passed to a CARDINAL in the line below, the i=zero case would not suffer the RT fault. It would give 0,0 as bounds of the being-compiled Extract, which seems right to me. On 01/19/2016 12:36 PM, Hosking, Antony L wrote: > Can you try this version of Extract.GetBounds? > > PROCEDURE GetBounds (ce: CallExpr.T; VAR min, max: Target.Int) = > VAR min_bits, max_bits: Target.Int; i: INTEGER; > BEGIN > Expr.GetBounds (ce.args[2], min_bits, max_bits); > IF TInt.ToInt (max_bits, i) AND i > 0 AND i < Word_types[rep].size THEN ..............................AND 0 <= i ................................. > IF NOT TWord.Extract (TInt.MOne, 0, i, max) THEN > EVAL Type.GetBounds (T, min, max); > END; > min := TInt.Zero; > ELSE > (* possible that we'll preserve all bits *) > Expr.GetBounds (ce.args[0], min, max); > END; > END GetBounds; > >> On 19 Jan 2016, at 1:09 PM, Rodney M. Bates wrote: >> >> I have a simple fix that made this RT crash go away, but now I can't rebuild >> the libraries/compiler from all source, with different symptoms for different >> methods. >> >> On 01/17/2016 10:01 PM, Peter McKinna wrote: >>> This is unusual. >>> >>> PROCEDURE Test() = >>> VAR x,m := 1; >>> BEGIN >>> x := Word.Extract(x,m,n); >>> END Test; >>> >>> induces >>> >>> new source -> compiling test.m3 >>> "../src/test.m3", line 190: undefined (n) >>> >>> >>> *** >>> *** runtime error: >>> *** An enumeration or subrange value was out of range. >>> *** file "../AMD64_LINUX/WordExtract.m3 => ../src/builtinWord/Extract.mg", l >>> ine 120 >>> *** >>> >>> Aborted (core dumped) >>> >>> >>> fix the undefined n and it compiles ok. >>> >>> Any takers to fix this? >>> >>> Should have a bug tracking system really. >>> >>> Peter >>> >>> >>> >>> _______________________________________________ >>> M3devel mailing list >>> M3devel at elegosoft.com >>> https://mail.elegosoft.com/cgi-bin/mailman/listinfo/m3devel >>> >> >> -- >> Rodney Bates >> rodney.m.bates at acm.org >> _______________________________________________ >> M3devel mailing list >> M3devel at elegosoft.com >> https://mail.elegosoft.com/cgi-bin/mailman/listinfo/m3devel > > -- Rodney Bates rodney.m.bates at acm.org From rodney_bates at lcwb.coop Tue Jan 19 22:32:49 2016 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Tue, 19 Jan 2016 15:32:49 -0600 Subject: [M3devel] compiler bug In-Reply-To: <6F7EC87B-E386-433F-8D73-429097CBC802@purdue.edu> References: <569E7BE2.3000603@lcwb.coop> <90215E6A-DD51-4671-81DC-120422B83B8F@purdue.edu> <569E98F4.7070709@lcwb.coop> <6F7EC87B-E386-433F-8D73-429097CBC802@purdue.edu> Message-ID: <569EAB81.5000001@lcwb.coop> On 01/19/2016 02:21 PM, Hosking, Antony L wrote: > That should work. What errors do you see with that change? > The out of range compiler crash goes away. The "undefined (n)" error messages remains, as it should. The problem I am having now, probably unrelated to this change, is, when I try to rebuild everything to test that it didn't break something elsewhere, I got other build failures. I plan to post these, but there are so many different build procedures I have tried, it will take some work to distill it enough for a comprehensible post. >> On 19 Jan 2016, at 3:13 PM, Rodney M. Bates > wrote: >> >> That's almost what I did, except as below. Since i is passed to a >> CARDINAL in the line below, the i=zero case would not suffer the RT >> fault. It would give 0,0 as bounds of the being-compiled Extract, >> which seems right to me. >> >> On 01/19/2016 12:36 PM, Hosking, Antony L wrote: >>> Can you try this version of Extract.GetBounds? >>> >>> PROCEDURE GetBounds (ce: CallExpr.T; VAR min, max: Target.Int) = >>> VAR min_bits, max_bits: Target.Int; i: INTEGER; >>> BEGIN >>> Expr.GetBounds (ce.args[2], min_bits, max_bits); >>> IF TInt.ToInt (max_bits, i) AND i > 0 AND i < Word_types[rep].size THEN >> ..............................AND 0 <= i ................................. >>> IF NOT TWord.Extract (TInt.MOne, 0, i, max) THEN >>> EVAL Type.GetBounds (T, min, max); >>> END; >>> min := TInt.Zero; >>> ELSE >>> (* possible that we'll preserve all bits *) >>> Expr.GetBounds (ce.args[0], min, max); >>> END; >>> END GetBounds; >>> >>>> On 19 Jan 2016, at 1:09 PM, Rodney M. Bates > wrote: >>>> >>>> I have a simple fix that made this RT crash go away, but now I can't rebuild >>>> the libraries/compiler from all source, with different symptoms for different >>>> methods. >>>> >>>> On 01/17/2016 10:01 PM, Peter McKinna wrote: >>>>> This is unusual. >>>>> >>>>> PROCEDURE Test() = >>>>> VAR x,m := 1; >>>>> BEGIN >>>>> x := Word.Extract(x,m,n); >>>>> END Test; >>>>> >>>>> induces >>>>> >>>>> new source -> compiling test.m3 >>>>> "../src/test.m3", line 190: undefined (n) >>>>> >>>>> >>>>> *** >>>>> *** runtime error: >>>>> *** An enumeration or subrange value was out of range. >>>>> *** file "../AMD64_LINUX/WordExtract.m3 => ../src/builtinWord/Extract.mg", l >>>>> ine 120 >>>>> *** >>>>> >>>>> Aborted (core dumped) >>>>> >>>>> >>>>> fix the undefined n and it compiles ok. >>>>> >>>>> Any takers to fix this? >>>>> >>>>> Should have a bug tracking system really. >>>>> >>>>> Peter >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> M3devel mailing list >>>>> M3devel at elegosoft.com >>>>> https://mail.elegosoft.com/cgi-bin/mailman/listinfo/m3devel >>>>> >>>> >>>> -- >>>> Rodney Bates >>>> rodney.m.bates at acm.org >>>> _______________________________________________ >>>> M3devel mailing list >>>> M3devel at elegosoft.com >>>> https://mail.elegosoft.com/cgi-bin/mailman/listinfo/m3devel >>> >>> >> >> -- >> Rodney Bates >> rodney.m.bates at acm.org > -- Rodney Bates rodney.m.bates at acm.org From rodney_bates at lcwb.coop Wed Jan 20 23:45:02 2016 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Wed, 20 Jan 2016 16:45:02 -0600 Subject: [M3devel] compiler bug In-Reply-To: <569E7BE2.3000603@lcwb.coop> References: <569E7BE2.3000603@lcwb.coop> Message-ID: <56A00DEE.1060804@lcwb.coop> If I try to compile with an old cm3 executable named cm3-5.8.6, I get these errors trying to compile the cm3 executable (and others too, e.g. mklib): ------------------------------------------------------------------------------ -> linking cm3 _m3main.c:7:11: error: ?argc? was not declared in this scope int main (argc, argv, envp) ^ _m3main.c:7:17: error: ?argv? was not declared in this scope int main (argc, argv, envp) ^ _m3main.c:7:23: error: ?envp? was not declared in this scope int main (argc, argv, envp) ^ _m3main.c:7:27: error: expression list treated as compound expression in initializer [-fpermissive] int main (argc, argv, envp) ^ _m3main.c:8:1: error: expected ?,? or ?;? before ?int? int argc; ^ _m3main.c:11:1: error: expected unqualified-id before ?{? token { ^ ------------------------------------------------------------------------------ This happens regardless of whether I use upgrade.py, upgrade.sh, do-cm3-front.sh, or cm3 directly in the cm3 package. If I use a cm3 executable compiled on 2015-8-28, compiling sysutils, I can compile the libraries and compiler, but when I try to use them to recompile, I get: -------------------------------------------------------------------------------- - -> archiving libsysutils.a *** *** runtime error: *** An array subscript was out of range. *** file "../src/M3Build.m3", line 1719 *** Aborted (core dumped) *** execution of [, ] failed *** ------------------------------------------------------------------------------- This also happens when I use a saved executable dated 2015-10-18 On 01/19/2016 12:09 PM, Rodney M. Bates wrote: > I have a simple fix that made this RT crash go away, but now I can't rebuild > the libraries/compiler from all source, with different symptoms for different > methods. > > On 01/17/2016 10:01 PM, Peter McKinna wrote: >> This is unusual. >> >> PROCEDURE Test() = >> VAR x,m := 1; >> BEGIN >> x := Word.Extract(x,m,n); >> END Test; >> >> induces >> >> new source -> compiling test.m3 >> "../src/test.m3", line 190: undefined (n) >> >> >> *** >> *** runtime error: >> *** An enumeration or subrange value was out of range. >> *** file "../AMD64_LINUX/WordExtract.m3 => ../src/builtinWord/Extract.mg", l >> ine 120 >> *** >> >> Aborted (core dumped) >> >> >> fix the undefined n and it compiles ok. >> >> Any takers to fix this? >> >> Should have a bug tracking system really. >> >> Peter >> >> >> >> _______________________________________________ >> M3devel mailing list >> M3devel at elegosoft.com >> https://mail.elegosoft.com/cgi-bin/mailman/listinfo/m3devel >> > -- Rodney Bates rodney.m.bates at acm.org From rodney_bates at lcwb.coop Thu Jan 21 17:19:39 2016 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Thu, 21 Jan 2016 10:19:39 -0600 Subject: [M3devel] compiler bug In-Reply-To: <56A00DEE.1060804@lcwb.coop> References: <569E7BE2.3000603@lcwb.coop> <56A00DEE.1060804@lcwb.coop> Message-ID: <56A1051B.2080201@lcwb.coop> On 01/20/2016 04:45 PM, Rodney M. Bates wrote: > If I try to compile with an old cm3 executable named cm3-5.8.6, I get these > errors trying to compile the cm3 executable (and others too, e.g. mklib): > ------------------------------------------------------------------------------ > -> linking cm3 > _m3main.c:7:11: error: ?argc? was not declared in this scope > int main (argc, argv, envp) > ^ > _m3main.c:7:17: error: ?argv? was not declared in this scope > int main (argc, argv, envp) > ^ > _m3main.c:7:23: error: ?envp? was not declared in this scope > int main (argc, argv, envp) > ^ > _m3main.c:7:27: error: expression list treated as compound expression in initializer [-fpermissive] > int main (argc, argv, envp) > ^ > _m3main.c:8:1: error: expected ?,? or ?;? before ?int? > int argc; > ^ > _m3main.c:11:1: error: expected unqualified-id before ?{? token > { > ^ > > ------------------------------------------------------------------------------ > > This happens regardless of whether I use upgrade.py, upgrade.sh, do-cm3-front.sh, > or cm3 directly in the cm3 package. > > If I use a cm3 executable compiled on 2015-8-28, compiling sysutils, I can compile > the libraries and compiler, but when I try to use them to recompile, I get: > > -------------------------------------------------------------------------------- > - -> archiving libsysutils.a > > > *** > *** runtime error: > *** An array subscript was out of range. > *** file "../src/M3Build.m3", line 1719 > *** > > Aborted (core dumped) > *** execution of [, ] failed *** > > ------------------------------------------------------------------------------- > > This also happens when I use a saved executable dated 2015-10-18 Attempting to diagnose this problem, I find it has gone away. Don't know what changed. I used the same cm3 and cm3cg executables, same source code, and did realcleans both times, but I suppose there must be places for local state to hide. Anyway, now it rebuilds itself and converges to identical-sized cm3 executables after 3 rebuild cycles. > > > > > On 01/19/2016 12:09 PM, Rodney M. Bates wrote: >> I have a simple fix that made this RT crash go away, but now I can't rebuild >> the libraries/compiler from all source, with different symptoms for different >> methods. >> >> On 01/17/2016 10:01 PM, Peter McKinna wrote: >>> This is unusual. >>> >>> PROCEDURE Test() = >>> VAR x,m := 1; >>> BEGIN >>> x := Word.Extract(x,m,n); >>> END Test; >>> >>> induces >>> >>> new source -> compiling test.m3 >>> "../src/test.m3", line 190: undefined (n) >>> >>> >>> *** >>> *** runtime error: >>> *** An enumeration or subrange value was out of range. >>> *** file "../AMD64_LINUX/WordExtract.m3 => ../src/builtinWord/Extract.mg", l >>> ine 120 >>> *** >>> >>> Aborted (core dumped) >>> >>> >>> fix the undefined n and it compiles ok. >>> >>> Any takers to fix this? >>> >>> Should have a bug tracking system really. >>> >>> Peter >>> >>> >>> >>> _______________________________________________ >>> M3devel mailing list >>> M3devel at elegosoft.com >>> https://mail.elegosoft.com/cgi-bin/mailman/listinfo/m3devel >>> >> > -- Rodney Bates rodney.m.bates at acm.org