<?xml version="1.0" encoding="UTF-8"?>
<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns="http://purl.org/rss/1.0/" xmlns:taxo="http://purl.org/rss/1.0/modules/taxonomy/" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:syn="http://purl.org/rss/1.0/modules/syndication/" xmlns:admin="http://webns.net/mvcb/">
  <channel rdf:about="http://permalink.gmane.org/gmane.comp.gcc.patches">
    <title>gmane.comp.gcc.patches</title>
    <link>http://permalink.gmane.org/gmane.comp.gcc.patches</link>
    <description/>
    <syn:updatePeriod>hourly</syn:updatePeriod>
    <syn:updateFrequency>1</syn:updateFrequency>
    <syn:updateBase>1901-01-01T00:00+00:00</syn:updateBase>
    <items>
      <rdf:Seq>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.gcc.patches/286606"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.gcc.patches/286605"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.gcc.patches/286604"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.gcc.patches/286603"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.gcc.patches/286602"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.gcc.patches/286601"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.gcc.patches/286600"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.gcc.patches/286599"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.gcc.patches/286598"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.gcc.patches/286596"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.gcc.patches/286594"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.gcc.patches/286593"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.gcc.patches/286591"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.gcc.patches/286590"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.gcc.patches/286588"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.gcc.patches/286587"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.gcc.patches/286586"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.gcc.patches/286585"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.gcc.patches/286584"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.gcc.patches/286583"/>
      </rdf:Seq>
    </items>
    <image rdf:resource="http://gmane.org/img/gmane-25t.png"/>
    <textinput rdf:resource=""/>
  </channel>
  <image rdf:about="http://gmane.org/img/gmane-25t.png">
    <title>Gmane</title>
    <url>http://gmane.org/img/gmane-25t.png</url>
    <link>http://gmane.org</link>
  </image>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.gcc.patches/286606">
    <title>[committed] PR 55777: inlining nomips16 into mips16</title>
    <link>http://permalink.gmane.org/gmane.comp.gcc.patches/286606</link>
    <description>&lt;pre&gt;This patch prevents inlining between functions of different ISA modes.

Tested on mips64-linux-gnu and applied.

Richard


gcc/
PR target/55777
* config/mips/mips.c (mips_can_inline_p): New function.
(TARGET_CAN_INLINE_P): Define.

gcc/testsuite/
PR target/55777
* gcc.target/mips/mips16-attributes-5.c,
* gcc.target/mips/mips16-attributes-6.c: New tests.

Index: gcc/config/mips/mips.c
===================================================================
--- gcc/config/mips/mips.c2013-05-21 19:20:41.821261620 +0100
+++ gcc/config/mips/mips.c2013-05-25 09:35:42.073502492 +0100
&amp;lt; at &amp;gt;&amp;lt; at &amp;gt; -1426,6 +1426,16 &amp;lt; at &amp;gt;&amp;lt; at &amp;gt; mips_merge_decl_attributes (tree olddecl
   return merge_attributes (DECL_ATTRIBUTES (olddecl),
    DECL_ATTRIBUTES (newdecl));
 }
