Bug 21210 - [4.0 Regression] Trouble with __complex__ types default construction
Summary: [4.0 Regression] Trouble with __complex__ types default construction
Status: RESOLVED FIXED
Alias: None
Product: gcc
Classification: Unclassified
Component: c++ (show other bugs)
Version: 4.0.0
: P5 normal
Target Milestone: 4.0.4
Assignee: Not yet assigned to anyone
URL:
Keywords: rejects-valid
Depends on:
Blocks: 30209
  Show dependency treegraph
 
Reported: 2005-04-25 09:56 UTC by Marcel Loose
Modified: 2007-07-07 22:57 UTC (History)
2 users (show)

See Also:
Host:
Target:
Build:
Known to work: 3.4.0 4.2.0 4.1.2
Known to fail: 4.0.0 4.1.0
Last reconfirmed: 2006-02-01 04:35:11


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Marcel Loose 2005-04-25 09:56:28 UTC
The GCC 4.0.0 release does not support the use of the GNU builtin __complex__
anymore in, e.g., std::vector. The code below used to compile on GNU
(compatible) compilers prior to GCC 4.0

<code>
#include <vector>
typedef float __complex__ fcomplex;
std::vector<fcomplex> vfc(10);
</code>

GCC 4.0.0 produces the following diagnostic:

$ /data/loose/gcc-4.0.0/bin/g++ -v -save-temps -c -Wall -W tVec.cc

Using built-in specs.
Target: i686-pc-linux-gnu
Configured with: ../../src/gcc-4.0.0/configure --prefix=/data/loose/gcc-4.0.0
--enable-threads --enable-__cxa_atexit
Thread model: posix
gcc version 4.0.0
 /data/loose/gcc-4.0.0/libexec/gcc/i686-pc-linux-gnu/4.0.0/cc1plus -E -quiet -v
-D_GNU_SOURCE tVec.cc -mtune=pentiumpro -Wall -W -fpch-preprocess -o tVec.ii
ignoring nonexistent directory
"/data/loose/gcc-4.0.0/lib/gcc/i686-pc-linux-gnu/4.0.0/../../../../i686-pc-linux-gnu/include"
#include "..." search starts here:
#include <...> search starts here:
 /data/loose/gcc-4.0.0/lib/gcc/i686-pc-linux-gnu/4.0.0/../../../../include/c++/4.0.0
 /data/loose/gcc-4.0.0/lib/gcc/i686-pc-linux-gnu/4.0.0/../../../../include/c++/4.0.0/i686-pc-linux-gnu
 /data/loose/gcc-4.0.0/lib/gcc/i686-pc-linux-gnu/4.0.0/../../../../include/c++/4.0.0/backward
 /usr/local/include
 /data/loose/gcc-4.0.0/include
 /data/loose/gcc-4.0.0/lib/gcc/i686-pc-linux-gnu/4.0.0/include
 /usr/include
End of search list.
 /data/loose/gcc-4.0.0/libexec/gcc/i686-pc-linux-gnu/4.0.0/cc1plus
-fpreprocessed tVec.ii -quiet -dumpbase tVec.cc -mtune=pentiumpro -auxbase tVec
-Wall -W -version -o tVec.s
GNU C++ version 4.0.0 (i686-pc-linux-gnu)
        compiled by GNU C version 4.0.0.
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
/data/loose/gcc-4.0.0/lib/gcc/i686-pc-linux-gnu/4.0.0/../../../../include/c++/4.0.0/bits/stl_vector.h:
In constructor ‘std::vector<_Tp, _Alloc>::vector(size_t) [with _Tp = float
__complex__, _Alloc = std::allocator<float __complex__>]’:
tVec.cc:3:   instantiated from here
/data/loose/gcc-4.0.0/lib/gcc/i686-pc-linux-gnu/4.0.0/../../../../include/c++/4.0.0/bits/stl_vector.h:219:
error: invalid cast from type ‘int’ to type ‘float __complex__’
Comment 1 Paolo Carlini 2005-04-25 11:59:33 UTC
Actually, this has nothing to do with std::vector per se. This tiny snippet
suffices to trigger the C++ front-end problem:

  typedef float __complex__ fcomplex;
  fcomplex cplx = fcomplex();



Comment 2 Andrew Pinski 2005-04-25 13:22:41 UTC
Confirmed, with  Paolo's reduced testcase.
Comment 3 Mark Mitchell 2005-05-29 21:27:58 UTC
See:

http://gcc.gnu.org/ml/gcc-patches/2005-05/msg02777.html

for additional analysis regarding this PR.
Comment 4 Andrew Pinski 2005-06-01 00:33:22 UTC
: Search converges between 2004-10-19-161001-trunk (#599) and 2004-10-20-014001-trunk 
(#600).
Comment 5 Mark Mitchell 2005-06-02 05:04:50 UTC
I am no longer working on this PR.  There is considerable debate about what the
right changes to make to the language are, so I am leaving this aside.
Comment 6 Mark Mitchell 2005-07-06 17:03:01 UTC
Postponed until 4.0.2.
Comment 7 Mark Mitchell 2005-09-05 17:03:06 UTC
I've removed the target milestone for this PR, as the discussion linked to shows
that we don't know yet what we want the behavior to be.
Comment 8 Mark Mitchell 2006-05-25 02:35:59 UTC
Will not be fixed in 4.1.1; adjust target milestone to 4.1.2.
Comment 9 Roger Sayle 2006-06-12 18:55:04 UTC
Subject: Bug 21210

Author: sayle
Date: Mon Jun 12 18:50:22 2006
New Revision: 114573

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=114573
Log:

	PR c++/21210
	* typeck2.c (build_functional_cast): Use cp_convert to construct
	non-aggregate initializers instead of the user-level build_c_cast.

	* g++.dg/init/complex1.C: New test case.


Added:
    trunk/gcc/testsuite/g++.dg/init/complex1.C
Modified:
    trunk/gcc/cp/ChangeLog
    trunk/gcc/cp/typeck2.c
    trunk/gcc/testsuite/ChangeLog

Comment 10 Roger Sayle 2006-06-13 18:06:08 UTC
Subject: Bug 21210

Author: sayle
Date: Tue Jun 13 18:06:00 2006
New Revision: 114618

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=114618
Log:

	PR c++/21210
	* typeck2.c (build_functional_cast): Use cp_convert to construct
	non-aggregate initializers instead of the user-level build_c_cast.

	* g++.dg/init/complex1.C: New test case.


Added:
    branches/gcc-4_1-branch/gcc/testsuite/g++.dg/init/complex1.C
Modified:
    branches/gcc-4_1-branch/gcc/cp/ChangeLog
    branches/gcc-4_1-branch/gcc/cp/typeck2.c
    branches/gcc-4_1-branch/gcc/testsuite/ChangeLog

Comment 11 Roger Sayle 2006-06-14 04:35:40 UTC
Subject: Bug 21210

Author: sayle
Date: Wed Jun 14 04:35:29 2006
New Revision: 114634

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=114634
Log:

	PR c++/21210
	* typeck2.c (build_functional_cast): Use cp_convert to construct
	non-aggregate initializers instead of the user-level build_c_cast.

	* g++.dg/init/complex1.C: New test case.


Added:
    branches/gcc-4_0-branch/gcc/testsuite/g++.dg/init/complex1.C
Modified:
    branches/gcc-4_0-branch/gcc/cp/ChangeLog
    branches/gcc-4_0-branch/gcc/cp/typeck2.c
    branches/gcc-4_0-branch/gcc/testsuite/ChangeLog

Comment 12 Steven Bosscher 2006-06-14 05:28:21 UTC
.