Bug 18644 - [3.3/3.4 regression] -Wsynth warning in <complex>
Summary: [3.3/3.4 regression] -Wsynth warning in <complex>
Status: RESOLVED FIXED
Alias: None
Product: gcc
Classification: Unclassified
Component: c++ (show other bugs)
Version: 4.0.0
: P2 normal
Target Milestone: 3.3.6
Assignee: Gabriel Dos Reis
URL:
Keywords: rejects-valid
Depends on:
Blocks:
 
Reported: 2004-11-24 04:39 UTC by Wolfgang Bangerth
Modified: 2005-04-04 07:56 UTC (History)
1 user (show)

See Also:
Host:
Target:
Build:
Known to work:
Known to fail:
Last reconfirmed: 2004-11-24 06:19:38


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Wolfgang Bangerth 2004-11-24 04:39:03 UTC
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.
Comment 1 Andrew Pinski 2004-11-24 06:19:38 UTC
Confirmed.
Comment 2 Benjamin Kosnik 2004-11-25 16:38:23 UTC
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
Comment 3 Wolfgang Bangerth 2004-11-25 19:19:46 UTC
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. 
Comment 4 Gabriel Dos Reis 2004-11-26 03:16:07 UTC
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
Comment 5 Wolfgang Bangerth 2004-11-26 04:33:04 UTC
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/

Comment 6 Gabriel Dos Reis 2004-11-26 17:45:09 UTC
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
Comment 7 Gabriel Dos Reis 2004-11-27 21:27:27 UTC
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
Comment 8 Benjamin Kosnik 2004-11-30 17:03:38 UTC
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
Comment 9 Wolfgang Bangerth 2004-11-30 17:06:14 UTC
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/

Comment 10 CVS Commits 2005-03-31 14:21:41 UTC
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

Comment 11 CVS Commits 2005-04-01 00:28:06 UTC
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

Comment 13 Gabriel Dos Reis 2005-04-04 07:56:47 UTC
Fixed on all active branches.