This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug c++/28088] [4.1 Regression] Internal compiler error on boost mpl test/apply.cpp
- From: "fang at csl dot cornell dot edu" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: 23 Oct 2006 03:34:50 -0000
- Subject: [Bug c++/28088] [4.1 Regression] Internal compiler error on boost mpl test/apply.cpp
- References: <bug-28088-12394@http.gcc.gnu.org/bugzilla/>
- Reply-to: gcc-bugzilla at gcc dot gnu dot org
------- Comment #12 from fang at csl dot cornell dot edu 2006-10-23 03:34 -------
Subject: Re: [4.1 Regression] Internal compiler error on
boost mpl test/apply.cpp
> There were PRs that showed that this extension (for those who don't
> remember: we allowed to match templates with trailing default arguments to
> match template template parameters with fewer template arguments) leads to
> wrong code in some circumstances. It's also one of the more obscure and
> less well thought out extensions, in my opinion.
>
> So my view of things is that the patch should be backported. But then I'm
> not in charge of this, of course :-)
My $.02, as a user:
* This said extension was never given a period of deprecation before it
was axed.
* This extension is used in much existing code in practice, especially
when using the STL container templates as template template arguments.
(Since the Alloc param is always defaulted to std::allocator...)
While I'm favor of removing extensions for the sake of standard
conformance (and fixing wrong code), I think that a sudden change on the
4.1 release branch might cause some agony to those who aren't prepared to
migrate to the 4.2-like behavior, in disabling the extension. The warning
might even state the consequence of this extension: unexpected behavior or
wrong code. Caveat emptor.
I suggest adding such a diagnostic on existing release branches, to give
fair warning when people are (often unknowingly) using the extension.
Fortunately, it is easy to write an autoconf-macro to detect this feature,
using the test case in http://gcc.gnu.org/gcc-4.2/changes.html.
(and I have done so, if anyone would like it)
End $.02.
Fang
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28088