This is the mail archive of the gcc-bugs@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[Bug c++/28501] ICE with __real__ and implicit type conversion



------- Comment #5 from mmitchel at gcc dot gnu dot org  2009-02-08 20:53 -------
Paolo --

I didn't realize that something like "__real__ 3" was valid GNU C; I thought
that the argument had to have complex type.  But, it looks like that is not the
case.

Given that, yes, I think the test case should be accepted, as a GNU extension. 
When __real__ (or __imag__) is applied to an expression with class type, we
should see if the expression can be converted to any of the built-in types to
which __real__ can ordinarily be applied.  If there is only one such type, then
we should use that conversion; if there is more than one, then we should report
the same kind of error used when we have an ambiguous overload.  I don't think
we should be trying to deduce anything from the context in which the __real__
expression is being used.

So, your patch looks like a fine start.  I'm not sure what it will do for cases
like:

  struct A {
    operator int();
    operator __complex__ double();
    template <typename T> operator __complex__ T();
  };

though.  As above, I think those cases should be errors, since there's no way
to know which conversion operator to prefer.  

-- Mark


-- 

mmitchel at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |mmitchel at gcc dot gnu dot
                   |                            |org


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]