+
+/* Implement TARGET_CAN_INLINE_P.  */
+
+static bool
+mips_can_inline_p (tree caller, tree callee)
+{
+  if (mips_get_compress_mode (callee) != mips_get_compress_mode (caller))
+    return false;
+  return default_target_can_inline_p (caller, callee);
+}
 
 /* If X is a PLUS&lt;/pre&gt;</description>
    <dc:creator>Richard Sandiford</dc:creator>
    <dc:date>2013-05-25T15:52:42</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.gcc.patches/286605">
    <title>Re: Partial fix for PR opt/55177</title>
    <link>http://permalink.gmane.org/gmane.comp.gcc.patches/286605</link>
    <description>&lt;pre&gt;
Copied from optimize-bswapdi-1.c, but I should probably have copied it from 
optimize-bswapsi-1.c for the bswapsi case.  Will adjust.


OK, I'll take a look.

&lt;/pre&gt;</description>
    <dc:creator>Eric Botcazou</dc:creator>
    <dc:date>2013-05-25T13:42:50</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.gcc.patches/286604">
    <title>[PATCH 2/2] autogenerated part of patch</title>
    <link>http://permalink.gmane.org/gmane.comp.gcc.patches/286604</link>
    <description>&lt;pre&gt;This patch is 547K in size, so I've uploaded it to:

http://dmalcolm.fedorapeople.org/gcc/large-patches/928e2d33daafe1943766dfb437f6ba7b795dfa41-0002-autogenerated-part-of-cfun-expansion.patch

Patch autogenerated by refactor_cfun.py from
https://github.com/davidmalcolm/gcc-refactoring-scripts
revision 3badf4e33b0f66e4c9276efedd4e7f4cb6117f12
(the revision quoted in the ChangeLog is off-by-one)

There's a slight bug in the ChangeLog generation affecting the filenames
in testsuite/ChangeLog

The script doesn't yet check/update copyright years in files that it
touches.

&lt;/pre&gt;</description>
    <dc:creator>David Malcolm</dc:creator>
    <dc:date>2013-05-25T13:02:21</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.gcc.patches/286603">
    <title>[PATCH 0/2] Proof-of-concept towards removal of the "cfun" global</title>
    <link>http://permalink.gmane.org/gmane.comp.gcc.patches/286603</link>
    <description>&lt;pre&gt;Here's an idea that could make it easier to remove the "cfun" global.

"cfun" is a major piece of global state within gcc: it's the 5th most
accessed variable in the build (accessed in ~4600 places within one stage
of a build, based on [1]).   This is an obstacle to making gcc's code be
usable as a library.

I can think of three approaches to "cfun":
(a) status quo: a global variable, with macros to prevent direct
    assignment, and an API for changing cfun.
(b) have a global "context" or "universe" object, and put cfun in
    there (perhaps with tricks to be able to make this a singleton in a
    non-library build, optimizing away the context lookups somehow
    - see [2] for discussion on this)
(c) go through all of the places where cfun is used, and somehow ensure
    that they're passed in the data they need.  Often it's not the
    function that's used, but its cfg.

I think (c) is the ideal from a modularity perspective (it unlocks the
ability to have optimization passes be working on different functi&lt;/pre&gt;</description>
    <dc:creator>David Malcolm</dc:creator>
    <dc:date>2013-05-25T13:02:19</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.gcc.patches/286602">
    <title>[PATCH 1/2] handwritten part of patch</title>
    <link>http://permalink.gmane.org/gmane.comp.gcc.patches/286602</link>
    <description>&lt;pre&gt;Eliminate all direct references to "cfun" from macros in
basic-block.h and introduce access methods to control_flow_graph

* basic-block.h (control_flow_graph::get_basic_block_by_idx): New
accessor methods.
(control_flow_graph::get_entry_block): New method.
(control_flow_graph::get_exit_block): New method.
(control_flow_graph::get_basic_block_info): New methods.
(control_flow_graph::get_n_basic_blocks): New methods.
(control_flow_graph::get_n_edges): New methods.
(control_flow_graph::get_last_basic_block): New methods.
(control_flow_graph::get_label_to_block_map): New methods.
(control_flow_graph::get_profile_status): New method.
(control_flow_graph::set_profile_status): New method.
(ENTRY_BLOCK_PTR): Eliminate this macro.
(EXIT_BLOCK_PTR): Likewise.
(basic_block_info): Likewise.
(n_basic_blocks): Likewise.
(n_edges): Likewise.
(last_basic_block): Likewise.
(label_to_block_map): Likewise.
(profile_status): Likewise.
(BASIC_BLOCK): Likewise.
(SET_BASIC_BLOCK): Likewise.
(FOR_EACH_BB_FN&lt;/pre&gt;</description>
    <dc:creator>David Malcolm</dc:creator>
    <dc:date>2013-05-25T13:02:20</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.gcc.patches/286601">
    <title>Re: Partial fix for PR opt/55177</title>
    <link>http://permalink.gmane.org/gmane.comp.gcc.patches/286601</link>
    <description>&lt;pre&gt;

What is the significance of the target selection?

builtin-bswap-9.c fails on ia64, it still generates bswap:DI for foo2,
foo3 and foo4.

Andreas.

&lt;/pre&gt;</description>
    <dc:creator>Andreas Schwab</dc:creator>
    <dc:date>2013-05-25T12:36:00</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.gcc.patches/286600">
    <title>[C++ testcase, committed] PR 52216</title>
    <link>http://permalink.gmane.org/gmane.comp.gcc.patches/286600</link>
    <description>&lt;pre&gt;Hi,

I'm adding the testcase and closing the bug as fixed for 4.9.0.

Thanks,
Paolo.

////////////////////
2013-05-25  Paolo Carlini  &amp;lt;paolo.carlini&amp;lt; at &amp;gt;oracle.com&amp;gt;

PR c++/52216
* g++.dg/cpp0x/new1.C: New.
Index: g++.dg/cpp0x/new1.C
===================================================================
--- g++.dg/cpp0x/new1.C(revision 0)
+++ g++.dg/cpp0x/new1.C(working copy)
&amp;lt; at &amp;gt;&amp;lt; at &amp;gt; -0,0 +1,8 &amp;lt; at &amp;gt;&amp;lt; at &amp;gt;
+// PR c++/52216
+// { dg-require-effective-target c++11 }
+
+#include &amp;lt;new&amp;gt;
+
+int n;
+
+static_assert(!noexcept(::new (std::nothrow) int[n]), "");
&lt;/pre&gt;</description>
    <dc:creator>Paolo Carlini</dc:creator>
    <dc:date>2013-05-25T12:03:13</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.gcc.patches/286599">
    <title>Re: PR tree-optimization/57337</title>
    <link>http://permalink.gmane.org/gmane.comp.gcc.patches/286599</link>
    <description>&lt;pre&gt;

But there should be a safe default answer for
Equal uids. Unless we are asking different questions in different places. Thus, I do not like the stmt walking but rather have a safe fallback.

Richard.




&lt;/pre&gt;</description>
    <dc:creator>Richard Biener</dc:creator>
    <dc:date>2013-05-25T11:46:47</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.gcc.patches/286598">
    <title>Re: [PATCH] Fix incorrect discriminator assignment.</title>
    <link>http://permalink.gmane.org/gmane.comp.gcc.patches/286598</link>
    <description>&lt;pre&gt;
This cause pr57413.

Dominique

PS the escaping in the regexp seems strange: \[0-9]

&lt;/pre&gt;</description>
    <dc:creator>Dominique Dhumieres</dc:creator>
    <dc:date>2013-05-25T09:50:52</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.gcc.patches/286596">
    <title>Re: Use unsigned(-1) for lshift</title>
    <link>http://permalink.gmane.org/gmane.comp.gcc.patches/286596</link>
    <description>&lt;pre&gt;

Not in C++ after DR1457, where it becomes implementation defined (depends 
on conversions from unsigned to signed, likely ok on all 2s complement 
platforms). But we should indeed use HOST_WIDE_INT_MIN instead (the 
definition of that one might also need fixing if we don't want to rely on 
implementation defined behavior, but it reduces the number of places to 
fix). Consider this part of the patch changed to:

 * tree-ssa-structalias.c (UNKNOWN_OFFSET): Use HOST_WIDE_INT_MIN.

  /* Use 0x8000... as special unknown offset.  */
-#define UNKNOWN_OFFSET ((HOST_WIDE_INT)-1 &amp;lt;&amp;lt; (HOST_BITS_PER_WIDE_INT-1))
+#define UNKNOWN_OFFSET HOST_WIDE_INT_MIN



(A way that still relies on 2s complement but not on conversions from 
unsigned to negative signed would be to define HOST_WIDE_INT_MAX as 
HOST_WIDE_INT_M1U/2 cast to signed and HOST_WIDE_INT_MIN as 
-HOST_WIDE_INT_MAX-1. Otherwise we'd have to include &amp;lt;limits.h&amp;gt;, or 
&amp;lt;limits&amp;gt; now we are doing C++, and rely on them giving safe values.)

&lt;/pre&gt;</description>
    <dc:creator>Marc Glisse</dc:creator>
    <dc:date>2013-05-25T06:36:11</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.gcc.patches/286594">
    <title>Re: [PATCH, rs6000] power8 patches, patch #2, add crypto builtins</title>
    <link>http://permalink.gmane.org/gmane.comp.gcc.patches/286594</link>
    <description>&lt;pre&gt;[gcc/testsuite]
2013-05-20  Michael Meissner  &amp;lt;meissner&amp;lt; at &amp;gt;linux.vnet.ibm.com&amp;gt;

        * gcc.target/powerpc/crypto-builtin-1.c: New file, test for power8
        crypto builtins.

The testcase needs to check something more than

/* { dg-require-effective-target powerpc_vsx_ok } */

I don't know if we need to separate the new VSX operations from the
crypto opterations, but the new testcases need to ensure that the
assembler and/or processor support the new instructions.

Thanks, David

&lt;/pre&gt;</description>
    <dc:creator>David Edelsohn</dc:creator>
    <dc:date>2013-05-25T04:07:32</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.gcc.patches/286593">
    <title>Re: [PATCH, rs6000] power8 patches, patch #4, new power8 builtins</title>
    <link>http://permalink.gmane.org/gmane.comp.gcc.patches/286593</link>
    <description>&lt;pre&gt;On Tue, May 21, 2013 at 7:47 PM, Michael Meissner
&amp;lt;meissner&amp;lt; at &amp;gt;linux.vnet.ibm.com&amp;gt; wrote:



Completely turning off splitting wide types seems like an
unnecessarily large hammer to prevent splitting a value across
registers within logical atomic operations.  I think we need to
examine other alternatives.

- David

&lt;/pre&gt;</description>
    <dc:creator>David Edelsohn</dc:creator>
    <dc:date>2013-05-25T04:03:51</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.gcc.patches/286591">
    <title>Re: [patch][google/gcc-4.8] Port gcov intermediate format from google/gcc-4.7</title>
    <link>http://permalink.gmane.org/gmane.comp.gcc.patches/286591</link>
    <description>&lt;pre&gt;
Is there an indentation issue here?





Try to avoid the following format only changes by reorganization --
for instance refactor the following part into a helper function.

Ok for google branch with those change.  Please submit the change to trunk asap.

thanks,

David


&lt;/pre&gt;</description>
    <dc:creator>Xinliang David Li</dc:creator>
    <dc:date>2013-05-25T02:42:59</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.gcc.patches/286590">
    <title>Re: [google gcc-4_8] not mapping debug expr to a deleted varpool node (issue9760043)</title>
    <link>http://permalink.gmane.org/gmane.comp.gcc.patches/286590</link>
    <description>&lt;pre&gt;

IIUC, it is the real target var-decl of VAR that gets removed from
lipo's symtab thus calling real_var_pool_node later will trigger
gcc_assert. This fix just moved the assertion earlier?

It should be ok for now to just drop the debug expr if the var is
static/global.

David


&lt;/pre&gt;</description>
    <dc:creator>Xinliang David Li</dc:creator>
    <dc:date>2013-05-25T02:18:28</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.gcc.patches/286588">
    <title>Re: [C++ Patch] PR 25666</title>
    <link>http://permalink.gmane.org/gmane.comp.gcc.patches/286588</link>
    <description>&lt;pre&gt;OK.

Jason

&lt;/pre&gt;</description>
    <dc:creator>Jason Merrill</dc:creator>
    <dc:date>2013-05-25T00:46:35</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.gcc.patches/286587">
    <title>[google gcc-4_8] not mapping debug expr to a deleted varpool node (issue9760043)</title>
    <link>http://permalink.gmane.org/gmane.comp.gcc.patches/286587</link>
    <description>&lt;pre&gt;This patch fixes a bug in exposed in LIPO build (ICE in copy tree node).

Tested with bookstrap and google internal benchmarks.

-Rong

2013-05-24  Rong Xu  &amp;lt;xur&amp;lt; at &amp;gt;google.com&amp;gt;
        Google ref b/8963414.
* gcc/tree-inline.c (add_local_variables): Not map
        to deleted debug expression.

Index: gcc/tree-inline.c
===================================================================
--- gcc/tree-inline.c(revision 199128)
+++ gcc/tree-inline.c(working copy)
&amp;lt; at &amp;gt;&amp;lt; at &amp;gt; -3788,6 +3788,17 &amp;lt; at &amp;gt;&amp;lt; at &amp;gt; add_local_variables (struct function *callee, stru
   {
     tree tem = DECL_DEBUG_EXPR (var);
     bool old_regimplify = id-&amp;gt;regimplify;
+
+            /* The mapped debug expression might be deleted
+               as a varpool node (the reachbility analysis
+               of varpool node does not check the reference
+               from debug expressions.
+               Set it to 0 if that's the case.  */
+            if (L_IPO_COMP_MODE &amp;amp;&amp;amp; tem &amp;amp;&amp;amp;
+                (TREE_STATIC (tem) || DECL_EXTERNAL(tem)) &amp;amp;&amp;amp;
+             &lt;/pre&gt;</description>
    <dc:creator>Rong Xu</dc:creator>
    <dc:date>2013-05-24T23:26:59</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.gcc.patches/286586">
    <title>Re: Use unsigned(-1) for lshift</title>
    <link>http://permalink.gmane.org/gmane.comp.gcc.patches/286586</link>
    <description>&lt;pre&gt;
This is still undefined behaviour (shifting a 1 into the sign bit)?


Segher


&lt;/pre&gt;</description>
    <dc:creator>Segher Boessenkool</dc:creator>
    <dc:date>2013-05-24T22:15:59</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.gcc.patches/286585">
    <title>[patch][google/gcc-4.8] Port gcov intermediate format from google/gcc-4.7</title>
    <link>http://permalink.gmane.org/gmane.comp.gcc.patches/286585</link>
    <description>&lt;pre&gt;Hi,

This patch forward ports r175134 from google/gcc-4.7 into
google/gcc-4.8. The intermediate format is a bit simplified. I am also
planning to propose this for trunk in a separate message.

Bootstrapped and tested on x86_64. Okay for google/gcc-4_8?

Thanks,
Sharad

2013-05-24   Sharad Singhai  &amp;lt;singhai&amp;lt; at &amp;gt;google.com&amp;gt;

* gcov.c (print_usage): Handle new options.
(process_args): Handle new options.
(get_gcov_file_intermediate_name): New function.
(output_intermediate_file): New function.
(generate_results): Handle new option.
(release_function): Relase demangled name.
(read_graph_file): Handle demangled name.
(output_lines): Ditto.
* doc/gcov.texi: Document gcov intermediate format.

testsuite/ChangeLog:

2013-05-24   Sharad Singhai  &amp;lt;singhai&amp;lt; at &amp;gt;google.com&amp;gt;

* g++.dg/gcov/gcov-8.C: New testcase.
* lib/gcov.exp: Handle intermediate format.


Index: testsuite/g++.dg/gcov/gcov-8.C
===================================================================
--- testsuite/g++.dg/gcov/gcov-8.C (revision 0)
+++ testsuite/g++.dg&lt;/pre&gt;</description>
    <dc:creator>Sharad Singhai</dc:creator>
    <dc:date>2013-05-24T21:32:36</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.gcc.patches/286584">
    <title>Re: [patch] Default to --enable-libstdcxx-time=auto</title>
    <link>http://permalink.gmane.org/gmane.comp.gcc.patches/286584</link>
    <description>&lt;pre&gt;

Strictly speaking, yes.  In Solaris 11, the librt functions were moved
to libc, but librt is left behind as a filter on libc.  It were best to
wrap -lrt in -z ignore/-z record (the Solaris equivalents of
--as-needed/--no-as-needed) when linking C++ programs, which is one
reason I think this is best handled with a new libstdc++.spec since most
of the configury is already present in libstdc++, along the lines of
libgfortran.spec.

acinclude.m4 would have to be amended to use AC_SEARCH_LIBS rather than
hardcoding the addition of -lrt to GLIBCXX_LIBS.

For the moment, this patch

http://gcc.gnu.org/ml/gcc-patches/2013-05/msg01488.html

does the job which is far less intrusive than adding libstdc++.spec, but
is certainly suboptimal.

Rainer

&lt;/pre&gt;</description>
    <dc:creator>Rainer Orth</dc:creator>
    <dc:date>2013-05-24T21:21:50</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.gcc.patches/286583">
    <title>Re: [PATCH, updated] Vtable pointer verification, main gcc changes (patch 2 of 3)</title>
    <link>http://permalink.gmane.org/gmane.comp.gcc.patches/286583</link>
    <description>&lt;pre&gt;
I will put them there.


No, I don't at this time.


Ok, will do.


Will do.


Yes (I didn't realize I had left the commented out code in the patch;
I'm sorry about that).


I will remove it.  I didn't mean for it to be in the patch.


Another piece I meant to remove previously (sorry again).


I really do want to use two separate iterators here.  gsi_virtual_call
iterates linearly through all the statements in the basic block.
gsi_vtbl_assign gets moved around a bit, later down in the code, to
find the exact position for inserting the verification call.


Ok.


Ok.


Ok.

&lt;/pre&gt;</description>
    <dc:creator>Caroline Tice</dc:creator>
    <dc:date>2013-05-24T20:51:38</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.gcc.patches/286582">
    <title>[C++ Patch] PR 25666</title>
    <link>http://permalink.gmane.org/gmane.comp.gcc.patches/286582</link>
    <description>&lt;pre&gt;Hi,

this remained assigned to me way too much time. The story goes that we 
used to ICE on parse/dtor6.C, then Mark fixed the ICE, and Volker opened 
25666 as a purely diagnostic issue, that is about the lack of a terse 
error message mentioning that templated destructors are illegal. Turns 
out we do already have such kind of diagnostics, but only in 
push_template_decl_real: in this case do_friend calls instead 
check_classfn which doesn't, thus ends up producing the more verbose 
generic diagnostics.

Tested x86_64-linux.

Thanks,
Paolo.

/////////////////////////////
/cp
2013-05-24  Paolo Carlini  &amp;lt;paolo.carlini&amp;lt; at &amp;gt;oracle.com&amp;gt;

PR c++/25666
* decl2.c (check_classfn): Check for destructors declared as member
templates.

/testsuite
2013-05-24  Paolo Carlini  &amp;lt;paolo.carlini&amp;lt; at &amp;gt;oracle.com&amp;gt;

PR c++/25666
* g++.dg/parse/dtor16.C: New.
* g++.dg/parse/dtor6.C: Adjust.
Index: cp/decl2.c
===================================================================
--- cp/decl2.c(revision 199313)
+++ cp/decl2.c(working co&lt;/pre&gt;</description>
    <dc:creator>Paolo Carlini</dc:creator>
    <dc:date>2013-05-24T20:43:46</dc:date>
  </item>
  <textinput rdf:about="http://search.gmane.org/?group=$group=gmane.comp.gcc.patches">
    <title>Search Engine</title>
    <description>Search the mailing list at Gmane</description>
    <name>query</name>
    <link>http://search.gmane.org/?group=$group=gmane.comp.gcc.patches</link>
  </textinput>
</rdf:RDF>
