http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54959
Bug #: 54959
Summary: current_pass == NULL during invocation of pass->gate
within execute_ipa_summary_passes()
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: plugins
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: dmalc...@redhat.com
In my gcc-python-plugin I allow users to create custom passes.
(FWIW see
http://gcc-python-plugin.readthedocs.org/en/latest/passes.html#creating-new-optimization-passes
for what this looks like from the user's perspective).
In particular, I've been supporting a gate() method, mirroring that of the
underlying opt_pass.
I have a single impl_gate() handler that's shared by all such user-created
passes, which I then dispatch to appropriate python code. Given that the
gate() callback takes no arguments, I've been looking up the relevant opt_pass*
by looking at the "current_pass" global.
This works for GIMPLE_PASS passes, but not for those of kind IPA_PASS.
Specifically, within gcc-4.7.0:gcc/passes.c:
1875 void
1876 execute_ipa_summary_passes (struct ipa_opt_pass_d *ipa_pass)
1877 {
1878 while (ipa_pass)
1879 {
1880 struct opt_pass *pass = &ipa_pass->pass;
1881
1882 /* Execute all of the IPA_PASSes in the list. */
1883 if (ipa_pass->pass.type == IPA_PASS
>>1884 && (!pass->gate || pass->gate ())
1885 && ipa_pass->generate_summary)
1886 {
at line 1884, pass->gate() is called, but current_pass is NULL, so I don't see
to have a way of figuring out which opt_pass* the gate() callback was called
on.
Is it possible to set current_pass in this loop before calling gate()?
Alternatively, all such callbacks could gain an argument, passing in "pass"
(though that would be an API change).
Hope the above makes sense
