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: [PATCH, 4.6 regression]. New error: case label does not reduce


> 
> 
> On 02/15/2012 06:03 PM, Joseph S. Myers wrote:
>> On Wed, 15 Feb 2012, Christian Bruel wrote:
>>
>>> Removal of this NOP_EXPR if !CAN_HAVE_LOCATION_P fixes the problem.
>>> looks safe from my testing, because the loc is inserted using
>>> 'protected_set_expr_location', whereas no loc for a constant case
>>> doesn't seem to introduce new problems with the debugging information.
>>> But in case I also added a few paranoid gcc_assert.
>>
>> Is it safe to set TREE_NO_WARNING without that check?  I'd have thought 
>> the check was to avoid setting TREE_NO_WARNING on a shared node when 
>> warnings are to be disabled in only one context where that node is used.

In fact, we can't omit the TREE_NO_WARNING is !CAN_HAVE_LOCATION_P, the
tentative bellow causes a regression on middle-end/13325.

What I'm unsure is why we couldn't have a TREE_NO_WARNING on a
!CAN_HAVE_LOCATION_P. This seems necessary on some cases without using a
NOP_EXPR.


>>
> 
> OK, I see, we can still keep the check, like with :
> 
> Index: c-common.c
> ===================================================================
> --- c-common.c  (revision 184301)
> +++ c-common.c  (working copy)
> @@ -1435,12 +1435,9 @@
>       have been done by this point, so remove them again.  */
>    nowarning |= TREE_NO_WARNING (ret);
>    STRIP_TYPE_NOPS (ret);
> -  if (nowarning && !TREE_NO_WARNING (ret))
> -    {
> -      if (!CAN_HAVE_LOCATION_P (ret))
> -       ret = build1 (NOP_EXPR, TREE_TYPE (ret), ret);
> -      TREE_NO_WARNING (ret) = 1;
> -    }
> +  if (nowarning && CAN_HAVE_LOCATION_P (ret))
> +    TREE_NO_WARNING (ret) = 1;
> +
>    if (ret != expr)
>      protected_set_expr_location (ret, loc);
>    return ret;
> 
> We propagate the flag to the new node for non-constant folded
> expressions, or for a converted constant (so NOT_EXPR is not stripped),
> 
> Does it make sense to set TREE_NO_WARNING for a not-converted folded
> constant ? it seems that in the proposal, a warning before the fold is
> OK, and a warning after the fold on the new expression is still to be
> honored. The NO_WARNING flag on an non-converted constant that is folded
> looks unnecessary. I tried to forge different scenarios, were the result
> of the folded constant would force a duplicate warning, but no success
> to find a regression case.
> 
> Thanks
> 
> Christian


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