Re: Mismatched types in ADDR_EXPR fromc-typeck.c:build_function_call

[Paul Schlie <schlie at comcast dot net>]

> From: Gabriel Dos Reis <gdr@integrable-solutions.net>
> <rguenth@tat.physik.uni-tuebingen.de>, <gcc@gcc.gnu.org>
> Subject: Re: Mismatched types in ADDR_EXPR from c-typeck.c:build_function_call
> 
> | Thereby all literal values are implied to be qualified as a read-only
> | 'literal' object/reference, which has the semantics, that it may not be
> | assigned/modified, but unlike 'const' may not be cast away; thereby for
> 
> If you cast away a const, you're still not allowed to modify the
> object, so the compiler is still allowed to do the optimization.
> Notice any type qualifier can be casted away, so introducing one does
> not solve the problem, it just adds another complexity,

Unless a 'literal' qualifier is defined as being sticky; never "cast away".
(Eliminating the complexity associated with having to track and maintain
READONLY tree attributes distinct from an object's declared qualified type?)

I apologize if I'm belabored this issue too much, but do so predominantly
resulting from observing that GCC's present inconsistent use of the tree
READONLY/unchanging attribute to track and maintain proper semantic
treatment of literal values and references, need not be distinct from an
object's qualified type, thereby also enabling more strictly correct
qualification semantics be applied to function arguments and return value
types then otherwise seemingly possible, thereby producing a more flexible
and consistent representation of objects/references and their semantics.

(I'll leave it be, but obviously wanted to try to plant another seed.)