[Bug c++/13971] [3.4/3.5 Regression] ICE when compiling koffice-cvs (in build_conditional_expr, at cp/call.c:3068)

Sun Feb 15 22:42:00 GMT 2004

------- Additional Comments From mmitchel at gcc dot gnu dot org  2004-02-15 22:42 -------
The standard is not clear.

Here, "QChar::null" is an lvalue of type "const QChar".  Meanwhile,
"s[psi]" is an rvalue of type "QCharRef".

According to [expr.cond], we try to convert each of the operands to
the type of the other.  The applicable language is:

  E1 can be converted to match E2 if E1 can be implicitly converted to
  the type that expression E2 would have if E2 were converted to an
  rvalue (or the type it has, if E2 is an rvalue).

where, here, "E1" is "s[psi]", and "E2" is "QChar::null".

The type that E2 would have if it were an rvalue is "const QChar"
because rvalues of class-type can be cv-qualified.  E1 can certainly
be implicitly converted to "const QChar" since:

  const QChar t = s[psi];

is valid; the cv-qualification of the left-hand and right-hand sides
is ignored in this context.

We then have:

   that conversion is applied to the chosen operand and the converted
   operand is used in place of the original operand for the remainder
   of this section.

Now, the questions:

- What is the type of this converted operand: "const QChar" or just
  "QChar" as returned by the conversion operator?

- What if the "QChar::null" had type "QChar" and the conversion
  operator returned "const QChar"?

I think the logic conclusion is that the type of both operands, after
the conversion, should be treated as the union of the cv-qualification
of the two converted operands.

I have asked Steve Adamczyk to open a core issue.

In the meantime, I'll look at implementing the suggested fix.

-- 

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13971