Closed Bug 923374 Opened 11 years ago Closed 7 years ago

sixgill causes compilation to fail

Categories

(Core :: JavaScript Engine, defect)

defect
Not set
normal

Tracking

()

RESOLVED FIXED

People

(Reporter: sfink, Unassigned)

References

Details

Attachments

(3 files)

When running the static rooting analysis on a build slave, I am getting many errors of the form: In instantiation of ‘void vector<_Tp>::push_back(void* const&) [with _Tp = void*; vector<_Tp>::ptr = void*]’: error: ‘_S_construct’ was not declared in this scope error: ‘_S_construct’ was not declared in this scope This breaks the compilation. basecc helpfully reruns without the plugin, but the resulting xdbs cause the analysis to fail. Oddly, this does not happen on my desktop where I've been running the analysis automatically. Maybe it's a difference in the gcc versions or something; I don't know. But if I take a preprocessed file that shows the problem, it will fail on both the build slave and on my desktop.
If I compile this file with c++ -fplugin=/home/sfink/src/sixgill-finkdesk/gcc/xgill.so -fno-exceptions -std=gnu++0x -c nop.cpp then I get the error.
Attached file Stack trace of error (deleted) —
This is a stack trace of the write() that shows the error. Basically, it comes from a call to XIL_GlobalName.
Attached file Random debugging info (deleted) —
This shows a dump of... er, something nearby the problematic subtree. In the 2nd part, I'm dumping out the TREE_CODE() stack for every generate_TranslateTree call underneath the problematic CLEANUP_POINT_EXPR (I put a key as to what was what in there too.)
So it seems like some state is not correct for XIL_GlobalName's call to decl_as_string, but I have no idea what that might be. I'm about at the limit of where dumb debugging is going to help, and I'm not sure I want to learn this much about gcc internals.
Blocks: 916677
This definitely looks like a bug in GCC. tsubst_copy_and_build, which reports the error, has a |complain| argument controlling when it reports errors. This is correctly set to zero on the call stack but is not checked when unqualified_name_lookup_error is called. The relevant code from gcc-4.7.2 source: if (TREE_CODE (function) == IDENTIFIER_NODE) { unqualified_name_lookup_error (function); release_tree_vector (call_args); return error_mark_node; } This looks like it was fixed for gcc-4.8.0. The relevant code from that source: if (TREE_CODE (function) == IDENTIFIER_NODE) { if (complain & tf_error) unqualified_name_lookup_error (function); release_tree_vector (call_args); RETURN (error_mark_node); } It is still returning an error node so I don't know if it will just spew a different error down the line, but I would suggest retrying with 4.8.0 or above and seeing if compilation succeeds.
Do you know why it fails at all when running with the plugin enabled? Is there some reason why the actual compile never tries to do this?
Yeah, the plugin calls decl_as_string, which ends up calling tsubst_copy_and_build. decl_as_string isn't supposed to cause compilation errors to be generated, though.
Right, I just wasn't sure why _S_construct wouldn't be resolvable when it presumably is during the real compile. Right now, I'm only seeing the error with gcc 4.7.3, not gcc 4.7.2, and there's no releng build of gcc 4.8 yet. So maybe I'll try downgrading to 4.7.2 first. (Both 4.7.2 and 4.7.3 fail on the preprocessed file I attached, but for whatever reason, 4.7.2 is producing a preprocessed file that *does* work, at least on my desktop machine.) The other issue with using 4.8.0 is that it'll be even harder to get b2g up, since afaik only 4.7.something is available there right now.
(we're on gcc 4.9, soon upgrading to 6.1 or something.)
Status: NEW → RESOLVED
Closed: 7 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: