[C++] Fixes for duplicate warnings regressions [1/2]

On 11/23/2013 08:12 PM, Jason Merrill wrote:
> On 11/10/2013 05:26 AM, Paolo Carlini wrote:
>> this is the issue with -Waddress caused by the fix for c++/56930. I'm
>> handling it as already described, that is by adding a bool parameter to
>> c_common_truthvalue_conversion.
>
> Why not handle this by making that warning respect 
> c_inhibit_evaluation_warnings?

Good question, but it doesn't work, in the sense that we can't simply 
protect the warning itself with "c_inhibit_evaluation_warnings == 0" 
(per the attached) and bump the global around the second cp_convert, 
because then we don't warn *at all*. The reason being that with the 
*first* cp_convert we end up calling c_common_truthvalue_conversion with 
c_inhibit_evaluation_warnings bumped. The bumping happens in 
cp_truthvalue_conversion. A mess, yes. At this Stage, if we don't feel 
like going with something like my last try or something even less 
straightforward reworking the way we bump c_inhibit_evaluation_warnings 
in the various circumstances, I'm tempted to go back to my first try:

-      tree folded_result = cp_convert (type, folded, complain);
+      tree folded_result
+	= folded != expr ? cp_convert (type, folded, complain) : result;


Would it be safe? I mean, is it at all possible that folded == expr and 
in fact we should call again cp_convert? Because otherwise it's also a 
(minor) optimization and radically avoids the problem.

Paolo.

On 11/25/2013 05:02 AM, Paolo Carlini wrote:
> because then we don't warn *at all*. The reason being that with the
> *first* cp_convert we end up calling c_common_truthvalue_conversion with
> c_inhibit_evaluation_warnings bumped. The bumping happens in
> cp_truthvalue_conversion. A mess, yes.

Perhaps cp_truthvalue_conversion should do something more specific to 
the actual warning it's trying to avoid.

> At this Stage, if we don't feel
> like going with something like my last try or something even less
> straightforward reworking the way we bump c_inhibit_evaluation_warnings
> in the various circumstances, I'm tempted to go back to my first try:
>
> -      tree folded_result = cp_convert (type, folded, complain);
> +      tree folded_result
> +    = folded != expr ? cp_convert (type, folded, complain) : result;
>
> Would it be safe? I mean, is it at all possible that folded == expr and
> in fact we should call again cp_convert? Because otherwise it's also a
> (minor) optimization and radically avoids the problem.

That's fine with me.

Jason

Hi,

On 11/25/2013 10:47 PM, Jason Merrill wrote:
> On 11/25/2013 05:02 AM, Paolo Carlini wrote:
>> because then we don't warn *at all*. The reason being that with the
>> *first* cp_convert we end up calling c_common_truthvalue_conversion with
>> c_inhibit_evaluation_warnings bumped. The bumping happens in
>> cp_truthvalue_conversion. A mess, yes.
> Perhaps cp_truthvalue_conversion should do something more specific to 
> the actual warning it's trying to avoid.
Agreed, I'll investigate.
>> At this Stage, if we don't feel
>> like going with something like my last try or something even less
>> straightforward reworking the way we bump c_inhibit_evaluation_warnings
>> in the various circumstances, I'm tempted to go back to my first try:
>>
>> -      tree folded_result = cp_convert (type, folded, complain);
>> +      tree folded_result
>> +    = folded != expr ? cp_convert (type, folded, complain) : result;
>>
>> Would it be safe? I mean, is it at all possible that folded == expr and
>> in fact we should call again cp_convert? Because otherwise it's also a
>> (minor) optimization and radically avoids the problem.
>
> That's fine with me.
Ok.Then, first I'm going to commit this tweak: if we agree that it does 
what I thought it does, it cannot hurt.

Paolo.