From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 16605 invoked by alias); 11 Feb 2016 18:26:44 -0000 Mailing-List: contact kawa-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: kawa-owner@sourceware.org Received: (qmail 16588 invoked by uid 89); 11 Feb 2016 18:26:43 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.3.2 spammy=UD:scm, mysteriously X-HELO: mail-vk0-f52.google.com Received: from mail-vk0-f52.google.com (HELO mail-vk0-f52.google.com) (209.85.213.52) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-GCM-SHA256 encrypted) ESMTPS; Thu, 11 Feb 2016 18:26:42 +0000 Received: by mail-vk0-f52.google.com with SMTP id e6so43112732vkh.2 for ; Thu, 11 Feb 2016 10:26:42 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from:to:content-type:content-transfer-encoding; bh=G/fb3zcjCArA+kiidJdSzGwItHhCQb9oVYMUb3Zf7o8=; b=P0CDJ6oCzO/h8+Pdu0AcvBgQtfmmoeF2bJ63C0bS5TWlaeeKlhIjDC9kciK+T6aiA1 gF8CXqA3y3ilKUPUWgMHm+U+FNF2bsJ3gG20D8Ct1CoUE4btsbm4oBDMe+0SNFzg70TP 9R481r0Z3fYkfQ4nd99wyBoqNdRCHdvDD+PZDYepFCdfMBNOCPMKXk+8Mn+GnVjqWjT8 v6GpXYefDdzrZ8RhulxB4zRlAEo4Sm6V2AMfSYVT5tuzVV/jBXGKSKsxw70KM6IoVIAb 6nP9oAzEM8sW/8Pj+Ck1FRvk2MLtYboKnSq7iucpdPG4F6EqAlMhhUjDjh4aO8r3xhLG 6CYw== X-Gm-Message-State: AG10YOTTKFDmqxElGCogBV2tFtgoJOueb+iSJOceB/LKgA3T+ZIaiEiD9IyERLVubYt0onZQfN7Eebd0KwwvEw== MIME-Version: 1.0 X-Received: by 10.31.154.21 with SMTP id c21mr36036319vke.38.1455215200109; Thu, 11 Feb 2016 10:26:40 -0800 (PST) Received: by 10.31.184.133 with HTTP; Thu, 11 Feb 2016 10:26:40 -0800 (PST) In-Reply-To: <56BC9451.30002@bothner.com> References: <56BC9451.30002@bothner.com> Date: Thu, 11 Feb 2016 18:26:00 -0000 Message-ID: Subject: Re: How do i debug --no-inline or --full-tailcalls options? From: OKUMURA Yuki To: kawa@sourceware.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-IsSubscribed: yes X-SW-Source: 2016-q1/txt/msg00010.txt.bz2 Ah, thanks for the comments! 2016-02-11 23:01 GMT+09:00 Per Bothner : - snip - > Why do you want to use --no-inlining? One advantage I can see is beter > stack traces (at least when --no-full-tailcalls). It might be reasonable= to > retrict --no-inlining's effect to "normal" functions. Use of --no-inline is just because it (accidentally) solved another problem: (https://github.com/okuoku/yuni/issues/34) I don't fully understand what is happening on that issue yet; with --full-tailcalls and without --no-inline, Kawa seems to skip some procedures when its result is not consumed at all. (ie. every skipped procedures were wrapper around SET!) I prepared (somewhat) minified program which exhibits the problem: https://gist.github.com/okuoku/d5cba6f31b781db911aa The code prepares 2 vectors which hold some data but when I move some setters into a R7RS library, these setters are mysteriously "skipped" and a vector field would left uninitialized. Without --full-tailcall nor --no-inline, it works fine: $ java kawa.repl --r7rs check3.scm (SET!-CALLED: 0 test) (SET!-CALLED: 1 #) (SET!-CALLED: 0 #(test #)) (SET!-CALLED: 1 (INIT1 . INIT2)) (#(test #) ("INIT1" . "INIT2")) but with --full-tailcall, a SET!-CALLED message is missing; $ java kawa.repl --r7rs --full-tailcalls check3.scm (SET!-CALLED: 0 test) (SET!-CALLED: 1 #) (SET!-CALLED: 1 (INIT1 . INIT2)) ("UNINITIALIZED_x" ("INIT1" . "INIT2")) this means a line here=E2=98=85 (define (make-minidispatch-obj class param) (let ((obj (make-minitype-obj))) (baseset! obj 0 class) =E2=98=85 (baseset! obj 1 param) obj)))) was skipped. The problem is gone in case we added --no-inline: $ java kawa.repl --r7rs --full-tailcalls --no-inline check3.scm (SET!-CALLED: 0 test) (SET!-CALLED: 1 #) (SET!-CALLED: 0 #(test #)) (SET!-CALLED: 1 (INIT1 . INIT2)) (#(test #) ("INIT1" . "INIT2")) This is why I ended up specifying --no-inline. I suspect this behaviour is backend's problem since when I merged explicit libraries into a module, problem would just disappear.