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

[Gabriel Dos Reis <gdr at integrable-solutions dot net>]

Paul Schlie <schlie@comcast.net> writes:

| > Joseph S. Myers writes:
| >> Richard Guenther wrote:
| >> The following snippet
| >> 
| >>       /* Differs from default_conversion by not setting TREE_ADDRESSABLE
| >>          (because calling an inline function does not mean the function
| >>          needs to be separately compiled).  */
| >>       fntype = build_type_variant (TREE_TYPE (function),
| >>                                    TREE_READONLY (function),
| >>                                    TREE_THIS_VOLATILE (function));
| >>       fundecl = function;
| >>       function = build1 (ADDR_EXPR, build_pointer_type (fntype),
| >> function);
| >
| > If you want to avoid this then you need to arrange for const and noreturn
| > attributes on functions always to be represented by qualifiers on the type
| > and not on the decl.  This is part of bug 3481.
| 
| I wonder if further a read-only 'literal' type qualifier should be added
| as an implicitly declared type qualifier, thereby allowing implicitly
| declared literal values/references to be effectively and reliably tracked,
| without the complexity of relying on the use of READONLY_TREES, etc.

As I already explained you, in C++ "const" does exactly that.
C adopted a different meaning when it adopted "const", but the
compiler is allowed -- after checking semantics restrictions -- to
internally do constant propagation. I'm agnostic of yet another type
qualifier. 

| 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,

-- Gaby