* plugin callbacks after compiler errors @ 2009-06-09 19:33 Taras Glek 2009-06-09 19:45 ` Basile STARYNKEVITCH 2009-06-09 22:12 ` Diego Novillo 0 siblings, 2 replies; 7+ messages in thread From: Taras Glek @ 2009-06-09 19:33 UTC (permalink / raw) To: gcc While developing my plugin I've noticed that many callbacks need to be guarded with "if (errorcount)" or the plugin will cause a gcc crash due to receiving less complete data than it expected. Should the plugin API guard callbacks in invoke_plugin_callbacks() to avoid 99% of plugins running into this issue? Taras ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: plugin callbacks after compiler errors 2009-06-09 19:33 plugin callbacks after compiler errors Taras Glek @ 2009-06-09 19:45 ` Basile STARYNKEVITCH 2009-06-09 22:12 ` Diego Novillo 1 sibling, 0 replies; 7+ messages in thread From: Basile STARYNKEVITCH @ 2009-06-09 19:45 UTC (permalink / raw) To: Taras Glek; +Cc: gcc Taras Glek wrote: > While developing my plugin I've noticed that many callbacks need to be > guarded with "if (errorcount)" or the plugin will cause a gcc crash > due to receiving less complete data than it expected. > > Should the plugin API guard callbacks in invoke_plugin_callbacks() to > avoid 99% of plugins running into this issue? I am not sure this should be a fixed, wired (ie built-in) policy. One could imagine some plugins whose main role is precisely to issue additional errors (and IIRC, your TreeHydra did something similar to that). Maybe we should just fix the documentation, saying that plugins should care (and plugin writers should think of) previously detected errors. Maybe we might differentiate errors found by other passes and error found by plugins. Maybe we should also extend the API so that some plugins get disabled when errorcount is >0. I tend to believe it should not become a general policy (but at least tunable plugin by plugin) but I may be wrong. Regards. -- Basile STARYNKEVITCH http://starynkevitch.net/Basile/ email: basile<at>starynkevitch<dot>net mobile: +33 6 8501 2359 8, rue de la Faiencerie, 92340 Bourg La Reine, France *** opinions {are only mines, sont seulement les miennes} *** ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: plugin callbacks after compiler errors 2009-06-09 19:33 plugin callbacks after compiler errors Taras Glek 2009-06-09 19:45 ` Basile STARYNKEVITCH @ 2009-06-09 22:12 ` Diego Novillo 2009-06-10 2:14 ` Taras Glek 1 sibling, 1 reply; 7+ messages in thread From: Diego Novillo @ 2009-06-09 22:12 UTC (permalink / raw) To: Taras Glek; +Cc: gcc On Tue, Jun 9, 2009 at 15:33, Taras Glek<taras.glek@gmail.com> wrote: > While developing my plugin I've noticed that many callbacks need to be > guarded with "if (errorcount)" or the plugin will cause a gcc crash due to > receiving less complete data than it expected. More details please. What exactly is the error and how is errorcount related? > Should the plugin API guard callbacks in invoke_plugin_callbacks() to avoid > 99% of plugins running into this issue? At the point that plugins are invoked, they should be able to deal with whatever state the IL is at that moment. I'd favor flexibility over protection here. But I'd like to see more details on what you're after here. Diego. ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: plugin callbacks after compiler errors 2009-06-09 22:12 ` Diego Novillo @ 2009-06-10 2:14 ` Taras Glek 2009-06-15 13:32 ` Rafael Espindola 0 siblings, 1 reply; 7+ messages in thread From: Taras Glek @ 2009-06-10 2:14 UTC (permalink / raw) To: Diego Novillo; +Cc: gcc Diego Novillo wrote: > On Tue, Jun 9, 2009 at 15:33, Taras Glek<taras.glek@gmail.com> wrote: > >> While developing my plugin I've noticed that many callbacks need to be >> guarded with "if (errorcount)" or the plugin will cause a gcc crash due to >> receiving less complete data than it expected. >> > > More details please. What exactly is the error and how is errorcount related? > > >> Should the plugin API guard callbacks in invoke_plugin_callbacks() to avoid >> 99% of plugins running into this issue? >> > > At the point that plugins are invoked, they should be able to deal > with whatever state the IL is at that moment. I'd favor flexibility > over protection here. But I'd like to see more details on what you're > after here. > This is more of a polish issue than anything else. Trouble is that one may never see these bugs during plugin development unless the plugins are tested on files that have syntax errors. Test command: /home/bradh/devel/gcc-build/gcc/cc1 -quiet -O1 -ftest-coverage -fplugin=../gcc_dehydra.so -o /dev/null -fplugin-arg-gcc_dehydra-=test_numinfo.js numinfo.cc Failure msg: Expected 'OK' output; Errors: numinfo.cc:14:6: error: expected â=â, â,â, â;â, âasmâ or â__attribute__â before âboolvarâ numinfo.cc:19:7: error: expected â=â, â,â, â;â, âasmâ or â__attribute__â before âenumvarâ numinfo.cc:21:7: error: expected identifier or â(â before â&â token numinfo.cc:22:21: error: âenumvarâ undeclared here (not in a function) *** WARNING *** there are active plugins, do not report this as a bug unless you can reproduce it without enabling any plugins. Event Plugins PLUGIN_FINISH_TYPE gcc_dehydra PLUGIN_FINISH_UNIT gcc_dehydra PLUGIN_CXX_CP_PRE_GENERICIZE gcc_dehydra PLUGIN_FINISH gcc_dehydra PLUGIN_EVENT_LAST gcc_dehydra plugin_init gcc_dehydra numinfo.cc:22:1: internal compiler error: tree check: expected class âtypeâ, have âexceptionalâ (error_mark) in process_type, at dehydra_plugin.c:139 Please submit a full bug report, with preprocessed source if appropriate. See <http://gcc.gnu.org/bugs.html> for instructions. Stuff like FINISH_TYPE, PLUGIN_CXX_CP_PRE_GENERICIZE, etc can end up with error nodes instead of what is normally expected to be there. I can't imagine a usecase for when it would be useful for a plugin to have the error marker node. As I said, it's a minor polish issue. It may be sufficient to just have a note in the documentation as Basil suggested. Taras ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: plugin callbacks after compiler errors 2009-06-10 2:14 ` Taras Glek @ 2009-06-15 13:32 ` Rafael Espindola 2009-06-15 13:43 ` Diego Novillo 2009-06-15 14:30 ` Basile STARYNKEVITCH 0 siblings, 2 replies; 7+ messages in thread From: Rafael Espindola @ 2009-06-15 13:32 UTC (permalink / raw) To: Taras Glek; +Cc: Diego Novillo, gcc > As I said, it's a minor polish issue. It may be sufficient to just have a > note in the documentation as Basil suggested. I would prefer just changing the documentation too. In general I think that plugins should see gcc the same way a builtin pass does. If a plugin needs to look at the IL early in the pipeline it should be ready to work with previous errors. > > Taras > Cheers, -- Rafael Avila de Espindola Google | Gordon House | Barrow Street | Dublin 4 | Ireland Registered in Dublin, Ireland | Registration Number: 368047 ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: plugin callbacks after compiler errors 2009-06-15 13:32 ` Rafael Espindola @ 2009-06-15 13:43 ` Diego Novillo 2009-06-15 14:30 ` Basile STARYNKEVITCH 1 sibling, 0 replies; 7+ messages in thread From: Diego Novillo @ 2009-06-15 13:43 UTC (permalink / raw) To: Rafael Espindola; +Cc: Taras Glek, gcc On Mon, Jun 15, 2009 at 09:32, Rafael Espindola<espindola@google.com> wrote: >> As I said, it's a minor polish issue. It may be sufficient to just have a >> note in the documentation as Basil suggested. > > I would prefer just changing the documentation too. In general I think > that plugins > should see gcc the same way a builtin pass does. If a plugin needs to > look at the > IL early in the pipeline it should be ready to work with previous errors. Agreed. As we chatted last week, we may want to offer a simplified interface to those plugins that are never going to be integrated with the compiler. For now, plugins should get on the same roller coaster the rest of the passes are in. However, that may be more work than it's worth. It would force an API translation layer that may be burdensome to maintain. I would prefer to wait until we have more experience with plugin usage. Diego. ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: plugin callbacks after compiler errors 2009-06-15 13:32 ` Rafael Espindola 2009-06-15 13:43 ` Diego Novillo @ 2009-06-15 14:30 ` Basile STARYNKEVITCH 1 sibling, 0 replies; 7+ messages in thread From: Basile STARYNKEVITCH @ 2009-06-15 14:30 UTC (permalink / raw) Cc: gcc Rafael Espindola wrote: >> As I said, it's a minor polish issue. It may be sufficient to just have a >> note in the documentation as Basil suggested. I am sorry to be picky, but my first name is spelled Basile (in France, where I live and am a citizen). I do know that is it written Basil in English & Vasilii in (transliterated) Russian; but I prefer to be called by my official first name; unless it is an English or American habit to change the spelling of names. Indeed my parents me after Basil of Caesarea, http://en.wikipedia.org/wiki/Basil_of_Caesarea (called Basil the Great in the Orthodox church; he is the author of several remarkable texts, and of the http://en.wikipedia.org/wiki/Basil_of_Caesarea). But please do me a favor: on mailing lists spell my first name as it is in my signature. Actually, I would suppose that rule is nearly universal! Of course, I don't care if russian speakers call me Vassilii or even Vassia. Regards. -- Basile STARYNKEVITCH http://starynkevitch.net/Basile/ email: basile<at>starynkevitch<dot>net mobile: +33 6 8501 2359 8, rue de la Faiencerie, 92340 Bourg La Reine, France *** opinions {are only mines, sont seulement les miennes} *** ^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2009-06-15 14:30 UTC | newest] Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2009-06-09 19:33 plugin callbacks after compiler errors Taras Glek 2009-06-09 19:45 ` Basile STARYNKEVITCH 2009-06-09 22:12 ` Diego Novillo 2009-06-10 2:14 ` Taras Glek 2009-06-15 13:32 ` Rafael Espindola 2009-06-15 13:43 ` Diego Novillo 2009-06-15 14:30 ` Basile STARYNKEVITCH
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).