This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC 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: [C++, diagnostic, obvious?] Typo in fix for PR 35058


Hi,
> 2009/1/28 Paolo Carlini <paolo.carlini@oracle.com>:
>   
>> Hi Manuel, Gaby, all,
>>
>> which certainly looks very strange and inconsistent with the other
>> changes in the same patch. I'm pretty sure the below was really
>> intended, I'm tempted to commit it as obvious, but I'll wait a couple of
>> days, to be sure...
>>     
> I am not so sure about this. Is this actually a permerror or a
> pedwarn?
It is a pederror, I included in my first email a verbatim excerpt from
the changes in r138089.
>  If it is a real permerror, then I honestly do not know what
> the original code intended when (pedantic || complain == tf_none) was
> false. And it seems strange that my patch changed that. It seems we do
> not have a testcase that triggers this diagnostic.
>   
I see. Certainly the current code doesn't make much sense.
> There is another dubious case in the same function:
>
> 	    else if ((pedantic || warn_pointer_arith)
> 		     && !TYPE_PTROB_P (argtype))
>               {
>                 if (complain & tf_error)
>                   permerror (input_location, (code == PREINCREMENT_EXPR
>                               || code == POSTINCREMENT_EXPR)
>                              ? G_("ISO C++ forbids incrementing a
> pointer of type %qT")
>                              : G_("ISO C++ forbids decrementing a
> pointer of type %qT"),
>                              argtype);
>                 else
>                   return error_mark_node;
>               }
>
> As a rule-of-thumb, permerrors should never be conditional on pedantic
> or warn_*. Otherwise, enabling warning flags may actually trigger new
> errors. Hence, either this should actually be a pedwarn or we should
> remove both pedantic and warn_pointer_arith from here. It all depends
> on what the standard says and what we support something as an
> extension.
>   
Ok. I'll try to look further into both, then. But I have other things in
my queue, thus if you feel like taking care of this one, just go ahead,
I would appreciate it.

Thanks,
Paolo.


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