[Bug c++/14912] Do not print default template arguments in error messages

[Bug c++/14912] Do not print default template arguments in error messages

[pcarlini at suse dot de]

------- Comment #35 from pcarlini at suse dot de  2007-10-12 11:04 -------
*** Bug 33747 has been marked as a duplicate of this bug. ***


-- 

pcarlini at suse dot de changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |pluto at agmk dot net


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14912

[Bug c++/14912] Do not print default template arguments in error messages

[pluto at agmk dot net]

------- Comment #36 from pluto at agmk dot net  2007-10-15 14:04 -------
could someone update this patch for 4.3?


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14912

[Bug c++/14912] Do not print default template arguments in error messages

[b0ntrict0r at yandex dot ru]

------- Comment #37 from b0ntrict0r at yandex dot ru  2008-09-19 12:22 -------
Created an attachment (id=16361)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16361&action=view)
Updated patch

Could someone test updated patch?


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14912

[Bug c++/14912] Do not print default template arguments in error messages

[pluto at agmk dot net]

------- Comment #38 from pluto at agmk dot net  2008-09-22 09:21 -------
(In reply to comment #37)
> Created an attachment (id=16361)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16361&action=view) [edit]
> Updated patch
> 
> Could someone test updated patch?
> 

it doesn't build.

../../gcc/cp/error.c: In function 'dump_template_argument':
../../gcc/cp/error.c:144: warning: passing argument 2 of
'dump_template_argument_list' makes pointer from integer without a cast
../../gcc/cp/error.c:144: error: too few arguments to function
'dump_template_argument_list'
../../gcc/cp/error.c: In function 'count_non_default_template_args':
../../gcc/cp/error.c:159: error: expected declaration specifiers before ')'
token
../../gcc/cp/error.c:184: error: expected '=', ',', ';', 'asm' or
'__attribute__' before '{' token
../../gcc/cp/error.c:212: error: expected '=', ',', ';', 'asm' or
'__attribute__' before '{' token
../../gcc/cp/error.c:258: error: expected '=', ',', ';', 'asm' or
'__attribute__' before '{' token
../../gcc/cp/error.c:302: error: expected declaration specifiers before '}'
token
../../gcc/cp/error.c:309: error: expected '=', ',', ';', 'asm' or
'__attribute__' before '{' token
../../gcc/cp/error.c:463: error: expected '=', ',', ';', 'asm' or
'__attribute__' before '{' token
../../gcc/cp/error.c:478: error: expected '=', ',', ';', 'asm' or
'__attribute__' before '{' token
../../gcc/cp/error.c:494: error: expected '=', ',', ';', 'asm' or
'__attribute__' before '{' token
../../gcc/cp/error.c:562: error: expected '=', ',', ';', 'asm' or
'__attribute__' before '{' token
../../gcc/cp/error.c:671: error: expected '=', ',', ';', 'asm' or
'__attribute__' before '{' token
(...)


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14912

[Bug c++/14912] Do not print default template arguments in error messages

[b0ntrict0r at yandex dot ru]

------- Comment #39 from b0ntrict0r at yandex dot ru  2008-09-22 15:12 -------
Created an attachment (id=16380)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16380&action=view)
Updated fixed


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14912

[Bug c++/14912] Do not print default template arguments in error messages

[pluto at agmk dot net]

------- Comment #40 from pluto at agmk dot net  2008-09-22 21:54 -------
(In reply to comment #39)
> Created an attachment (id=16380)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16380&action=view) [edit]
> Updated fixed
> 

1). still there is a warning:

../../gcc/cp/error.c: In function 'dump_template_argument_list':
../../gcc/cp/error.c:190: warning: signed and unsigned type in conditional
expression

2). seems to work, but...

#include <set>
#include <string>
template < typename T, typename S = std::set< std::string >, int N = 1 >
struct X
{
        virtual ~X() = 0;
};
void f()
{
        X< float > x;  // error here.
}

$ g++ d2.cpp -c
d2.cpp: In function &#8216;void f()&#8217;:
d2.cpp:10: error: cannot declare variable &#8216;x&#8217; to be of abstract
type &#8216;X<float>&#8217;
d2.cpp:5: note:   because the following virtual functions are pure within
&#8216;X<float>&#8217;:
d2.cpp:6: note:         X<T, S, N>::~X() [with T = float, S =
std::set<std::basic_string<char> >, int N = 1]

^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 d2.cpp:6: note could look like 'X<T, S, N>::~X() [with T = float]'


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14912

[Bug c++/14912] Do not print default template arguments in error messages

[pluto at agmk dot net]

------- Comment #41 from pluto at agmk dot net  2008-09-23 10:12 -------
and the lastest patch causes internal error in cc1plus in my codebase:

$
/local/devel/toolchain43/x86_64-gnu-linux.host64.diag/bin/x86_64-gnu-linux-g++
smsSimClock.ii -c -std=gnu++0x

Internal compiler error: Error reporting routines re-entered.
Please submit a full bug report,
with preprocessed source if appropriate.
See <http://gcc.gnu.org/bugs.html> for instructions.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14912

[Bug c++/14912] Do not print default template arguments in error messages

[pluto at agmk dot net]

------- Comment #42 from pluto at agmk dot net  2008-09-23 10:13 -------
Created an attachment (id=16389)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16389&action=view)
internal-error-testcase


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14912

[Bug c++/14912] Do not print default template arguments in error messages

[b0ntrict0r at yandex dot ru]

------- Comment #43 from b0ntrict0r at yandex dot ru  2008-09-23 14:31 -------
(In reply to comment #42)
> Created an attachment (id=16389)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16389&action=view) [edit]
> internal-error-testcase
> 

Hm... I can reproduce it with gcc 4.3.2 and cannot reproduce with 4.3.1:
original and patches gcc 4.3.1 works correctly.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14912

[Bug c++/14912] Do not print default template arguments in error messages

[pluto at agmk dot net]

------- Comment #44 from pluto at agmk dot net  2008-09-25 13:20 -------
i can reproduce this internal error on both 4.3.1 and 4.3-head.
here's a backtrace:

Breakpoint 1, error_recursion (context=0x10aeb40) at
../../gcc-4_3-branch/gcc/diagnostic.c:637
637       if (context->lock < 3)
(gdb) p *context
$1 = {
  printer = 0x112dc10,
  diagnostic_count =     {0,
    0,
    0,
    2,
    0,
    0,
    0,
    0,
    0,
    0},
  issue_warnings_are_errors_message = 1 '\001',
  warning_as_error_requested = 0 '\0',
  classify_diagnostic =     '\0' <repeats 764 times>,
  show_option_requested = 0 '\0',
  abort_on_error = 0 '\0',
  begin_diagnostic = 0x471f0c <cp_diagnostic_starter>,
  end_diagnostic = 0x471f55 <cp_diagnostic_finalizer>,
  internal_error = 0,
  last_function = 0x0,
  last_module = 0,
  lock = 2
}
(gdb) bt
#0  error_recursion (context=0x10aeb40) at
../../gcc-4_3-branch/gcc/diagnostic.c:637
#1  0x00000000005bbf84 in diagnostic_report_diagnostic (context=0x10aeb40,
diagnostic=0x7fff28b41dd0)
    at ../../gcc-4_3-branch/gcc/diagnostic.c:363
#2  0x00000000005bcc7a in internal_error (gmsgid=0xc2a3e7 "in %s, at %s:%d") at
../../gcc-4_3-branch/gcc/diagnostic.c:606
#3  0x00000000005bcdfe in fancy_abort (file=0xbe1418
"../../gcc-4_3-branch/gcc/cp/pt.c", line=15585, function=0xbe60f0
"dependent_type_p")
    at ../../gcc-4_3-branch/gcc/diagnostic.c:660
#4  0x0000000000452025 in dependent_type_p (type=0x7fa41a45acc0) at
../../gcc-4_3-branch/gcc/cp/pt.c:15585
#5  0x0000000000495f83 in cxx_sizeof_or_alignof_type (type=0x7fa41a45acc0,
op=250, complain=1 '\001')
    at ../../gcc-4_3-branch/gcc/cp/typeck.c:1289
#6  0x0000000000447db8 in tsubst_copy_and_build (t=0x7fa41a443b80,
args=0x7fa41a459b40, complain=tf_none, in_decl=0x0, function_p=0 '\0',
    integral_constant_expression_p=1 '\001') at
../../gcc-4_3-branch/gcc/cp/pt.c:10887
#7  0x000000000046d656 in count_non_default_template_args (args=0x7fa41a459b40,
params=0x7fa41a443c00)
    at ../../gcc-4_3-branch/gcc/cp/error.c:172
#8  0x000000000046fd64 in dump_template_parms (info=0x7fa41a45b750, primary=0,
flags=4) at ../../gcc-4_3-branch/gcc/cp/error.c:1343
#9  0x000000000046e387 in dump_aggr_type (t=0x7fa41a45ae40, flags=4) at
../../gcc-4_3-branch/gcc/cp/error.c:548
#10 0x000000000046dba5 in dump_type (t=0x7fa41a45ae40, flags=4) at
../../gcc-4_3-branch/gcc/cp/error.c:342
#11 0x000000000046f80a in dump_function_decl (t=0x7fa41a45c480, flags=4) at
../../gcc-4_3-branch/gcc/cp/error.c:1162
#12 0x000000000046f0e7 in dump_decl (t=0x7fa41a4a0b60, flags=4) at
../../gcc-4_3-branch/gcc/cp/error.c:947
#13 0x000000000047199b in decl_as_string (decl=0x7fa41a4a0b60, flags=4) at
../../gcc-4_3-branch/gcc/cp/error.c:2220
#14 0x00000000004719ca in lang_decl_name (decl=0x7fa41a4a0b60, v=2) at
../../gcc-4_3-branch/gcc/cp/error.c:2230
#15 0x00000000004bfbc9 in cxx_printable_name (decl=0x7fa41a4a0b60, v=2) at
../../gcc-4_3-branch/gcc/cp/tree.c:1207
#16 0x0000000000472143 in cp_print_error_function (context=0x10aeb40,
diagnostic=0x7fff28b42670) at ../../gcc-4_3-branch/gcc/cp/error.c:2471
#17 0x0000000000471f32 in cp_diagnostic_starter (context=0x10aeb40,
diagnostic=0x7fff28b42670) at ../../gcc-4_3-branch/gcc/cp/error.c:2424
#18 0x00000000005bc1b3 in diagnostic_report_diagnostic (context=0x10aeb40,
diagnostic=0x7fff28b42670)
    at ../../gcc-4_3-branch/gcc/diagnostic.c:421
#19 0x00000000005bcc7a in internal_error (gmsgid=0xc2a3e7 "in %s, at %s:%d") at
../../gcc-4_3-branch/gcc/diagnostic.c:606
#20 0x00000000005bcdfe in fancy_abort (file=0xbe1418
"../../gcc-4_3-branch/gcc/cp/pt.c", line=15585, function=0xbe60f0
"dependent_type_p")
    at ../../gcc-4_3-branch/gcc/diagnostic.c:660
#21 0x0000000000452025 in dependent_type_p (type=0x7fa41a45acc0) at
../../gcc-4_3-branch/gcc/cp/pt.c:15585
#22 0x0000000000495f83 in cxx_sizeof_or_alignof_type (type=0x7fa41a45acc0,
op=250, complain=1 '\001')
    at ../../gcc-4_3-branch/gcc/cp/typeck.c:1289
#23 0x0000000000447db8 in tsubst_copy_and_build (t=0x7fa41a443b80,
args=0x7fa41a459b40, complain=tf_none, in_decl=0x0, function_p=0 '\0',
    integral_constant_expression_p=1 '\001') at
../../gcc-4_3-branch/gcc/cp/pt.c:10887
#24 0x000000000046d656 in count_non_default_template_args (args=0x7fa41a459b40,
params=0x7fa41a443c00)
    at ../../gcc-4_3-branch/gcc/cp/error.c:172
#25 0x000000000046fd64 in dump_template_parms (info=0x7fa41a45b750, primary=0,
flags=4) at ../../gcc-4_3-branch/gcc/cp/error.c:1343
#26 0x000000000046e387 in dump_aggr_type (t=0x7fa41a45ae40, flags=4) at
../../gcc-4_3-branch/gcc/cp/error.c:548
#27 0x000000000046dba5 in dump_type (t=0x7fa41a45ae40, flags=4) at
../../gcc-4_3-branch/gcc/cp/error.c:342
#28 0x000000000046f80a in dump_function_decl (t=0x7fa41a45c480, flags=4) at
../../gcc-4_3-branch/gcc/cp/error.c:1162
#29 0x000000000046f0e7 in dump_decl (t=0x7fa41a4a0b60, flags=4) at
../../gcc-4_3-branch/gcc/cp/error.c:947
#30 0x000000000047199b in decl_as_string (decl=0x7fa41a4a0b60, flags=4) at
../../gcc-4_3-branch/gcc/cp/error.c:2220
#31 0x00000000004719ca in lang_decl_name (decl=0x7fa41a4a0b60, v=2) at
../../gcc-4_3-branch/gcc/cp/error.c:2230
#32 0x00000000004bfbc9 in cxx_printable_name (decl=0x7fa41a4a0b60, v=2) at
../../gcc-4_3-branch/gcc/cp/tree.c:1207
#33 0x0000000000472143 in cp_print_error_function (context=0x10aeb40,
diagnostic=0x7fff28b42f10) at ../../gcc-4_3-branch/gcc/cp/error.c:2471
#34 0x0000000000471f32 in cp_diagnostic_starter (context=0x10aeb40,
diagnostic=0x7fff28b42f10) at ../../gcc-4_3-branch/gcc/cp/error.c:2424
#35 0x00000000005bc1b3 in diagnostic_report_diagnostic (context=0x10aeb40,
diagnostic=0x7fff28b42f10)
    at ../../gcc-4_3-branch/gcc/diagnostic.c:421
#36 0x00000000005bcc7a in internal_error (gmsgid=0xc2a3e7 "in %s, at %s:%d") at
../../gcc-4_3-branch/gcc/diagnostic.c:606
#37 0x00000000005bcdfe in fancy_abort (file=0xbe1418
"../../gcc-4_3-branch/gcc/cp/pt.c", line=15585, function=0xbe60f0
"dependent_type_p")
    at ../../gcc-4_3-branch/gcc/diagnostic.c:660
#38 0x0000000000452025 in dependent_type_p (type=0x7fa41a45acc0) at
../../gcc-4_3-branch/gcc/cp/pt.c:15585
#39 0x0000000000495f83 in cxx_sizeof_or_alignof_type (type=0x7fa41a45acc0,
op=250, complain=1 '\001')
    at ../../gcc-4_3-branch/gcc/cp/typeck.c:1289
#40 0x0000000000447db8 in tsubst_copy_and_build (t=0x7fa41a443b80,
args=0x7fa41a459b40, complain=tf_none, in_decl=0x0, function_p=0 '\0',
    integral_constant_expression_p=1 '\001') at
../../gcc-4_3-branch/gcc/cp/pt.c:10887
#41 0x000000000046d656 in count_non_default_template_args (args=0x7fa41a459b40,
params=0x7fa41a443c00)
    at ../../gcc-4_3-branch/gcc/cp/error.c:172
#42 0x000000000046fd64 in dump_template_parms (info=0x7fa41a45b750, primary=0,
flags=4) at ../../gcc-4_3-branch/gcc/cp/error.c:1343
#43 0x000000000046e387 in dump_aggr_type (t=0x7fa41a45ae40, flags=4) at
../../gcc-4_3-branch/gcc/cp/error.c:548
#44 0x000000000046dba5 in dump_type (t=0x7fa41a45ae40, flags=4) at
../../gcc-4_3-branch/gcc/cp/error.c:342
#45 0x000000000046f80a in dump_function_decl (t=0x7fa41a45c480, flags=4) at
../../gcc-4_3-branch/gcc/cp/error.c:1162
#46 0x000000000046f0e7 in dump_decl (t=0x7fa41a4a0b60, flags=4) at
../../gcc-4_3-branch/gcc/cp/error.c:947
#47 0x000000000047199b in decl_as_string (decl=0x7fa41a4a0b60, flags=4) at
../../gcc-4_3-branch/gcc/cp/error.c:2220
#48 0x00000000004719ca in lang_decl_name (decl=0x7fa41a4a0b60, v=2) at
../../gcc-4_3-branch/gcc/cp/error.c:2230
#49 0x00000000004bfbc9 in cxx_printable_name (decl=0x7fa41a4a0b60, v=2) at
../../gcc-4_3-branch/gcc/cp/tree.c:1207
#50 0x0000000000446174 in tsubst_expr (t=0x7fa41a462580, args=0x7fa41a2a68a0,
complain=tf_warning_or_error, in_decl=0x7fa41a45c480,
    integral_constant_expression_p=0 '\0') at
../../gcc-4_3-branch/gcc/cp/pt.c:10291
#51 0x0000000000445dee in tsubst_expr (t=0x7fa41a4151b0, args=0x7fa41a2a68a0,
complain=tf_warning_or_error, in_decl=0x7fa41a45c480,
    integral_constant_expression_p=0 '\0') at
../../gcc-4_3-branch/gcc/cp/pt.c:10217
#52 0x0000000000446613 in tsubst_expr (t=0x7fa41a406b90, args=0x7fa41a2a68a0,
complain=tf_warning_or_error, in_decl=0x7fa41a45c480,
    integral_constant_expression_p=0 '\0') at
../../gcc-4_3-branch/gcc/cp/pt.c:10374
#53 0x0000000000450ffb in instantiate_decl (d=0x7fa41a4a0b60, defer_ok=0,
expl_inst_class_mem_p=0 '\0')
    at ../../gcc-4_3-branch/gcc/cp/pt.c:15040
#54 0x0000000000451264 in instantiate_pending_templates (retries=0) at
../../gcc-4_3-branch/gcc/cp/pt.c:15138
#55 0x000000000046c4e3 in cp_write_global_declarations () at
../../gcc-4_3-branch/gcc/cp/decl2.c:3331
#56 0x000000000077b6ff in compile_file () at
../../gcc-4_3-branch/gcc/toplev.c:1055
#57 0x000000000077d142 in do_compile () at
../../gcc-4_3-branch/gcc/toplev.c:2240
#58 0x000000000077d1a6 in toplev_main (argc=13, argv=0x7fff28b43e78) at
../../gcc-4_3-branch/gcc/toplev.c:2272
#59 0x000000000052ed37 in main (argc=13, argv=0x7fff28b43e78) at
../../gcc-4_3-branch/gcc/main.c:35


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14912

[Bug c++/14912] Do not print default template arguments in error messages

[pluto at agmk dot net]

------- Comment #45 from pluto at agmk dot net  2009-03-02 21:04 -------
bug ping...


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14912

[Bug c++/14912] Do not print default template arguments in error messages

[hjl dot tools at gmail dot com]

------- Comment #46 from hjl dot tools at gmail dot com  2009-03-02 21:59 -------
(In reply to comment #42)
> Created an attachment (id=16389)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16389&action=view) [edit]
> internal-error-testcase
> 

I got

gnu-6:pts/4[294]> ./xgcc -B./ -S /tmp/smsSimClock.ii   -std=gnu++0x
gnu-6:pts/4[295]> ./xgcc -B./ -S /tmp/smsSimClock.ii   -std=gnu++0x -O
gnu-6:pts/4[296]> ./xgcc -B./ -S /tmp/smsSimClock.ii   -std=gnu++0x -O2

with gcc 4.4 revision 144547.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14912

[Bug c++/14912] Do not print default template arguments in error messages

[jason at gcc dot gnu dot org]

------- Comment #47 from jason at gcc dot gnu dot org  2009-03-03 18:55 -------
Created an attachment (id=17392)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17392&action=view)
updated patch that fixes ICE

Here's an update of the patch that fixes the ICE; we need to set
processing_template_decl around the call to tsubst_copy_and_build.


-- 

jason at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
Attachment #8457 is|0                           |1
           obsolete|                            |
  Attachment #16380|0                           |1
        is obsolete|                            |


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14912

[Bug c++/14912] Do not print default template arguments in error messages

[pluto at agmk dot net]

------- Comment #48 from pluto at agmk dot net  2009-03-23 19:00 -------
with the latest patch applied on top of 4.4-svn i get
following diagnostic for simple code snippet:

$ cat 14912-2.cpp
#include <string>
std::string s = 7;

$ /opt/gcc44/bin/g++ -c -Wall -O2 14912-2.cpp
14912-2.cpp:2: error: invalid conversion from 'int' to 'const char*'
14912-2.cpp:2: error:   initializing argument 1 of 'std::basic_string<_CharT,
_Traits, _Alloc>::basic_string(const _CharT*, const _Alloc&) [with _CharT =
char, _Traits = std::char_traits<char>, _Alloc = std::allocator<char>]'

defaults are still printed in this case.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14912

[Bug c++/14912] Do not print default template arguments in error messages

[jason at gcc dot gnu dot org]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1152 bytes --]



------- Comment #49 from jason at gcc dot gnu dot org  2009-04-05 06:06 -------
I think it's best to just leave the default arguments in when pretty-printing a
function template specialization, as in the string example; otherwise we won't
know what _Alloc in the function parameter list means.

Just omitting default arguments when dumping class template specializations
will solve the combinatorial explosion problem as displayed in the original bug
report; if we're dealing with vector<vector<vector<int> > > a bug report
referring to a member of vector will look like

.../libstdc++-v3/include/bits/stl_vector.h:1006:   instantiated from ‘void
std::vector<_Tp, _Alloc>::_M_initialize_dispatch(_InputIterator,
_InputIterator, std::__false_type) [with _InputIterator = double, _Tp =
std::vector<std::vector<int> >, _Alloc =
std::allocator<std::vector<std::vector<int> > >]’

So we only see std::allocator once, not in all the sub-vectors.  This seems to
me like the right balance, which happens to be what the current patch provides.
 I'm going to clean it up a bit more and check it in.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14912

[Bug c++/14912] Do not print default template arguments in error messages

[jason at gcc dot gnu dot org]

------- Comment #50 from jason at gcc dot gnu dot org  2009-04-05 19:29 -------
Subject: Bug 14912

Author: jason
Date: Sun Apr  5 19:29:02 2009
New Revision: 145566

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=145566
Log:
        PR c++/14912
        * error.c (count_non_default_template_args): New fn.
        (dump_template_parms): Call it.
        (dump_template_argument_list): Call it.  Add parms parm.
        (dump_template_argument): Adjust call to dump_template_argument_list.
        (dump_type, dump_decl): Likewise.
        (dump_template_bindings): Refactor logic.

Added:
    trunk/gcc/testsuite/g++.dg/template/error39.C
Modified:
    trunk/gcc/cp/ChangeLog
    trunk/gcc/cp/error.c


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14912

[Bug c++/14912] Do not print default template arguments in error messages

[jason at gcc dot gnu dot org]

------- Comment #51 from jason at gcc dot gnu dot org  2009-04-09 20:30 -------
Patch applied for 4.5.


-- 

jason at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|ASSIGNED                    |RESOLVED
         Resolution|                            |FIXED


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14912

[Bug c++/14912] Do not print default template arguments in error messages

[arekm at pld-linux dot org]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 8920 bytes --]



------- Comment #52 from arekm at pld-linux dot org  2009-07-26 10:38 -------
btw. this patch backported to gcc 4.4 [1] causes build problems with -g flags
like: https://svn.boost.org/trac/boost/ticket/3287

I just tested gcc trunk and the problem is the same.

How to test? On linux x86_64 (it's 4MB preprocessed source so won't work on
other architectures) do:
wget http://carme.pld-linux.org/~arekm/gcc-pr14912.cxx
[arekm@carme-pld ~]$ ~/gcc-test/bin/g++ -v
Using built-in specs.                     
Target: x86_64-unknown-linux-gnu          
Configured with: ./configure --prefix=/home/users/arekm/gcc-test
--enable-languages=c,c++
Thread model: posix                                                             
gcc version 4.5.0 20090726 (experimental) (GCC)                                 
[arekm@carme-pld ~]$ ~/gcc-test/bin/g++ -c gcc-pr14912.cxx 
/home/users/arekm/rpm/BUILD/kdepimlibs-4.2.98/akonadi/itemserializer.cpp: In
constructor ‘PluginRegistry::PluginRegistry()’:
/home/users/arekm/rpm/BUILD/kdepimlibs-4.2.98/akonadi/itemserializer.cpp:157:172:
internal compiler error: in create_tmp_var, at gimplify.c:504
Please submit a full bug report,                                                
with preprocessed source if appropriate.                                        
See <http://gcc.gnu.org/bugs.html> for instructions.                            
zsh: exit 1     ~/gcc-test/bin/g++ -c gcc-pr14912.cxx


So looks ok (beside internal compiler error which is not interesting for us in
this case). But now look what happens if -g2 is used:


[arekm@carme-pld ~]$ ~/gcc-test/bin/g++ -g2 -c gcc-pr14912.cxx
In file included from /usr/include/boost/graph/adjacency_list.hpp:39:0,
                 from
