From: Rainer T. <ta...@ta...> - 2008-12-29 14:12:14
|
Hello, one test is failing on AIX: 3734 - all OK 3823 - one failure Interpreter: REXX-ooRexx_4.0.0(MT) 6.03 29 Dec 2008 ooRexxUnit: 2.0.0_3.2.0 ooTest: 1.0.0_4.0.0 Tests ran: 18777 Assertions: 551082 Failures: 1 Errors: 0 Skipped files: 21 [failure] [20081229 14:57:00.475025] svn: r3813 Change date: 2008-12-27 19:20:06 +0100 Test: TEST_FLUSH_ON_CLOSE Class: Stream.testGroup File: /daten/svn/ooRexx/test/trunk/ooRexx/base/class/Stream.testGroup Line: 147 Failed: assertTrue Expected: [1] Actual: [[0], identityHash="105807830"] File search: 00:00:11.942046 Suite construction: 00:00:06.367430 Test execution: 00:05:48.641093 Total time: 00:06:12.177301 This test was updated. A simple say SysIsFile("tmpOutDelMe.txt"); is working. Bye Rainer |
From: Mark M. <mie...@gm...> - 2008-12-29 15:58:59
|
On Mon, Dec 29, 2008 at 6:12 AM, Rainer Tammer <ta...@ta...> wrote: > Hello, > one test is failing on AIX: Rainer, that looks to be some type of difference in the way SysIsFile() works on Unix. The assertation fails on Linux also. I'll fix it some time today. -- Mark Miesfeld |
From: Mark M. <mie...@gm...> - 2008-12-29 16:00:56
|
On Mon, Dec 29, 2008 at 7:58 AM, Mark Miesfeld <mie...@gm...> wrote: > On Mon, Dec 29, 2008 at 6:12 AM, Rainer Tammer <ta...@ta...> wrote: >> Hello, >> one test is failing on AIX: > > Rainer, that looks to be some type of difference in the way > SysIsFile() works on Unix. The assertation fails on Linux also. No, it's a capitalization thing. TMPOUTDELME.TXT ;-( -- Mark Miesfeld |
From: Rainer T. <ta...@ta...> - 2008-12-29 16:12:02
|
Hello, Mark Miesfeld wrote: > On Mon, Dec 29, 2008 at 7:58 AM, Mark Miesfeld <mie...@gm...> wrote: > >> On Mon, Dec 29, 2008 at 6:12 AM, Rainer Tammer <ta...@ta...> wrote: >> >>> Hello, >>> one test is failing on AIX: >>> >> Rainer, that looks to be some type of difference in the way >> SysIsFile() works on Unix. The assertation fails on Linux also. >> > > No, it's a capitalization thing. > > TMPOUTDELME.TXT ;-( > > Ahh, didn't catch this... As the date for the beta gets closer (??) I have to add a couple lines to the readme files... Currently gcc does not build ooRexx correctly on AIX. Should I add a check in the configure files and barf ?? The IBM XL C/C++ V9/V10 compiler can build ooRexx on AIX (but only with some special fixes which will be released next year). Is the 64 build supposed to work on Unix ?? > -- > Mark Miesfeld > > Bye Rainer > ------------------------------------------------------------------------------ > _______________________________________________ > Oorexx-devel mailing list > Oor...@li... > https://lists.sourceforge.net/lists/listinfo/oorexx-devel > > > |
From: Rick M. <obj...@gm...> - 2008-12-29 20:43:00
|
On Mon, Dec 29, 2008 at 11:12 AM, Rainer Tammer <ta...@ta...> wrote: > Hello, > > Mark Miesfeld wrote: > > On Mon, Dec 29, 2008 at 7:58 AM, Mark Miesfeld <mie...@gm...> wrote: > > > On Mon, Dec 29, 2008 at 6:12 AM, Rainer Tammer <ta...@ta...> wrote: > > > Hello, > one test is failing on AIX: > > > Rainer, that looks to be some type of difference in the way > SysIsFile() works on Unix. The assertation fails on Linux also. > > > No, it's a capitalization thing. > > TMPOUTDELME.TXT ;-( > > > > Ahh, didn't catch this... > > As the date for the beta gets closer (??) I have to add a couple lines to > the readme files... > > Currently gcc does not build ooRexx correctly on AIX. Should I add a check > in the configure files and barf ?? What are the issues with gcc? I think I'd prefer the config files not have negative checks like that, as it would make it more difficult for an ambitious soul from attempting it get it working. > The IBM XL C/C++ V9/V10 compiler can build ooRexx on AIX (but only with some > special fixes which will be released next year). > > Is the 64 build supposed to work on Unix ?? I know of no reasons why it wouldn't. It certainly works on Linux and has also been successfully built on Solaris. However, it might require some debugging to get it in to working shape by somebody with access to a given system. > > -- > Mark Miesfeld > > > > Bye > Rainer > > ------------------------------------------------------------------------------ > _______________________________________________ > Oorexx-devel mailing list > Oor...@li... > https://lists.sourceforge.net/lists/listinfo/oorexx-devel > > > > > ------------------------------------------------------------------------------ > > _______________________________________________ > Oorexx-devel mailing list > Oor...@li... > https://lists.sourceforge.net/lists/listinfo/oorexx-devel > > |
From: Mark M. <mie...@gm...> - 2008-12-29 20:53:58
|
On Mon, Dec 29, 2008 at 12:42 PM, Rick McGuire <obj...@gm...> wrote: > On Mon, Dec 29, 2008 at 11:12 AM, Rainer Tammer <ta...@ta...> wrote: >> Is the 64 build supposed to work on Unix ?? > > I know of no reasons why it wouldn't. It certainly works on Linux and > has also been successfully built on Solaris. However, it might > require some debugging to get it in to working shape by somebody with > access to a given system. Rick, Rainer's first problem was some contention with his 32-bit version. I think he still had the 32-bit rxapi daemon running. With that out of the way he gets a core dump when rexximage runs. I was going to forward his e-mail to the list, but instead I just copy-pasted it in below: after I have moved the 32 bit build away (and killd rxapi) I get this: /daten/svn/ooRexx/main64/trunk/.libs/lt-rexximage -> core (the 64 bit rxapi is not yet build)... dbx /daten/svn/ooRexx/main64/trunk/.libs/lt-rexximage Type 'help' for help. [using memory image in core] reading symbolic information ... Illegal instruction (illegal opcode) in . at 0x0 ($t1) warning: Unable to access address 0x0 from core (dbx) where .() at 0x0 RexxMemory::markObjectsMain(RexxObject*)(this = 0x09001000a027c6f8, rootObject = 0x09001000a027c6f8), line 368 in "RexxMemory.cpp" RexxMemory::markObjects()(this = 0x09001000a027c6f8), line 617 in "RexxMemory.cpp" RexxMemory::collect()(this = 0x09001000a027c6f8), line 993 in "RexxMemory.cpp" NormalSegmentSet::handleAllocationFailure(unsigned long)(this = 0x09001000a027c840, allocationLength = 2304), line 1269 in "MemorySegment.cpp" RexxMemory.RexxMemory::newObject(unsigned long,unsigned long)(this = 0x09001000a027c6f8, requestLength = 2304, type = 0), line 1074 in "RexxMemory.cpp" ArrayClass.newObject(unsigned long)(0x9001000a027c6f8, 0x900), line 185 in "RexxMemory.hpp" ArrayClass.new_object(unsigned long)(0x900), line 415 in "RexxMemory.hpp" clone()(this = 0x0000000110058458), line 2170 in "ObjectClass.cpp" RexxInternalObject::copy()(this = 0x0000000110058458), line 487 in "ObjectClass.cpp" copy()(this = 0x000000011019ef10), line 128 in "RexxCollection.cpp" unnamed block in methodDictionaryMerge(RexxTable*)(this = 0x0000000110249108, sourceDictionary = 0x000000011025b2a8), line 710 in "RexxBehaviour.cpp" methodDictionaryMerge(RexxTable*)(this = 0x0000000110249108, sourceDictionary = 0x000000011025b2a8), line 710 in "RexxBehaviour.cpp" createClassBehaviour(RexxBehaviour*)(this = 0x0000000110173140, target_class_behaviour = 0x0000000110249108), line 844 in "ClassClass.cpp" updateSubClasses()(this = 0x0000000110173140), line 745 in "ClassClass.cpp" unnamed block in updateSubClasses()(this = 0x00000001100637c0), line 755 in "ClassClass.cpp" updateSubClasses()(this = 0x00000001100637c0), line 755 in "ClassClass.cpp" inherit(RexxClass*,RexxClass*)(this = 0x00000001100637c0, mixin_class = 0x0000000110248ff8, position = (nil)), line 1066 in "ClassClass.cpp" RexxMemory::createImage()(), line 1407 in "Setup.cpp" RexxMemory::initialize(bool)(this = 0x09001000a027c6f8, _restoringImage = false), line 222 in "RexxMemory.cpp" startInterpreter(Interpreter::InterpreterStartupMode)(mode = SAVE_IMAGE_MODE), line 135 in "Interpreter.cpp" RexxCreateInterpreterImage(), line 96 in "InterpreterAPI.cpp" main(argc = 1, argv = 0x0ffffffffffff850), line 44 in "rexximage.cpp" (dbx) If I build the 64 bit rxapi and start it prior to the image creation I get the same dump as above. |
From: Rainer T. <ta...@ta...> - 2009-01-02 09:10:57
|
Hello Rick, Rick McGuire wrote: > On Mon, Dec 29, 2008 at 11:12 AM, Rainer Tammer <ta...@ta...> wrote: > >> ... deleted for clarity ... >> >> Currently gcc does not build ooRexx correctly on AIX. Should I add a check >> in the configure files and barf ?? >> > > What are the issues with gcc? I think I'd prefer the config files not > have negative checks like that, as it would make it more difficult for > an ambitious soul from attempting it get it working. > > I can build ooRexx with gcc 4.2.4 (after small patch). g++ -DHAVE_CONFIG_H -I. -DORX_VER=4 -DORX_REL=0 -DORX_MOD=0 -DORX_FIX=0 -DORX_SYS_STR=\"AIX\" -DORX_CATDIR=\"/opt/ooRexx/bin\" -DORX_SHARED_LIBRARY_EXT=\".so\" -I./lib -I./api -I./api/platform/unix -g -O2 -g -O2 -maix32 -pthread -Wall -funsigned-char -Wpointer-arith -Wcast-qual -Wcast-align -Wshadow -Wwrite-strings -D__cplusplus -Wredundant-decls -DNOOPT -DPTHREAD_KERNEL -D_POSIX_THREAD -D_REENTRANT -D_GNU_SOURCE -DOPSYS_AIX43 -DAIX -DOPSYS_AIX -MT librxmath_la-rxmath.lo -MD -MP -MF .deps/librxmath_la-rxmath.Tpo -c ./extensions/rxmath/rxmath.cpp -DPIC -o .libs/librxmath_la-rxmath.o In file included from /usr/include/sys/ptrace.h:28, from /usr/include/sys/proc.h:48, from /usr/include/sys/pri.h:43, from /usr/include/sys/sched.h:38, from /usr/include/sched.h:51, from /usr/include/pthread.h:64, from ./api/platform/unix/rexxapitypes.h:49, from ./api/rexx.h:65, from ./api/oorexxapi.h:47, from ./extensions/rxmath/rxmath.cpp:98: ./extensions/rxmath/rxmath.cpp:70: error: previous declaration of 'int errno' with 'C++' linkage /usr/include/sys/thread.h:852: error: conflicts with new declaration with 'C' linkage gmake[2]: *** [librxmath_la-rxmath.lo] Error 1 gmake[2]: Leaving directory `/daten/source/ooRexx/gcc/trunk' gmake[1]: *** [all-recursive] Error 1 gmake[1]: Leaving directory `/daten/source/ooRexx/gcc/trunk' gmake: *** [all] Error 2 So I have changed this to: rxmath.cpp: #ifdef __cplusplus extern "C" { #endif extern int errno; #ifdef __cplusplus } #endif The images gets created and some basic tests work OK. Working: ====== usepipe.rex usecomp.rex stack.rex rexxcps.rex qtime.rex qdate.rex ccreply.rex factor.rex Error: ==== properties.rex -------------- Error deleting the existing properties file. RC: 87 terminate called after throwing an instance of 'RexxNativeActivation*' ,, this looks thread related: core dump (no full traceback for gcc avail): pthread_k 88 ?? _p_raise 8C raise 30 abort B8 greply.rex ---------- sometimes strange output: Using GUARDED method to wait until sum is complete: Inside method sum_up: loop iteration 1000 Inside method sum_up: loop iteration 2000 Inside method sum_up: loop iteration 3000 Inside method sum_up: loop iteration 4000 Inside method sum_up: loop iteration 5000 Result should be 12502500: 12502500 Using UNGUARDED method to obtain an intermediate result: Inside method sum_up: loop iteration 1000 Result should be less than 12502500: 1943406 Inside method sum_up: loop iteration 2000 or Using GUARDED method to wait until sum is complete: Inside method sum_up: loop iteration 1000 Inside method sum_up: loop iteration 2000 Inside method sum_up: loop iteration 3000 Inside method sum_up: loop iteration 4000 Inside method sum_up: loop iteration 5000 Result should be 12502500: 12502500 Using UNGUARDED method to obtain an intermediate result: Inside method sum_up: loop iteration 1000 Inside method sum_up: loop iteration 2000 Inside method sum_up: loop iteration 3000 Inside method sum_up: loop iteration 4000 Inside method sum_up: loop iteration 5000 Result should be less than 12502500: 12502500 sfserver.rex ------------- Press [Enter] To Shutdown terminate called after throwing an instance of 'RexxNativeActivation*' (with core dump) The AIX g++ port is not known to be perfect... So I think I will change configure.ac: case "$target" in *ibm-aix*) GENERIC_OS="-DAIX" GENERIC_OPSYS="-DOPSYS_AIX" GENERIC_DEFINES="$GENERIC_DEFINES -DOPSYS_AIX43" # ORX_SHARED_LIBRARY_EXT=".a" case "$CXX" in # g++) # CC_WARNINGS="-maix32 -pthread $GCC_WARNINGS" # CXX_WARNINGS="-maix32 -pthread $GCXX_WARNINGS" # ;; xlC_r) CC_WARNINGS="$XLC_WARNINGS" CXX_WARNINGS="$XLCXX_WARNINGS" ORX_LDFLAGS_PACKAGE="" ORX_INIT_LDFLAGS="-Wl,-binitfini:_init:_fini" ;; *) AC_MSG_ERROR("Compiler $CXX is not supported on this platform") ;; esac Is this OK ?? Bye Rainer |
From: Rainer T. <ta...@ta...> - 2008-12-30 07:16:27
|
Hello, Mark Miesfeld wrote: > Hi Rainer, > > I passed this on to Rick on the developer list. > > It seems similar to some problems we first had to debug on 64-bit. > Because values like pointer are bigger in size, it increases the size > of objects that ooRexx is managing. This was causing new objects to > be bigger than was allotted for them. Which in turn overwrote memory. > It is an area in the interpreter I do not understand well (among many > areas.) Much better then I do :-)) I only "maintain" the AIX build because I still have Rexx programs running and nobody else volunteered... Yes, it is possible that through different alignment schemas a bigger memory chunk is needed. I think this problem is not related to little/big endian issues. > It will probably have to be solved by Rick. > > We'll see if he comes back with some things for you to try. Don't be > discouraged if we don't hear much from him right away, he seems to be > very busy lately. > I can empathize with him.Currently I am very busy myself too. > As for rxapi. I also have a lot of trouble trying to build on SuSE. > I have to be very careful to be sure there are no rxapi processes from > a previous build lingering around. (This is just on 32-bit.) For > some reason, it does not seem to be a problem on Fedora. My > suggestion there is just what you did, be sure the 32-bit ooRexx is > not interfering when you try to build 64-bit. > > Very strange. Which libc version is used on SuSE / Fedorea ?? > -- > Mark Miesfeld > Bye Rainer > On Mon, Dec 29, 2008 at 8:44 AM, Rainer Tammer <ta...@ta...> wrote: > >> Hello, >> after I have moved the 32 bit build away (and killd rxapi) I get this: >> >> /daten/svn/ooRexx/main64/trunk/.libs/lt-rexximage -> core (the 64 bit >> rxapi is not yet build)... >> >> dbx /daten/svn/ooRexx/main64/trunk/.libs/lt-rexximage >> Type 'help' for help. >> [using memory image in core] >> reading symbolic information ... >> >> Illegal instruction (illegal opcode) in . at 0x0 ($t1) >> warning: Unable to access address 0x0 from core >> (dbx) where >> .() at 0x0 >> RexxMemory::markObjectsMain(RexxObject*)(this = 0x09001000a027c6f8, >> rootObject = 0x09001000a027c6f8), line 368 in "RexxMemory.cpp" >> RexxMemory::markObjects()(this = 0x09001000a027c6f8), line 617 in >> "RexxMemory.cpp" >> RexxMemory::collect()(this = 0x09001000a027c6f8), line 993 in >> "RexxMemory.cpp" >> NormalSegmentSet::handleAllocationFailure(unsigned long)(this = >> 0x09001000a027c840, allocationLength = 2304), line 1269 in >> "MemorySegment.cpp" >> RexxMemory.RexxMemory::newObject(unsigned long,unsigned long)(this = >> 0x09001000a027c6f8, requestLength = 2304, type = 0), line 1074 in >> "RexxMemory.cpp" >> ArrayClass.newObject(unsigned long)(0x9001000a027c6f8, 0x900), line 185 >> in "RexxMemory.hpp" >> ArrayClass.new_object(unsigned long)(0x900), line 415 in "RexxMemory.hpp" >> clone()(this = 0x0000000110058458), line 2170 in "ObjectClass.cpp" >> RexxInternalObject::copy()(this = 0x0000000110058458), line 487 in >> "ObjectClass.cpp" >> copy()(this = 0x000000011019ef10), line 128 in "RexxCollection.cpp" >> unnamed block in methodDictionaryMerge(RexxTable*)(this = >> 0x0000000110249108, sourceDictionary = 0x000000011025b2a8), line 710 in >> "RexxBehaviour.cpp" >> methodDictionaryMerge(RexxTable*)(this = 0x0000000110249108, >> sourceDictionary = 0x000000011025b2a8), line 710 in "RexxBehaviour.cpp" >> createClassBehaviour(RexxBehaviour*)(this = 0x0000000110173140, >> target_class_behaviour = 0x0000000110249108), line 844 in "ClassClass.cpp" >> updateSubClasses()(this = 0x0000000110173140), line 745 in "ClassClass.cpp" >> unnamed block in updateSubClasses()(this = 0x00000001100637c0), line 755 >> in "ClassClass.cpp" >> updateSubClasses()(this = 0x00000001100637c0), line 755 in "ClassClass.cpp" >> inherit(RexxClass*,RexxClass*)(this = 0x00000001100637c0, mixin_class = >> 0x0000000110248ff8, position = (nil)), line 1066 in "ClassClass.cpp" >> RexxMemory::createImage()(), line 1407 in "Setup.cpp" >> RexxMemory::initialize(bool)(this = 0x09001000a027c6f8, _restoringImage >> = false), line 222 in "RexxMemory.cpp" >> startInterpreter(Interpreter::InterpreterStartupMode)(mode = >> SAVE_IMAGE_MODE), line 135 in "Interpreter.cpp" >> RexxCreateInterpreterImage(), line 96 in "InterpreterAPI.cpp" >> main(argc = 1, argv = 0x0ffffffffffff850), line 44 in "rexximage.cpp" >> (dbx) >> >> If I build the 64 bit rxapi and start it prior to the image creation I >> get the same dump as above. >> >> Bye >> Rainer >> >> > > > |
From: Rainer T. <ta...@ta...> - 2008-12-30 07:56:21
|
Hello, there is one problem with the 64 bit build on AIX... it was not a 64 bit build... I need to explain this a bit. __WORDSIZE is not defined in AIX -> so in rexxapitypes.h __REXX64__ never gets defined ==> no go - crash - boom If I feed -D__WORDSIZE=64 to configure then I get the following make error: xlC_r -DHAVE_CONFIG_H -I. -DORX_VER=4 -DORX_REL=0 -DORX_MOD=0 -DORX_FIX=0 -DORX_SYS_STR=\"AIX\" -DORX_CATDIR=\"/opt/ooRexx/bin\" -DORX_SHARED_LIBRARY_EXT=\".so\" -I./lib -I./api -I./api/platform/unix -I./common -I./common/platform/unix -I./interpreter -I./interpreter/behaviour -I./interpreter/execution -I./interpreter/memory -I./interpreter/package -I./interpreter/concurrency -I./interpreter/expression -I./interpreter/instructions -I./interpreter/classes -I./interpreter/classes/support -I./interpreter/runtime -I./interpreter/parser -I./interpreter/messages -I./interpreter/streamLibrary -I./interpreter/platform/common -I./interpreter/platform/unix -g -D__WORDSIZE=64 -+ -qchars=unsigned -qnodigraph -DNOOPT -DPTHREAD_KERNEL -D_POSIX_THREAD -D_REENTRANT -D_GNU_SOURCE -DOPSYS_AIX43 -DAIX -DOPSYS_AIX -c -M ./interpreter/runtime/Numerics.cpp -DPIC -o .libs/librexx_la-Numerics.o "./interpreter/runtime/Numerics.cpp", line 53.49: 1540-0274 (S) The name lookup for "__INT64_C" did not find a declaration. "./interpreter/runtime/Numerics.cpp", line 54.49: 1540-0274 (S) The name lookup for "__INT64_C" did not find a declaration. "./interpreter/runtime/Numerics.cpp", line 55.46: 1540-0274 (S) The name lookup for "__INT64_C" did not find a declaration. "./interpreter/runtime/Numerics.cpp", line 56.46: 1540-0274 (S) The name lookup for "__INT64_C" did not find a declaration. gmake: *** [librexx_la-Numerics.lo] Error 1 ==> __INT64_C does not work on AIX I can use limits.h on AIX: #ifdef __64BIT__ #define LONG_MAX (9223372036854775807L) #define LONG_MIN (-LONG_MAX - 1) ... Is this what you have intended ? So I changed Numerics.cpp #ifdef __REXX64__ #ifdef AIX const wholenumber_t Numerics::MAX_WHOLENUMBER = LONG_MAX; const wholenumber_t Numerics::MIN_WHOLENUMBER = LONG_MIN; const wholenumber_t Numerics::MAX_EXPONENT = LONG_MAX; const wholenumber_t Numerics::MIN_EXPONENT = LONG_MIN; #else ... With this patch I can create the image and 64 bit rexx is working on AIX. The samples + callrex1 / callrexx2 are working fine. I still have to run the test suite. So now I have to prepare (a more polished) patch. Bye Rainer |
From: Rainer T. <ta...@ta...> - 2008-12-30 08:11:05
Attachments:
testOORexx-3828_64.log
|
Hello, the test suite shows some errors. Probably my assumption for the MAX_WHOLENUMBER / MIN_WHOLENUMBER ... was not correct (or the test suite is not jet 64 bit aware). I have attached the log of the test suite run. The following test fails because the precession is higher: [failure] [20081230 08:54:11.317357] svn: r3573 Change date: 2008-10-19 00:16:29 +0200 Test: TESTFLOAT01 Class: METHOD.testGroup File: /daten/svn/ooRexx/test/trunk/ooRexx/API/oo/METHOD.testGroup Line: 658 Failed: assertSame Expected: [[3.40282347E+38], identityHash="571618120"] Actual: [[3.4028234663852886E+38], identityHash="594021920"] ... Bye Rainer |
From: Rainer T. <ta...@ta...> - 2008-12-30 08:44:22
|
Hello, with the following patch the test suite is almost successfully: Index: interpreter/runtime/Numerics.cpp =================================================================== --- interpreter/runtime/Numerics.cpp<-->(revision 3828) +++ interpreter/runtime/Numerics.cpp<-->(working copy) @@ -50,6 +50,9 @@ #include <limits.h> . #ifdef __REXX64__ +#ifndef __INT64_C +# define __INT64_C(c) c ## L +#endif const wholenumber_t Numerics::MAX_WHOLENUMBER = __INT64_C(999999999999999999); const wholenumber_t Numerics::MIN_WHOLENUMBER = __INT64_C(-999999999999999999); const wholenumber_t Numerics::MAX_EXPONENT = __INT64_C(999999999999999999); configure is called with: export CC=xlc_r export CXX=xlC_r export LDFLAGS="-Wl,-brtl" export OBJECT_MODE=64 export CFLAGS="-D__WORDSIZE=64" ----------- failures -------------------- Interpreter: REXX-ooRexx_4.0.0(MT) 6.03 30 Dec 2008 ooRexxUnit: 2.0.0_3.2.0 ooTest: 1.0.0_4.0.0 Tests ran: 18777 Assertions: 551047 Failures: 3 Errors: 0 Skipped files: 21 [failure] [20081230 09:33:06.875724] svn: r3371 Change date: 2008-09-21 06:33:29 +0200 Test: TESTFLOAT01 Class: CONVERSION.testGroup File: /daten/svn/ooRexx/test/trunk/ooRexx/API/oo/CONVERSION.testGroup Line: 871 Failed: assertSame Expected: [[3.40282347E+38], identityHash="571635368"] Actual: [[3.4028234663852886E+38], identityHash="592371406"] [failure] [20081230 09:33:06.993658] svn: r3371 Change date: 2008-09-21 06:33:29 +0200 Test: TESTFLOAT01 Class: FUNCTION.testGroup File: /daten/svn/ooRexx/test/trunk/ooRexx/API/oo/FUNCTION.testGroup Line: 534 Failed: assertSame Expected: [[3.40282347E+38], identityHash="571733066"] Actual: [[3.4028234663852886E+38], identityHash="592579300"] [failure] [20081230 09:33:07.112455] svn: r3573 Change date: 2008-10-19 00:16:29 +0200 Test: TESTFLOAT01 Class: METHOD.testGroup File: /daten/svn/ooRexx/test/trunk/ooRexx/API/oo/METHOD.testGroup Line: 658 Failed: assertSame Expected: [[3.40282347E+38], identityHash="571618120"] Actual: [[3.4028234663852886E+38], identityHash="592796862"] File search: 00:00:17.331969 Suite construction: 00:00:06.779225 Test execution: 00:06:15.617452 Total time: 00:06:44.572291 All three failures are caused by a higher precession. Bye Rainer |
From: Rainer T. <ta...@ta...> - 2008-12-30 13:02:00
Attachments:
ooRexx-3828_64-V2.patch
|
Hello, with the following build options: export CC=xlc_r export CXX=xlC_r export LDFLAGS="-Wl,-brtl" export OBJECT_MODE=64 ./configure --disable-static make and the following patch (attached as patch file) Index: interpreter/runtime/Numerics.cpp =================================================================== --- interpreter/runtime/Numerics.cpp (revision 3828) +++ interpreter/runtime/Numerics.cpp (working copy) @@ -50,6 +50,9 @@ #include <limits.h> #ifdef __REXX64__ +#ifndef __INT64_C +# define __INT64_C(c) c ## L +#endif const wholenumber_t Numerics::MAX_WHOLENUMBER = __INT64_C(999999999999999999); const wholenumber_t Numerics::MIN_WHOLENUMBER = __INT64_C(-999999999999999999); const wholenumber_t Numerics::MAX_EXPONENT = __INT64_C(999999999999999999); Index: api/platform/unix/rexxapitypes.h =================================================================== --- api/platform/unix/rexxapitypes.h (revision 3828) +++ api/platform/unix/rexxapitypes.h (working copy) @@ -48,7 +48,8 @@ #include <limits.h> #include <pthread.h> -#if __WORDSIZE == 64 +// AIX does not define __WORDSIZE, use __64BIT__ instead +#if __WORDSIZE == 64 || defined(__64BIT__) #define __REXX64__ #else #undef __REXX64__ ooRexx 4.0.0 can be build on AIX as 64 bit executable. I have tried to make the patch as small as possible. Any comments ? I would like to see a small change to rexx -v: Current version: Open Object Rexx Version 4.0.0 Build date: Dec 30 2008 Copyright (c) IBM Corporation 1995, 2004. Copyright (c) RexxLA 2005-2008. All Rights Reserved. This program and the accompanying materials are made available under the terms of the Common Public License v1.0 which accompanies this distribution. http://www.oorexx.org/license.html Syntax is "rexx [-v] filename [arguments]" or "rexx [-e] program_string [arguments]". Proposed version: Open Object Rexx Version 4.0.0 Build date: Dec 30 2008 Bit mode: 64 <- see here (or 32) Copyright (c) IBM Corporation 1995, 2004. Copyright (c) RexxLA 2005-2008. All Rights Reserved. This program and the accompanying materials are made available under the terms of the Common Public License v1.0 which accompanies this distribution. http://www.oorexx.org/license.html Syntax is "rexx [-v] filename [arguments]" or "rexx [-e] program_string [arguments]". So that it is easier to distinguish the binaries. What do you think ? Bye Rainer |
From: Mark M. <mie...@gm...> - 2008-12-30 15:24:11
|
Hi Rainer, On Tue, Dec 30, 2008 at 5:02 AM, Rainer Tammer <ta...@ta...> wrote: > Index: interpreter/runtime/Numerics.cpp > =================================================================== > --- interpreter/runtime/Numerics.cpp (revision 3828) > +++ interpreter/runtime/Numerics.cpp (working copy) > @@ -50,6 +50,9 @@ > #include <limits.h> > > #ifdef __REXX64__ > +#ifndef __INT64_C > +# define __INT64_C(c) c ## L > +#endif > const wholenumber_t Numerics::MAX_WHOLENUMBER = > __INT64_C(999999999999999999); > const wholenumber_t Numerics::MIN_WHOLENUMBER = > __INT64_C(-999999999999999999); > const wholenumber_t Numerics::MAX_EXPONENT = __INT64_C(999999999999999999); > Index: api/platform/unix/rexxapitypes.h > =================================================================== > --- api/platform/unix/rexxapitypes.h (revision 3828) > +++ api/platform/unix/rexxapitypes.h (working copy) > @@ -48,7 +48,8 @@ > #include <limits.h> > #include <pthread.h> > > -#if __WORDSIZE == 64 > +// AIX does not define __WORDSIZE, use __64BIT__ instead > +#if __WORDSIZE == 64 || defined(__64BIT__) > #define __REXX64__ > #else > #undef __REXX64__ > > Any comments ? If __WORDSIZE and __INT64_C are not defined on AIX, those 2 changes seem okay to me. We'll see what Rick thinks. > I would like to see a small change to rexx -v: I would also like to see some type of change here. On 64-bit windows, 32-bit binaries also run. I'd like to be able to tell from the command line which binary, 32-bit or 64-bit, was getting invoked. > Proposed version: > > Open Object Rexx Version 4.0.0 > Build date: Dec 30 2008 > Bit mode: 64 <- see here (or 32) > Copyright (c) IBM Corporation 1995, 2004. > Copyright (c) RexxLA 2005-2008. > All Rights Reserved. > This program and the accompanying materials > are made available under the terms of the Common Public License v1.0 > which accompanies this distribution. > http://www.oorexx.org/license.html > Syntax is "rexx [-v] filename [arguments]" > or "rexx [-e] program_string [arguments]". I know that part of that format is dictated by the standard, but not how much. Again, Rick is the expert. I personally would rather see: Open Object Rexx Version 4.0.0 (64-bit) Build date: Dec 30 2008 Copyright (c) IBM Corporation 1995, 2004. Copyright (c) RexxLA 2005-2008. But, I'm not sure if the above fits the standard. Below would be my second pick: Open Object Rexx Version 4.0.0 Build date: Dec 30 2008 (64-bit) Copyright (c) IBM Corporation 1995, 2004. Copyright (c) RexxLA 2005-2008. -- Mark Miesfeld |
From: Rainer T. <ta...@ta...> - 2008-12-30 18:04:35
|
Hello, >> I would like to see a small change to rexx -v: >> > > I would also like to see some type of change here. On 64-bit windows, > 32-bit binaries also run. I'd like to be able to tell from the > command line which binary, 32-bit or 64-bit, was getting invoked. > > >> Proposed version: >> >> Open Object Rexx Version 4.0.0 >> Build date: Dec 30 2008 >> Bit mode: 64 <- see here (or 32) >> Copyright (c) IBM Corporation 1995, 2004. >> Copyright (c) RexxLA 2005-2008. >> All Rights Reserved. >> This program and the accompanying materials >> are made available under the terms of the Common Public License v1.0 >> which accompanies this distribution. >> http://www.oorexx.org/license.html >> Syntax is "rexx [-v] filename [arguments]" >> or "rexx [-e] program_string [arguments]". >> > > I know that part of that format is dictated by the standard, but not > how much. Again, Rick is the expert. I personally would rather see: > > Open Object Rexx Version 4.0.0 (64-bit) > Build date: Dec 30 2008 > Copyright (c) IBM Corporation 1995, 2004. > Copyright (c) RexxLA 2005-2008. > > But, I'm not sure if the above fits the standard. Below would be my > second pick: > > Open Object Rexx Version 4.0.0 > Build date: Dec 30 2008 (64-bit) > Copyright (c) IBM Corporation 1995, 2004. > Copyright (c) RexxLA 2005-2008. > > Both versions look good to me. My suggestion was based on the fact that I did not want to brake the format of the existing lines. If someone parses the text then an extra line is less intrusive... > -- > Mark Miesfeld > > > Bye Rainer |
From: Mark M. <mie...@gm...> - 2008-12-30 15:45:23
|
On Tue, Dec 30, 2008 at 7:30 AM, Rick McGuire <obj...@gm...> wrote: > There's no standard for what "rexx -v" returns, so we have a lot of > freedom here. I'm not sure I like the parenthetical form. The word > size is not really a modifier of the version number, but an attribute > of its own. Okay. > I do think it would be a good idea to include the > information though. Yeah, I do too. I was going for less lines, but an extra line is fine. -- Mark Miesfeld |
From: Rainer T. <ta...@ta...> - 2008-12-30 18:08:25
|
Hello, should I prepare a new patch an post it to the tarcker or is this sufficient ?? api/platform/unix/rexxapitypes.h ?? // AIX does not define __WORDSIZE, use __64BIT__ instead #if __WORDSIZE == 64 || defined(__64BIT__) #define __REXX64__ #else #undef __REXX64__ #endif // AIX (and maybe others) needs a little help here #ifdef __REXX64__ #ifndef __INT64_C #define __INT64_C(c) c ## L #endif #else #ifndef __INT64_C #define __INT64_C(c) c ## LL #endif #endif Bye Rainer |
From: Mark M. <mie...@gm...> - 2008-12-30 18:34:32
|
Rainer, I just took your input below and committed a change. Thanks for tracking this down and thanks a lot for doing the AIX builds. I don't know who else would get access to an AIX system. -- Mark Miesfeld On Tue, Dec 30, 2008 at 10:08 AM, Rainer Tammer <ta...@ta...> wrote: > Hello, > should I prepare a new patch an post it to the tarcker or is this > sufficient ?? > > api/platform/unix/rexxapitypes.h ?? > > // AIX does not define __WORDSIZE, use __64BIT__ instead > #if __WORDSIZE == 64 || defined(__64BIT__) > #define __REXX64__ > #else > #undef __REXX64__ > #endif > > // AIX (and maybe others) needs a little help here > #ifdef __REXX64__ > #ifndef __INT64_C > #define __INT64_C(c) c ## L > #endif > #else > #ifndef __INT64_C > #define __INT64_C(c) c ## LL > #endif > #endif > > > Bye > Rainer > > > ------------------------------------------------------------------------------ > _______________________________________________ > Oorexx-devel mailing list > Oor...@li... > https://lists.sourceforge.net/lists/listinfo/oorexx-devel > |
From: Rainer T. <ta...@ta...> - 2008-12-30 19:15:45
|
Hello, there is a little problem with the patch... You have unfortunately used the 32 bit part (with the LL): // AIX (and maybe others) needs a little help here #ifdef __REXX64__ #ifndef __INT64_C #define __INT64_C(c) c ## L <----- this is the 64 bit version #endif #else #ifndef __INT64_C #define __INT64_C(c) c ## LL <------ this is the 32 bit version #endif #endif Could you please use the above or just this #ifdef __REXX64__ #ifndef __INT64_C #define __INT64_C(c) c ## L <----- this is the 64 bit version #endif #endif I have opened artifact 2477577 for that. I think the limitation to __REXX64__ is necessary as this version is only for 64 bit. The 32 bit version is different (see above). If you like to add this to rexxplatformdefs.h then it is important that rexxplatformdefs.h is always included after rexxapitypes.h. I think rexxapitypes.h would be a safer place. bye Rainer Mark Miesfeld wrote: > Rainer, > > I just took your input below and committed a change. Thanks for > tracking this down and thanks a lot for doing the AIX builds. I don't > know who else would get access to an AIX system. > > -- > Mark Miesfeld > > On Tue, Dec 30, 2008 at 10:08 AM, Rainer Tammer <ta...@ta...> wrote: > >> Hello, >> should I prepare a new patch an post it to the tarcker or is this >> sufficient ?? >> >> api/platform/unix/rexxapitypes.h ?? >> >> // AIX does not define __WORDSIZE, use __64BIT__ instead >> #if __WORDSIZE == 64 || defined(__64BIT__) >> #define __REXX64__ >> #else >> #undef __REXX64__ >> #endif >> >> // AIX (and maybe others) needs a little help here >> #ifdef __REXX64__ >> #ifndef __INT64_C >> #define __INT64_C(c) c ## L >> #endif >> #else >> #ifndef __INT64_C >> #define __INT64_C(c) c ## LL >> #endif >> #endif >> >> >> Bye >> Rainer >> >> >> ------------------------------------------------------------------------------ >> _______________________________________________ >> Oorexx-devel mailing list >> Oor...@li... >> https://lists.sourceforge.net/lists/listinfo/oorexx-devel >> >> > > ------------------------------------------------------------------------------ > _______________________________________________ > Oorexx-devel mailing list > Oor...@li... > https://lists.sourceforge.net/lists/listinfo/oorexx-devel > > > |
From: Mark M. <mie...@gm...> - 2008-12-30 19:38:36
|
On Tue, Dec 30, 2008 at 11:15 AM, Rainer Tammer <ta...@ta...> wrote: > there is a little problem with the patch... > You have unfortunately used the 32 bit part (with the LL): > #ifndef __INT64_C > > #define __INT64_C(c) c ## L <----- this is the 64 bit version Sorry, I wasn't thinking. I'll change that. > I think the limitation to __REXX64__ is necessary as this version is only > for 64 bit. I don't think it is necessary because the actual use of __INT64_C is already wrapped with ifdef __REXX64__. > If you like to add this to rexxplatformdefs.h then it is important that > rexxplatformdefs.h is > always included after rexxapitypes.h. It is always included after rexxapitypes.h > I think rexxapitypes.h would be a > safer place. Rick is the ultimate decider on where things should go. It wouldn't be the first time I put something in the wrong place. <grin> If he thinks it should be moved, then I will. I put it there because: 1.) It is not a type. 2.) Windows uses the same define but with LL because on Windows 64-bit a long is still 32-bits so long long is correct. That makes the define a sort of platform specific define. Which in turn seems to dictate it should go in rexxplatformdefs.h -- Mark Miesfeld |
From: Rick M. <obj...@gm...> - 2008-12-30 19:46:19
|
If rexxplatformdefs.h is the location for the Windows version of this, then it's probably the most appropriate place for the *ix equivalent. Rick On Tue, Dec 30, 2008 at 2:38 PM, Mark Miesfeld <mie...@gm...> wrote: > On Tue, Dec 30, 2008 at 11:15 AM, Rainer Tammer <ta...@ta...> wrote: > >> there is a little problem with the patch... >> You have unfortunately used the 32 bit part (with the LL): > >> #ifndef __INT64_C >> >> #define __INT64_C(c) c ## L <----- this is the 64 bit version > > Sorry, I wasn't thinking. I'll change that. > >> I think the limitation to __REXX64__ is necessary as this version is only >> for 64 bit. > > I don't think it is necessary because the actual use of __INT64_C is > already wrapped with ifdef __REXX64__. > >> If you like to add this to rexxplatformdefs.h then it is important that >> rexxplatformdefs.h is >> always included after rexxapitypes.h. > > It is always included after rexxapitypes.h > >> I think rexxapitypes.h would be a >> safer place. > > Rick is the ultimate decider on where things should go. It wouldn't > be the first time I put something in the wrong place. <grin> > > If he thinks it should be moved, then I will. I put it there because: > 1.) It is not a type. 2.) Windows uses the same define but with LL > because on Windows 64-bit a long is still 32-bits so long long is > correct. That makes the define a sort of platform specific define. > Which in turn seems to dictate it should go in rexxplatformdefs.h > > -- > Mark Miesfeld > > ------------------------------------------------------------------------------ > _______________________________________________ > Oorexx-devel mailing list > Oor...@li... > https://lists.sourceforge.net/lists/listinfo/oorexx-devel > |
From: Rainer T. <ta...@ta...> - 2008-12-30 20:17:56
|
Hello, Rick McGuire wrote: > If rexxplatformdefs.h is the location for the Windows version of this, > then it's probably the most appropriate place for the *ix equivalent. > > sorry, I forgot to check the Windows version... The unix/rexxplatformdefs.h is good. I only have used the __REXX64__ to provide a __INT64_C suitable for 32 bit (even if currently not used). > Rick > Bye Rainer > On Tue, Dec 30, 2008 at 2:38 PM, Mark Miesfeld <mie...@gm...> wrote: > >> On Tue, Dec 30, 2008 at 11:15 AM, Rainer Tammer <ta...@ta...> wrote: >> >> >>> there is a little problem with the patch... >>> You have unfortunately used the 32 bit part (with the LL): >>> >>> #ifndef __INT64_C >>> >>> #define __INT64_C(c) c ## L <----- this is the 64 bit version >>> >> Sorry, I wasn't thinking. I'll change that. >> >> >>> I think the limitation to __REXX64__ is necessary as this version is only >>> for 64 bit. >>> >> I don't think it is necessary because the actual use of __INT64_C is >> already wrapped with ifdef __REXX64__. >> >> >>> If you like to add this to rexxplatformdefs.h then it is important that >>> rexxplatformdefs.h is >>> always included after rexxapitypes.h. >>> >> It is always included after rexxapitypes.h >> >> >>> I think rexxapitypes.h would be a >>> safer place. >>> >> Rick is the ultimate decider on where things should go. It wouldn't >> be the first time I put something in the wrong place. <grin> >> >> If he thinks it should be moved, then I will. I put it there because: >> 1.) It is not a type. 2.) Windows uses the same define but with LL >> because on Windows 64-bit a long is still 32-bits so long long is >> correct. That makes the define a sort of platform specific define. >> Which in turn seems to dictate it should go in rexxplatformdefs.h >> >> -- >> Mark Miesfeld >> >> ------------------------------------------------------------------------------ >> _______________________________________________ >> Oorexx-devel mailing list >> Oor...@li... >> https://lists.sourceforge.net/lists/listinfo/oorexx-devel >> >> > > ------------------------------------------------------------------------------ > _______________________________________________ > Oorexx-devel mailing list > Oor...@li... > https://lists.sourceforge.net/lists/listinfo/oorexx-devel > > > |