784631 - C++ compilation error jsinterp.cpp:3685

Status: RESOLVED FIXED

(Core :: JavaScript Engine, defect)

Description

[David Teller [:Yoric] - still alive but not very active]

Attachment: Build log

Building from clean with clang, I have the following error:

jsinterp.cpp:3685:9: error: indirect goto might cross protected scopes

Attaching build log.

clang -v produces
Apple clang version 2.1 (tags/Apple/clang-163.7.1) (based on LLVM 3.0svn)
Target: x86_64-apple-darwin11.4.0
Thread model: posix

This is a blocker for me, as a gcc-related bug also prevents me from building with gcc.

Comment 1

[Hanspeter Niederstrasser]

Possibly similar to bug 664252

Comment 2

[Terrence Cole [:terrence]]

Attachment: v0

This fixes the indicated clang build error and one other that I have been experiencing for several months.

Comment 3

[Jeff Walden [:Waldo]]

Comment on attachment 659784 [details] [diff] [review]
v0

Review of attachment 659784 [details] [diff] [review]:
-----------------------------------------------------------------

Bleh.  If this fixes things, good, I guess.  Don't much like the blockDepth obfuscation, tho, seeing as I can't find anything in C++98 or C++11 saying that goto out of a scope with an object with a non-trivial is undefined.  :-\  (6.6 seems to say all objects with automatic storage duration are destroyed, regardless of destructor type.)  Any chance you could inquire around and find out why clang thinks this should be an error?  Maybe it's actually a clang bug.

Comment 5

[Rafael Ávila de Espíndola (:espindola) (not reading bugmail)]

The problem is that computed gotos are not in the standard. With a regular goto the compiler knows where it is going and can find out which objects have to be destructed. With a computed goto it cannot.

Comment 6

[Jeff Walden [:Waldo]]

Ugh.  Can we just stop having a threaded interpreter finally, to save ourselves some hassle and acknowledge that if you're interpreting, you're just gonna be slow?  :-(

Comment 7

[Terrence Cole [:terrence]]

https://hg.mozilla.org/integration/mozilla-inbound/rev/8cebabaead16

Comment 8

[Terrence Cole [:terrence]]

(In reply to Jeff Walden [:Waldo] (remove +bmo to email) from comment #6)
> Ugh.  Can we just stop having a threaded interpreter finally, to save
> ourselves some hassle and acknowledge that if you're interpreting, you're
> just gonna be slow?  :-(

Python has a threaded interpreter loop and it isn't utterly hideous, like ours.  We should just do whatever they are doing.

Comment 9

[Rafael Ávila de Espíndola (:espindola) (not reading bugmail)]

(In reply to Jeff Walden [:Waldo] (remove +bmo to email) from comment #6)
> Ugh.  Can we just stop having a threaded interpreter finally, to save
> ourselves some hassle and acknowledge that if you're interpreting, you're
> just gonna be slow?  :-(

We can benchmark it again, but given that the interpreter was showing up in the profile when we started the clang switch I guess the answer is no.

Comment 10

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/mozilla-central/rev/8cebabaead16