/home/users/arekm/rpm/BUILD/kdepimlibs-4.2.98/akonadi/itemserializer.cpp:39:
/usr/include/boost/graph/graph_traits.hpp: In instantiation of
‘boost::graph_traits<boost::adjacency_list<> >’:
/usr/include/boost/graph/adjacency_iterator.hpp:53:3:   instantiated from
‘boost::adjacency_iterator_generator<boost::adjacency_list<>, long unsigned
int,
boost::detail::out_edge_iter<__gnu_cxx::__normal_iterator<boost::detail::sep_<long
unsigned int, boost::no_property>*, std::vector<boost::detail::sep_<long
unsigned int, boost::no_property> > >, long unsigned int,
boost::detail::edge_desc_impl<boost::directed_tag, long unsigned int>, long
int> >’                   
/usr/include/boost/graph/detail/adjacency_list.hpp:2346:56:   instantiated from
‘boost::detail::adj_list_gen<boost::adjacency_list<>, boost::vecS,
boost::vecS, boost::directedS, boost::no_property, boost::no_property,
boost::no_property, boost::listS>::config’                                    
/usr/include/boost/graph/detail/adjacency_list.hpp:516:7:   instantiated from
‘boost::directed_edges_helper<boost::detail::adj_list_gen<boost::adjacency_list<>,
boost::vecS, boost::vecS, boost::directedS, boost::no_property,
boost::no_property, boost::no_property, boost::listS>::config>’               
/usr/include/boost/graph/detail/adjacency_list.hpp:568:46:   instantiated from
‘boost::directed_graph_helper<boost::detail::adj_list_gen<boost::adjacency_list<>,
boost::vecS, boost::vecS, boost::directedS, boost::no_property,
boost::no_property, boost::no_property, boost::listS>::config>’               
/usr/include/boost/graph/detail/adjacency_list.hpp:1489:5:   instantiated from
‘boost::adj_list_helper<boost::detail::adj_list_gen<boost::adjacency_list<>,
boost::vecS, boost::vecS, boost::directedS, boost::no_property,
boost::no_property, boost::no_property, boost::listS>::config,
boost::directed_graph_helper<boost::detail::adj_list_gen<boost::adjacency_list<>,
boost::vecS, boost::vecS, boost::directedS, boost::no_property,
boost::no_property, boost::no_property, boost::listS>::config> >’             
/usr/include/boost/graph/detail/adjacency_list.hpp:2069:5:   instantiated from
‘boost::vec_adj_list_impl<boost::adjacency_list<>,
boost::detail::adj_list_gen<boost::adjacency_list<>, boost::vecS, boost::vecS,
boost::directedS, boost::no_property, boost::no_property, boost::no_property,
boost::listS>::config,
boost::directed_graph_helper<boost::detail::adj_list_gen<boost::adjacency_list<>,
boost::vecS, boost::vecS, boost::directedS, boost::no_property,
boost::no_property, boost::no_property, boost::listS>::config> >’
/usr/include/boost/graph/adjacency_list.hpp:380:3:   instantiated from
‘boost::adjacency_list<>’
/home/users/arekm/rpm/BUILD/kdepimlibs-4.2.98/akonadi/itemserializer.cpp:184:38:
  instantiated from here
/usr/include/boost/graph/graph_traits.hpp:29:47: error: no type named
‘vertex_descriptor’ in ‘class boost::adjacency_list<>’
/usr/include/boost/graph/graph_traits.hpp:30:45: error: no type named
‘edge_descriptor’ in ‘class boost::adjacency_list<>’
/usr/include/boost/graph/graph_traits.hpp:31:48: error: no type named
‘adjacency_iterator’ in ‘class boost::adjacency_list<>’
/usr/include/boost/graph/graph_traits.hpp:32:47: error: no type named
‘out_edge_iterator’ in ‘class boost::adjacency_list<>’
/usr/include/boost/graph/graph_traits.hpp:33:46: error: no type named
‘in_edge_iterator’ in ‘class boost::adjacency_list<>’
/usr/include/boost/graph/graph_traits.hpp:34:45: error: no type named
‘vertex_iterator’ in ‘class boost::adjacency_list<>’
/usr/include/boost/graph/graph_traits.hpp:35:43: error: no type named
‘edge_iterator’ in ‘class boost::adjacency_list<>’
/usr/include/boost/graph/graph_traits.hpp:37:47: error: no type named
‘directed_category’ in ‘class boost::adjacency_list<>’
/usr/include/boost/graph/graph_traits.hpp:38:52: error: no type named
‘edge_parallel_category’ in ‘class boost::adjacency_list<>’
/usr/include/boost/graph/graph_traits.hpp:39:48: error: no type named
‘traversal_category’ in ‘class boost::adjacency_list<>’
/usr/include/boost/graph/graph_traits.hpp:41:48: error: no type named
‘vertices_size_type’ in ‘class boost::adjacency_list<>’
/usr/include/boost/graph/graph_traits.hpp:42:45: error: no type named
‘edges_size_type’ in ‘class boost::adjacency_list<>’
/usr/include/boost/graph/graph_traits.hpp:43:46: error: no type named
‘degree_size_type’ in ‘class boost::adjacency_list<>’
In file included from /usr/include/boost/graph/topological_sort.hpp:16:0,
                 from
/home/users/arekm/rpm/BUILD/kdepimlibs-4.2.98/akonadi/itemserializer.cpp:40:
/usr/include/boost/graph/depth_first_search.hpp: In function ‘void
boost::depth_first_search(const VertexListGraph&, const
boost::bgl_named_params<P, T, R>&) [with VertexListGraph =
boost::adjacency_list<>, P =
boost::topo_sort_visitor<std::back_insert_iterator<QVector<int> > >, T =
boost::graph_visitor_t, R = boost::bgl_named_params<int,
boost::buffer_param_t>]’:
/usr/include/boost/graph/topological_sort.hpp:64:5:   instantiated from ‘void
boost::topological_sort(VertexListGraph&, OutputIterator, const
boost::bgl_named_params<P, T, R>&) [with VertexListGraph =
boost::adjacency_list<>, OutputIterator =
std::back_insert_iterator<QVector<int> >, P = int, T = boost::buffer_param_t, R
= boost::no_property]’
/usr/include/boost/graph/topological_sort.hpp:70:5:   instantiated from ‘void
boost::topological_sort(VertexListGraph&, OutputIterator) [with VertexListGraph
= boost::adjacency_list<>, OutputIterator =
std::back_insert_iterator<QVector<int> >]’
/home/users/arekm/rpm/BUILD/kdepimlibs-4.2.98/akonadi/itemserializer.cpp:198:69:
  instantiated from here
/usr/include/boost/graph/depth_first_search.hpp:296:5: error: no matching
function for call to ‘depth_first_search(const boost::adjacency_list<>&,
const boost::topo_sort_visitor<std::back_insert_iterator<QVector<int> > >&,
boost::detail::color_map_maker<boost::adjacency_list<>,
boost::parameter::aux::arg_list<boost::parameter::aux::tagged_argument<boost::graph::keywords::tag::visitor,
const boost::topo_sort_visitor<std::back_insert_iterator<QVector<int> > > >,
boost::parameter::aux::arg_list<boost::parameter::aux::tagged_argument<boost::graph::keywords::tag::buffer,
const int> > > >::map_type, const long unsigned int&)’
/home/users/arekm/rpm/BUILD/kdepimlibs-4.2.98/akonadi/itemserializer.cpp: In
constructor ‘PluginRegistry::PluginRegistry()’:
/home/users/arekm/rpm/BUILD/kdepimlibs-4.2.98/akonadi/itemserializer.cpp:157:172:
internal compiler error: in create_tmp_var, at gimplify.c:504
Please submit a full bug report,
with preprocessed source if appropriate.
See <http://gcc.gnu.org/bugs.html> for instructions.
zsh: exit 1     ~/gcc-test/bin/g++ -g2 -c gcc-pr14912.cxx


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14912

[Bug c++/14912] Do not print default template arguments in error messages

[jason at gcc dot gnu dot org]

------- Comment #53 from jason at gcc dot gnu dot org  2009-07-29 20:36 -------
Subject: Bug 14912

Author: jason
Date: Wed Jul 29 20:35:40 2009
New Revision: 150223

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=150223
Log:
        PR c++/14912
        * cp-tree.h (enum tsubst_flags): Add tf_no_class_instantiations.
        * error.c (count_non_default_template_args): Pass it.
        * pt.c (tsubst) [TYPENAME_TYPE]: Don't complete type if it's set.

Added:
    trunk/gcc/testsuite/g++.dg/template/defarg13.C
Modified:
    trunk/gcc/cp/ChangeLog
    trunk/gcc/cp/cp-tree.h
    trunk/gcc/cp/error.c
    trunk/gcc/cp/pt.c
    trunk/gcc/testsuite/ChangeLog


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14912

[Bug c++/14912] Do not print default template arguments in error messages

[jason at gcc dot gnu dot org]

------- Comment #54 from jason at gcc dot gnu dot org  2009-07-29 21:09 -------
Thanks for the testcase, the patch I just checked in should fix it.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14912

[Bug c++/14912] Do not print default template arguments in error messages

[gdr at integrable-solutions dot net]

------- Additional Comments From gdr at integrable-solutions dot net  2005-03-27 03:16 -------
Subject: Re:  Do not print default template arguments in error messages

"giovannibajo at libero dot it" <gcc-bugzilla@gcc.gnu.org> writes:

