From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 22513 invoked by alias); 7 Jan 2008 08:11:33 -0000 Received: (qmail 22407 invoked by alias); 7 Jan 2008 08:10:47 -0000 Date: Mon, 07 Jan 2008 09:48:00 -0000 Message-ID: <20080107081047.22406.qmail@sourceware.org> X-Bugzilla-Reason: CC References: Subject: [Bug c++/31780] [4.2/4.3 regression] ICE with incompatible types for ?: with "complex type" conversion In-Reply-To: Reply-To: gcc-bugzilla@gcc.gnu.org To: gcc-bugs@gcc.gnu.org From: "gdr at cs dot tamu dot edu" Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-bugs-owner@gcc.gnu.org X-SW-Source: 2008-01/txt/msg00594.txt.bz2 ------- Comment #33 from gdr at cs dot tamu dot edu 2008-01-07 08:10 ------- Subject: Re: [4.2/4.3 regression] ICE with incompatible types for ?: with "complex type" conversion "mark at codesourcery dot com" writes: | Subject: Re: [4.2/4.3 regression] ICE with incompatible types | for ?: with "complex type" conversion | | gdr at cs dot tamu dot edu wrote: | | > | Is it conceivable that ISO C++ will ever add a | > | complex::complex(int) constructor that doesn't set the real part | > | to the value of the argument (converted to double), and the imaginary | > | part to zero? | > | > That isn't the issue. My concern is whether ISO C++ will ever | > change conversion rules, say from integers to floats or doubles. The | > answer is likely. | | What's the likely change? Ban implicit narrowing conversions, in the sense that a round trip will not give the same value back. The exact rules are in flux (there was a specification discussed at the last Kona meeting, but it got changed based on feedback, and may likely change from now to Sophia Antipolis meeting). However, the general idea meets consensus. -- Gaby -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31780