http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53573
--- Comment #3 from Keean Schupke 2012-06-04 13:44:14 UTC ---
From: Technicalities C.13.8.3:
" struct X { X(int); /* ... */ };
"
" void g(X);
"
" template void f(T a) { g(a); }
"
" void h()
" {
" extern void g(int);
" f(2);
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53573
--- Comment #4 from Keean Schupke 2012-06-04 16:38:21 UTC ---
From C++ Standard N3242=11-0012 14.6 Name Resolution
10. If a name does not depend on a template-parameter (as defined in 14.6.2), a
declaration (or set of declarations) for that name s
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53573
--- Comment #5 from Keean Schupke 2012-06-04 17:13:18 UTC ---
The following program will apparently compile correctly, but will silently
produce incorrect results at runtime:
#include
char g(char x) {
return x - 1;
}
template T f(T t) {
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53573
--- Comment #6 from Keean Schupke 2012-06-05 09:06:01 UTC ---
The suggested work around in the error message 'adding -fpermissive' to
gcc-4.7.0 does not fix the problem as suggested by the error message. This
would suggest the compiler is not disp
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53573
Manuel López-Ibáñez changed:
What|Removed |Added
CC||manu at gcc dot gnu.org
--- Comment
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53573
--- Comment #8 from Keean Schupke 2012-06-05 10:15:18 UTC ---
(In reply to comment #7)
Have a read of the C++ standard, the example given in:
N3242=11-0012 14.6 Name Resolution: paragraph 10
Which I have pasted above into comment #4 and the extr
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53573
Jonathan Wakely changed:
What|Removed |Added
Severity|major |normal
--- Comment #9 from Jonathan Wak
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53573
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53573
--- Comment #11 from Keean Schupke 2012-06-05 11:07:14 UTC
---
(In reply to comment #9)
Can you point me at where in the specification this is defined?
> (In reply to comment #2)
> > The function called in the template definition is clearly d
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53573
--- Comment #12 from Keean Schupke 2012-06-05 11:14:00 UTC
---
(In reply to comment #10)
although -fpermissive allows the code to compile (in some circumstances) it
does not in all, and it also produces incorrect output, for example:
#include
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53573
--- Comment #13 from Keean Schupke 2012-06-05 11:25:40 UTC
---
(In reply to comment #9)
>From ISO14882 14.6 - Name resolution [temp.res]
-8- When looking for the declaration of a name used in a template definition,
the usual lookup rules (basic
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53573
--- Comment #14 from Jonathan Wakely 2012-06-05
11:31:07 UTC ---
[temp.dep.res] says dependent name resolution considers declarations visible at
the point of definition, and declarations from associated namespaces from the
instantiation context a
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53573
--- Comment #15 from Jonathan Wakely 2012-06-05
11:33:59 UTC ---
(In reply to comment #12)
> (In reply to comment #10)
>
> although -fpermissive allows the code to compile (in some circumstances) it
> does not in all, and it also produces incorr
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53573
--- Comment #16 from Keean Schupke 2012-06-05 11:53:32 UTC
---
(In reply to comment #14)
Basic.lookup.argdep is not specific to templates, so why does the dependent
lookup work outside of templates?
int g(int x) {
return x - 1;
}
double g(
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53573
--- Comment #16 from Keean Schupke 2012-06-05 11:53:32 UTC
---
(In reply to comment #14)
Basic.lookup.argdep is not specific to templates, so why does the dependent
lookup work outside of templates?
int g(int x) {
return x - 1;
}
double g(
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53573
--- Comment #18 from Jonathan Wakely 2012-06-05
11:57:20 UTC ---
(In reply to comment #16)
> why does ADL work here if [basic.lookup.argdep] means what you imply?
That's not ADL, so I don't know what you're asking.
Bugzilla is not the right pla
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53573
--- Comment #19 from Keean Schupke 2012-06-05 12:55:06 UTC
---
(In reply to comment #18)
Sorry about that. It does indeed seem that the combination of [temp.dep.res]
and [basic.lookup.argdep] imply this behaviour. I think my point was more about
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53573
--- Comment #20 from Paolo Carlini 2012-06-05
16:31:21 UTC ---
I'm under the impression that the bug reports using the word 'broken' are the
ones most likely broken, err invalid. Maybe just another manifestation of the
illusion of confidence, wel
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53573
--- Comment #21 from Keean Schupke 2012-06-05 17:01:01 UTC
---
(In reply to comment #20)
Yes, once again sorry. Obviously not GCC's problem for implementing the
standard correctly, but this causes problems producing elegant datatype generic
code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53573
--- Comment #22 from Jonathan Wakely 2012-06-05
17:30:18 UTC ---
(In reply to comment #21)
> Is there any chance this 'feature' of GCC could be kept as a g++ specific
> extension in 'gnu++11' mode, as I think the old behaviour is an improvement
>
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53573
--- Comment #23 from Keean Schupke 2012-06-27 06:48:28 UTC
---
(In reply to comment #22)
> (In reply to comment #21)
> > Is there any chance this 'feature' of GCC could be kept as a g++ specific
> > extension in 'gnu++11' mode, as I think the old
21 matches
Mail list logo