| (In reply to comment #31)
| 
| > >Patched: 
| > >test.cc: In member function 'void A<T, N, X>::foo() [with T = int]': 
| > >test.cc:14:   instantiated from here 
| > >test.cc:9: error: 'class std::vector<int>' has no member 
| named 'doesnotexist' 
| >  
| > That's a good improvement, but do you think you could write the first line 
| > with A<T> instead of A<T,N,X>? I find it confusing to see the second and 
| > third template argument, but then no explanation as to their values... 
| 
| That's exactly what I was hinting at at the end of comment #7. I then 
| implemented the solution proposed in comment #8 (showing them with <default>), 
| until Gaby said it would be a showstopper.

*If* you print N and X then yes it is surprising not to say what they
 bind to ("explanation"); but "<default>" is not good.
However, if you do not print them, then you don't have to explain what
 they mean.

| I will investigate printing A<T> instead of A<T,N,X>, but I am not confident it 
| can be done easily (if at all).

If you're going to print only the binding of "T", and not for N nor
X, then you do know that you don't have to print them, i.e. they are
instantiated with default values.
Granted, as the code in error.c currently is, you would have those
information only after the fact (in dump_bindings()).  However, the
code path in cxx-pretty-print.c is different and more amenable to that
kind of thing.  Alternatively, you could do lazy printing with error.c
but that is more complicated than it should be.

-- Gaby


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14912

[Bug c++/14912] Do not print default template arguments in error messages

[dave at boost-consulting dot com]

------- Additional Comments From dave at boost-consulting dot com  2005-03-27 01:52 -------
This is obviously becoming personal.  I wanted a record of my technical concerns
in the bug database, but as the tone has changed I don't think it's appropriate
to continue this here.  I will reply to Gaby offline and try to clear up the
misunderstandings there.


-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|dave at boost-consulting dot|
                   |com                         |


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14912

[Bug c++/14912] Do not print default template arguments in error messages

[giovannibajo at libero dot it]

------- Additional Comments From giovannibajo at libero dot it  2005-03-27 00:56 -------
(In reply to comment #31)

> >Patched: 
> >test.cc: In member function 'void A<T, N, X>::foo() [with T = int]': 
> >test.cc:14:   instantiated from here 
> >test.cc:9: error: 'class std::vector<int>' has no member 
named 'doesnotexist' 
>  
> That's a good improvement, but do you think you could write the first line 
> with A<T> instead of A<T,N,X>? I find it confusing to see the second and 
> third template argument, but then no explanation as to their values... 

That's exactly what I was hinting at at the end of comment #7. I then 
implemented the solution proposed in comment #8 (showing them with <default>), 
until Gaby said it would be a showstopper.

I will investigate printing A<T> instead of A<T,N,X>, but I am not confident it 
can be done easily (if at all).

-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14912

[Bug c++/14912] Do not print default template arguments in error messages

[bangerth at dealii dot org]

------- Additional Comments From bangerth at dealii dot org  2005-03-26 22:57 -------
Giovanni, in your example in comment #27, you get this: 
 
>Patched: 
>test.cc: In member function 'void A<T, N, X>::foo() [with T = int]': 
>test.cc:14:   instantiated from here 
>test.cc:9: error: 'class std::vector<int>' has no member named 'doesnotexist' 
 
That's a good improvement, but do you think you could write the first line 
with A<T> instead of A<T,N,X>? I find it confusing to see the second and 
third template argument, but then no explanation as to their values... 
 
Thanks 
  Wolfgang 

-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14912

[Bug c++/14912] Do not print default template arguments in error messages

[gdr at integrable-solutions dot net]

------- Additional Comments From gdr at integrable-solutions dot net  2005-03-26 19:52 -------
Subject: Re:  Do not print default template arguments in error messages

"giovannibajo at libero dot it" <gcc-bugzilla@gcc.gnu.org> writes:

| ------- Additional Comments From giovannibajo at libero dot it  2005-03-26 19:24 -------
| OK, before I clean up the patch, I'll post an example. For this code:
| 
| ----------------------------------------------
| #include <map>
| #include <vector>
| #include <string>
| 
| std::map<std::string, std::vector<int> > m;
| 
| void bar(void)
| {
|   std::vector<int> k;
|   m.insert(std::make_pair(0, k));
| }
| ----------------------------------------------
| 
| I get this:
| 
| <path>/stl_pair.h: In constructor 'std::pair<_T1, _T2>::pair(const 
| std::pair<_U1, _U2>&) [with _U1 = int, _U2 = std::vector<int>, _T1 = const 
| std::string, _T2 = std::vector<int>]':
| test3.cc:10:   instantiated from here
| <path>/stl_pair.h:90: error: invalid conversion from 'const int' to 'const 
| char*'
| <path>/stl_pair.h:90: error:   initializing argument 1 
| of 'std::basic_string<_CharT, _Traits, _Alloc>::basic_string(const _CharT*, 
| const _Alloc&) [with _CharT = char]'
| 
| (I manually edited '<path>')
| Without my patch, I get this:

That is  fair improvement.  I realize we don't retain std::string in
the last diagnostic, but we don't need to do that before you check-in
your patch -- that is a whole project in itself.

-- Gaby


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14912

[Bug c++/14912] Do not print default template arguments in error messages

[giovannibajo at libero dot it]

------- Additional Comments From giovannibajo at libero dot it  2005-03-26 19:26 -------
Another comparison:

---------------------------------------
#include <vector>

template <class T, int N=0, int X=1>
struct A
{
  std::vector<T> v;
  
  void foo(void)
  { v.doesnotexist(); }
};

void foo(void)
{
  A<int,0> a;
  a.foo();
}
---------------------------------------

Patched:
test.cc: In member function 'void A<T, N, X>::foo() [with T = int]':
test.cc:14:   instantiated from here
test.cc:9: error: 'class std::vector<int>' has no member named 'doesnotexist'


