For the following simple program -------------------- #include <complex> int main () { std::complex<double> x; x = std::complex<double>(1,0); } -------------------- I get this warning since 3.2: g/x> /home/bangerth/bin/gcc-4*/bin/c++ -c x.cc -Wsynth x.cc: In function `int main()': x.cc:5: warning: using synthesized 'std::complex<double>& std::complex<double>::operator=(const std::complex<double>&)' for copy assignment /home/bangerth/bin/gcc-4.0-pre/lib/gcc/i686-pc-linux-gnu/4.0.0/../../../../include/c++/4.0.0/complex:1193: warning: where cfront would use 'std::complex<double>& std::complex<double>::operator=(const std::complex<_Tp>&) [with _Tp = double]' This is a regression against 2.95, in which no such warning was given. The warning is annoying since one can't really use <complex> with -Werror. I see two ways around this annoying mis-feature: either -Wsynth shouldn't report anything for system/libstdc++ headers, or (my preference) libstdc++ gets fixed up by adding the copy operator. The latter would clearly be allowed by the as-if rule. W.
Confirmed.
Gaby can you look at this? Adding the copy ctor here will change ABI, so not super likely. Why are we getting this warning anyway? -benjamin
I am not an expert in ABI questions, but in my naive world constructors are somewhat different than regular functions if they are declared inline (and synthesized constructors always are): - you can't take the address of a constructor - (old) code linked against a new libstdc++ with a new constructor would be fine since the old synthesized constructor had been inlined - (new) code linked against an old libstdc++ without the new constructor would also be fine if the new constructor were declared inline, since then no call to the respective library function would be attempted IOW, the result is a situation where programs couldn't tell the difference. The fact that you can't take the address of a constructor makes the situation markedly different from the case of a regular function. W.
Subject: Re: [3.3/3.4/4.0 regression] -Wsynth warning in <complex> "bangerth at dealii dot org" <gcc-bugzilla@gcc.gnu.org> writes: | I am not an expert in ABI questions, but in my naive world constructors | are somewhat different than regular functions if they are declared | inline (and synthesized constructors always are): The issue is not taking the address of the copy constructor, but the change in calling convention. It you declare a copy consttuctor, you change the ABI in the sense that the compiler is now forced to pass everything in stack, where it used to pass it in register. | - you can't take the address of a constructor | - (old) code linked against a new libstdc++ with a new constructor would | be fine since the old synthesized constructor had been inlined No, it won't because on plateforms where they are expecting the result of a complex<>-returning function to come in register they will get garbage. The diagnostic is nonsensical. The fix is to fix the diagnostic, not to paper over the problem. -- Gaby
Subject: Re: [3.3/3.4/4.0 regression] -Wsynth warning in <complex> > The issue is not taking the address of the copy constructor, but the > change in calling convention. It you declare a copy consttuctor, you > change the ABI in the sense that the compiler is now forced to pass > everything in stack, where it used to pass it in register. Ah, ok, I didn't know about these subtleties. > The diagnostic is nonsensical. The fix is to fix the diagnostic, not > to paper over the problem. That's certainly the best solution. -Wsynth should just not trigger in libstdc++ headers. Thanks W. ------------------------------------------------------------------------- Wolfgang Bangerth email: bangerth@ices.utexas.edu www: http://www.ices.utexas.edu/~bangerth/
Subject: Re: [3.3/3.4/4.0 regression] -Wsynth warning in <complex> "bangerth at ices dot utexas dot edu" <gcc-bugzilla@gcc.gnu.org> writes: | > The diagnostic is nonsensical. The fix is to fix the diagnostic, not | > to paper over the problem. | | That's certainly the best solution. -Wsynth should just not trigger in | libstdc++ headers. yes, and even more in user codes where it does not make sense. Remember, we're currently compiling programs with ISO rules, and we have very very little provisions to compile programs with cfront rules (and you'd have to specify which version of cfront). -- Gaby
Subject: Re: [3.3/3.4/4.0 regression] -Wsynth warning in <complex> "bkoz at gcc dot gnu dot org" <gcc-bugzilla@gcc.gnu.org> writes: | Why are we getting this warning anyway? I don't know why we're getting that warning. It is meaningless. Someone asked why this is happening in V3 header files (which are supposed to be system headers): I believe for the same bugs that makes it that you get warning on _DECLs that come from *instantiations* of templates defined in such headers. -- Gaby
Yo thanks G. Wolfgang, the whole implications of adding copy ctors changing calling conventions was not clear to me either, before the -Weffc++ changes. There was some discussion of this at that time, and the libstdc++ ABI document page has a edited version of the results of that conversation. Turns out adding dtors also matters. Anyway. I'd like to re-assign this to a g++ bug, or middle end or whatever. Sound like a plan? -benjamin
Subject: Re: [3.3/3.4/4.0 regression] -Wsynth warning in <complex> > I'd like to re-assign this to a g++ bug, or middle end or whatever. Sound > like a plan? Yes, certainly. I guess it's a front-end bug to warn about this in libstdc++ headers, so "c++" would be the correct category to put it into. W. ------------------------------------------------------------------------- Wolfgang Bangerth email: bangerth@ices.utexas.edu www: http://www.ices.utexas.edu/~bangerth/
Subject: Bug 18644 CVSROOT: /cvs/gcc Module name: gcc Changes by: gdr@gcc.gnu.org 2005-03-31 14:21:20 Modified files: gcc : ChangeLog gcc/cp : ChangeLog call.c gcc/doc : invoke.texi Log message: doc/ PR c++/18644 * doc/invoke.texi (-Wsynth): Don't document, as it now is void of semantics. cp/ PR c++/18644 * call.c (build_new_op): Remove check for -Wsynth. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcc&r1=2.8050&r2=2.8051 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/ChangeLog.diff?cvsroot=gcc&r1=1.4680&r2=1.4681 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/call.c.diff?cvsroot=gcc&r1=1.531&r2=1.532 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/doc/invoke.texi.diff?cvsroot=gcc&r1=1.594&r2=1.595
Subject: Bug 18644 CVSROOT: /cvs/gcc Module name: gcc Changes by: gdr@gcc.gnu.org 2005-04-01 00:28:00 Modified files: gcc/testsuite : ChangeLog gcc/testsuite/g++.old-deja/g++.jason: warning9.C Log message: PR c++/18644 * g++.old-deja/g++.jason/warning9.C (struct A, main): Adjust Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gcc&r1=1.5255&r2=1.5256 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/g++.old-deja/g++.jason/warning9.C.diff?cvsroot=gcc&r1=1.3&r2=1.4
Subject: Bug 18644 CVSROOT: /cvs/gcc Module name: gcc Branch: gcc-3_3-branch Changes by: gdr@gcc.gnu.org 2005-04-04 07:42:35 Modified files: gcc : ChangeLog gcc/cp : ChangeLog call.c gcc/doc : invoke.texi gcc/testsuite : ChangeLog gcc/testsuite/g++.old-deja/g++.jason: warning9.C Log message: PR c++/18644 * doc/invoke.texi (-Wsynth): Remove documentation. cp/ PR c++/18644 * call.c (build_new_op): Remove check for warn_synth. testsuite/ PR c++/18644 * g++.old-deja/g++.jason/warning9.C (struct A, main): Adjust. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcc&only_with_tag=gcc-3_3-branch&r1=1.16114.2.1062&r2=1.16114.2.1063 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/ChangeLog.diff?cvsroot=gcc&only_with_tag=gcc-3_3-branch&r1=1.3076.2.281&r2=1.3076.2.282 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/call.c.diff?cvsroot=gcc&only_with_tag=gcc-3_3-branch&r1=1.341.2.43&r2=1.341.2.44 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/doc/invoke.texi.diff?cvsroot=gcc&only_with_tag=gcc-3_3-branch&r1=1.209.2.59&r2=1.209.2.60 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gcc&only_with_tag=gcc-3_3-branch&r1=1.2261.2.398&r2=1.2261.2.399 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/g++.old-deja/g++.jason/warning9.C.diff?cvsroot=gcc&only_with_tag=gcc-3_3-branch&r1=1.2&r2=1.2.74.1
Fixed on all active branches.