Paul Schlie <[EMAIL PROTECTED]> 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