Unpatched:
test.cc: In member function `void A<T, N, X>::foo() [with T = int, int N = 0, 
int X = 1]':
test.cc:14:   instantiated from here
test.cc:9: error: 'class std::vector<int, std::allocator<int> >' has no member 
named 'doesnotexist'



-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14912

[Bug c++/14912] Do not print default template arguments in error messages

[giovannibajo at libero dot it]

------- Additional Comments From giovannibajo at libero dot it  2005-03-26 19:24 -------
OK, before I clean up the patch, I'll post an example. For this code:

----------------------------------------------
#include <map>
#include <vector>
#include <string>

std::map<std::string, std::vector<int> > m;

void bar(void)
{
  std::vector<int> k;
  m.insert(std::make_pair(0, k));
}
----------------------------------------------

I get this:

<path>/stl_pair.h: In constructor 'std::pair<_T1, _T2>::pair(const 
std::pair<_U1, _U2>&) [with _U1 = int, _U2 = std::vector<int>, _T1 = const 
std::string, _T2 = std::vector<int>]':
test3.cc:10:   instantiated from here
<path>/stl_pair.h:90: error: invalid conversion from 'const int' to 'const 
char*'
<path>/stl_pair.h:90: error:   initializing argument 1 
of 'std::basic_string<_CharT, _Traits, _Alloc>::basic_string(const _CharT*, 
const _Alloc&) [with _CharT = char]'

(I manually edited '<path>')
Without my patch, I get this:


<path>/stl_pair.h: In constructor `std::pair<_T1, _T2>::pair(const 
std::pair<_U1, _U2>&) [with _U1 = int, _U2 = std::vector<int, 
std::allocator<int> >, _T1 = const std::string, _T2 = std::vector<int, 
std::allocator<int> >]':
test3.cc:10:   instantiated from here
<path>/stl_pair.h:90: error: invalid conversion from `const int' to `const 
char*'
<path>/stl_pair.h:90: error:   initializing argument 1 of 
`std::basic_string<_CharT, _Traits, _Alloc>::basic_string(const _CharT*, const 
_Alloc&) [with _CharT = char, _Traits = std::char_traits<char>, _Alloc = 
std::allocator<char>]'


If someone wants to submit an additional testcase, I'm happy to test it.

-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14912

[Bug c++/14912] Do not print default template arguments in error messages

[dave at boost-consulting dot com]

------- Additional Comments From dave at boost-consulting dot com  2005-03-26 16:14 -------
This is obviously becoming personal.  I wanted a record of my technical concerns
in the bug database, but as the tone has changed I don't think it's appropriate
to continue this here.  I will reply to Gaby offline and try to clear up the
misunderstandings there.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14912

[Bug c++/14912] Do not print default template arguments in error messages

[gdr at integrable-solutions dot net]

------- Additional Comments From gdr at integrable-solutions dot net  2005-03-26 15:55 -------
Subject: Re:  Do not print default template arguments in error messages

"dave at boost-consulting dot com" <gcc-bugzilla@gcc.gnu.org> writes:

| ------- Additional Comments From dave at boost-consulting dot com  2005-03-26 12:57 -------
| Subject: Re:  Do not print default template arguments in error messages
| 
| "gdr at integrable-solutions dot net" <gcc-bugzilla@gcc.gnu.org> writes:
| 
| > ------- Additional Comments From gdr at integrable-solutions dot net  2005-03-26 04:13 -------
| > Subject: Re:  Do not print default template arguments in error messages
| >
| > "dave at boost-consulting dot com" <gcc-bugzilla@gcc.gnu.org> writes:
| >
| > [...]
| >
| > | Please, I'm begging you not to go down this road.  GCC is one of the
| >
| > I know you have strong opinions on what compilers should print; we had
| > part of this discussions on -core and it did not seem like that was a
| > universal solution that handles all the cases.  
| 
| First, I don't know if I've misunderstood what you meant by "show how
| it was written,"

If user writes vector<int>, I would like to print vector<T> [with T = int],
not vector<int>, <default> > (or variants).  Similarly, if user
wirtes vector<int, allocator<int> >, then ideally I would also like to
print vector<T, Allocator> [with T = int, Allocator = alloctor<int>].

There are discussions about carret diagnostics, but this is not it.

[...]

| > I'm going to scheme that handle the majority of the cases right.
| 
| Assuming your intention is to do what I fear (otherwise, please ignore
| the rest):

I can't ignore ignore the rest, not because I'm goiing to do something
stupid but because you also request to tke what you're saying
"seriously".  And also, because, I'm a bit fed up of your arrogance.

[...]

| > | only compilers that gets it right today (VC8 will follow), and all
| > | the ones that try to follow the "show how it was written" rule
| > | often give errors that are, for all practical purposes, unusable.
| > | If you make GCC work like the others, it will be a leap backwards
| > | and a terrible disservice to users.
| >
| > yes, you're entitled to your opinions.
| 
| This is very disappointing.  Condescencion is entirely uncalled for.

oh really?  when people try to do things, you immediately think or
"fear" that they are going to do the wrong thing.  Oh yeah, that is
not called "condescencion", you're just feeling they are stupid.

| I won't claim to know what your level of expertise is, but I know I've
| done more comparative research on template-related error messages than
| most people.  If you care about GCC's usability you ought at least to
| take what I say seriously.

Oh, I do read what you write -- everytime I have the chance.  
I know also from experience usually it is probably good not to say
anything contrary to your opinions.  But I can't resist, especially
when you don't quite understand the variations. 

-- Gaby


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14912

[Bug c++/14912] Do not print default template arguments in error messages

[gdr at integrable-solutions dot net]

------- Additional Comments From gdr at integrable-solutions dot net  2005-03-26 15:40 -------
Subject: Re:  Do not print default template arguments in error messages

"giovannibajo at libero dot it" <gcc-bugzilla@gcc.gnu.org> writes:

| ------- Additional Comments From giovannibajo at libero dot it  2005-03-26 11:59 -------
| Subject: Re:  Do not print default template arguments in error messages
| 
| gdr at integrable-solutions dot net <gcc-bugzilla@gcc.gnu.org> wrote:
| 
| >>>> The first patch will deal with just removal of default
| >>>> arguments, and I believe that the less intrusive and clean
| >>>> solution is to
| >>>> display <default> in the "with" clause.
| >>> please:
| >>>   (1) don't do an unconditional removal;
| >>>   (2) don't show <default>.
| >>> I would oppose any patch short of that.
| >>
| >> Yes, the remove will be conditioned on a flag (but I believe this
| >> has to become
| >> the default).
| >
| > which flag?  A compiler option?  I don't think a multiplication of
| > compiler options for this stuff is a good way to go.
| 
| Then what? You said "don't do an unconditional removal". What did you mean,
| exactly?


Use the format flags -- I think I already said that -- '#'.
If it is present (i.e. the verbose parameter non zero, therefore the
flags asking for default values) then honor it.  Otherwise effectively
don't print the default values.

-- Gaby


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14912

[Bug c++/14912] Do not print default template arguments in error messages

[dave at boost-consulting dot com]

------- Additional Comments From dave at boost-consulting dot com  2005-03-26 12:57 -------
Subject: Re:  Do not print default template arguments in error messages

"gdr at integrable-solutions dot net" <gcc-bugzilla@gcc.gnu.org> writes:

> ------- Additional Comments From gdr at integrable-solutions dot net  2005-03-26 04:13 -------
> Subject: Re:  Do not print default template arguments in error messages
>
> "dave at boost-consulting dot com" <gcc-bugzilla@gcc.gnu.org> writes:
>
> [...]
>
> | Please, I'm begging you not to go down this road.  GCC is one of the
>
> I know you have strong opinions on what compilers should print; we had
> part of this discussions on -core and it did not seem like that was a
> universal solution that handles all the cases.  

First, I don't know if I've misunderstood what you meant by "show how
it was written," so I'd really appreciate if you'd clarify that before
we go any further down this road.  To make it easy on you, let me try
to be very clear about what I fear.  If you run this through the
Comeau on-line compiler:

  template <class T>
  struct foo1
  {
      // ...
      typedef T* pointer; 
  };

  template <class T>
  struct foo2
  {
      // ...
      typedef T** pointer; // oops, should've been T*
  };

  template <class U, class V>
  struct bar
  {
      bar( V v )
      {
          U u = v;
      }
  };

  template <class U, class V>
  struct baz
  {
      baz()
      {
          bar<
              typename foo1<U>::pointer,
              typename foo2<V>::pointer
          > b(0);
      };
  };

  baz<int,int> x;

You'll get a message that says:

  line 20: error: a value of type "foo2<int>::pointer" cannot be
          used to initialize an entity of type "foo1<int>::pointer"
            U u = v;
                  ^
          detected during:
            instantiation of "bar<U, V>::bar(V) [with U=foo1<int>::pointer,
                      V=foo2<int>::pointer]" at line 32
            instantiation of "baz<U, V>::baz() [with U=int, V=int]" at line 36


It is the appearance of "foo1<int>::pointer" and "foo2<int>::pointer"
in the error message, rather than "int*" and "int**", that I'm
concerned about.  Nothing in the error message points at
the definition of foo1 or foo2 above, so the user gets no help in
understanding which one might be the true cause of the error.  And
even if it pointed at foo1 or foo2, in general the real source of
foo2<T>::pointer could easily have been some other template:

  template <class T>
  struct foo1
  {
      typedef typename foobar<T>::value_type* pointer; 
  };

This happens very typically in the standard library, where nested
types are transferred and modified from allocators into containers and
so forth.  I want to be sure that GCC continues to show "int*"
and "int**" in these cases.  

> I'm going to scheme that handle the majority of the cases right.

Assuming your intention is to do what I fear (otherwise, please ignore
the rest):

On what basis can you say that?  Have you got some measurement of what
the majority of cases look like, and an objective way to understand
what "right" is?

No solution universally handles all the cases perfectly, but we can
make some objective analysis of how tractable it is to find any given
piece of important information in the various schemes.  Going down the
EDG path may make a few kinds of analysis incrementally easier, but it
makes other kinds vastly harder, to the point of being nearly
impossible.  I keep a copy of GCC on hand at all times just for
situations like this, no mater what compiler I'm using.  I find it
ironic that if GCC makes the change I fear, the only compiler left
that yields workable error messages in these kinds of situations will
be from Microsoft.

> | only compilers that gets it right today (VC8 will follow), and all
> | the ones that try to follow the "show how it was written" rule
> | often give errors that are, for all practical purposes, unusable.
> | If you make GCC work like the others, it will be a leap backwards
> | and a terrible disservice to users.
>
> yes, you're entitled to your opinions.

This is very disappointing.  Condescencion is entirely uncalled for.
I won't claim to know what your level of expertise is, but I know I've
done more comparative research on template-related error messages than
most people.  If you care about GCC's usability you ought at least to
take what I say seriously.



-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14912

[Bug c++/14912] Do not print default template arguments in error messages

[giovannibajo at libero dot it]

------- Additional Comments From giovannibajo at libero dot it  2005-03-26 11:59 -------
Subject: Re:  Do not print default template arguments in error messages

gdr at integrable-solutions dot net <gcc-bugzilla@gcc.gnu.org> wrote:

>>>> The first patch will deal with just removal of default
>>>> arguments, and I believe that the less intrusive and clean
>>>> solution is to
>>>> display <default> in the "with" clause.
>>> please:
>>>   (1) don't do an unconditional removal;
>>>   (2) don't show <default>.
>>> I would oppose any patch short of that.
>>
>> Yes, the remove will be conditioned on a flag (but I believe this
>> has to become
>> the default).
>
> which flag?  A compiler option?  I don't think a multiplication of
> compiler options for this stuff is a good way to go.

Then what? You said "don't do an unconditional removal". What did you mean,
exactly?

Giovanni Bajo



-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14912

[Bug c++/14912] Do not print default template arguments in error messages

[gdr at integrable-solutions dot net]

------- Additional Comments From gdr at integrable-solutions dot net  2005-03-26 04:13 -------
Subject: Re:  Do not print default template arguments in error messages

"dave at boost-consulting dot com" <gcc-bugzilla@gcc.gnu.org> writes:

[...]

| Please, I'm begging you not to go down this road.  GCC is one of the

I know you have strong opinions on what compilers should print; we had
part of this discussions on -core and it did not seem like that was a
universal solution that handles all the cases.  I'm going to scheme
that handle the majority of the cases right.

| only compilers that gets it right today (VC8 will follow), and all the
| ones that try to follow the "show how it was written" rule often give
| errors that are, for all practical purposes, unusable.  If you make
| GCC work like the others, it will be a leap backwards and a terrible
| disservice to users.

yes, you're entitled to your opinions.

-- Gaby


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14912

[Bug c++/14912] Do not print default template arguments in error messages

[gdr at integrable-solutions dot net]

------- Additional Comments From gdr at integrable-solutions dot net  2005-03-26 04:06 -------
Subject: Re:  Do not print default template arguments in error messages

"giovannibajo at libero dot it" <gcc-bugzilla@gcc.gnu.org> writes:

| ------- Additional Comments From giovannibajo at libero dot it  2005-03-26 00:35 -------
| (In reply to comment #12)
| 
| > Look at the most general template and same_type_p() with any default
| > type.  
| 
| How can it work? The default parameter can be dependent on previous template 
| parameters. For instace, in vector, the default type in the most general 
| template would be something like std::allocator<T> (with T being a previous 
| template parameter), while the type in the instantiation is something like 
| std::allocator<int>.
| 
| > Again that is better done with cxx-pretty-print.c
| 
| I don't know what cxx-pretty-print.c is, exactly.

cp/cxx-pretty-print.c

| Is it currently used? 

Yes.  Curently, the pretty-printing job is done by both error.c and
cxx-pretty-print.c.  But, the goal is to move the codes to the latter.


| Everytime I step with GDB into an error()/warning()/info() call I only see code 
| from errors.c being used. My current patch is modifying errors.c because that 
| is what the FE currently uses, as far as I can tell.

you're just mistaken.  I have been modifying the codes for long time
now, and I have an idea of the code path.

-- Gaby


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14912

[Bug c++/14912] Do not print default template arguments in error messages

[gdr at integrable-solutions dot net]

------- Additional Comments From gdr at integrable-solutions dot net  2005-03-26 04:04 -------
Subject: Re:  Do not print default template arguments in error messages

"giovannibajo at libero dot it" <gcc-bugzilla@gcc.gnu.org> writes:

| ------- Additional Comments From giovannibajo at libero dot it  2005-03-26 00:30 -------
| (In reply to comment #14)
| 
| > | The first patch will deal with just removal of default 
| > | arguments, and I believe that the less intrusive and clean solution is to 
| > | display <default> in the "with" clause.
| > please:
| >   (1) don't do an unconditional removal;
| >   (2) don't show <default>.
| > I would oppose any patch short of that.
| 
| Yes, the remove will be conditioned on a flag (but I believe this has to become 
| the default).

which flag?  A compiler option?  I don't think a multiplication of
compiler options for this stuff is a good way to go.

| About the <default>, I don't understand what you are proposing as an 
| alternative. Are you proposing to completely remove those template parameters 
| from the "with" clause? 

when they are default, yes.

-- Gaby


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14912

[Bug c++/14912] Do not print default template arguments in error messages

[dave at boost-consulting dot com]

------- Additional Comments From dave at boost-consulting dot com  2005-03-26 02:01 -------
Subject: Re:  Do not print default template arguments in error messages

"gdr at integrable-solutions dot net" <gcc-bugzilla@gcc.gnu.org> writes:

> ------- Additional Comments From gdr at integrable-solutions dot net  2005-03-25 22:06 -------
> Subject: Re:  Do not print default template arguments in error messages
>
> "giovannibajo at libero dot it" <gcc-bugzilla@gcc.gnu.org> writes:
>
> | ------- Additional Comments From giovannibajo at libero dot it  2005-03-23 02:44 -------
> | I'll try to do this. This is a simple testcase:
> | 
> | ---------------------------
> | template <class T, int N=0, int X=1>
> | struct A
> | {
> |    typedef typename T::x x;
> | };
> | void foo(void)
> | {
> |   A<void,0> a;
> | }
> | ---------------------------
> | test.cc: At global scope:
> | test.cc: In instantiation of 'A<void, 0, 1>':
> | test.cc:8:   instantiated from here
> | test.cc:4: error: 'void' is not a class, struct, or union type
> | 
> | Do we want the error message to show 'A<void, 0>' or 'A<void>'? In other words, 
>
> Most of the time, we want to print what user wrote.  

That rule could be really bad in cases like:

     A<void, foo<bar>::value>

The actual identity of the 2nd argument is usually far more important
at the point where the error is reported than seeing the way the user
wrote it, and the deduction needed for the user to determine that
foo<bar>::value is actually 0, 1, or whatever can be arbitrarily
complicated.  The user may have to look through an arbitrary number of
template definitions in arbitrary locations, finding all
specializations and essentially doing instantiation by hand.  By
contrast, finding out how a template argument was written is trivial
because GCC gives you a nice backtrace where you will see each
template in the instantiation chain being supplied with arguments.

Please, I'm begging you not to go down this road.  GCC is one of the
only compilers that gets it right today (VC8 will follow), and all the
ones that try to follow the "show how it was written" rule often give
errors that are, for all practical purposes, unusable.  If you make
GCC work like the others, it will be a leap backwards and a terrible
disservice to users.

If you choose to show an argument that happens to match the default
but was in fact supplied explicitly, I have no real objection.  Just
show it in its simplified normal form and do not try to show "what was
written."

If you never really meant to go in the direction I fear, I just ask
that you try find a way to describe what you want that can't be
misinterpreted the way I did.  Someone might go off and do the wrong
thing anyway unless it is expressed clearly.



-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14912

[Bug c++/14912] Do not print default template arguments in error messages

[giovannibajo at libero dot it]

------- Additional Comments From giovannibajo at libero dot it  2005-03-26 00:35 -------
(In reply to comment #12)

> Look at the most general template and same_type_p() with any default
> type.  

How can it work? The default parameter can be dependent on previous template 
parameters. For instace, in vector, the default type in the most general 
template would be something like std::allocator<T> (with T being a previous 
template parameter), while the type in the instantiation is something like 
std::allocator<int>.

> Again that is better done with cxx-pretty-print.c

I don't know what cxx-pretty-print.c is, exactly. Is it currently used? 
Everytime I step with GDB into an error()/warning()/info() call I only see code 
from errors.c being used. My current patch is modifying errors.c because that 
is what the FE currently uses, as far as I can tell.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14912

[Bug c++/14912] Do not print default template arguments in error messages

[giovannibajo at libero dot it]

------- Additional Comments From giovannibajo at libero dot it  2005-03-26 00:30 -------
(In reply to comment #14)

> | The first patch will deal with just removal of default 
> | arguments, and I believe that the less intrusive and clean solution is to 
> | display <default> in the "with" clause.
> please:
>   (1) don't do an unconditional removal;
>   (2) don't show <default>.
> I would oppose any patch short of that.

Yes, the remove will be conditioned on a flag (but I believe this has to become 
the default).

About the <default>, I don't understand what you are proposing as an 
alternative. Are you proposing to completely remove those template parameters 
from the "with" clause? To me it's almost indifferent. I believe the <default> 
is clearer, but I'm not strong on it either, and I am happy to change it if it 
has to be a showstopper for the patch.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14912

[Bug c++/14912] Do not print default template arguments in error messages

[gdr at integrable-solutions dot net]

------- Additional Comments From gdr at integrable-solutions dot net  2005-03-25 22:11 -------
Subject: Re:  Do not print default template arguments in error messages

"giovannibajo at libero dot it" <gcc-bugzilla@gcc.gnu.org> writes:

| I cannot fix all the diagnostic problems in GCC with a single patch,
| we need to do this incrementally.

100% agreed.

| The first patch will deal with just removal of default 
| arguments, and I believe that the less intrusive and clean solution is to 
| display <default> in the "with" clause.

please:

  (1) don't do an unconditional removal;
  (2) don't show <default>.

I would oppose any patch short of that.

-- Gaby


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14912

[Bug c++/14912] Do not print default template arguments in error messages

[gdr at integrable-solutions dot net]

------- Additional Comments From gdr at integrable-solutions dot net  2005-03-25 22:09 -------
Subject: Re:  Do not print default template arguments in error messages

"giovannibajo at libero dot it" <gcc-bugzilla@gcc.gnu.org> writes:

| ------- Additional Comments From giovannibajo at libero dot it  2005-03-23 11:01 -------
| or maybe:
| 
| test.cc: In member function `void A<T, N, X>::foo() [with T = int, int N = 
| <default>, int X = <default>]':

