Studying note of GCC-3.4.6 source (145)

5.13.

Stage after parsing

5.13.1.

Preliminaries - detail of conversion

5.13.1.1.

Determine appropriate conversion

C++ is a type-strong language. However, in practice, we always can
write code like: “1 + 5.0f;”,
in which “1” is of
integer type, and “5.0f” is of
floating point type. We can even write more amazing code like: “a + b;”
assuming both “a” and “b” are instances of certain class. It dues to the
compiler will generate code for us to do the necessary and appropriate
conversions. In this section, we will see the conversions that compiler will
use behind and rules of these conversions enacted by the language standard.

We first begin with function can_convert_arg

, which is used to test if two
specified types agree with each other.

5996

bool

5997

can_convert_arg

(tree to, tree from,
tree arg)
in
call.c

5998

{

5999

tree t = implicit_conversion
(to, from, arg, LOOKUP_NORMAL);

6000

return
(t
&& ! ICS_BAD_FLAG (t));

6001

}

Indicated by
its name, conversions carried in below function, are those the compiler can be
used freely as it considers as appropriately. It is one of interesting and
powerful features of C++ language; and frequently confuses programmer even the
seniors. In [3], section 13.3.3.1
“Implicit conversion sequences” explains what implicit conversion is in detail:

1. An implicit conversion sequence is a sequence of conversions used to convert an argument in a function call to the type of the corresponding parameter of the function being called. The sequence of conversions is an implicit conversion as defined in clause 4, which means it is governed by the rules for initialization of an object or reference by a single expression (8.5, 8.5.3). 2. Implicit conversion sequences are concerned only with the type, cv-qualification, and lvalueness of the argument and how these are converted to match the corresponding properties of the parameter. Other properties, such as the lifetime, storage class, alignment, or accessibility of the argument and whether or not the argument is a bit-field are ignored. So, although an implicit conversion sequence can be defined for a given argument-parameter pair, the conversion from the argument to the parameter might still be ill-formed in the final analysis. 3. A well-formed implicit conversion sequence is one of the following forms: — a standard conversion sequence (13.3.3.1.1), — a user-defined conversion sequence (13.3.3.1.2), or — an ellipsis conversion sequence (13.3.3.1.3). 4. However, when considering the argument of a user-defined conversion function that is a candidate by 13.3.1.3 when invoked for the copying of the temporary in the second step of a class copy-initialization, or by 13.3.1.4, 13.3.1.5, or 13.3.1.6 in all cases, only standard conversion sequences and ellipsis conversion sequences are allowed. 5. For the case where the parameter type is a reference, see 13.3.3.1.4. (reference binding ) 6. When the parameter type is not a reference, the implicit conversion sequence models a copy-initialization of the parameter from the argument expression. The implicit conversion sequence is the one required to convert the argument expression to an rvalue of the type of the parameter. [Note: when the parameter has a class type, this is a conceptual conversion defined for the purposes of clause 13; the actual initialization is defined in terms of constructors and is not a conversion.] Any difference in top-level cv-qualification is subsumed by the initialization itself and does not constitute a conversion. [Example: a parameter of type A can be initialized from an argument of type const A. The implicit conversion sequence for that case is the identity sequence; it contains no “conversion” from const A to A.] When the parameter has a class type and the argument expression has the same type, the implicit conversion sequence is an identity conversion. When the parameter has a class type and the argument expression has a derived class type, the implicit conversion sequence is a derived-to-base Conversion from the derived class to the base class. [Note: there is no such standard conversion; this derived-to-base Conversion exists only in the description of implicit conversion sequences.] A derived-to-base Conversion has Conversion rank (13.3.3.1.1). 7. In all contexts, when converting to the implicit object parameter or when converting to the left operand of an assignment operation only standard conversion sequences that create no temporary object for the result are allowed. 8. If no conversions are required to match an argument to a parameter type, the implicit conversion sequence is the standard conversion sequence consisting of the identity conversion (13.3.3.1.1). 9. If no sequence of conversions can be found to convert an argument to a parameter type or the conversion is otherwise ill-formed, an implicit conversion sequence cannot be formed. 10. If several different sequences of conversions exist that each convert the argument to the parameter type, the implicit conversion sequence associated with the parameter is defined to be the unique conversion sequence designated the ambiguous conversion sequence. For the purpose of ranking implicit conversion sequences as described in 13.3.3.2, the ambiguous conversion sequence is treated as a user-defined sequence that is indistinguishable from any other user-defined conversion sequence (The ambiguous conversion sequence is ranked with user-defined conversion sequences because multiple conversion sequences for an argument can exist only if they involve different user-defined conversions. The ambiguous conversion sequence is indistinguishable from any other user-defined conversion sequence because it represents at least two user-defined conversion sequences, each with a different user-defined conversion, and any other user-defined conversion sequence must be indistinguishable from at least one of them. This rule prevents a function from becoming non-viable because of an ambiguous conversion sequence for one of its parameters. Consider this example, class B; class A { A (B&); }; class B { operator A (); }; class C { C (B&); }; void f(A) { } void f(C) { } B b; f(b); //ambiguous because b -> C via constructor and // b -> A via constructor or conversion function. If it were not for this rule, f(A) would be eliminated as a viable function for the call f(b) causing overload resolution to select f(C) as the function to call even though it is not clearly the best choice. On the other hand, if an f(B) were to be declared then f(b) would resolve to that f(B) because the exact match with f(B) is better than any of the sequences required to match f(A). If a function that uses the ambiguous conversion sequence is selected as the best viable function, the call will be ill-formed because the conversion of one of the arguments in the call is ambiguous. 11. The three forms of implicit conversion sequences mentioned above are defined in the following subclauses.

Before going ahead into
the code, first we need clarify the concept of lvalue and rvalue. An lvalue
refers to an object or function. It must be an entity that is addressable; i.e.,
if it refers to object, it should be able to be placed on left-hand-side of an
assignment operation (that is why it called lvalue). And those that are
non-lvalue are called rvalue (which can’t be used on left-hand-side of
assginment operation).

1097

static
tree

1098

implicit_conversion

(tree to, tree from, tree expr, int flags)
in call.c

1099

{

1100

tree conv;

1101

1102

if (from == error_mark_node
|| to == error_mark_node

1103

|| expr ==
error_mark_node)

1104

return
NULL_TREE;

1105

1106

if (TREE_CODE (to) ==
REFERENCE_TYPE)

1107

conv = reference_binding
(to, from, expr, flags);

1108

else

1109

conv = standard_conversion
(to, from, expr, flags);

1110

1111

if (conv)

1112

return
conv;

1113

1114

if (expr != NULL_TREE

1115

&& (IS_AGGR_TYPE
(from)

1116

|| IS_AGGR_TYPE
(to))

1117

&& (flags &
LOOKUP_NO_CONVERSION) == 0)

1118

{

1119

struct
z_candidate
*cand;

1120

1121

cand = build_user_type_conversion_1

1122

(to, expr,
LOOKUP_ONLYCONVERTING);

1123

if (cand)

1124

conv =
cand->second_conv;

1125

1126

/*
We used to try to bind a reference to a temporary here, but that

1127

now
handled by the recursive call to this function at the end

1128

of
reference_binding.
*/

1129

return
conv;

1130

}

1131

1132

return
NULL_TREE;

1133

}

See the conversion processing routines may recurse each other, here
to handle reference type, the function invokes reference_binding

again.
However, as we are going forward within the tree of the expression, as long as
no loop back of dependence exists there will not be the infinite recursion. And
as C++ is the language requires declaration before using, mutual dependence is illegal;
the parser should be able to find out this ill form.

5.13.1.1.1.

Case
of standard conversion sequence

[3] section 13.3.3.1.1
“Standard conversion sequence” gives detail about the sequence.

1. Table 9 summarizes the conversions defined in clause 4 (“Standard conversions”, section 4 in [3]) and partitions them into four disjoint categories: Lvalue Transformation, Qualification Adjustment, Promotion, and Conversion. [Note: these categories are orthogonal with respect to lvalue-ness, cv-qualification, and data representation: the Lvalue Transformations do not change the cv-qualification or data representation of the type; the Qualification Adjustments do not change the lvalue -ness or data representation of the type; and the Promotions and Conversions do not change the lvalue-ness or cv-qualification of the type.] 2. [Note: As described in clause 4, a standard conversion sequence is either the Identity conversion by itself (that is, no conversion) or consists of one to three conversions from the other four categories. At most one conversion from each category is allowed in a single standard conversion sequence. If there are two or more conversions in the sequence, the conversions are applied in the canonical order: Lvalue Transformation , Promotion or Conversion , Qualification Adjustment . —end note ] 3. Each conversion in Table 9 also has an associated rank (Exact Match, Promotion, or Conversion). These are used to rank standard conversion sequences (13.3.3.2). The rank of a conversion sequence is determined by considering the rank of each conversion in the sequence and the rank of any reference binding (13.3.3.1.4). If any of those has Conversion rank, the sequence has Conversion rank; otherwise, if any of those has Promotion rank, the sequence has Promotion rank; otherwise, the sequence has Exact Match rank. Table 9: - conversions Conversion Category Rank Subclause No conversions required Identity Exact Match Lvalue-to-rvalue conversion Lvalue Transformation 4.1 Array-to-pointer conversion 4.2 Function-to-pointer conversion 4.3 Qualification conversion Qualification Adjustment 4.4 Integral promotions Promotion Promotion 4.5 Floating point promotion 4.6 Integral conversion Conversion Conversion 4.7 Floating point conversion 4.8 Floating-integral conversions 4.9 Pointer conversions 4.10 Pointer to member conversions 4.11 Boolean conversions 4.12

Below we just skip the
resolving of overload from line 472 to 479 (it will be covered by section about
reference binding, remember type_unknown_p

returns true if expr

is
an overload). Always keep in mind that below standard_conversion

handles
implicit conversion, only conversions mentioned in above table are considered; never confuse it with
force conversion.

456

static
tree

457

standard_conversion

(tree to, tree from,
tree expr, int flags)
in
call.c

458

{

459

enum
tree_code fcode, tcode;

460

tree conv;

461

bool fromref = false;

462

463

to = v (to);

464

if (TREE_CODE (from) == REFERENCE_TYPE)

465

{

466

fromref = true;

467

from = TREE_TYPE (from);

468

}

469

to = strip_top_quals (to);

470

from = strip_top_quals (from);

471

472

if ((TYPE_PTRFN_P (to) || TYPE_PTRMEMFUNC_P
(to))

473

&& expr && type_unknown_p
(expr))

474

{

475

expr = instantiate_type (to, expr,
tf_conv);

476

if (expr == error_mark_node)

477

return
NULL_TREE;

478

from = TREE_TYPE (expr);

479

}

480

481

fcode = TREE_CODE (from);

482

tcode = TREE_CODE (to);

483

484

conv = build1
(IDENTITY_CONV, from, expr);

485

486

if (fcode == FUNCTION_TYPE)

487

{

488

from = build_pointer_type
(from);

489

fcode = TREE_CODE (from);

490

conv = build_conv
(LVALUE_CONV, from, conv);

491

}

492

else if (fcode == ARRAY_TYPE)

493

{

494

from = build_pointer_type
(TREE_TYPE (from));

495

fcode = TREE_CODE (from);

496

conv = build_conv
(LVALUE_CONV, from, conv);

497

}

498

else if (fromref || (expr
&& lvalue_p
(expr)))

499

conv = build_conv
(RVALUE_CONV, from, conv);

500

501

/* Allow conversion
between `__complex__' data types.
*/

502

if (tcode == COMPLEX_TYPE && fcode ==
COMPLEX_TYPE)

503

{

504

/* The standard
conversion sequence to convert FROM to TO is

505

the standard conversion
sequence to perform componentwise

506

conversion.
*/

507

tree part_conv = standard_conversion

508

(TREE_TYPE (to), TREE_TYPE (from),
NULL_TREE, flags);

509

510

if (part_conv)

511

{

512

conv = build_conv
(TREE_CODE (part_conv), to, conv);

513

ICS_STD_RANK (conv) = ICS_STD_RANK
(part_conv);

514

}

515

else

516

conv = NULL_TREE;

517

518

return
conv;

519

}

520

521

if (same_type_p (from, to))

522

return
conv;

Line 484 builds IDENTITY_COV for identity conversion. The type of *_CONV
node indicates the source type and its first operand is the expression to be
converted. So conversion sequence will be built with a big nested *_CONV node,
with the top *_CONV is the last conversion being done, and the innermost being the
first which always is IDENTITY_CONV.

In internal, the front-end defines following ranks for conversions
instead those shown by table-9 above. And note that the less value indicates more
preference.

343

#define
IDENTITY_RANK
0
in
call.c

344

#define
EXACT_RANK
1

345

#define
PROMO_RANK
2

346

#define
STD_RANK
3

347

#define
PBOOL_RANK
4

348

#define
USER_RANK
5

349

#define
ELLIPSIS_RANK
6

350

#define
BAD_RANK
7

Conversions that can be generated internally include: IDENTITY_CONV,
LVALUE_CONV, QUAL_CONV, STD_CONV, PTR_CONV, PMEM_CONV, BASE_CONV, REF_BIND, USER_CONV,
AMBIG_CONV, and RVALUE_CONV.

408

static
tree

409

build_conv

(enum
tree_code code, tree type, tree from)
in
call.c

410

{

411

tree t;

412

int rank = ICS_STD_RANK (from);

413

414

/* We can't use
buildl1 here because CODE could be USER_CONV, which

415

takes two
arguments. In that case, the caller is responsible for

416

filling in the
second argument.

*/

417

t
=
make_node

(code);

418

TREE_TYPE (t) = type;

419

TREE_OPERAND (t, 0) = from;

420

421

switch
(code)

422

{

423

case
PTR_CONV:

424

case
PMEM_CONV:

425

case
BASE_CONV:

426

case
STD_CONV:

427

if (rank < STD_RANK)

428

rank = STD_RANK;

429

break
;

430

431

case
QUAL_CONV:

432

if (rank < EXACT_RANK)

433

rank = EXACT_RANK;

434

435

default
:

436

break
;

437

}

438

ICS_STD_RANK (t) = rank;

439

ICS_USER_FLAG (t) = (code == USER_CONV || ICS_USER_FLAG (from));

440

ICS_BAD_FLAG (t) = ICS_BAD_FLAG (from);

441

return
t;

442

}

In above function, ICS_STD_RANK in fact will store the highest rank value
seen so far, whose usage we will see in later paragraphes.

Then above line 486 and 492 in standard_conversion

handle
function-to-pointer and array-to-point conversion, which is described by [3]
clause 4.2 “Array-to-pointer conversion and clause” 4.3 “Function-to-pointer
conversion” as below.

1. An lvalue or rvalue of type “array ofN T” or “array of unknown bound of T” can be converted to an rvalue of type “pointer to T.” The result is a pointer to the first element of the array. 2. A string literal (2.13.4) that is not a wide string literal can be converted to an rvalue of type “pointer to char”; a wide string literal can be converted to an rvalue of type “pointer to wchar_t”. In either case, the result is a pointer to the first element of the array. This conversion is considered only when there is an explicit appropriate pointer target type, and not when there is a general need to convert from an lvalue to an rvalue . [Note: this conversion is deprecated. See Annex D.] For the purpose of ranking in overload resolution (13.3.3.1.1), this conversion is considered an array-to-pointer conversion followed by a qualification conversion (4.4). [Example: "abc" is converted to “pointer to const char” as an array-to-pointer conversion, and then to “pointer to char” as a qualification conversion.]

1. An lvalue of function type T can be converted to an rvalue of type “pointer to T.” The result is a pointer to the function. (This conversion never applies to nonstatic member functions because an lvalue that refers to a nonstatic member function cannot be obtained.) 2. [Note: See 13.4 for additional rules for the case where the function is overloaded.]

Note that in terms 1 of
both clauses, rvalue of type “pointer to T” just means the pointer itself can’t
be modified, but its content can be changed. For example:

char a[10];

char *p = …;

a = p;
// a is
converted to rvalue of char*, assignment not allowed

*(a+1) = *p;
// object pointed
by a+1 is lvalue, it is OK

Compared with below clause, these two clauses include creation of pointer
type, the front-end must tells out these two situations from other cases of
lvalue transformation. So the front-end uses LVALUE_CONV for them.

Then in standard_conversion

,
arriving at line 498, if the condition is satisified, terms 1 mentioned in [3]
clause 4.1 “Lvalue-to-rvalue conversion” will be implemented. The front-end
uses RVALUE_CONV for the case. One difference of LVALUE_CONV and RVALUE_CONV is
that when building LVALUE_CONV, we have known the rvalue (see the pointer type
built at line 488 and 494), while for RVALUE_CONV, the rvalue is unknown at
that point, and later the front-end needs invoke decay_conversion

to do the
real conversion.

1. An lvalue (3.10) of a non-function, non-array type T can be converted to an rvalue . If T is an incomplete type, a program that necessitates this conversion is ill-formed. If the object to which the lvalue refers is not an object of type T and is not an object of a type derived from T, or if the object is uninitialized, a program that necessitates this conversion has undefined behavior. If T is a non-class type, the type of the rvalue is the cv-unqualified version of T. Otherwise, the type of the rvalue is T. [In C++ class rvalues can have cv-qualified types (because they are objects). This differs from ISO C, in which non-lvalues never have cv-qualified types.] 2. The value contained in the object indicated by the lvalue is the rvalue result. When an lvalue-to-rvalue conversion occurs within the operand of sizeof (5.3.3) the value contained in the referenced object is not accessed, since that operator does not evaluate its operand.

Focus upon following
function, given expression ref

, it can tell if it is lvalue or not. And see
that pointer type built for LVALUE_CONV above is rvalue told by this function.
This function should be studied carefully.

211

int

212

lvalue_p

(tree ref)
in
tree.c

213

{

214

return

215

(lvalue_p_1
(ref,
/*class rvalue ok*/
1) != clk_none);

216

}

The various kinds of lvalues we distinguish are given in below.

2964

typedef
enum
cp_lvalue_kind {
in
cp-tree.h

2965

clk_none = 0,
/* Things that
are not an lvalue.
*/

2966

clk_ordinary = 1, /* An ordinary lvalue.

*/

2967

clk_class = 2,
/* An rvalue of
class-type.
*/

2968

clk_bitfield = 4, /* An lvalue for a bit-field.
*/

2969

clk_packed = 8
/* An lvalue for
a packed field.
*/

2970

} cp_lvalue_kind
;

In [3], clause
3.10 (lvalues and rvalues), gives the following explaination.

1. Every expression is either an lvalue or an rvalue . 2. An lvalue refers to an object or function. Some rvalue expressions—those of class or cv-qualified class type—also refer to objects (Expressions such as invocations of constructors and of functions that return a class type refer to objects, and the implementation can invoke a member function upon such objects, but the expressions are not lvalues ). 3. [Note: some built-in operators and function calls yield lvalues . [Example: if E is an expression of pointer type, then *E is an lvalue expression referring to the object or function to which E points. As another example, the function int& f(); yields an lvalue , so the call f() is an lvalue expression.]] 4. [Note: some builtin operators expect lvalue operands. [Example: built-in assignment operators all expect their left hand operands to be lvalues .] Other built-in operators yield rvalues , and some expect them. [Example: the unary and binary + operators expect rvalue arguments and yield rvalue results.] The discussion of each built-in operator in clause 5 indicates whether it expects lvalue operands and whether it yields an lvalue .] 5. The result of calling a function that does not return a reference is an rvalue . User defined operators are functions, and whether such operators expect or yield lvalues is determined by their parameter and return types. 6. An expression which holds a temporary object resulting from a cast to a nonreference type is an rvalue (this includes the explicit creation of an object using functional notation (5.2.3)). 7. Whenever an lvalue appears in a context where an rvalue is expected, the lvalue is converted to an rvalue ; see 4.1, 4.2, and 4.3. 8. The discussion of reference initialization in 8.5.3 and of temporaries in 12.2 indicates the behavior of lvalues and rvalues in other significant contexts. 9. Class rvalues can have cv-qualified types; non-class rvalues always have cv-unqualified types. Rvalues shall always have complete types or the void type; in addition to these types, lvalues can also have incomplete types. 10. An lvalue for an object is necessary in order to modify the object except that an rvalue of class type can also be used to modify its referent under certain circumstances. [Example: a member function called for an object (9.3) can modify the object.] 11. Functions cannot be modified, but pointers to functions can be modifiable. 12. A pointer to an incomplete type can be modifiable. At some point in the program when the pointed to type is complete, the object at which the pointer points can also be modified. 13. The referent of a const-qualified expression shall not be modified (through that expression), except that if it is of class type and has a mutable component, that component can be modified (7.1.5.1). 14. If an expression can be used to modify the object to which it refers, the expression is called modifiable. A program that attempts to modify an object through a nonmodifiable lvalue or rvalue expression is illformed. 15. If a program attempts to access the stored value of an object through an lvalue of other than one of the following types the behavior is undefined (The intent of this list is to specify those circumstances in which an object may or may not be aliased): — the dynamic type of the object, — a cv-qualified version of the dynamic type of the object, — a type that is the signed or unsigned type corresponding to the dynamic type of the object, — a type that is the signed or unsigned type corresponding to a cv-qualified version of the dynamic type of the object, — an aggregate or union type that includes one of the aforementioned types among its members (including, recursively, a member of a subaggregate or contained union), — a type that is a (possibly cv-qualified) base class type of the dynamic type of the object, — a char or unsigned char type.

Considering non-static
method processed below, as non-static method must be invoked as: “a.fa();” with
given object which may not addressable (for example, in statement “A().fa();”,
“A()” returns an rvalue), non-static method is just considered as rvalue. Further,
expression “A().fa();” can modify the object, so “A()” can be considered as
lvalue if not require strict lvalue (argument treat_class_rvalues_as_lvalues

is
1). Pay attention to TARGET_EXPR at line 156, it would wrapsthe temperary
object returned by “A()” ( see comment at line 161).

62

static
cp_lvalue_kind

63

lvalue_p_1

(tree ref,
in
tree.c

64

int treat_class_rvalues_as_lvalues)

65

{

66

cp_lvalue_kind op1_lvalue_kind = clk_none;

67

cp_lvalue_kind op2_lvalue_kind = clk_none;

68

69

if (TREE_CODE (TREE_TYPE (ref)) ==
REFERENCE_TYPE)

70

return
clk_ordinary;

71

72

if (ref == current_class_ptr

)

73

return
clk_none;

74

75

switch
(TREE_CODE (ref))

76

{

77

/* preincrements and predecrements are valid
lvals, provided

78

what they refer
to are valid lvals.
*/

79

case
PREINCREMENT_EXPR:

80

case
PREDECREMENT_EXPR:

81

case
SAVE_EXPR:

82

case
UNSAVE_EXPR:

83

case
TRY_CATCH_EXPR:

84

case
WITH_CLEANUP_EXPR:

85

case
REALPART_EXPR:

86

case
IMAGPART_EXPR:

87

return
lvalue_p_1 (TREE_OPERAND (ref, 0),

88

treat_class_rvalues_as_lvalues);

89

90

case
COMPONENT_REF:

91

op1_lvalue_kind = lvalue_p_1
(TREE_OPERAND (ref, 0),

92

treat_class_rvalues_as_lvalues);

93

/* In an
expression of the form "X.Y", the packed-ness of the

94

expression
does not depend on "X".
*/

95

op1_lvalue_kind &= ~clk_packed;

96

/* Look at the member designator.
*/

97

if (!op1_lvalue_kind

98

/* The
"field" can be a FUNCTION_DECL or an OVERLOAD in some

99

situations.
*/

100

|| TREE_CODE (TREE_OPERAND (ref, 1))
!= FIELD_DECL)

101

;

102

else if (DECL_C_BIT_FIELD (TREE_OPERAND
(ref, 1)))

103

{

104

/* Clear the
ordinary bit. If this object was a class

105

rvalue we
want to preserve that information.
*/

106

op1_lvalue_kind &= ~clk_ordinary;

107

/* The lvalue
is for a bitfield.
*/

108

op1_lvalue_kind |= clk_bitfield;

109

}

110

else if (DECL_PACKED (TREE_OPERAND (ref,
1)))

111

op1_lvalue_kind |= clk_packed;

112

113

return
op1_lvalue_kind;

114

115

case
STRING_CST:

116

return
clk_ordinary;

117

118

case
VAR_DECL:

119

if (TREE_READONLY (ref) && !
TREE_STATIC (ref)

120

&& DECL_LANG_SPECIFIC (ref)

121

&& DECL_IN_AGGR_P (ref))

122

return
clk_none;

123

case
INDIRECT_REF:

124

case
ARRAY_REF:

125

case
PARM_DECL:

126

case
RESULT_DECL:

127

if (TREE_CODE (TREE_TYPE (ref)) !=
METHOD_TYPE)

128

return
clk_ordinary;

129

break
;

130

131

/* A currently unresolved scope ref.
*/

132

case
SCOPE_REF:

133

abort ();

134

case
MAX_EXPR:

135

case
MIN_EXPR:

136

op1_lvalue_kind = lvalue_p_1
(TREE_OPERAND (ref, 0),

137

treat_class_rvalues_as_lvalues);

138

op2_lvalue_kind = lvalue_p_1
(TREE_OPERAND (ref, 1),

139

treat_class_rvalues_as_lvalues);

140

break
;

141

142

case
COND_EXPR:

143

op1_lvalue_kind = lvalue_p_1
(TREE_OPERAND (ref, 1),

144

treat_class_rvalues_as_lvalues);

145

op2_lvalue_kind = lvalue_p_1
(TREE_OPERAND (ref, 2),

146

treat_class_rvalues_as_lvalues);

147

break
;

148

149

case
MODIFY_EXPR:

150

return
clk_ordinary;

151

152

case
COMPOUND_EXPR:

153

return
lvalue_p_1 (TREE_OPERAND (ref, 1),

154

treat_class_rvalues_as_lvalues);

155

156

case
TARGET_EXPR:

157

return
treat_class_rvalues_as_lvalues ? clk_class : clk_none;

158

159

case
CALL_EXPR:

160

case
VA_ARG_EXPR:

161

/* Any class-valued
call would be wrapped in a TARGET_EXPR.

*/

162

return
clk_none;

163

164

case
FUNCTION_DECL:

165

/* All
functions (except non-static-member functions) are

166

lvalues.
*/

167

return
(DECL_NONSTATIC_MEMBER_FUNCTION_P (ref)

168

? clk_none : clk_ordinary);

169

170

case
NON_DEPENDENT_EXPR:

171

/* We must
consider NON_DEPENDENT_EXPRs to be lvalues so that

172

things like
"&E" where "E" is an expression with a

173

non-dependent
type work. It is safe to be lenient because an

174

error will be
issued when the template is instantiated if "E"

175

is not an
lvalue.
*/

176

return
clk_ordinary;

177

178

default
:

179

break
;

180

}

181

182

/* If one operand is
not an lvalue at all, then this expression is

183

not an
lvalue.
*/

184

if (!op1_lvalue_kind || !op2_lvalue_kind)

185

return
clk_none;

186

187

/* Otherwise, it's
an lvalue, and it has all the odd properties

188

contributed by
either operand.
*/

189

op1_lvalue_kind = op1_lvalue_kind |
op2_lvalue_kind;

190

/* It's not an
ordinary lvalue if it involves either a bit-field or

191

a class
rvalue.
*/

192

if ((op1_lvalue_kind & ~clk_ordinary) !=
clk_none)

193

op1_lvalue_kind &= ~clk_ordinary;

194

return
op1_lvalue_kind;

195

}

Above, NON_DEPENDENT_EXPR is a placeholder for an expression that is
not type-dependent, but does occur in a template. See INDIRECT_REF is lvalue
(however pointer is rvalue itself, it is the case described by terms 3 above);
and normal variable is also lvalue (line 118); further if an array is referred,
its reference is lvalue, otherwise the array would be decayed to pointer of
rvalue. Next note that MODIFY_EXPR at line 149, no doubt must be lvalue, and
COMPOUND_EXPR following depends on its second operand. And for expressions may
contains operand of lvalue, lvalue_p_1

recurs into the operand.

It is worth note that call expression “f();” of “int& f();” is
lvalue, but expression like “f() = 5;” is illegal; the only case this lvalue
can be used directly is using “f()” as parameter which is covered by PARM_DECL
at line 125; so CALL_EXPR not within PARM_DECL is just regarded as rvalue.
Further, being lvalue, PARM_DECL, RESULT_DECL, ARRAY_REF, and INDIRECT_REF can
be of type of non-static method of class.

standard_conversion (continue)

524

if ((tcode == POINTER_TYPE ||
TYPE_PTR_TO_MEMBER_P (to))

525

&& expr && null_ptr_cst_p
(expr))

526

conv = build_conv
(STD_CONV, to, conv);

527

else if (tcode == POINTER_TYPE &&
fcode == POINTER_TYPE

528

&& TREE_CODE (TREE_TYPE (to))
== VECTOR_TYPE

529

&& TREE_CODE (TREE_TYPE (from))
== VECTOR_TYPE

530

&& ((*targetm

.vector_opaque_p) (TREE_TYPE
(to))

531

|| (*targetm

.vector_opaque_p)
(TREE_TYPE (from))))

532

conv = build_conv
(STD_CONV, to, conv);

533

else
if ((tcode == INTEGER_TYPE && fcode == POINTER_TYPE)

534

|| (tcode == POINTER_TYPE && fcode == INTEGER_TYPE))

535

{

536

/* For backwards
brain damage compatibility, allow interconversion of

537

pointers and
integers with a pedwarn.
*/

538

conv = build_conv
(STD_CONV, to, conv);

539

ICS_BAD_FLAG (conv) = 1;

540

}

541

else if (tcode == ENUMERAL_TYPE &&
fcode == INTEGER_TYPE)

542

{

543

/* For backwards
brain damage compatibility, allow interconversion of

544

enums and
integers with a pedwarn.
*/

545

conv = build_conv
(STD_CONV, to, conv);

546

ICS_BAD_FLAG (conv) = 1;

547

}

Note above, converting between pointers and integers and between
integers and enums are both bad conversions in the context of C++ langauge (but
it just gives warning under C). So the conversion is recorded and given the
rank of lowest priority.

standard_conversion (continue)

548

else if ((tcode == POINTER_TYPE &&
fcode == POINTER_TYPE)

549

|| (TYPE_PTRMEM_P (to) &&
TYPE_PTRMEM_P (from)))

550

{

551

tree to_pointee;

552

tree from_pointee;

553

554

if (tcode == POINTER_TYPE

555

&&
same_type_ignoring_top_level_qualifiers_p (TREE_TYPE (from),

556

TREE_TYPE (to)))

557

;

558

else if (VOID_TYPE_P (TREE_TYPE (to))

559

&& !TYPE_PTRMEM_P (from)

560

&& TREE_CODE (TREE_TYPE
(from)) != FUNCTION_TYPE)

561

{

562

from = build_pointer_type

563

(cp_build_qualified_type (void_type_node,

564

cp_type_quals (TREE_TYPE (from))));

565

conv = build_conv
(PTR_CONV, from, conv);

566

}

567

else if (TYPE_PTRMEM_P (from))

568

{

569

tree fbase = TYPE_PTRMEM_CLASS_TYPE
(from);

570

tree tbase = TYPE_PTRMEM_CLASS_TYPE (to);

571

572

if (DERIVED_FROM_P (fbase, tbase)

573

&&
(same_type_ignoring_top_level_qualifiers_p

574

(TYPE_PTRMEM_POINTED_TO_TYPE (from),

575

TYPE_PTRMEM_POINTED_TO_TYPE
(to))))

576

{

577

from = build_ptrmem_type (tbase,

578

TYPE_PTRMEM_POINTED_TO_TYPE (from));

579

conv = build_conv
(PMEM_CONV, from, conv);

580

}

581

else if (!same_type_p (fbase, tbase))

582

return
NULL;

583

}

584

else if (IS_AGGR_TYPE (TREE_TYPE (from))

585

&& IS_AGGR_TYPE (TREE_TYPE
(to))

586

/* [conv.ptr]

587

588

An rvalue of
type "pointer to cv D," where D is a

589

class type,
can be converted to an rvalue of type

590

"pointer
to cv B," where B is a base class (clause

591

_class.derived_) of D. If B is an inaccessible

592

(clause
_class.access_) or ambiguous

593

(_class.member.lookup_) base class of D, a program

594

that
necessitates this conversion is ill-formed.

*/

595

/* Therefore,
we use DERIVED_FROM_P, and not

596

ACESSIBLY_UNIQUELY_DERIVED_FROM_P,
in this test.
*/

597

&& DERIVED_FROM_P (TREE_TYPE
(to), TREE_TYPE (from)))

598

{

599

from =

600

cp_build_qualified_type (TREE_TYPE
(to),

601

cp_type_quals
(TREE_TYPE (from)));

602

from = build_pointer_type
(from);

603

conv = build_conv
(PTR_CONV, from, conv);

604

}

605

606

if (tcode == POINTER_TYPE)

607

{

608

to_pointee = TREE_TYPE (to);

609

from_pointee = TREE_TYPE (from);

610

}

611

else

612

{

613

to_pointee = TYPE_PTRMEM_POINTED_TO_TYPE
(to);

614

from_pointee =
TYPE_PTRMEM_POINTED_TO_TYPE (from);

615

}

616

617

if (same_type_p (from, to))

618

/* OK */
;

619

else
if (comp_ptr_ttypes (to_pointee, from_pointee))

620

conv = build_conv
(QUAL_CONV, to, conv);

621

else if (expr && string_conv_p (to,
expr, 0))

622

/* converting
from string constant to char *.
*/

623

conv = build_conv
(QUAL_CONV, to, conv);

624

else if (ptr_reasonably_similar
(to_pointee, from_pointee))

625

{

626

conv = build_conv
(PTR_CONV, to, conv);

627

ICS_BAD_FLAG (conv) = 1;

628

}

629

else

630

return
0;

631

632

from = to;

633

}

Again in [3]
clause 4.10 “Pointer covnersions”, finds following paragraphes. And note that
code at line 499 in the function has converted lvalue into rvalue, conv

above
holds the conversion.

1. A null pointer constant is an integral constant expression (5.19) rvalue of integer type that evaluates to zero. A null pointer constant can be converted to a pointer type; the result is the null pointer value of that type and is distinguishable from every other value of pointer to object or pointer to function type. Two null pointer values of the same type shall compare equal. The conversion of a null pointer constant to a pointer to cv-qualified type is a single conversion, and not the sequence of a pointer conversion followed by a qualification conversion (4.4). 2. An rvalue of type “pointer to cv T,” where T is an object type, can be converted to an rvalue of type “pointer to cv void.” The result of converting a “pointer to cv T” to a “pointer to cv void” points to the start of the storage location where the object of type T resides, as if the object is a most derived object (1.8) of type T (that is, not a base class subobject). 3. An rvalue of type “pointer to cv D,” where D is a class type, can be converted to an rvalue of type “pointer to cv B,” where B is a base class (clause 10) of D. If B is an inaccessible (clause 11) or ambiguous (10.2) base class of D, a program that necessitates this conversion is ill-formed. The result of the conversion is a pointer to the base class sub-object of the derived class object. The null pointer value is converted to the null pointer value of the destination type.

Terms 1 is worked by line
526 above. It is one step STD_CONV. And condition of terms 2 is tested by code
at line 558 ~ 560. Then condition in line 584 ~ 597 fullfils terms 3.

Further clause
4.11 “Pointer to member conversion” is shown in below.

1. A null pointer constant (4.10) can be converted to a pointer to member type; the result is the null member pointer value of that type and is distinguishable from any pointer to member not created from a null pointer constant. Two null member pointer values of the same type shall compare equal. The conversion of a null pointer constant to a pointer to member of cv-qualified type is a single conversion, and not the sequence of a pointer to member conversion followed by a qualification conversion (4.4). 2. An rvalue of type “pointer to member of B of type cv T,” where B is a class type, can be converted to an rvalue of type “pointer to member of D of type cv T,” where D is a derived class (clause 10) of B. If B is an inaccessible (clause 11), ambiguous (10.2) or virtual (10.1) base class of D, a program that necessitates this conversion is ill-formed. The result of the conversion refers to the same member as the pointer to member before the conversion took place, but it refers to the base class member as if it were a member of the derived class. The result refers to the member in D’s instance of B. Since the result has type “pointer to member of D of type cv T,” it can be dereferenced with a D object. The result is the same as if the pointer to member of B were dereferenced with the B sub-object of D. The null member pointer value is converted to the null member pointer value of the destination type. [The rule for conversion of pointers to members (from pointer to member of base to pointer to member of derived) appears inverted compared to the rule for pointers to objects (from pointer to derived to pointer to base) (4.10, clause 10). This inversion is necessary to ensure type safety. Note that a pointer to member is not a pointer to object or a pointer to function and the rules for conversions of such pointers do not apply to pointers to members. In particular, a pointer to member cannot be converted to a void*.]

Terms 1 is also covered by
line 526 above. And terms 2 is handled by block at line 567. Arriving at line
617, with above conversion sequence, from

and to

should be either of same type, or just with
different cv-qualifiers; otherwise, no conversion sequence is applicable.

Below conversion between pointer-to-method is similar with that of
pointer-to-member. Note that fromfn

and tofn

are functions pointed respectively; fbase

and tbase

are the implicit this

pointer each. So conversion can be carried out is: “an rvalue of type “pointer
to method of B of type cv T,” where B is a class type, can be converted to an rvalue
of type “pointer to the same
method
of D of type cv T,” where D is a derived class of B.” And see that “same” here
is a little stricter than the that meaning among overloads.

standard_conversion (continue)

634

else if (TYPE_PTRMEMFUNC_P (to) &&
TYPE_PTRMEMFUNC_P (from))

635

{

636

tree fromfn = TREE_TYPE (TYPE_PTRMEMFUNC_FN_TYPE
(from));

637

tree tofn = TREE_TYPE
(TYPE_PTRMEMFUNC_FN_TYPE (to));

638

tree fbase = TREE_TYPE (TREE_VALUE
(TYPE_ARG_TYPES (fromfn)));

639

tree tbase = TREE_TYPE (TREE_VALUE
(TYPE_ARG_TYPES (tofn)));

640

641

if (!DERIVED_FROM_P (fbase, tbase)

642

|| !same_type_p (TREE_TYPE (fromfn),
TREE_TYPE (tofn))

643

|| !compparms (TREE_CHAIN
(TYPE_ARG_TYPES (fromfn)),

644

TREE_CHAIN (TYPE_ARG_TYPES
(tofn)))

645

|| cp_type_quals (fbase) != cp_type_quals
(tbase))

646

return
0;

647

648

from = cp_build_qualified_type (tbase,
cp_type_quals (fbase));

649

from = build_method_type_directly

(from,

650

TREE_TYPE (fromfn),

651

TREE_CHAIN
(TYPE_ARG_TYPES (fromfn)));

652

from = build_ptrmemfunc_type (build_pointer_type
(from));

653

conv = build_conv
(PMEM_CONV, from, conv);

654

}

[3], clause
4.12 “Boolean conversions” gives guideline how to do the conversion as below.

1. An rvalue of arithmetic, enumeration, pointer, or pointer to member type can be converted to an rvalue of type bool. A zero value, null pointer value, or null member pointer value is converted to false; any other value is converted to true.

However, conversion from
pointer to boolean is alittle bit inferior to those of integer types.

standard_conversion (continue)

655

else if (tcode == BOOLEAN_TYPE)

656

{

657

/* [conv.bool]

658

659

An rvalue of
arithmetic, enumeration, pointer, or pointer to

660

member type can
be converted to an rvalue of type bool.

*/

661

if (ARITHMETIC_TYPE_P (from)

662

|| fcode == ENUMERAL_TYPE

663

|| fcode == POINTER_TYPE

664

|| TYPE_PTR_TO_MEMBER_P (from))

665

{

666

conv = build_conv
(STD_CONV, to, conv);

667

if (fcode == POINTER_TYPE

668

|| TYPE_PTRMEM_P (from)

669

|| (TYPE_PTRMEMFUNC_P (from)

670

&& ICS_STD_RANK (conv) <
PBOOL_RANK))

671

ICS_STD_RANK (conv) = PBOOL_RANK;

672

return
conv;

673

}

674

675

return
NULL_TREE;

676

}

Then below
code handles coversions described by [3], clause 4.5 “Integeral promotions”,
4.6 “Floating point promotion”, 4.7 “Integral conversions”, 4.8 “Floating point
conversions”, and 4.9 “Floating-integral conversions”. And below paragraphes
give the detail.

1. An rvalue of type char , signed char , unsigned char , short int , or unsigned short int can be converted to an rvalue of type int if int can represent all the values of the source type; otherwise, the source rvalue can be converted to an rvalue of type unsigned int . 2. An rvalue of type wchar_t (3.9.1) or an enumeration type (7.2) can be converted to an rvalue of the first of the following types that can represent all the values of its underlying type: int , unsigned int , long , or unsigned long . 3. An rvalue for an integral bit-field (9.6) can be converted to an rvalue of type int if int can represent all the values of the bit-field; otherwise, it can be converted to unsigned int if unsigned int can represent all the values of the bit-field. If the bit-field is larger yet, no integral promotion applies to it. If the bit-field has an enumerated type, it is treated as any other value of that type for promotion purposes. 4. An rvalue of type bool can be converted to an rvalue of type int , with false becoming zero and true becoming one. 5. These conversions are called integral promotions.

1. An rvalue of type float can be converted to an rvalue of type double . The value is unchanged. 2. This conversion is called floating point promotion.

1. An rvalue of an integer type can be converted to an rvalue of another integer type. An rvalue of an enumeration type can be converted to an rvalue of an integer type. 2. If the destination type is unsigned, the resulting value is the least unsigned integer congruent to the source integer (modulo 2n where n is the number of bits used to represent the unsigned type). [Note: In a two’s complement representation, this conversion is conceptual and there is no change in the bit pattern (if there is no truncation).] 3. If the destination type is signed, the value is unchanged if it can be represented in the destination type (and bit-field width); otherwise, the value is implementation-defined. 4. If the destination type is bool , see 4.12. If the source type is bool , the value false is converted to zero and the value true is converted to one. 5. The conversions allowed as integral promotions are excluded from the set of integral conversions.

1. An rvalue of floating point type can be converted to an rvalue of another floating point type. If the source value can be exactly represented in the destination type, the result of the conversion is that exact representation. If the source value is between two adjacent destination values, the result of the conversion is an implementation-defined choice of either of those values. Otherwise, the behavior is undefined. 2. The conversions allowed as floating point promotions are excluded from the set of floating point conversions.

1. An rvalue of a floating point type can be converted to an rvalue of an integer type. The conversion truncates; that is, the fractional part is discarded. The behavior is undefined if the truncated value cannot be represented in the destination type. [Note:If the destination type is bool, see 4.12.] 2. An rvalue of an integer type or of an enumeration type can be converted to an rvalue of a floating point type. The result is exact if possible. Otherwise, it is an implementation-defined choice of either the next lower or higher representable value. [Note: loss of precision occurs if the integral value cannot be represented exactly as a value of the floating type.] If the source type is bool, the value false is converted to zero and the value true is converted to one.

Code from line 679 to 690
covers all cases mentioned above. As PROMO_RANK is preferred to STD_RANK, it
always uses PROMO_RANK as possible.

standard_conversion (continue)

677

/* We don't check
for ENUMERAL_TYPE here because there are no standard

678

conversions to
enum type.
*/

679

else if (tcode == INTEGER_TYPE || tcode ==
BOOLEAN_TYPE

680

|| tcode == REAL_TYPE)

681

{

682

if (! (INTEGRAL_CODE_P (fcode) || fcode ==
REAL_TYPE))

683

return
0;

684

conv = build_conv
(STD_CONV, to, conv);

685

686

/* Give this a better
rank if it's a promotion.
*/

687

if (same_type_p (to, type_promotes_to
(from))

688

&& ICS_STD_RANK (TREE_OPERAND
(conv, 0)) <= PROMO_RANK)

689

ICS_STD_RANK (conv) = PROMO_RANK;

690

}

691

else if (fcode == VECTOR_TYPE &&
tcode == VECTOR_TYPE

692

&& ((*targetm

.vector_opaque_p) (from)

693

|| (*targetm

.vector_opaque_p) (to)))

694

return
build_conv
(STD_CONV, to, conv);

695

else if (!(flags &
LOOKUP_CONSTRUCTOR_CALLABLE)

696

&& IS_AGGR_TYPE (to)
&& IS_AGGR_TYPE (from)

697

&& is_properly_derived_from
(from, to))

698

{

699

if (TREE_CODE (conv) == RVALUE_CONV)

700

conv = TREE_OPERAND (conv, 0);

701

conv = build_conv
(BASE_CONV, to, conv);

702

/* The
derived-to-base conversion indicates the initialization

703

of a parameter
with base type from an object of a derived

704

type. A
temporary object is created to hold the result of

705

the
conversion.
*/

706

NEED_TEMPORARY_P (conv) = 1;

707

}

708

else

709

return
0;

710

711

return
conv;

712

}

Code between line 695 to 707 handles the case of derived-to-base
conversion, which is defined by terms 6 of the clause “Implicit conversion
sequeunces”.