Examples:  https://tbpl.mozilla.org/php/getParsedLog.php?id=47885243&full=1&branch=mozilla-inbound  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 , it's JSObject::is<T>() that it tries to use; in , 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.
Created attachment 8488072 [details] [diff] [review] 1066193.patch Dan, do you think that might help? We could land this and see if the amount of intermittent lowers...
Attachment #8488072 - Flags: feedback?(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.
Attachment #8488072 - Flags: feedback?(sunfish) → feedback+
If that doesn't work, you could add even more qualifications: this->MDefinition::is<T>().
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
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
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" :) )
Summary: Intermittent build failures due to MDefinition::is<T> → spurious G++ error: cannot call member function '...' without object
It looks like the patch in comment 1 fixes the failures I was seeing in my first try push.
Thanks Brian for trying. r=h4writer over irc, pushed now: https://hg.mozilla.org/integration/mozilla-inbound/rev/9d5b23b90cf5
Assignee: nobody → benj
Status: NEW → ASSIGNED
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
Created attachment 8488692 [details] [diff] [review] Part 2, IonExitFrameLayout r+ from sfink on IRC. https://hg.mozilla.org/integration/mozilla-inbound/rev/75888bec4541
Attachment #8488692 - Flags: review+
Status: ASSIGNED → RESOLVED
Last Resolved: 4 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla35
You need to log in before you can comment on or make changes to this bug.