[Bug c++/45428] New: Address of templete function even if named as a template-id is not properly determined
I do not know if this is a duplicate report as there are other similar tickets
about problems with addresses of overloads, but as far as I've seen none seems
to be reported against template-ids.
Consider this snippet.
---
struct function
{
void (*outline)(void *);
};
templatetypename _T
struct info
{
_T *t_0;
};
templatetypename _T
static void my_fun(info_T *_args)
{
}
templatetypename _T
void f(_T t)
{
function fun = {
(void(*)(void)) my_fun_T // This is test.cpp:22
};
}
int main(int argc, char *argv[])
{
int a = 3;
f(a);
float b = 1.0f;
f(b);
return 0;
}
---
g++ yields the following errors
test.cpp: In function void f(_T) [with _T = int]:
test.cpp:28: instantiated from here
test.cpp:22: error: insufficient contextual information to determine type
test.cpp: In function void f(_T) [with _T = float]:
test.cpp:30: instantiated from here
test.cpp:22: error: insufficient contextual information to determine type
A workaround that seems to work is using a double casting, a first one that
selects the right overload (even if this would not be needed as we passed all
the template-arguments of the template-id of the function and no
template-parameter is left to deduce) before the original casting.
templatetypename _T
void f(_T t)
{
function fun = {
(void(*)(void))(void (*)(info_T *_args)) my_fun_T
};
}
Neither __typeof__(my_fun_T) or decltype (C++0x) seem able to figure the
precise 'my_fun_T'.
Usign __typeof__ like in
(void(*)(void))(__typeof__(my_fun_T)) my_fun_T
yields a
test.cpp:22: error: type of my_funint is unknown
while decltype (g++ -std=c++0x) used like in
(void(*)(void)) (decltype(my_fun_T)) my_fun_T
ends with an ICE
test.cpp:22: internal compiler error: in finish_decltype_type, at
cp/semantics.c:4694
I'm not entirely sure whether this scenario should be regarded as valid but
icc, comeau and xlc++ accept this code, so I'm inclined to think g++ should
accept it too.
--
Summary: Address of templete function even if named as a
template-id is not properly determined
Product: gcc
Version: 4.4.5
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: roger dot ferrer at bsc dot es
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45428
[Bug c++/45428] Address of template function even if fully named as a template-id is not properly determined
--- Comment #3 from roger dot ferrer at bsc dot es 2010-08-27 15:46 --- (In reply to comment #2) (In reply to comment #1) (In reply to comment #0) (void(*)(void)) my_fun_T // This is test.cpp:22 Can I assume you meant to case to (void(*)(void*)) here? Yes it was a typo, sorry. Even if fixed, though, g++ 4.4 does not compile it. Anyway if 4.5 and 4.6 accept such code I guess this is already fixed in forthcoming releases, right? Maybe the PR should be closed as fixed. Anyway, using the double-cast workaround g++ 4.4 does link. Thanks -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45428
[Bug c++/43327] New: ICE in unifiy.c
The following code
---
template typename _T
struct A
{
template int _N, int _M
struct B;
template int _N
struct B_N, _T::m
{
static void f();
};
};
struct C
{
static const int m = 4;
};
void m()
{
AC::B1, 4::f();
}
--
causes the following ICE as of 4.2
[g++ 4.4]
test.cc: In function âvoid m()â:
test.cc:22: internal compiler error: in unify, at cp/pt.c:14081
g++ 4.1 yields this error, instead
[g++ 4.1]
test.cc: In function âvoid m()â:
test.cc:22: error: incomplete type âAC::B1, 4â used in nested name
specifier
This code seems fine to me (and so seems to intel, xlc++ and comeau online) so
I assume it is some issue in g++.
--
Summary: ICE in unifiy.c
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: roger dot ferrer at bsc dot es
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43327
[Bug c++/43327] ICE in unifiy.c
--- Comment #1 from roger dot ferrer at bsc dot es 2010-03-11 07:56 ---
For what it's worth, replacing
static const int m = 4;
with
enum { m = 4 };
works fine.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43327
[Bug c++/41426] New: User defined conversion on return ignores array types
I think g++ simplifies too early array types into pointers when looking for a
conversion sequence in a return statement.
---
struct B
{
B (int (v)[10]);
B();
};
B g2()
{
int c[10];
return c;
}
---
results in
test.cc: In function B g2():
test.cc:10: error: conversion from int* to non-scalar type B requested
while at least the conversion constructor B::B(int ()[10]) should be given a
chance.
For another (slightly) more elaborated example
---
template typename _T
struct A
{
template int _N
A(_T (V)[_N]);
A();
};
Afloat g1()
{
float f[] = {1.1f, 2.3f};
return f;
}
---
which gives
prova.cc: In function Afloat g1():
prova.cc:12: error: conversion from float* to non-scalar type Afloat
requested
Again, at least the 'AT::A_N(T ()[_N])' constructor should be given a
chance (which eventually should succeed).
Using an explicit-conversion can be used as workaround.
--
Summary: User defined conversion on return ignores array types
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: roger dot ferrer at bsc dot es
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41426
[Bug preprocessor/39512] linemap_init in lex.c does not initialize reallocator
--- Comment #4 from roger dot ferrer at bsc dot es 2009-03-30 18:04 --- Thanks a lot. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39512
[Bug preprocessor/39512] New: linemap_init in lex.c does not initialize reallocator
Seems that 'reallocator' field is not set to NULL in lex.c:linemap_init. Later on in the code this field can be initialized with xrealloc only if it was NULL. Since it is a pointer to a function, using it it leads to unexpected behaviour (e.g. SIGILL or SIGTRAP). Doing a quick grep in the source code, shows that toplev.c does initialize this field, so I guess this problem is not visible in normal gcc usage. Initializing the field in the function fixes the problem. (Note: since I did not find any libcpp component, I filled the bug under preprocessor cathegory) -- Summary: linemap_init in lex.c does not initialize reallocator Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: preprocessor AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: roger dot ferrer at bsc dot es http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39512
