From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 6013 invoked by alias); 22 Jan 2008 15:38:35 -0000 Received: (qmail 4537 invoked by uid 48); 22 Jan 2008 15:37:51 -0000 Date: Tue, 22 Jan 2008 16:01:00 -0000 Message-ID: <20080122153751.4535.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: "jason at gcc dot gnu dot org" 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/msg02582.txt.bz2 ------- Comment #37 from jason at gcc dot gnu dot org 2008-01-22 15:37 ------- (In reply to comment #7) > Since complex types are arithmetic types in GNU C++, we should allow standard > conversions to them from integers, just as we do for all other arithmetic > types. > > However, this runs into problems with libstdc++. In particular, > std::complex has a constructor from double and also a constructor from > __complex__ double. Making the change in this patch makes that conversion > ambiguous because now "std::complex(1)" can go via either the > "__complex__ double" constructor or the plain "double" constructor. It seems clear to me that conversion to complex should be worse than conversion to another scalar arithmetic type. I would implement this in hypothetical standardese by defining "complex conversions" for the conversion from scalar to complex, and the term "scalar arithmetic conversions" for integer, float and integer-float conversions, then adding to 13.3.3.2p3 an additional rule that S1 is better than S2 if S1 is a scalar arithmetic conversion and S2 is a complex conversion. I think this approach would avoid the need for extra constructors. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31780