* [Caml-list] Re: Marshalling tests fail on AMD x86_64 (Opteron). (PR#1979) [not found] <200312160316.EAA00843@pauillac.inria.fr> @ 2003-12-20 11:30 ` Xavier Leroy 2003-12-20 14:58 ` skaller ` (2 more replies) 0 siblings, 3 replies; 4+ messages in thread From: Xavier Leroy @ 2003-12-20 11:30 UTC (permalink / raw) To: nogin; +Cc: caml-list [-- Attachment #1: Type: text/plain, Size: 1803 bytes --] > I am having problems with the marshaller (I am getting a segfault in the > marshaller) on the AMD x86_64 (Opteron) running Fedora Core development > version (AKA Red Hat Raw Hide) and OCaml 3.07+2. > To figure out what is going on, I tried running some tests. > When I run test/Moretest/intext.byt, I get: > > ... > Test 223 passed. > Test 300 passed. > Uncaught exception: Failure("input_value_from_block: bad object") > Exit 2 > > When I run test/Moretest/intext.out, I get: > > ... > Test 223 passed. > Test 300 passed. > Test 401 FAILED. > > Do these indicate a bug? Or is this expected and I should look for the > source of my problems elsewhere? The second test failure is actually a nasty bug in the AMD64 port of OCaml, causing exceptions raised from C code to misbehave with ocamlopt. (ocamlc isn't affected.) The first test failure is either a bug in gcc or an unspecified behavior of C that I wasn't aware of. Basically, some stuff is computed with type 'unsigned int', stored in an 'unsigned long' variable, and compared against an 'unsigned int' constant. The gcc-generated code performs a sign extension 32 -> 64 bits on the unsigned int, causing the test to fail. This behavior also occurs with older versions of gcc on the Alpha. Digital Unix's Alpha cc compiler (the only other 64-bit C compiler I have at hand) doesn't do sign extension. A small example that reproduces the behavior is attached. I'll let the C language lawyers argue what the correct behavior is. At any rate, plase find attached a patch against 3.07pl2 that fixes the ocamlopt exception bug, and works around the undesired sign extension. With this patch, the "intext" regression test passes on your AMD64 machine. Let me know if that improves the situation with your other crashes. - Xavier Leroy [-- Attachment #2: patch --] [-- Type: text/plain, Size: 1932 bytes --] Index: csl/byterun/intern.c diff -c csl/byterun/intern.c:1.50 csl/byterun/intern.c:1.52 *** csl/byterun/intern.c:1.50 Thu Dec 12 19:59:11 2002 --- csl/byterun/intern.c Sat Dec 20 11:57:38 2003 *************** *** 15,20 **** --- 15,22 ---- /* Structured input, compact format */ + /* The interface of this file is "intext.h" */ + #include <string.h> #include "alloc.h" #include "custom.h" *************** *** 496,502 **** CAMLexport value input_value_from_malloc(char * data, long ofs) { ! mlsize_t magic, block_len; value obj; intern_input = (unsigned char *) data; --- 498,505 ---- CAMLexport value input_value_from_malloc(char * data, long ofs) { ! uint32 magic; ! mlsize_t block_len; value obj; intern_input = (unsigned char *) data; *************** *** 514,520 **** CAMLexport value input_value_from_block(char * data, long len) { ! mlsize_t magic, block_len; value obj; intern_input = (unsigned char *) data; --- 517,524 ---- CAMLexport value input_value_from_block(char * data, long len) { ! uint32 magic; ! mlsize_t block_len; value obj; intern_input = (unsigned char *) data; Index: csl/asmrun/amd64.S diff -c csl/asmrun/amd64.S:1.1 csl/asmrun/amd64.S:1.3 *** csl/asmrun/amd64.S:1.1 Mon Jun 30 10:28:45 2003 --- csl/asmrun/amd64.S Sat Dec 20 12:05:51 2003 *************** *** 252,258 **** FUNCTION(raise_caml_exception) movq %rdi, %rax movq caml_exception_pointer(%rip), %rsp ! popq caml_exception_pointer(%rip) ret /* Callback from C to Caml */ --- 252,259 ---- FUNCTION(raise_caml_exception) movq %rdi, %rax movq caml_exception_pointer(%rip), %rsp ! popq %r14 /* Recover previous exception handler */ ! movq young_ptr(%rip), %r15 /* Reload alloc ptr */ ret /* Callback from C to Caml */ [-- Attachment #3: bug.c --] [-- Type: text/plain, Size: 467 bytes --] #include <stdio.h> static unsigned char * src; #define read32u() \ (src += 4, \ (src[-4] << 24) + (src[-3] << 16) + (src[-2] << 8) + src[-1]) #define Intext_magic_number 0x8495A6BEU int check_magic() { unsigned long magic; magic = read32u(); return (magic == Intext_magic_number); } static unsigned char testdata[4] = { 0x84, 0x95, 0xA6, 0xBE }; int main() { src = testdata; if (check_magic()) printf("OK\n"); else printf("Bug\n"); return 0; } ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [Caml-list] Re: Marshalling tests fail on AMD x86_64 (Opteron). (PR#1979) 2003-12-20 11:30 ` [Caml-list] Re: Marshalling tests fail on AMD x86_64 (Opteron). (PR#1979) Xavier Leroy @ 2003-12-20 14:58 ` skaller 2003-12-20 16:45 ` John Carr 2003-12-22 6:44 ` Aleksey Nogin 2 siblings, 0 replies; 4+ messages in thread From: skaller @ 2003-12-20 14:58 UTC (permalink / raw) To: Xavier Leroy; +Cc: nogin, caml-list On Sat, 2003-12-20 at 22:30, Xavier Leroy wrote: > > I am having problems with the marshaller (I am getting a segfault in the > The first test failure is either a bug in gcc or an unspecified > behavior of C that I wasn't aware of. Basically, some stuff is > computed with type 'unsigned int', stored in an 'unsigned long' > variable, and compared against an 'unsigned int' constant. The > gcc-generated code performs a sign extension 32 -> 64 bits on the > unsigned int, causing the test to fail. This behavior also occurs > with older versions of gcc on the Alpha. Digital Unix's Alpha cc > compiler (the only other 64-bit C compiler I have at hand) doesn't do > sign extension. A small example that reproduces the behavior is > attached. I'll let the C language lawyers argue what the correct > behavior is. Here is the rule for promotion of two values prior to a binary operation, from ISO 'C99' Standard: 6.3.1.8 Usual arithmetic conversions ... Otherwise, if both operands have signed integer types or both have unsigned integer types, the operand with the type of lesser integer conversion rank is converted to the type of the operand with greater rank. ------------------- To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/ Beginner's list: http://groups.yahoo.com/group/ocaml_beginners ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [Caml-list] Re: Marshalling tests fail on AMD x86_64 (Opteron). (PR#1979) 2003-12-20 11:30 ` [Caml-list] Re: Marshalling tests fail on AMD x86_64 (Opteron). (PR#1979) Xavier Leroy 2003-12-20 14:58 ` skaller @ 2003-12-20 16:45 ` John Carr 2003-12-22 6:44 ` Aleksey Nogin 2 siblings, 0 replies; 4+ messages in thread From: John Carr @ 2003-12-20 16:45 UTC (permalink / raw) To: Xavier Leroy; +Cc: caml-list > The first test failure is either a bug in gcc or an unspecified > behavior of C that I wasn't aware of. Basically, some stuff is > computed with type 'unsigned int', stored in an 'unsigned long' > variable, and compared against an 'unsigned int' constant. It isn't generated with type unsigned int. The read32u macro in the attached file yields an int, not an unsigned int, because (unsigned char) promotes to (signed int). If I change "long" to "long long" in the attached file and compile with gcc on x86 the program prints "Bug". This is your macro definition: #define read32u() \ (src += 4, \ (src[-4] << 24) + (src[-3] << 16) + (src[-2] << 8) + src[-1]) Try adding a cast: #define read32u() \ (src += 4, \ (unsigned int)((src[-4] << 24) + (src[-3] << 16) + (src[-2] << 8) + src[-1])) ------------------- To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/ Beginner's list: http://groups.yahoo.com/group/ocaml_beginners ^ permalink raw reply [flat|nested] 4+ messages in thread
* [Caml-list] Re: Marshalling tests fail on AMD x86_64 (Opteron). (PR#1979) 2003-12-20 11:30 ` [Caml-list] Re: Marshalling tests fail on AMD x86_64 (Opteron). (PR#1979) Xavier Leroy 2003-12-20 14:58 ` skaller 2003-12-20 16:45 ` John Carr @ 2003-12-22 6:44 ` Aleksey Nogin 2 siblings, 0 replies; 4+ messages in thread From: Aleksey Nogin @ 2003-12-22 6:44 UTC (permalink / raw) To: Xavier Leroy; +Cc: caml-list On 20.12.2003 03:30, Xavier Leroy wrote: > At any rate, plase find attached a patch against 3.07pl2 that fixes the > ocamlopt exception bug, and works around the undesired sign extension. > With this patch, the "intext" regression test passes on your AMD64 machine. > Let me know if that improves the situation with your other crashes. I compiled today's CVS version and haven't seen a single crash so far. (I can not fully test whether everything works because of PR#1925/PR#1927/PR#1929 which is still there - both on 32 bit and 64bit - despite PR#1929 being marked as fixed). -- Aleksey Nogin Home Page: http://nogin.org/ E-Mail: nogin@cs.caltech.edu (office), aleksey@nogin.org (personal) Office: Jorgensen 70, tel: (626) 395-2907 ------------------- To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/ Beginner's list: http://groups.yahoo.com/group/ocaml_beginners ^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2003-12-22 8:42 UTC | newest] Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- [not found] <200312160316.EAA00843@pauillac.inria.fr> 2003-12-20 11:30 ` [Caml-list] Re: Marshalling tests fail on AMD x86_64 (Opteron). (PR#1979) Xavier Leroy 2003-12-20 14:58 ` skaller 2003-12-20 16:45 ` John Carr 2003-12-22 6:44 ` Aleksey Nogin
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox