This is the mail archive of the fortran@gcc.gnu.org mailing list for the GNU Fortran project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: PR 40989: Fix Wimplicit


On 3 May 2010 18:11, Gabriel Dos Reis <gdr@integrable-solutions.net> wrote:
> On Sat, May 1, 2010 at 3:14 PM, Manuel López-Ibáñez
> <lopezibanez@gmail.com> wrote:
>> On 1 May 2010 17:05, Gabriel Dos Reis <dosreis@gmail.com> wrote:
>>> On Sat, May 1, 2010 at 7:47 AM, Manuel López-Ibáñez
>>> <lopezibanez@gmail.com> wrote:
>>>> The problem here is that group options (options that enable other
>>>> options) are not handled correctly when enabled by -Werror=. The
>>>> following patch fixes this issue for Wimplicit but also adds the
>>>> infrastructure to fix it for all other options. When
>>>> enabling/disabling an option, we should always use the new
>>>> process_option function.
>>>>
>>>> In the future, we should be able to generate the calls to
>>>> process_option automatically from the .opt files.
>>>>
>>>> Bootstrapped and regression tested on x86_64-linux-gnu. OK?
>>>
>>> -Wimplicit actually does not make sense for C++, so C++ should not
>>> be named here (and I guess ObjC++ by extension.)
>>
>> Sure.
>>
>>> It seems to me that this is warning is valid only for the C-family language.
>>> Rename 'lang_mask' to 'c_family_mask' or 'c_family_lang_mask'.
>>
>> Ok.
>>
>>> the addition of the name 'process_option' to 'handle_option' is a bit confusing.
>>> I would suggest to rename process_option to broadcast_user_option.
>>
>> broadcast sounds a bit strange. I think process_option should be named
>> handle_option because it is the parent of all the language-specific
>> and target-specific handle_option functions.
>>
>> The current handle_option reads an option from the command line (from
>> argv), so I would rename it to read_cmdline_option. This change is
>> very minor, because this function is only used in opts.c and called
>> only once.
>>
>> In summary, the new function for handling an option in general would
>> be handle_option, whereas the function for reading an option from the
>> command line would be read_cmdline_option. What do you think about
>> this?
>
> agreed.

Committed as revision 159102.

The bug is only fixed for Wimplicit, all other group options need to
use handle_option to enable sub-options. It would be nice to do this
automatically from the *.opt files. But I am not working on it.

Cheers,

Manuel.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]