[Bug plugins/61176] [4.9/4.10 Regression] plugin builds including gimple.h not building
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61176 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Target Milestone|4.9.1 |4.9.2 --- Comment #10 from Jakub Jelinek jakub at gcc dot gnu.org --- GCC 4.9.1 has been released.
[Bug plugins/61176] [4.9/4.10 Regression] plugin builds including gimple.h not building
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61176 PaX Team pageexec at gmail dot com changed: What|Removed |Added CC||pageexec at gmail dot com --- Comment #8 from PaX Team pageexec at gmail dot com --- 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...
[Bug plugins/61176] [4.9/4.10 Regression] plugin builds including gimple.h not building
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61176 --- Comment #9 from Andrew Macleod amacleod at redhat dot com --- so. 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.
[Bug plugins/61176] [4.9/4.10 Regression] plugin builds including gimple.h not building
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61176
--- Comment #2 from Matthias Klose doko at gcc dot gnu.org ---
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.
[Bug plugins/61176] [4.9/4.10 Regression] plugin builds including gimple.h not building
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61176 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #3 from Jakub Jelinek jakub at gcc dot gnu.org --- IMHO the header flattening is a serious mistake, but others think otherwise :(.
[Bug plugins/61176] [4.9/4.10 Regression] plugin builds including gimple.h not building
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61176 --- Comment #4 from Andrew Macleod amacleod at redhat dot com --- 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.
[Bug plugins/61176] [4.9/4.10 Regression] plugin builds including gimple.h not building
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61176 --- Comment #5 from Andrew Macleod 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.
[Bug plugins/61176] [4.9/4.10 Regression] plugin builds including gimple.h not building
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61176 --- Comment #6 from Matthias Klose doko at ubuntu dot com --- 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.
[Bug plugins/61176] [4.9/4.10 Regression] plugin builds including gimple.h not building
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61176 --- Comment #7 from Andrew Macleod amacleod at redhat dot com --- 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.
[Bug plugins/61176] [4.9/4.10 Regression] plugin builds including gimple.h not building
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61176 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |4.9.1 --- Comment #1 from Richard Biener rguenth at gcc dot gnu.org --- There was never the promise that the plugin API were anything close to stable.
