Bug 15542 - [3.4/4.0 Regression] operator & and template definitions
[3.4/4.0 Regression] operator & and template definitions
Status: RESOLVED FIXED
Product: gcc
Classification: Unclassified
Component: c++
3.4.0
: P2 normal
: 3.4.1
Assigned To: Mark Mitchell
: rejects-valid
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2004-05-19 15:51 UTC by Jeff Downs
Modified: 2004-10-30 21:11 UTC (History)
1 user (show)

See Also:
Host:
Target:
Build:
Known to work: 3.3.3
Known to fail: 3.4.0 4.0.0
Last reconfirmed: 2004-05-19 15:59:29


Attachments
Testcase for the issue described (1.68 KB, text/x-c++src)
2004-05-19 15:52 UTC, Jeff Downs
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Jeff Downs 2004-05-19 15:51:40 UTC
Attached below is a simple C++ source file to demonstrate what appears to be a
name lookupor template generation bug in the new parser scheme. It has to do
with directly supplying the result of the application of the operator '&' to a
templated function, from within a template definition, when operator '&' is
overloaded in a templated class.

A call like this succeeds when the object whose & operator is invoked depends on
a templated parameter of the enclosing template definition. It fails when the
the object whose & operator is invoked is independent of the enclosing template
parameters. I am aware of the 3.4.0 changes regarding template definition
dependence and such, but I don't think any of that should apply here; it should
be able to find and generate the appropriate template instantiation.

The comments inline with the code explain further;   the behavior seems very
inconsistent as exhibited by the examples.  I believe the code to be valid. At
the very least I expect that the compiler would treat all provided scenarios
equally. 

There is some preprocessor guarded code in the test code that, when included,
causes the entire thing to compile, seemingly by forceing the required template
instantiation.


Cmd Line for basic issue:
g++ -c file.cpp

Cmd Line to see external template generation causing compilation to succeed:
g++ -DTEST_TWO -c file.cpp


Errors produced during compilation using first cmd line, above:
file.cpp: In function `void templateTest(T&)':
file.cpp:56: error: no matching function for call to `templatedFunc(Opr<const
char>*&)'
file.cpp:57: error: cannot convert `Opr<const char>*' to `const char**' for
argument `1' to `void templatedFunc(T**) [with T = const char]'




This all worked in gcc 3.3.3.

gcc details:
Reading specs from /usr/local/lib/gcc/sparc-sun-solaris2.8/3.4.0/specs
Configured with: ../configure --with-as=/usr/ccs/bin/as
--with-ld=/usr/ccs/bin/ld --disable-nls
Thread model: posix
gcc version 3.4.0
Comment 1 Jeff Downs 2004-05-19 15:52:55 UTC
Created attachment 6342 [details]
Testcase for the issue described
Comment 2 Andrew Pinski 2004-05-19 15:59:28 UTC
Confirmed, this looks like the case where gcc is not looking up non-dependent functions at parse time 
right.
Comment 3 Wolfgang Bangerth 2004-05-19 17:29:58 UTC
Indeed, here is a smaller example: 
--------- 
struct S { 
    const char** operator & (); 
}; 
 
template <typename> struct S_T { 
    const char** operator & (); 
}; 
 
template <class T> void foo(T **) {} 
 
template <typename> void templateTest() { 
  S               s; 
  foo(&s); 
   
  S_T<const char> s_t; 
  foo(&s_t); 
} 
------------------- 
 
g/x> /home/bangerth/bin/gcc-3.4-pre/bin/c++ -c x.cc 
x.cc: In function `void templateTest()': 
x.cc:16: error: no matching function for call to `foo(S_T<const char>*&)' 
 
The call foo(&s) goes through, but the call to foo(&s_t) doesn't. This 
may indicate that gcc thinks that it is somehow dependent, even though it 
is not (all template arguments are actually fixed). 
 
W. 
Comment 4 Jeff Downs 2004-05-19 18:07:47 UTC
Indeed. I also noticed that I only observed this behavior with the templated
class overriding operator &.

What really baffled me (and relieved, at the same time since it allowed me to
work-around) is that doing a static_cast (in the original example) forced it to
find the template.  Similarly, a case I didn't include was naming a const char
** local and assigning it the result of the & operator.  This also works,
probably for the same internal reasons as static_cast does.
Comment 5 Mark Mitchell 2004-05-22 18:19:32 UTC
Working on a fix.
Comment 6 CVS Commits 2004-05-22 19:17:07 UTC
Subject: Bug 15542

