------- Comment #35 from gdr at cs dot tamu dot edu 2008-01-08 02:52 ------- Subject: Re: [4.2/4.3 regression] ICE with incompatible types for ?: with "complex type" conversion
"mark at codesourcery dot com" <[EMAIL PROTECTED]> writes: | ------- Comment #34 from mark at codesourcery dot com 2008-01-07 16:17 ------- | Subject: Re: [4.2/4.3 regression] ICE with incompatible types | for ?: with "complex type" conversion | | gdr at cs dot tamu dot edu wrote: | | > | What's the likely change? | > | > Ban implicit narrowing conversions, in the sense that a round trip will not | > give the same value back. | | Which direction is narrowing, between "int" and "float"? The rule is not just based on 'type'; if the source value is a constant, then the implementation determine whether a round trip is OK. Otherwise, it uses 'just' the type rule (for safe approximation). furthermore, based on feedback from Koan meeting, it is also proposed that narrowing should not cross integer-float barrier. | (Both have | values unrepresentable in the other, of course.) Would you please give | an example of how this change, together with the new constructors, would | make some program behave differently than the standard says it should? Please see the details in the proposal put foward by BS, me, and JSA titled `initializer list' (post Toronto meeting), and the recent `rationale' paper by BS in the mid-term mailing. Look for the section or word `narrowing'. (I'm currently in a location in san francisco where the nhe flakky network connection does not ease extended mail). -- Gaby -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31780
