Currently, it is possible to specify an initial value in the .opt file with Init(). However, this value is set at the beginning, so it is (impossible?) to know whether the value is the default or was set explicitly in some other way. This is why many options are initialized to -1 instead. The infrastructure to detect whether options have been set explicitly seems to be there, but it is not clear how to use it to fix the above problem.
On Sun, 22 Apr 2012, manu at gcc dot gnu.org wrote: > The infrastructure to detect whether options have been set explicitly seems to > be there, but it is not clear how to use it to fix the above problem. My notion is that the _set information should move from being a boolean to recording the "distance" of the option that set some field from that field (it might be set by an option that directly corresponds to the field, or by one indirectly implying it, or a default if no relevant option is given at all). Distance is in the sense of appendix 1 of <http://gcc.gnu.org/ml/gcc/2010-01/msg00063.html>. This is explicitly not a detailed design; anyone implementing it would need to flesh out the details.
(In reply to comment #1) > On Sun, 22 Apr 2012, manu at gcc dot gnu.org wrote: > This is explicitly not a detailed design; anyone implementing it would > need to flesh out the details. Say we have: A enables B enables C. Do we actually need to track that C was enabled by B or by A? Sorry I cannot imagine what for. For warning options, it is sufficient to track the C was enabled by other option different from C. It seems we have most of the infrastructure to do this, however, it is unclear how to use this infrastructure to make Init() useful again, or implement PR 53063.
On Tue, 24 Apr 2012, manu at gcc dot gnu.org wrote: > Say we have: A enables B enables C. Do we actually need to track that C was > enabled by B or by A? Sorry I cannot imagine what for. The idea is that -WB -Wno-B leaves C disabled, but -WB -Wno-A leaves it enabled (because -WB is more specific than -Wno-A, it takes precedence whatever the ordering of those two options). If there were any option -WC or -Wno-C on the command line, the last such option would apply regardless of the -WA / -Wno-A / -WB / -Wno-B options (that much at least is already implemented for some option implications). > For warning options, it is sufficient to track the C was enabled by other > option different from C. It seems we have most of the infrastructure to do Even for that, you still need to move away from _set being a boolean, since there will be three values (default, explicit -WC / -Wno-C, controlled by some other option but not the most specific option). > this, however, it is unclear how to use this infrastructure to make Init() > useful again, or implement PR 53063. Init() should I think ideally be just for the defaults (with _set replacing the present uses of -1 or 2 in Init to mean "not set").
(In reply to comment #3) > > Init() should I think ideally be just for the defaults (with _set > replacing the present uses of -1 or 2 in Init to mean "not set"). Do you think it is possible to implement just this last part with _set being a boolean? The code handling -Wb would still need to check explicitly that -Wc is "not set", but the .opt file infrastructure will take care to set the value Init() when "not set" after all command-line options have been processed.
On Tue, 24 Apr 2012, manu at gcc dot gnu.org wrote: > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53072 > > --- Comment #4 from Manuel López-Ibáñez <manu at gcc dot gnu.org> 2012-04-24 14:49:54 UTC --- > (In reply to comment #3) > > > > Init() should I think ideally be just for the defaults (with _set > > replacing the present uses of -1 or 2 in Init to mean "not set"). > > Do you think it is possible to implement just this last part with _set being a > boolean? The code handling -Wb would still need to check explicitly that -Wc is > "not set", but the .opt file infrastructure will take care to set the value > Init() when "not set" after all command-line options have been processed. It may be possible - you'd need to avoid implicit setting marking the implied option as "set" - and I don't think delaying processing of Init() will actually be helpful anyway.
(In reply to comment #5) > > It may be possible - you'd need to avoid implicit setting marking the > implied option as "set" - and I don't think delaying processing of Init() > will actually be helpful anyway. Then, I don't understand what is your plan. The current hack uses Init(-1) and checks if warn_whatever == -1 as late as possible before setting the real default value. My idea was to mimic this, but using the "set" structure instead of -1, and using the Init value as the default value. A strategy to implement this could be to introduce a new Default(), which will be set unconditionally if the option is "unset". This will allow to get rid of Init(-1) incrementally.
This is being fixed by PR53063. *** This bug has been marked as a duplicate of bug 53063 ***