CVSROOT:	/cvs/gcc
Module name:	gcc
Branch: 	gcc-3_4-branch
Changes by:	mmitchel@gcc.gnu.org	2004-05-22 19:16:53

Modified files:
	gcc/cp         : ChangeLog class.c typeck.c 
	gcc/testsuite  : ChangeLog 
Added files:
	gcc/testsuite/g++.dg/inherit: union1.C 
	gcc/testsuite/g++.dg/template: addr1.C array5.C array6.C 

Log message:
	PR c++/15507
	* g++.dg/inherit/union1.C: New test.
	
	PR c++/15542
	* g++.dg/template/addr1.C: New test.
	
	PR c++/15427
	* g++.dg/template/array5.C: New test.
	
	PR c++/15287
	* g++.dg/template/array6.C: New test.
	
	PR c++/15507
	* g++.dg/inherit/union1.C: New test.
	
	PR c++/15542
	* g++.dg/template/addr1.C: New test.
	
	PR c++/15427
	* g++.dg/template/array5.C: New test.
	
	PR c++/15287
	* g++.dg/template/array6.C: New test.

Patches:
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/ChangeLog.diff?cvsroot=gcc&only_with_tag=gcc-3_4-branch&r1=1.3892.2.100&r2=1.3892.2.101
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/class.c.diff?cvsroot=gcc&only_with_tag=gcc-3_4-branch&r1=1.595.4.7&r2=1.595.4.8
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/typeck.c.diff?cvsroot=gcc&only_with_tag=gcc-3_4-branch&r1=1.519.2.14&r2=1.519.2.15
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gcc&only_with_tag=gcc-3_4-branch&r1=1.3389.2.177&r2=1.3389.2.178
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/g++.dg/inherit/union1.C.diff?cvsroot=gcc&only_with_tag=gcc-3_4-branch&r1=NONE&r2=1.1.2.1
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/g++.dg/template/addr1.C.diff?cvsroot=gcc&only_with_tag=gcc-3_4-branch&r1=NONE&r2=1.1.2.1
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/g++.dg/template/array5.C.diff?cvsroot=gcc&only_with_tag=gcc-3_4-branch&r1=NONE&r2=1.1.2.1
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/g++.dg/template/array6.C.diff?cvsroot=gcc&only_with_tag=gcc-3_4-branch&r1=NONE&r2=1.1.2.1

Comment 7 CVS Commits 2004-05-22 19:28:40 UTC
Subject: Bug 15542

CVSROOT:	/cvs/gcc
Module name:	gcc
Changes by:	mmitchel@gcc.gnu.org	2004-05-22 19:28:31

Modified files:
	gcc/cp         : ChangeLog class.c typeck.c 
	gcc/testsuite  : ChangeLog 
Added files:
	gcc/testsuite/g++.dg/inherit: union1.C 
	gcc/testsuite/g++.dg/template: addr1.C array5.C array6.C 

Log message:
	PR c++/15507
	* class.c (layout_nonempty_base_or_field): Do not try to avoid
	layout conflicts for unions.
	
	PR c++/15542
	* typeck.c (build_x_unary_op): Instantiate template class
	specializations before looking for "operator &".
	
	PR c++/15427
	* typeck.c (complete_type): Layout non-dependent array types, even
	in templates.
	
	PR c++/15287
	* typeck.c (build_unary_op): Do not optimize "&x[y]" when in a
	template.
	
	PR c++/15507
	* g++.dg/inherit/union1.C: New test.
	
	PR c++/15542
	* g++.dg/template/addr1.C: New test.
	
	PR c++/15427
	* g++.dg/template/array5.C: New test.
	
	PR c++/15287
	* g++.dg/template/array6.C: New test.

Patches:
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/ChangeLog.diff?cvsroot=gcc&r1=1.4050&r2=1.4051
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/class.c.diff?cvsroot=gcc&r1=1.612&r2=1.613
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/typeck.c.diff?cvsroot=gcc&r1=1.542&r2=1.543
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gcc&r1=1.3769&r2=1.3770
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/g++.dg/inherit/union1.C.diff?cvsroot=gcc&r1=1.1&r2=1.2
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/g++.dg/template/addr1.C.diff?cvsroot=gcc&r1=1.1&r2=1.2
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/g++.dg/template/array5.C.diff?cvsroot=gcc&r1=1.1&r2=1.2
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/g++.dg/template/array6.C.diff?cvsroot=gcc&r1=1.1&r2=1.2

Comment 8 Mark Mitchell 2004-05-22 19:30:31 UTC
Fixed in GCC 3.4.1.