$ cat test.cpp #include <gcc-plugin.h> #include <tree.h> #include <gimple.h> int main(void) { return 0; } $ g++-4.9 test.cpp -o test -I$(g++-4.9 -print-file-name=plugin)/include ... /usr/lib/gcc/x86_64-linux-gnu/4.9/plugin/include/gimple.h:276:22: error: field ‘call_used’ has incomplete type ‘pt_solution’ struct pt_solution call_used; including tree-ssa-alias.h works around it, but more headers are needed. Assuming that gimple.h is needed by plugins how do you find out about all the required includes?
There was never the promise that the plugin API were anything close to "stable".
is this about stability? With trying, you find out that the following will work: #include <gcc-plugin.h> #include <tree.h> #include <function.h> #include <basic-block.h> #include <coretypes.h> #include <is-a.h> #include <predict.h> #include <internal-fn.h> #include <tree-ssa-alias.h> #include <gimple-expr.h> #include <gimple.h> int main(void) { return 0; } is there any way to find out all the needed includes? Telling plugin writers to hard-code all of this doesn't seem like a viable solution.
IMHO the header flattening is a serious mistake, but others think otherwise :(.
We have to flatten it before we can fix it... its a complete dependency mess. you could create a plugin-includes.h which includes all the files from the primary globbing files that were flattened (gimple.h and tree.h). Start by copying all the original includes from those 2 files. Then each plugin doesn't have to figure out what it needs... at least until we get back to a reasonable state.
btw, the long term plan is that #include "gimple.h" will get all the basic prerequisites you need to manipulate gimple. And then you just #include any extras your specific task requires. We're just in a transition state this release as we flatten to reconstruct a more sensible modular layout.
Am 14.05.2014 14:21, schrieb amacleod at redhat dot com: > btw, the long term plan is that #include "gimple.h" will get all the basic > prerequisites you need to manipulate gimple. And then you just #include any > extras your specific task requires. We're just in a transition state this > release as we flatten to reconstruct a more sensible modular layout. this is for 4.10, but what to do about 4.9? Maybe have gimple-plugin.h and tree-plugin.h headers, which won't go away for 4.10 and then would just include gimple.h and tree.h? I would appreciate if you could name all the toplevel headers.
Thats part of the fun. There is little rhyme nor reason to what includes what right now.. it was purely demand driven over many years. For your current purposes, gimple.h and tree.h were the primary accumulators we have already flattened, but there are a lot of include files which include 4 or 5 or 7 or more other files. Some where flattened, others haven't been tackled yet. We're trying to move to the include what you use model... with .h files containing just the exports for their .c file, and a few module headers which do some aggregation of common/required headers. Eventually including gimple.h alone will compile and provide basic manipulation routines, but you may still need to include other files depending on what you actually require. Plugins can either follow the same model, or could have one giant accumulator which includes everything... It sounds like the latter may be better for the interm, but I would encourage it to revert to the same model once the work is complete.
I maintain a compatibility header for gcc plugins that also happens to include all the headers that we needed so far: https://www.grsecurity.net/~paxguy1/gcc-common.h (this copy may not always be up-to-date, the latest version is inside the PaX patch). As for include-what-you-use, I think it's not a viable model for plugins that want to support a range of gcc versions...
sooooo. Include them all with an accumulator file as suggested? Over a run of multiple generations you have to expect some sort of flux in include structure, especially since we don't guarantee much. The only way I see you can have any kind of stability is to have a standard file you include which can adjust and include whatever is needed for any given release.
GCC 4.9.1 has been released.
GCC 4.9.2 has been released.
Surely not a "regression" in the classical sense but a plugin bug or a plugin (stable-) API deficiency.
gcc-plugin.h has had a number of includes added to ease the pain of flattening basic-block.h and cgraph.h this release. If there are still issues with tree.h or others, submit a patch which adds the required includes.
it seems that gcc/builtins.h doesn't get installed for plugins.
builtins.h has been already in 4.9, just contained far less info and thus has been less important. Quick check of new headers in toplevel directory that most likely aren't in PLUGIN_HEADERS reveals also: auto-profile.h ccmp.h collect-utils.h dojump.h explow.h fibonacci_heap.h gcse-common.h generic-match.h gimple-match.h graphite-isl-ast-to-gimple.h ifcvt.h ipa-chkp.h ipa-icf-gimple.h ipa-icf.h loop-unroll.h lto-section-names.h regcprop.h rtl-chkp.h rtlhash.h rtl-iter.h shrink-wrap.h symbol-summary.h tree-chkp.h Supposedly we should include those in PLUGIN_HEADERS too.
And comparing the right now installed headers with what is in gcc/*.h gcc/*.def reveals also: addresses.h asan.h bb-reorder.h builtin-attrs.def builtins.h builtin-types.def cilk.h collect2-aix.h collect2.h conditions.h convert.h coverage.h cppbuiltin.h cselib.h data-streamer.h dbgcnt.def dbgcnt.h dbxout.h dce.h ddg.h dfp.h domwalk.h dwarf2asm.h dwarf2out.h errors.h et-forest.h expmed.h expr.h file-find.h gcc.h gcov-counter.def gcov-io.h gcse.h gengtype.h gensupport.h ggc-internal.h gimple-streamer.h glimits.h graphds.h graph.h graphite-poly.h graphite-scop-detection.h graphite-sese-to-poly.h gstab.h gsyms.h gsyslimits.h hooks.h hosthooks-def.h hosthooks.h hw-doloop.h insn-addr.h ipa-inline.h ira.h ira-int.h langhooks-def.h libfuncs.h limitx.h limity.h lower-subreg.h lra.h lra-int.h lto-compress.h lto-streamer.h machmode.def omega.h omp-low.h optabs.def optabs.h opts-diagnostic.h passes.def profile.h read-md.h recog.h regrename.h regs.h reload.h rtl-error.h rtlhooks-def.h sched-int.h sdbout.h sel-sched-dump.h sel-sched.h sel-sched-ir.h sese.h sparseset.h sreal.h stab.def streamer-hooks.h target-def.h target-globals.h targhooks.h trans-mem.h tree-affine.h tree-browser.def tree-chrec.h tree-data-ref.h tree-diagnostic.h tree-scalar-evolution.h tree-ssa-live.h tree-ssa-propagate.h tree-stdarg.h tree-streamer.h tree-vectorizer.h tsan.h tsystem.h typeclass.h ubsan.h valtrack.h value-prof.h vmsdbg.h vtable-verify.h xcoff.h xcoffout.h (already existing in 4.9). So, how do we decide which of these headers are interesting to plugin writers?
Created attachment 35144 [details] gcc5-pr61176.patch Patch to install all gcc/*.h and gcc/*.def headers, even when they aren't listed in PLUGIN_HEADERS.
(In reply to Jakub Jelinek from comment #17) > Created attachment 35144 [details] > gcc5-pr61176.patch > > Patch to install all gcc/*.h and gcc/*.def headers, even when they aren't > listed in PLUGIN_HEADERS. thanks, this will be a big (future-proof) step towards writing plugins! on a related note, there's PR61311 where (among other issues) i list a few more missing headers needed for LTO. some would now be handled with the wildcard match however there's still a few missing: gcc/lto/lto.h <build_dir>/gcc/gcov-iov.h while lto/lto.h is probably easy to add, i'm not sure about the build-time generated one...
Author: jakub Date: Tue Mar 31 05:31:57 2015 New Revision: 221786 URL: https://gcc.gnu.org/viewcvs?rev=221786&root=gcc&view=rev Log: PR plugins/61176 * Makefile.in (install-plugin): Add all gcc/*.{h,def} files automatically to $headers. Modified: trunk/gcc/ChangeLog trunk/gcc/Makefile.in
update for gcc-6: <build_dir>/gcc/params.list is also needed now as it gets included by params.h.
(In reply to PaX Team from comment #20) > update for gcc-6: <build_dir>/gcc/params.list is also needed now as it gets > included by params.h. PR69758 fixes it.
Definitely has been fixed for a while.