From dabenavidesd at yahoo.es Wed May 4 03:38:26 2016 From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.) Date: Wed, 4 May 2016 01:38:26 +0000 (UTC) Subject: [M3devel] looking if is there any interest References: <122527900.156772.1462325906591.JavaMail.yahoo.ref@mail.yahoo.com> Message-ID: <122527900.156772.1462325906591.JavaMail.yahoo@mail.yahoo.com> Hi floks:Does anyone think in a Cross Platform development environment system; for instance:1. I have a compiler front end in my tablet (say yet to be finished M3clipse) that creates an AST, 2. and sent to generate code for certain platform (in a CM3-IDE of SRC M3 compiler server) to a given target, 3. Download it and execute it in a terminal or windows client? I finally have resources in hardware to make some development, and looking forward to see get the best idea I can implement. thanks in advance -------------- next part -------------- An HTML attachment was scrubbed... URL: From rodney_bates at lcwb.coop Tue May 10 17:21:42 2016 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Tue, 10 May 2016 10:21:42 -0500 Subject: [M3devel] looking if is there any interest In-Reply-To: <122527900.156772.1462325906591.JavaMail.yahoo@mail.yahoo.com> References: <122527900.156772.1462325906591.JavaMail.yahoo.ref@mail.yahoo.com> <122527900.156772.1462325906591.JavaMail.yahoo@mail.yahoo.com> Message-ID: <5731FC86.5070206@lcwb.coop> I'm not sure I fully understand. You propose to have the front-end run on a tablet, code generation run on a remote server? Presumably because the tablet lacks sufficient hardware resources? Then the code executes where, back on the tablet? Personally, I find editing/developing code without a real keyboard to be so hopelessly painful, I just wouldn't do it. Touch screens have exasperatingly high false positive, false negative, and wrong gesture recognition. Maybe I have different hand capacitance than most people. I would prefer to do the editing off the tablet, in which case, it would make sense that the front-end compiling be done on the compile server too. On 05/03/2016 08:38 PM, Daniel Alejandro Benavides D. wrote: > Hi floks: > Does anyone think in a Cross Platform development environment system; for instance: > 1. I have a compiler front end in my tablet (say yet to be finished M3clipse) that creates an AST, > 2. and sent to generate code for certain platform (in a CM3-IDE of SRC M3 compiler server) to a given target, > 3. Download it and execute it in a terminal or windows client? > > I finally have resources in hardware to make some development, and looking forward to see get the best idea I can implement. > > thanks in advance > > > _______________________________________________ > 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 dabenavidesd at yahoo.es Tue May 10 20:02:33 2016 From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.) Date: Tue, 10 May 2016 18:02:33 +0000 (UTC) Subject: [M3devel] looking if is there any interest In-Reply-To: <5731FC86.5070206@lcwb.coop> References: <122527900.156772.1462325906591.JavaMail.yahoo.ref@mail.yahoo.com> <122527900.156772.1462325906591.JavaMail.yahoo@mail.yahoo.com> <5731FC86.5070206@lcwb.coop> Message-ID: <163359176.3358022.1462903353852.JavaMail.yahoo@mail.yahoo.com> Hello Rodney: more or less yes; it's just taking advantage of the CM3/SRC-M3 compiler infrastructure, as ( and please correct me if wrong): (1) Use a Java enabled device (like a tablet running Android, etc via M3clipse) to type check? and AST ("new "m3front) (2) Receive AST via network service CM3-IDE server and do IR ("m3middle") (3). In a gcc enabled platform code generate m3cg ("m3back") The good part of making this adaptation is that most of machines today are either (1) or (3) type (or both just as you say), so we can make the compiler more readily available? (if 1 and 3 are too ). Also, it would nice to have separate machines for easier working so people can contribute where they want and upgrade programs automatically (every distributed computing advantage). So we just concentrate in (2) to be highly available. Besides there are a lot of (3) type machines. Now I have one question, can we made (2) enough platform independent so just have one machine for all platforms, Jay? Thanks in advance El Martes 10 de Mayo de 2016 10:21, Rodney M. Bates escribi?: I'm not sure I fully understand.? You propose to have the front-end run on a tablet, code generation run on a remote server?? Presumably because the tablet lacks sufficient hardware resources?? Then the code executes where, back on the tablet? Personally, I find editing/developing code without a real keyboard to be so hopelessly painful, I just wouldn't do it.? Touch screens have exasperatingly high false positive, false negative, and wrong gesture recognition.? Maybe I have different hand capacitance than most people.? I would prefer to do the editing off the tablet, in which case, it would make sense that the front-end compiling be done on the compile server too. On 05/03/2016 08:38 PM, Daniel Alejandro Benavides D. wrote: > Hi floks: > Does anyone think in a Cross Platform development environment system; for instance: > 1. I have a compiler front end in my tablet (say yet to be finished M3clipse) that creates an AST, > 2. and sent to generate code for certain platform (in a CM3-IDE of SRC M3 compiler server) to a given target, > 3. Download it and execute it in a terminal or windows client? > > I finally have resources in hardware to make some development, and looking forward to see get the best idea I can implement. > > thanks in advance > > > _______________________________________________ > 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From dabenavidesd at yahoo.es Sat May 14 20:23:42 2016 From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.) Date: Sat, 14 May 2016 18:23:42 +0000 (UTC) Subject: [M3devel] A possible source, target References: <671131443.3734750.1463250222583.JavaMail.yahoo.ref@mail.yahoo.com> Message-ID: <671131443.3734750.1463250222583.JavaMail.yahoo@mail.yahoo.com> Hello:if you mind; what about supporting cross development like this platform: PINE64, the World's First 64-Bit Expandable Supercomputer, Runs Ubuntu and Android 5.1 | ? | | ? | | ? | ? | ? | ? | ? | | PINE64, the World's First 64-Bit Expandable Supercomp...It can also run OpenWrt Linux and openHUB | | | | Ver en news.softpedia.com | Vista previa por Yahoo | | | | ? | just for U$15/?14Thanks in advance -------------- next part -------------- An HTML attachment was scrubbed... URL: From peter.mckinna at gmail.com Mon May 23 04:28:05 2016 From: peter.mckinna at gmail.com (Peter McKinna) Date: Mon, 23 May 2016 12:28:05 +1000 Subject: [M3devel] cm3cg failing on linuxlibc6 Message-ID: I dont know what changed but the backend is crashing on linuxlibc6 when compiled with -O Try compiling m3core. Also some of my low level tests with Long.And and Long.Shift are not working with normal compile without the optimisations on that platform. Bit suspicious. I'm still investigating. Anyone got any clues or can replicate? Thanks Peter -------------- next part -------------- An HTML attachment was scrubbed... URL: From rodney_bates at lcwb.coop Mon May 23 20:40:19 2016 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Mon, 23 May 2016 13:40:19 -0500 Subject: [M3devel] cm3cg failing on linuxlibc6 Message-ID: <57434E93.2030205@lcwb.coop> I did git pull and rebuilt on LINUXLIBC6. The built cm3 executable crashes compiling a very small experiment program: rodney at yellowstone:~/proj/m3/exp/FmtBug/src$ cm3- Segmentation fault (core dumped) m3gdb (after I built it) gives this: rodney at yellowstone:~/proj/m3/exp/FmtBug/src$ m3gdb cm3- GNU gdb plus Modula-3 6.4 Copyright 2005 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i686-pc-linux-gnu"...Using host libthread_db library "/lib/tls/i686/cmov/libthread_db.so.1". (m3gdb) run Starting program: /usr/local/cm3-githead/bin/cm3- [Thread debugging using libthread_db enabled] [New LWP 23615] [New Thread -1216829744 (LWP 23615)] Program received signal SIGSEGV, Segmentation fault. [Switching to Thread -1216829744 (LWP 23615)] 0x0037c26f in siglongjmp () from /lib/tls/i686/cmov/libc.so.6 (m3gdb) bt #0 0x0037c26f in siglongjmp () from /lib/tls/i686/cmov/libc.so.6 #1 0x577b2a84 in ?? () Cannot access memory at address 0xd7a0906f (m3gdb) quit stock gdb gives even less information: rodney at yellowstone:~/proj/m3/exp/FmtBug/src$ gdb cm3- GNU gdb (GDB) 7.1-ubuntu Copyright (C) 2010 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "i486-linux-gnu". For bug reporting instructions, please see: ... Reading symbols from /usr/local/cm3-githead/bin/cm3-...done. (gdb) run Starting program: /usr/local/cm3-githead/bin/cm3- [Thread debugging using libthread_db enabled] Program received signal SIGSEGV, Segmentation fault. 0x0032e26f in ?? () from /lib/tls/i686/cmov/libc.so.6 (gdb) bt #0 0x0032e26f in ?? () from /lib/tls/i686/cmov/libc.so.6 #1 0xfb35d04b in ?? () Cannot access memory at address 0x7bee2da0 (gdb) Note that gdb gives a different address in the same library for the point of fault. m3gdb claims it's in siglongjmp. I recall there were some recent changes involving longjump. On 05/22/2016 09:28 PM, Peter McKinna wrote: > I dont know what changed but the backend is crashing on linuxlibc6 when compiled with -O Try compiling m3core. > > Also some of my low level tests with Long.And and Long.Shift are not working with > normal compile without the optimisations on that platform. Bit suspicious. I'm still investigating. > > Anyone got any clues or can replicate? > > Thanks 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 peter.mckinna at gmail.com Tue May 24 09:24:52 2016 From: peter.mckinna at gmail.com (Peter McKinna) Date: Tue, 24 May 2016 17:24:52 +1000 Subject: [M3devel] cm3cg failing on linuxlibc6 In-Reply-To: <57434E93.2030205@lcwb.coop> References: <57434E93.2030205@lcwb.coop> Message-ID: I may have been a tad hasty in blaming the back end for the crashes, the front end has some explaining to do as well. I was getting an infinite loop in a program which I have cut down here to demonstrate. The original cm3 5.2 I think it was from elegosoft worked fine. The latest produces different intermediate code. First the source, (excuse the size, its extracted from my implementation of grisu which I was on the point of pushing to github) MODULE Main; IMPORT Long,IO,Fmt; CONST kUint64MSB = 16_8000000000000000L; TYPE Uint64 = Long.T; PROCEDURE Normalize(sig : Long.T; exp : INTEGER) = CONST k10MSBits = 16_FFC0000000000000L; VAR significand : Uint64; exponent : INTEGER; BEGIN <*ASSERT sig # 0L *> significand := sig; exponent := exp; (*IO.Put("sig init " & Fmt.LongInt(significand) & "\n");*) (* This method is mainly called for normalizing boundaries. In general boundaries need to be shifted by 10 bits. We thus optimize for this case. *) WHILE Long.And(significand, k10MSBits) = 0L DO significand := Long.LeftShift(significand, 10); (*IO.Put("sig loop 1 " & Fmt.LongInt(significand) & "\n");*) DEC(exponent, 10); END; (*IO.Put("sig after loop 1 " & Fmt.LongInt(significand) & "\n");*) (* IO.PutLongInt(Long.And(significand, kUint64MSB)); IO.Put("\n"); *) WHILE Long.And(significand, kUint64MSB) = 0L DO (*IO.Put("sig loop2 1 " & Fmt.LongInt(significand) & "\n");*) significand := Long.LeftShift(significand, 1); (*IO.Put("sig loop2 2 " & Fmt.LongInt(significand) & "\n");*) DEC(exponent); END; END Normalize; BEGIN Normalize(3L,2); END Main. Now the correct intermediate from the original cm3 Its a shame we cant embed the cm3 version into the intermediate. But theres no mention of widechar so you can tell its an old version. begin_unit 0 -----FILE ../src/Main.m3 ----- -----LINE 1 ----- # module global constants declare_segment * -1 T v.1 # module global data declare_segment M_Main -1 F v.2 -----LINE 45 ----- declare_procedure Main_M3 1 Addr 0 0 T * p.1 declare_param mode 4 4 Int.32 425470580 F F 100 v.3 declare_proctype 1318003907 2 0 0 0 declare_formal sig 89530742 declare_formal exp 425470580 import_procedure Main_I3 0 Addr 0 p.2 export_unit Main import_procedure Fmt_I3 0 Addr 0 p.3 import_unit Fmt import_procedure IO_I3 0 Addr 0 p.4 import_unit IO import_procedure Long_I3 0 Addr 0 p.5 import_unit Long import_procedure RTHooks_I3 0 Addr 0 p.6 import_unit RTHooks declare_typename 89530742 Uint64 declare_procedure Main__Normalize 2 Void 0 0 F * p.7 declare_local significand 8 4 Int.64 89530742 F F 50 v.4 declare_local exponent 4 4 Int.32 425470580 F F 50 v.5 declare_param sig 8 4 Int.64 89530742 F F 50 v.6 declare_param exp 4 4 Int.32 425470580 F F 50 v.7 # Normalize -----LINE 11 ----- begin_procedure p.7 -----LINE 12 ----- -----LINE 19 ----- load v.6 0 Int.64 Int.64 load_integer Int.64 0 if_ne Int.64 L.1 100 import_procedure RTHooks__ReportFault 2 Void 0 p.8 declare_param module 4 4 Addr 138420323 F F 50 v.8 declare_param info 4 4 Int.32 425470580 F F 50 v.9 set_runtime_proc ReportFault p.8 abort 0 . L.1 F -----LINE 20 ----- load v.6 0 Int.64 Int.64 store v.4 0 Int.64 Int.64 -----LINE 21 ----- load v.7 0 Int.32 Int.32 store v.5 0 Int.32 Int.32 -----LINE 26 ----- jump L.2 . L.3 F -----LINE 27 ----- load v.4 0 Int.64 Int.64 load_integer Int.32 10 shift_left Int.64 store v.4 0 Int.64 Int.64 -----LINE 29 ----- load v.5 0 Int.32 Int.32 load_integer Int.32 10 subtract Int.32 store v.5 0 Int.32 Int.32 -----LINE 26 ----- . L.2 F load v.4 0 Int.64 Int.64 load_integer Int.64 -18014398509481984 and Int.64 load_integer Int.64 0 if_eq Int.64 L.3 80 . L.4 F -----LINE 36 ----- jump L.5 . L.6 F -----LINE 38 ----- load v.4 0 Int.64 Int.64 load_integer Int.32 1 shift_left Int.64 store v.4 0 Int.64 Int.64 -----LINE 40 ----- load v.5 0 Int.32 Int.32 load_integer Int.32 1 subtract Int.32 store v.5 0 Int.32 Int.32 -----LINE 36 ----- . L.5 F load v.4 0 Int.64 Int.64 load_integer Int.64 -9223372036854775808 and Int.64 load_integer Int.64 0 if_eq Int.64 L.6 80 . L.7 F -----LINE 43 ----- exit_proc Void end_procedure p.7 # Main_M3 # module main body Main_M3 -----LINE 45 ----- begin_procedure p.1 load v.3 0 Int.32 Int.32 if_false Int.32 L.8 0 -----LINE 47 ----- start_call_direct p.7 0 Void load_integer Int.64 3 pop_param Int.64 load_integer Int.32 2 pop_param Int.32 call_direct p.7 Void . L.8 F load_address v.2 0 exit_proc Addr end_procedure p.1 # global constant type descriptor declare_record -1 448 0 # global data type descriptor declare_record -1 896 0 # module global constants bind_segment v.1 56 4 Struct F T begin_init v.1 # procedure names init_chars 0 "Main_M3" init_chars 8 "Normalize" # procedure table init_proc 20 p.1 init_var 24 v.1 0 init_proc 28 p.7 init_var 32 v.1 8 # file name init_chars 40 "../src/Main.m3" end_init v.1 # module global data bind_segment v.2 112 4 Struct F T begin_init v.2 init_var 0 v.1 40 init_var 20 v.1 20 init_var 36 v.2 52 init_proc 44 p.1 init_int 48 3 Int.32 init_proc 56 p.2 init_var 60 v.2 64 init_proc 68 p.3 init_var 72 v.2 76 init_proc 80 p.4 init_var 84 v.2 88 init_proc 92 p.5 init_var 96 v.2 100 init_proc 104 p.6 end_init v.2 # load map # # # global data allocation for M_Main # 0 52 4 *module info* # 52 12 4 import Main # 64 12 4 import Fmt # 76 12 4 import IO # 88 12 4 import Long # 100 12 4 import RTHooks # 112 0 4 *TOTAL* # # # global constants for M_Main # 0 18 4 *proc names* # 20 20 4 *proc info* # 40 15 1 *string* # 56 0 4 *TOTAL* # end_unit Now the intermediate from the latest compiler begin_unit 0 widechar_size 16 -----FILE ../src/Main.m3 ----- -----LINE 1 ----- # module global constants declare_segment * -1 T v.1 # module global data declare_segment M_Main -1 F v.2 -----LINE 45 ----- declare_procedure Main_M3 1 Addr 0 0 T * p.1 declare_param mode 4 4 Int.32 425470580 F F 100 v.3 declare_proctype 1318003907 2 0 0 0 declare_formal sig 89530742 declare_formal exp 425470580 import_procedure Main_I3 0 Addr 0 p.2 export_unit Main import_procedure Fmt_I3 0 Addr 0 p.3 import_unit Fmt import_procedure IO_I3 0 Addr 0 p.4 import_unit IO import_procedure Long_I3 0 Addr 0 p.5 import_unit Long import_procedure RTHooks_I3 0 Addr 0 p.6 import_unit RTHooks declare_typename 89530742 Uint64 declare_procedure Main__Normalize 2 Void 0 0 F * p.7 declare_local significand 8 8 Int.64 89530742 F F 50 v.4 declare_local exponent 4 4 Int.32 425470580 F F 50 v.5 declare_param sig 8 8 Int.64 89530742 F F 50 v.6 declare_param exp 4 4 Int.32 425470580 F F 50 v.7 # Normalize -----LINE 11 ----- begin_procedure p.7 -----LINE 12 ----- -----LINE 19 ----- load_integer Int.64 0 load v.6 0 Int.64 Int.64 if_ne Int.64 L.1 100 declare_proctype -1531209598 2 0 -1 0 declare_formal module 138420323 declare_formal info 425470580 import_procedure RTHooks__ReportFault 2 Void 0 p.8 declare_param module 4 4 Addr 138420323 F F 50 v.8 declare_param info 4 4 Int.32 425470580 F F 50 v.9 set_runtime_proc ReportFault p.8 abort 0 . L.1 F -----LINE 20 ----- load v.6 0 Int.64 Int.64 store v.4 0 Int.64 Int.64 -----LINE 21 ----- load v.7 0 Int.32 Int.32 store v.5 0 Int.32 Int.32 -----LINE 26 ----- jump L.2 . L.3 F -----LINE 27 ----- load v.4 0 Int.64 Int.64 load_integer Int.32 10 shift_left Word.64 store v.4 0 Int.64 Int.64 -----LINE 29 ----- load v.5 0 Int.32 Int.32 load_integer Int.32 10 subtract Int.32 store v.5 0 Int.32 Int.32 -----LINE 26 ----- . L.2 F load_integer Int.64 -18014398509481984 load v.4 0 Int.64 Int.64 and Word.64 load_integer Int.64 0 if_eq Int.64 L.3 80 . L.4 F -----LINE 36 ----- jump L.5 . L.6 F -----LINE 38 ----- load v.4 0 Int.64 Int.64 load_integer Int.32 1 shift_left Word.64 store v.4 0 Int.64 Int.64 -----LINE 40 ----- load v.5 0 Int.32 Int.32 load_integer Int.32 1 subtract Int.32 store v.5 0 Int.32 Int.32 -----LINE 36 ----- . L.5 F load_integer Int.64 0 load v.4 0 Int.64 Int.64 and Word.64 load_integer Int.64 0 if_eq Int.64 L.6 80 . L.7 F -----LINE 43 ----- exit_proc Void end_procedure p.7 # Main_M3 # module main body Main_M3 -----LINE 45 ----- begin_procedure p.1 load v.3 0 Int.32 Int.32 if_false Int.32 L.8 0 -----LINE 47 ----- start_call_direct p.7 0 Void load_integer Int.64 3 pop_param Int.64 load_integer Int.32 2 pop_param Int.32 call_direct p.7 Void . L.8 F load_address v.2 0 exit_proc Addr end_procedure p.1 # global constant type descriptor declare_record -1 448 0 # global data type descriptor declare_record -1 896 0 # module global constants bind_segment v.1 56 8 Struct F T begin_init v.1 # procedure names init_chars 0 "Main_M3" init_chars 8 "Normalize" # procedure table init_proc 20 p.1 init_var 24 v.1 0 init_proc 28 p.7 init_var 32 v.1 8 # file name init_chars 40 "../src/Main.m3" end_init v.1 # module global data bind_segment v.2 112 8 Struct F T begin_init v.2 init_var 0 v.1 40 init_var 20 v.1 20 init_var 36 v.2 52 init_proc 44 p.1 init_int 48 3 Int.32 init_proc 56 p.2 init_var 60 v.2 64 init_proc 68 p.3 init_var 72 v.2 76 init_proc 80 p.4 init_var 84 v.2 88 init_proc 92 p.5 init_var 96 v.2 100 init_proc 104 p.6 end_init v.2 # load map # # # global data allocation for M_Main # 0 52 4 *module info* # 52 12 4 import Main # 64 12 4 import Fmt # 76 12 4 import IO # 88 12 4 import Long # 100 12 4 import RTHooks # 112 0 4 *TOTAL* # # # global constants for M_Main # 0 18 4 *proc names* # 20 20 4 *proc info* # 40 15 1 *string* # 56 0 4 *TOTAL* # end_unit Its very similar except for using Word.64 instead of Int.64 and a couple of other cosmetic issues. The trouble is near label L5 where it does a load_integer of 0 instead of the big constant. The result of anding the zero and testing for zero is causing the loop. Compiling this with -O also causes the backend to crash. Both of these are on LINUXLIBC6. The AMD64 intermediate is correct. Seems like its not parsing the big long for some reason or else its wrapping around. Any ideas? Regards Peter On Tue, May 24, 2016 at 4:40 AM, Rodney M. Bates wrote: > > > > I did git pull and rebuilt on LINUXLIBC6. The built cm3 executable > crashes compiling > a very small experiment program: > > rodney at yellowstone:~/proj/m3/exp/FmtBug/src$ cm3- > Segmentation fault (core dumped) > > m3gdb (after I built it) gives this: > > rodney at yellowstone:~/proj/m3/exp/FmtBug/src$ m3gdb cm3- > GNU gdb plus Modula-3 6.4 > Copyright 2005 Free Software Foundation, Inc. > GDB is free software, covered by the GNU General Public License, and you > are > welcome to change it and/or distribute copies of it under certain > conditions. > Type "show copying" to see the conditions. > There is absolutely no warranty for GDB. Type "show warranty" for > details. > This GDB was configured as "i686-pc-linux-gnu"...Using host libthread_db > library "/lib/tls/i686/cmov/libthread_db.so.1". > > (m3gdb) run > Starting program: /usr/local/cm3-githead/bin/cm3- > [Thread debugging using libthread_db enabled] > [New LWP 23615] > [New Thread -1216829744 (LWP 23615)] > > Program received signal SIGSEGV, Segmentation fault. > [Switching to Thread -1216829744 (LWP 23615)] > 0x0037c26f in siglongjmp () from /lib/tls/i686/cmov/libc.so.6 > (m3gdb) bt > #0 0x0037c26f in siglongjmp () from /lib/tls/i686/cmov/libc.so.6 > #1 0x577b2a84 in ?? () > Cannot access memory at address 0xd7a0906f > (m3gdb) quit > > > stock gdb gives even less information: > > rodney at yellowstone:~/proj/m3/exp/FmtBug/src$ gdb cm3- > GNU gdb (GDB) 7.1-ubuntu > Copyright (C) 2010 Free Software Foundation, Inc. > License GPLv3+: GNU GPL version 3 or later < > http://gnu.org/licenses/gpl.html> > This is free software: you are free to change and redistribute it. > There is NO WARRANTY, to the extent permitted by law. Type "show > copying" > and "show warranty" for details. > This GDB was configured as "i486-linux-gnu". > For bug reporting instructions, please see: > ... > Reading symbols from /usr/local/cm3-githead/bin/cm3-...done. > (gdb) run > Starting program: /usr/local/cm3-githead/bin/cm3- > [Thread debugging using libthread_db enabled] > > Program received signal SIGSEGV, Segmentation fault. > 0x0032e26f in ?? () from /lib/tls/i686/cmov/libc.so.6 > (gdb) bt > #0 0x0032e26f in ?? () from /lib/tls/i686/cmov/libc.so.6 > #1 0xfb35d04b in ?? () > Cannot access memory at address 0x7bee2da0 > (gdb) > > Note that gdb gives a different address in the same library for the point > of fault. > > m3gdb claims it's in siglongjmp. I recall there were some recent changes > involving > longjump. > > > > > > > On 05/22/2016 09:28 PM, Peter McKinna wrote: > > I dont know what changed but the backend is crashing on linuxlibc6 when > compiled with -O Try compiling m3core. > > > > Also some of my low level tests with Long.And and Long.Shift are not > working with > > normal compile without the optimisations on that platform. Bit > suspicious. I'm still investigating. > > > > Anyone got any clues or can replicate? > > > > Thanks 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rodney_bates at lcwb.coop Thu May 26 05:58:11 2016 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Wed, 25 May 2016 22:58:11 -0500 Subject: [M3devel] cm3cg failing on linuxlibc6 In-Reply-To: References: <57434E93.2030205@lcwb.coop> Message-ID: <57467453.4040702@lcwb.coop> Just an FYI on the And bug. I think I have diagnosed this for this particular case. TInt.ToBytes is following the invariants of a TInt.T, which always uses twos-complement notation, but, with a 9th byte, is big enough to hold the entire overlap of the 64-bit signed and unsigned ranges. OTOH, M3CG_BinWr.AddBigX is converting to signed-magnitude, with a separate sign. It passes an absolute value to ToBytes. For only this single value 16_8000000000000000, this is representable as a positive absolute value in 8 bytes, but ToBytes correctly considers this too few bytes for twos-complement and returns zero. It will take more work to look at all the calls on ToBytes and ascertain which cases suffer this mismatch. Also, I am currently unable to build a working compiler for LINUXLIBC6, something to do with jumbufs. So I will have to get around that before testing a fix and for regressions. It looks like it doesn't happen when compiling on a 64-bit machine because that takes a different path, using native INTEGER rather than TInt for the constant value. On 05/24/2016 02:24 AM, Peter McKinna wrote: > I may have been a tad hasty in blaming the back end for the crashes, the front end has some explaining to do as well. > > I was getting an infinite loop in a program which I have cut down here to demonstrate. The original cm3 5.2 I think it > was from elegosoft worked fine. The latest produces different intermediate code. > > First the source, (excuse the size, its extracted from my implementation of grisu which I was on the point of pushing to github) > > MODULE Main; > > IMPORT Long,IO,Fmt; > > CONST > kUint64MSB = 16_8000000000000000L; > > TYPE > Uint64 = Long.T; > PROCEDURE Normalize(sig : Long.T; exp : INTEGER) = > CONST > k10MSBits = 16_FFC0000000000000L; > VAR > significand : Uint64; > exponent : INTEGER; > > BEGIN > <*ASSERT sig # 0L *> > significand := sig; > exponent := exp; > (*IO.Put("sig init " & Fmt.LongInt(significand) & "\n");*) > > (* This method is mainly called for normalizing boundaries. In general > boundaries need to be shifted by 10 bits. We thus optimize for this case. *) > WHILE Long.And(significand, k10MSBits) = 0L DO > significand := Long.LeftShift(significand, 10); > (*IO.Put("sig loop 1 " & Fmt.LongInt(significand) & "\n");*) > DEC(exponent, 10); > END; > (*IO.Put("sig after loop 1 " & Fmt.LongInt(significand) & "\n");*) > (* > IO.PutLongInt(Long.And(significand, kUint64MSB)); > IO.Put("\n"); > *) > WHILE Long.And(significand, kUint64MSB) = 0L DO > (*IO.Put("sig loop2 1 " & Fmt.LongInt(significand) & "\n");*) > significand := Long.LeftShift(significand, 1); > (*IO.Put("sig loop2 2 " & Fmt.LongInt(significand) & "\n");*) > DEC(exponent); > END; > END Normalize; > BEGIN > > Normalize(3L,2); > END Main. > > Now the correct intermediate from the original cm3 > Its a shame we cant embed the cm3 version into the intermediate. But theres no mention of widechar so you can tell its an old > version. > > begin_unit0 > -----FILE ../src/Main.m3 ----- > -----LINE 1 ----- > # module global constants > declare_segment* -1 T v.1 > # module global data > declare_segmentM_Main -1 F v.2 > -----LINE 45 ----- > declare_procedureMain_M3 1 Addr 0 0 T * p.1 > declare_parammode 4 4 Int.32 425470580 F F 100 v.3 > declare_proctype1318003907 2 0 0 0 > declare_formalsig 89530742 > declare_formalexp 425470580 > import_procedureMain_I3 0 Addr 0 p.2 > export_unitMain > import_procedureFmt_I3 0 Addr 0 p.3 > import_unitFmt > import_procedureIO_I3 0 Addr 0 p.4 > import_unitIO > import_procedureLong_I3 0 Addr 0 p.5 > import_unitLong > import_procedureRTHooks_I3 0 Addr 0 p.6 > import_unitRTHooks > declare_typename89530742 Uint64 > declare_procedureMain__Normalize 2 Void 0 0 F * p.7 > declare_localsignificand 8 4 Int.64 89530742 F F 50 v.4 > declare_localexponent 4 4 Int.32 425470580 F F 50 v.5 > declare_paramsig 8 4 Int.64 89530742 F F 50 v.6 > declare_paramexp 4 4 Int.32 425470580 F F 50 v.7 > # Normalize > -----LINE 11 ----- > begin_procedurep.7 > -----LINE 12 ----- > -----LINE 19 ----- > loadv.6 0 Int.64 Int.64 > load_integerInt.64 0 > if_neInt.64 L.1 100 > import_procedureRTHooks__ReportFault 2 Void 0 p.8 > declare_parammodule 4 4 Addr 138420323 F F 50 v.8 > declare_paraminfo 4 4 Int.32 425470580 F F 50 v.9 > set_runtime_procReportFault p.8 > abort0 > . L.1 F > -----LINE 20 ----- > loadv.6 0 Int.64 Int.64 > storev.4 0 Int.64 Int.64 > -----LINE 21 ----- > loadv.7 0 Int.32 Int.32 > storev.5 0 Int.32 Int.32 > -----LINE 26 ----- > jumpL.2 > . L.3 F > -----LINE 27 ----- > loadv.4 0 Int.64 Int.64 > load_integerInt.32 10 > shift_leftInt.64 > storev.4 0 Int.64 Int.64 > -----LINE 29 ----- > loadv.5 0 Int.32 Int.32 > load_integerInt.32 10 > subtractInt.32 > storev.5 0 Int.32 Int.32 > -----LINE 26 ----- > . L.2 F > loadv.4 0 Int.64 Int.64 > load_integerInt.64 -18014398509481984 > andInt.64 > load_integerInt.64 0 > if_eqInt.64 L.3 80 > . L.4 F > -----LINE 36 ----- > jumpL.5 > . L.6 F > -----LINE 38 ----- > loadv.4 0 Int.64 Int.64 > load_integerInt.32 1 > shift_leftInt.64 > storev.4 0 Int.64 Int.64 > -----LINE 40 ----- > loadv.5 0 Int.32 Int.32 > load_integerInt.32 1 > subtractInt.32 > storev.5 0 Int.32 Int.32 > -----LINE 36 ----- > . L.5 F > loadv.4 0 Int.64 Int.64 > load_integerInt.64 -9223372036854775808 > andInt.64 > load_integerInt.64 0 > if_eqInt.64 L.6 80 > . L.7 F > -----LINE 43 ----- > exit_procVoid > end_procedurep.7 > # Main_M3 > # module main body Main_M3 > -----LINE 45 ----- > begin_procedurep.1 > loadv.3 0 Int.32 Int.32 > if_falseInt.32 L.8 0 > -----LINE 47 ----- > start_call_directp.7 0 Void > load_integerInt.64 3 > pop_paramInt.64 > load_integerInt.32 2 > pop_paramInt.32 > call_directp.7 Void > . L.8 F > load_addressv.2 0 > exit_procAddr > end_procedurep.1 > # global constant type descriptor > declare_record-1 448 0 > # global data type descriptor > declare_record-1 896 0 > # module global constants > bind_segmentv.1 56 4 Struct F T > begin_initv.1 > # procedure names > init_chars0 "Main_M3" > init_chars8 "Normalize" > # procedure table > init_proc20 p.1 > init_var24 v.1 0 > init_proc28 p.7 > init_var32 v.1 8 > # file name > init_chars40 "../src/Main.m3" > end_initv.1 > # module global data > bind_segmentv.2 112 4 Struct F T > begin_initv.2 > init_var0 v.1 40 > init_var20 v.1 20 > init_var36 v.2 52 > init_proc44 p.1 > init_int48 3 Int.32 > init_proc56 p.2 > init_var60 v.2 64 > init_proc68 p.3 > init_var72 v.2 76 > init_proc80 p.4 > init_var84 v.2 88 > init_proc92 p.5 > init_var96 v.2 100 > init_proc104 p.6 > end_initv.2 > # load map > # > # > # global data allocation for M_Main > # 0 52 4 *module info* > # 52 12 4 import Main > # 64 12 4 import Fmt > # 76 12 4 import IO > # 88 12 4 import Long > # 100 12 4 import RTHooks > # 112 0 4 *TOTAL* > # > # > # global constants for M_Main > # 0 18 4 *proc names* > # 20 20 4 *proc info* > # 40 15 1 *string* > # 56 0 4 *TOTAL* > # > end_unit > > > Now the intermediate from the latest compiler > > begin_unit0 > widechar_size16 > -----FILE ../src/Main.m3 ----- > -----LINE 1 ----- > # module global constants > declare_segment* -1 T v.1 > # module global data > declare_segmentM_Main -1 F v.2 > -----LINE 45 ----- > declare_procedureMain_M3 1 Addr 0 0 T * p.1 > declare_parammode 4 4 Int.32 425470580 F F 100 v.3 > declare_proctype1318003907 2 0 0 0 > declare_formalsig 89530742 > declare_formalexp 425470580 > import_procedureMain_I3 0 Addr 0 p.2 > export_unitMain > import_procedureFmt_I3 0 Addr 0 p.3 > import_unitFmt > import_procedureIO_I3 0 Addr 0 p.4 > import_unitIO > import_procedureLong_I3 0 Addr 0 p.5 > import_unitLong > import_procedureRTHooks_I3 0 Addr 0 p.6 > import_unitRTHooks > declare_typename89530742 Uint64 > declare_procedureMain__Normalize 2 Void 0 0 F * p.7 > declare_localsignificand 8 8 Int.64 89530742 F F 50 v.4 > declare_localexponent 4 4 Int.32 425470580 F F 50 v.5 > declare_paramsig 8 8 Int.64 89530742 F F 50 v.6 > declare_paramexp 4 4 Int.32 425470580 F F 50 v.7 > # Normalize > -----LINE 11 ----- > begin_procedurep.7 > -----LINE 12 ----- > -----LINE 19 ----- > load_integerInt.64 0 > loadv.6 0 Int.64 Int.64 > if_neInt.64 L.1 100 > declare_proctype-1531209598 2 0 -1 0 > declare_formalmodule 138420323 > declare_formalinfo 425470580 > import_procedureRTHooks__ReportFault 2 Void 0 p.8 > declare_parammodule 4 4 Addr 138420323 F F 50 v.8 > declare_paraminfo 4 4 Int.32 425470580 F F 50 v.9 > set_runtime_procReportFault p.8 > abort0 > . L.1 F > -----LINE 20 ----- > loadv.6 0 Int.64 Int.64 > storev.4 0 Int.64 Int.64 > -----LINE 21 ----- > loadv.7 0 Int.32 Int.32 > storev.5 0 Int.32 Int.32 > -----LINE 26 ----- > jumpL.2 > . L.3 F > -----LINE 27 ----- > loadv.4 0 Int.64 Int.64 > load_integerInt.32 10 > shift_leftWord.64 > storev.4 0 Int.64 Int.64 > -----LINE 29 ----- > loadv.5 0 Int.32 Int.32 > load_integerInt.32 10 > subtractInt.32 > storev.5 0 Int.32 Int.32 > -----LINE 26 ----- > . L.2 F > load_integerInt.64 -18014398509481984 > loadv.4 0 Int.64 Int.64 > andWord.64 > load_integerInt.64 0 > if_eqInt.64 L.3 80 > . L.4 F > -----LINE 36 ----- > jumpL.5 > . L.6 F > -----LINE 38 ----- > loadv.4 0 Int.64 Int.64 > load_integerInt.32 1 > shift_leftWord.64 > storev.4 0 Int.64 Int.64 > -----LINE 40 ----- > loadv.5 0 Int.32 Int.32 > load_integerInt.32 1 > subtractInt.32 > storev.5 0 Int.32 Int.32 > -----LINE 36 ----- > . L.5 F > load_integerInt.64 0 > loadv.4 0 Int.64 Int.64 > andWord.64 > load_integerInt.64 0 > if_eqInt.64 L.6 80 > . L.7 F > -----LINE 43 ----- > exit_procVoid > end_procedurep.7 > # Main_M3 > # module main body Main_M3 > -----LINE 45 ----- > begin_procedurep.1 > loadv.3 0 Int.32 Int.32 > if_falseInt.32 L.8 0 > -----LINE 47 ----- > start_call_directp.7 0 Void > load_integerInt.64 3 > pop_paramInt.64 > load_integerInt.32 2 > pop_paramInt.32 > call_directp.7 Void > . L.8 F > load_addressv.2 0 > exit_procAddr > end_procedurep.1 > # global constant type descriptor > declare_record-1 448 0 > # global data type descriptor > declare_record-1 896 0 > # module global constants > bind_segmentv.1 56 8 Struct F T > begin_initv.1 > # procedure names > init_chars0 "Main_M3" > init_chars8 "Normalize" > # procedure table > init_proc20 p.1 > init_var24 v.1 0 > init_proc28 p.7 > init_var32 v.1 8 > # file name > init_chars40 "../src/Main.m3" > end_initv.1 > # module global data > bind_segmentv.2 112 8 Struct F T > begin_initv.2 > init_var0 v.1 40 > init_var20 v.1 20 > init_var36 v.2 52 > init_proc44 p.1 > init_int48 3 Int.32 > init_proc56 p.2 > init_var60 v.2 64 > init_proc68 p.3 > init_var72 v.2 76 > init_proc80 p.4 > init_var84 v.2 88 > init_proc92 p.5 > init_var96 v.2 100 > init_proc104 p.6 > end_initv.2 > # load map > # > # > # global data allocation for M_Main > # 0 52 4 *module info* > # 52 12 4 import Main > # 64 12 4 import Fmt > # 76 12 4 import IO > # 88 12 4 import Long > # 100 12 4 import RTHooks > # 112 0 4 *TOTAL* > # > # > # global constants for M_Main > # 0 18 4 *proc names* > # 20 20 4 *proc info* > # 40 15 1 *string* > # 56 0 4 *TOTAL* > # > end_unit > > > Its very similar except for using Word.64 instead of Int.64 and a couple of other cosmetic issues. > The trouble is near label L5 where it does a load_integer of 0 instead of the big constant. > The result of anding the zero and testing for zero is causing the loop. > Compiling this with -O also causes the backend to crash. > Both of these are on LINUXLIBC6. The AMD64 intermediate is correct. Seems like its not parsing the > big long for some reason or else its wrapping around. > > Any ideas? > > Regards Peter > > > > On Tue, May 24, 2016 at 4:40 AM, Rodney M. Bates > wrote: > > > > > I did git pull and rebuilt on LINUXLIBC6. The built cm3 executable crashes compiling > a very small experiment program: > > rodney at yellowstone:~/proj/m3/exp/FmtBug/src$ cm3- > Segmentation fault (core dumped) > > m3gdb (after I built it) gives this: > > rodney at yellowstone:~/proj/m3/exp/FmtBug/src$ m3gdb cm3- > GNU gdb plus Modula-3 6.4 > Copyright 2005 Free Software Foundation, Inc. > GDB is free software, covered by the GNU General Public License, and you are > welcome to change it and/or distribute copies of it under certain conditions. > Type "show copying" to see the conditions. > There is absolutely no warranty for GDB. Type "show warranty" for details. > This GDB was configured as "i686-pc-linux-gnu"...Using host libthread_db library "/lib/tls/i686/cmov/libthread_db.so.1". > > (m3gdb) run > Starting program: /usr/local/cm3-githead/bin/cm3- > [Thread debugging using libthread_db enabled] > [New LWP 23615] > [New Thread -1216829744 (LWP 23615)] > > Program received signal SIGSEGV, Segmentation fault. > [Switching to Thread -1216829744 (LWP 23615)] > 0x0037c26f in siglongjmp () from /lib/tls/i686/cmov/libc.so.6 > (m3gdb) bt > #0 0x0037c26f in siglongjmp () from /lib/tls/i686/cmov/libc.so.6 > #1 0x577b2a84 in ?? () > Cannot access memory at address 0xd7a0906f > (m3gdb) quit > > > stock gdb gives even less information: > > rodney at yellowstone:~/proj/m3/exp/FmtBug/src$ gdb cm3- > GNU gdb (GDB) 7.1-ubuntu > Copyright (C) 2010 Free Software Foundation, Inc. > License GPLv3+: GNU GPL version 3 or later > This is free software: you are free to change and redistribute it. > There is NO WARRANTY, to the extent permitted by law. Type "show copying" > and "show warranty" for details. > This GDB was configured as "i486-linux-gnu". > For bug reporting instructions, please see: > ... > Reading symbols from /usr/local/cm3-githead/bin/cm3-...done. > (gdb) run > Starting program: /usr/local/cm3-githead/bin/cm3- > [Thread debugging using libthread_db enabled] > > Program received signal SIGSEGV, Segmentation fault. > 0x0032e26f in ?? () from /lib/tls/i686/cmov/libc.so.6 > (gdb) bt > #0 0x0032e26f in ?? () from /lib/tls/i686/cmov/libc.so.6 > #1 0xfb35d04b in ?? () > Cannot access memory at address 0x7bee2da0 > (gdb) > > Note that gdb gives a different address in the same library for the point of fault. > > m3gdb claims it's in siglongjmp. I recall there were some recent changes involving > longjump. > > > > > > > On 05/22/2016 09:28 PM, Peter McKinna wrote: > > I dont know what changed but the backend is crashing on linuxlibc6 when compiled with -O Try compiling m3core. > > > > Also some of my low level tests with Long.And and Long.Shift are not working with > > normal compile without the optimisations on that platform. Bit suspicious. I'm still investigating. > > > > Anyone got any clues or can replicate? > > > > Thanks 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 Thu May 26 19:03:46 2016 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Thu, 26 May 2016 12:03:46 -0500 Subject: [M3devel] cm3cg failing on linuxlibc6 In-Reply-To: References: <57434E93.2030205@lcwb.coop> <57467453.4040702@lcwb.coop> Message-ID: <57472C72.8090904@lcwb.coop> I am getting this output from your example, with the output commented back in: sig init 3 sig loop 1 3072 sig loop 1 3145728 sig loop 1 3221225472 sig loop 1 3298534883328 sig loop 1 3377699720527872 sig loop 1 3458764513820540928 sig after loop 1 3458764513820540928 0 sig loop2 1 3458764513820540928 sig loop2 2 6917529027641081856 sig loop2 1 6917529027641081856 sig loop2 2 -4611686018427387904 Does it look right? The IR looks right: $ diff Main.mc.m3cgcat.bad Main.mc.m3cgcat 34c34 < load_integer Int.64 0 --- > load_integer Int.64 -9223372036854775808 It still needs some regression testing and wrapping up. On 05/26/2016 12:08 AM, Peter McKinna wrote: > Wow, nice work. Is there a problem in the backend as well? Or other problems in the front end? I suspect the back end problem is something else. That's next. > That dodgy intermediate looked like perfectly good code apart from the loop > so I cant understand why the back end would crash with optimizations on. > > Also what is the deal with jump bufs ? This is unrelated. It just prevented getting a running cm3 on LINUXLIBC6. I now have gotten around thislocally, but it needs more work to not break other platforms. > > Regards Peter > > > On Thu, May 26, 2016 at 1:58 PM, Rodney M. Bates > wrote: > > Just an FYI on the And bug. > > I think I have diagnosed this for this particular case. TInt.ToBytes is following > the invariants of a TInt.T, which always uses twos-complement notation, but, with > a 9th byte, is big enough to hold the entire overlap of the 64-bit signed and unsigned > ranges. OTOH, M3CG_BinWr.AddBigX is converting to signed-magnitude, with a separate > sign. It passes an absolute value to ToBytes. For only this single value > 16_8000000000000000, this is representable as a positive absolute value in 8 bytes, > but ToBytes correctly considers this too few bytes for twos-complement and returns > zero. > > It will take more work to look at all the calls on ToBytes and ascertain which > cases suffer this mismatch. Also, I am currently unable to build a working > compiler for LINUXLIBC6, something to do with jumbufs. So I will have to get around > that before testing a fix and for regressions. > > It looks like it doesn't happen when compiling on a 64-bit machine because that > takes a different path, using native INTEGER rather than TInt for the constant > value. > > > On 05/24/2016 02:24 AM, Peter McKinna wrote: > > I may have been a tad hasty in blaming the back end for the crashes, the front end has some explaining to do as well. > > I was getting an infinite loop in a program which I have cut down here to demonstrate. The original cm3 5.2 I think it > was from elegosoft worked fine. The latest produces different intermediate code. > > First the source, (excuse the size, its extracted from my implementation of grisu which I was on the point of pushing to github) > > MODULE Main; > > IMPORT Long,IO,Fmt; > > CONST > kUint64MSB = 16_8000000000000000L; > > TYPE > Uint64 = Long.T; > PROCEDURE Normalize(sig : Long.T; exp : INTEGER) = > CONST > k10MSBits = 16_FFC0000000000000L; > VAR > significand : Uint64; > exponent : INTEGER; > > BEGIN > <*ASSERT sig # 0L *> > significand := sig; > exponent := exp; > (*IO.Put("sig init " & Fmt.LongInt(significand) & "\n");*) > > (* This method is mainly called for normalizing boundaries. In general > boundaries need to be shifted by 10 bits. We thus optimize for this case. *) > WHILE Long.And(significand, k10MSBits) = 0L DO > significand := Long.LeftShift(significand, 10); > (*IO.Put("sig loop 1 " & Fmt.LongInt(significand) & "\n");*) > DEC(exponent, 10); > END; > (*IO.Put("sig after loop 1 " & Fmt.LongInt(significand) & "\n");*) > (* > IO.PutLongInt(Long.And(significand, kUint64MSB)); > IO.Put("\n"); > *) > WHILE Long.And(significand, kUint64MSB) = 0L DO > (*IO.Put("sig loop2 1 " & Fmt.LongInt(significand) & "\n");*) > significand := Long.LeftShift(significand, 1); > (*IO.Put("sig loop2 2 " & Fmt.LongInt(significand) & "\n");*) > DEC(exponent); > END; > END Normalize; > BEGIN > > Normalize(3L,2); > END Main. > > Now the correct intermediate from the original cm3 > Its a shame we cant embed the cm3 version into the intermediate. But theres no mention of widechar so you can tell its an old > version. > > begin_unit0 > -----FILE ../src/Main.m3 ----- > -----LINE 1 ----- > # module global constants > declare_segment* -1 T v.1 > # module global data > declare_segmentM_Main -1 F v.2 > -----LINE 45 ----- > declare_procedureMain_M3 1 Addr 0 0 T * p.1 > declare_parammode 4 4 Int.32 425470580 F F 100 v.3 > declare_proctype1318003907 2 0 0 0 > declare_formalsig 89530742 > declare_formalexp 425470580 > import_procedureMain_I3 0 Addr 0 p.2 > export_unitMain > import_procedureFmt_I3 0 Addr 0 p.3 > import_unitFmt > import_procedureIO_I3 0 Addr 0 p.4 > import_unitIO > import_procedureLong_I3 0 Addr 0 p.5 > import_unitLong > import_procedureRTHooks_I3 0 Addr 0 p.6 > import_unitRTHooks > declare_typename89530742 Uint64 > declare_procedureMain__Normalize 2 Void 0 0 F * p.7 > declare_localsignificand 8 4 Int.64 89530742 F F 50 v.4 > declare_localexponent 4 4 Int.32 425470580 F F 50 v.5 > declare_paramsig 8 4 Int.64 89530742 F F 50 v.6 > declare_paramexp 4 4 Int.32 425470580 F F 50 v.7 > # Normalize > -----LINE 11 ----- > begin_procedurep.7 > -----LINE 12 ----- > -----LINE 19 ----- > loadv.6 0 Int.64 Int.64 > load_integerInt.64 0 > if_neInt.64 L.1 100 > import_procedureRTHooks__ReportFault 2 Void 0 p.8 > declare_parammodule 4 4 Addr 138420323 F F 50 v.8 > declare_paraminfo 4 4 Int.32 425470580 F F 50 v.9 > set_runtime_procReportFault p.8 > abort0 > . L.1 F > -----LINE 20 ----- > loadv.6 0 Int.64 Int.64 > storev.4 0 Int.64 Int.64 > -----LINE 21 ----- > loadv.7 0 Int.32 Int.32 > storev.5 0 Int.32 Int.32 > -----LINE 26 ----- > jumpL.2 > . L.3 F > -----LINE 27 ----- > loadv.4 0 Int.64 Int.64 > load_integerInt.32 10 > shift_leftInt.64 > storev.4 0 Int.64 Int.64 > -----LINE 29 ----- > loadv.5 0 Int.32 Int.32 > load_integerInt.32 10 > subtractInt.32 > storev.5 0 Int.32 Int.32 > -----LINE 26 ----- > . L.2 F > loadv.4 0 Int.64 Int.64 > load_integerInt.64 -18014398509481984 > andInt.64 > load_integerInt.64 0 > if_eqInt.64 L.3 80 > . L.4 F > -----LINE 36 ----- > jumpL.5 > . L.6 F > -----LINE 38 ----- > loadv.4 0 Int.64 Int.64 > load_integerInt.32 1 > shift_leftInt.64 > storev.4 0 Int.64 Int.64 > -----LINE 40 ----- > loadv.5 0 Int.32 Int.32 > load_integerInt.32 1 > subtractInt.32 > storev.5 0 Int.32 Int.32 > -----LINE 36 ----- > . L.5 F > loadv.4 0 Int.64 Int.64 > load_integerInt.64 -9223372036854775808 > andInt.64 > load_integerInt.64 0 > if_eqInt.64 L.6 80 > . L.7 F > -----LINE 43 ----- > exit_procVoid > end_procedurep.7 > # Main_M3 > # module main body Main_M3 > -----LINE 45 ----- > begin_procedurep.1 > loadv.3 0 Int.32 Int.32 > if_falseInt.32 L.8 0 > -----LINE 47 ----- > start_call_directp.7 0 Void > load_integerInt.64 3 > pop_paramInt.64 > load_integerInt.32 2 > pop_paramInt.32 > call_directp.7 Void > . L.8 F > load_addressv.2 0 > exit_procAddr > end_procedurep.1 > # global constant type descriptor > declare_record-1 448 0 > # global data type descriptor > declare_record-1 896 0 > # module global constants > bind_segmentv.1 56 4 Struct F T > begin_initv.1 > # procedure names > init_chars0 "Main_M3" > init_chars8 "Normalize" > # procedure table > init_proc20 p.1 > init_var24 v.1 0 > init_proc28 p.7 > init_var32 v.1 8 > # file name > init_chars40 "../src/Main.m3" > end_initv.1 > # module global data > bind_segmentv.2 112 4 Struct F T > > begin_initv.2 > init_var0 v.1 40 > init_var20 v.1 20 > init_var36 v.2 52 > init_proc44 p.1 > init_int48 3 Int.32 > init_proc56 p.2 > init_var60 v.2 64 > init_proc68 p.3 > init_var72 v.2 76 > init_proc80 p.4 > init_var84 v.2 88 > init_proc92 p.5 > init_var96 v.2 100 > init_proc104 p.6 > end_initv.2 > # load map > # > # > # global data allocation for M_Main > # 0 52 4 *module info* > # 52 12 4 import Main > # 64 12 4 import Fmt > # 76 12 4 import IO > # 88 12 4 import Long > # 100 12 4 import RTHooks > # 112 0 4 *TOTAL* > # > # > # global constants for M_Main > # 0 18 4 *proc names* > # 20 20 4 *proc info* > # 40 15 1 *string* > # 56 0 4 *TOTAL* > # > end_unit > > > Now the intermediate from the latest compiler > > begin_unit0 > widechar_size16 > -----FILE ../src/Main.m3 ----- > -----LINE 1 ----- > # module global constants > declare_segment* -1 T v.1 > # module global data > declare_segmentM_Main -1 F v.2 > -----LINE 45 ----- > declare_procedureMain_M3 1 Addr 0 0 T * p.1 > declare_parammode 4 4 Int.32 425470580 F F 100 v.3 > declare_proctype1318003907 2 0 0 0 > declare_formalsig 89530742 > declare_formalexp 425470580 > import_procedureMain_I3 0 Addr 0 p.2 > export_unitMain > import_procedureFmt_I3 0 Addr 0 p.3 > import_unitFmt > import_procedureIO_I3 0 Addr 0 p.4 > import_unitIO > import_procedureLong_I3 0 Addr 0 p.5 > import_unitLong > import_procedureRTHooks_I3 0 Addr 0 p.6 > import_unitRTHooks > declare_typename89530742 Uint64 > declare_procedureMain__Normalize 2 Void 0 0 F * p.7 > declare_localsignificand 8 8 Int.64 89530742 F F 50 v.4 > declare_localexponent 4 4 Int.32 425470580 F F 50 v.5 > declare_paramsig 8 8 Int.64 89530742 F F 50 v.6 > declare_paramexp 4 4 Int.32 425470580 F F 50 v.7 > # Normalize > -----LINE 11 ----- > begin_procedurep.7 > -----LINE 12 ----- > -----LINE 19 ----- > load_integerInt.64 0 > loadv.6 0 Int.64 Int.64 > if_neInt.64 L.1 100 > declare_proctype-1531209598 2 0 -1 0 > declare_formalmodule 138420323 > declare_formalinfo 425470580 > import_procedureRTHooks__ReportFault 2 Void 0 p.8 > declare_parammodule 4 4 Addr 138420323 F F 50 v.8 > declare_paraminfo 4 4 Int.32 425470580 F F 50 v.9 > set_runtime_procReportFault p.8 > abort0 > . L.1 F > -----LINE 20 ----- > loadv.6 0 Int.64 Int.64 > storev.4 0 Int.64 Int.64 > -----LINE 21 ----- > loadv.7 0 Int.32 Int.32 > storev.5 0 Int.32 Int.32 > -----LINE 26 ----- > jumpL.2 > . L.3 F > -----LINE 27 ----- > loadv.4 0 Int.64 Int.64 > load_integerInt.32 10 > shift_leftWord.64 > storev.4 0 Int.64 Int.64 > -----LINE 29 ----- > loadv.5 0 Int.32 Int.32 > load_integerInt.32 10 > subtractInt.32 > storev.5 0 Int.32 Int.32 > -----LINE 26 ----- > . L.2 F > load_integerInt.64 -18014398509481984 > loadv.4 0 Int.64 Int.64 > andWord.64 > load_integerInt.64 0 > if_eqInt.64 L.3 80 > . L.4 F > -----LINE 36 ----- > jumpL.5 > . L.6 F > -----LINE 38 ----- > loadv.4 0 Int.64 Int.64 > load_integerInt.32 1 > shift_leftWord.64 > storev.4 0 Int.64 Int.64 > -----LINE 40 ----- > loadv.5 0 Int.32 Int.32 > load_integerInt.32 1 > subtractInt.32 > storev.5 0 Int.32 Int.32 > -----LINE 36 ----- > . L.5 F > load_integerInt.64 0 > loadv.4 0 Int.64 Int.64 > andWord.64 > load_integerInt.64 0 > if_eqInt.64 L.6 80 > . L.7 F > -----LINE 43 ----- > exit_procVoid > end_procedurep.7 > # Main_M3 > # module main body Main_M3 > -----LINE 45 ----- > begin_procedurep.1 > loadv.3 0 Int.32 Int.32 > if_falseInt.32 L.8 0 > -----LINE 47 ----- > start_call_directp.7 0 Void > load_integerInt.64 3 > pop_paramInt.64 > load_integerInt.32 2 > pop_paramInt.32 > call_directp.7 Void > . L.8 F > load_addressv.2 0 > exit_procAddr > end_procedurep.1 > # global constant type descriptor > declare_record-1 448 0 > # global data type descriptor > declare_record-1 896 0 > # module global constants > bind_segmentv.1 56 8 Struct F T > begin_initv.1 > # procedure names > init_chars0 "Main_M3" > init_chars8 "Normalize" > # procedure table > init_proc20 p.1 > init_var24 v.1 0 > init_proc28 p.7 > init_var32 v.1 8 > # file name > init_chars40 "../src/Main.m3" > end_initv.1 > # module global data > bind_segmentv.2 112 8 Struct F T > > begin_initv.2 > init_var0 v.1 40 > init_var20 v.1 20 > init_var36 v.2 52 > init_proc44 p.1 > init_int48 3 Int.32 > init_proc56 p.2 > init_var60 v.2 64 > init_proc68 p.3 > init_var72 v.2 76 > init_proc80 p.4 > init_var84 v.2 88 > init_proc92 p.5 > init_var96 v.2 100 > init_proc104 p.6 > end_initv.2 > # load map > # > # > # global data allocation for M_Main > # 0 52 4 *module info* > # 52 12 4 import Main > # 64 12 4 import Fmt > # 76 12 4 import IO > # 88 12 4 import Long > # 100 12 4 import RTHooks > # 112 0 4 *TOTAL* > # > # > # global constants for M_Main > # 0 18 4 *proc names* > # 20 20 4 *proc info* > # 40 15 1 *string* > # 56 0 4 *TOTAL* > # > end_unit > > > Its very similar except for using Word.64 instead of Int.64 and a couple of other cosmetic issues. > The trouble is near label L5 where it does a load_integer of 0 instead of the big constant. > The result of anding the zero and testing for zero is causing the loop. > Compiling this with -O also causes the backend to crash. > Both of these are on LINUXLIBC6. The AMD64 intermediate is correct. Seems like its not parsing the > big long for some reason or else its wrapping around. > > Any ideas? > > Regards Peter > > > > On Tue, May 24, 2016 at 4:40 AM, Rodney M. Bates >> wrote: > > > > > I did git pull and rebuilt on LINUXLIBC6. The built cm3 executable crashes compiling > a very small experiment program: > > rodney at yellowstone:~/proj/m3/exp/FmtBug/src$ cm3- > Segmentation fault (core dumped) > > m3gdb (after I built it) gives this: > > rodney at yellowstone:~/proj/m3/exp/FmtBug/src$ m3gdb cm3- > GNU gdb plus Modula-3 6.4 > Copyright 2005 Free Software Foundation, Inc. > GDB is free software, covered by the GNU General Public License, and you are > welcome to change it and/or distribute copies of it under certain conditions. > Type "show copying" to see the conditions. > There is absolutely no warranty for GDB. Type "show warranty" for details. > This GDB was configured as "i686-pc-linux-gnu"...Using host libthread_db library "/lib/tls/i686/cmov/libthread_db.so.1". > > (m3gdb) run > Starting program: /usr/local/cm3-githead/bin/cm3- > [Thread debugging using libthread_db enabled] > [New LWP 23615] > [New Thread -1216829744 (LWP 23615)] > > Program received signal SIGSEGV, Segmentation fault. > [Switching to Thread -1216829744 (LWP 23615)] > 0x0037c26f in siglongjmp () from /lib/tls/i686/cmov/libc.so.6 > (m3gdb) bt > #0 0x0037c26f in siglongjmp () from /lib/tls/i686/cmov/libc.so.6 > #1 0x577b2a84 in ?? () > Cannot access memory at address 0xd7a0906f > (m3gdb) quit > > > stock gdb gives even less information: > > rodney at yellowstone:~/proj/m3/exp/FmtBug/src$ gdb cm3- > GNU gdb (GDB) 7.1-ubuntu > Copyright (C) 2010 Free Software Foundation, Inc. > License GPLv3+: GNU GPL version 3 or later > This is free software: you are free to change and redistribute it. > There is NO WARRANTY, to the extent permitted by law. Type "show copying" > and "show warranty" for details. > This GDB was configured as "i486-linux-gnu". > For bug reporting instructions, please see: > ... > Reading symbols from /usr/local/cm3-githead/bin/cm3-...done. > (gdb) run > Starting program: /usr/local/cm3-githead/bin/cm3- > [Thread debugging using libthread_db enabled] > > Program received signal SIGSEGV, Segmentation fault. > 0x0032e26f in ?? () from /lib/tls/i686/cmov/libc.so.6 > (gdb) bt > #0 0x0032e26f in ?? () from /lib/tls/i686/cmov/libc.so.6 > #1 0xfb35d04b in ?? () > Cannot access memory at address 0x7bee2da0 > (gdb) > > Note that gdb gives a different address in the same library for the point of fault. > > m3gdb claims it's in siglongjmp. I recall there were some recent changes involving > longjump. > > > > > > > On 05/22/2016 09:28 PM, Peter McKinna wrote: > > I dont know what changed but the backend is crashing on linuxlibc6 when compiled with -O Try compiling m3core. > > > > Also some of my low level tests with Long.And and Long.Shift are not working with > > normal compile without the optimisations on that platform. Bit suspicious. I'm still investigating. > > > > Anyone got any clues or can replicate? > > > > Thanks 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 Thu May 26 23:23:18 2016 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Thu, 26 May 2016 16:23:18 -0500 Subject: [M3devel] cm3cg failing on linuxlibc6 In-Reply-To: <57472C72.8090904@lcwb.coop> References: <57434E93.2030205@lcwb.coop> <57467453.4040702@lcwb.coop> <57472C72.8090904@lcwb.coop> Message-ID: <57476946.20706@lcwb.coop> It's now verified to recompile itself twice, committed and pushed to github. On 05/26/2016 12:03 PM, Rodney M. Bates wrote: > I am getting this output from your example, with the output commented back in: > > sig init 3 > sig loop 1 3072 > sig loop 1 3145728 > sig loop 1 3221225472 > sig loop 1 3298534883328 > sig loop 1 3377699720527872 > sig loop 1 3458764513820540928 > sig after loop 1 3458764513820540928 > 0 > sig loop2 1 3458764513820540928 > sig loop2 2 6917529027641081856 > sig loop2 1 6917529027641081856 > sig loop2 2 -4611686018427387904 > > > Does it look right? The IR looks right: > > $ diff Main.mc.m3cgcat.bad Main.mc.m3cgcat > 34c34 > < load_integer Int.64 0 > --- > > load_integer Int.64 -9223372036854775808 > > > It still needs some regression testing and wrapping up. > > > > On 05/26/2016 12:08 AM, Peter McKinna wrote: >> Wow, nice work. Is there a problem in the backend as well? Or other problems in the front end? > > I suspect the back end problem is something else. That's next. > >> That dodgy intermediate looked like perfectly good code apart from the loop >> so I cant understand why the back end would crash with optimizations on. >> >> Also what is the deal with jump bufs ? > > This is unrelated. It just prevented getting a running cm3 on LINUXLIBC6. I now > have gotten around thislocally, but it needs more work to not break other platforms. > >> >> Regards Peter >> >> >> On Thu, May 26, 2016 at 1:58 PM, Rodney M. Bates > wrote: >> >> Just an FYI on the And bug. >> >> I think I have diagnosed this for this particular case. TInt.ToBytes is following >> the invariants of a TInt.T, which always uses twos-complement notation, but, with >> a 9th byte, is big enough to hold the entire overlap of the 64-bit signed and unsigned >> ranges. OTOH, M3CG_BinWr.AddBigX is converting to signed-magnitude, with a separate >> sign. It passes an absolute value to ToBytes. For only this single value >> 16_8000000000000000, this is representable as a positive absolute value in 8 bytes, >> but ToBytes correctly considers this too few bytes for twos-complement and returns >> zero. >> >> It will take more work to look at all the calls on ToBytes and ascertain which >> cases suffer this mismatch. Also, I am currently unable to build a working >> compiler for LINUXLIBC6, something to do with jumbufs. So I will have to get around >> that before testing a fix and for regressions. >> >> It looks like it doesn't happen when compiling on a 64-bit machine because that >> takes a different path, using native INTEGER rather than TInt for the constant >> value. >> >> >> On 05/24/2016 02:24 AM, Peter McKinna wrote: >> >> I may have been a tad hasty in blaming the back end for the crashes, the front end has some explaining to do as well. >> >> I was getting an infinite loop in a program which I have cut down here to demonstrate. The original cm3 5.2 I think it >> was from elegosoft worked fine. The latest produces different intermediate code. >> >> First the source, (excuse the size, its extracted from my implementation of grisu which I was on the point of pushing to github) >> >> MODULE Main; >> >> IMPORT Long,IO,Fmt; >> >> CONST >> kUint64MSB = 16_8000000000000000L; >> >> TYPE >> Uint64 = Long.T; >> PROCEDURE Normalize(sig : Long.T; exp : INTEGER) = >> CONST >> k10MSBits = 16_FFC0000000000000L; >> VAR >> significand : Uint64; >> exponent : INTEGER; >> >> BEGIN >> <*ASSERT sig # 0L *> >> significand := sig; >> exponent := exp; >> (*IO.Put("sig init " & Fmt.LongInt(significand) & "\n");*) >> >> (* This method is mainly called for normalizing boundaries. In general >> boundaries need to be shifted by 10 bits. We thus optimize for this case. *) >> WHILE Long.And(significand, k10MSBits) = 0L DO >> significand := Long.LeftShift(significand, 10); >> (*IO.Put("sig loop 1 " & Fmt.LongInt(significand) & "\n");*) >> DEC(exponent, 10); >> END; >> (*IO.Put("sig after loop 1 " & Fmt.LongInt(significand) & "\n");*) >> (* >> IO.PutLongInt(Long.And(significand, kUint64MSB)); >> IO.Put("\n"); >> *) >> WHILE Long.And(significand, kUint64MSB) = 0L DO >> (*IO.Put("sig loop2 1 " & Fmt.LongInt(significand) & "\n");*) >> significand := Long.LeftShift(significand, 1); >> (*IO.Put("sig loop2 2 " & Fmt.LongInt(significand) & "\n");*) >> DEC(exponent); >> END; >> END Normalize; >> BEGIN >> >> Normalize(3L,2); >> END Main. >> >> Now the correct intermediate from the original cm3 >> Its a shame we cant embed the cm3 version into the intermediate. But theres no mention of widechar so you can tell its an old >> version. >> >> begin_unit0 >> -----FILE ../src/Main.m3 ----- >> -----LINE 1 ----- >> # module global constants >> declare_segment* -1 T v.1 >> # module global data >> declare_segmentM_Main -1 F v.2 >> -----LINE 45 ----- >> declare_procedureMain_M3 1 Addr 0 0 T * p.1 >> declare_parammode 4 4 Int.32 425470580 F F 100 v.3 >> declare_proctype1318003907 2 0 0 0 >> declare_formalsig 89530742 >> declare_formalexp 425470580 >> import_procedureMain_I3 0 Addr 0 p.2 >> export_unitMain >> import_procedureFmt_I3 0 Addr 0 p.3 >> import_unitFmt >> import_procedureIO_I3 0 Addr 0 p.4 >> import_unitIO >> import_procedureLong_I3 0 Addr 0 p.5 >> import_unitLong >> import_procedureRTHooks_I3 0 Addr 0 p.6 >> import_unitRTHooks >> declare_typename89530742 Uint64 >> declare_procedureMain__Normalize 2 Void 0 0 F * p.7 >> declare_localsignificand 8 4 Int.64 89530742 F F 50 v.4 >> declare_localexponent 4 4 Int.32 425470580 F F 50 v.5 >> declare_paramsig 8 4 Int.64 89530742 F F 50 v.6 >> declare_paramexp 4 4 Int.32 425470580 F F 50 v.7 >> # Normalize >> -----LINE 11 ----- >> begin_procedurep.7 >> -----LINE 12 ----- >> -----LINE 19 ----- >> loadv.6 0 Int.64 Int.64 >> load_integerInt.64 0 >> if_neInt.64 L.1 100 >> import_procedureRTHooks__ReportFault 2 Void 0 p.8 >> declare_parammodule 4 4 Addr 138420323 F F 50 v.8 >> declare_paraminfo 4 4 Int.32 425470580 F F 50 v.9 >> set_runtime_procReportFault p.8 >> abort0 >> . L.1 F >> -----LINE 20 ----- >> loadv.6 0 Int.64 Int.64 >> storev.4 0 Int.64 Int.64 >> -----LINE 21 ----- >> loadv.7 0 Int.32 Int.32 >> storev.5 0 Int.32 Int.32 >> -----LINE 26 ----- >> jumpL.2 >> . L.3 F >> -----LINE 27 ----- >> loadv.4 0 Int.64 Int.64 >> load_integerInt.32 10 >> shift_leftInt.64 >> storev.4 0 Int.64 Int.64 >> -----LINE 29 ----- >> loadv.5 0 Int.32 Int.32 >> load_integerInt.32 10 >> subtractInt.32 >> storev.5 0 Int.32 Int.32 >> -----LINE 26 ----- >> . L.2 F >> loadv.4 0 Int.64 Int.64 >> load_integerInt.64 -18014398509481984 >> andInt.64 >> load_integerInt.64 0 >> if_eqInt.64 L.3 80 >> . L.4 F >> -----LINE 36 ----- >> jumpL.5 >> . L.6 F >> -----LINE 38 ----- >> loadv.4 0 Int.64 Int.64 >> load_integerInt.32 1 >> shift_leftInt.64 >> storev.4 0 Int.64 Int.64 >> -----LINE 40 ----- >> loadv.5 0 Int.32 Int.32 >> load_integerInt.32 1 >> subtractInt.32 >> storev.5 0 Int.32 Int.32 >> -----LINE 36 ----- >> . L.5 F >> loadv.4 0 Int.64 Int.64 >> load_integerInt.64 -9223372036854775808 >> andInt.64 >> load_integerInt.64 0 >> if_eqInt.64 L.6 80 >> . L.7 F >> -----LINE 43 ----- >> exit_procVoid >> end_procedurep.7 >> # Main_M3 >> # module main body Main_M3 >> -----LINE 45 ----- >> begin_procedurep.1 >> loadv.3 0 Int.32 Int.32 >> if_falseInt.32 L.8 0 >> -----LINE 47 ----- >> start_call_directp.7 0 Void >> load_integerInt.64 3 >> pop_paramInt.64 >> load_integerInt.32 2 >> pop_paramInt.32 >> call_directp.7 Void >> . L.8 F >> load_addressv.2 0 >> exit_procAddr >> end_procedurep.1 >> # global constant type descriptor >> declare_record-1 448 0 >> # global data type descriptor >> declare_record-1 896 0 >> # module global constants >> bind_segmentv.1 56 4 Struct F T >> begin_initv.1 >> # procedure names >> init_chars0 "Main_M3" >> init_chars8 "Normalize" >> # procedure table >> init_proc20 p.1 >> init_var24 v.1 0 >> init_proc28 p.7 >> init_var32 v.1 8 >> # file name >> init_chars40 "../src/Main.m3" >> end_initv.1 >> # module global data >> bind_segmentv.2 112 4 Struct F T >> >> begin_initv.2 >> init_var0 v.1 40 >> init_var20 v.1 20 >> init_var36 v.2 52 >> init_proc44 p.1 >> init_int48 3 Int.32 >> init_proc56 p.2 >> init_var60 v.2 64 >> init_proc68 p.3 >> init_var72 v.2 76 >> init_proc80 p.4 >> init_var84 v.2 88 >> init_proc92 p.5 >> init_var96 v.2 100 >> init_proc104 p.6 >> end_initv.2 >> # load map >> # >> # >> # global data allocation for M_Main >> # 0 52 4 *module info* >> # 52 12 4 import Main >> # 64 12 4 import Fmt >> # 76 12 4 import IO >> # 88 12 4 import Long >> # 100 12 4 import RTHooks >> # 112 0 4 *TOTAL* >> # >> # >> # global constants for M_Main >> # 0 18 4 *proc names* >> # 20 20 4 *proc info* >> # 40 15 1 *string* >> # 56 0 4 *TOTAL* >> # >> end_unit >> >> >> Now the intermediate from the latest compiler >> >> begin_unit0 >> widechar_size16 >> -----FILE ../src/Main.m3 ----- >> -----LINE 1 ----- >> # module global constants >> declare_segment* -1 T v.1 >> # module global data >> declare_segmentM_Main -1 F v.2 >> -----LINE 45 ----- >> declare_procedureMain_M3 1 Addr 0 0 T * p.1 >> declare_parammode 4 4 Int.32 425470580 F F 100 v.3 >> declare_proctype1318003907 2 0 0 0 >> declare_formalsig 89530742 >> declare_formalexp 425470580 >> import_procedureMain_I3 0 Addr 0 p.2 >> export_unitMain >> import_procedureFmt_I3 0 Addr 0 p.3 >> import_unitFmt >> import_procedureIO_I3 0 Addr 0 p.4 >> import_unitIO >> import_procedureLong_I3 0 Addr 0 p.5 >> import_unitLong >> import_procedureRTHooks_I3 0 Addr 0 p.6 >> import_unitRTHooks >> declare_typename89530742 Uint64 >> declare_procedureMain__Normalize 2 Void 0 0 F * p.7 >> declare_localsignificand 8 8 Int.64 89530742 F F 50 v.4 >> declare_localexponent 4 4 Int.32 425470580 F F 50 v.5 >> declare_paramsig 8 8 Int.64 89530742 F F 50 v.6 >> declare_paramexp 4 4 Int.32 425470580 F F 50 v.7 >> # Normalize >> -----LINE 11 ----- >> begin_procedurep.7 >> -----LINE 12 ----- >> -----LINE 19 ----- >> load_integerInt.64 0 >> loadv.6 0 Int.64 Int.64 >> if_neInt.64 L.1 100 >> declare_proctype-1531209598 2 0 -1 0 >> declare_formalmodule 138420323 >> declare_formalinfo 425470580 >> import_procedureRTHooks__ReportFault 2 Void 0 p.8 >> declare_parammodule 4 4 Addr 138420323 F F 50 v.8 >> declare_paraminfo 4 4 Int.32 425470580 F F 50 v.9 >> set_runtime_procReportFault p.8 >> abort0 >> . L.1 F >> -----LINE 20 ----- >> loadv.6 0 Int.64 Int.64 >> storev.4 0 Int.64 Int.64 >> -----LINE 21 ----- >> loadv.7 0 Int.32 Int.32 >> storev.5 0 Int.32 Int.32 >> -----LINE 26 ----- >> jumpL.2 >> . L.3 F >> -----LINE 27 ----- >> loadv.4 0 Int.64 Int.64 >> load_integerInt.32 10 >> shift_leftWord.64 >> storev.4 0 Int.64 Int.64 >> -----LINE 29 ----- >> loadv.5 0 Int.32 Int.32 >> load_integerInt.32 10 >> subtractInt.32 >> storev.5 0 Int.32 Int.32 >> -----LINE 26 ----- >> . L.2 F >> load_integerInt.64 -18014398509481984 >> loadv.4 0 Int.64 Int.64 >> andWord.64 >> load_integerInt.64 0 >> if_eqInt.64 L.3 80 >> . L.4 F >> -----LINE 36 ----- >> jumpL.5 >> . L.6 F >> -----LINE 38 ----- >> loadv.4 0 Int.64 Int.64 >> load_integerInt.32 1 >> shift_leftWord.64 >> storev.4 0 Int.64 Int.64 >> -----LINE 40 ----- >> loadv.5 0 Int.32 Int.32 >> load_integerInt.32 1 >> subtractInt.32 >> storev.5 0 Int.32 Int.32 >> -----LINE 36 ----- >> . L.5 F >> load_integerInt.64 0 >> loadv.4 0 Int.64 Int.64 >> andWord.64 >> load_integerInt.64 0 >> if_eqInt.64 L.6 80 >> . L.7 F >> -----LINE 43 ----- >> exit_procVoid >> end_procedurep.7 >> # Main_M3 >> # module main body Main_M3 >> -----LINE 45 ----- >> begin_procedurep.1 >> loadv.3 0 Int.32 Int.32 >> if_falseInt.32 L.8 0 >> -----LINE 47 ----- >> start_call_directp.7 0 Void >> load_integerInt.64 3 >> pop_paramInt.64 >> load_integerInt.32 2 >> pop_paramInt.32 >> call_directp.7 Void >> . L.8 F >> load_addressv.2 0 >> exit_procAddr >> end_procedurep.1 >> # global constant type descriptor >> declare_record-1 448 0 >> # global data type descriptor >> declare_record-1 896 0 >> # module global constants >> bind_segmentv.1 56 8 Struct F T >> begin_initv.1 >> # procedure names >> init_chars0 "Main_M3" >> init_chars8 "Normalize" >> # procedure table >> init_proc20 p.1 >> init_var24 v.1 0 >> init_proc28 p.7 >> init_var32 v.1 8 >> # file name >> init_chars40 "../src/Main.m3" >> end_initv.1 >> # module global data >> bind_segmentv.2 112 8 Struct F T >> >> begin_initv.2 >> init_var0 v.1 40 >> init_var20 v.1 20 >> init_var36 v.2 52 >> init_proc44 p.1 >> init_int48 3 Int.32 >> init_proc56 p.2 >> init_var60 v.2 64 >> init_proc68 p.3 >> init_var72 v.2 76 >> init_proc80 p.4 >> init_var84 v.2 88 >> init_proc92 p.5 >> init_var96 v.2 100 >> init_proc104 p.6 >> end_initv.2 >> # load map >> # >> # >> # global data allocation for M_Main >> # 0 52 4 *module info* >> # 52 12 4 import Main >> # 64 12 4 import Fmt >> # 76 12 4 import IO >> # 88 12 4 import Long >> # 100 12 4 import RTHooks >> # 112 0 4 *TOTAL* >> # >> # >> # global constants for M_Main >> # 0 18 4 *proc names* >> # 20 20 4 *proc info* >> # 40 15 1 *string* >> # 56 0 4 *TOTAL* >> # >> end_unit >> >> >> Its very similar except for using Word.64 instead of Int.64 and a couple of other cosmetic issues. >> The trouble is near label L5 where it does a load_integer of 0 instead of the big constant. >> The result of anding the zero and testing for zero is causing the loop. >> Compiling this with -O also causes the backend to crash. >> Both of these are on LINUXLIBC6. The AMD64 intermediate is correct. Seems like its not parsing the >> big long for some reason or else its wrapping around. >> >> Any ideas? >> >> Regards Peter >> >> >> >> On Tue, May 24, 2016 at 4:40 AM, Rodney M. Bates >> wrote: >> >> >> >> >> I did git pull and rebuilt on LINUXLIBC6. The built cm3 executable crashes compiling >> a very small experiment program: >> >> rodney at yellowstone:~/proj/m3/exp/FmtBug/src$ cm3- >> Segmentation fault (core dumped) >> >> m3gdb (after I built it) gives this: >> >> rodney at yellowstone:~/proj/m3/exp/FmtBug/src$ m3gdb cm3- >> GNU gdb plus Modula-3 6.4 >> Copyright 2005 Free Software Foundation, Inc. >> GDB is free software, covered by the GNU General Public License, and you are >> welcome to change it and/or distribute copies of it under certain conditions. >> Type "show copying" to see the conditions. >> There is absolutely no warranty for GDB. Type "show warranty" for details. >> This GDB was configured as "i686-pc-linux-gnu"...Using host libthread_db library "/lib/tls/i686/cmov/libthread_db.so.1". >> >> (m3gdb) run >> Starting program: /usr/local/cm3-githead/bin/cm3- >> [Thread debugging using libthread_db enabled] >> [New LWP 23615] >> [New Thread -1216829744 (LWP 23615)] >> >> Program received signal SIGSEGV, Segmentation fault. >> [Switching to Thread -1216829744 (LWP 23615)] >> 0x0037c26f in siglongjmp () from /lib/tls/i686/cmov/libc.so.6 >> (m3gdb) bt >> #0 0x0037c26f in siglongjmp () from /lib/tls/i686/cmov/libc.so.6 >> #1 0x577b2a84 in ?? () >> Cannot access memory at address 0xd7a0906f >> (m3gdb) quit >> >> >> stock gdb gives even less information: >> >> rodney at yellowstone:~/proj/m3/exp/FmtBug/src$ gdb cm3- >> GNU gdb (GDB) 7.1-ubuntu >> Copyright (C) 2010 Free Software Foundation, Inc. >> License GPLv3+: GNU GPL version 3 or later >> This is free software: you are free to change and redistribute it. >> There is NO WARRANTY, to the extent permitted by law. Type "show copying" >> and "show warranty" for details. >> This GDB was configured as "i486-linux-gnu". >> For bug reporting instructions, please see: >> ... >> Reading symbols from /usr/local/cm3-githead/bin/cm3-...done. >> (gdb) run >> Starting program: /usr/local/cm3-githead/bin/cm3- >> [Thread debugging using libthread_db enabled] >> >> Program received signal SIGSEGV, Segmentation fault. >> 0x0032e26f in ?? () from /lib/tls/i686/cmov/libc.so.6 >> (gdb) bt >> #0 0x0032e26f in ?? () from /lib/tls/i686/cmov/libc.so.6 >> #1 0xfb35d04b in ?? () >> Cannot access memory at address 0x7bee2da0 >> (gdb) >> >> Note that gdb gives a different address in the same library for the point of fault. >> >> m3gdb claims it's in siglongjmp. I recall there were some recent changes involving >> longjump. >> >> >> >> >> >> >> On 05/22/2016 09:28 PM, Peter McKinna wrote: >> > I dont know what changed but the backend is crashing on linuxlibc6 when compiled with -O Try compiling m3core. >> > >> > Also some of my low level tests with Long.And and Long.Shift are not working with >> > normal compile without the optimisations on that platform. Bit suspicious. I'm still investigating. >> > >> > Anyone got any clues or can replicate? >> > >> > Thanks 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 Fri May 27 20:38:07 2016 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Fri, 27 May 2016 13:38:07 -0500 Subject: [M3devel] cm3cg failing on linuxlibc6 In-Reply-To: References: Message-ID: <5748940F.5020808@lcwb.coop> On 05/22/2016 09:28 PM, Peter McKinna wrote: > I dont know what changed but the backend is crashing on linuxlibc6 when compiled with -O Try compiling m3core. > I get crashes compiling with -O -O1 -O2 -O3, with different symptoms. -O and -O2 just segfault. -O2 and -O3 get: ... /usr/local/cm3//bin/cm3cg -march=i686 -quiet -fno-reorder-blocks -funwind-tables -fPIC -m32 -O3 -gstabs+ Main.mc -o Main.ms *** glibc detected *** /usr/local/cm3//bin/cm3cg: double free or corruption (fasttop): 0x0a20b0d8 *** ======= Backtrace: ========= /lib/tls/i686/cmov/libc.so.6(+0x6e0a1)[0xac00a1] /lib/tls/i686/cmov/libc.so.6(+0x6f8f8)[0xac18f8] /lib/tls/i686/cmov/libc.so.6(cfree+0x6d)[0xac4a6d] /usr/local/cm3//bin/cm3cg[0x81c7df8] ======= Memory map: ======== 00180000-002ef000 r-xp 00000000 08:05 5507589 /usr/lib/libstdc++.so.6.0.21 002ef000-002f5000 r--p 0016e000 08:05 5507589 /usr/lib/libstdc++.so.6.0.21 002f5000-002f6000 rw-p 00174000 08:05 5507589 /usr/lib/libstdc++.so.6.0.21 002f6000-002f9000 rw-p 00000000 00:00 0 00360000-0037c000 r-xp 00000000 08:05 4337255 /lib/libgcc_s.so.1 0037c000-0037d000 r--p 0001b000 08:05 4337255 /lib/libgcc_s.so.1 0037d000-0037e000 rw-p 0001c000 08:05 4337255 /lib/libgcc_s.so.1 0087a000-00895000 r-xp 00000000 08:05 4336906 /lib/ld-2.11.1.so 00895000-00896000 r--p 0001a000 08:05 4336906 /lib/ld-2.11.1.so 00896000-00897000 rw-p 0001b000 08:05 4336906 /lib/ld-2.11.1.so 00a52000-00bae000 r-xp 00000000 08:05 4467785 /lib/tls/i686/cmov/libc-2.11.1.so 00bae000-00bb0000 r--p 0015b000 08:05 4467785 /lib/tls/i686/cmov/libc-2.11.1.so 00bb0000-00bb1000 rw-p 0015d000 08:05 4467785 /lib/tls/i686/cmov/libc-2.11.1.so 00bb1000-00bb4000 rw-p 00000000 00:00 0 00deb000-00e0f000 r-xp 00000000 08:05 4467782 /lib/tls/i686/cmov/libm-2.11.1.so 00e0f000-00e10000 r--p 00023000 08:05 4467782 /lib/tls/i686/cmov/libm-2.11.1.so 00e10000-00e11000 rw-p 00024000 08:05 4467782 /lib/tls/i686/cmov/libm-2.11.1.so 00f24000-00f25000 r-xp 00000000 00:00 0 [vdso] 08048000-088cd000 r-xp 00000000 08:05 5778669 /usr/local/cm3-githead/bin/cm3cg 088cd000-088ce000 r--p 00885000 08:05 5778669 /usr/local/cm3-githead/bin/cm3cg 088ce000-088d4000 rw-p 00886000 08:05 5778669 /usr/local/cm3-githead/bin/cm3cg 088d4000-089fe000 rw-p 00000000 00:00 0 0a149000-0a216000 rw-p 00000000 00:00 0 [heap] b7300000-b7321000 rw-p 00000000 00:00 0 b7321000-b7400000 ---p 00000000 00:00 0 b74d4000-b771a000 rw-p 00000000 00:00 0 b772b000-b7733000 rw-p 00000000 00:00 0 bff93000-bffa8000 rw-p 00000000 00:00 0 [stack] ../src/Main.m3: In function 'Main__Normalize': ../src/Main.m3:41:0: internal compiler error: Aborted Please submit a full bug report, with preprocessed source if appropriate. See for instructions. Were you compiling things earlier with -O successfully? I vaguely recall something to the effect that cm3cg never has worked with optimization. Anybody remember about this? > Also some of my low level tests with Long.And and Long.Shift are not working with > normal compile without the optimisations on that platform. Bit suspicious. I'm still investigating. > > Anyone got any clues or can replicate? > > Thanks 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 Fri May 27 20:45:31 2016 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Fri, 27 May 2016 13:45:31 -0500 Subject: [M3devel] cm3cg failing on linuxlibc6 In-Reply-To: <57434E93.2030205@lcwb.coop> References: <57434E93.2030205@lcwb.coop> Message-ID: <574895CB.10200@lcwb.coop> I got around this problem by setting Alloca_jmpbuf back to TRUE in m3-libs/m3core/src/runtime/ex_frame/RTExFrame.m3 and m3-sys/m3middle/src/Target.m3 I am trying to remember, but as I recall, TRUE was failing on some other platform, and the change was reverted. But now FALSE is failing on LINUXLIBC6 and TRUE is working there. What do you remember about this, Jay? On 05/23/2016 01:40 PM, Rodney M. Bates wrote: > > > > I did git pull and rebuilt on LINUXLIBC6. The built cm3 executable crashes compiling > a very small experiment program: > > rodney at yellowstone:~/proj/m3/exp/FmtBug/src$ cm3- > Segmentation fault (core dumped) > > m3gdb (after I built it) gives this: > > rodney at yellowstone:~/proj/m3/exp/FmtBug/src$ m3gdb cm3- > GNU gdb plus Modula-3 6.4 > Copyright 2005 Free Software Foundation, Inc. > GDB is free software, covered by the GNU General Public License, and you are > welcome to change it and/or distribute copies of it under certain conditions. > Type "show copying" to see the conditions. > There is absolutely no warranty for GDB. Type "show warranty" for details. > This GDB was configured as "i686-pc-linux-gnu"...Using host libthread_db library "/lib/tls/i686/cmov/libthread_db.so.1". > > (m3gdb) run > Starting program: /usr/local/cm3-githead/bin/cm3- > [Thread debugging using libthread_db enabled] > [New LWP 23615] > [New Thread -1216829744 (LWP 23615)] > > Program received signal SIGSEGV, Segmentation fault. > [Switching to Thread -1216829744 (LWP 23615)] > 0x0037c26f in siglongjmp () from /lib/tls/i686/cmov/libc.so.6 > (m3gdb) bt > #0 0x0037c26f in siglongjmp () from /lib/tls/i686/cmov/libc.so.6 > #1 0x577b2a84 in ?? () > Cannot access memory at address 0xd7a0906f > (m3gdb) quit > > > stock gdb gives even less information: > > rodney at yellowstone:~/proj/m3/exp/FmtBug/src$ gdb cm3- > GNU gdb (GDB) 7.1-ubuntu > Copyright (C) 2010 Free Software Foundation, Inc. > License GPLv3+: GNU GPL version 3 or later > This is free software: you are free to change and redistribute it. > There is NO WARRANTY, to the extent permitted by law. Type "show copying" > and "show warranty" for details. > This GDB was configured as "i486-linux-gnu". > For bug reporting instructions, please see: > ... > Reading symbols from /usr/local/cm3-githead/bin/cm3-...done. > (gdb) run > Starting program: /usr/local/cm3-githead/bin/cm3- > [Thread debugging using libthread_db enabled] > > Program received signal SIGSEGV, Segmentation fault. > 0x0032e26f in ?? () from /lib/tls/i686/cmov/libc.so.6 > (gdb) bt > #0 0x0032e26f in ?? () from /lib/tls/i686/cmov/libc.so.6 > #1 0xfb35d04b in ?? () > Cannot access memory at address 0x7bee2da0 > (gdb) > > Note that gdb gives a different address in the same library for the point of fault. > > m3gdb claims it's in siglongjmp. I recall there were some recent changes involving > longjump. > > > > > > On 05/22/2016 09:28 PM, Peter McKinna wrote: > > I dont know what changed but the backend is crashing on linuxlibc6 when compiled with -O Try compiling m3core. > > > > Also some of my low level tests with Long.And and Long.Shift are not working with > > normal compile without the optimisations on that platform. Bit suspicious. I'm still investigating. > > > > Anyone got any clues or can replicate? > > > > Thanks 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 lists at darko.org Sat May 28 01:50:20 2016 From: lists at darko.org (Darko Volaric) Date: Sat, 28 May 2016 01:50:20 +0200 Subject: [M3devel] cm3cg failing on linuxlibc6 In-Reply-To: <574895CB.10200@lcwb.coop> References: <57434E93.2030205@lcwb.coop> <574895CB.10200@lcwb.coop> Message-ID: This, perhaps: https://github.com/modula3/cm3/issues/10 On Fri, May 27, 2016 at 8:45 PM, Rodney M. Bates wrote: > I got around this problem by setting Alloca_jmpbuf back to TRUE in > > m3-libs/m3core/src/runtime/ex_frame/RTExFrame.m3 and > m3-sys/m3middle/src/Target.m3 > > I am trying to remember, but as I recall, TRUE was failing on some other > platform, > and the change was reverted. But now FALSE is failing on LINUXLIBC6 and > TRUE > is working there. > > What do you remember about this, Jay? > > > > On 05/23/2016 01:40 PM, Rodney M. Bates wrote: > >> >> >> >> I did git pull and rebuilt on LINUXLIBC6. The built cm3 executable >> crashes compiling >> a very small experiment program: >> >> rodney at yellowstone:~/proj/m3/exp/FmtBug/src$ cm3- >> Segmentation fault (core dumped) >> >> m3gdb (after I built it) gives this: >> >> rodney at yellowstone:~/proj/m3/exp/FmtBug/src$ m3gdb cm3- >> GNU gdb plus Modula-3 6.4 >> Copyright 2005 Free Software Foundation, Inc. >> GDB is free software, covered by the GNU General Public License, and >> you are >> welcome to change it and/or distribute copies of it under certain >> conditions. >> Type "show copying" to see the conditions. >> There is absolutely no warranty for GDB. Type "show warranty" for >> details. >> This GDB was configured as "i686-pc-linux-gnu"...Using host >> libthread_db library "/lib/tls/i686/cmov/libthread_db.so.1". >> >> (m3gdb) run >> Starting program: /usr/local/cm3-githead/bin/cm3- >> [Thread debugging using libthread_db enabled] >> [New LWP 23615] >> [New Thread -1216829744 (LWP 23615)] >> >> Program received signal SIGSEGV, Segmentation fault. >> [Switching to Thread -1216829744 (LWP 23615)] >> 0x0037c26f in siglongjmp () from /lib/tls/i686/cmov/libc.so.6 >> (m3gdb) bt >> #0 0x0037c26f in siglongjmp () from /lib/tls/i686/cmov/libc.so.6 >> #1 0x577b2a84 in ?? () >> Cannot access memory at address 0xd7a0906f >> (m3gdb) quit >> >> >> stock gdb gives even less information: >> >> rodney at yellowstone:~/proj/m3/exp/FmtBug/src$ gdb cm3- >> GNU gdb (GDB) 7.1-ubuntu >> Copyright (C) 2010 Free Software Foundation, Inc. >> License GPLv3+: GNU GPL version 3 or later < >> http://gnu.org/licenses/gpl.html> >> This is free software: you are free to change and redistribute it. >> There is NO WARRANTY, to the extent permitted by law. Type "show >> copying" >> and "show warranty" for details. >> This GDB was configured as "i486-linux-gnu". >> For bug reporting instructions, please see: >> ... >> Reading symbols from /usr/local/cm3-githead/bin/cm3-...done. >> (gdb) run >> Starting program: /usr/local/cm3-githead/bin/cm3- >> [Thread debugging using libthread_db enabled] >> >> Program received signal SIGSEGV, Segmentation fault. >> 0x0032e26f in ?? () from /lib/tls/i686/cmov/libc.so.6 >> (gdb) bt >> #0 0x0032e26f in ?? () from /lib/tls/i686/cmov/libc.so.6 >> #1 0xfb35d04b in ?? () >> Cannot access memory at address 0x7bee2da0 >> (gdb) >> >> Note that gdb gives a different address in the same library for the point >> of fault. >> >> m3gdb claims it's in siglongjmp. I recall there were some recent changes >> involving >> longjump. >> >> >> >> >> >> On 05/22/2016 09:28 PM, Peter McKinna wrote: >> > I dont know what changed but the backend is crashing on linuxlibc6 >> when compiled with -O Try compiling m3core. >> > >> > Also some of my low level tests with Long.And and Long.Shift are not >> working with >> > normal compile without the optimisations on that platform. Bit >> suspicious. I'm still investigating. >> > >> > Anyone got any clues or can replicate? >> > >> > Thanks 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Tue May 31 08:52:05 2016 From: jay.krell at cornell.edu (Jay K) Date: Tue, 31 May 2016 06:52:05 +0000 Subject: [M3devel] old problem of new releases on old systems esp. Unix Message-ID: fyi..in the vein of really needing to release as C or asm instead of binaries, like the 3.6 system did: https://github.com/modula3/cm3/releases/download/verification-release-x86_64/cm3-bin-core-AMD64_LINUX-d5.9.0-x86_64-unknown-linux-gnu-2014-08-19-18-12-25.tgz % cm3 -versioncm3: /lib/libc.so.6: version `GLIBC_2.14' not found (required by cm3) on an older system: % uname -aLinux birch 2.6.26-2-amd64 #1 SMP Sun Mar 4 21:48:06 UTC 2012 x86_64 GNU/Linux or maybe do more investigation of gcc/ld switches to produce more compatible binaries.. ..just need to converge on what such a system really looks like in terms of build portability -- like cmake or autotools or extremely simple.. I have a bit of mental block getting anywhere on this. None of the C/C++ build systems quite do what I'd like and I haven't yet written my own.. (i.e. esp in terms of picking what is statically linked vs. what is dynamically linked).. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Tue May 31 09:32:23 2016 From: jay.krell at cornell.edu (Jay K) Date: Tue, 31 May 2016 07:32:23 +0000 Subject: [M3devel] replace build system?? Message-ID: Design of a new or bootstrap/cross/distribution build system? I'd really like our stuff to be as easy to distribute and develop as stuff using e.g. autotools or cmake. And as portable. And to reuse other people's work. And have a solid cross build story. And distribution be C or .o or .a or .S files, not executables and so/dylibs. i.e. I'd really like to get out of the build system business. like to just use autotools or cmake? But I suspect our system's qualities is difficult to replicate within the other frameworks. i.e. the incrementality The way every dynamic library is also available statically. Thoughts? For example, enable easier mixing of Modula-3 with C and C++ i.e. within one Makefile or such. Is it possible for Modula-3 to efficiently have the single source to single .o per invocation model? ?- Jay From hendrik at topoi.pooq.com Tue May 31 18:05:03 2016 From: hendrik at topoi.pooq.com (Hendrik Boom) Date: Tue, 31 May 2016 12:05:03 -0400 Subject: [M3devel] replace build system?? In-Reply-To: References: Message-ID: <20160531160502.GC12646@topoi.pooq.com> On Tue, May 31, 2016 at 07:32:23AM +0000, Jay K wrote: > Design of a new or bootstrap/cross/distribution build system? > > > I'd really like our stuff to be as easy to distribute and develop > as stuff using e.g. autotools or cmake. And as portable. > > > And to reuse other people's work. > > > And have a solid cross build story. > > > And distribution be C or .o or .a or .S files, not executables and so/dylibs. Isn't there an m3 compiler that generates C? Didn't you even write it? -- hendrik k From estellnb at elstel.org Tue May 31 18:35:06 2016 From: estellnb at elstel.org (Elmar Stellnberger) Date: Tue, 31 May 2016 18:35:06 +0200 Subject: [M3devel] replace build system?? In-Reply-To: References: Message-ID: Am 2016-05-31 um 09:32 schrieb Jay K: > i.e. I'd really like to get out of the build system business. > like to just use autotools or cmake? A make-based build solution would have other advantages as well like f.i. parallel build by make --jobs=4. That way CM3 could build up to four times faster. > But I suspect our system's qualities is difficult to replicate within the other frameworks. > i.e. the incrementality > The way every dynamic library is also available statically. > Why not employ a simple hand written make-file that determines that by environment variables? i.e. what libraries to build statically. From dmuysers at hotmail.com Tue May 31 18:39:16 2016 From: dmuysers at hotmail.com (dirk muysers) Date: Tue, 31 May 2016 18:39:16 +0200 Subject: [M3devel] The mailing list archive Message-ID: is still not available! -------------- next part -------------- An HTML attachment was scrubbed... URL: From dabenavidesd at yahoo.es Tue May 31 19:06:13 2016 From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.) Date: Tue, 31 May 2016 17:06:13 +0000 (UTC) Subject: [M3devel] replace build system?? In-Reply-To: References: Message-ID: <1784674298.4028093.1464714373116.JavaMail.yahoo@mail.yahoo.com> Hi Jay and all:I am searching options to make it easier (maybe tricking our selves) for new Modula-3 users explore our system.As I said recently, there is a java front end (just misses IRC type checking m3clipse) and there was FOSS "Scale compiler" backend written in Java, M3 DEC-SRC front end compatible (it generated Sparc, Alpha and Powerpc object code). An excerpt from The Common Language Encoding Form(Clef) Design Document: "For Modula-3, Scale uses the Digital Equipment Corporation(DEC) Systems Research Center (SRC) Modula-3 front end to generate an AST representation. M32CLEFreads the Modula-3 AST and uses the generation interface to convert it to Scale's high-level representation." [1] But anyway in my research found DEC was working just before sold to Compaq in an enriched type system, so I would prefer to let current compiler to do the job just in case we anyhow got their experimental type checker: "Modern programming languages, such as C++, Java, and Ada, include compile-time checks to detect a wide range of possible errors. The checks are based on declaring or inferring a type for each object (i.e., variables and procedures) and analyzing the program to establish that objects are used in ways consistent with their types. This kind of automated support is especially helpful for detecting the kinds of errors (such as passing arguments that overflow a corresponding parameter) so successfully used by attackers of operating system and network software. Ever more expressive type systems are a continuing theme in programming language research, with considerable attention being directed recently at the representation of security properties using types (Digital Equipment Corporation, 1997). Success would mean that compile-time checks could play an even bigger role in supporting trustworthiness properties. " [2] Thanks in advance for any comment [1]?Abstract?. [on line]. Available on en: ftp://ftp.cs.umass.edu/pub/osl/papers/clef97-abs.html. [Accessed: 31-may-2016]. [2]?Trust in Cyberspace?. [on line]. Available on: http://cryptome.org/tic.htm. [Accessed: 31-may-2016]. El Martes 31 de Mayo de 2016 11:35, Elmar Stellnberger escribi?: Am 2016-05-31 um 09:32 schrieb Jay K: > i.e. I'd really like to get out of the build system business. > like to just use autotools or cmake? A make-based build solution would have other advantages as well like f.i. parallel build by make --jobs=4. That way CM3 could build up to four times faster. > But I suspect our system's qualities is difficult to replicate within the other frameworks. > i.e. the incrementality > The way every dynamic library is also available statically. > ? Why not employ a simple hand written make-file that determines that by environment variables? i.e. what libraries to build statically. _______________________________________________ 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 mika at async.caltech.edu Tue May 31 19:16:05 2016 From: mika at async.caltech.edu (mika at async.caltech.edu) Date: Tue, 31 May 2016 10:16:05 -0700 Subject: [M3devel] replace build system?? In-Reply-To: <1784674298.4028093.1464714373116.JavaMail.yahoo@mail.yahoo.com> References: <1784674298.4028093.1464714373116.JavaMail.yahoo@mail.yahoo.com> Message-ID: <20160531171605.13AA61A2068@async.async.caltech.edu> I mentioned this before a few times on this mailing list.... CM3 is already fairly parallel if you turn on the right options. Every back-end invocation can be done in parallel. Set M3_PARALLEL_BACK in the config to 10 or 20 and watch it go... "Daniel Alejandro Benavides D." writes: ... >A make-based build solution would have other advantages as well like=20 >f.i. parallel build by make --jobs=3D4. That way CM3 could build up to=20 >four times faster. ... From jay.krell at cornell.edu Tue May 31 19:17:15 2016 From: jay.krell at cornell.edu (Jay K) Date: Tue, 31 May 2016 17:17:15 +0000 Subject: [M3devel] replace build system?? In-Reply-To: <20160531160502.GC12646@topoi.pooq.com> References: , <20160531160502.GC12646@topoi.pooq.com> Message-ID: Yes it is a backend within cm3, a peer of cm3cg and the integrated NT/x86 backend. I'd really like to move everyone from cm3cg to it. I tested it a bunch at least a while ago. There is still some scripting or such to make a distribution with it. Currently what is provided is enough to build cm3 and mklib from system-specific C. Statically linked. System-specific is hard to completely fix. Statically linked is normal for cm3/mklib anyway. It generates little Makefiles. Ideally the entire system would be distributed this way. Though merely distributing the cm3cg produced .s/.o/.a files would be an approvement. Everytime I look, I don't like cmake or autotools, nor want to keep maintaining our system-specific config files, nor have the time/energy to write something new in C or C++. ?- Jay ---------------------------------------- > Date: Tue, 31 May 2016 12:05:03 -0400 > From: hendrik at topoi.pooq.com > To: m3devel at elegosoft.com > Subject: Re: [M3devel] replace build system?? > > On Tue, May 31, 2016 at 07:32:23AM +0000, Jay K wrote: >> Design of a new or bootstrap/cross/distribution build system? >> >> >> I'd really like our stuff to be as easy to distribute and develop >> as stuff using e.g. autotools or cmake. And as portable. >> >> >> And to reuse other people's work. >> >> >> And have a solid cross build story. >> >> >> And distribution be C or .o or .a or .S files, not executables and so/dylibs. > > Isn't there an m3 compiler that generates C? Didn't you even write it? > > -- hendrik > k > _______________________________________________ > M3devel mailing list > M3devel at elegosoft.com > https://mail.elegosoft.com/cgi-bin/mailman/listinfo/m3devel From jay.krell at cornell.edu Tue May 31 19:18:46 2016 From: jay.krell at cornell.edu (Jay K) Date: Tue, 31 May 2016 17:18:46 +0000 Subject: [M3devel] replace build system?? In-Reply-To: <20160531171605.13AA61A2068@async.async.caltech.edu> References: , , <1784674298.4028093.1464714373116.JavaMail.yahoo@mail.yahoo.com>, <20160531171605.13AA61A2068@async.async.caltech.edu> Message-ID: We should probably learn how to get the number of processors and optionally system load and make this more automatic. Posix should standardize more of this. :( ?- Jay ---------------------------------------- > To: estellnb at elstel.org; jay.krell at cornell.edu; m3devel at elegosoft.com > To: dabenavidesd at yahoo.es > Date: Tue, 31 May 2016 10:16:05 -0700 > From: mika at async.caltech.edu > Subject: Re: [M3devel] replace build system?? > > I mentioned this before a few times on this mailing list.... CM3 is already fairly > parallel if you turn on the right options. Every back-end invocation can be done > in parallel. > > Set M3_PARALLEL_BACK in the config to 10 or 20 and watch it go... > > "Daniel Alejandro Benavides D." writes: > ... >>A make-based build solution would have other advantages as well like=20 >>f.i. parallel build by make --jobs=3D4. That way CM3 could build up to=20 >>four times faster. > ... > _______________________________________________ > M3devel mailing list > M3devel at elegosoft.com > https://mail.elegosoft.com/cgi-bin/mailman/listinfo/m3devel From dabenavidesd at yahoo.es Wed May 4 03:38:26 2016 From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.) Date: Wed, 4 May 2016 01:38:26 +0000 (UTC) Subject: [M3devel] looking if is there any interest References: <122527900.156772.1462325906591.JavaMail.yahoo.ref@mail.yahoo.com> Message-ID: <122527900.156772.1462325906591.JavaMail.yahoo@mail.yahoo.com> Hi floks:Does anyone think in a Cross Platform development environment system; for instance:1. I have a compiler front end in my tablet (say yet to be finished M3clipse) that creates an AST, 2. and sent to generate code for certain platform (in a CM3-IDE of SRC M3 compiler server) to a given target, 3. Download it and execute it in a terminal or windows client? I finally have resources in hardware to make some development, and looking forward to see get the best idea I can implement. thanks in advance -------------- next part -------------- An HTML attachment was scrubbed... URL: From rodney_bates at lcwb.coop Tue May 10 17:21:42 2016 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Tue, 10 May 2016 10:21:42 -0500 Subject: [M3devel] looking if is there any interest In-Reply-To: <122527900.156772.1462325906591.JavaMail.yahoo@mail.yahoo.com> References: <122527900.156772.1462325906591.JavaMail.yahoo.ref@mail.yahoo.com> <122527900.156772.1462325906591.JavaMail.yahoo@mail.yahoo.com> Message-ID: <5731FC86.5070206@lcwb.coop> I'm not sure I fully understand. You propose to have the front-end run on a tablet, code generation run on a remote server? Presumably because the tablet lacks sufficient hardware resources? Then the code executes where, back on the tablet? Personally, I find editing/developing code without a real keyboard to be so hopelessly painful, I just wouldn't do it. Touch screens have exasperatingly high false positive, false negative, and wrong gesture recognition. Maybe I have different hand capacitance than most people. I would prefer to do the editing off the tablet, in which case, it would make sense that the front-end compiling be done on the compile server too. On 05/03/2016 08:38 PM, Daniel Alejandro Benavides D. wrote: > Hi floks: > Does anyone think in a Cross Platform development environment system; for instance: > 1. I have a compiler front end in my tablet (say yet to be finished M3clipse) that creates an AST, > 2. and sent to generate code for certain platform (in a CM3-IDE of SRC M3 compiler server) to a given target, > 3. Download it and execute it in a terminal or windows client? > > I finally have resources in hardware to make some development, and looking forward to see get the best idea I can implement. > > thanks in advance > > > _______________________________________________ > 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 dabenavidesd at yahoo.es Tue May 10 20:02:33 2016 From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.) Date: Tue, 10 May 2016 18:02:33 +0000 (UTC) Subject: [M3devel] looking if is there any interest In-Reply-To: <5731FC86.5070206@lcwb.coop> References: <122527900.156772.1462325906591.JavaMail.yahoo.ref@mail.yahoo.com> <122527900.156772.1462325906591.JavaMail.yahoo@mail.yahoo.com> <5731FC86.5070206@lcwb.coop> Message-ID: <163359176.3358022.1462903353852.JavaMail.yahoo@mail.yahoo.com> Hello Rodney: more or less yes; it's just taking advantage of the CM3/SRC-M3 compiler infrastructure, as ( and please correct me if wrong): (1) Use a Java enabled device (like a tablet running Android, etc via M3clipse) to type check? and AST ("new "m3front) (2) Receive AST via network service CM3-IDE server and do IR ("m3middle") (3). In a gcc enabled platform code generate m3cg ("m3back") The good part of making this adaptation is that most of machines today are either (1) or (3) type (or both just as you say), so we can make the compiler more readily available? (if 1 and 3 are too ). Also, it would nice to have separate machines for easier working so people can contribute where they want and upgrade programs automatically (every distributed computing advantage). So we just concentrate in (2) to be highly available. Besides there are a lot of (3) type machines. Now I have one question, can we made (2) enough platform independent so just have one machine for all platforms, Jay? Thanks in advance El Martes 10 de Mayo de 2016 10:21, Rodney M. Bates escribi?: I'm not sure I fully understand.? You propose to have the front-end run on a tablet, code generation run on a remote server?? Presumably because the tablet lacks sufficient hardware resources?? Then the code executes where, back on the tablet? Personally, I find editing/developing code without a real keyboard to be so hopelessly painful, I just wouldn't do it.? Touch screens have exasperatingly high false positive, false negative, and wrong gesture recognition.? Maybe I have different hand capacitance than most people.? I would prefer to do the editing off the tablet, in which case, it would make sense that the front-end compiling be done on the compile server too. On 05/03/2016 08:38 PM, Daniel Alejandro Benavides D. wrote: > Hi floks: > Does anyone think in a Cross Platform development environment system; for instance: > 1. I have a compiler front end in my tablet (say yet to be finished M3clipse) that creates an AST, > 2. and sent to generate code for certain platform (in a CM3-IDE of SRC M3 compiler server) to a given target, > 3. Download it and execute it in a terminal or windows client? > > I finally have resources in hardware to make some development, and looking forward to see get the best idea I can implement. > > thanks in advance > > > _______________________________________________ > 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From dabenavidesd at yahoo.es Sat May 14 20:23:42 2016 From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.) Date: Sat, 14 May 2016 18:23:42 +0000 (UTC) Subject: [M3devel] A possible source, target References: <671131443.3734750.1463250222583.JavaMail.yahoo.ref@mail.yahoo.com> Message-ID: <671131443.3734750.1463250222583.JavaMail.yahoo@mail.yahoo.com> Hello:if you mind; what about supporting cross development like this platform: PINE64, the World's First 64-Bit Expandable Supercomputer, Runs Ubuntu and Android 5.1 | ? | | ? | | ? | ? | ? | ? | ? | | PINE64, the World's First 64-Bit Expandable Supercomp...It can also run OpenWrt Linux and openHUB | | | | Ver en news.softpedia.com | Vista previa por Yahoo | | | | ? | just for U$15/?14Thanks in advance -------------- next part -------------- An HTML attachment was scrubbed... URL: From peter.mckinna at gmail.com Mon May 23 04:28:05 2016 From: peter.mckinna at gmail.com (Peter McKinna) Date: Mon, 23 May 2016 12:28:05 +1000 Subject: [M3devel] cm3cg failing on linuxlibc6 Message-ID: I dont know what changed but the backend is crashing on linuxlibc6 when compiled with -O Try compiling m3core. Also some of my low level tests with Long.And and Long.Shift are not working with normal compile without the optimisations on that platform. Bit suspicious. I'm still investigating. Anyone got any clues or can replicate? Thanks Peter -------------- next part -------------- An HTML attachment was scrubbed... URL: From rodney_bates at lcwb.coop Mon May 23 20:40:19 2016 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Mon, 23 May 2016 13:40:19 -0500 Subject: [M3devel] cm3cg failing on linuxlibc6 Message-ID: <57434E93.2030205@lcwb.coop> I did git pull and rebuilt on LINUXLIBC6. The built cm3 executable crashes compiling a very small experiment program: rodney at yellowstone:~/proj/m3/exp/FmtBug/src$ cm3- Segmentation fault (core dumped) m3gdb (after I built it) gives this: rodney at yellowstone:~/proj/m3/exp/FmtBug/src$ m3gdb cm3- GNU gdb plus Modula-3 6.4 Copyright 2005 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i686-pc-linux-gnu"...Using host libthread_db library "/lib/tls/i686/cmov/libthread_db.so.1". (m3gdb) run Starting program: /usr/local/cm3-githead/bin/cm3- [Thread debugging using libthread_db enabled] [New LWP 23615] [New Thread -1216829744 (LWP 23615)] Program received signal SIGSEGV, Segmentation fault. [Switching to Thread -1216829744 (LWP 23615)] 0x0037c26f in siglongjmp () from /lib/tls/i686/cmov/libc.so.6 (m3gdb) bt #0 0x0037c26f in siglongjmp () from /lib/tls/i686/cmov/libc.so.6 #1 0x577b2a84 in ?? () Cannot access memory at address 0xd7a0906f (m3gdb) quit stock gdb gives even less information: rodney at yellowstone:~/proj/m3/exp/FmtBug/src$ gdb cm3- GNU gdb (GDB) 7.1-ubuntu Copyright (C) 2010 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "i486-linux-gnu". For bug reporting instructions, please see: ... Reading symbols from /usr/local/cm3-githead/bin/cm3-...done. (gdb) run Starting program: /usr/local/cm3-githead/bin/cm3- [Thread debugging using libthread_db enabled] Program received signal SIGSEGV, Segmentation fault. 0x0032e26f in ?? () from /lib/tls/i686/cmov/libc.so.6 (gdb) bt #0 0x0032e26f in ?? () from /lib/tls/i686/cmov/libc.so.6 #1 0xfb35d04b in ?? () Cannot access memory at address 0x7bee2da0 (gdb) Note that gdb gives a different address in the same library for the point of fault. m3gdb claims it's in siglongjmp. I recall there were some recent changes involving longjump. On 05/22/2016 09:28 PM, Peter McKinna wrote: > I dont know what changed but the backend is crashing on linuxlibc6 when compiled with -O Try compiling m3core. > > Also some of my low level tests with Long.And and Long.Shift are not working with > normal compile without the optimisations on that platform. Bit suspicious. I'm still investigating. > > Anyone got any clues or can replicate? > > Thanks 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 peter.mckinna at gmail.com Tue May 24 09:24:52 2016 From: peter.mckinna at gmail.com (Peter McKinna) Date: Tue, 24 May 2016 17:24:52 +1000 Subject: [M3devel] cm3cg failing on linuxlibc6 In-Reply-To: <57434E93.2030205@lcwb.coop> References: <57434E93.2030205@lcwb.coop> Message-ID: I may have been a tad hasty in blaming the back end for the crashes, the front end has some explaining to do as well. I was getting an infinite loop in a program which I have cut down here to demonstrate. The original cm3 5.2 I think it was from elegosoft worked fine. The latest produces different intermediate code. First the source, (excuse the size, its extracted from my implementation of grisu which I was on the point of pushing to github) MODULE Main; IMPORT Long,IO,Fmt; CONST kUint64MSB = 16_8000000000000000L; TYPE Uint64 = Long.T; PROCEDURE Normalize(sig : Long.T; exp : INTEGER) = CONST k10MSBits = 16_FFC0000000000000L; VAR significand : Uint64; exponent : INTEGER; BEGIN <*ASSERT sig # 0L *> significand := sig; exponent := exp; (*IO.Put("sig init " & Fmt.LongInt(significand) & "\n");*) (* This method is mainly called for normalizing boundaries. In general boundaries need to be shifted by 10 bits. We thus optimize for this case. *) WHILE Long.And(significand, k10MSBits) = 0L DO significand := Long.LeftShift(significand, 10); (*IO.Put("sig loop 1 " & Fmt.LongInt(significand) & "\n");*) DEC(exponent, 10); END; (*IO.Put("sig after loop 1 " & Fmt.LongInt(significand) & "\n");*) (* IO.PutLongInt(Long.And(significand, kUint64MSB)); IO.Put("\n"); *) WHILE Long.And(significand, kUint64MSB) = 0L DO (*IO.Put("sig loop2 1 " & Fmt.LongInt(significand) & "\n");*) significand := Long.LeftShift(significand, 1); (*IO.Put("sig loop2 2 " & Fmt.LongInt(significand) & "\n");*) DEC(exponent); END; END Normalize; BEGIN Normalize(3L,2); END Main. Now the correct intermediate from the original cm3 Its a shame we cant embed the cm3 version into the intermediate. But theres no mention of widechar so you can tell its an old version. begin_unit 0 -----FILE ../src/Main.m3 ----- -----LINE 1 ----- # module global constants declare_segment * -1 T v.1 # module global data declare_segment M_Main -1 F v.2 -----LINE 45 ----- declare_procedure Main_M3 1 Addr 0 0 T * p.1 declare_param mode 4 4 Int.32 425470580 F F 100 v.3 declare_proctype 1318003907 2 0 0 0 declare_formal sig 89530742 declare_formal exp 425470580 import_procedure Main_I3 0 Addr 0 p.2 export_unit Main import_procedure Fmt_I3 0 Addr 0 p.3 import_unit Fmt import_procedure IO_I3 0 Addr 0 p.4 import_unit IO import_procedure Long_I3 0 Addr 0 p.5 import_unit Long import_procedure RTHooks_I3 0 Addr 0 p.6 import_unit RTHooks declare_typename 89530742 Uint64 declare_procedure Main__Normalize 2 Void 0 0 F * p.7 declare_local significand 8 4 Int.64 89530742 F F 50 v.4 declare_local exponent 4 4 Int.32 425470580 F F 50 v.5 declare_param sig 8 4 Int.64 89530742 F F 50 v.6 declare_param exp 4 4 Int.32 425470580 F F 50 v.7 # Normalize -----LINE 11 ----- begin_procedure p.7 -----LINE 12 ----- -----LINE 19 ----- load v.6 0 Int.64 Int.64 load_integer Int.64 0 if_ne Int.64 L.1 100 import_procedure RTHooks__ReportFault 2 Void 0 p.8 declare_param module 4 4 Addr 138420323 F F 50 v.8 declare_param info 4 4 Int.32 425470580 F F 50 v.9 set_runtime_proc ReportFault p.8 abort 0 . L.1 F -----LINE 20 ----- load v.6 0 Int.64 Int.64 store v.4 0 Int.64 Int.64 -----LINE 21 ----- load v.7 0 Int.32 Int.32 store v.5 0 Int.32 Int.32 -----LINE 26 ----- jump L.2 . L.3 F -----LINE 27 ----- load v.4 0 Int.64 Int.64 load_integer Int.32 10 shift_left Int.64 store v.4 0 Int.64 Int.64 -----LINE 29 ----- load v.5 0 Int.32 Int.32 load_integer Int.32 10 subtract Int.32 store v.5 0 Int.32 Int.32 -----LINE 26 ----- . L.2 F load v.4 0 Int.64 Int.64 load_integer Int.64 -18014398509481984 and Int.64 load_integer Int.64 0 if_eq Int.64 L.3 80 . L.4 F -----LINE 36 ----- jump L.5 . L.6 F -----LINE 38 ----- load v.4 0 Int.64 Int.64 load_integer Int.32 1 shift_left Int.64 store v.4 0 Int.64 Int.64 -----LINE 40 ----- load v.5 0 Int.32 Int.32 load_integer Int.32 1 subtract Int.32 store v.5 0 Int.32 Int.32 -----LINE 36 ----- . L.5 F load v.4 0 Int.64 Int.64 load_integer Int.64 -9223372036854775808 and Int.64 load_integer Int.64 0 if_eq Int.64 L.6 80 . L.7 F -----LINE 43 ----- exit_proc Void end_procedure p.7 # Main_M3 # module main body Main_M3 -----LINE 45 ----- begin_procedure p.1 load v.3 0 Int.32 Int.32 if_false Int.32 L.8 0 -----LINE 47 ----- start_call_direct p.7 0 Void load_integer Int.64 3 pop_param Int.64 load_integer Int.32 2 pop_param Int.32 call_direct p.7 Void . L.8 F load_address v.2 0 exit_proc Addr end_procedure p.1 # global constant type descriptor declare_record -1 448 0 # global data type descriptor declare_record -1 896 0 # module global constants bind_segment v.1 56 4 Struct F T begin_init v.1 # procedure names init_chars 0 "Main_M3" init_chars 8 "Normalize" # procedure table init_proc 20 p.1 init_var 24 v.1 0 init_proc 28 p.7 init_var 32 v.1 8 # file name init_chars 40 "../src/Main.m3" end_init v.1 # module global data bind_segment v.2 112 4 Struct F T begin_init v.2 init_var 0 v.1 40 init_var 20 v.1 20 init_var 36 v.2 52 init_proc 44 p.1 init_int 48 3 Int.32 init_proc 56 p.2 init_var 60 v.2 64 init_proc 68 p.3 init_var 72 v.2 76 init_proc 80 p.4 init_var 84 v.2 88 init_proc 92 p.5 init_var 96 v.2 100 init_proc 104 p.6 end_init v.2 # load map # # # global data allocation for M_Main # 0 52 4 *module info* # 52 12 4 import Main # 64 12 4 import Fmt # 76 12 4 import IO # 88 12 4 import Long # 100 12 4 import RTHooks # 112 0 4 *TOTAL* # # # global constants for M_Main # 0 18 4 *proc names* # 20 20 4 *proc info* # 40 15 1 *string* # 56 0 4 *TOTAL* # end_unit Now the intermediate from the latest compiler begin_unit 0 widechar_size 16 -----FILE ../src/Main.m3 ----- -----LINE 1 ----- # module global constants declare_segment * -1 T v.1 # module global data declare_segment M_Main -1 F v.2 -----LINE 45 ----- declare_procedure Main_M3 1 Addr 0 0 T * p.1 declare_param mode 4 4 Int.32 425470580 F F 100 v.3 declare_proctype 1318003907 2 0 0 0 declare_formal sig 89530742 declare_formal exp 425470580 import_procedure Main_I3 0 Addr 0 p.2 export_unit Main import_procedure Fmt_I3 0 Addr 0 p.3 import_unit Fmt import_procedure IO_I3 0 Addr 0 p.4 import_unit IO import_procedure Long_I3 0 Addr 0 p.5 import_unit Long import_procedure RTHooks_I3 0 Addr 0 p.6 import_unit RTHooks declare_typename 89530742 Uint64 declare_procedure Main__Normalize 2 Void 0 0 F * p.7 declare_local significand 8 8 Int.64 89530742 F F 50 v.4 declare_local exponent 4 4 Int.32 425470580 F F 50 v.5 declare_param sig 8 8 Int.64 89530742 F F 50 v.6 declare_param exp 4 4 Int.32 425470580 F F 50 v.7 # Normalize -----LINE 11 ----- begin_procedure p.7 -----LINE 12 ----- -----LINE 19 ----- load_integer Int.64 0 load v.6 0 Int.64 Int.64 if_ne Int.64 L.1 100 declare_proctype -1531209598 2 0 -1 0 declare_formal module 138420323 declare_formal info 425470580 import_procedure RTHooks__ReportFault 2 Void 0 p.8 declare_param module 4 4 Addr 138420323 F F 50 v.8 declare_param info 4 4 Int.32 425470580 F F 50 v.9 set_runtime_proc ReportFault p.8 abort 0 . L.1 F -----LINE 20 ----- load v.6 0 Int.64 Int.64 store v.4 0 Int.64 Int.64 -----LINE 21 ----- load v.7 0 Int.32 Int.32 store v.5 0 Int.32 Int.32 -----LINE 26 ----- jump L.2 . L.3 F -----LINE 27 ----- load v.4 0 Int.64 Int.64 load_integer Int.32 10 shift_left Word.64 store v.4 0 Int.64 Int.64 -----LINE 29 ----- load v.5 0 Int.32 Int.32 load_integer Int.32 10 subtract Int.32 store v.5 0 Int.32 Int.32 -----LINE 26 ----- . L.2 F load_integer Int.64 -18014398509481984 load v.4 0 Int.64 Int.64 and Word.64 load_integer Int.64 0 if_eq Int.64 L.3 80 . L.4 F -----LINE 36 ----- jump L.5 . L.6 F -----LINE 38 ----- load v.4 0 Int.64 Int.64 load_integer Int.32 1 shift_left Word.64 store v.4 0 Int.64 Int.64 -----LINE 40 ----- load v.5 0 Int.32 Int.32 load_integer Int.32 1 subtract Int.32 store v.5 0 Int.32 Int.32 -----LINE 36 ----- . L.5 F load_integer Int.64 0 load v.4 0 Int.64 Int.64 and Word.64 load_integer Int.64 0 if_eq Int.64 L.6 80 . L.7 F -----LINE 43 ----- exit_proc Void end_procedure p.7 # Main_M3 # module main body Main_M3 -----LINE 45 ----- begin_procedure p.1 load v.3 0 Int.32 Int.32 if_false Int.32 L.8 0 -----LINE 47 ----- start_call_direct p.7 0 Void load_integer Int.64 3 pop_param Int.64 load_integer Int.32 2 pop_param Int.32 call_direct p.7 Void . L.8 F load_address v.2 0 exit_proc Addr end_procedure p.1 # global constant type descriptor declare_record -1 448 0 # global data type descriptor declare_record -1 896 0 # module global constants bind_segment v.1 56 8 Struct F T begin_init v.1 # procedure names init_chars 0 "Main_M3" init_chars 8 "Normalize" # procedure table init_proc 20 p.1 init_var 24 v.1 0 init_proc 28 p.7 init_var 32 v.1 8 # file name init_chars 40 "../src/Main.m3" end_init v.1 # module global data bind_segment v.2 112 8 Struct F T begin_init v.2 init_var 0 v.1 40 init_var 20 v.1 20 init_var 36 v.2 52 init_proc 44 p.1 init_int 48 3 Int.32 init_proc 56 p.2 init_var 60 v.2 64 init_proc 68 p.3 init_var 72 v.2 76 init_proc 80 p.4 init_var 84 v.2 88 init_proc 92 p.5 init_var 96 v.2 100 init_proc 104 p.6 end_init v.2 # load map # # # global data allocation for M_Main # 0 52 4 *module info* # 52 12 4 import Main # 64 12 4 import Fmt # 76 12 4 import IO # 88 12 4 import Long # 100 12 4 import RTHooks # 112 0 4 *TOTAL* # # # global constants for M_Main # 0 18 4 *proc names* # 20 20 4 *proc info* # 40 15 1 *string* # 56 0 4 *TOTAL* # end_unit Its very similar except for using Word.64 instead of Int.64 and a couple of other cosmetic issues. The trouble is near label L5 where it does a load_integer of 0 instead of the big constant. The result of anding the zero and testing for zero is causing the loop. Compiling this with -O also causes the backend to crash. Both of these are on LINUXLIBC6. The AMD64 intermediate is correct. Seems like its not parsing the big long for some reason or else its wrapping around. Any ideas? Regards Peter On Tue, May 24, 2016 at 4:40 AM, Rodney M. Bates wrote: > > > > I did git pull and rebuilt on LINUXLIBC6. The built cm3 executable > crashes compiling > a very small experiment program: > > rodney at yellowstone:~/proj/m3/exp/FmtBug/src$ cm3- > Segmentation fault (core dumped) > > m3gdb (after I built it) gives this: > > rodney at yellowstone:~/proj/m3/exp/FmtBug/src$ m3gdb cm3- > GNU gdb plus Modula-3 6.4 > Copyright 2005 Free Software Foundation, Inc. > GDB is free software, covered by the GNU General Public License, and you > are > welcome to change it and/or distribute copies of it under certain > conditions. > Type "show copying" to see the conditions. > There is absolutely no warranty for GDB. Type "show warranty" for > details. > This GDB was configured as "i686-pc-linux-gnu"...Using host libthread_db > library "/lib/tls/i686/cmov/libthread_db.so.1". > > (m3gdb) run > Starting program: /usr/local/cm3-githead/bin/cm3- > [Thread debugging using libthread_db enabled] > [New LWP 23615] > [New Thread -1216829744 (LWP 23615)] > > Program received signal SIGSEGV, Segmentation fault. > [Switching to Thread -1216829744 (LWP 23615)] > 0x0037c26f in siglongjmp () from /lib/tls/i686/cmov/libc.so.6 > (m3gdb) bt > #0 0x0037c26f in siglongjmp () from /lib/tls/i686/cmov/libc.so.6 > #1 0x577b2a84 in ?? () > Cannot access memory at address 0xd7a0906f > (m3gdb) quit > > > stock gdb gives even less information: > > rodney at yellowstone:~/proj/m3/exp/FmtBug/src$ gdb cm3- > GNU gdb (GDB) 7.1-ubuntu > Copyright (C) 2010 Free Software Foundation, Inc. > License GPLv3+: GNU GPL version 3 or later < > http://gnu.org/licenses/gpl.html> > This is free software: you are free to change and redistribute it. > There is NO WARRANTY, to the extent permitted by law. Type "show > copying" > and "show warranty" for details. > This GDB was configured as "i486-linux-gnu". > For bug reporting instructions, please see: > ... > Reading symbols from /usr/local/cm3-githead/bin/cm3-...done. > (gdb) run > Starting program: /usr/local/cm3-githead/bin/cm3- > [Thread debugging using libthread_db enabled] > > Program received signal SIGSEGV, Segmentation fault. > 0x0032e26f in ?? () from /lib/tls/i686/cmov/libc.so.6 > (gdb) bt > #0 0x0032e26f in ?? () from /lib/tls/i686/cmov/libc.so.6 > #1 0xfb35d04b in ?? () > Cannot access memory at address 0x7bee2da0 > (gdb) > > Note that gdb gives a different address in the same library for the point > of fault. > > m3gdb claims it's in siglongjmp. I recall there were some recent changes > involving > longjump. > > > > > > > On 05/22/2016 09:28 PM, Peter McKinna wrote: > > I dont know what changed but the backend is crashing on linuxlibc6 when > compiled with -O Try compiling m3core. > > > > Also some of my low level tests with Long.And and Long.Shift are not > working with > > normal compile without the optimisations on that platform. Bit > suspicious. I'm still investigating. > > > > Anyone got any clues or can replicate? > > > > Thanks 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rodney_bates at lcwb.coop Thu May 26 05:58:11 2016 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Wed, 25 May 2016 22:58:11 -0500 Subject: [M3devel] cm3cg failing on linuxlibc6 In-Reply-To: References: <57434E93.2030205@lcwb.coop> Message-ID: <57467453.4040702@lcwb.coop> Just an FYI on the And bug. I think I have diagnosed this for this particular case. TInt.ToBytes is following the invariants of a TInt.T, which always uses twos-complement notation, but, with a 9th byte, is big enough to hold the entire overlap of the 64-bit signed and unsigned ranges. OTOH, M3CG_BinWr.AddBigX is converting to signed-magnitude, with a separate sign. It passes an absolute value to ToBytes. For only this single value 16_8000000000000000, this is representable as a positive absolute value in 8 bytes, but ToBytes correctly considers this too few bytes for twos-complement and returns zero. It will take more work to look at all the calls on ToBytes and ascertain which cases suffer this mismatch. Also, I am currently unable to build a working compiler for LINUXLIBC6, something to do with jumbufs. So I will have to get around that before testing a fix and for regressions. It looks like it doesn't happen when compiling on a 64-bit machine because that takes a different path, using native INTEGER rather than TInt for the constant value. On 05/24/2016 02:24 AM, Peter McKinna wrote: > I may have been a tad hasty in blaming the back end for the crashes, the front end has some explaining to do as well. > > I was getting an infinite loop in a program which I have cut down here to demonstrate. The original cm3 5.2 I think it > was from elegosoft worked fine. The latest produces different intermediate code. > > First the source, (excuse the size, its extracted from my implementation of grisu which I was on the point of pushing to github) > > MODULE Main; > > IMPORT Long,IO,Fmt; > > CONST > kUint64MSB = 16_8000000000000000L; > > TYPE > Uint64 = Long.T; > PROCEDURE Normalize(sig : Long.T; exp : INTEGER) = > CONST > k10MSBits = 16_FFC0000000000000L; > VAR > significand : Uint64; > exponent : INTEGER; > > BEGIN > <*ASSERT sig # 0L *> > significand := sig; > exponent := exp; > (*IO.Put("sig init " & Fmt.LongInt(significand) & "\n");*) > > (* This method is mainly called for normalizing boundaries. In general > boundaries need to be shifted by 10 bits. We thus optimize for this case. *) > WHILE Long.And(significand, k10MSBits) = 0L DO > significand := Long.LeftShift(significand, 10); > (*IO.Put("sig loop 1 " & Fmt.LongInt(significand) & "\n");*) > DEC(exponent, 10); > END; > (*IO.Put("sig after loop 1 " & Fmt.LongInt(significand) & "\n");*) > (* > IO.PutLongInt(Long.And(significand, kUint64MSB)); > IO.Put("\n"); > *) > WHILE Long.And(significand, kUint64MSB) = 0L DO > (*IO.Put("sig loop2 1 " & Fmt.LongInt(significand) & "\n");*) > significand := Long.LeftShift(significand, 1); > (*IO.Put("sig loop2 2 " & Fmt.LongInt(significand) & "\n");*) > DEC(exponent); > END; > END Normalize; > BEGIN > > Normalize(3L,2); > END Main. > > Now the correct intermediate from the original cm3 > Its a shame we cant embed the cm3 version into the intermediate. But theres no mention of widechar so you can tell its an old > version. > > begin_unit0 > -----FILE ../src/Main.m3 ----- > -----LINE 1 ----- > # module global constants > declare_segment* -1 T v.1 > # module global data > declare_segmentM_Main -1 F v.2 > -----LINE 45 ----- > declare_procedureMain_M3 1 Addr 0 0 T * p.1 > declare_parammode 4 4 Int.32 425470580 F F 100 v.3 > declare_proctype1318003907 2 0 0 0 > declare_formalsig 89530742 > declare_formalexp 425470580 > import_procedureMain_I3 0 Addr 0 p.2 > export_unitMain > import_procedureFmt_I3 0 Addr 0 p.3 > import_unitFmt > import_procedureIO_I3 0 Addr 0 p.4 > import_unitIO > import_procedureLong_I3 0 Addr 0 p.5 > import_unitLong > import_procedureRTHooks_I3 0 Addr 0 p.6 > import_unitRTHooks > declare_typename89530742 Uint64 > declare_procedureMain__Normalize 2 Void 0 0 F * p.7 > declare_localsignificand 8 4 Int.64 89530742 F F 50 v.4 > declare_localexponent 4 4 Int.32 425470580 F F 50 v.5 > declare_paramsig 8 4 Int.64 89530742 F F 50 v.6 > declare_paramexp 4 4 Int.32 425470580 F F 50 v.7 > # Normalize > -----LINE 11 ----- > begin_procedurep.7 > -----LINE 12 ----- > -----LINE 19 ----- > loadv.6 0 Int.64 Int.64 > load_integerInt.64 0 > if_neInt.64 L.1 100 > import_procedureRTHooks__ReportFault 2 Void 0 p.8 > declare_parammodule 4 4 Addr 138420323 F F 50 v.8 > declare_paraminfo 4 4 Int.32 425470580 F F 50 v.9 > set_runtime_procReportFault p.8 > abort0 > . L.1 F > -----LINE 20 ----- > loadv.6 0 Int.64 Int.64 > storev.4 0 Int.64 Int.64 > -----LINE 21 ----- > loadv.7 0 Int.32 Int.32 > storev.5 0 Int.32 Int.32 > -----LINE 26 ----- > jumpL.2 > . L.3 F > -----LINE 27 ----- > loadv.4 0 Int.64 Int.64 > load_integerInt.32 10 > shift_leftInt.64 > storev.4 0 Int.64 Int.64 > -----LINE 29 ----- > loadv.5 0 Int.32 Int.32 > load_integerInt.32 10 > subtractInt.32 > storev.5 0 Int.32 Int.32 > -----LINE 26 ----- > . L.2 F > loadv.4 0 Int.64 Int.64 > load_integerInt.64 -18014398509481984 > andInt.64 > load_integerInt.64 0 > if_eqInt.64 L.3 80 > . L.4 F > -----LINE 36 ----- > jumpL.5 > . L.6 F > -----LINE 38 ----- > loadv.4 0 Int.64 Int.64 > load_integerInt.32 1 > shift_leftInt.64 > storev.4 0 Int.64 Int.64 > -----LINE 40 ----- > loadv.5 0 Int.32 Int.32 > load_integerInt.32 1 > subtractInt.32 > storev.5 0 Int.32 Int.32 > -----LINE 36 ----- > . L.5 F > loadv.4 0 Int.64 Int.64 > load_integerInt.64 -9223372036854775808 > andInt.64 > load_integerInt.64 0 > if_eqInt.64 L.6 80 > . L.7 F > -----LINE 43 ----- > exit_procVoid > end_procedurep.7 > # Main_M3 > # module main body Main_M3 > -----LINE 45 ----- > begin_procedurep.1 > loadv.3 0 Int.32 Int.32 > if_falseInt.32 L.8 0 > -----LINE 47 ----- > start_call_directp.7 0 Void > load_integerInt.64 3 > pop_paramInt.64 > load_integerInt.32 2 > pop_paramInt.32 > call_directp.7 Void > . L.8 F > load_addressv.2 0 > exit_procAddr > end_procedurep.1 > # global constant type descriptor > declare_record-1 448 0 > # global data type descriptor > declare_record-1 896 0 > # module global constants > bind_segmentv.1 56 4 Struct F T > begin_initv.1 > # procedure names > init_chars0 "Main_M3" > init_chars8 "Normalize" > # procedure table > init_proc20 p.1 > init_var24 v.1 0 > init_proc28 p.7 > init_var32 v.1 8 > # file name > init_chars40 "../src/Main.m3" > end_initv.1 > # module global data > bind_segmentv.2 112 4 Struct F T > begin_initv.2 > init_var0 v.1 40 > init_var20 v.1 20 > init_var36 v.2 52 > init_proc44 p.1 > init_int48 3 Int.32 > init_proc56 p.2 > init_var60 v.2 64 > init_proc68 p.3 > init_var72 v.2 76 > init_proc80 p.4 > init_var84 v.2 88 > init_proc92 p.5 > init_var96 v.2 100 > init_proc104 p.6 > end_initv.2 > # load map > # > # > # global data allocation for M_Main > # 0 52 4 *module info* > # 52 12 4 import Main > # 64 12 4 import Fmt > # 76 12 4 import IO > # 88 12 4 import Long > # 100 12 4 import RTHooks > # 112 0 4 *TOTAL* > # > # > # global constants for M_Main > # 0 18 4 *proc names* > # 20 20 4 *proc info* > # 40 15 1 *string* > # 56 0 4 *TOTAL* > # > end_unit > > > Now the intermediate from the latest compiler > > begin_unit0 > widechar_size16 > -----FILE ../src/Main.m3 ----- > -----LINE 1 ----- > # module global constants > declare_segment* -1 T v.1 > # module global data > declare_segmentM_Main -1 F v.2 > -----LINE 45 ----- > declare_procedureMain_M3 1 Addr 0 0 T * p.1 > declare_parammode 4 4 Int.32 425470580 F F 100 v.3 > declare_proctype1318003907 2 0 0 0 > declare_formalsig 89530742 > declare_formalexp 425470580 > import_procedureMain_I3 0 Addr 0 p.2 > export_unitMain > import_procedureFmt_I3 0 Addr 0 p.3 > import_unitFmt > import_procedureIO_I3 0 Addr 0 p.4 > import_unitIO > import_procedureLong_I3 0 Addr 0 p.5 > import_unitLong > import_procedureRTHooks_I3 0 Addr 0 p.6 > import_unitRTHooks > declare_typename89530742 Uint64 > declare_procedureMain__Normalize 2 Void 0 0 F * p.7 > declare_localsignificand 8 8 Int.64 89530742 F F 50 v.4 > declare_localexponent 4 4 Int.32 425470580 F F 50 v.5 > declare_paramsig 8 8 Int.64 89530742 F F 50 v.6 > declare_paramexp 4 4 Int.32 425470580 F F 50 v.7 > # Normalize > -----LINE 11 ----- > begin_procedurep.7 > -----LINE 12 ----- > -----LINE 19 ----- > load_integerInt.64 0 > loadv.6 0 Int.64 Int.64 > if_neInt.64 L.1 100 > declare_proctype-1531209598 2 0 -1 0 > declare_formalmodule 138420323 > declare_formalinfo 425470580 > import_procedureRTHooks__ReportFault 2 Void 0 p.8 > declare_parammodule 4 4 Addr 138420323 F F 50 v.8 > declare_paraminfo 4 4 Int.32 425470580 F F 50 v.9 > set_runtime_procReportFault p.8 > abort0 > . L.1 F > -----LINE 20 ----- > loadv.6 0 Int.64 Int.64 > storev.4 0 Int.64 Int.64 > -----LINE 21 ----- > loadv.7 0 Int.32 Int.32 > storev.5 0 Int.32 Int.32 > -----LINE 26 ----- > jumpL.2 > . L.3 F > -----LINE 27 ----- > loadv.4 0 Int.64 Int.64 > load_integerInt.32 10 > shift_leftWord.64 > storev.4 0 Int.64 Int.64 > -----LINE 29 ----- > loadv.5 0 Int.32 Int.32 > load_integerInt.32 10 > subtractInt.32 > storev.5 0 Int.32 Int.32 > -----LINE 26 ----- > . L.2 F > load_integerInt.64 -18014398509481984 > loadv.4 0 Int.64 Int.64 > andWord.64 > load_integerInt.64 0 > if_eqInt.64 L.3 80 > . L.4 F > -----LINE 36 ----- > jumpL.5 > . L.6 F > -----LINE 38 ----- > loadv.4 0 Int.64 Int.64 > load_integerInt.32 1 > shift_leftWord.64 > storev.4 0 Int.64 Int.64 > -----LINE 40 ----- > loadv.5 0 Int.32 Int.32 > load_integerInt.32 1 > subtractInt.32 > storev.5 0 Int.32 Int.32 > -----LINE 36 ----- > . L.5 F > load_integerInt.64 0 > loadv.4 0 Int.64 Int.64 > andWord.64 > load_integerInt.64 0 > if_eqInt.64 L.6 80 > . L.7 F > -----LINE 43 ----- > exit_procVoid > end_procedurep.7 > # Main_M3 > # module main body Main_M3 > -----LINE 45 ----- > begin_procedurep.1 > loadv.3 0 Int.32 Int.32 > if_falseInt.32 L.8 0 > -----LINE 47 ----- > start_call_directp.7 0 Void > load_integerInt.64 3 > pop_paramInt.64 > load_integerInt.32 2 > pop_paramInt.32 > call_directp.7 Void > . L.8 F > load_addressv.2 0 > exit_procAddr > end_procedurep.1 > # global constant type descriptor > declare_record-1 448 0 > # global data type descriptor > declare_record-1 896 0 > # module global constants > bind_segmentv.1 56 8 Struct F T > begin_initv.1 > # procedure names > init_chars0 "Main_M3" > init_chars8 "Normalize" > # procedure table > init_proc20 p.1 > init_var24 v.1 0 > init_proc28 p.7 > init_var32 v.1 8 > # file name > init_chars40 "../src/Main.m3" > end_initv.1 > # module global data > bind_segmentv.2 112 8 Struct F T > begin_initv.2 > init_var0 v.1 40 > init_var20 v.1 20 > init_var36 v.2 52 > init_proc44 p.1 > init_int48 3 Int.32 > init_proc56 p.2 > init_var60 v.2 64 > init_proc68 p.3 > init_var72 v.2 76 > init_proc80 p.4 > init_var84 v.2 88 > init_proc92 p.5 > init_var96 v.2 100 > init_proc104 p.6 > end_initv.2 > # load map > # > # > # global data allocation for M_Main > # 0 52 4 *module info* > # 52 12 4 import Main > # 64 12 4 import Fmt > # 76 12 4 import IO > # 88 12 4 import Long > # 100 12 4 import RTHooks > # 112 0 4 *TOTAL* > # > # > # global constants for M_Main > # 0 18 4 *proc names* > # 20 20 4 *proc info* > # 40 15 1 *string* > # 56 0 4 *TOTAL* > # > end_unit > > > Its very similar except for using Word.64 instead of Int.64 and a couple of other cosmetic issues. > The trouble is near label L5 where it does a load_integer of 0 instead of the big constant. > The result of anding the zero and testing for zero is causing the loop. > Compiling this with -O also causes the backend to crash. > Both of these are on LINUXLIBC6. The AMD64 intermediate is correct. Seems like its not parsing the > big long for some reason or else its wrapping around. > > Any ideas? > > Regards Peter > > > > On Tue, May 24, 2016 at 4:40 AM, Rodney M. Bates > wrote: > > > > > I did git pull and rebuilt on LINUXLIBC6. The built cm3 executable crashes compiling > a very small experiment program: > > rodney at yellowstone:~/proj/m3/exp/FmtBug/src$ cm3- > Segmentation fault (core dumped) > > m3gdb (after I built it) gives this: > > rodney at yellowstone:~/proj/m3/exp/FmtBug/src$ m3gdb cm3- > GNU gdb plus Modula-3 6.4 > Copyright 2005 Free Software Foundation, Inc. > GDB is free software, covered by the GNU General Public License, and you are > welcome to change it and/or distribute copies of it under certain conditions. > Type "show copying" to see the conditions. > There is absolutely no warranty for GDB. Type "show warranty" for details. > This GDB was configured as "i686-pc-linux-gnu"...Using host libthread_db library "/lib/tls/i686/cmov/libthread_db.so.1". > > (m3gdb) run > Starting program: /usr/local/cm3-githead/bin/cm3- > [Thread debugging using libthread_db enabled] > [New LWP 23615] > [New Thread -1216829744 (LWP 23615)] > > Program received signal SIGSEGV, Segmentation fault. > [Switching to Thread -1216829744 (LWP 23615)] > 0x0037c26f in siglongjmp () from /lib/tls/i686/cmov/libc.so.6 > (m3gdb) bt > #0 0x0037c26f in siglongjmp () from /lib/tls/i686/cmov/libc.so.6 > #1 0x577b2a84 in ?? () > Cannot access memory at address 0xd7a0906f > (m3gdb) quit > > > stock gdb gives even less information: > > rodney at yellowstone:~/proj/m3/exp/FmtBug/src$ gdb cm3- > GNU gdb (GDB) 7.1-ubuntu > Copyright (C) 2010 Free Software Foundation, Inc. > License GPLv3+: GNU GPL version 3 or later > This is free software: you are free to change and redistribute it. > There is NO WARRANTY, to the extent permitted by law. Type "show copying" > and "show warranty" for details. > This GDB was configured as "i486-linux-gnu". > For bug reporting instructions, please see: > ... > Reading symbols from /usr/local/cm3-githead/bin/cm3-...done. > (gdb) run > Starting program: /usr/local/cm3-githead/bin/cm3- > [Thread debugging using libthread_db enabled] > > Program received signal SIGSEGV, Segmentation fault. > 0x0032e26f in ?? () from /lib/tls/i686/cmov/libc.so.6 > (gdb) bt > #0 0x0032e26f in ?? () from /lib/tls/i686/cmov/libc.so.6 > #1 0xfb35d04b in ?? () > Cannot access memory at address 0x7bee2da0 > (gdb) > > Note that gdb gives a different address in the same library for the point of fault. > > m3gdb claims it's in siglongjmp. I recall there were some recent changes involving > longjump. > > > > > > > On 05/22/2016 09:28 PM, Peter McKinna wrote: > > I dont know what changed but the backend is crashing on linuxlibc6 when compiled with -O Try compiling m3core. > > > > Also some of my low level tests with Long.And and Long.Shift are not working with > > normal compile without the optimisations on that platform. Bit suspicious. I'm still investigating. > > > > Anyone got any clues or can replicate? > > > > Thanks 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 Thu May 26 19:03:46 2016 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Thu, 26 May 2016 12:03:46 -0500 Subject: [M3devel] cm3cg failing on linuxlibc6 In-Reply-To: References: <57434E93.2030205@lcwb.coop> <57467453.4040702@lcwb.coop> Message-ID: <57472C72.8090904@lcwb.coop> I am getting this output from your example, with the output commented back in: sig init 3 sig loop 1 3072 sig loop 1 3145728 sig loop 1 3221225472 sig loop 1 3298534883328 sig loop 1 3377699720527872 sig loop 1 3458764513820540928 sig after loop 1 3458764513820540928 0 sig loop2 1 3458764513820540928 sig loop2 2 6917529027641081856 sig loop2 1 6917529027641081856 sig loop2 2 -4611686018427387904 Does it look right? The IR looks right: $ diff Main.mc.m3cgcat.bad Main.mc.m3cgcat 34c34 < load_integer Int.64 0 --- > load_integer Int.64 -9223372036854775808 It still needs some regression testing and wrapping up. On 05/26/2016 12:08 AM, Peter McKinna wrote: > Wow, nice work. Is there a problem in the backend as well? Or other problems in the front end? I suspect the back end problem is something else. That's next. > That dodgy intermediate looked like perfectly good code apart from the loop > so I cant understand why the back end would crash with optimizations on. > > Also what is the deal with jump bufs ? This is unrelated. It just prevented getting a running cm3 on LINUXLIBC6. I now have gotten around thislocally, but it needs more work to not break other platforms. > > Regards Peter > > > On Thu, May 26, 2016 at 1:58 PM, Rodney M. Bates > wrote: > > Just an FYI on the And bug. > > I think I have diagnosed this for this particular case. TInt.ToBytes is following > the invariants of a TInt.T, which always uses twos-complement notation, but, with > a 9th byte, is big enough to hold the entire overlap of the 64-bit signed and unsigned > ranges. OTOH, M3CG_BinWr.AddBigX is converting to signed-magnitude, with a separate > sign. It passes an absolute value to ToBytes. For only this single value > 16_8000000000000000, this is representable as a positive absolute value in 8 bytes, > but ToBytes correctly considers this too few bytes for twos-complement and returns > zero. > > It will take more work to look at all the calls on ToBytes and ascertain which > cases suffer this mismatch. Also, I am currently unable to build a working > compiler for LINUXLIBC6, something to do with jumbufs. So I will have to get around > that before testing a fix and for regressions. > > It looks like it doesn't happen when compiling on a 64-bit machine because that > takes a different path, using native INTEGER rather than TInt for the constant > value. > > > On 05/24/2016 02:24 AM, Peter McKinna wrote: > > I may have been a tad hasty in blaming the back end for the crashes, the front end has some explaining to do as well. > > I was getting an infinite loop in a program which I have cut down here to demonstrate. The original cm3 5.2 I think it > was from elegosoft worked fine. The latest produces different intermediate code. > > First the source, (excuse the size, its extracted from my implementation of grisu which I was on the point of pushing to github) > > MODULE Main; > > IMPORT Long,IO,Fmt; > > CONST > kUint64MSB = 16_8000000000000000L; > > TYPE > Uint64 = Long.T; > PROCEDURE Normalize(sig : Long.T; exp : INTEGER) = > CONST > k10MSBits = 16_FFC0000000000000L; > VAR > significand : Uint64; > exponent : INTEGER; > > BEGIN > <*ASSERT sig # 0L *> > significand := sig; > exponent := exp; > (*IO.Put("sig init " & Fmt.LongInt(significand) & "\n");*) > > (* This method is mainly called for normalizing boundaries. In general > boundaries need to be shifted by 10 bits. We thus optimize for this case. *) > WHILE Long.And(significand, k10MSBits) = 0L DO > significand := Long.LeftShift(significand, 10); > (*IO.Put("sig loop 1 " & Fmt.LongInt(significand) & "\n");*) > DEC(exponent, 10); > END; > (*IO.Put("sig after loop 1 " & Fmt.LongInt(significand) & "\n");*) > (* > IO.PutLongInt(Long.And(significand, kUint64MSB)); > IO.Put("\n"); > *) > WHILE Long.And(significand, kUint64MSB) = 0L DO > (*IO.Put("sig loop2 1 " & Fmt.LongInt(significand) & "\n");*) > significand := Long.LeftShift(significand, 1); > (*IO.Put("sig loop2 2 " & Fmt.LongInt(significand) & "\n");*) > DEC(exponent); > END; > END Normalize; > BEGIN > > Normalize(3L,2); > END Main. > > Now the correct intermediate from the original cm3 > Its a shame we cant embed the cm3 version into the intermediate. But theres no mention of widechar so you can tell its an old > version. > > begin_unit0 > -----FILE ../src/Main.m3 ----- > -----LINE 1 ----- > # module global constants > declare_segment* -1 T v.1 > # module global data > declare_segmentM_Main -1 F v.2 > -----LINE 45 ----- > declare_procedureMain_M3 1 Addr 0 0 T * p.1 > declare_parammode 4 4 Int.32 425470580 F F 100 v.3 > declare_proctype1318003907 2 0 0 0 > declare_formalsig 89530742 > declare_formalexp 425470580 > import_procedureMain_I3 0 Addr 0 p.2 > export_unitMain > import_procedureFmt_I3 0 Addr 0 p.3 > import_unitFmt > import_procedureIO_I3 0 Addr 0 p.4 > import_unitIO > import_procedureLong_I3 0 Addr 0 p.5 > import_unitLong > import_procedureRTHooks_I3 0 Addr 0 p.6 > import_unitRTHooks > declare_typename89530742 Uint64 > declare_procedureMain__Normalize 2 Void 0 0 F * p.7 > declare_localsignificand 8 4 Int.64 89530742 F F 50 v.4 > declare_localexponent 4 4 Int.32 425470580 F F 50 v.5 > declare_paramsig 8 4 Int.64 89530742 F F 50 v.6 > declare_paramexp 4 4 Int.32 425470580 F F 50 v.7 > # Normalize > -----LINE 11 ----- > begin_procedurep.7 > -----LINE 12 ----- > -----LINE 19 ----- > loadv.6 0 Int.64 Int.64 > load_integerInt.64 0 > if_neInt.64 L.1 100 > import_procedureRTHooks__ReportFault 2 Void 0 p.8 > declare_parammodule 4 4 Addr 138420323 F F 50 v.8 > declare_paraminfo 4 4 Int.32 425470580 F F 50 v.9 > set_runtime_procReportFault p.8 > abort0 > . L.1 F > -----LINE 20 ----- > loadv.6 0 Int.64 Int.64 > storev.4 0 Int.64 Int.64 > -----LINE 21 ----- > loadv.7 0 Int.32 Int.32 > storev.5 0 Int.32 Int.32 > -----LINE 26 ----- > jumpL.2 > . L.3 F > -----LINE 27 ----- > loadv.4 0 Int.64 Int.64 > load_integerInt.32 10 > shift_leftInt.64 > storev.4 0 Int.64 Int.64 > -----LINE 29 ----- > loadv.5 0 Int.32 Int.32 > load_integerInt.32 10 > subtractInt.32 > storev.5 0 Int.32 Int.32 > -----LINE 26 ----- > . L.2 F > loadv.4 0 Int.64 Int.64 > load_integerInt.64 -18014398509481984 > andInt.64 > load_integerInt.64 0 > if_eqInt.64 L.3 80 > . L.4 F > -----LINE 36 ----- > jumpL.5 > . L.6 F > -----LINE 38 ----- > loadv.4 0 Int.64 Int.64 > load_integerInt.32 1 > shift_leftInt.64 > storev.4 0 Int.64 Int.64 > -----LINE 40 ----- > loadv.5 0 Int.32 Int.32 > load_integerInt.32 1 > subtractInt.32 > storev.5 0 Int.32 Int.32 > -----LINE 36 ----- > . L.5 F > loadv.4 0 Int.64 Int.64 > load_integerInt.64 -9223372036854775808 > andInt.64 > load_integerInt.64 0 > if_eqInt.64 L.6 80 > . L.7 F > -----LINE 43 ----- > exit_procVoid > end_procedurep.7 > # Main_M3 > # module main body Main_M3 > -----LINE 45 ----- > begin_procedurep.1 > loadv.3 0 Int.32 Int.32 > if_falseInt.32 L.8 0 > -----LINE 47 ----- > start_call_directp.7 0 Void > load_integerInt.64 3 > pop_paramInt.64 > load_integerInt.32 2 > pop_paramInt.32 > call_directp.7 Void > . L.8 F > load_addressv.2 0 > exit_procAddr > end_procedurep.1 > # global constant type descriptor > declare_record-1 448 0 > # global data type descriptor > declare_record-1 896 0 > # module global constants > bind_segmentv.1 56 4 Struct F T > begin_initv.1 > # procedure names > init_chars0 "Main_M3" > init_chars8 "Normalize" > # procedure table > init_proc20 p.1 > init_var24 v.1 0 > init_proc28 p.7 > init_var32 v.1 8 > # file name > init_chars40 "../src/Main.m3" > end_initv.1 > # module global data > bind_segmentv.2 112 4 Struct F T > > begin_initv.2 > init_var0 v.1 40 > init_var20 v.1 20 > init_var36 v.2 52 > init_proc44 p.1 > init_int48 3 Int.32 > init_proc56 p.2 > init_var60 v.2 64 > init_proc68 p.3 > init_var72 v.2 76 > init_proc80 p.4 > init_var84 v.2 88 > init_proc92 p.5 > init_var96 v.2 100 > init_proc104 p.6 > end_initv.2 > # load map > # > # > # global data allocation for M_Main > # 0 52 4 *module info* > # 52 12 4 import Main > # 64 12 4 import Fmt > # 76 12 4 import IO > # 88 12 4 import Long > # 100 12 4 import RTHooks > # 112 0 4 *TOTAL* > # > # > # global constants for M_Main > # 0 18 4 *proc names* > # 20 20 4 *proc info* > # 40 15 1 *string* > # 56 0 4 *TOTAL* > # > end_unit > > > Now the intermediate from the latest compiler > > begin_unit0 > widechar_size16 > -----FILE ../src/Main.m3 ----- > -----LINE 1 ----- > # module global constants > declare_segment* -1 T v.1 > # module global data > declare_segmentM_Main -1 F v.2 > -----LINE 45 ----- > declare_procedureMain_M3 1 Addr 0 0 T * p.1 > declare_parammode 4 4 Int.32 425470580 F F 100 v.3 > declare_proctype1318003907 2 0 0 0 > declare_formalsig 89530742 > declare_formalexp 425470580 > import_procedureMain_I3 0 Addr 0 p.2 > export_unitMain > import_procedureFmt_I3 0 Addr 0 p.3 > import_unitFmt > import_procedureIO_I3 0 Addr 0 p.4 > import_unitIO > import_procedureLong_I3 0 Addr 0 p.5 > import_unitLong > import_procedureRTHooks_I3 0 Addr 0 p.6 > import_unitRTHooks > declare_typename89530742 Uint64 > declare_procedureMain__Normalize 2 Void 0 0 F * p.7 > declare_localsignificand 8 8 Int.64 89530742 F F 50 v.4 > declare_localexponent 4 4 Int.32 425470580 F F 50 v.5 > declare_paramsig 8 8 Int.64 89530742 F F 50 v.6 > declare_paramexp 4 4 Int.32 425470580 F F 50 v.7 > # Normalize > -----LINE 11 ----- > begin_procedurep.7 > -----LINE 12 ----- > -----LINE 19 ----- > load_integerInt.64 0 > loadv.6 0 Int.64 Int.64 > if_neInt.64 L.1 100 > declare_proctype-1531209598 2 0 -1 0 > declare_formalmodule 138420323 > declare_formalinfo 425470580 > import_procedureRTHooks__ReportFault 2 Void 0 p.8 > declare_parammodule 4 4 Addr 138420323 F F 50 v.8 > declare_paraminfo 4 4 Int.32 425470580 F F 50 v.9 > set_runtime_procReportFault p.8 > abort0 > . L.1 F > -----LINE 20 ----- > loadv.6 0 Int.64 Int.64 > storev.4 0 Int.64 Int.64 > -----LINE 21 ----- > loadv.7 0 Int.32 Int.32 > storev.5 0 Int.32 Int.32 > -----LINE 26 ----- > jumpL.2 > . L.3 F > -----LINE 27 ----- > loadv.4 0 Int.64 Int.64 > load_integerInt.32 10 > shift_leftWord.64 > storev.4 0 Int.64 Int.64 > -----LINE 29 ----- > loadv.5 0 Int.32 Int.32 > load_integerInt.32 10 > subtractInt.32 > storev.5 0 Int.32 Int.32 > -----LINE 26 ----- > . L.2 F > load_integerInt.64 -18014398509481984 > loadv.4 0 Int.64 Int.64 > andWord.64 > load_integerInt.64 0 > if_eqInt.64 L.3 80 > . L.4 F > -----LINE 36 ----- > jumpL.5 > . L.6 F > -----LINE 38 ----- > loadv.4 0 Int.64 Int.64 > load_integerInt.32 1 > shift_leftWord.64 > storev.4 0 Int.64 Int.64 > -----LINE 40 ----- > loadv.5 0 Int.32 Int.32 > load_integerInt.32 1 > subtractInt.32 > storev.5 0 Int.32 Int.32 > -----LINE 36 ----- > . L.5 F > load_integerInt.64 0 > loadv.4 0 Int.64 Int.64 > andWord.64 > load_integerInt.64 0 > if_eqInt.64 L.6 80 > . L.7 F > -----LINE 43 ----- > exit_procVoid > end_procedurep.7 > # Main_M3 > # module main body Main_M3 > -----LINE 45 ----- > begin_procedurep.1 > loadv.3 0 Int.32 Int.32 > if_falseInt.32 L.8 0 > -----LINE 47 ----- > start_call_directp.7 0 Void > load_integerInt.64 3 > pop_paramInt.64 > load_integerInt.32 2 > pop_paramInt.32 > call_directp.7 Void > . L.8 F > load_addressv.2 0 > exit_procAddr > end_procedurep.1 > # global constant type descriptor > declare_record-1 448 0 > # global data type descriptor > declare_record-1 896 0 > # module global constants > bind_segmentv.1 56 8 Struct F T > begin_initv.1 > # procedure names > init_chars0 "Main_M3" > init_chars8 "Normalize" > # procedure table > init_proc20 p.1 > init_var24 v.1 0 > init_proc28 p.7 > init_var32 v.1 8 > # file name > init_chars40 "../src/Main.m3" > end_initv.1 > # module global data > bind_segmentv.2 112 8 Struct F T > > begin_initv.2 > init_var0 v.1 40 > init_var20 v.1 20 > init_var36 v.2 52 > init_proc44 p.1 > init_int48 3 Int.32 > init_proc56 p.2 > init_var60 v.2 64 > init_proc68 p.3 > init_var72 v.2 76 > init_proc80 p.4 > init_var84 v.2 88 > init_proc92 p.5 > init_var96 v.2 100 > init_proc104 p.6 > end_initv.2 > # load map > # > # > # global data allocation for M_Main > # 0 52 4 *module info* > # 52 12 4 import Main > # 64 12 4 import Fmt > # 76 12 4 import IO > # 88 12 4 import Long > # 100 12 4 import RTHooks > # 112 0 4 *TOTAL* > # > # > # global constants for M_Main > # 0 18 4 *proc names* > # 20 20 4 *proc info* > # 40 15 1 *string* > # 56 0 4 *TOTAL* > # > end_unit > > > Its very similar except for using Word.64 instead of Int.64 and a couple of other cosmetic issues. > The trouble is near label L5 where it does a load_integer of 0 instead of the big constant. > The result of anding the zero and testing for zero is causing the loop. > Compiling this with -O also causes the backend to crash. > Both of these are on LINUXLIBC6. The AMD64 intermediate is correct. Seems like its not parsing the > big long for some reason or else its wrapping around. > > Any ideas? > > Regards Peter > > > > On Tue, May 24, 2016 at 4:40 AM, Rodney M. Bates >> wrote: > > > > > I did git pull and rebuilt on LINUXLIBC6. The built cm3 executable crashes compiling > a very small experiment program: > > rodney at yellowstone:~/proj/m3/exp/FmtBug/src$ cm3- > Segmentation fault (core dumped) > > m3gdb (after I built it) gives this: > > rodney at yellowstone:~/proj/m3/exp/FmtBug/src$ m3gdb cm3- > GNU gdb plus Modula-3 6.4 > Copyright 2005 Free Software Foundation, Inc. > GDB is free software, covered by the GNU General Public License, and you are > welcome to change it and/or distribute copies of it under certain conditions. > Type "show copying" to see the conditions. > There is absolutely no warranty for GDB. Type "show warranty" for details. > This GDB was configured as "i686-pc-linux-gnu"...Using host libthread_db library "/lib/tls/i686/cmov/libthread_db.so.1". > > (m3gdb) run > Starting program: /usr/local/cm3-githead/bin/cm3- > [Thread debugging using libthread_db enabled] > [New LWP 23615] > [New Thread -1216829744 (LWP 23615)] > > Program received signal SIGSEGV, Segmentation fault. > [Switching to Thread -1216829744 (LWP 23615)] > 0x0037c26f in siglongjmp () from /lib/tls/i686/cmov/libc.so.6 > (m3gdb) bt > #0 0x0037c26f in siglongjmp () from /lib/tls/i686/cmov/libc.so.6 > #1 0x577b2a84 in ?? () > Cannot access memory at address 0xd7a0906f > (m3gdb) quit > > > stock gdb gives even less information: > > rodney at yellowstone:~/proj/m3/exp/FmtBug/src$ gdb cm3- > GNU gdb (GDB) 7.1-ubuntu > Copyright (C) 2010 Free Software Foundation, Inc. > License GPLv3+: GNU GPL version 3 or later > This is free software: you are free to change and redistribute it. > There is NO WARRANTY, to the extent permitted by law. Type "show copying" > and "show warranty" for details. > This GDB was configured as "i486-linux-gnu". > For bug reporting instructions, please see: > ... > Reading symbols from /usr/local/cm3-githead/bin/cm3-...done. > (gdb) run > Starting program: /usr/local/cm3-githead/bin/cm3- > [Thread debugging using libthread_db enabled] > > Program received signal SIGSEGV, Segmentation fault. > 0x0032e26f in ?? () from /lib/tls/i686/cmov/libc.so.6 > (gdb) bt > #0 0x0032e26f in ?? () from /lib/tls/i686/cmov/libc.so.6 > #1 0xfb35d04b in ?? () > Cannot access memory at address 0x7bee2da0 > (gdb) > > Note that gdb gives a different address in the same library for the point of fault. > > m3gdb claims it's in siglongjmp. I recall there were some recent changes involving > longjump. > > > > > > > On 05/22/2016 09:28 PM, Peter McKinna wrote: > > I dont know what changed but the backend is crashing on linuxlibc6 when compiled with -O Try compiling m3core. > > > > Also some of my low level tests with Long.And and Long.Shift are not working with > > normal compile without the optimisations on that platform. Bit suspicious. I'm still investigating. > > > > Anyone got any clues or can replicate? > > > > Thanks 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 Thu May 26 23:23:18 2016 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Thu, 26 May 2016 16:23:18 -0500 Subject: [M3devel] cm3cg failing on linuxlibc6 In-Reply-To: <57472C72.8090904@lcwb.coop> References: <57434E93.2030205@lcwb.coop> <57467453.4040702@lcwb.coop> <57472C72.8090904@lcwb.coop> Message-ID: <57476946.20706@lcwb.coop> It's now verified to recompile itself twice, committed and pushed to github. On 05/26/2016 12:03 PM, Rodney M. Bates wrote: > I am getting this output from your example, with the output commented back in: > > sig init 3 > sig loop 1 3072 > sig loop 1 3145728 > sig loop 1 3221225472 > sig loop 1 3298534883328 > sig loop 1 3377699720527872 > sig loop 1 3458764513820540928 > sig after loop 1 3458764513820540928 > 0 > sig loop2 1 3458764513820540928 > sig loop2 2 6917529027641081856 > sig loop2 1 6917529027641081856 > sig loop2 2 -4611686018427387904 > > > Does it look right? The IR looks right: > > $ diff Main.mc.m3cgcat.bad Main.mc.m3cgcat > 34c34 > < load_integer Int.64 0 > --- > > load_integer Int.64 -9223372036854775808 > > > It still needs some regression testing and wrapping up. > > > > On 05/26/2016 12:08 AM, Peter McKinna wrote: >> Wow, nice work. Is there a problem in the backend as well? Or other problems in the front end? > > I suspect the back end problem is something else. That's next. > >> That dodgy intermediate looked like perfectly good code apart from the loop >> so I cant understand why the back end would crash with optimizations on. >> >> Also what is the deal with jump bufs ? > > This is unrelated. It just prevented getting a running cm3 on LINUXLIBC6. I now > have gotten around thislocally, but it needs more work to not break other platforms. > >> >> Regards Peter >> >> >> On Thu, May 26, 2016 at 1:58 PM, Rodney M. Bates > wrote: >> >> Just an FYI on the And bug. >> >> I think I have diagnosed this for this particular case. TInt.ToBytes is following >> the invariants of a TInt.T, which always uses twos-complement notation, but, with >> a 9th byte, is big enough to hold the entire overlap of the 64-bit signed and unsigned >> ranges. OTOH, M3CG_BinWr.AddBigX is converting to signed-magnitude, with a separate >> sign. It passes an absolute value to ToBytes. For only this single value >> 16_8000000000000000, this is representable as a positive absolute value in 8 bytes, >> but ToBytes correctly considers this too few bytes for twos-complement and returns >> zero. >> >> It will take more work to look at all the calls on ToBytes and ascertain which >> cases suffer this mismatch. Also, I am currently unable to build a working >> compiler for LINUXLIBC6, something to do with jumbufs. So I will have to get around >> that before testing a fix and for regressions. >> >> It looks like it doesn't happen when compiling on a 64-bit machine because that >> takes a different path, using native INTEGER rather than TInt for the constant >> value. >> >> >> On 05/24/2016 02:24 AM, Peter McKinna wrote: >> >> I may have been a tad hasty in blaming the back end for the crashes, the front end has some explaining to do as well. >> >> I was getting an infinite loop in a program which I have cut down here to demonstrate. The original cm3 5.2 I think it >> was from elegosoft worked fine. The latest produces different intermediate code. >> >> First the source, (excuse the size, its extracted from my implementation of grisu which I was on the point of pushing to github) >> >> MODULE Main; >> >> IMPORT Long,IO,Fmt; >> >> CONST >> kUint64MSB = 16_8000000000000000L; >> >> TYPE >> Uint64 = Long.T; >> PROCEDURE Normalize(sig : Long.T; exp : INTEGER) = >> CONST >> k10MSBits = 16_FFC0000000000000L; >> VAR >> significand : Uint64; >> exponent : INTEGER; >> >> BEGIN >> <*ASSERT sig # 0L *> >> significand := sig; >> exponent := exp; >> (*IO.Put("sig init " & Fmt.LongInt(significand) & "\n");*) >> >> (* This method is mainly called for normalizing boundaries. In general >> boundaries need to be shifted by 10 bits. We thus optimize for this case. *) >> WHILE Long.And(significand, k10MSBits) = 0L DO >> significand := Long.LeftShift(significand, 10); >> (*IO.Put("sig loop 1 " & Fmt.LongInt(significand) & "\n");*) >> DEC(exponent, 10); >> END; >> (*IO.Put("sig after loop 1 " & Fmt.LongInt(significand) & "\n");*) >> (* >> IO.PutLongInt(Long.And(significand, kUint64MSB)); >> IO.Put("\n"); >> *) >> WHILE Long.And(significand, kUint64MSB) = 0L DO >> (*IO.Put("sig loop2 1 " & Fmt.LongInt(significand) & "\n");*) >> significand := Long.LeftShift(significand, 1); >> (*IO.Put("sig loop2 2 " & Fmt.LongInt(significand) & "\n");*) >> DEC(exponent); >> END; >> END Normalize; >> BEGIN >> >> Normalize(3L,2); >> END Main. >> >> Now the correct intermediate from the original cm3 >> Its a shame we cant embed the cm3 version into the intermediate. But theres no mention of widechar so you can tell its an old >> version. >> >> begin_unit0 >> -----FILE ../src/Main.m3 ----- >> -----LINE 1 ----- >> # module global constants >> declare_segment* -1 T v.1 >> # module global data >> declare_segmentM_Main -1 F v.2 >> -----LINE 45 ----- >> declare_procedureMain_M3 1 Addr 0 0 T * p.1 >> declare_parammode 4 4 Int.32 425470580 F F 100 v.3 >> declare_proctype1318003907 2 0 0 0 >> declare_formalsig 89530742 >> declare_formalexp 425470580 >> import_procedureMain_I3 0 Addr 0 p.2 >> export_unitMain >> import_procedureFmt_I3 0 Addr 0 p.3 >> import_unitFmt >> import_procedureIO_I3 0 Addr 0 p.4 >> import_unitIO >> import_procedureLong_I3 0 Addr 0 p.5 >> import_unitLong >> import_procedureRTHooks_I3 0 Addr 0 p.6 >> import_unitRTHooks >> declare_typename89530742 Uint64 >> declare_procedureMain__Normalize 2 Void 0 0 F * p.7 >> declare_localsignificand 8 4 Int.64 89530742 F F 50 v.4 >> declare_localexponent 4 4 Int.32 425470580 F F 50 v.5 >> declare_paramsig 8 4 Int.64 89530742 F F 50 v.6 >> declare_paramexp 4 4 Int.32 425470580 F F 50 v.7 >> # Normalize >> -----LINE 11 ----- >> begin_procedurep.7 >> -----LINE 12 ----- >> -----LINE 19 ----- >> loadv.6 0 Int.64 Int.64 >> load_integerInt.64 0 >> if_neInt.64 L.1 100 >> import_procedureRTHooks__ReportFault 2 Void 0 p.8 >> declare_parammodule 4 4 Addr 138420323 F F 50 v.8 >> declare_paraminfo 4 4 Int.32 425470580 F F 50 v.9 >> set_runtime_procReportFault p.8 >> abort0 >> . L.1 F >> -----LINE 20 ----- >> loadv.6 0 Int.64 Int.64 >> storev.4 0 Int.64 Int.64 >> -----LINE 21 ----- >> loadv.7 0 Int.32 Int.32 >> storev.5 0 Int.32 Int.32 >> -----LINE 26 ----- >> jumpL.2 >> . L.3 F >> -----LINE 27 ----- >> loadv.4 0 Int.64 Int.64 >> load_integerInt.32 10 >> shift_leftInt.64 >> storev.4 0 Int.64 Int.64 >> -----LINE 29 ----- >> loadv.5 0 Int.32 Int.32 >> load_integerInt.32 10 >> subtractInt.32 >> storev.5 0 Int.32 Int.32 >> -----LINE 26 ----- >> . L.2 F >> loadv.4 0 Int.64 Int.64 >> load_integerInt.64 -18014398509481984 >> andInt.64 >> load_integerInt.64 0 >> if_eqInt.64 L.3 80 >> . L.4 F >> -----LINE 36 ----- >> jumpL.5 >> . L.6 F >> -----LINE 38 ----- >> loadv.4 0 Int.64 Int.64 >> load_integerInt.32 1 >> shift_leftInt.64 >> storev.4 0 Int.64 Int.64 >> -----LINE 40 ----- >> loadv.5 0 Int.32 Int.32 >> load_integerInt.32 1 >> subtractInt.32 >> storev.5 0 Int.32 Int.32 >> -----LINE 36 ----- >> . L.5 F >> loadv.4 0 Int.64 Int.64 >> load_integerInt.64 -9223372036854775808 >> andInt.64 >> load_integerInt.64 0 >> if_eqInt.64 L.6 80 >> . L.7 F >> -----LINE 43 ----- >> exit_procVoid >> end_procedurep.7 >> # Main_M3 >> # module main body Main_M3 >> -----LINE 45 ----- >> begin_procedurep.1 >> loadv.3 0 Int.32 Int.32 >> if_falseInt.32 L.8 0 >> -----LINE 47 ----- >> start_call_directp.7 0 Void >> load_integerInt.64 3 >> pop_paramInt.64 >> load_integerInt.32 2 >> pop_paramInt.32 >> call_directp.7 Void >> . L.8 F >> load_addressv.2 0 >> exit_procAddr >> end_procedurep.1 >> # global constant type descriptor >> declare_record-1 448 0 >> # global data type descriptor >> declare_record-1 896 0 >> # module global constants >> bind_segmentv.1 56 4 Struct F T >> begin_initv.1 >> # procedure names >> init_chars0 "Main_M3" >> init_chars8 "Normalize" >> # procedure table >> init_proc20 p.1 >> init_var24 v.1 0 >> init_proc28 p.7 >> init_var32 v.1 8 >> # file name >> init_chars40 "../src/Main.m3" >> end_initv.1 >> # module global data >> bind_segmentv.2 112 4 Struct F T >> >> begin_initv.2 >> init_var0 v.1 40 >> init_var20 v.1 20 >> init_var36 v.2 52 >> init_proc44 p.1 >> init_int48 3 Int.32 >> init_proc56 p.2 >> init_var60 v.2 64 >> init_proc68 p.3 >> init_var72 v.2 76 >> init_proc80 p.4 >> init_var84 v.2 88 >> init_proc92 p.5 >> init_var96 v.2 100 >> init_proc104 p.6 >> end_initv.2 >> # load map >> # >> # >> # global data allocation for M_Main >> # 0 52 4 *module info* >> # 52 12 4 import Main >> # 64 12 4 import Fmt >> # 76 12 4 import IO >> # 88 12 4 import Long >> # 100 12 4 import RTHooks >> # 112 0 4 *TOTAL* >> # >> # >> # global constants for M_Main >> # 0 18 4 *proc names* >> # 20 20 4 *proc info* >> # 40 15 1 *string* >> # 56 0 4 *TOTAL* >> # >> end_unit >> >> >> Now the intermediate from the latest compiler >> >> begin_unit0 >> widechar_size16 >> -----FILE ../src/Main.m3 ----- >> -----LINE 1 ----- >> # module global constants >> declare_segment* -1 T v.1 >> # module global data >> declare_segmentM_Main -1 F v.2 >> -----LINE 45 ----- >> declare_procedureMain_M3 1 Addr 0 0 T * p.1 >> declare_parammode 4 4 Int.32 425470580 F F 100 v.3 >> declare_proctype1318003907 2 0 0 0 >> declare_formalsig 89530742 >> declare_formalexp 425470580 >> import_procedureMain_I3 0 Addr 0 p.2 >> export_unitMain >> import_procedureFmt_I3 0 Addr 0 p.3 >> import_unitFmt >> import_procedureIO_I3 0 Addr 0 p.4 >> import_unitIO >> import_procedureLong_I3 0 Addr 0 p.5 >> import_unitLong >> import_procedureRTHooks_I3 0 Addr 0 p.6 >> import_unitRTHooks >> declare_typename89530742 Uint64 >> declare_procedureMain__Normalize 2 Void 0 0 F * p.7 >> declare_localsignificand 8 8 Int.64 89530742 F F 50 v.4 >> declare_localexponent 4 4 Int.32 425470580 F F 50 v.5 >> declare_paramsig 8 8 Int.64 89530742 F F 50 v.6 >> declare_paramexp 4 4 Int.32 425470580 F F 50 v.7 >> # Normalize >> -----LINE 11 ----- >> begin_procedurep.7 >> -----LINE 12 ----- >> -----LINE 19 ----- >> load_integerInt.64 0 >> loadv.6 0 Int.64 Int.64 >> if_neInt.64 L.1 100 >> declare_proctype-1531209598 2 0 -1 0 >> declare_formalmodule 138420323 >> declare_formalinfo 425470580 >> import_procedureRTHooks__ReportFault 2 Void 0 p.8 >> declare_parammodule 4 4 Addr 138420323 F F 50 v.8 >> declare_paraminfo 4 4 Int.32 425470580 F F 50 v.9 >> set_runtime_procReportFault p.8 >> abort0 >> . L.1 F >> -----LINE 20 ----- >> loadv.6 0 Int.64 Int.64 >> storev.4 0 Int.64 Int.64 >> -----LINE 21 ----- >> loadv.7 0 Int.32 Int.32 >> storev.5 0 Int.32 Int.32 >> -----LINE 26 ----- >> jumpL.2 >> . L.3 F >> -----LINE 27 ----- >> loadv.4 0 Int.64 Int.64 >> load_integerInt.32 10 >> shift_leftWord.64 >> storev.4 0 Int.64 Int.64 >> -----LINE 29 ----- >> loadv.5 0 Int.32 Int.32 >> load_integerInt.32 10 >> subtractInt.32 >> storev.5 0 Int.32 Int.32 >> -----LINE 26 ----- >> . L.2 F >> load_integerInt.64 -18014398509481984 >> loadv.4 0 Int.64 Int.64 >> andWord.64 >> load_integerInt.64 0 >> if_eqInt.64 L.3 80 >> . L.4 F >> -----LINE 36 ----- >> jumpL.5 >> . L.6 F >> -----LINE 38 ----- >> loadv.4 0 Int.64 Int.64 >> load_integerInt.32 1 >> shift_leftWord.64 >> storev.4 0 Int.64 Int.64 >> -----LINE 40 ----- >> loadv.5 0 Int.32 Int.32 >> load_integerInt.32 1 >> subtractInt.32 >> storev.5 0 Int.32 Int.32 >> -----LINE 36 ----- >> . L.5 F >> load_integerInt.64 0 >> loadv.4 0 Int.64 Int.64 >> andWord.64 >> load_integerInt.64 0 >> if_eqInt.64 L.6 80 >> . L.7 F >> -----LINE 43 ----- >> exit_procVoid >> end_procedurep.7 >> # Main_M3 >> # module main body Main_M3 >> -----LINE 45 ----- >> begin_procedurep.1 >> loadv.3 0 Int.32 Int.32 >> if_falseInt.32 L.8 0 >> -----LINE 47 ----- >> start_call_directp.7 0 Void >> load_integerInt.64 3 >> pop_paramInt.64 >> load_integerInt.32 2 >> pop_paramInt.32 >> call_directp.7 Void >> . L.8 F >> load_addressv.2 0 >> exit_procAddr >> end_procedurep.1 >> # global constant type descriptor >> declare_record-1 448 0 >> # global data type descriptor >> declare_record-1 896 0 >> # module global constants >> bind_segmentv.1 56 8 Struct F T >> begin_initv.1 >> # procedure names >> init_chars0 "Main_M3" >> init_chars8 "Normalize" >> # procedure table >> init_proc20 p.1 >> init_var24 v.1 0 >> init_proc28 p.7 >> init_var32 v.1 8 >> # file name >> init_chars40 "../src/Main.m3" >> end_initv.1 >> # module global data >> bind_segmentv.2 112 8 Struct F T >> >> begin_initv.2 >> init_var0 v.1 40 >> init_var20 v.1 20 >> init_var36 v.2 52 >> init_proc44 p.1 >> init_int48 3 Int.32 >> init_proc56 p.2 >> init_var60 v.2 64 >> init_proc68 p.3 >> init_var72 v.2 76 >> init_proc80 p.4 >> init_var84 v.2 88 >> init_proc92 p.5 >> init_var96 v.2 100 >> init_proc104 p.6 >> end_initv.2 >> # load map >> # >> # >> # global data allocation for M_Main >> # 0 52 4 *module info* >> # 52 12 4 import Main >> # 64 12 4 import Fmt >> # 76 12 4 import IO >> # 88 12 4 import Long >> # 100 12 4 import RTHooks >> # 112 0 4 *TOTAL* >> # >> # >> # global constants for M_Main >> # 0 18 4 *proc names* >> # 20 20 4 *proc info* >> # 40 15 1 *string* >> # 56 0 4 *TOTAL* >> # >> end_unit >> >> >> Its very similar except for using Word.64 instead of Int.64 and a couple of other cosmetic issues. >> The trouble is near label L5 where it does a load_integer of 0 instead of the big constant. >> The result of anding the zero and testing for zero is causing the loop. >> Compiling this with -O also causes the backend to crash. >> Both of these are on LINUXLIBC6. The AMD64 intermediate is correct. Seems like its not parsing the >> big long for some reason or else its wrapping around. >> >> Any ideas? >> >> Regards Peter >> >> >> >> On Tue, May 24, 2016 at 4:40 AM, Rodney M. Bates >> wrote: >> >> >> >> >> I did git pull and rebuilt on LINUXLIBC6. The built cm3 executable crashes compiling >> a very small experiment program: >> >> rodney at yellowstone:~/proj/m3/exp/FmtBug/src$ cm3- >> Segmentation fault (core dumped) >> >> m3gdb (after I built it) gives this: >> >> rodney at yellowstone:~/proj/m3/exp/FmtBug/src$ m3gdb cm3- >> GNU gdb plus Modula-3 6.4 >> Copyright 2005 Free Software Foundation, Inc. >> GDB is free software, covered by the GNU General Public License, and you are >> welcome to change it and/or distribute copies of it under certain conditions. >> Type "show copying" to see the conditions. >> There is absolutely no warranty for GDB. Type "show warranty" for details. >> This GDB was configured as "i686-pc-linux-gnu"...Using host libthread_db library "/lib/tls/i686/cmov/libthread_db.so.1". >> >> (m3gdb) run >> Starting program: /usr/local/cm3-githead/bin/cm3- >> [Thread debugging using libthread_db enabled] >> [New LWP 23615] >> [New Thread -1216829744 (LWP 23615)] >> >> Program received signal SIGSEGV, Segmentation fault. >> [Switching to Thread -1216829744 (LWP 23615)] >> 0x0037c26f in siglongjmp () from /lib/tls/i686/cmov/libc.so.6 >> (m3gdb) bt >> #0 0x0037c26f in siglongjmp () from /lib/tls/i686/cmov/libc.so.6 >> #1 0x577b2a84 in ?? () >> Cannot access memory at address 0xd7a0906f >> (m3gdb) quit >> >> >> stock gdb gives even less information: >> >> rodney at yellowstone:~/proj/m3/exp/FmtBug/src$ gdb cm3- >> GNU gdb (GDB) 7.1-ubuntu >> Copyright (C) 2010 Free Software Foundation, Inc. >> License GPLv3+: GNU GPL version 3 or later >> This is free software: you are free to change and redistribute it. >> There is NO WARRANTY, to the extent permitted by law. Type "show copying" >> and "show warranty" for details. >> This GDB was configured as "i486-linux-gnu". >> For bug reporting instructions, please see: >> ... >> Reading symbols from /usr/local/cm3-githead/bin/cm3-...done. >> (gdb) run >> Starting program: /usr/local/cm3-githead/bin/cm3- >> [Thread debugging using libthread_db enabled] >> >> Program received signal SIGSEGV, Segmentation fault. >> 0x0032e26f in ?? () from /lib/tls/i686/cmov/libc.so.6 >> (gdb) bt >> #0 0x0032e26f in ?? () from /lib/tls/i686/cmov/libc.so.6 >> #1 0xfb35d04b in ?? () >> Cannot access memory at address 0x7bee2da0 >> (gdb) >> >> Note that gdb gives a different address in the same library for the point of fault. >> >> m3gdb claims it's in siglongjmp. I recall there were some recent changes involving >> longjump. >> >> >> >> >> >> >> On 05/22/2016 09:28 PM, Peter McKinna wrote: >> > I dont know what changed but the backend is crashing on linuxlibc6 when compiled with -O Try compiling m3core. >> > >> > Also some of my low level tests with Long.And and Long.Shift are not working with >> > normal compile without the optimisations on that platform. Bit suspicious. I'm still investigating. >> > >> > Anyone got any clues or can replicate? >> > >> > Thanks 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 Fri May 27 20:38:07 2016 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Fri, 27 May 2016 13:38:07 -0500 Subject: [M3devel] cm3cg failing on linuxlibc6 In-Reply-To: References: Message-ID: <5748940F.5020808@lcwb.coop> On 05/22/2016 09:28 PM, Peter McKinna wrote: > I dont know what changed but the backend is crashing on linuxlibc6 when compiled with -O Try compiling m3core. > I get crashes compiling with -O -O1 -O2 -O3, with different symptoms. -O and -O2 just segfault. -O2 and -O3 get: ... /usr/local/cm3//bin/cm3cg -march=i686 -quiet -fno-reorder-blocks -funwind-tables -fPIC -m32 -O3 -gstabs+ Main.mc -o Main.ms *** glibc detected *** /usr/local/cm3//bin/cm3cg: double free or corruption (fasttop): 0x0a20b0d8 *** ======= Backtrace: ========= /lib/tls/i686/cmov/libc.so.6(+0x6e0a1)[0xac00a1] /lib/tls/i686/cmov/libc.so.6(+0x6f8f8)[0xac18f8] /lib/tls/i686/cmov/libc.so.6(cfree+0x6d)[0xac4a6d] /usr/local/cm3//bin/cm3cg[0x81c7df8] ======= Memory map: ======== 00180000-002ef000 r-xp 00000000 08:05 5507589 /usr/lib/libstdc++.so.6.0.21 002ef000-002f5000 r--p 0016e000 08:05 5507589 /usr/lib/libstdc++.so.6.0.21 002f5000-002f6000 rw-p 00174000 08:05 5507589 /usr/lib/libstdc++.so.6.0.21 002f6000-002f9000 rw-p 00000000 00:00 0 00360000-0037c000 r-xp 00000000 08:05 4337255 /lib/libgcc_s.so.1 0037c000-0037d000 r--p 0001b000 08:05 4337255 /lib/libgcc_s.so.1 0037d000-0037e000 rw-p 0001c000 08:05 4337255 /lib/libgcc_s.so.1 0087a000-00895000 r-xp 00000000 08:05 4336906 /lib/ld-2.11.1.so 00895000-00896000 r--p 0001a000 08:05 4336906 /lib/ld-2.11.1.so 00896000-00897000 rw-p 0001b000 08:05 4336906 /lib/ld-2.11.1.so 00a52000-00bae000 r-xp 00000000 08:05 4467785 /lib/tls/i686/cmov/libc-2.11.1.so 00bae000-00bb0000 r--p 0015b000 08:05 4467785 /lib/tls/i686/cmov/libc-2.11.1.so 00bb0000-00bb1000 rw-p 0015d000 08:05 4467785 /lib/tls/i686/cmov/libc-2.11.1.so 00bb1000-00bb4000 rw-p 00000000 00:00 0 00deb000-00e0f000 r-xp 00000000 08:05 4467782 /lib/tls/i686/cmov/libm-2.11.1.so 00e0f000-00e10000 r--p 00023000 08:05 4467782 /lib/tls/i686/cmov/libm-2.11.1.so 00e10000-00e11000 rw-p 00024000 08:05 4467782 /lib/tls/i686/cmov/libm-2.11.1.so 00f24000-00f25000 r-xp 00000000 00:00 0 [vdso] 08048000-088cd000 r-xp 00000000 08:05 5778669 /usr/local/cm3-githead/bin/cm3cg 088cd000-088ce000 r--p 00885000 08:05 5778669 /usr/local/cm3-githead/bin/cm3cg 088ce000-088d4000 rw-p 00886000 08:05 5778669 /usr/local/cm3-githead/bin/cm3cg 088d4000-089fe000 rw-p 00000000 00:00 0 0a149000-0a216000 rw-p 00000000 00:00 0 [heap] b7300000-b7321000 rw-p 00000000 00:00 0 b7321000-b7400000 ---p 00000000 00:00 0 b74d4000-b771a000 rw-p 00000000 00:00 0 b772b000-b7733000 rw-p 00000000 00:00 0 bff93000-bffa8000 rw-p 00000000 00:00 0 [stack] ../src/Main.m3: In function 'Main__Normalize': ../src/Main.m3:41:0: internal compiler error: Aborted Please submit a full bug report, with preprocessed source if appropriate. See for instructions. Were you compiling things earlier with -O successfully? I vaguely recall something to the effect that cm3cg never has worked with optimization. Anybody remember about this? > Also some of my low level tests with Long.And and Long.Shift are not working with > normal compile without the optimisations on that platform. Bit suspicious. I'm still investigating. > > Anyone got any clues or can replicate? > > Thanks 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 Fri May 27 20:45:31 2016 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Fri, 27 May 2016 13:45:31 -0500 Subject: [M3devel] cm3cg failing on linuxlibc6 In-Reply-To: <57434E93.2030205@lcwb.coop> References: <57434E93.2030205@lcwb.coop> Message-ID: <574895CB.10200@lcwb.coop> I got around this problem by setting Alloca_jmpbuf back to TRUE in m3-libs/m3core/src/runtime/ex_frame/RTExFrame.m3 and m3-sys/m3middle/src/Target.m3 I am trying to remember, but as I recall, TRUE was failing on some other platform, and the change was reverted. But now FALSE is failing on LINUXLIBC6 and TRUE is working there. What do you remember about this, Jay? On 05/23/2016 01:40 PM, Rodney M. Bates wrote: > > > > I did git pull and rebuilt on LINUXLIBC6. The built cm3 executable crashes compiling > a very small experiment program: > > rodney at yellowstone:~/proj/m3/exp/FmtBug/src$ cm3- > Segmentation fault (core dumped) > > m3gdb (after I built it) gives this: > > rodney at yellowstone:~/proj/m3/exp/FmtBug/src$ m3gdb cm3- > GNU gdb plus Modula-3 6.4 > Copyright 2005 Free Software Foundation, Inc. > GDB is free software, covered by the GNU General Public License, and you are > welcome to change it and/or distribute copies of it under certain conditions. > Type "show copying" to see the conditions. > There is absolutely no warranty for GDB. Type "show warranty" for details. > This GDB was configured as "i686-pc-linux-gnu"...Using host libthread_db library "/lib/tls/i686/cmov/libthread_db.so.1". > > (m3gdb) run > Starting program: /usr/local/cm3-githead/bin/cm3- > [Thread debugging using libthread_db enabled] > [New LWP 23615] > [New Thread -1216829744 (LWP 23615)] > > Program received signal SIGSEGV, Segmentation fault. > [Switching to Thread -1216829744 (LWP 23615)] > 0x0037c26f in siglongjmp () from /lib/tls/i686/cmov/libc.so.6 > (m3gdb) bt > #0 0x0037c26f in siglongjmp () from /lib/tls/i686/cmov/libc.so.6 > #1 0x577b2a84 in ?? () > Cannot access memory at address 0xd7a0906f > (m3gdb) quit > > > stock gdb gives even less information: > > rodney at yellowstone:~/proj/m3/exp/FmtBug/src$ gdb cm3- > GNU gdb (GDB) 7.1-ubuntu > Copyright (C) 2010 Free Software Foundation, Inc. > License GPLv3+: GNU GPL version 3 or later > This is free software: you are free to change and redistribute it. > There is NO WARRANTY, to the extent permitted by law. Type "show copying" > and "show warranty" for details. > This GDB was configured as "i486-linux-gnu". > For bug reporting instructions, please see: > ... > Reading symbols from /usr/local/cm3-githead/bin/cm3-...done. > (gdb) run > Starting program: /usr/local/cm3-githead/bin/cm3- > [Thread debugging using libthread_db enabled] > > Program received signal SIGSEGV, Segmentation fault. > 0x0032e26f in ?? () from /lib/tls/i686/cmov/libc.so.6 > (gdb) bt > #0 0x0032e26f in ?? () from /lib/tls/i686/cmov/libc.so.6 > #1 0xfb35d04b in ?? () > Cannot access memory at address 0x7bee2da0 > (gdb) > > Note that gdb gives a different address in the same library for the point of fault. > > m3gdb claims it's in siglongjmp. I recall there were some recent changes involving > longjump. > > > > > > On 05/22/2016 09:28 PM, Peter McKinna wrote: > > I dont know what changed but the backend is crashing on linuxlibc6 when compiled with -O Try compiling m3core. > > > > Also some of my low level tests with Long.And and Long.Shift are not working with > > normal compile without the optimisations on that platform. Bit suspicious. I'm still investigating. > > > > Anyone got any clues or can replicate? > > > > Thanks 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 lists at darko.org Sat May 28 01:50:20 2016 From: lists at darko.org (Darko Volaric) Date: Sat, 28 May 2016 01:50:20 +0200 Subject: [M3devel] cm3cg failing on linuxlibc6 In-Reply-To: <574895CB.10200@lcwb.coop> References: <57434E93.2030205@lcwb.coop> <574895CB.10200@lcwb.coop> Message-ID: This, perhaps: https://github.com/modula3/cm3/issues/10 On Fri, May 27, 2016 at 8:45 PM, Rodney M. Bates wrote: > I got around this problem by setting Alloca_jmpbuf back to TRUE in > > m3-libs/m3core/src/runtime/ex_frame/RTExFrame.m3 and > m3-sys/m3middle/src/Target.m3 > > I am trying to remember, but as I recall, TRUE was failing on some other > platform, > and the change was reverted. But now FALSE is failing on LINUXLIBC6 and > TRUE > is working there. > > What do you remember about this, Jay? > > > > On 05/23/2016 01:40 PM, Rodney M. Bates wrote: > >> >> >> >> I did git pull and rebuilt on LINUXLIBC6. The built cm3 executable >> crashes compiling >> a very small experiment program: >> >> rodney at yellowstone:~/proj/m3/exp/FmtBug/src$ cm3- >> Segmentation fault (core dumped) >> >> m3gdb (after I built it) gives this: >> >> rodney at yellowstone:~/proj/m3/exp/FmtBug/src$ m3gdb cm3- >> GNU gdb plus Modula-3 6.4 >> Copyright 2005 Free Software Foundation, Inc. >> GDB is free software, covered by the GNU General Public License, and >> you are >> welcome to change it and/or distribute copies of it under certain >> conditions. >> Type "show copying" to see the conditions. >> There is absolutely no warranty for GDB. Type "show warranty" for >> details. >> This GDB was configured as "i686-pc-linux-gnu"...Using host >> libthread_db library "/lib/tls/i686/cmov/libthread_db.so.1". >> >> (m3gdb) run >> Starting program: /usr/local/cm3-githead/bin/cm3- >> [Thread debugging using libthread_db enabled] >> [New LWP 23615] >> [New Thread -1216829744 (LWP 23615)] >> >> Program received signal SIGSEGV, Segmentation fault. >> [Switching to Thread -1216829744 (LWP 23615)] >> 0x0037c26f in siglongjmp () from /lib/tls/i686/cmov/libc.so.6 >> (m3gdb) bt >> #0 0x0037c26f in siglongjmp () from /lib/tls/i686/cmov/libc.so.6 >> #1 0x577b2a84 in ?? () >> Cannot access memory at address 0xd7a0906f >> (m3gdb) quit >> >> >> stock gdb gives even less information: >> >> rodney at yellowstone:~/proj/m3/exp/FmtBug/src$ gdb cm3- >> GNU gdb (GDB) 7.1-ubuntu >> Copyright (C) 2010 Free Software Foundation, Inc. >> License GPLv3+: GNU GPL version 3 or later < >> http://gnu.org/licenses/gpl.html> >> This is free software: you are free to change and redistribute it. >> There is NO WARRANTY, to the extent permitted by law. Type "show >> copying" >> and "show warranty" for details. >> This GDB was configured as "i486-linux-gnu". >> For bug reporting instructions, please see: >> ... >> Reading symbols from /usr/local/cm3-githead/bin/cm3-...done. >> (gdb) run >> Starting program: /usr/local/cm3-githead/bin/cm3- >> [Thread debugging using libthread_db enabled] >> >> Program received signal SIGSEGV, Segmentation fault. >> 0x0032e26f in ?? () from /lib/tls/i686/cmov/libc.so.6 >> (gdb) bt >> #0 0x0032e26f in ?? () from /lib/tls/i686/cmov/libc.so.6 >> #1 0xfb35d04b in ?? () >> Cannot access memory at address 0x7bee2da0 >> (gdb) >> >> Note that gdb gives a different address in the same library for the point >> of fault. >> >> m3gdb claims it's in siglongjmp. I recall there were some recent changes >> involving >> longjump. >> >> >> >> >> >> On 05/22/2016 09:28 PM, Peter McKinna wrote: >> > I dont know what changed but the backend is crashing on linuxlibc6 >> when compiled with -O Try compiling m3core. >> > >> > Also some of my low level tests with Long.And and Long.Shift are not >> working with >> > normal compile without the optimisations on that platform. Bit >> suspicious. I'm still investigating. >> > >> > Anyone got any clues or can replicate? >> > >> > Thanks 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Tue May 31 08:52:05 2016 From: jay.krell at cornell.edu (Jay K) Date: Tue, 31 May 2016 06:52:05 +0000 Subject: [M3devel] old problem of new releases on old systems esp. Unix Message-ID: fyi..in the vein of really needing to release as C or asm instead of binaries, like the 3.6 system did: https://github.com/modula3/cm3/releases/download/verification-release-x86_64/cm3-bin-core-AMD64_LINUX-d5.9.0-x86_64-unknown-linux-gnu-2014-08-19-18-12-25.tgz % cm3 -versioncm3: /lib/libc.so.6: version `GLIBC_2.14' not found (required by cm3) on an older system: % uname -aLinux birch 2.6.26-2-amd64 #1 SMP Sun Mar 4 21:48:06 UTC 2012 x86_64 GNU/Linux or maybe do more investigation of gcc/ld switches to produce more compatible binaries.. ..just need to converge on what such a system really looks like in terms of build portability -- like cmake or autotools or extremely simple.. I have a bit of mental block getting anywhere on this. None of the C/C++ build systems quite do what I'd like and I haven't yet written my own.. (i.e. esp in terms of picking what is statically linked vs. what is dynamically linked).. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Tue May 31 09:32:23 2016 From: jay.krell at cornell.edu (Jay K) Date: Tue, 31 May 2016 07:32:23 +0000 Subject: [M3devel] replace build system?? Message-ID: Design of a new or bootstrap/cross/distribution build system? I'd really like our stuff to be as easy to distribute and develop as stuff using e.g. autotools or cmake. And as portable. And to reuse other people's work. And have a solid cross build story. And distribution be C or .o or .a or .S files, not executables and so/dylibs. i.e. I'd really like to get out of the build system business. like to just use autotools or cmake? But I suspect our system's qualities is difficult to replicate within the other frameworks. i.e. the incrementality The way every dynamic library is also available statically. Thoughts? For example, enable easier mixing of Modula-3 with C and C++ i.e. within one Makefile or such. Is it possible for Modula-3 to efficiently have the single source to single .o per invocation model? ?- Jay From hendrik at topoi.pooq.com Tue May 31 18:05:03 2016 From: hendrik at topoi.pooq.com (Hendrik Boom) Date: Tue, 31 May 2016 12:05:03 -0400 Subject: [M3devel] replace build system?? In-Reply-To: References: Message-ID: <20160531160502.GC12646@topoi.pooq.com> On Tue, May 31, 2016 at 07:32:23AM +0000, Jay K wrote: > Design of a new or bootstrap/cross/distribution build system? > > > I'd really like our stuff to be as easy to distribute and develop > as stuff using e.g. autotools or cmake. And as portable. > > > And to reuse other people's work. > > > And have a solid cross build story. > > > And distribution be C or .o or .a or .S files, not executables and so/dylibs. Isn't there an m3 compiler that generates C? Didn't you even write it? -- hendrik k From estellnb at elstel.org Tue May 31 18:35:06 2016 From: estellnb at elstel.org (Elmar Stellnberger) Date: Tue, 31 May 2016 18:35:06 +0200 Subject: [M3devel] replace build system?? In-Reply-To: References: Message-ID: Am 2016-05-31 um 09:32 schrieb Jay K: > i.e. I'd really like to get out of the build system business. > like to just use autotools or cmake? A make-based build solution would have other advantages as well like f.i. parallel build by make --jobs=4. That way CM3 could build up to four times faster. > But I suspect our system's qualities is difficult to replicate within the other frameworks. > i.e. the incrementality > The way every dynamic library is also available statically. > Why not employ a simple hand written make-file that determines that by environment variables? i.e. what libraries to build statically. From dmuysers at hotmail.com Tue May 31 18:39:16 2016 From: dmuysers at hotmail.com (dirk muysers) Date: Tue, 31 May 2016 18:39:16 +0200 Subject: [M3devel] The mailing list archive Message-ID: is still not available! -------------- next part -------------- An HTML attachment was scrubbed... URL: From dabenavidesd at yahoo.es Tue May 31 19:06:13 2016 From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.) Date: Tue, 31 May 2016 17:06:13 +0000 (UTC) Subject: [M3devel] replace build system?? In-Reply-To: References: Message-ID: <1784674298.4028093.1464714373116.JavaMail.yahoo@mail.yahoo.com> Hi Jay and all:I am searching options to make it easier (maybe tricking our selves) for new Modula-3 users explore our system.As I said recently, there is a java front end (just misses IRC type checking m3clipse) and there was FOSS "Scale compiler" backend written in Java, M3 DEC-SRC front end compatible (it generated Sparc, Alpha and Powerpc object code). An excerpt from The Common Language Encoding Form(Clef) Design Document: "For Modula-3, Scale uses the Digital Equipment Corporation(DEC) Systems Research Center (SRC) Modula-3 front end to generate an AST representation. M32CLEFreads the Modula-3 AST and uses the generation interface to convert it to Scale's high-level representation." [1] But anyway in my research found DEC was working just before sold to Compaq in an enriched type system, so I would prefer to let current compiler to do the job just in case we anyhow got their experimental type checker: "Modern programming languages, such as C++, Java, and Ada, include compile-time checks to detect a wide range of possible errors. The checks are based on declaring or inferring a type for each object (i.e., variables and procedures) and analyzing the program to establish that objects are used in ways consistent with their types. This kind of automated support is especially helpful for detecting the kinds of errors (such as passing arguments that overflow a corresponding parameter) so successfully used by attackers of operating system and network software. Ever more expressive type systems are a continuing theme in programming language research, with considerable attention being directed recently at the representation of security properties using types (Digital Equipment Corporation, 1997). Success would mean that compile-time checks could play an even bigger role in supporting trustworthiness properties. " [2] Thanks in advance for any comment [1]?Abstract?. [on line]. Available on en: ftp://ftp.cs.umass.edu/pub/osl/papers/clef97-abs.html. [Accessed: 31-may-2016]. [2]?Trust in Cyberspace?. [on line]. Available on: http://cryptome.org/tic.htm. [Accessed: 31-may-2016]. El Martes 31 de Mayo de 2016 11:35, Elmar Stellnberger escribi?: Am 2016-05-31 um 09:32 schrieb Jay K: > i.e. I'd really like to get out of the build system business. > like to just use autotools or cmake? A make-based build solution would have other advantages as well like f.i. parallel build by make --jobs=4. That way CM3 could build up to four times faster. > But I suspect our system's qualities is difficult to replicate within the other frameworks. > i.e. the incrementality > The way every dynamic library is also available statically. > ? Why not employ a simple hand written make-file that determines that by environment variables? i.e. what libraries to build statically. _______________________________________________ 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 mika at async.caltech.edu Tue May 31 19:16:05 2016 From: mika at async.caltech.edu (mika at async.caltech.edu) Date: Tue, 31 May 2016 10:16:05 -0700 Subject: [M3devel] replace build system?? In-Reply-To: <1784674298.4028093.1464714373116.JavaMail.yahoo@mail.yahoo.com> References: <1784674298.4028093.1464714373116.JavaMail.yahoo@mail.yahoo.com> Message-ID: <20160531171605.13AA61A2068@async.async.caltech.edu> I mentioned this before a few times on this mailing list.... CM3 is already fairly parallel if you turn on the right options. Every back-end invocation can be done in parallel. Set M3_PARALLEL_BACK in the config to 10 or 20 and watch it go... "Daniel Alejandro Benavides D." writes: ... >A make-based build solution would have other advantages as well like=20 >f.i. parallel build by make --jobs=3D4. That way CM3 could build up to=20 >four times faster. ... From jay.krell at cornell.edu Tue May 31 19:17:15 2016 From: jay.krell at cornell.edu (Jay K) Date: Tue, 31 May 2016 17:17:15 +0000 Subject: [M3devel] replace build system?? In-Reply-To: <20160531160502.GC12646@topoi.pooq.com> References: , <20160531160502.GC12646@topoi.pooq.com> Message-ID: Yes it is a backend within cm3, a peer of cm3cg and the integrated NT/x86 backend. I'd really like to move everyone from cm3cg to it. I tested it a bunch at least a while ago. There is still some scripting or such to make a distribution with it. Currently what is provided is enough to build cm3 and mklib from system-specific C. Statically linked. System-specific is hard to completely fix. Statically linked is normal for cm3/mklib anyway. It generates little Makefiles. Ideally the entire system would be distributed this way. Though merely distributing the cm3cg produced .s/.o/.a files would be an approvement. Everytime I look, I don't like cmake or autotools, nor want to keep maintaining our system-specific config files, nor have the time/energy to write something new in C or C++. ?- Jay ---------------------------------------- > Date: Tue, 31 May 2016 12:05:03 -0400 > From: hendrik at topoi.pooq.com > To: m3devel at elegosoft.com > Subject: Re: [M3devel] replace build system?? > > On Tue, May 31, 2016 at 07:32:23AM +0000, Jay K wrote: >> Design of a new or bootstrap/cross/distribution build system? >> >> >> I'd really like our stuff to be as easy to distribute and develop >> as stuff using e.g. autotools or cmake. And as portable. >> >> >> And to reuse other people's work. >> >> >> And have a solid cross build story. >> >> >> And distribution be C or .o or .a or .S files, not executables and so/dylibs. > > Isn't there an m3 compiler that generates C? Didn't you even write it? > > -- hendrik > k > _______________________________________________ > M3devel mailing list > M3devel at elegosoft.com > https://mail.elegosoft.com/cgi-bin/mailman/listinfo/m3devel From jay.krell at cornell.edu Tue May 31 19:18:46 2016 From: jay.krell at cornell.edu (Jay K) Date: Tue, 31 May 2016 17:18:46 +0000 Subject: [M3devel] replace build system?? In-Reply-To: <20160531171605.13AA61A2068@async.async.caltech.edu> References: , , <1784674298.4028093.1464714373116.JavaMail.yahoo@mail.yahoo.com>, <20160531171605.13AA61A2068@async.async.caltech.edu> Message-ID: We should probably learn how to get the number of processors and optionally system load and make this more automatic. Posix should standardize more of this. :( ?- Jay ---------------------------------------- > To: estellnb at elstel.org; jay.krell at cornell.edu; m3devel at elegosoft.com > To: dabenavidesd at yahoo.es > Date: Tue, 31 May 2016 10:16:05 -0700 > From: mika at async.caltech.edu > Subject: Re: [M3devel] replace build system?? > > I mentioned this before a few times on this mailing list.... CM3 is already fairly > parallel if you turn on the right options. Every back-end invocation can be done > in parallel. > > Set M3_PARALLEL_BACK in the config to 10 or 20 and watch it go... > > "Daniel Alejandro Benavides D." writes: > ... >>A make-based build solution would have other advantages as well like=20 >>f.i. parallel build by make --jobs=3D4. That way CM3 could build up to=20 >>four times faster. > ... > _______________________________________________ > M3devel mailing list > M3devel at elegosoft.com > https://mail.elegosoft.com/cgi-bin/mailman/listinfo/m3devel From dabenavidesd at yahoo.es Wed May 4 03:38:26 2016 From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.) Date: Wed, 4 May 2016 01:38:26 +0000 (UTC) Subject: [M3devel] looking if is there any interest References: <122527900.156772.1462325906591.JavaMail.yahoo.ref@mail.yahoo.com> Message-ID: <122527900.156772.1462325906591.JavaMail.yahoo@mail.yahoo.com> Hi floks:Does anyone think in a Cross Platform development environment system; for instance:1. I have a compiler front end in my tablet (say yet to be finished M3clipse) that creates an AST, 2. and sent to generate code for certain platform (in a CM3-IDE of SRC M3 compiler server) to a given target, 3. Download it and execute it in a terminal or windows client? I finally have resources in hardware to make some development, and looking forward to see get the best idea I can implement. thanks in advance -------------- next part -------------- An HTML attachment was scrubbed... URL: From rodney_bates at lcwb.coop Tue May 10 17:21:42 2016 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Tue, 10 May 2016 10:21:42 -0500 Subject: [M3devel] looking if is there any interest In-Reply-To: <122527900.156772.1462325906591.JavaMail.yahoo@mail.yahoo.com> References: <122527900.156772.1462325906591.JavaMail.yahoo.ref@mail.yahoo.com> <122527900.156772.1462325906591.JavaMail.yahoo@mail.yahoo.com> Message-ID: <5731FC86.5070206@lcwb.coop> I'm not sure I fully understand. You propose to have the front-end run on a tablet, code generation run on a remote server? Presumably because the tablet lacks sufficient hardware resources? Then the code executes where, back on the tablet? Personally, I find editing/developing code without a real keyboard to be so hopelessly painful, I just wouldn't do it. Touch screens have exasperatingly high false positive, false negative, and wrong gesture recognition. Maybe I have different hand capacitance than most people. I would prefer to do the editing off the tablet, in which case, it would make sense that the front-end compiling be done on the compile server too. On 05/03/2016 08:38 PM, Daniel Alejandro Benavides D. wrote: > Hi floks: > Does anyone think in a Cross Platform development environment system; for instance: > 1. I have a compiler front end in my tablet (say yet to be finished M3clipse) that creates an AST, > 2. and sent to generate code for certain platform (in a CM3-IDE of SRC M3 compiler server) to a given target, > 3. Download it and execute it in a terminal or windows client? > > I finally have resources in hardware to make some development, and looking forward to see get the best idea I can implement. > > thanks in advance > > > _______________________________________________ > 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 dabenavidesd at yahoo.es Tue May 10 20:02:33 2016 From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.) Date: Tue, 10 May 2016 18:02:33 +0000 (UTC) Subject: [M3devel] looking if is there any interest In-Reply-To: <5731FC86.5070206@lcwb.coop> References: <122527900.156772.1462325906591.JavaMail.yahoo.ref@mail.yahoo.com> <122527900.156772.1462325906591.JavaMail.yahoo@mail.yahoo.com> <5731FC86.5070206@lcwb.coop> Message-ID: <163359176.3358022.1462903353852.JavaMail.yahoo@mail.yahoo.com> Hello Rodney: more or less yes; it's just taking advantage of the CM3/SRC-M3 compiler infrastructure, as ( and please correct me if wrong): (1) Use a Java enabled device (like a tablet running Android, etc via M3clipse) to type check? and AST ("new "m3front) (2) Receive AST via network service CM3-IDE server and do IR ("m3middle") (3). In a gcc enabled platform code generate m3cg ("m3back") The good part of making this adaptation is that most of machines today are either (1) or (3) type (or both just as you say), so we can make the compiler more readily available? (if 1 and 3 are too ). Also, it would nice to have separate machines for easier working so people can contribute where they want and upgrade programs automatically (every distributed computing advantage). So we just concentrate in (2) to be highly available. Besides there are a lot of (3) type machines. Now I have one question, can we made (2) enough platform independent so just have one machine for all platforms, Jay? Thanks in advance El Martes 10 de Mayo de 2016 10:21, Rodney M. Bates escribi?: I'm not sure I fully understand.? You propose to have the front-end run on a tablet, code generation run on a remote server?? Presumably because the tablet lacks sufficient hardware resources?? Then the code executes where, back on the tablet? Personally, I find editing/developing code without a real keyboard to be so hopelessly painful, I just wouldn't do it.? Touch screens have exasperatingly high false positive, false negative, and wrong gesture recognition.? Maybe I have different hand capacitance than most people.? I would prefer to do the editing off the tablet, in which case, it would make sense that the front-end compiling be done on the compile server too. On 05/03/2016 08:38 PM, Daniel Alejandro Benavides D. wrote: > Hi floks: > Does anyone think in a Cross Platform development environment system; for instance: > 1. I have a compiler front end in my tablet (say yet to be finished M3clipse) that creates an AST, > 2. and sent to generate code for certain platform (in a CM3-IDE of SRC M3 compiler server) to a given target, > 3. Download it and execute it in a terminal or windows client? > > I finally have resources in hardware to make some development, and looking forward to see get the best idea I can implement. > > thanks in advance > > > _______________________________________________ > 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From dabenavidesd at yahoo.es Sat May 14 20:23:42 2016 From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.) Date: Sat, 14 May 2016 18:23:42 +0000 (UTC) Subject: [M3devel] A possible source, target References: <671131443.3734750.1463250222583.JavaMail.yahoo.ref@mail.yahoo.com> Message-ID: <671131443.3734750.1463250222583.JavaMail.yahoo@mail.yahoo.com> Hello:if you mind; what about supporting cross development like this platform: PINE64, the World's First 64-Bit Expandable Supercomputer, Runs Ubuntu and Android 5.1 | ? | | ? | | ? | ? | ? | ? | ? | | PINE64, the World's First 64-Bit Expandable Supercomp...It can also run OpenWrt Linux and openHUB | | | | Ver en news.softpedia.com | Vista previa por Yahoo | | | | ? | just for U$15/?14Thanks in advance -------------- next part -------------- An HTML attachment was scrubbed... URL: From peter.mckinna at gmail.com Mon May 23 04:28:05 2016 From: peter.mckinna at gmail.com (Peter McKinna) Date: Mon, 23 May 2016 12:28:05 +1000 Subject: [M3devel] cm3cg failing on linuxlibc6 Message-ID: I dont know what changed but the backend is crashing on linuxlibc6 when compiled with -O Try compiling m3core. Also some of my low level tests with Long.And and Long.Shift are not working with normal compile without the optimisations on that platform. Bit suspicious. I'm still investigating. Anyone got any clues or can replicate? Thanks Peter -------------- next part -------------- An HTML attachment was scrubbed... URL: From rodney_bates at lcwb.coop Mon May 23 20:40:19 2016 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Mon, 23 May 2016 13:40:19 -0500 Subject: [M3devel] cm3cg failing on linuxlibc6 Message-ID: <57434E93.2030205@lcwb.coop> I did git pull and rebuilt on LINUXLIBC6. The built cm3 executable crashes compiling a very small experiment program: rodney at yellowstone:~/proj/m3/exp/FmtBug/src$ cm3- Segmentation fault (core dumped) m3gdb (after I built it) gives this: rodney at yellowstone:~/proj/m3/exp/FmtBug/src$ m3gdb cm3- GNU gdb plus Modula-3 6.4 Copyright 2005 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i686-pc-linux-gnu"...Using host libthread_db library "/lib/tls/i686/cmov/libthread_db.so.1". (m3gdb) run Starting program: /usr/local/cm3-githead/bin/cm3- [Thread debugging using libthread_db enabled] [New LWP 23615] [New Thread -1216829744 (LWP 23615)] Program received signal SIGSEGV, Segmentation fault. [Switching to Thread -1216829744 (LWP 23615)] 0x0037c26f in siglongjmp () from /lib/tls/i686/cmov/libc.so.6 (m3gdb) bt #0 0x0037c26f in siglongjmp () from /lib/tls/i686/cmov/libc.so.6 #1 0x577b2a84 in ?? () Cannot access memory at address 0xd7a0906f (m3gdb) quit stock gdb gives even less information: rodney at yellowstone:~/proj/m3/exp/FmtBug/src$ gdb cm3- GNU gdb (GDB) 7.1-ubuntu Copyright (C) 2010 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "i486-linux-gnu". For bug reporting instructions, please see: ... Reading symbols from /usr/local/cm3-githead/bin/cm3-...done. (gdb) run Starting program: /usr/local/cm3-githead/bin/cm3- [Thread debugging using libthread_db enabled] Program received signal SIGSEGV, Segmentation fault. 0x0032e26f in ?? () from /lib/tls/i686/cmov/libc.so.6 (gdb) bt #0 0x0032e26f in ?? () from /lib/tls/i686/cmov/libc.so.6 #1 0xfb35d04b in ?? () Cannot access memory at address 0x7bee2da0 (gdb) Note that gdb gives a different address in the same library for the point of fault. m3gdb claims it's in siglongjmp. I recall there were some recent changes involving longjump. On 05/22/2016 09:28 PM, Peter McKinna wrote: > I dont know what changed but the backend is crashing on linuxlibc6 when compiled with -O Try compiling m3core. > > Also some of my low level tests with Long.And and Long.Shift are not working with > normal compile without the optimisations on that platform. Bit suspicious. I'm still investigating. > > Anyone got any clues or can replicate? > > Thanks 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 peter.mckinna at gmail.com Tue May 24 09:24:52 2016 From: peter.mckinna at gmail.com (Peter McKinna) Date: Tue, 24 May 2016 17:24:52 +1000 Subject: [M3devel] cm3cg failing on linuxlibc6 In-Reply-To: <57434E93.2030205@lcwb.coop> References: <57434E93.2030205@lcwb.coop> Message-ID: I may have been a tad hasty in blaming the back end for the crashes, the front end has some explaining to do as well. I was getting an infinite loop in a program which I have cut down here to demonstrate. The original cm3 5.2 I think it was from elegosoft worked fine. The latest produces different intermediate code. First the source, (excuse the size, its extracted from my implementation of grisu which I was on the point of pushing to github) MODULE Main; IMPORT Long,IO,Fmt; CONST kUint64MSB = 16_8000000000000000L; TYPE Uint64 = Long.T; PROCEDURE Normalize(sig : Long.T; exp : INTEGER) = CONST k10MSBits = 16_FFC0000000000000L; VAR significand : Uint64; exponent : INTEGER; BEGIN <*ASSERT sig # 0L *> significand := sig; exponent := exp; (*IO.Put("sig init " & Fmt.LongInt(significand) & "\n");*) (* This method is mainly called for normalizing boundaries. In general boundaries need to be shifted by 10 bits. We thus optimize for this case. *) WHILE Long.And(significand, k10MSBits) = 0L DO significand := Long.LeftShift(significand, 10); (*IO.Put("sig loop 1 " & Fmt.LongInt(significand) & "\n");*) DEC(exponent, 10); END; (*IO.Put("sig after loop 1 " & Fmt.LongInt(significand) & "\n");*) (* IO.PutLongInt(Long.And(significand, kUint64MSB)); IO.Put("\n"); *) WHILE Long.And(significand, kUint64MSB) = 0L DO (*IO.Put("sig loop2 1 " & Fmt.LongInt(significand) & "\n");*) significand := Long.LeftShift(significand, 1); (*IO.Put("sig loop2 2 " & Fmt.LongInt(significand) & "\n");*) DEC(exponent); END; END Normalize; BEGIN Normalize(3L,2); END Main. Now the correct intermediate from the original cm3 Its a shame we cant embed the cm3 version into the intermediate. But theres no mention of widechar so you can tell its an old version. begin_unit 0 -----FILE ../src/Main.m3 ----- -----LINE 1 ----- # module global constants declare_segment * -1 T v.1 # module global data declare_segment M_Main -1 F v.2 -----LINE 45 ----- declare_procedure Main_M3 1 Addr 0 0 T * p.1 declare_param mode 4 4 Int.32 425470580 F F 100 v.3 declare_proctype 1318003907 2 0 0 0 declare_formal sig 89530742 declare_formal exp 425470580 import_procedure Main_I3 0 Addr 0 p.2 export_unit Main import_procedure Fmt_I3 0 Addr 0 p.3 import_unit Fmt import_procedure IO_I3 0 Addr 0 p.4 import_unit IO import_procedure Long_I3 0 Addr 0 p.5 import_unit Long import_procedure RTHooks_I3 0 Addr 0 p.6 import_unit RTHooks declare_typename 89530742 Uint64 declare_procedure Main__Normalize 2 Void 0 0 F * p.7 declare_local significand 8 4 Int.64 89530742 F F 50 v.4 declare_local exponent 4 4 Int.32 425470580 F F 50 v.5 declare_param sig 8 4 Int.64 89530742 F F 50 v.6 declare_param exp 4 4 Int.32 425470580 F F 50 v.7 # Normalize -----LINE 11 ----- begin_procedure p.7 -----LINE 12 ----- -----LINE 19 ----- load v.6 0 Int.64 Int.64 load_integer Int.64 0 if_ne Int.64 L.1 100 import_procedure RTHooks__ReportFault 2 Void 0 p.8 declare_param module 4 4 Addr 138420323 F F 50 v.8 declare_param info 4 4 Int.32 425470580 F F 50 v.9 set_runtime_proc ReportFault p.8 abort 0 . L.1 F -----LINE 20 ----- load v.6 0 Int.64 Int.64 store v.4 0 Int.64 Int.64 -----LINE 21 ----- load v.7 0 Int.32 Int.32 store v.5 0 Int.32 Int.32 -----LINE 26 ----- jump L.2 . L.3 F -----LINE 27 ----- load v.4 0 Int.64 Int.64 load_integer Int.32 10 shift_left Int.64 store v.4 0 Int.64 Int.64 -----LINE 29 ----- load v.5 0 Int.32 Int.32 load_integer Int.32 10 subtract Int.32 store v.5 0 Int.32 Int.32 -----LINE 26 ----- . L.2 F load v.4 0 Int.64 Int.64 load_integer Int.64 -18014398509481984 and Int.64 load_integer Int.64 0 if_eq Int.64 L.3 80 . L.4 F -----LINE 36 ----- jump L.5 . L.6 F -----LINE 38 ----- load v.4 0 Int.64 Int.64 load_integer Int.32 1 shift_left Int.64 store v.4 0 Int.64 Int.64 -----LINE 40 ----- load v.5 0 Int.32 Int.32 load_integer Int.32 1 subtract Int.32 store v.5 0 Int.32 Int.32 -----LINE 36 ----- . L.5 F load v.4 0 Int.64 Int.64 load_integer Int.64 -9223372036854775808 and Int.64 load_integer Int.64 0 if_eq Int.64 L.6 80 . L.7 F -----LINE 43 ----- exit_proc Void end_procedure p.7 # Main_M3 # module main body Main_M3 -----LINE 45 ----- begin_procedure p.1 load v.3 0 Int.32 Int.32 if_false Int.32 L.8 0 -----LINE 47 ----- start_call_direct p.7 0 Void load_integer Int.64 3 pop_param Int.64 load_integer Int.32 2 pop_param Int.32 call_direct p.7 Void . L.8 F load_address v.2 0 exit_proc Addr end_procedure p.1 # global constant type descriptor declare_record -1 448 0 # global data type descriptor declare_record -1 896 0 # module global constants bind_segment v.1 56 4 Struct F T begin_init v.1 # procedure names init_chars 0 "Main_M3" init_chars 8 "Normalize" # procedure table init_proc 20 p.1 init_var 24 v.1 0 init_proc 28 p.7 init_var 32 v.1 8 # file name init_chars 40 "../src/Main.m3" end_init v.1 # module global data bind_segment v.2 112 4 Struct F T begin_init v.2 init_var 0 v.1 40 init_var 20 v.1 20 init_var 36 v.2 52 init_proc 44 p.1 init_int 48 3 Int.32 init_proc 56 p.2 init_var 60 v.2 64 init_proc 68 p.3 init_var 72 v.2 76 init_proc 80 p.4 init_var 84 v.2 88 init_proc 92 p.5 init_var 96 v.2 100 init_proc 104 p.6 end_init v.2 # load map # # # global data allocation for M_Main # 0 52 4 *module info* # 52 12 4 import Main # 64 12 4 import Fmt # 76 12 4 import IO # 88 12 4 import Long # 100 12 4 import RTHooks # 112 0 4 *TOTAL* # # # global constants for M_Main # 0 18 4 *proc names* # 20 20 4 *proc info* # 40 15 1 *string* # 56 0 4 *TOTAL* # end_unit Now the intermediate from the latest compiler begin_unit 0 widechar_size 16 -----FILE ../src/Main.m3 ----- -----LINE 1 ----- # module global constants declare_segment * -1 T v.1 # module global data declare_segment M_Main -1 F v.2 -----LINE 45 ----- declare_procedure Main_M3 1 Addr 0 0 T * p.1 declare_param mode 4 4 Int.32 425470580 F F 100 v.3 declare_proctype 1318003907 2 0 0 0 declare_formal sig 89530742 declare_formal exp 425470580 import_procedure Main_I3 0 Addr 0 p.2 export_unit Main import_procedure Fmt_I3 0 Addr 0 p.3 import_unit Fmt import_procedure IO_I3 0 Addr 0 p.4 import_unit IO import_procedure Long_I3 0 Addr 0 p.5 import_unit Long import_procedure RTHooks_I3 0 Addr 0 p.6 import_unit RTHooks declare_typename 89530742 Uint64 declare_procedure Main__Normalize 2 Void 0 0 F * p.7 declare_local significand 8 8 Int.64 89530742 F F 50 v.4 declare_local exponent 4 4 Int.32 425470580 F F 50 v.5 declare_param sig 8 8 Int.64 89530742 F F 50 v.6 declare_param exp 4 4 Int.32 425470580 F F 50 v.7 # Normalize -----LINE 11 ----- begin_procedure p.7 -----LINE 12 ----- -----LINE 19 ----- load_integer Int.64 0 load v.6 0 Int.64 Int.64 if_ne Int.64 L.1 100 declare_proctype -1531209598 2 0 -1 0 declare_formal module 138420323 declare_formal info 425470580 import_procedure RTHooks__ReportFault 2 Void 0 p.8 declare_param module 4 4 Addr 138420323 F F 50 v.8 declare_param info 4 4 Int.32 425470580 F F 50 v.9 set_runtime_proc ReportFault p.8 abort 0 . L.1 F -----LINE 20 ----- load v.6 0 Int.64 Int.64 store v.4 0 Int.64 Int.64 -----LINE 21 ----- load v.7 0 Int.32 Int.32 store v.5 0 Int.32 Int.32 -----LINE 26 ----- jump L.2 . L.3 F -----LINE 27 ----- load v.4 0 Int.64 Int.64 load_integer Int.32 10 shift_left Word.64 store v.4 0 Int.64 Int.64 -----LINE 29 ----- load v.5 0 Int.32 Int.32 load_integer Int.32 10 subtract Int.32 store v.5 0 Int.32 Int.32 -----LINE 26 ----- . L.2 F load_integer Int.64 -18014398509481984 load v.4 0 Int.64 Int.64 and Word.64 load_integer Int.64 0 if_eq Int.64 L.3 80 . L.4 F -----LINE 36 ----- jump L.5 . L.6 F -----LINE 38 ----- load v.4 0 Int.64 Int.64 load_integer Int.32 1 shift_left Word.64 store v.4 0 Int.64 Int.64 -----LINE 40 ----- load v.5 0 Int.32 Int.32 load_integer Int.32 1 subtract Int.32 store v.5 0 Int.32 Int.32 -----LINE 36 ----- . L.5 F load_integer Int.64 0 load v.4 0 Int.64 Int.64 and Word.64 load_integer Int.64 0 if_eq Int.64 L.6 80 . L.7 F -----LINE 43 ----- exit_proc Void end_procedure p.7 # Main_M3 # module main body Main_M3 -----LINE 45 ----- begin_procedure p.1 load v.3 0 Int.32 Int.32 if_false Int.32 L.8 0 -----LINE 47 ----- start_call_direct p.7 0 Void load_integer Int.64 3 pop_param Int.64 load_integer Int.32 2 pop_param Int.32 call_direct p.7 Void . L.8 F load_address v.2 0 exit_proc Addr end_procedure p.1 # global constant type descriptor declare_record -1 448 0 # global data type descriptor declare_record -1 896 0 # module global constants bind_segment v.1 56 8 Struct F T begin_init v.1 # procedure names init_chars 0 "Main_M3" init_chars 8 "Normalize" # procedure table init_proc 20 p.1 init_var 24 v.1 0 init_proc 28 p.7 init_var 32 v.1 8 # file name init_chars 40 "../src/Main.m3" end_init v.1 # module global data bind_segment v.2 112 8 Struct F T begin_init v.2 init_var 0 v.1 40 init_var 20 v.1 20 init_var 36 v.2 52 init_proc 44 p.1 init_int 48 3 Int.32 init_proc 56 p.2 init_var 60 v.2 64 init_proc 68 p.3 init_var 72 v.2 76 init_proc 80 p.4 init_var 84 v.2 88 init_proc 92 p.5 init_var 96 v.2 100 init_proc 104 p.6 end_init v.2 # load map # # # global data allocation for M_Main # 0 52 4 *module info* # 52 12 4 import Main # 64 12 4 import Fmt # 76 12 4 import IO # 88 12 4 import Long # 100 12 4 import RTHooks # 112 0 4 *TOTAL* # # # global constants for M_Main # 0 18 4 *proc names* # 20 20 4 *proc info* # 40 15 1 *string* # 56 0 4 *TOTAL* # end_unit Its very similar except for using Word.64 instead of Int.64 and a couple of other cosmetic issues. The trouble is near label L5 where it does a load_integer of 0 instead of the big constant. The result of anding the zero and testing for zero is causing the loop. Compiling this with -O also causes the backend to crash. Both of these are on LINUXLIBC6. The AMD64 intermediate is correct. Seems like its not parsing the big long for some reason or else its wrapping around. Any ideas? Regards Peter On Tue, May 24, 2016 at 4:40 AM, Rodney M. Bates wrote: > > > > I did git pull and rebuilt on LINUXLIBC6. The built cm3 executable > crashes compiling > a very small experiment program: > > rodney at yellowstone:~/proj/m3/exp/FmtBug/src$ cm3- > Segmentation fault (core dumped) > > m3gdb (after I built it) gives this: > > rodney at yellowstone:~/proj/m3/exp/FmtBug/src$ m3gdb cm3- > GNU gdb plus Modula-3 6.4 > Copyright 2005 Free Software Foundation, Inc. > GDB is free software, covered by the GNU General Public License, and you > are > welcome to change it and/or distribute copies of it under certain > conditions. > Type "show copying" to see the conditions. > There is absolutely no warranty for GDB. Type "show warranty" for > details. > This GDB was configured as "i686-pc-linux-gnu"...Using host libthread_db > library "/lib/tls/i686/cmov/libthread_db.so.1". > > (m3gdb) run > Starting program: /usr/local/cm3-githead/bin/cm3- > [Thread debugging using libthread_db enabled] > [New LWP 23615] > [New Thread -1216829744 (LWP 23615)] > > Program received signal SIGSEGV, Segmentation fault. > [Switching to Thread -1216829744 (LWP 23615)] > 0x0037c26f in siglongjmp () from /lib/tls/i686/cmov/libc.so.6 > (m3gdb) bt > #0 0x0037c26f in siglongjmp () from /lib/tls/i686/cmov/libc.so.6 > #1 0x577b2a84 in ?? () > Cannot access memory at address 0xd7a0906f > (m3gdb) quit > > > stock gdb gives even less information: > > rodney at yellowstone:~/proj/m3/exp/FmtBug/src$ gdb cm3- > GNU gdb (GDB) 7.1-ubuntu > Copyright (C) 2010 Free Software Foundation, Inc. > License GPLv3+: GNU GPL version 3 or later < > http://gnu.org/licenses/gpl.html> > This is free software: you are free to change and redistribute it. > There is NO WARRANTY, to the extent permitted by law. Type "show > copying" > and "show warranty" for details. > This GDB was configured as "i486-linux-gnu". > For bug reporting instructions, please see: > ... > Reading symbols from /usr/local/cm3-githead/bin/cm3-...done. > (gdb) run > Starting program: /usr/local/cm3-githead/bin/cm3- > [Thread debugging using libthread_db enabled] > > Program received signal SIGSEGV, Segmentation fault. > 0x0032e26f in ?? () from /lib/tls/i686/cmov/libc.so.6 > (gdb) bt > #0 0x0032e26f in ?? () from /lib/tls/i686/cmov/libc.so.6 > #1 0xfb35d04b in ?? () > Cannot access memory at address 0x7bee2da0 > (gdb) > > Note that gdb gives a different address in the same library for the point > of fault. > > m3gdb claims it's in siglongjmp. I recall there were some recent changes > involving > longjump. > > > > > > > On 05/22/2016 09:28 PM, Peter McKinna wrote: > > I dont know what changed but the backend is crashing on linuxlibc6 when > compiled with -O Try compiling m3core. > > > > Also some of my low level tests with Long.And and Long.Shift are not > working with > > normal compile without the optimisations on that platform. Bit > suspicious. I'm still investigating. > > > > Anyone got any clues or can replicate? > > > > Thanks 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rodney_bates at lcwb.coop Thu May 26 05:58:11 2016 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Wed, 25 May 2016 22:58:11 -0500 Subject: [M3devel] cm3cg failing on linuxlibc6 In-Reply-To: References: <57434E93.2030205@lcwb.coop> Message-ID: <57467453.4040702@lcwb.coop> Just an FYI on the And bug. I think I have diagnosed this for this particular case. TInt.ToBytes is following the invariants of a TInt.T, which always uses twos-complement notation, but, with a 9th byte, is big enough to hold the entire overlap of the 64-bit signed and unsigned ranges. OTOH, M3CG_BinWr.AddBigX is converting to signed-magnitude, with a separate sign. It passes an absolute value to ToBytes. For only this single value 16_8000000000000000, this is representable as a positive absolute value in 8 bytes, but ToBytes correctly considers this too few bytes for twos-complement and returns zero. It will take more work to look at all the calls on ToBytes and ascertain which cases suffer this mismatch. Also, I am currently unable to build a working compiler for LINUXLIBC6, something to do with jumbufs. So I will have to get around that before testing a fix and for regressions. It looks like it doesn't happen when compiling on a 64-bit machine because that takes a different path, using native INTEGER rather than TInt for the constant value. On 05/24/2016 02:24 AM, Peter McKinna wrote: > I may have been a tad hasty in blaming the back end for the crashes, the front end has some explaining to do as well. > > I was getting an infinite loop in a program which I have cut down here to demonstrate. The original cm3 5.2 I think it > was from elegosoft worked fine. The latest produces different intermediate code. > > First the source, (excuse the size, its extracted from my implementation of grisu which I was on the point of pushing to github) > > MODULE Main; > > IMPORT Long,IO,Fmt; > > CONST > kUint64MSB = 16_8000000000000000L; > > TYPE > Uint64 = Long.T; > PROCEDURE Normalize(sig : Long.T; exp : INTEGER) = > CONST > k10MSBits = 16_FFC0000000000000L; > VAR > significand : Uint64; > exponent : INTEGER; > > BEGIN > <*ASSERT sig # 0L *> > significand := sig; > exponent := exp; > (*IO.Put("sig init " & Fmt.LongInt(significand) & "\n");*) > > (* This method is mainly called for normalizing boundaries. In general > boundaries need to be shifted by 10 bits. We thus optimize for this case. *) > WHILE Long.And(significand, k10MSBits) = 0L DO > significand := Long.LeftShift(significand, 10); > (*IO.Put("sig loop 1 " & Fmt.LongInt(significand) & "\n");*) > DEC(exponent, 10); > END; > (*IO.Put("sig after loop 1 " & Fmt.LongInt(significand) & "\n");*) > (* > IO.PutLongInt(Long.And(significand, kUint64MSB)); > IO.Put("\n"); > *) > WHILE Long.And(significand, kUint64MSB) = 0L DO > (*IO.Put("sig loop2 1 " & Fmt.LongInt(significand) & "\n");*) > significand := Long.LeftShift(significand, 1); > (*IO.Put("sig loop2 2 " & Fmt.LongInt(significand) & "\n");*) > DEC(exponent); > END; > END Normalize; > BEGIN > > Normalize(3L,2); > END Main. > > Now the correct intermediate from the original cm3 > Its a shame we cant embed the cm3 version into the intermediate. But theres no mention of widechar so you can tell its an old > version. > > begin_unit0 > -----FILE ../src/Main.m3 ----- > -----LINE 1 ----- > # module global constants > declare_segment* -1 T v.1 > # module global data > declare_segmentM_Main -1 F v.2 > -----LINE 45 ----- > declare_procedureMain_M3 1 Addr 0 0 T * p.1 > declare_parammode 4 4 Int.32 425470580 F F 100 v.3 > declare_proctype1318003907 2 0 0 0 > declare_formalsig 89530742 > declare_formalexp 425470580 > import_procedureMain_I3 0 Addr 0 p.2 > export_unitMain > import_procedureFmt_I3 0 Addr 0 p.3 > import_unitFmt > import_procedureIO_I3 0 Addr 0 p.4 > import_unitIO > import_procedureLong_I3 0 Addr 0 p.5 > import_unitLong > import_procedureRTHooks_I3 0 Addr 0 p.6 > import_unitRTHooks > declare_typename89530742 Uint64 > declare_procedureMain__Normalize 2 Void 0 0 F * p.7 > declare_localsignificand 8 4 Int.64 89530742 F F 50 v.4 > declare_localexponent 4 4 Int.32 425470580 F F 50 v.5 > declare_paramsig 8 4 Int.64 89530742 F F 50 v.6 > declare_paramexp 4 4 Int.32 425470580 F F 50 v.7 > # Normalize > -----LINE 11 ----- > begin_procedurep.7 > -----LINE 12 ----- > -----LINE 19 ----- > loadv.6 0 Int.64 Int.64 > load_integerInt.64 0 > if_neInt.64 L.1 100 > import_procedureRTHooks__ReportFault 2 Void 0 p.8 > declare_parammodule 4 4 Addr 138420323 F F 50 v.8 > declare_paraminfo 4 4 Int.32 425470580 F F 50 v.9 > set_runtime_procReportFault p.8 > abort0 > . L.1 F > -----LINE 20 ----- > loadv.6 0 Int.64 Int.64 > storev.4 0 Int.64 Int.64 > -----LINE 21 ----- > loadv.7 0 Int.32 Int.32 > storev.5 0 Int.32 Int.32 > -----LINE 26 ----- > jumpL.2 > . L.3 F > -----LINE 27 ----- > loadv.4 0 Int.64 Int.64 > load_integerInt.32 10 > shift_leftInt.64 > storev.4 0 Int.64 Int.64 > -----LINE 29 ----- > loadv.5 0 Int.32 Int.32 > load_integerInt.32 10 > subtractInt.32 > storev.5 0 Int.32 Int.32 > -----LINE 26 ----- > . L.2 F > loadv.4 0 Int.64 Int.64 > load_integerInt.64 -18014398509481984 > andInt.64 > load_integerInt.64 0 > if_eqInt.64 L.3 80 > . L.4 F > -----LINE 36 ----- > jumpL.5 > . L.6 F > -----LINE 38 ----- > loadv.4 0 Int.64 Int.64 > load_integerInt.32 1 > shift_leftInt.64 > storev.4 0 Int.64 Int.64 > -----LINE 40 ----- > loadv.5 0 Int.32 Int.32 > load_integerInt.32 1 > subtractInt.32 > storev.5 0 Int.32 Int.32 > -----LINE 36 ----- > . L.5 F > loadv.4 0 Int.64 Int.64 > load_integerInt.64 -9223372036854775808 > andInt.64 > load_integerInt.64 0 > if_eqInt.64 L.6 80 > . L.7 F > -----LINE 43 ----- > exit_procVoid > end_procedurep.7 > # Main_M3 > # module main body Main_M3 > -----LINE 45 ----- > begin_procedurep.1 > loadv.3 0 Int.32 Int.32 > if_falseInt.32 L.8 0 > -----LINE 47 ----- > start_call_directp.7 0 Void > load_integerInt.64 3 > pop_paramInt.64 > load_integerInt.32 2 > pop_paramInt.32 > call_directp.7 Void > . L.8 F > load_addressv.2 0 > exit_procAddr > end_procedurep.1 > # global constant type descriptor > declare_record-1 448 0 > # global data type descriptor > declare_record-1 896 0 > # module global constants > bind_segmentv.1 56 4 Struct F T > begin_initv.1 > # procedure names > init_chars0 "Main_M3" > init_chars8 "Normalize" > # procedure table > init_proc20 p.1 > init_var24 v.1 0 > init_proc28 p.7 > init_var32 v.1 8 > # file name > init_chars40 "../src/Main.m3" > end_initv.1 > # module global data > bind_segmentv.2 112 4 Struct F T > begin_initv.2 > init_var0 v.1 40 > init_var20 v.1 20 > init_var36 v.2 52 > init_proc44 p.1 > init_int48 3 Int.32 > init_proc56 p.2 > init_var60 v.2 64 > init_proc68 p.3 > init_var72 v.2 76 > init_proc80 p.4 > init_var84 v.2 88 > init_proc92 p.5 > init_var96 v.2 100 > init_proc104 p.6 > end_initv.2 > # load map > # > # > # global data allocation for M_Main > # 0 52 4 *module info* > # 52 12 4 import Main > # 64 12 4 import Fmt > # 76 12 4 import IO > # 88 12 4 import Long > # 100 12 4 import RTHooks > # 112 0 4 *TOTAL* > # > # > # global constants for M_Main > # 0 18 4 *proc names* > # 20 20 4 *proc info* > # 40 15 1 *string* > # 56 0 4 *TOTAL* > # > end_unit > > > Now the intermediate from the latest compiler > > begin_unit0 > widechar_size16 > -----FILE ../src/Main.m3 ----- > -----LINE 1 ----- > # module global constants > declare_segment* -1 T v.1 > # module global data > declare_segmentM_Main -1 F v.2 > -----LINE 45 ----- > declare_procedureMain_M3 1 Addr 0 0 T * p.1 > declare_parammode 4 4 Int.32 425470580 F F 100 v.3 > declare_proctype1318003907 2 0 0 0 > declare_formalsig 89530742 > declare_formalexp 425470580 > import_procedureMain_I3 0 Addr 0 p.2 > export_unitMain > import_procedureFmt_I3 0 Addr 0 p.3 > import_unitFmt > import_procedureIO_I3 0 Addr 0 p.4 > import_unitIO > import_procedureLong_I3 0 Addr 0 p.5 > import_unitLong > import_procedureRTHooks_I3 0 Addr 0 p.6 > import_unitRTHooks > declare_typename89530742 Uint64 > declare_procedureMain__Normalize 2 Void 0 0 F * p.7 > declare_localsignificand 8 8 Int.64 89530742 F F 50 v.4 > declare_localexponent 4 4 Int.32 425470580 F F 50 v.5 > declare_paramsig 8 8 Int.64 89530742 F F 50 v.6 > declare_paramexp 4 4 Int.32 425470580 F F 50 v.7 > # Normalize > -----LINE 11 ----- > begin_procedurep.7 > -----LINE 12 ----- > -----LINE 19 ----- > load_integerInt.64 0 > loadv.6 0 Int.64 Int.64 > if_neInt.64 L.1 100 > declare_proctype-1531209598 2 0 -1 0 > declare_formalmodule 138420323 > declare_formalinfo 425470580 > import_procedureRTHooks__ReportFault 2 Void 0 p.8 > declare_parammodule 4 4 Addr 138420323 F F 50 v.8 > declare_paraminfo 4 4 Int.32 425470580 F F 50 v.9 > set_runtime_procReportFault p.8 > abort0 > . L.1 F > -----LINE 20 ----- > loadv.6 0 Int.64 Int.64 > storev.4 0 Int.64 Int.64 > -----LINE 21 ----- > loadv.7 0 Int.32 Int.32 > storev.5 0 Int.32 Int.32 > -----LINE 26 ----- > jumpL.2 > . L.3 F > -----LINE 27 ----- > loadv.4 0 Int.64 Int.64 > load_integerInt.32 10 > shift_leftWord.64 > storev.4 0 Int.64 Int.64 > -----LINE 29 ----- > loadv.5 0 Int.32 Int.32 > load_integerInt.32 10 > subtractInt.32 > storev.5 0 Int.32 Int.32 > -----LINE 26 ----- > . L.2 F > load_integerInt.64 -18014398509481984 > loadv.4 0 Int.64 Int.64 > andWord.64 > load_integerInt.64 0 > if_eqInt.64 L.3 80 > . L.4 F > -----LINE 36 ----- > jumpL.5 > . L.6 F > -----LINE 38 ----- > loadv.4 0 Int.64 Int.64 > load_integerInt.32 1 > shift_leftWord.64 > storev.4 0 Int.64 Int.64 > -----LINE 40 ----- > loadv.5 0 Int.32 Int.32 > load_integerInt.32 1 > subtractInt.32 > storev.5 0 Int.32 Int.32 > -----LINE 36 ----- > . L.5 F > load_integerInt.64 0 > loadv.4 0 Int.64 Int.64 > andWord.64 > load_integerInt.64 0 > if_eqInt.64 L.6 80 > . L.7 F > -----LINE 43 ----- > exit_procVoid > end_procedurep.7 > # Main_M3 > # module main body Main_M3 > -----LINE 45 ----- > begin_procedurep.1 > loadv.3 0 Int.32 Int.32 > if_falseInt.32 L.8 0 > -----LINE 47 ----- > start_call_directp.7 0 Void > load_integerInt.64 3 > pop_paramInt.64 > load_integerInt.32 2 > pop_paramInt.32 > call_directp.7 Void > . L.8 F > load_addressv.2 0 > exit_procAddr > end_procedurep.1 > # global constant type descriptor > declare_record-1 448 0 > # global data type descriptor > declare_record-1 896 0 > # module global constants > bind_segmentv.1 56 8 Struct F T > begin_initv.1 > # procedure names > init_chars0 "Main_M3" > init_chars8 "Normalize" > # procedure table > init_proc20 p.1 > init_var24 v.1 0 > init_proc28 p.7 > init_var32 v.1 8 > # file name > init_chars40 "../src/Main.m3" > end_initv.1 > # module global data > bind_segmentv.2 112 8 Struct F T > begin_initv.2 > init_var0 v.1 40 > init_var20 v.1 20 > init_var36 v.2 52 > init_proc44 p.1 > init_int48 3 Int.32 > init_proc56 p.2 > init_var60 v.2 64 > init_proc68 p.3 > init_var72 v.2 76 > init_proc80 p.4 > init_var84 v.2 88 > init_proc92 p.5 > init_var96 v.2 100 > init_proc104 p.6 > end_initv.2 > # load map > # > # > # global data allocation for M_Main > # 0 52 4 *module info* > # 52 12 4 import Main > # 64 12 4 import Fmt > # 76 12 4 import IO > # 88 12 4 import Long > # 100 12 4 import RTHooks > # 112 0 4 *TOTAL* > # > # > # global constants for M_Main > # 0 18 4 *proc names* > # 20 20 4 *proc info* > # 40 15 1 *string* > # 56 0 4 *TOTAL* > # > end_unit > > > Its very similar except for using Word.64 instead of Int.64 and a couple of other cosmetic issues. > The trouble is near label L5 where it does a load_integer of 0 instead of the big constant. > The result of anding the zero and testing for zero is causing the loop. > Compiling this with -O also causes the backend to crash. > Both of these are on LINUXLIBC6. The AMD64 intermediate is correct. Seems like its not parsing the > big long for some reason or else its wrapping around. > > Any ideas? > > Regards Peter > > > > On Tue, May 24, 2016 at 4:40 AM, Rodney M. Bates > wrote: > > > > > I did git pull and rebuilt on LINUXLIBC6. The built cm3 executable crashes compiling > a very small experiment program: > > rodney at yellowstone:~/proj/m3/exp/FmtBug/src$ cm3- > Segmentation fault (core dumped) > > m3gdb (after I built it) gives this: > > rodney at yellowstone:~/proj/m3/exp/FmtBug/src$ m3gdb cm3- > GNU gdb plus Modula-3 6.4 > Copyright 2005 Free Software Foundation, Inc. > GDB is free software, covered by the GNU General Public License, and you are > welcome to change it and/or distribute copies of it under certain conditions. > Type "show copying" to see the conditions. > There is absolutely no warranty for GDB. Type "show warranty" for details. > This GDB was configured as "i686-pc-linux-gnu"...Using host libthread_db library "/lib/tls/i686/cmov/libthread_db.so.1". > > (m3gdb) run > Starting program: /usr/local/cm3-githead/bin/cm3- > [Thread debugging using libthread_db enabled] > [New LWP 23615] > [New Thread -1216829744 (LWP 23615)] > > Program received signal SIGSEGV, Segmentation fault. > [Switching to Thread -1216829744 (LWP 23615)] > 0x0037c26f in siglongjmp () from /lib/tls/i686/cmov/libc.so.6 > (m3gdb) bt > #0 0x0037c26f in siglongjmp () from /lib/tls/i686/cmov/libc.so.6 > #1 0x577b2a84 in ?? () > Cannot access memory at address 0xd7a0906f > (m3gdb) quit > > > stock gdb gives even less information: > > rodney at yellowstone:~/proj/m3/exp/FmtBug/src$ gdb cm3- > GNU gdb (GDB) 7.1-ubuntu > Copyright (C) 2010 Free Software Foundation, Inc. > License GPLv3+: GNU GPL version 3 or later > This is free software: you are free to change and redistribute it. > There is NO WARRANTY, to the extent permitted by law. Type "show copying" > and "show warranty" for details. > This GDB was configured as "i486-linux-gnu". > For bug reporting instructions, please see: > ... > Reading symbols from /usr/local/cm3-githead/bin/cm3-...done. > (gdb) run > Starting program: /usr/local/cm3-githead/bin/cm3- > [Thread debugging using libthread_db enabled] > > Program received signal SIGSEGV, Segmentation fault. > 0x0032e26f in ?? () from /lib/tls/i686/cmov/libc.so.6 > (gdb) bt > #0 0x0032e26f in ?? () from /lib/tls/i686/cmov/libc.so.6 > #1 0xfb35d04b in ?? () > Cannot access memory at address 0x7bee2da0 > (gdb) > > Note that gdb gives a different address in the same library for the point of fault. > > m3gdb claims it's in siglongjmp. I recall there were some recent changes involving > longjump. > > > > > > > On 05/22/2016 09:28 PM, Peter McKinna wrote: > > I dont know what changed but the backend is crashing on linuxlibc6 when compiled with -O Try compiling m3core. > > > > Also some of my low level tests with Long.And and Long.Shift are not working with > > normal compile without the optimisations on that platform. Bit suspicious. I'm still investigating. > > > > Anyone got any clues or can replicate? > > > > Thanks 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 Thu May 26 19:03:46 2016 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Thu, 26 May 2016 12:03:46 -0500 Subject: [M3devel] cm3cg failing on linuxlibc6 In-Reply-To: References: <57434E93.2030205@lcwb.coop> <57467453.4040702@lcwb.coop> Message-ID: <57472C72.8090904@lcwb.coop> I am getting this output from your example, with the output commented back in: sig init 3 sig loop 1 3072 sig loop 1 3145728 sig loop 1 3221225472 sig loop 1 3298534883328 sig loop 1 3377699720527872 sig loop 1 3458764513820540928 sig after loop 1 3458764513820540928 0 sig loop2 1 3458764513820540928 sig loop2 2 6917529027641081856 sig loop2 1 6917529027641081856 sig loop2 2 -4611686018427387904 Does it look right? The IR looks right: $ diff Main.mc.m3cgcat.bad Main.mc.m3cgcat 34c34 < load_integer Int.64 0 --- > load_integer Int.64 -9223372036854775808 It still needs some regression testing and wrapping up. On 05/26/2016 12:08 AM, Peter McKinna wrote: > Wow, nice work. Is there a problem in the backend as well? Or other problems in the front end? I suspect the back end problem is something else. That's next. > That dodgy intermediate looked like perfectly good code apart from the loop > so I cant understand why the back end would crash with optimizations on. > > Also what is the deal with jump bufs ? This is unrelated. It just prevented getting a running cm3 on LINUXLIBC6. I now have gotten around thislocally, but it needs more work to not break other platforms. > > Regards Peter > > > On Thu, May 26, 2016 at 1:58 PM, Rodney M. Bates > wrote: > > Just an FYI on the And bug. > > I think I have diagnosed this for this particular case. TInt.ToBytes is following > the invariants of a TInt.T, which always uses twos-complement notation, but, with > a 9th byte, is big enough to hold the entire overlap of the 64-bit signed and unsigned > ranges. OTOH, M3CG_BinWr.AddBigX is converting to signed-magnitude, with a separate > sign. It passes an absolute value to ToBytes. For only this single value > 16_8000000000000000, this is representable as a positive absolute value in 8 bytes, > but ToBytes correctly considers this too few bytes for twos-complement and returns > zero. > > It will take more work to look at all the calls on ToBytes and ascertain which > cases suffer this mismatch. Also, I am currently unable to build a working > compiler for LINUXLIBC6, something to do with jumbufs. So I will have to get around > that before testing a fix and for regressions. > > It looks like it doesn't happen when compiling on a 64-bit machine because that > takes a different path, using native INTEGER rather than TInt for the constant > value. > > > On 05/24/2016 02:24 AM, Peter McKinna wrote: > > I may have been a tad hasty in blaming the back end for the crashes, the front end has some explaining to do as well. > > I was getting an infinite loop in a program which I have cut down here to demonstrate. The original cm3 5.2 I think it > was from elegosoft worked fine. The latest produces different intermediate code. > > First the source, (excuse the size, its extracted from my implementation of grisu which I was on the point of pushing to github) > > MODULE Main; > > IMPORT Long,IO,Fmt; > > CONST > kUint64MSB = 16_8000000000000000L; > > TYPE > Uint64 = Long.T; > PROCEDURE Normalize(sig : Long.T; exp : INTEGER) = > CONST > k10MSBits = 16_FFC0000000000000L; > VAR > significand : Uint64; > exponent : INTEGER; > > BEGIN > <*ASSERT sig # 0L *> > significand := sig; > exponent := exp; > (*IO.Put("sig init " & Fmt.LongInt(significand) & "\n");*) > > (* This method is mainly called for normalizing boundaries. In general > boundaries need to be shifted by 10 bits. We thus optimize for this case. *) > WHILE Long.And(significand, k10MSBits) = 0L DO > significand := Long.LeftShift(significand, 10); > (*IO.Put("sig loop 1 " & Fmt.LongInt(significand) & "\n");*) > DEC(exponent, 10); > END; > (*IO.Put("sig after loop 1 " & Fmt.LongInt(significand) & "\n");*) > (* > IO.PutLongInt(Long.And(significand, kUint64MSB)); > IO.Put("\n"); > *) > WHILE Long.And(significand, kUint64MSB) = 0L DO > (*IO.Put("sig loop2 1 " & Fmt.LongInt(significand) & "\n");*) > significand := Long.LeftShift(significand, 1); > (*IO.Put("sig loop2 2 " & Fmt.LongInt(significand) & "\n");*) > DEC(exponent); > END; > END Normalize; > BEGIN > > Normalize(3L,2); > END Main. > > Now the correct intermediate from the original cm3 > Its a shame we cant embed the cm3 version into the intermediate. But theres no mention of widechar so you can tell its an old > version. > > begin_unit0 > -----FILE ../src/Main.m3 ----- > -----LINE 1 ----- > # module global constants > declare_segment* -1 T v.1 > # module global data > declare_segmentM_Main -1 F v.2 > -----LINE 45 ----- > declare_procedureMain_M3 1 Addr 0 0 T * p.1 > declare_parammode 4 4 Int.32 425470580 F F 100 v.3 > declare_proctype1318003907 2 0 0 0 > declare_formalsig 89530742 > declare_formalexp 425470580 > import_procedureMain_I3 0 Addr 0 p.2 > export_unitMain > import_procedureFmt_I3 0 Addr 0 p.3 > import_unitFmt > import_procedureIO_I3 0 Addr 0 p.4 > import_unitIO > import_procedureLong_I3 0 Addr 0 p.5 > import_unitLong > import_procedureRTHooks_I3 0 Addr 0 p.6 > import_unitRTHooks > declare_typename89530742 Uint64 > declare_procedureMain__Normalize 2 Void 0 0 F * p.7 > declare_localsignificand 8 4 Int.64 89530742 F F 50 v.4 > declare_localexponent 4 4 Int.32 425470580 F F 50 v.5 > declare_paramsig 8 4 Int.64 89530742 F F 50 v.6 > declare_paramexp 4 4 Int.32 425470580 F F 50 v.7 > # Normalize > -----LINE 11 ----- > begin_procedurep.7 > -----LINE 12 ----- > -----LINE 19 ----- > loadv.6 0 Int.64 Int.64 > load_integerInt.64 0 > if_neInt.64 L.1 100 > import_procedureRTHooks__ReportFault 2 Void 0 p.8 > declare_parammodule 4 4 Addr 138420323 F F 50 v.8 > declare_paraminfo 4 4 Int.32 425470580 F F 50 v.9 > set_runtime_procReportFault p.8 > abort0 > . L.1 F > -----LINE 20 ----- > loadv.6 0 Int.64 Int.64 > storev.4 0 Int.64 Int.64 > -----LINE 21 ----- > loadv.7 0 Int.32 Int.32 > storev.5 0 Int.32 Int.32 > -----LINE 26 ----- > jumpL.2 > . L.3 F > -----LINE 27 ----- > loadv.4 0 Int.64 Int.64 > load_integerInt.32 10 > shift_leftInt.64 > storev.4 0 Int.64 Int.64 > -----LINE 29 ----- > loadv.5 0 Int.32 Int.32 > load_integerInt.32 10 > subtractInt.32 > storev.5 0 Int.32 Int.32 > -----LINE 26 ----- > . L.2 F > loadv.4 0 Int.64 Int.64 > load_integerInt.64 -18014398509481984 > andInt.64 > load_integerInt.64 0 > if_eqInt.64 L.3 80 > . L.4 F > -----LINE 36 ----- > jumpL.5 > . L.6 F > -----LINE 38 ----- > loadv.4 0 Int.64 Int.64 > load_integerInt.32 1 > shift_leftInt.64 > storev.4 0 Int.64 Int.64 > -----LINE 40 ----- > loadv.5 0 Int.32 Int.32 > load_integerInt.32 1 > subtractInt.32 > storev.5 0 Int.32 Int.32 > -----LINE 36 ----- > . L.5 F > loadv.4 0 Int.64 Int.64 > load_integerInt.64 -9223372036854775808 > andInt.64 > load_integerInt.64 0 > if_eqInt.64 L.6 80 > . L.7 F > -----LINE 43 ----- > exit_procVoid > end_procedurep.7 > # Main_M3 > # module main body Main_M3 > -----LINE 45 ----- > begin_procedurep.1 > loadv.3 0 Int.32 Int.32 > if_falseInt.32 L.8 0 > -----LINE 47 ----- > start_call_directp.7 0 Void > load_integerInt.64 3 > pop_paramInt.64 > load_integerInt.32 2 > pop_paramInt.32 > call_directp.7 Void > . L.8 F > load_addressv.2 0 > exit_procAddr > end_procedurep.1 > # global constant type descriptor > declare_record-1 448 0 > # global data type descriptor > declare_record-1 896 0 > # module global constants > bind_segmentv.1 56 4 Struct F T > begin_initv.1 > # procedure names > init_chars0 "Main_M3" > init_chars8 "Normalize" > # procedure table > init_proc20 p.1 > init_var24 v.1 0 > init_proc28 p.7 > init_var32 v.1 8 > # file name > init_chars40 "../src/Main.m3" > end_initv.1 > # module global data > bind_segmentv.2 112 4 Struct F T > > begin_initv.2 > init_var0 v.1 40 > init_var20 v.1 20 > init_var36 v.2 52 > init_proc44 p.1 > init_int48 3 Int.32 > init_proc56 p.2 > init_var60 v.2 64 > init_proc68 p.3 > init_var72 v.2 76 > init_proc80 p.4 > init_var84 v.2 88 > init_proc92 p.5 > init_var96 v.2 100 > init_proc104 p.6 > end_initv.2 > # load map > # > # > # global data allocation for M_Main > # 0 52 4 *module info* > # 52 12 4 import Main > # 64 12 4 import Fmt > # 76 12 4 import IO > # 88 12 4 import Long > # 100 12 4 import RTHooks > # 112 0 4 *TOTAL* > # > # > # global constants for M_Main > # 0 18 4 *proc names* > # 20 20 4 *proc info* > # 40 15 1 *string* > # 56 0 4 *TOTAL* > # > end_unit > > > Now the intermediate from the latest compiler > > begin_unit0 > widechar_size16 > -----FILE ../src/Main.m3 ----- > -----LINE 1 ----- > # module global constants > declare_segment* -1 T v.1 > # module global data > declare_segmentM_Main -1 F v.2 > -----LINE 45 ----- > declare_procedureMain_M3 1 Addr 0 0 T * p.1 > declare_parammode 4 4 Int.32 425470580 F F 100 v.3 > declare_proctype1318003907 2 0 0 0 > declare_formalsig 89530742 > declare_formalexp 425470580 > import_procedureMain_I3 0 Addr 0 p.2 > export_unitMain > import_procedureFmt_I3 0 Addr 0 p.3 > import_unitFmt > import_procedureIO_I3 0 Addr 0 p.4 > import_unitIO > import_procedureLong_I3 0 Addr 0 p.5 > import_unitLong > import_procedureRTHooks_I3 0 Addr 0 p.6 > import_unitRTHooks > declare_typename89530742 Uint64 > declare_procedureMain__Normalize 2 Void 0 0 F * p.7 > declare_localsignificand 8 8 Int.64 89530742 F F 50 v.4 > declare_localexponent 4 4 Int.32 425470580 F F 50 v.5 > declare_paramsig 8 8 Int.64 89530742 F F 50 v.6 > declare_paramexp 4 4 Int.32 425470580 F F 50 v.7 > # Normalize > -----LINE 11 ----- > begin_procedurep.7 > -----LINE 12 ----- > -----LINE 19 ----- > load_integerInt.64 0 > loadv.6 0 Int.64 Int.64 > if_neInt.64 L.1 100 > declare_proctype-1531209598 2 0 -1 0 > declare_formalmodule 138420323 > declare_formalinfo 425470580 > import_procedureRTHooks__ReportFault 2 Void 0 p.8 > declare_parammodule 4 4 Addr 138420323 F F 50 v.8 > declare_paraminfo 4 4 Int.32 425470580 F F 50 v.9 > set_runtime_procReportFault p.8 > abort0 > . L.1 F > -----LINE 20 ----- > loadv.6 0 Int.64 Int.64 > storev.4 0 Int.64 Int.64 > -----LINE 21 ----- > loadv.7 0 Int.32 Int.32 > storev.5 0 Int.32 Int.32 > -----LINE 26 ----- > jumpL.2 > . L.3 F > -----LINE 27 ----- > loadv.4 0 Int.64 Int.64 > load_integerInt.32 10 > shift_leftWord.64 > storev.4 0 Int.64 Int.64 > -----LINE 29 ----- > loadv.5 0 Int.32 Int.32 > load_integerInt.32 10 > subtractInt.32 > storev.5 0 Int.32 Int.32 > -----LINE 26 ----- > . L.2 F > load_integerInt.64 -18014398509481984 > loadv.4 0 Int.64 Int.64 > andWord.64 > load_integerInt.64 0 > if_eqInt.64 L.3 80 > . L.4 F > -----LINE 36 ----- > jumpL.5 > . L.6 F > -----LINE 38 ----- > loadv.4 0 Int.64 Int.64 > load_integerInt.32 1 > shift_leftWord.64 > storev.4 0 Int.64 Int.64 > -----LINE 40 ----- > loadv.5 0 Int.32 Int.32 > load_integerInt.32 1 > subtractInt.32 > storev.5 0 Int.32 Int.32 > -----LINE 36 ----- > . L.5 F > load_integerInt.64 0 > loadv.4 0 Int.64 Int.64 > andWord.64 > load_integerInt.64 0 > if_eqInt.64 L.6 80 > . L.7 F > -----LINE 43 ----- > exit_procVoid > end_procedurep.7 > # Main_M3 > # module main body Main_M3 > -----LINE 45 ----- > begin_procedurep.1 > loadv.3 0 Int.32 Int.32 > if_falseInt.32 L.8 0 > -----LINE 47 ----- > start_call_directp.7 0 Void > load_integerInt.64 3 > pop_paramInt.64 > load_integerInt.32 2 > pop_paramInt.32 > call_directp.7 Void > . L.8 F > load_addressv.2 0 > exit_procAddr > end_procedurep.1 > # global constant type descriptor > declare_record-1 448 0 > # global data type descriptor > declare_record-1 896 0 > # module global constants > bind_segmentv.1 56 8 Struct F T > begin_initv.1 > # procedure names > init_chars0 "Main_M3" > init_chars8 "Normalize" > # procedure table > init_proc20 p.1 > init_var24 v.1 0 > init_proc28 p.7 > init_var32 v.1 8 > # file name > init_chars40 "../src/Main.m3" > end_initv.1 > # module global data > bind_segmentv.2 112 8 Struct F T > > begin_initv.2 > init_var0 v.1 40 > init_var20 v.1 20 > init_var36 v.2 52 > init_proc44 p.1 > init_int48 3 Int.32 > init_proc56 p.2 > init_var60 v.2 64 > init_proc68 p.3 > init_var72 v.2 76 > init_proc80 p.4 > init_var84 v.2 88 > init_proc92 p.5 > init_var96 v.2 100 > init_proc104 p.6 > end_initv.2 > # load map > # > # > # global data allocation for M_Main > # 0 52 4 *module info* > # 52 12 4 import Main > # 64 12 4 import Fmt > # 76 12 4 import IO > # 88 12 4 import Long > # 100 12 4 import RTHooks > # 112 0 4 *TOTAL* > # > # > # global constants for M_Main > # 0 18 4 *proc names* > # 20 20 4 *proc info* > # 40 15 1 *string* > # 56 0 4 *TOTAL* > # > end_unit > > > Its very similar except for using Word.64 instead of Int.64 and a couple of other cosmetic issues. > The trouble is near label L5 where it does a load_integer of 0 instead of the big constant. > The result of anding the zero and testing for zero is causing the loop. > Compiling this with -O also causes the backend to crash. > Both of these are on LINUXLIBC6. The AMD64 intermediate is correct. Seems like its not parsing the > big long for some reason or else its wrapping around. > > Any ideas? > > Regards Peter > > > > On Tue, May 24, 2016 at 4:40 AM, Rodney M. Bates >> wrote: > > > > > I did git pull and rebuilt on LINUXLIBC6. The built cm3 executable crashes compiling > a very small experiment program: > > rodney at yellowstone:~/proj/m3/exp/FmtBug/src$ cm3- > Segmentation fault (core dumped) > > m3gdb (after I built it) gives this: > > rodney at yellowstone:~/proj/m3/exp/FmtBug/src$ m3gdb cm3- > GNU gdb plus Modula-3 6.4 > Copyright 2005 Free Software Foundation, Inc. > GDB is free software, covered by the GNU General Public License, and you are > welcome to change it and/or distribute copies of it under certain conditions. > Type "show copying" to see the conditions. > There is absolutely no warranty for GDB. Type "show warranty" for details. > This GDB was configured as "i686-pc-linux-gnu"...Using host libthread_db library "/lib/tls/i686/cmov/libthread_db.so.1". > > (m3gdb) run > Starting program: /usr/local/cm3-githead/bin/cm3- > [Thread debugging using libthread_db enabled] > [New LWP 23615] > [New Thread -1216829744 (LWP 23615)] > > Program received signal SIGSEGV, Segmentation fault. > [Switching to Thread -1216829744 (LWP 23615)] > 0x0037c26f in siglongjmp () from /lib/tls/i686/cmov/libc.so.6 > (m3gdb) bt > #0 0x0037c26f in siglongjmp () from /lib/tls/i686/cmov/libc.so.6 > #1 0x577b2a84 in ?? () > Cannot access memory at address 0xd7a0906f > (m3gdb) quit > > > stock gdb gives even less information: > > rodney at yellowstone:~/proj/m3/exp/FmtBug/src$ gdb cm3- > GNU gdb (GDB) 7.1-ubuntu > Copyright (C) 2010 Free Software Foundation, Inc. > License GPLv3+: GNU GPL version 3 or later > This is free software: you are free to change and redistribute it. > There is NO WARRANTY, to the extent permitted by law. Type "show copying" > and "show warranty" for details. > This GDB was configured as "i486-linux-gnu". > For bug reporting instructions, please see: > ... > Reading symbols from /usr/local/cm3-githead/bin/cm3-...done. > (gdb) run > Starting program: /usr/local/cm3-githead/bin/cm3- > [Thread debugging using libthread_db enabled] > > Program received signal SIGSEGV, Segmentation fault. > 0x0032e26f in ?? () from /lib/tls/i686/cmov/libc.so.6 > (gdb) bt > #0 0x0032e26f in ?? () from /lib/tls/i686/cmov/libc.so.6 > #1 0xfb35d04b in ?? () > Cannot access memory at address 0x7bee2da0 > (gdb) > > Note that gdb gives a different address in the same library for the point of fault. > > m3gdb claims it's in siglongjmp. I recall there were some recent changes involving > longjump. > > > > > > > On 05/22/2016 09:28 PM, Peter McKinna wrote: > > I dont know what changed but the backend is crashing on linuxlibc6 when compiled with -O Try compiling m3core. > > > > Also some of my low level tests with Long.And and Long.Shift are not working with > > normal compile without the optimisations on that platform. Bit suspicious. I'm still investigating. > > > > Anyone got any clues or can replicate? > > > > Thanks 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 Thu May 26 23:23:18 2016 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Thu, 26 May 2016 16:23:18 -0500 Subject: [M3devel] cm3cg failing on linuxlibc6 In-Reply-To: <57472C72.8090904@lcwb.coop> References: <57434E93.2030205@lcwb.coop> <57467453.4040702@lcwb.coop> <57472C72.8090904@lcwb.coop> Message-ID: <57476946.20706@lcwb.coop> It's now verified to recompile itself twice, committed and pushed to github. On 05/26/2016 12:03 PM, Rodney M. Bates wrote: > I am getting this output from your example, with the output commented back in: > > sig init 3 > sig loop 1 3072 > sig loop 1 3145728 > sig loop 1 3221225472 > sig loop 1 3298534883328 > sig loop 1 3377699720527872 > sig loop 1 3458764513820540928 > sig after loop 1 3458764513820540928 > 0 > sig loop2 1 3458764513820540928 > sig loop2 2 6917529027641081856 > sig loop2 1 6917529027641081856 > sig loop2 2 -4611686018427387904 > > > Does it look right? The IR looks right: > > $ diff Main.mc.m3cgcat.bad Main.mc.m3cgcat > 34c34 > < load_integer Int.64 0 > --- > > load_integer Int.64 -9223372036854775808 > > > It still needs some regression testing and wrapping up. > > > > On 05/26/2016 12:08 AM, Peter McKinna wrote: >> Wow, nice work. Is there a problem in the backend as well? Or other problems in the front end? > > I suspect the back end problem is something else. That's next. > >> That dodgy intermediate looked like perfectly good code apart from the loop >> so I cant understand why the back end would crash with optimizations on. >> >> Also what is the deal with jump bufs ? > > This is unrelated. It just prevented getting a running cm3 on LINUXLIBC6. I now > have gotten around thislocally, but it needs more work to not break other platforms. > >> >> Regards Peter >> >> >> On Thu, May 26, 2016 at 1:58 PM, Rodney M. Bates > wrote: >> >> Just an FYI on the And bug. >> >> I think I have diagnosed this for this particular case. TInt.ToBytes is following >> the invariants of a TInt.T, which always uses twos-complement notation, but, with >> a 9th byte, is big enough to hold the entire overlap of the 64-bit signed and unsigned >> ranges. OTOH, M3CG_BinWr.AddBigX is converting to signed-magnitude, with a separate >> sign. It passes an absolute value to ToBytes. For only this single value >> 16_8000000000000000, this is representable as a positive absolute value in 8 bytes, >> but ToBytes correctly considers this too few bytes for twos-complement and returns >> zero. >> >> It will take more work to look at all the calls on ToBytes and ascertain which >> cases suffer this mismatch. Also, I am currently unable to build a working >> compiler for LINUXLIBC6, something to do with jumbufs. So I will have to get around >> that before testing a fix and for regressions. >> >> It looks like it doesn't happen when compiling on a 64-bit machine because that >> takes a different path, using native INTEGER rather than TInt for the constant >> value. >> >> >> On 05/24/2016 02:24 AM, Peter McKinna wrote: >> >> I may have been a tad hasty in blaming the back end for the crashes, the front end has some explaining to do as well. >> >> I was getting an infinite loop in a program which I have cut down here to demonstrate. The original cm3 5.2 I think it >> was from elegosoft worked fine. The latest produces different intermediate code. >> >> First the source, (excuse the size, its extracted from my implementation of grisu which I was on the point of pushing to github) >> >> MODULE Main; >> >> IMPORT Long,IO,Fmt; >> >> CONST >> kUint64MSB = 16_8000000000000000L; >> >> TYPE >> Uint64 = Long.T; >> PROCEDURE Normalize(sig : Long.T; exp : INTEGER) = >> CONST >> k10MSBits = 16_FFC0000000000000L; >> VAR >> significand : Uint64; >> exponent : INTEGER; >> >> BEGIN >> <*ASSERT sig # 0L *> >> significand := sig; >> exponent := exp; >> (*IO.Put("sig init " & Fmt.LongInt(significand) & "\n");*) >> >> (* This method is mainly called for normalizing boundaries. In general >> boundaries need to be shifted by 10 bits. We thus optimize for this case. *) >> WHILE Long.And(significand, k10MSBits) = 0L DO >> significand := Long.LeftShift(significand, 10); >> (*IO.Put("sig loop 1 " & Fmt.LongInt(significand) & "\n");*) >> DEC(exponent, 10); >> END; >> (*IO.Put("sig after loop 1 " & Fmt.LongInt(significand) & "\n");*) >> (* >> IO.PutLongInt(Long.And(significand, kUint64MSB)); >> IO.Put("\n"); >> *) >> WHILE Long.And(significand, kUint64MSB) = 0L DO >> (*IO.Put("sig loop2 1 " & Fmt.LongInt(significand) & "\n");*) >> significand := Long.LeftShift(significand, 1); >> (*IO.Put("sig loop2 2 " & Fmt.LongInt(significand) & "\n");*) >> DEC(exponent); >> END; >> END Normalize; >> BEGIN >> >> Normalize(3L,2); >> END Main. >> >> Now the correct intermediate from the original cm3 >> Its a shame we cant embed the cm3 version into the intermediate. But theres no mention of widechar so you can tell its an old >> version. >> >> begin_unit0 >> -----FILE ../src/Main.m3 ----- >> -----LINE 1 ----- >> # module global constants >> declare_segment* -1 T v.1 >> # module global data >> declare_segmentM_Main -1 F v.2 >> -----LINE 45 ----- >> declare_procedureMain_M3 1 Addr 0 0 T * p.1 >> declare_parammode 4 4 Int.32 425470580 F F 100 v.3 >> declare_proctype1318003907 2 0 0 0 >> declare_formalsig 89530742 >> declare_formalexp 425470580 >> import_procedureMain_I3 0 Addr 0 p.2 >> export_unitMain >> import_procedureFmt_I3 0 Addr 0 p.3 >> import_unitFmt >> import_procedureIO_I3 0 Addr 0 p.4 >> import_unitIO >> import_procedureLong_I3 0 Addr 0 p.5 >> import_unitLong >> import_procedureRTHooks_I3 0 Addr 0 p.6 >> import_unitRTHooks >> declare_typename89530742 Uint64 >> declare_procedureMain__Normalize 2 Void 0 0 F * p.7 >> declare_localsignificand 8 4 Int.64 89530742 F F 50 v.4 >> declare_localexponent 4 4 Int.32 425470580 F F 50 v.5 >> declare_paramsig 8 4 Int.64 89530742 F F 50 v.6 >> declare_paramexp 4 4 Int.32 425470580 F F 50 v.7 >> # Normalize >> -----LINE 11 ----- >> begin_procedurep.7 >> -----LINE 12 ----- >> -----LINE 19 ----- >> loadv.6 0 Int.64 Int.64 >> load_integerInt.64 0 >> if_neInt.64 L.1 100 >> import_procedureRTHooks__ReportFault 2 Void 0 p.8 >> declare_parammodule 4 4 Addr 138420323 F F 50 v.8 >> declare_paraminfo 4 4 Int.32 425470580 F F 50 v.9 >> set_runtime_procReportFault p.8 >> abort0 >> . L.1 F >> -----LINE 20 ----- >> loadv.6 0 Int.64 Int.64 >> storev.4 0 Int.64 Int.64 >> -----LINE 21 ----- >> loadv.7 0 Int.32 Int.32 >> storev.5 0 Int.32 Int.32 >> -----LINE 26 ----- >> jumpL.2 >> . L.3 F >> -----LINE 27 ----- >> loadv.4 0 Int.64 Int.64 >> load_integerInt.32 10 >> shift_leftInt.64 >> storev.4 0 Int.64 Int.64 >> -----LINE 29 ----- >> loadv.5 0 Int.32 Int.32 >> load_integerInt.32 10 >> subtractInt.32 >> storev.5 0 Int.32 Int.32 >> -----LINE 26 ----- >> . L.2 F >> loadv.4 0 Int.64 Int.64 >> load_integerInt.64 -18014398509481984 >> andInt.64 >> load_integerInt.64 0 >> if_eqInt.64 L.3 80 >> . L.4 F >> -----LINE 36 ----- >> jumpL.5 >> . L.6 F >> -----LINE 38 ----- >> loadv.4 0 Int.64 Int.64 >> load_integerInt.32 1 >> shift_leftInt.64 >> storev.4 0 Int.64 Int.64 >> -----LINE 40 ----- >> loadv.5 0 Int.32 Int.32 >> load_integerInt.32 1 >> subtractInt.32 >> storev.5 0 Int.32 Int.32 >> -----LINE 36 ----- >> . L.5 F >> loadv.4 0 Int.64 Int.64 >> load_integerInt.64 -9223372036854775808 >> andInt.64 >> load_integerInt.64 0 >> if_eqInt.64 L.6 80 >> . L.7 F >> -----LINE 43 ----- >> exit_procVoid >> end_procedurep.7 >> # Main_M3 >> # module main body Main_M3 >> -----LINE 45 ----- >> begin_procedurep.1 >> loadv.3 0 Int.32 Int.32 >> if_falseInt.32 L.8 0 >> -----LINE 47 ----- >> start_call_directp.7 0 Void >> load_integerInt.64 3 >> pop_paramInt.64 >> load_integerInt.32 2 >> pop_paramInt.32 >> call_directp.7 Void >> . L.8 F >> load_addressv.2 0 >> exit_procAddr >> end_procedurep.1 >> # global constant type descriptor >> declare_record-1 448 0 >> # global data type descriptor >> declare_record-1 896 0 >> # module global constants >> bind_segmentv.1 56 4 Struct F T >> begin_initv.1 >> # procedure names >> init_chars0 "Main_M3" >> init_chars8 "Normalize" >> # procedure table >> init_proc20 p.1 >> init_var24 v.1 0 >> init_proc28 p.7 >> init_var32 v.1 8 >> # file name >> init_chars40 "../src/Main.m3" >> end_initv.1 >> # module global data >> bind_segmentv.2 112 4 Struct F T >> >> begin_initv.2 >> init_var0 v.1 40 >> init_var20 v.1 20 >> init_var36 v.2 52 >> init_proc44 p.1 >> init_int48 3 Int.32 >> init_proc56 p.2 >> init_var60 v.2 64 >> init_proc68 p.3 >> init_var72 v.2 76 >> init_proc80 p.4 >> init_var84 v.2 88 >> init_proc92 p.5 >> init_var96 v.2 100 >> init_proc104 p.6 >> end_initv.2 >> # load map >> # >> # >> # global data allocation for M_Main >> # 0 52 4 *module info* >> # 52 12 4 import Main >> # 64 12 4 import Fmt >> # 76 12 4 import IO >> # 88 12 4 import Long >> # 100 12 4 import RTHooks >> # 112 0 4 *TOTAL* >> # >> # >> # global constants for M_Main >> # 0 18 4 *proc names* >> # 20 20 4 *proc info* >> # 40 15 1 *string* >> # 56 0 4 *TOTAL* >> # >> end_unit >> >> >> Now the intermediate from the latest compiler >> >> begin_unit0 >> widechar_size16 >> -----FILE ../src/Main.m3 ----- >> -----LINE 1 ----- >> # module global constants >> declare_segment* -1 T v.1 >> # module global data >> declare_segmentM_Main -1 F v.2 >> -----LINE 45 ----- >> declare_procedureMain_M3 1 Addr 0 0 T * p.1 >> declare_parammode 4 4 Int.32 425470580 F F 100 v.3 >> declare_proctype1318003907 2 0 0 0 >> declare_formalsig 89530742 >> declare_formalexp 425470580 >> import_procedureMain_I3 0 Addr 0 p.2 >> export_unitMain >> import_procedureFmt_I3 0 Addr 0 p.3 >> import_unitFmt >> import_procedureIO_I3 0 Addr 0 p.4 >> import_unitIO >> import_procedureLong_I3 0 Addr 0 p.5 >> import_unitLong >> import_procedureRTHooks_I3 0 Addr 0 p.6 >> import_unitRTHooks >> declare_typename89530742 Uint64 >> declare_procedureMain__Normalize 2 Void 0 0 F * p.7 >> declare_localsignificand 8 8 Int.64 89530742 F F 50 v.4 >> declare_localexponent 4 4 Int.32 425470580 F F 50 v.5 >> declare_paramsig 8 8 Int.64 89530742 F F 50 v.6 >> declare_paramexp 4 4 Int.32 425470580 F F 50 v.7 >> # Normalize >> -----LINE 11 ----- >> begin_procedurep.7 >> -----LINE 12 ----- >> -----LINE 19 ----- >> load_integerInt.64 0 >> loadv.6 0 Int.64 Int.64 >> if_neInt.64 L.1 100 >> declare_proctype-1531209598 2 0 -1 0 >> declare_formalmodule 138420323 >> declare_formalinfo 425470580 >> import_procedureRTHooks__ReportFault 2 Void 0 p.8 >> declare_parammodule 4 4 Addr 138420323 F F 50 v.8 >> declare_paraminfo 4 4 Int.32 425470580 F F 50 v.9 >> set_runtime_procReportFault p.8 >> abort0 >> . L.1 F >> -----LINE 20 ----- >> loadv.6 0 Int.64 Int.64 >> storev.4 0 Int.64 Int.64 >> -----LINE 21 ----- >> loadv.7 0 Int.32 Int.32 >> storev.5 0 Int.32 Int.32 >> -----LINE 26 ----- >> jumpL.2 >> . L.3 F >> -----LINE 27 ----- >> loadv.4 0 Int.64 Int.64 >> load_integerInt.32 10 >> shift_leftWord.64 >> storev.4 0 Int.64 Int.64 >> -----LINE 29 ----- >> loadv.5 0 Int.32 Int.32 >> load_integerInt.32 10 >> subtractInt.32 >> storev.5 0 Int.32 Int.32 >> -----LINE 26 ----- >> . L.2 F >> load_integerInt.64 -18014398509481984 >> loadv.4 0 Int.64 Int.64 >> andWord.64 >> load_integerInt.64 0 >> if_eqInt.64 L.3 80 >> . L.4 F >> -----LINE 36 ----- >> jumpL.5 >> . L.6 F >> -----LINE 38 ----- >> loadv.4 0 Int.64 Int.64 >> load_integerInt.32 1 >> shift_leftWord.64 >> storev.4 0 Int.64 Int.64 >> -----LINE 40 ----- >> loadv.5 0 Int.32 Int.32 >> load_integerInt.32 1 >> subtractInt.32 >> storev.5 0 Int.32 Int.32 >> -----LINE 36 ----- >> . L.5 F >> load_integerInt.64 0 >> loadv.4 0 Int.64 Int.64 >> andWord.64 >> load_integerInt.64 0 >> if_eqInt.64 L.6 80 >> . L.7 F >> -----LINE 43 ----- >> exit_procVoid >> end_procedurep.7 >> # Main_M3 >> # module main body Main_M3 >> -----LINE 45 ----- >> begin_procedurep.1 >> loadv.3 0 Int.32 Int.32 >> if_falseInt.32 L.8 0 >> -----LINE 47 ----- >> start_call_directp.7 0 Void >> load_integerInt.64 3 >> pop_paramInt.64 >> load_integerInt.32 2 >> pop_paramInt.32 >> call_directp.7 Void >> . L.8 F >> load_addressv.2 0 >> exit_procAddr >> end_procedurep.1 >> # global constant type descriptor >> declare_record-1 448 0 >> # global data type descriptor >> declare_record-1 896 0 >> # module global constants >> bind_segmentv.1 56 8 Struct F T >> begin_initv.1 >> # procedure names >> init_chars0 "Main_M3" >> init_chars8 "Normalize" >> # procedure table >> init_proc20 p.1 >> init_var24 v.1 0 >> init_proc28 p.7 >> init_var32 v.1 8 >> # file name >> init_chars40 "../src/Main.m3" >> end_initv.1 >> # module global data >> bind_segmentv.2 112 8 Struct F T >> >> begin_initv.2 >> init_var0 v.1 40 >> init_var20 v.1 20 >> init_var36 v.2 52 >> init_proc44 p.1 >> init_int48 3 Int.32 >> init_proc56 p.2 >> init_var60 v.2 64 >> init_proc68 p.3 >> init_var72 v.2 76 >> init_proc80 p.4 >> init_var84 v.2 88 >> init_proc92 p.5 >> init_var96 v.2 100 >> init_proc104 p.6 >> end_initv.2 >> # load map >> # >> # >> # global data allocation for M_Main >> # 0 52 4 *module info* >> # 52 12 4 import Main >> # 64 12 4 import Fmt >> # 76 12 4 import IO >> # 88 12 4 import Long >> # 100 12 4 import RTHooks >> # 112 0 4 *TOTAL* >> # >> # >> # global constants for M_Main >> # 0 18 4 *proc names* >> # 20 20 4 *proc info* >> # 40 15 1 *string* >> # 56 0 4 *TOTAL* >> # >> end_unit >> >> >> Its very similar except for using Word.64 instead of Int.64 and a couple of other cosmetic issues. >> The trouble is near label L5 where it does a load_integer of 0 instead of the big constant. >> The result of anding the zero and testing for zero is causing the loop. >> Compiling this with -O also causes the backend to crash. >> Both of these are on LINUXLIBC6. The AMD64 intermediate is correct. Seems like its not parsing the >> big long for some reason or else its wrapping around. >> >> Any ideas? >> >> Regards Peter >> >> >> >> On Tue, May 24, 2016 at 4:40 AM, Rodney M. Bates >> wrote: >> >> >> >> >> I did git pull and rebuilt on LINUXLIBC6. The built cm3 executable crashes compiling >> a very small experiment program: >> >> rodney at yellowstone:~/proj/m3/exp/FmtBug/src$ cm3- >> Segmentation fault (core dumped) >> >> m3gdb (after I built it) gives this: >> >> rodney at yellowstone:~/proj/m3/exp/FmtBug/src$ m3gdb cm3- >> GNU gdb plus Modula-3 6.4 >> Copyright 2005 Free Software Foundation, Inc. >> GDB is free software, covered by the GNU General Public License, and you are >> welcome to change it and/or distribute copies of it under certain conditions. >> Type "show copying" to see the conditions. >> There is absolutely no warranty for GDB. Type "show warranty" for details. >> This GDB was configured as "i686-pc-linux-gnu"...Using host libthread_db library "/lib/tls/i686/cmov/libthread_db.so.1". >> >> (m3gdb) run >> Starting program: /usr/local/cm3-githead/bin/cm3- >> [Thread debugging using libthread_db enabled] >> [New LWP 23615] >> [New Thread -1216829744 (LWP 23615)] >> >> Program received signal SIGSEGV, Segmentation fault. >> [Switching to Thread -1216829744 (LWP 23615)] >> 0x0037c26f in siglongjmp () from /lib/tls/i686/cmov/libc.so.6 >> (m3gdb) bt >> #0 0x0037c26f in siglongjmp () from /lib/tls/i686/cmov/libc.so.6 >> #1 0x577b2a84 in ?? () >> Cannot access memory at address 0xd7a0906f >> (m3gdb) quit >> >> >> stock gdb gives even less information: >> >> rodney at yellowstone:~/proj/m3/exp/FmtBug/src$ gdb cm3- >> GNU gdb (GDB) 7.1-ubuntu >> Copyright (C) 2010 Free Software Foundation, Inc. >> License GPLv3+: GNU GPL version 3 or later >> This is free software: you are free to change and redistribute it. >> There is NO WARRANTY, to the extent permitted by law. Type "show copying" >> and "show warranty" for details. >> This GDB was configured as "i486-linux-gnu". >> For bug reporting instructions, please see: >> ... >> Reading symbols from /usr/local/cm3-githead/bin/cm3-...done. >> (gdb) run >> Starting program: /usr/local/cm3-githead/bin/cm3- >> [Thread debugging using libthread_db enabled] >> >> Program received signal SIGSEGV, Segmentation fault. >> 0x0032e26f in ?? () from /lib/tls/i686/cmov/libc.so.6 >> (gdb) bt >> #0 0x0032e26f in ?? () from /lib/tls/i686/cmov/libc.so.6 >> #1 0xfb35d04b in ?? () >> Cannot access memory at address 0x7bee2da0 >> (gdb) >> >> Note that gdb gives a different address in the same library for the point of fault. >> >> m3gdb claims it's in siglongjmp. I recall there were some recent changes involving >> longjump. >> >> >> >> >> >> >> On 05/22/2016 09:28 PM, Peter McKinna wrote: >> > I dont know what changed but the backend is crashing on linuxlibc6 when compiled with -O Try compiling m3core. >> > >> > Also some of my low level tests with Long.And and Long.Shift are not working with >> > normal compile without the optimisations on that platform. Bit suspicious. I'm still investigating. >> > >> > Anyone got any clues or can replicate? >> > >> > Thanks 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 Fri May 27 20:38:07 2016 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Fri, 27 May 2016 13:38:07 -0500 Subject: [M3devel] cm3cg failing on linuxlibc6 In-Reply-To: References: Message-ID: <5748940F.5020808@lcwb.coop> On 05/22/2016 09:28 PM, Peter McKinna wrote: > I dont know what changed but the backend is crashing on linuxlibc6 when compiled with -O Try compiling m3core. > I get crashes compiling with -O -O1 -O2 -O3, with different symptoms. -O and -O2 just segfault. -O2 and -O3 get: ... /usr/local/cm3//bin/cm3cg -march=i686 -quiet -fno-reorder-blocks -funwind-tables -fPIC -m32 -O3 -gstabs+ Main.mc -o Main.ms *** glibc detected *** /usr/local/cm3//bin/cm3cg: double free or corruption (fasttop): 0x0a20b0d8 *** ======= Backtrace: ========= /lib/tls/i686/cmov/libc.so.6(+0x6e0a1)[0xac00a1] /lib/tls/i686/cmov/libc.so.6(+0x6f8f8)[0xac18f8] /lib/tls/i686/cmov/libc.so.6(cfree+0x6d)[0xac4a6d] /usr/local/cm3//bin/cm3cg[0x81c7df8] ======= Memory map: ======== 00180000-002ef000 r-xp 00000000 08:05 5507589 /usr/lib/libstdc++.so.6.0.21 002ef000-002f5000 r--p 0016e000 08:05 5507589 /usr/lib/libstdc++.so.6.0.21 002f5000-002f6000 rw-p 00174000 08:05 5507589 /usr/lib/libstdc++.so.6.0.21 002f6000-002f9000 rw-p 00000000 00:00 0 00360000-0037c000 r-xp 00000000 08:05 4337255 /lib/libgcc_s.so.1 0037c000-0037d000 r--p 0001b000 08:05 4337255 /lib/libgcc_s.so.1 0037d000-0037e000 rw-p 0001c000 08:05 4337255 /lib/libgcc_s.so.1 0087a000-00895000 r-xp 00000000 08:05 4336906 /lib/ld-2.11.1.so 00895000-00896000 r--p 0001a000 08:05 4336906 /lib/ld-2.11.1.so 00896000-00897000 rw-p 0001b000 08:05 4336906 /lib/ld-2.11.1.so 00a52000-00bae000 r-xp 00000000 08:05 4467785 /lib/tls/i686/cmov/libc-2.11.1.so 00bae000-00bb0000 r--p 0015b000 08:05 4467785 /lib/tls/i686/cmov/libc-2.11.1.so 00bb0000-00bb1000 rw-p 0015d000 08:05 4467785 /lib/tls/i686/cmov/libc-2.11.1.so 00bb1000-00bb4000 rw-p 00000000 00:00 0 00deb000-00e0f000 r-xp 00000000 08:05 4467782 /lib/tls/i686/cmov/libm-2.11.1.so 00e0f000-00e10000 r--p 00023000 08:05 4467782 /lib/tls/i686/cmov/libm-2.11.1.so 00e10000-00e11000 rw-p 00024000 08:05 4467782 /lib/tls/i686/cmov/libm-2.11.1.so 00f24000-00f25000 r-xp 00000000 00:00 0 [vdso] 08048000-088cd000 r-xp 00000000 08:05 5778669 /usr/local/cm3-githead/bin/cm3cg 088cd000-088ce000 r--p 00885000 08:05 5778669 /usr/local/cm3-githead/bin/cm3cg 088ce000-088d4000 rw-p 00886000 08:05 5778669 /usr/local/cm3-githead/bin/cm3cg 088d4000-089fe000 rw-p 00000000 00:00 0 0a149000-0a216000 rw-p 00000000 00:00 0 [heap] b7300000-b7321000 rw-p 00000000 00:00 0 b7321000-b7400000 ---p 00000000 00:00 0 b74d4000-b771a000 rw-p 00000000 00:00 0 b772b000-b7733000 rw-p 00000000 00:00 0 bff93000-bffa8000 rw-p 00000000 00:00 0 [stack] ../src/Main.m3: In function 'Main__Normalize': ../src/Main.m3:41:0: internal compiler error: Aborted Please submit a full bug report, with preprocessed source if appropriate. See for instructions. Were you compiling things earlier with -O successfully? I vaguely recall something to the effect that cm3cg never has worked with optimization. Anybody remember about this? > Also some of my low level tests with Long.And and Long.Shift are not working with > normal compile without the optimisations on that platform. Bit suspicious. I'm still investigating. > > Anyone got any clues or can replicate? > > Thanks 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 Fri May 27 20:45:31 2016 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Fri, 27 May 2016 13:45:31 -0500 Subject: [M3devel] cm3cg failing on linuxlibc6 In-Reply-To: <57434E93.2030205@lcwb.coop> References: <57434E93.2030205@lcwb.coop> Message-ID: <574895CB.10200@lcwb.coop> I got around this problem by setting Alloca_jmpbuf back to TRUE in m3-libs/m3core/src/runtime/ex_frame/RTExFrame.m3 and m3-sys/m3middle/src/Target.m3 I am trying to remember, but as I recall, TRUE was failing on some other platform, and the change was reverted. But now FALSE is failing on LINUXLIBC6 and TRUE is working there. What do you remember about this, Jay? On 05/23/2016 01:40 PM, Rodney M. Bates wrote: > > > > I did git pull and rebuilt on LINUXLIBC6. The built cm3 executable crashes compiling > a very small experiment program: > > rodney at yellowstone:~/proj/m3/exp/FmtBug/src$ cm3- > Segmentation fault (core dumped) > > m3gdb (after I built it) gives this: > > rodney at yellowstone:~/proj/m3/exp/FmtBug/src$ m3gdb cm3- > GNU gdb plus Modula-3 6.4 > Copyright 2005 Free Software Foundation, Inc. > GDB is free software, covered by the GNU General Public License, and you are > welcome to change it and/or distribute copies of it under certain conditions. > Type "show copying" to see the conditions. > There is absolutely no warranty for GDB. Type "show warranty" for details. > This GDB was configured as "i686-pc-linux-gnu"...Using host libthread_db library "/lib/tls/i686/cmov/libthread_db.so.1". > > (m3gdb) run > Starting program: /usr/local/cm3-githead/bin/cm3- > [Thread debugging using libthread_db enabled] > [New LWP 23615] > [New Thread -1216829744 (LWP 23615)] > > Program received signal SIGSEGV, Segmentation fault. > [Switching to Thread -1216829744 (LWP 23615)] > 0x0037c26f in siglongjmp () from /lib/tls/i686/cmov/libc.so.6 > (m3gdb) bt > #0 0x0037c26f in siglongjmp () from /lib/tls/i686/cmov/libc.so.6 > #1 0x577b2a84 in ?? () > Cannot access memory at address 0xd7a0906f > (m3gdb) quit > > > stock gdb gives even less information: > > rodney at yellowstone:~/proj/m3/exp/FmtBug/src$ gdb cm3- > GNU gdb (GDB) 7.1-ubuntu > Copyright (C) 2010 Free Software Foundation, Inc. > License GPLv3+: GNU GPL version 3 or later > This is free software: you are free to change and redistribute it. > There is NO WARRANTY, to the extent permitted by law. Type "show copying" > and "show warranty" for details. > This GDB was configured as "i486-linux-gnu". > For bug reporting instructions, please see: > ... > Reading symbols from /usr/local/cm3-githead/bin/cm3-...done. > (gdb) run > Starting program: /usr/local/cm3-githead/bin/cm3- > [Thread debugging using libthread_db enabled] > > Program received signal SIGSEGV, Segmentation fault. > 0x0032e26f in ?? () from /lib/tls/i686/cmov/libc.so.6 > (gdb) bt > #0 0x0032e26f in ?? () from /lib/tls/i686/cmov/libc.so.6 > #1 0xfb35d04b in ?? () > Cannot access memory at address 0x7bee2da0 > (gdb) > > Note that gdb gives a different address in the same library for the point of fault. > > m3gdb claims it's in siglongjmp. I recall there were some recent changes involving > longjump. > > > > > > On 05/22/2016 09:28 PM, Peter McKinna wrote: > > I dont know what changed but the backend is crashing on linuxlibc6 when compiled with -O Try compiling m3core. > > > > Also some of my low level tests with Long.And and Long.Shift are not working with > > normal compile without the optimisations on that platform. Bit suspicious. I'm still investigating. > > > > Anyone got any clues or can replicate? > > > > Thanks 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 lists at darko.org Sat May 28 01:50:20 2016 From: lists at darko.org (Darko Volaric) Date: Sat, 28 May 2016 01:50:20 +0200 Subject: [M3devel] cm3cg failing on linuxlibc6 In-Reply-To: <574895CB.10200@lcwb.coop> References: <57434E93.2030205@lcwb.coop> <574895CB.10200@lcwb.coop> Message-ID: This, perhaps: https://github.com/modula3/cm3/issues/10 On Fri, May 27, 2016 at 8:45 PM, Rodney M. Bates wrote: > I got around this problem by setting Alloca_jmpbuf back to TRUE in > > m3-libs/m3core/src/runtime/ex_frame/RTExFrame.m3 and > m3-sys/m3middle/src/Target.m3 > > I am trying to remember, but as I recall, TRUE was failing on some other > platform, > and the change was reverted. But now FALSE is failing on LINUXLIBC6 and > TRUE > is working there. > > What do you remember about this, Jay? > > > > On 05/23/2016 01:40 PM, Rodney M. Bates wrote: > >> >> >> >> I did git pull and rebuilt on LINUXLIBC6. The built cm3 executable >> crashes compiling >> a very small experiment program: >> >> rodney at yellowstone:~/proj/m3/exp/FmtBug/src$ cm3- >> Segmentation fault (core dumped) >> >> m3gdb (after I built it) gives this: >> >> rodney at yellowstone:~/proj/m3/exp/FmtBug/src$ m3gdb cm3- >> GNU gdb plus Modula-3 6.4 >> Copyright 2005 Free Software Foundation, Inc. >> GDB is free software, covered by the GNU General Public License, and >> you are >> welcome to change it and/or distribute copies of it under certain >> conditions. >> Type "show copying" to see the conditions. >> There is absolutely no warranty for GDB. Type "show warranty" for >> details. >> This GDB was configured as "i686-pc-linux-gnu"...Using host >> libthread_db library "/lib/tls/i686/cmov/libthread_db.so.1". >> >> (m3gdb) run >> Starting program: /usr/local/cm3-githead/bin/cm3- >> [Thread debugging using libthread_db enabled] >> [New LWP 23615] >> [New Thread -1216829744 (LWP 23615)] >> >> Program received signal SIGSEGV, Segmentation fault. >> [Switching to Thread -1216829744 (LWP 23615)] >> 0x0037c26f in siglongjmp () from /lib/tls/i686/cmov/libc.so.6 >> (m3gdb) bt >> #0 0x0037c26f in siglongjmp () from /lib/tls/i686/cmov/libc.so.6 >> #1 0x577b2a84 in ?? () >> Cannot access memory at address 0xd7a0906f >> (m3gdb) quit >> >> >> stock gdb gives even less information: >> >> rodney at yellowstone:~/proj/m3/exp/FmtBug/src$ gdb cm3- >> GNU gdb (GDB) 7.1-ubuntu >> Copyright (C) 2010 Free Software Foundation, Inc. >> License GPLv3+: GNU GPL version 3 or later < >> http://gnu.org/licenses/gpl.html> >> This is free software: you are free to change and redistribute it. >> There is NO WARRANTY, to the extent permitted by law. Type "show >> copying" >> and "show warranty" for details. >> This GDB was configured as "i486-linux-gnu". >> For bug reporting instructions, please see: >> ... >> Reading symbols from /usr/local/cm3-githead/bin/cm3-...done. >> (gdb) run >> Starting program: /usr/local/cm3-githead/bin/cm3- >> [Thread debugging using libthread_db enabled] >> >> Program received signal SIGSEGV, Segmentation fault. >> 0x0032e26f in ?? () from /lib/tls/i686/cmov/libc.so.6 >> (gdb) bt >> #0 0x0032e26f in ?? () from /lib/tls/i686/cmov/libc.so.6 >> #1 0xfb35d04b in ?? () >> Cannot access memory at address 0x7bee2da0 >> (gdb) >> >> Note that gdb gives a different address in the same library for the point >> of fault. >> >> m3gdb claims it's in siglongjmp. I recall there were some recent changes >> involving >> longjump. >> >> >> >> >> >> On 05/22/2016 09:28 PM, Peter McKinna wrote: >> > I dont know what changed but the backend is crashing on linuxlibc6 >> when compiled with -O Try compiling m3core. >> > >> > Also some of my low level tests with Long.And and Long.Shift are not >> working with >> > normal compile without the optimisations on that platform. Bit >> suspicious. I'm still investigating. >> > >> > Anyone got any clues or can replicate? >> > >> > Thanks 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Tue May 31 08:52:05 2016 From: jay.krell at cornell.edu (Jay K) Date: Tue, 31 May 2016 06:52:05 +0000 Subject: [M3devel] old problem of new releases on old systems esp. Unix Message-ID: fyi..in the vein of really needing to release as C or asm instead of binaries, like the 3.6 system did: https://github.com/modula3/cm3/releases/download/verification-release-x86_64/cm3-bin-core-AMD64_LINUX-d5.9.0-x86_64-unknown-linux-gnu-2014-08-19-18-12-25.tgz % cm3 -versioncm3: /lib/libc.so.6: version `GLIBC_2.14' not found (required by cm3) on an older system: % uname -aLinux birch 2.6.26-2-amd64 #1 SMP Sun Mar 4 21:48:06 UTC 2012 x86_64 GNU/Linux or maybe do more investigation of gcc/ld switches to produce more compatible binaries.. ..just need to converge on what such a system really looks like in terms of build portability -- like cmake or autotools or extremely simple.. I have a bit of mental block getting anywhere on this. None of the C/C++ build systems quite do what I'd like and I haven't yet written my own.. (i.e. esp in terms of picking what is statically linked vs. what is dynamically linked).. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Tue May 31 09:32:23 2016 From: jay.krell at cornell.edu (Jay K) Date: Tue, 31 May 2016 07:32:23 +0000 Subject: [M3devel] replace build system?? Message-ID: Design of a new or bootstrap/cross/distribution build system? I'd really like our stuff to be as easy to distribute and develop as stuff using e.g. autotools or cmake. And as portable. And to reuse other people's work. And have a solid cross build story. And distribution be C or .o or .a or .S files, not executables and so/dylibs. i.e. I'd really like to get out of the build system business. like to just use autotools or cmake? But I suspect our system's qualities is difficult to replicate within the other frameworks. i.e. the incrementality The way every dynamic library is also available statically. Thoughts? For example, enable easier mixing of Modula-3 with C and C++ i.e. within one Makefile or such. Is it possible for Modula-3 to efficiently have the single source to single .o per invocation model? ?- Jay From hendrik at topoi.pooq.com Tue May 31 18:05:03 2016 From: hendrik at topoi.pooq.com (Hendrik Boom) Date: Tue, 31 May 2016 12:05:03 -0400 Subject: [M3devel] replace build system?? In-Reply-To: References: Message-ID: <20160531160502.GC12646@topoi.pooq.com> On Tue, May 31, 2016 at 07:32:23AM +0000, Jay K wrote: > Design of a new or bootstrap/cross/distribution build system? > > > I'd really like our stuff to be as easy to distribute and develop > as stuff using e.g. autotools or cmake. And as portable. > > > And to reuse other people's work. > > > And have a solid cross build story. > > > And distribution be C or .o or .a or .S files, not executables and so/dylibs. Isn't there an m3 compiler that generates C? Didn't you even write it? -- hendrik k From estellnb at elstel.org Tue May 31 18:35:06 2016 From: estellnb at elstel.org (Elmar Stellnberger) Date: Tue, 31 May 2016 18:35:06 +0200 Subject: [M3devel] replace build system?? In-Reply-To: References: Message-ID: Am 2016-05-31 um 09:32 schrieb Jay K: > i.e. I'd really like to get out of the build system business. > like to just use autotools or cmake? A make-based build solution would have other advantages as well like f.i. parallel build by make --jobs=4. That way CM3 could build up to four times faster. > But I suspect our system's qualities is difficult to replicate within the other frameworks. > i.e. the incrementality > The way every dynamic library is also available statically. > Why not employ a simple hand written make-file that determines that by environment variables? i.e. what libraries to build statically. From dmuysers at hotmail.com Tue May 31 18:39:16 2016 From: dmuysers at hotmail.com (dirk muysers) Date: Tue, 31 May 2016 18:39:16 +0200 Subject: [M3devel] The mailing list archive Message-ID: is still not available! -------------- next part -------------- An HTML attachment was scrubbed... URL: From dabenavidesd at yahoo.es Tue May 31 19:06:13 2016 From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.) Date: Tue, 31 May 2016 17:06:13 +0000 (UTC) Subject: [M3devel] replace build system?? In-Reply-To: References: Message-ID: <1784674298.4028093.1464714373116.JavaMail.yahoo@mail.yahoo.com> Hi Jay and all:I am searching options to make it easier (maybe tricking our selves) for new Modula-3 users explore our system.As I said recently, there is a java front end (just misses IRC type checking m3clipse) and there was FOSS "Scale compiler" backend written in Java, M3 DEC-SRC front end compatible (it generated Sparc, Alpha and Powerpc object code). An excerpt from The Common Language Encoding Form(Clef) Design Document: "For Modula-3, Scale uses the Digital Equipment Corporation(DEC) Systems Research Center (SRC) Modula-3 front end to generate an AST representation. M32CLEFreads the Modula-3 AST and uses the generation interface to convert it to Scale's high-level representation." [1] But anyway in my research found DEC was working just before sold to Compaq in an enriched type system, so I would prefer to let current compiler to do the job just in case we anyhow got their experimental type checker: "Modern programming languages, such as C++, Java, and Ada, include compile-time checks to detect a wide range of possible errors. The checks are based on declaring or inferring a type for each object (i.e., variables and procedures) and analyzing the program to establish that objects are used in ways consistent with their types. This kind of automated support is especially helpful for detecting the kinds of errors (such as passing arguments that overflow a corresponding parameter) so successfully used by attackers of operating system and network software. Ever more expressive type systems are a continuing theme in programming language research, with considerable attention being directed recently at the representation of security properties using types (Digital Equipment Corporation, 1997). Success would mean that compile-time checks could play an even bigger role in supporting trustworthiness properties. " [2] Thanks in advance for any comment [1]?Abstract?. [on line]. Available on en: ftp://ftp.cs.umass.edu/pub/osl/papers/clef97-abs.html. [Accessed: 31-may-2016]. [2]?Trust in Cyberspace?. [on line]. Available on: http://cryptome.org/tic.htm. [Accessed: 31-may-2016]. El Martes 31 de Mayo de 2016 11:35, Elmar Stellnberger escribi?: Am 2016-05-31 um 09:32 schrieb Jay K: > i.e. I'd really like to get out of the build system business. > like to just use autotools or cmake? A make-based build solution would have other advantages as well like f.i. parallel build by make --jobs=4. That way CM3 could build up to four times faster. > But I suspect our system's qualities is difficult to replicate within the other frameworks. > i.e. the incrementality > The way every dynamic library is also available statically. > ? Why not employ a simple hand written make-file that determines that by environment variables? i.e. what libraries to build statically. _______________________________________________ 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 mika at async.caltech.edu Tue May 31 19:16:05 2016 From: mika at async.caltech.edu (mika at async.caltech.edu) Date: Tue, 31 May 2016 10:16:05 -0700 Subject: [M3devel] replace build system?? In-Reply-To: <1784674298.4028093.1464714373116.JavaMail.yahoo@mail.yahoo.com> References: <1784674298.4028093.1464714373116.JavaMail.yahoo@mail.yahoo.com> Message-ID: <20160531171605.13AA61A2068@async.async.caltech.edu> I mentioned this before a few times on this mailing list.... CM3 is already fairly parallel if you turn on the right options. Every back-end invocation can be done in parallel. Set M3_PARALLEL_BACK in the config to 10 or 20 and watch it go... "Daniel Alejandro Benavides D." writes: ... >A make-based build solution would have other advantages as well like=20 >f.i. parallel build by make --jobs=3D4. That way CM3 could build up to=20 >four times faster. ... From jay.krell at cornell.edu Tue May 31 19:17:15 2016 From: jay.krell at cornell.edu (Jay K) Date: Tue, 31 May 2016 17:17:15 +0000 Subject: [M3devel] replace build system?? In-Reply-To: <20160531160502.GC12646@topoi.pooq.com> References: , <20160531160502.GC12646@topoi.pooq.com> Message-ID: Yes it is a backend within cm3, a peer of cm3cg and the integrated NT/x86 backend. I'd really like to move everyone from cm3cg to it. I tested it a bunch at least a while ago. There is still some scripting or such to make a distribution with it. Currently what is provided is enough to build cm3 and mklib from system-specific C. Statically linked. System-specific is hard to completely fix. Statically linked is normal for cm3/mklib anyway. It generates little Makefiles. Ideally the entire system would be distributed this way. Though merely distributing the cm3cg produced .s/.o/.a files would be an approvement. Everytime I look, I don't like cmake or autotools, nor want to keep maintaining our system-specific config files, nor have the time/energy to write something new in C or C++. ?- Jay ---------------------------------------- > Date: Tue, 31 May 2016 12:05:03 -0400 > From: hendrik at topoi.pooq.com > To: m3devel at elegosoft.com > Subject: Re: [M3devel] replace build system?? > > On Tue, May 31, 2016 at 07:32:23AM +0000, Jay K wrote: >> Design of a new or bootstrap/cross/distribution build system? >> >> >> I'd really like our stuff to be as easy to distribute and develop >> as stuff using e.g. autotools or cmake. And as portable. >> >> >> And to reuse other people's work. >> >> >> And have a solid cross build story. >> >> >> And distribution be C or .o or .a or .S files, not executables and so/dylibs. > > Isn't there an m3 compiler that generates C? Didn't you even write it? > > -- hendrik > k > _______________________________________________ > M3devel mailing list > M3devel at elegosoft.com > https://mail.elegosoft.com/cgi-bin/mailman/listinfo/m3devel From jay.krell at cornell.edu Tue May 31 19:18:46 2016 From: jay.krell at cornell.edu (Jay K) Date: Tue, 31 May 2016 17:18:46 +0000 Subject: [M3devel] replace build system?? In-Reply-To: <20160531171605.13AA61A2068@async.async.caltech.edu> References: , , <1784674298.4028093.1464714373116.JavaMail.yahoo@mail.yahoo.com>, <20160531171605.13AA61A2068@async.async.caltech.edu> Message-ID: We should probably learn how to get the number of processors and optionally system load and make this more automatic. Posix should standardize more of this. :( ?- Jay ---------------------------------------- > To: estellnb at elstel.org; jay.krell at cornell.edu; m3devel at elegosoft.com > To: dabenavidesd at yahoo.es > Date: Tue, 31 May 2016 10:16:05 -0700 > From: mika at async.caltech.edu > Subject: Re: [M3devel] replace build system?? > > I mentioned this before a few times on this mailing list.... CM3 is already fairly > parallel if you turn on the right options. Every back-end invocation can be done > in parallel. > > Set M3_PARALLEL_BACK in the config to 10 or 20 and watch it go... > > "Daniel Alejandro Benavides D." writes: > ... >>A make-based build solution would have other advantages as well like=20 >>f.i. parallel build by make --jobs=3D4. That way CM3 could build up to=20 >>four times faster. > ... > _______________________________________________ > M3devel mailing list > M3devel at elegosoft.com > https://mail.elegosoft.com/cgi-bin/mailman/listinfo/m3devel