[Bug c/97702] New: comma operator does not drop qualifiers during lvalue conversion

[Bug c/97702] New: comma operator does not drop qualifiers during lvalue conversion

[uecker at eecs dot berkeley.edu]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97702

            Bug ID: 97702
           Summary: comma operator does not drop qualifiers during lvalue
                    conversion
           Product: gcc
           Version: 11.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c
          Assignee: unassigned at gcc dot gnu.org
          Reporter: uecker at eecs dot berkeley.edu
  Target Milestone: ---

The following code 

const int x = 0;
typeof(0, x) y = 0;
y = x;

yields an error because '(0, x)' and then 'y' is const 
qualified. This is incorrect as lvalue conversion
should remove the qualifier (ISO C17 6.3.2.1p2).

I assume this is a residual problem from the time
where GCC had generalized lvalues.

[Bug c/97702] comma operator does not drop qualifiers during lvalue conversion

[joseph at codesourcery dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97702

--- Comment #1 from joseph at codesourcery dot com <joseph at codesourcery dot com> ---
The C front end doesn't have any kind of general lvalue-to-rvalue 
conversion in the IR (other than for atomic lvalues where the code 
required for such a conversion is more than a simple load, as handled by 
convert_lvalue_to_rvalue) that tries to drop qualifiers; the DECL node is 
used directly to represent a load of a variable, even when the rvalue 
would have the unqualified type.  The circumstances in which typeof 
produces a qualified result type are underspecified.  When a C standard 
construct uses a type in a way that cares about qualifiers not being 
present on rvalues (which I think only applies to _Generic), the removal 
is handled at that point; see this code from c_parser_generic_selection:

  selector = default_function_array_conversion (selector_loc, selector);
[...]
  selector_type = TREE_TYPE (selector.value);
  /* In ISO C terms, rvalues (including the controlling expression of
     _Generic) do not have qualified types.  */
  if (TREE_CODE (selector_type) != ARRAY_TYPE)
    selector_type = TYPE_MAIN_VARIANT (selector_type);
  /* In ISO C terms, _Noreturn is not part of the type of expressions
     such as &abort, but in GCC it is represented internally as a type
     qualifier.  */
  if (FUNCTION_POINTER_TYPE_P (selector_type)
      && TYPE_QUALS (TREE_TYPE (selector_type)) != TYPE_UNQUALIFIED)
    selector_type
      = build_pointer_type (TYPE_MAIN_VARIANT (TREE_TYPE (selector_type)));

That said, the resolution of bug 45584 means casts always produce a result 
with explicitly unqualified type (including casts to a qualified type, see 
gcc.dg/pr13519-1.c).  It would seem reasonable to do the same for the 
comma operator.  There will be other places as well that do not remove 
qualifiers when constructing the internal representation for rvalues and 
would need adjusting to make the constness of the IR more consistent.  
One example is applying unary '+' to a const int variable; combine that 
with typeof and it shows the result to be const at present.

[Bug c/97702] comma operator does not drop qualifiers during lvalue conversion

[uecker at eecs dot berkeley.edu]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97702

--- Comment #2 from Martin Uecker <uecker at eecs dot berkeley.edu> ---
Thank you for the explanation.

Interestingly, from the following list, the only example that
removes the cast is the last one (which seems correct
as ISO C specifies casts to produce a value with the
unqualified type, for whatever reason).

#define T1(x) ((void)0,x)
#define T2(x) (+x)
#define T3(x) (-x)
#define T4(x) (1?x:x)
#define T5(x) (*&(x))
#define T6(x) ((const int)x)

int f(void)
{
    const int j = 0;
    __typeof__(T6(j)) i = 0;
    i = 0;
    return i;
}

[Bug c/97702] comma operator does not drop qualifiers during lvalue conversion

[joseph at codesourcery dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97702

--- Comment #3 from joseph at codesourcery dot com <joseph at codesourcery dot com> ---
T5 in that list is an lvalue, so it seems right not to drop qualifiers 
there.

[Bug c/97702] comma operator does not drop qualifiers during lvalue conversion

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97702

--- Comment #4 from Jonathan Wakely <redi at gcc dot gnu.org> ---
N.B. http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2593.htm proposes to
standardise typeof.

[Bug c/97702] comma operator does not drop qualifiers during lvalue conversion

[joseph at codesourcery dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97702

--- Comment #5 from joseph at codesourcery dot com <joseph at codesourcery dot com> ---
A standard version might well end up being handled slightly differently 
from the existing GNU version (cf. _Alignof and __alignof).

[Bug c/97702] comma operator does not drop qualifiers during lvalue conversion

[uecker at eecs dot berkeley.edu]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97702

--- Comment #6 from Martin Uecker <uecker at eecs dot berkeley.edu> ---


https://gcc.gnu.org/git/gitweb.cgi?p=gcc.git;h=32934a4f45a72144cdcd0712cc294fe88c36f13d


Author  Martin Uecker <muecker@gwdg.de> 
Fri, 20 Nov 2020 06:21:40 +0000 (07:21 +0100)
commit  32934a4f45a72144cdcd0712cc294fe88c36f13d

C: Drop qualifiers during lvalue conversion [PR97702]

2020-11-20  Martin Uecker  <muecker@gwdg.de>

gcc/
    * gimplify.c (gimplify_modify_expr_rhs): Optimizie
    NOP_EXPRs that contain compound literals.

gcc/c/
    * c-typeck.c (convert_lvalue_to_rvalue): Drop qualifiers.

gcc/testsuite/
    * gcc.dg/cond-constqual-1.c: Adapt test.
    * gcc.dg/lvalue-11.c: New test.
    * gcc.dg/pr60195.c: Add warning.

[Bug c/97702] comma operator does not drop qualifiers during lvalue conversion

[muecker at gwdg dot de]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97702

Martin Uecker <muecker at gwdg dot de> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
         Resolution|---                         |FIXED

--- Comment #7 from Martin Uecker <muecker at gwdg dot de> ---
Patch committed - marking resolved fixed.