Bug 5435 - Resolution of templates with VLAs
Summary: Resolution of templates with VLAs
Status: RESOLVED INVALID
Alias: None
Product: gcc
Classification: Unclassified
Component: c++ (show other bugs)
Version: 3.0.3
: P3 normal
Target Milestone: ---
Assignee: Not yet assigned to anyone
URL:
Keywords: rejects-valid
Depends on:
Blocks: C++VLA
  Show dependency treegraph
 
Reported: 2002-01-20 03:06 UTC by guillaume.lemaitre33
Modified: 2009-03-03 21:23 UTC (History)
5 users (show)

See Also:
Host:
Target:
Build:
Known to work:
Known to fail:
Last reconfirmed: 2006-03-05 03:52:59


Attachments
template.cc (133 bytes, text/plain)
2003-05-21 15:16 UTC, guillaume.lemaitre33
Details

Note You need to log in before you can comment on or make changes to this bug.
Description guillaume.lemaitre33 2002-01-20 03:06:01 UTC
instanciation of template that supposed to take the
address of a generic container as argument with the address
of a int[] doesn't work

the short example linked with show that erroneus behaviour

Release:
gcc-3.0.2 && gcc-3.0.3

Environment:
Linux Mandrake 8.1 - Duron 1 GHz

How-To-Repeat:
g++ -Wall -ansi template.cc -o template
Comment 1 Craig Rodrigues 2002-01-20 14:07:46 UTC
State-Changed-From-To: open->analyzed
State-Changed-Why: Your code example is ill-formed.
    
    You defined a template function, but did not refer to
    it properly.  Your code example should be something like:
    
    template< typename ContainerAddress_ >
    void f( ContainerAddress_ p_in ) {
    }
     
    int main( const int argc, char * argv[] ) {
      int mof[argc];
     
      f<int *>( mof );
     
      return 0;
    }
Comment 2 guillaume.lemaitre33 2002-01-28 18:42:13 UTC
From: =?iso-8859-1?Q?LEMA=CETRE?= Guillaume <guillaume.lemaitre33@wanadoo.fr>
To: rodrigc@gcc.gnu.org, guillaume.lemaitre33@wanadoo.fr
Cc:  
Subject: Re: c++/5435: Resolution of templates with thing[] types
Date: Mon, 28 Jan 2002 18:42:13 +0100

 rodrigc@gcc.gnu.org a écrit :
 > 
 > Synopsis: Resolution of templates with thing[] types
 > 
 > State-Changed-From-To: open->analyzed
 > State-Changed-By: rodrigc
 > State-Changed-When: Sun Jan 20 14:07:46 2002
 > State-Changed-Why:
 >     Your code example is ill-formed.
 > 
 >     You defined a template function, but did not refer to
 >     it properly.  Your code example should be something like:
 > 
 >     template< typename ContainerAddress_ >
 >     void f( ContainerAddress_ p_in ) {
 >     }
 > 
 >     int main( const int argc, char * argv[] ) {
 >       int mof[argc];
 > 
 >       f<int *>( mof );
 > 
 >       return 0;
 >     }
 > 
 > http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&database=gcc&pr=5435
 
 I think I haven't been clear the first time
 
 I consider that mof is a container, in the sense that I can apply
 operator[] to it, as I could do if I had declared mof like this :
 
 int * mof = new int[argc];
 
 So, as the name of the typename suggests it, i want to pass the address
 of the container I have to function 'f'; so the correct call seems to be
 
 template< typename ContainerAddress_ > void f( ContainerAdress_ p_in )
 {};
 f( &mof );
 
 
 with mof declared as a variable length array or a pointer to memory;
 
 The issue is that the template cannot resolve itself to int(*)[argc].
 If I specify f< int(*)[argc] >( &mof ) it doesn't work (I get an ICP),
 that's what I wanted to point out. The fact is that I verified if taking
 address of an array was legal, it seems to be... So I don't understand
 why it doesn't compile, or g++ doesn't convert int(*)[argc] to a int**
 to call the right function 'f'
 
 Maybe I'm totally mistaking, but I don't understand why arrays doesn't
 behave the same as memory spaces dynamically allocated with operator
 new. Maybe it's not your problem, perhaps i should post that sort of
 mail to newsgroups, but I thought it was a bug, and still think it's a
 bug. Or maybe it is the way f is defined ? Should it be declared like
 this ?
 
 template< typename Container_ > void f( Container_ * p_in ) {}
 
 it doesn't work either ...
 
 friendly
 Guillaume
 
 -- 
 "C'est terrible l'intelligence. C'est le seul outil de l'homme
  qui lui permette de mesurer l'étendue de son malheur."
 
                                                   P. Desproges

Comment 3 Nathanael C. Nerode 2003-01-11 18:34:27 UTC
From: Nathanael Nerode <neroden@twcny.rr.com>
To: gcc-gnats@gcc.gnu.org, guillaume.lemaitre33@wanadoo.fr,
   gcc-bugs@gcc.gnu.org, nobody@gcc.gnu.org
Cc:  
Subject: Re: c++/5435: ...
Date: Sat, 11 Jan 2003 18:34:27 -0500

 This only occurs with VLAs.  Note that if you replace mof[argc] with mof[5] 
 it compiles just fine.
 
 Resummarizing.
Comment 4 Drea Pinski 2003-08-02 17:56:09 UTC
Fixed on the mainline (20030801).  Will submit a testcase.
The function is mangled as _Z1fIPiEvT_ which is void f<int*>(int*).
Comment 5 Drea Pinski 2003-08-06 23:30:41 UTC
I was wrong the original test case does not compile still:
pr5435.cc: In function `int main(int, char**)':
pr5435.cc:8: error: no matching function for call to `f(int (*)[argc])'
2.95.3 accepted this but produced unasmeblable code.
Comment 6 Drea Pinski 2003-08-07 18:40:54 UTC
From Phil's regression hunter: Search converges between 2001-01-14-trunk (#2) and 
2001-01-21-trunk (#3). 
Comment 7 Drea Pinski 2003-08-10 18:14:32 UTC
The error message has changed:
pr5435.cc:8: error: no matching function for call to `f(int (*)[((long unsigned int)argc)])'
Comment 8 Drea Pinski 2003-12-28 04:58:23 UTC
Maybe this should wait until C++ gets VLA from C99.
Comment 9 Jason Merrill 2009-03-03 21:23:51 UTC
int (*)[argc] is not a valid template type argument, as it depends on a runtime value, and template arguments need to be known at compile time.  If you want to pass your VLA to a template function, you need to let it decay to int*.