[debbugs-tracker] bug#11171: closed (Incorrect ECMAScript compilation)

[GNU bug Tracking System]

Your message dated Thu, 05 Jul 2012 21:04:03 +0200
with message-id <address@hidden>
and subject line Re: bug#11171: Incorrect ECMAScript compilation
has caused the debbugs.gnu.org bug report #11171,
regarding Incorrect ECMAScript compilation
to be marked as done.

(If you believe you have received this mail in error, please contact
address@hidden)


-- 
11171: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=11171
GNU Bug Tracking System
Contact address@hidden with problems

--- Begin Message --- Subject: Incorrect ECMAScript compilation Date: Wed, 4 Apr 2012 18:07:41 +0200 Hello,

I was playing around with the ECMAScript implementation in 2.0.5, and found a bug when calling anonymous functions:

   ecmascript@(guile-user)> var foo = (function(x) { return x+1; })(1);

   $5 = 2

   ecmascript@(guile-user)> foo;

   ;;; <unknown-location>: warning: possibly unbound variable `foo'

   ERROR: In procedure #<procedure 8f4c140 ()>:

   ERROR: In procedure module-lookup: Unbound variable: foo

If you take a look at the compiled code:

   0    (assert-nargs-ee/locals 0)      ;; 0 args, 0 locals

   2    (new-frame)                     

   3    (toplevel-ref 7)                

   5    (mv-call 0 :L1233)              ;; MV -> 15

  10    (drop)                          

  11    (br :L1234)                     ;; -> 18

  15    (truncate-values 0 0)           

  18    (make-int8 2)                   ;; 2

  20    (return)                        

  21    (object-ref 8)                  

  23    (define)                        

  24    (void)                          

  25    (return)

I think it is the first (return) that causes the variable `foo' to not be defined. I did a bit of hacking and found out the problem occurs during the tree-il optimization step: Here's the tree-il code before optimization:

   (lambda () (lambda-case ((() #f #f #f () ()) (seq (call (@ (language ecmascript impl) js-init)) (seq (define foo (call (lambda () (lambda-case ((() (x) #f #f ((@ (language ecmascript impl) *undefined*)) (#{x 875}#)) (let () () () (primcall return (primcall #{1+}# (lexical x #{x 875}#))))))) (const 1))) (void))))))

And the tree-il after:

   (lambda () (lambda-case ((() #f #f #f () ()) (seq (call (@ (language ecmascript impl) js-init)) (seq (define foo (primcall return (const 2))) (void))))))

Regards,

Steve

--- End Message ---

> --- Begin Message ---
>
>
>
> Subject: 
>
> Re: bug#11171: Incorrect ECMAScript compilation
>
>
>
>
> Date: 
>
> Thu, 05 Jul 2012 21:04:03 +0200
>
>
>
>
> User-agent: 
>
> Gnus/5.13 (Gnus v5.13) Emacs/24.1 (gnu/linux)
>
>
>
>
> On Wed 04 Apr 2012 18:07, Steve Jothen <address@hidden> writes:
>
> > I was playing around with the ECMAScript implementation in 2.0.5, and
> > found a bug when calling anonymous functions:
> >
> >    ecmascript@(guile-user)> var foo = (function(x) { return x+1; })(1);
> >    $5 = 2
> >    ecmascript@(guile-user)> foo;
> >    ;;; <unknown-location>: warning: possibly unbound variable `foo'
> >    ERROR: In procedure #<procedure 8f4c140 ()>:
> >    ERROR: In procedure module-lookup: Unbound variable: foo
>
> Very interesting bug, and interesting analysis as well.
>
> > I did a bit of hacking and found out the problem occurs during the
> > tree-il optimization step: Here's the tree-il code before
> > optimization:
>
> This is almost right.  The real problem is actually in the
> ecmascript->tree-il compiler, that it uses this crazy `return' primcall
> that we never should have used.  Primcalls are not supposed to affect
> control flow!
>
> The answer is to replace the use of `return' with prompt and abort.
> It's a lose in the general case for speed, but a gain for correctness.
> I also added some optimizations that are able to remove the prompt in
> this particular case, so you can now:
>
>   > ,c var foo = (function(x) { return x+1; })(1);
>   [...]
>
> Embedded program #{826}#:
>
>    0    (assert-nargs-ee/locals 0)      ;; 0 args, 0 locals
>    2    (new-frame)                     
>    3    (toplevel-ref 7)                
>    5    (mv-call 0 :L823)               ;; MV -> 15
>   10    (drop)                          
>   11    (br :L824)                      ;; -> 18
>   15    (truncate-values 0 0)           
>   18    (make-int8 2)                   ;; 2
>   20    (object-ref 8)                  
>   22    (define)                        
>   23    (void)                          
>   24    (return)                     
>
> Here you see it inlined to var foo = 2.
>
> Thanks for the interesting bug report, and sorry for the delay!
>
> Andy
> -- 
> http://wingolog.org/
>
>
> --- End Message ---