--- Comment #7 from Stewart Gordon <> 2012-02-14 05:09:53 PST ---
(In reply to comment #6)
>> Moreover, why allow cast(float) if it isn't supposed to work?
> To summarize it.
> The floating point rules are relaxed such that omitting cast(real)cast(float)
> is a valid transformation.

But why?  I can't see any use case for someone writing cast(float) unless they
want it to convert the operand to a float.  I suppose what I meant to say is:
What good reason is there for the design whereby cast(float) does nothing?

(OK, so it allows it to be called on a library function with a float parameter,
but this affects only the specific case where the CastExpression is directly
used as an argument.)

> I think that's generally a better idea than to waste
> all those cycles. There is currently no mechanism to distinguish explicit 
> casts
> from implicit casts in the backend.

That is in itself a problem to be addressed.  It seems to be partly this that
has led to issue 2006 as well.  My guess is that there are other bugs that have
this same root cause.

Configure issuemail:
------- You are receiving this mail because: -------

Reply via email to