[Bug c++/31780] [4.2/4.3 regression] ICE with incompatible types for ?: with "complex type" conversion

["gdr at cs dot tamu dot edu" <gcc-bugzilla at gcc dot gnu dot org>]

------- 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" <gcc-bugzilla@gcc.gnu.org> 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