caml-list - the Caml user's mailing list
 help / color / mirror / Atom feed
* [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;
as well as URLs for NNTP newsgroup(s).