1066193 - spurious G++ error: cannot call member function '...' without object

Status: RESOLVED FIXED

(Core :: JavaScript Engine, defect)

Description

[Benjamin Bouvier [:bbouvier] (inactive)]

Examples: 
[1] https://tbpl.mozilla.org/php/getParsedLog.php?id=47885243&full=1&branch=mozilla-inbound
[2] https://tbpl.mozilla.org/php/getParsedLog.php?id=47894331&tree=Mozilla-Inbound

The issue is the following: while the compiler should resolve is<T>() to js::jit::MDefinition::is<T>, it doesn't and will try to use other is<T> definitions. For instance, in [1], it's JSObject::is<T>() that it tries to use; in [2], it's js::jit::IonExitFrameLayout::is<T>().

Sheriffs say it started to show up a few days ago.
The only common ground I can find so far is that the compiler used is gcc-4.7.2.
I call for internal compiler error.

Comment 1

[Benjamin Bouvier [:bbouvier] (inactive)]

Attachment: 1066193.patch

Dan, do you think that might help? We could land this and see if the amount of intermittent lowers...

Comment 2

[Dan Gohman [:sunfish]]

Comment on attachment 8488072 [details] [diff] [review]
1066193.patch

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

Odd. This patch looks worth trying, at least.

Comment 3

[Luke Wagner [:luke]]

If that doesn't work, you could add even more qualifications: this->MDefinition::is<T>().

Comment 4

[Brian Hackett [Laid off!]]

FWIW I have a try push that doesn't touch js/src/jit but which seems to be making this perma-failing on Linux debug:

https://tbpl.mozilla.org/?tree=Try&rev=7aa8cbf52b04

Comment 5

[Brian Hackett [Laid off!]]

And here's a try push which combines the above try push with the patch for comment 1:

https://tbpl.mozilla.org/?tree=Try&rev=1e6e4867210a

Comment 6

[Jim Blandy :jimb]

For what it's worth, I ran into similar failures in this Try push:
https://tbpl.mozilla.org/php/getParsedLog.php?id=47898338&tree=Try&full=1

I don't know how to tell which compiler that is running.

("internal compiler error" means the compiler crashed. This would be an "external compiler error" :) )

Comment 7

[Brian Hackett [Laid off!]]

It looks like the patch in comment 1 fixes the failures I was seeing in my first try push.

Comment 8

[Benjamin Bouvier [:bbouvier] (inactive)]

Thanks Brian for trying. r=h4writer over irc, pushed now:
https://hg.mozilla.org/integration/mozilla-inbound/rev/9d5b23b90cf5

Comment 9

[Benjamin Bouvier [:bbouvier] (inactive)]

So it happens again with IonExitFrameLayout::is<T> and JSObject::is<T>. It is showing up all over the place in inbound right now, so will probably make a quick workaround like the other, hoping it helps. That'd be really nice to have a way to reproduce it and file against gcc issues system, but that seems rather hard to reproduce...

https://tbpl.mozilla.org/php/getParsedLog.php?id=47976450&tree=Mozilla-Inbound
https://tbpl.mozilla.org/php/getParsedLog.php?id=47977124&tree=Mozilla-Inbound
https://tbpl.mozilla.org/php/getParsedLog.php?id=47977748&tree=Mozilla-Inbound

Comment 10

[Benjamin Bouvier [:bbouvier] (inactive)]

Attachment: Part 2, IonExitFrameLayout

r+ from sfink on IRC.
https://hg.mozilla.org/integration/mozilla-inbound/rev/75888bec4541

Comment 11

[Phil Ringnalda (:philor)]

https://hg.mozilla.org/mozilla-central/rev/9d5b23b90cf5
https://hg.mozilla.org/mozilla-central/rev/75888bec4541