oh no.

-- Gaby


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14912

[Bug c++/14912] Do not print default template arguments in error messages

[gdr at integrable-solutions dot net]

------- Additional Comments From gdr at integrable-solutions dot net  2005-03-25 22:09 -------
Subject: Re:  Do not print default template arguments in error messages

"giovannibajo at libero dot it" <gcc-bugzilla@gcc.gnu.org> writes:

| The first non-trivial issue is that, in order to print "std::vector<int>" 
| instead of "std::vector<int, std::allocator<int> >", we need to do the template 
| substitution at error printing time, and check if the resulting substitution 
| match.

I don't think so.  Look at the way error.c print templates.

 Either that, or I need to mark template arguments with a flag if they 
| come from the template-id.
| 
| Also, should we skip default arguments also in lines like this:
| 
| test.cc: In member function `void A<T, N, X>::foo() [with T = int, int N = 0, 
| int X = 1]':
| 
| We would be left with something like :

Look at the most general template and same_type_p() with any default
type.  Again that is better done with cxx-pretty-print.c

-- Gaby


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14912

[Bug c++/14912] Do not print default template arguments in error messages

[gdr at integrable-solutions dot net]

------- Additional Comments From gdr at integrable-solutions dot net  2005-03-25 22:06 -------
Subject: Re:  Do not print default template arguments in error messages

"giovannibajo at libero dot it" <gcc-bugzilla@gcc.gnu.org> writes:

| ------- Additional Comments From giovannibajo at libero dot it  2005-03-23 02:44 -------
| I'll try to do this. This is a simple testcase:
| 
| ---------------------------
| template <class T, int N=0, int X=1>
| struct A
| {
|    typedef typename T::x x;
| };
| void foo(void)
| {
|   A<void,0> a;
| }
| ---------------------------
| test.cc: At global scope:
| test.cc: In instantiation of 'A<void, 0, 1>':
| test.cc:8:   instantiated from here
| test.cc:4: error: 'void' is not a class, struct, or union type
| 
| Do we want the error message to show 'A<void, 0>' or 'A<void>'? In other words, 

Most of the time, we want to print what user wrote.  In some cases, we
want to have the pretty-printer show all arguments.  I certainly don't
want unconditional omission of default argument.  You will probably
have to work on the '#' modifier -- ideally, a patch tp that effect
should confive cxx-pretty-printer.c and nor error.c.

| should GCC try and remember which arguments were really specified in the 
| template-id (hard to do), or a simple check of equalness between the argument 
| and the default parameter would suffice?


Not necessarily, we don't have unified types system in the C++
front-end.  But, you can use same_type_p().

-- Gaby


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14912

[Bug c++/14912] Do not print default template arguments in error messages

[giovannibajo at libero dot it]

------- Additional Comments From giovannibajo at libero dot it  2005-03-24 02:15 -------
(In reply to comment #9)

> Doesn't sound right to me. [...]
> GCC ought to have a heuristic based on the lengths of the version with
> the "with" clause and the version with a full argument substitution, to decide
> whether to use "with" or just substitute the arguments in-line.

I cannot fix all the diagnostic problems in GCC with a single patch, we need to 
do this incrementally. The first patch will deal with just removal of default 
arguments, and I believe that the less intrusive and clean solution is to 
display <default> in the "with" clause.

Your heuristic proposal makes a lot of sense, and we can revisit it when we are 
done with the issue described in this bug.

I'd like also to reverse the instantiation context but that's a different patch 
again.

-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14912

[Bug c++/14912] Do not print default template arguments in error messages

[dave at boost-consulting dot com]

------- Additional Comments From dave at boost-consulting dot com  2005-03-23 12:55 -------
Doesn't sound right to me.  

I think you should either show vector<T> or include A in the "with" clause of
vector<T,A>.  I'm sort of inclined to the former; Don't forget that parameter
names are not always so short.  Another related issue is that "with" clauses are
sometimes unhelpful, as in the case you cite.  vector<int> is much, much
clearer.  GCC ought to have a heuristic based on the lengths of the version with
the "with" clause and the version with a full argument substitution, to decide
whether to use "with" or just substitute the arguments in-line.

-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14912

[Bug c++/14912] Do not print default template arguments in error messages

[giovannibajo at libero dot it]

------- Additional Comments From giovannibajo at libero dot it  2005-03-23 11:01 -------
or maybe:

test.cc: In member function `void A<T, N, X>::foo() [with T = int, int N = 
<default>, int X = <default>]':


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14912

[Bug c++/14912] Do not print default template arguments in error messages

[giovannibajo at libero dot it]

------- Additional Comments From giovannibajo at libero dot it  2005-03-23 10:51 -------
The first non-trivial issue is that, in order to print "std::vector<int>" 
instead of "std::vector<int, std::allocator<int> >", we need to do the template 
substitution at error printing time, and check if the resulting substitution 
match. Either that, or I need to mark template arguments with a flag if they 
come from the template-id.

Also, should we skip default arguments also in lines like this:

test.cc: In member function `void A<T, N, X>::foo() [with T = int, int N = 0, 
int X = 1]':

We would be left with something like :

test.cc: In member function `void A<T, N, X>::foo() [with T = int]':

I assume that sounds about right, even if it might be surprising at first why 
the "with" clause does not show all the parameters.



-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14912

[Bug c++/14912] Do not print default template arguments in error messages

[dave at boost-consulting dot com]

------- Additional Comments From dave at boost-consulting dot com  2005-03-23 04:55 -------
"should GCC try and remember which arguments were really specified in the 
template-id (hard to do), or a simple check of equalness between the argument 
and the default parameter would suffice?"

GCC should not try to remember the arguments.  That path is a slippery slope,
and leads to things similar to "deep typedef substitution," which makes error
messages much harder to read than necessary.

-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14912

[Bug c++/14912] Do not print default template arguments in error messages

[giovannibajo at libero dot it]

------- Additional Comments From giovannibajo at libero dot it  2005-03-23 02:44 -------
I'll try to do this. This is a simple testcase:

---------------------------
template <class T, int N=0, int X=1>
struct A
{
   typedef typename T::x x;
};
void foo(void)
{
  A<void,0> a;
}
---------------------------
test.cc: At global scope:
test.cc: In instantiation of 'A<void, 0, 1>':
test.cc:8:   instantiated from here
test.cc:4: error: 'void' is not a class, struct, or union type

Do we want the error message to show 'A<void, 0>' or 'A<void>'? In other words, 
should GCC try and remember which arguments were really specified in the 
template-id (hard to do), or a simple check of equalness between the argument 
and the default parameter would suffice?


-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |dave at boost-consulting dot
                   |                            |com
         AssignedTo|unassigned at gcc dot gnu   |giovannibajo at libero dot
                   |dot org                     |it
             Status|NEW                         |ASSIGNED


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14912

[Bug c++/14912] Do not print default template arguments in error messages

[gdr at integrable-solutions dot net]

------- Additional Comments From gdr at integrable-solutions dot net  2004-04-10 21:49 -------
Subject: Re:  Do not print default template arguments in error messages

"pinskia at gcc dot gnu dot org" <gcc-bugzilla@gcc.gnu.org> writes:

| The no space after the const is a bug, please file a seperate PR for
| it as it is a regression from 3.4.0. 

Yes, it is a bug.  Fixed soon.

-- Gaby


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14912

[Bug c++/14912] Do not print default template arguments in error messages

[pinskia at gcc dot gnu dot org]

------- Additional Comments From pinskia at gcc dot gnu dot org  2004-04-10 19:55 -------
I mean the latter.

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
     Ever Confirmed|                            |1
   Last reconfirmed|0000-00-00 00:00:00         |2004-04-10 19:55:53
               date|                            |


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14912

[Bug c++/14912] Do not print default template arguments in error messages

[schnetter at aei dot mpg dot de]

------- Additional Comments From schnetter at aei dot mpg dot de  2004-04-10 19:51 -------
I do not understand your second statement.  Do you want to say that the C++ 
standard requires default template parameters in diagnostics, or that the STL 
classes have to take these default template parameters?  I would expect the 
latter, but the former would be inconvenient. 
 

-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14912

[Bug c++/14912] Do not print default template arguments in error messages

[pinskia at gcc dot gnu dot org]

------- Additional Comments From pinskia at gcc dot gnu dot org  2004-04-10 19:39 -------
The no space after the const is a bug, please file a seperate PR for it as it is a regression from 3.4.0.

Note that the allocator template argument is required by the C++ standard.

But other than that I can confirm this.

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |gdr at gcc dot gnu dot org
           Keywords|                            |diagnostic
            Version|tree-ssa                    |3.5.0


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14912