[Bug ipa/60761] New: Names of all function clones in g++ are "<built-in>", in both warnings and dumps

[Bug ipa/60761] New: Names of all function clones in g++ are "<built-in>", in both warnings and dumps

[jamborm at gcc dot gnu.org]

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

            Bug ID: 60761
           Summary: Names of all function clones in g++ are "<built-in>",
                    in both warnings and dumps
           Product: gcc
           Version: 4.9.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: ipa
          Assignee: unassigned at gcc dot gnu.org
          Reporter: jamborm at gcc dot gnu.org
                CC: jakub at gcc dot gnu.org

Since revision r207465, all names of function clones in g++ (as
opposed to the C front-end) are "<built-in>", in dumps and even in
warnings, for example:

mjambor@virgil:~/gcc/bisect/test/clonenames$ ~/gcc/bisect/inst/bin/g++ -O3 -S
-Wall zz.C -fno-inline
zz.C: In function ‘<built-in>’:
zz.C:14:13: warning: iteration 3u invokes undefined behavior
[-Waggressive-loop-optimizations] 
     z[i] = i;
             ^
zz.C:13:3: note: containing loop
   for (int i = 0; i < s; i++)
   ^
zz.C:14:8: warning: array subscript is above array bounds [-Warray-bounds]
     z[i] = i;
        ^
mjambor@virgil:~/gcc/bisect/test/clonenames$ cat zz.C
extern int sum;

void do_sum (char *p)
{
  for (int i = 0; i < 2; i++)
    sum += p[i];
}

void
foo (int s)
{
  char z[3];
  for (int i = 0; i < s; i++)
    z[i] = i;
  do_sum (z);
}

int
bar (int i)
{
  foo (4);
  return 0;
}
>From gcc-bugs-return-448307-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Fri Apr 04 15:25:56 2014
Return-Path: <gcc-bugs-return-448307-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 18696 invoked by alias); 4 Apr 2014 15:25:55 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Delivered-To: mailing list gcc-bugs@gcc.gnu.org
Received: (qmail 18660 invoked by uid 48); 4 Apr 2014 15:25:52 -0000
From: "jamborm at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug ipa/60761] Names of all function clones in g++ are "<built-in>", in both warnings and dumps
Date: Fri, 04 Apr 2014 15:25:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: ipa
X-Bugzilla-Version: 4.9.0
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: jamborm at gcc dot gnu.org
X-Bugzilla-Status: UNCONFIRMED
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields:
Message-ID: <bug-60761-4-F1P2t7jmP2@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-60761-4@http.gcc.gnu.org/bugzilla/>
References: <bug-60761-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2014-04/txt/msg00327.txt.bz2
Content-length: 333

http://gcc.gnu.org/bugzilla/show_bug.cgi?id`761

--- Comment #1 from Martin Jambor <jamborm at gcc dot gnu.org> ---
This is because in dump_decl in gcc/cp/error.c there is:

    case FUNCTION_DECL:
      if (! DECL_LANG_SPECIFIC (t))
    pp_string (pp, M_("<built-in>"));

and the revision causing this clears DECL_LANG_SPECIFIC.

[Bug ipa/60761] Names of all function clones in g++ are "<built-in>", in both warnings and dumps

[manu at gcc dot gnu.org]

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

Manuel López-Ibáñez <manu at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |manu at gcc dot gnu.org

--- Comment #2 from Manuel López-Ibáñez <manu at gcc dot gnu.org> ---
(In reply to Martin Jambor from comment #0)
> mjambor@virgil:~/gcc/bisect/test/clonenames$ ~/gcc/bisect/inst/bin/g++ -O3
> -S -Wall zz.C -fno-inline
> zz.C: In function ‘<built-in>’:
> zz.C:14:13: warning: iteration 3u invokes undefined behavior
> [-Waggressive-loop-optimizations] 
>      z[i] = i;
>              ^

What is 3u?

> zz.C:13:3: note: containing loop

Wouldn't be more clear to say "within this loop"?


Isn't this a regression?
>From gcc-bugs-return-448376-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Sat Apr 05 16:25:17 2014
Return-Path: <gcc-bugs-return-448376-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 16285 invoked by alias); 5 Apr 2014 16:25:17 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Delivered-To: mailing list gcc-bugs@gcc.gnu.org
Received: (qmail 16241 invoked by uid 48); 5 Apr 2014 16:25:12 -0000
From: "manu at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug ipa/60761] Names of all function clones in g++ are "<built-in>", in both warnings and dumps
Date: Sat, 05 Apr 2014 16:25:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: ipa
X-Bugzilla-Version: 4.9.0
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: manu at gcc dot gnu.org
X-Bugzilla-Status: UNCONFIRMED
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields:
Message-ID: <bug-60761-4-wyH8HGFRWk@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-60761-4@http.gcc.gnu.org/bugzilla/>
References: <bug-60761-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2014-04/txt/msg00396.txt.bz2
Content-length: 6524

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

--- Comment #3 from Manuel López-Ibáñez <manu at gcc dot gnu.org> ---
(In reply to Manuel López-Ibáñez from comment #2)
> (In reply to Martin Jambor from comment #0)
> > mjambor@virgil:~/gcc/bisect/test/clonenames$ ~/gcc/bisect/inst/bin/g++ -O3
> > -S -Wall zz.C -fno-inline
> > zz.C: In function ‘<built-in>’:
> > zz.C:14:13: warning: iteration 3u invokes undefined behavior
> > [-Waggressive-loop-optimizations] 
> >      z[i] = i;
> >              ^
> 
> What is 3u?
> 
> > zz.C:13:3: note: containing loop
> 
> Wouldn't be more clear to say "within this loop"?
> 

I really cannot believe that after all this time, there is no printf-like code
to print a double_int. Why not %I? Interestingly, there is pp_double_int, so it
is obvious to me that this %E trick is just an ugly hack.

Index: tree-ssa-loop-niter.c
===================================================================
--- tree-ssa-loop-niter.c       (revision 208648)
+++ tree-ssa-loop-niter.c       (working copy)
@@ -2626,15 +2626,17 @@ do_warn_aggressive_loop_optimizations (s
   edge e = single_exit (loop);
   if (e == NULL)
     return;

   gimple estmt = last_stmt (e->src);
+#pragma GCC diagnostic ignored "-Wformat"
+#pragma GCC diagnostic ignored "-Wformat-extra-args"
   if (warning_at (gimple_location (stmt), OPT_Waggressive_loop_optimizations,
-                 "iteration %E invokes undefined behavior",
-                 double_int_to_tree (TREE_TYPE (loop->nb_iterations),
-                                     i_bound)))
-    inform (gimple_location (estmt), "containing loop");
+                 "iteration %I invokes undefined behavior",
+                 i_bound, TYPE_UNSIGNED (TREE_TYPE (loop->nb_iterations))))
+    inform (gimple_location (estmt), "within this loop");
+
   loop->warned_aggressive_loop_optimizations = true;
 }

 /* Records that AT_STMT is executed at most BOUND + 1 times in LOOP.  IS_EXIT
    is true if the loop is exited immediately after STMT, and this exit
Index: tree-pretty-print.c
===================================================================
--- tree-pretty-print.c (revision 208648)
+++ tree-pretty-print.c (working copy)
@@ -3435,32 +3435,8 @@ dump_function_header (FILE *dump_file, t
     }
   else
     fprintf (dump_file, ")\n\n");
 }

-/* Dump double_int D to pretty_printer PP.  UNS is true
-   if D is unsigned and false otherwise.  */
-void
-pp_double_int (pretty_printer *pp, double_int d, bool uns)
-{
-  if (d.fits_shwi ())
-    pp_wide_integer (pp, d.low);
-  else if (d.fits_uhwi ())
-    pp_unsigned_wide_integer (pp, d.low);
-  else
-    {
-      unsigned HOST_WIDE_INT low = d.low;
-      HOST_WIDE_INT high = d.high;
-      if (!uns && d.is_negative ())
-       {
-         pp_minus (pp);
-         high = ~high + !low;
-         low = -low;
-       }
-      /* Would "%x%0*x" or "%x%*0x" get zero-padding on all
-        systems?  */
-      sprintf (pp_buffer (pp)->digit_buffer,
-              HOST_WIDE_INT_PRINT_DOUBLE_HEX,
-              (unsigned HOST_WIDE_INT) high, low);
-      pp_string (pp, pp_buffer (pp)->digit_buffer);
-    }
-}
+
+
+
Index: pretty-print.c
===================================================================
--- pretty-print.c      (revision 208648)
+++ pretty-print.c      (working copy)
@@ -22,11 +22,12 @@ along with GCC; see the file COPYING3.
 #include "system.h"
 #include "coretypes.h"
 #include "intl.h"
 #include "pretty-print.h"
 #include "diagnostic-color.h"
-
+#include "double-int.h"
+extern void pp_double_int (pretty_printer *pp, double_int d, bool uns);
 #include <new>                    // For placement-new.

 #if HAVE_ICONV
 #include <iconv.h>
 #endif
@@ -261,10 +262,11 @@ pp_indent (pretty_printer *pp)
    %': apostrophe (should only be used in untranslated messages;
        translations should use appropriate punctuation directly).
    %.*s: a substring the length of which is specified by an argument
         integer.
    %Ns: likewise, but length specified as constant in the format string.
+   %I: double_int
    Flag 'q': quote formatted text (must come immediately after '%').

    Arguments can be used sequentially, or through %N$ resp. *N$
    notation Nth argument after the format string.  If %N$ / *N$
    notation is used, it must be used for all arguments, except %m, %%,
@@ -605,10 +607,19 @@ pp_format (pretty_printer *pp, text_info
            s = va_arg (*text->args_ptr, const char *);
            pp_append_text (pp, s, s + n);
          }
          break;

+
+       case 'I':
+         {
+           double_int i = va_arg (*text->args_ptr, double_int);
+           bool uns = va_arg (*text->args_ptr, int);
+           pp_double_int (pp, i, uns);
+         }
+         break;
+
        default:
          {
            bool ok;

            gcc_assert (pp_format_decoder (pp));
@@ -896,10 +907,38 @@ pp_character (pretty_printer *pp, int c)
     }
   obstack_1grow (pp_buffer (pp)->obstack, c);
   ++pp_buffer (pp)->line_length;
 }

+/* Dump double_int D to pretty_printer PP.  UNS is true
+   if D is unsigned and false otherwise.  */
+void
+pp_double_int (pretty_printer *pp, double_int d, bool uns)
+{
+  if (d.fits_shwi ())
+    pp_wide_integer (pp, d.low);
+  else if (d.fits_uhwi ())
+    pp_unsigned_wide_integer (pp, d.low);
+  else
+    {
+      unsigned HOST_WIDE_INT low = d.low;
+      HOST_WIDE_INT high = d.high;
+      if (!uns && d.is_negative ())
+       {
+         pp_minus (pp);
+         high = ~high + !low;
+         low = -low;
+       }
+      /* Would "%x%0*x" or "%x%*0x" get zero-padding on all
+        systems?  */
+      sprintf (pp_buffer (pp)->digit_buffer,
+              HOST_WIDE_INT_PRINT_DOUBLE_HEX,
+              (unsigned HOST_WIDE_INT) high, low);
+      pp_string (pp, pp_buffer (pp)->digit_buffer);
+    }
+}
+
 /* Append a STRING to the output area of PRETTY-PRINTER; the STRING may
    be line-wrapped if in appropriate mode.  */
 void
 pp_string (pretty_printer *pp, const char *str)
 {
>From gcc-bugs-return-448377-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Sat Apr 05 22:05:19 2014
Return-Path: <gcc-bugs-return-448377-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 3527 invoked by alias); 5 Apr 2014 22:05:18 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Delivered-To: mailing list gcc-bugs@gcc.gnu.org
Received: (qmail 3475 invoked by uid 48); 5 Apr 2014 22:05:13 -0000
From: "hubicka at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug ipa/60665] gcc/ipa-devirt.c:1510:7: warning: variable 'can_refer' is used uninitialized whenever '?:' condition is false
Date: Sat, 05 Apr 2014 22:05:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: ipa
X-Bugzilla-Version: 4.9.0
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: hubicka at gcc dot gnu.org
X-Bugzilla-Status: NEW
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields: bug_status cf_reconfirmed_on cc everconfirmed
Message-ID: <bug-60665-4-amDSSZrr7C@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-60665-4@http.gcc.gnu.org/bugzilla/>
References: <bug-60665-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2014-04/txt/msg00397.txt.bz2
Content-length: 669

http://gcc.gnu.org/bugzilla/show_bug.cgi?id`665

Jan Hubicka <hubicka at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2014-04-05
                 CC|                            |hubicka at gcc dot gnu.org
     Ever confirmed|0                           |1

--- Comment #1 from Jan Hubicka <hubicka at gcc dot gnu.org> ---
Not really a bug, since can_refer is unused in that case, but I will add
initialization to that code path, it would make sense.

[Bug ipa/60761] [4.9 Regression] Names of all function clones in g++ are "<built-in>", in both warnings and dumps

[rguenth at gcc dot gnu.org]

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

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |diagnostic
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2014-04-07
   Target Milestone|---                         |4.9.0
            Summary|Names of all function       |[4.9 Regression] Names of
                   |clones in g++ are           |all function clones in g++
                   |"<built-in>", in both       |are "<built-in>", in both
                   |warnings and dumps          |warnings and dumps
     Ever confirmed|0                           |1

--- Comment #4 from Richard Biener <rguenth at gcc dot gnu.org> ---
Confirmed.  IMHO the C++ FE should be less strict here...

[Bug ipa/60761] [4.9 Regression] Names of all function clones in g++ are "<built-in>", in both warnings and dumps

[rguenth at gcc dot gnu.org]

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

--- Comment #5 from Richard Biener <rguenth at gcc dot gnu.org> ---
4.8 prints

t.ii: In function ‘void _Z3fooi.constprop.0()’:
t.ii:14:8: warning: array subscript is above array bounds [-Warray-bounds]
     z[i] = i;
        ^

which isn't perfect either.  Is there a way for the C++ FE to get at the
original function decl that was cloned?  Like with

Index: gcc/cp/error.c
===================================================================
--- gcc/cp/error.c      (revision 209210)
+++ gcc/cp/error.c      (working copy)
@@ -34,6 +34,7 @@ along with GCC; see the file COPYING3.
 #include "pointer-set.h"
 #include "c-family/c-objc.h"
 #include "ubsan.h"
+#include "cgraph.h"

 #include <new>                    // For placement-new.

@@ -1145,7 +1146,17 @@ dump_decl (cxx_pretty_printer *pp, tree

     case FUNCTION_DECL:
       if (! DECL_LANG_SPECIFIC (t))
-       pp_string (pp, M_("<built-in>"));
+       {
+         cgraph_node *node;
+         if ((node = cgraph_get_node (t))
+             && node->former_clone_of)
+           {
+             dump_decl (pp, node->former_clone_of, flags);
+             pp_string (pp, M_(" <clone>"));
+           }
+         else
+           pp_string (pp, M_("<built-in>"));
+       }
       else if (DECL_GLOBAL_CTOR_P (t) || DECL_GLOBAL_DTOR_P (t))
        dump_global_iord (pp, t);
       else

which prints

t.ii: In function 'void foo(int) <clone>':
t.ii:14:13: warning: iteration 3u invokes undefined behavior
[-Waggressive-loop-optimizations]
     z[i] = i;
             ^
t.ii:13:3: note: containing loop
   for (int i = 0; i < s; i++)
   ^
t.ii:14:8: warning: array subscript is above array bounds [-Warray-bounds]
     z[i] = i;
        ^

does former_clone_of apply recursively?  Thus can we have a clone of a clone?
Is there a way to "pretty-print" the kind of clone?  That is, say
<clone with foo = 1> for a ipa-cp clone with parameter foo replaced by 1?
>From gcc-bugs-return-448526-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Tue Apr 08 11:53:19 2014
Return-Path: <gcc-bugs-return-448526-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 17382 invoked by alias); 8 Apr 2014 11:53:19 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Delivered-To: mailing list gcc-bugs@gcc.gnu.org
Received: (qmail 17321 invoked by uid 48); 8 Apr 2014 11:53:15 -0000
From: "rguenth at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug ipa/60761] [4.9 Regression] Names of all function clones in g++ are "<built-in>", in both warnings and dumps
Date: Tue, 08 Apr 2014 11:53:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: ipa
X-Bugzilla-Version: 4.9.0
X-Bugzilla-Keywords: diagnostic
X-Bugzilla-Severity: normal
X-Bugzilla-Who: rguenth at gcc dot gnu.org
X-Bugzilla-Status: NEW
X-Bugzilla-Priority: P1
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: 4.9.0
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields: priority
Message-ID: <bug-60761-4-XYSQJewuzk@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-60761-4@http.gcc.gnu.org/bugzilla/>
References: <bug-60761-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2014-04/txt/msg00546.txt.bz2
Content-length: 433

http://gcc.gnu.org/bugzilla/show_bug.cgi?id`761

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Priority|P3                          |P1

--- Comment #6 from Richard Biener <rguenth at gcc dot gnu.org> ---
Looks quite some usability regression to me, compared to 4.8.  Making P1.

[Bug ipa/60761] [4.9 Regression] Names of all function clones in g++ are "<built-in>", in both warnings and dumps

[manu at gcc dot gnu.org]

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

--- Comment #7 from Manuel López-Ibáñez <manu at gcc dot gnu.org> ---
(In reply to Richard Biener from comment #5)
> 
> does former_clone_of apply recursively?  Thus can we have a clone of a clone?
> Is there a way to "pretty-print" the kind of clone?  That is, say
> <clone with foo = 1> for a ipa-cp clone with parameter foo replaced by 1?

Why would you want to do that? At least for diagnostics to the users (not debug
dumps), that the function is a clone is an internal implementation detail.
>From gcc-bugs-return-448534-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Tue Apr 08 13:24:32 2014
Return-Path: <gcc-bugs-return-448534-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 18934 invoked by alias); 8 Apr 2014 13:24:32 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Delivered-To: mailing list gcc-bugs@gcc.gnu.org
Received: (qmail 18895 invoked by uid 48); 8 Apr 2014 13:24:28 -0000
From: "rguenth at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug middle-end/60787] [4.7 Regression] ICE in expand_builtin_eh_common, at except.c:1953
Date: Tue, 08 Apr 2014 13:24:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: middle-end
X-Bugzilla-Version: 4.7.3
X-Bugzilla-Keywords: EH, ice-on-valid-code
X-Bugzilla-Severity: normal
X-Bugzilla-Who: rguenth at gcc dot gnu.org
X-Bugzilla-Status: UNCONFIRMED
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: 4.7.4
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields: cf_known_to_work version target_milestone cf_known_to_fail
Message-ID: <bug-60787-4-XQiZcZNVm4@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-60787-4@http.gcc.gnu.org/bugzilla/>
References: <bug-60787-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2014-04/txt/msg00554.txt.bz2
Content-length: 479

http://gcc.gnu.org/bugzilla/show_bug.cgi?id`787

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
      Known to work|                            |4.6.4, 4.8.0, 4.9.0
            Version|4.9.0                       |4.7.3
   Target Milestone|---                         |4.7.4
      Known to fail|                            |4.7.0, 4.7.3

[Bug ipa/60761] [4.9 Regression] Names of all function clones in g++ are "<built-in>", in both warnings and dumps

[manu at gcc dot gnu.org]

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

--- Comment #8 from Manuel López-Ibáñez <manu at gcc dot gnu.org> ---
(In reply to Richard Biener from comment #5)
> which isn't perfect either.  Is there a way for the C++ FE to get at the
> original function decl that was cloned?  Like with
> 
> Index: gcc/cp/error.c
> ===================================================================
> --- gcc/cp/error.c      (revision 209210)
> +++ gcc/cp/error.c      (working copy)
> @@ -34,6 +34,7 @@ along with GCC; see the file COPYING3.
>  #include "pointer-set.h"
>  #include "c-family/c-objc.h"
>  #include "ubsan.h"
> +#include "cgraph.h"
>  
>  #include <new>                    // For placement-new.
>  
> @@ -1145,7 +1146,17 @@ dump_decl (cxx_pretty_printer *pp, tree
>  
>      case FUNCTION_DECL:
>        if (! DECL_LANG_SPECIFIC (t))
> -       pp_string (pp, M_("<built-in>"));
> +       {
> +         cgraph_node *node;
> +         if ((node = cgraph_get_node (t))
> +             && node->former_clone_of)
> +           {
> +             dump_decl (pp, node->former_clone_of, flags);
> +             pp_string (pp, M_(" <clone>"));
> +           }
> +         else
> +           pp_string (pp, M_("<built-in>"));
> +       }
>        else if (DECL_GLOBAL_CTOR_P (t) || DECL_GLOBAL_DTOR_P (t))
>         dump_global_iord (pp, t);
>        else
> 

Wouldn't it be better for the middle end to provide its own diagnostic_starter
function, which in turn calls the FE one and override
current_function_declaration around the call to the FE one by the original
function?

This will also allow in the future the middle-end to override other stuff that
it doesn't want the FE to deal with.
>From gcc-bugs-return-448537-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Tue Apr 08 14:18:34 2014
Return-Path: <gcc-bugs-return-448537-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 23895 invoked by alias); 8 Apr 2014 14:18:33 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Delivered-To: mailing list gcc-bugs@gcc.gnu.org
Received: (qmail 23845 invoked by uid 48); 8 Apr 2014 14:18:27 -0000
From: "trippels at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug middle-end/60787] [4.7 Regression] ICE in expand_builtin_eh_common, at except.c:1953
Date: Tue, 08 Apr 2014 14:18:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: middle-end
X-Bugzilla-Version: 4.7.3
X-Bugzilla-Keywords: EH, ice-on-valid-code
X-Bugzilla-Severity: normal
X-Bugzilla-Who: trippels at gcc dot gnu.org
X-Bugzilla-Status: NEW
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: 4.7.4
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields: bug_status cf_reconfirmed_on cc everconfirmed
Message-ID: <bug-60787-4-EeCTlR3sSy@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-60787-4@http.gcc.gnu.org/bugzilla/>
References: <bug-60787-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2014-04/txt/msg00557.txt.bz2
Content-length: 3056

http://gcc.gnu.org/bugzilla/show_bug.cgi?id`787

Markus Trippelsdorf <trippels at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2014-04-08
                 CC|                            |trippels at gcc dot gnu.org
     Ever confirmed|0                           |1

--- Comment #2 from Markus Trippelsdorf <trippels at gcc dot gnu.org> ---
This is what creduce came up with:

template <class T> void destroy (T *);
template <class FI> struct ArrayFill
{
  ArrayFill (FI, FI &p2) : tgt_start_ (), tgt_end_ (p2) {}
  template <class Val> void m_fn1 (Val &, int &)
  {
    while (tgt_cur_ != tgt_end_)
      ++tgt_cur_;
  }
  ~ArrayFill () throw()
  {
    if (tgt_cur_ != tgt_end_)
      while (tgt_cur_ != tgt_start_)
        {
          --tgt_cur_;
          destroy (&*tgt_cur_);
        }
  }
  const FI tgt_start_, tgt_end_;
  FI tgt_cur_;
};

template <class FI, class Val>
inline FI uninitialized_fill (FI &p1, FI &p2, Val &p3, int &p4)
{
  ArrayFill<FI> a (p1, p2);
  a.m_fn1 (p3, p4);
}

template <class, typename> struct A
{
  typedef int *pointer;
  typedef int &const_reference;
  template <class Val2> int m_fn1 (const A<Val2, int> &p1)
  {
    return cur_ == p1.cur_;
  }
  const_reference operator*() {}
  void operator++()
  {
    if (last_)
      cur_ = first_;
  }
  void operator--() { --cur_; }
  pointer cur_;
  pointer first_;
  pointer last_;
};

template <class Val, class Val2, typename BufSize>
inline int operator==(A<Val, BufSize> &p1, const A<Val2, BufSize> &p2)
{
  return p1.m_fn1 (p2);
}

template <class Val, class Val2, typename BufSize>
inline int operator!=(A<Val, BufSize> &p1, const A<Val2, BufSize> &p2)
{
  return !(p1 == p2);
}

struct B
{
  typedef A<int, int>::const_reference const_reference;
};
class C
{
public:
  typedef B::const_reference const_reference;
  int *p_ma_;
  struct MapCreator
  {
    ~MapCreator ();
  };
  struct MultiNodeCreator
  {
    MultiNodeCreator (A<int, int>::pointer *, A<int, int>::pointer *, int &p3)
        : ma_ (p3)
    {
    }
    ~MultiNodeCreator () throw();
    void m_fn1 ();
    int &ma_;
  };
  void m_fn1 (A<int, int>::pointer *, A<int, int>::pointer *, int &)
  {
    MultiNodeCreator b (0, 0, *p_ma_);
    b.m_fn1 ();
  }
  C::MapCreator initialize_map__new_map;
  int &m_fn2_p3;
  void m_fn2 (int, int)
  {
    m_fn1 (0, 0, m_fn2_p3);
    this->finish_.cur_ = this->finish_.first_;
  }
  C (int &);
  A<int, int> start_;
  A<int, int> finish_;
};

class G : C
{
  void m_fn3 (const_reference p1, const int &)
  {
    this->m_fn2 (0, 0);
    uninitialized_fill (this->start_, this->finish_, p1, *this->p_ma_);
  }
public:
  G (int, const_reference p2, int &p3) : C (p3) { m_fn3 (p2, 0); }
  void m_fn4 (const_reference p1) { G (0, p1, *this->p_ma_); }
};

class F
{
  void m_fn1 (int &);
  G m_jobs;
};
void F::m_fn1 (int &p1) { m_jobs.m_fn4 (p1); }

[Bug ipa/60761] [4.9 Regression] Names of all function clones in g++ are "<built-in>", in both warnings and dumps

[jamborm at gcc dot gnu.org]

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

--- Comment #9 from Martin Jambor <jamborm at gcc dot gnu.org> ---
(In reply to Richard Biener from comment #5)
> 4.8 prints
> 
> t.ii: In function ‘void _Z3fooi.constprop.0()’:
> t.ii:14:8: warning: array subscript is above array bounds [-Warray-bounds]
>      z[i] = i;
>         ^

I think that we can perhaps get closest to that with something like:

pp_string (pp, IDENTIFIER_POINTER (DECL_ASSEMBLER_NAME (t)));

which prints 

zz.C: In function ‘_Z3fooi.constprop.0’:

by using DECL_NAME instead of DECL_ASSEMBLER_NAME we can get
avoid mangling:

zz.C: In function ‘foo.constprop’:

> 
> does former_clone_of apply recursively? 

I believe that (at least currently) former_clone_of will always be the
original front-end declaration, i.e. the same as DECL_ABSTRACT_ORIGIN,
despite that...

> Thus can we have a clone of a clone?

...yes, the infrastructure allows that, although currently only such
clones are inline clones and thus not posing this problem.

> Is there a way to "pretty-print" the kind of clone?  That is, say
> <clone with foo = 1> for a ipa-cp clone with parameter foo replaced by 1?

Hm, it would require changes elsewhere to do for aggregate
replacements (we'd need to remember the old decl and we remember only
offsets, not expressions), for scalar replacements it is already
apparently quite possible:

diff --git a/gcc/cp/error.c b/gcc/cp/error.c
index 454feb5..bb8db31 100644
--- a/gcc/cp/error.c
+++ b/gcc/cp/error.c
@@ -34,6 +34,7 @@ along with GCC; see the file COPYING3.  If not see
 #include "pointer-set.h"
 #include "c-family/c-objc.h"
 #include "ubsan.h"
+#include "cgraph.h"

 #include <new>                    // For placement-new.

@@ -1144,7 +1145,35 @@ dump_decl (cxx_pretty_printer *pp, tree t, int flags)
       /* Fall through.  */

     case FUNCTION_DECL:
-      if (! DECL_LANG_SPECIFIC (t))
+      if (DECL_ABSTRACT_ORIGIN (t))
+       {
+         dump_decl (pp, DECL_ABSTRACT_ORIGIN (t), flags);
+         
+         cgraph_node *node = cgraph_get_node (t);
+         if (node && node->clone.tree_map)
+           {
+             struct ipa_replace_map *rmap;
+             unsigned i;
+             bool first = true;
+             pp_string (pp, M_(" <clone with "));
+
+             FOR_EACH_VEC_ELT (*node->clone.tree_map, i, rmap)
+               {
+                 if (first)
+                   first = false;
+                 else 
+                   pp_string (pp, (", "));
+
+                 dump_expr (pp, rmap->new_tree, flags);
+                 pp_string (pp, M_(" for "));
+                 dump_expr (pp, rmap->old_tree, flags);
+               }
+             pp_string (pp, ">");
+           }
+         else
+           pp_string (pp, M_(" <clone>"));
+       }
+      else if (! DECL_LANG_SPECIFIC (t))
        pp_string (pp, M_("<built-in>"));
       else if (DECL_GLOBAL_CTOR_P (t) || DECL_GLOBAL_DTOR_P (t))
        dump_global_iord (pp, t);

gives:

zz.C: In function ‘void foo(int) <clone with 4 for s>’:
>From gcc-bugs-return-448544-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Tue Apr 08 16:08:13 2014
Return-Path: <gcc-bugs-return-448544-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 13819 invoked by alias); 8 Apr 2014 16:08:12 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Delivered-To: mailing list gcc-bugs@gcc.gnu.org
Received: (qmail 13696 invoked by uid 55); 8 Apr 2014 16:08:06 -0000
From: "meissner at linux dot vnet.ibm.com" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug rtl-optimization/60763] [4.9 Regression] ICE in extract_insn starting with rev 208984
Date: Tue, 08 Apr 2014 16:08:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: rtl-optimization
X-Bugzilla-Version: 4.9.0
X-Bugzilla-Keywords: ice-on-valid-code
X-Bugzilla-Severity: normal
X-Bugzilla-Who: meissner at linux dot vnet.ibm.com
X-Bugzilla-Status: NEW
X-Bugzilla-Priority: P1
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: 4.9.0
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields:
Message-ID: <bug-60763-4-49opUb7X2v@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-60763-4@http.gcc.gnu.org/bugzilla/>
References: <bug-60763-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2014-04/txt/msg00564.txt.bz2
Content-length: 1881

http://gcc.gnu.org/bugzilla/show_bug.cgi?id`763

--- Comment #14 from Michael Meissner <meissner at linux dot vnet.ibm.com> ---
On Tue, Apr 08, 2014 at 03:21:13PM +0000, dje at gcc dot gnu.org wrote:
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id`763
>
> --- Comment #13 from David Edelsohn <dje at gcc dot gnu.org> ---
> Gentlemen, I really do not understand this discussion.
>
> I used the term "crude" and receive a response that it is not crude, but it is
> dangerous. WTF? Why is anyone trying to "sell" the patch when I repeatedly have
> said that I do not disagree with it in principle? I only am trying to ensure
> that this is the right use of the GCC API. i386 uses this idiom a lot; rs6000
> does not.
>
> I see multiple responses trying to convince me of a patch with which I already
> agree and no one writing a one line comment.

When you are doing a subreg type operation, before reload, you must NOT use the
register number directly.  This is the dangerous part that was mentioned.
Hence using gen_highpart, gen_lowpart, or simplify_gen_subreg is the
appropriate solution.

If you are doing splits after reload, and are dealing with whole registers, the
preferred solution is to create a new REG with the appropriate register number.
In particular, gen_highpart and gen_lowpart must not be used after reload.
However, up until the patch to add more checking, simplify_gen_subreg could be
used after reload.

The alpha, arm, i386, ia64, iq2000, m32k, m68k, mips, msp430, pa, pdp11,
picochip, rl78, rs6000, s390, sh, sparc, spu, and xtensa all generate a call to
gen_rtx_REG using REGNO of an operand to change types.

Out of force of habit, I've tended to use simplify_gen_subreg when doing
splitting, no matter whether it is before or after reload.  I thought with
'simplify' in the name, it would do the right thing after reload, but evidently
it does not.

[Bug ipa/60761] [4.9 Regression] Names of all function clones in g++ are "<built-in>", in both warnings and dumps

[jamborm at gcc dot gnu.org]

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

--- Comment #10 from Martin Jambor <jamborm at gcc dot gnu.org> ---
Created attachment 32574
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=32574&action=edit
WIP patch displaying IPA-CP information aout clones

This is an untested and very much WIP patch that shows how we can
print additional information about clones, at least about those
created by IPA-CP.  Of course eventually it should not be in the
front-end.  It also retains more information in memory, although not
that much.

For the source below, it produces the following output:

mjambor@virgil:~/gcc/mine/tests/pr60761-clonenames$ ~/gcc/mine/inst/bin/g++ -O3
-S -Wall aa.C -fno-inline
aa.C: In function ‘void foo(int, A*) <clone with 4 for s, 10 for data pointed
to by  a at offset 32>’:
aa.C:19:20: warning: iteration 3u invokes undefined behavior
[-Waggressive-loop-optimizations] 
     z[i] = i + a->j;
                    ^
aa.C:18:3: note: containing loop
   for (int i = 0; i < s; i++)
   ^
aa.C:19:8: warning: array subscript is above array bounds [-Warray-bounds]
     z[i] = i + a->j;


the source code is:

extern int sum;

void do_sum (char *p)
{
  for (int i = 0; i < 2; i++)
    sum += p[i];
}

struct A
{
  int i, j, k;
};

void
foo (int s, struct A *a)
{
  char z[3];
  for (int i = 0; i < s; i++)
    z[i] = i + a->j;
  do_sum (z);
}

int
bar (int i)
{
  struct A a;
  a.j = 10;
  foo (4, &a);
  return 0;
}
>From gcc-bugs-return-448629-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Wed Apr 09 16:14:26 2014
Return-Path: <gcc-bugs-return-448629-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 7524 invoked by alias); 9 Apr 2014 16:14:26 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Delivered-To: mailing list gcc-bugs@gcc.gnu.org
Received: (qmail 6802 invoked by uid 48); 9 Apr 2014 16:14:20 -0000
From: "jakub at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug ipa/60761] [4.9 Regression] Names of all function clones in g++ are "<built-in>", in both warnings and dumps
Date: Wed, 09 Apr 2014 16:14:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: ipa
X-Bugzilla-Version: 4.9.0
X-Bugzilla-Keywords: diagnostic
X-Bugzilla-Severity: normal
X-Bugzilla-Who: jakub at gcc dot gnu.org
X-Bugzilla-Status: NEW
X-Bugzilla-Priority: P1
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: 4.9.0
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields:
Message-ID: <bug-60761-4-7NvGYFn47H@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-60761-4@http.gcc.gnu.org/bugzilla/>
References: <bug-60761-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2014-04/txt/msg00649.txt.bz2
Content-length: 566

http://gcc.gnu.org/bugzilla/show_bug.cgi?id`761

--- Comment #11 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Won't that break say -g -O2 -Wall reporting with say:
static inline void
foo (char *p)
{
  __builtin___memcpy_chk (p, "abc", 3, __builtin_object_size (p, 0));
}

static inline void
bar (char *p)
{
  foo (p);
}

void
baz (void)
{
  char buf[2];
  bar (buf);
}

I mean, DECL_ABSTRACT_ORIGIN is set also for inlines, fnsplit created functions
and many other cases, printing <clone> after the function name in all those
cases might not be appropriate.

[Bug ipa/60761] [4.9 Regression] Names of all function clones in g++ are "<built-in>", in both warnings and dumps

[jakub at gcc dot gnu.org]

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

--- Comment #12 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Also, perhaps to make the change conservative enough for 4.9, might be best to
not append anything now, and only look at DECL_ABSTRACT_ORIGIN (recurse on it)
if !DECL_LANG_SPECIFIC.  More verbose printing can be perhaps deferred for
stage1.

[Bug ipa/60761] [4.9 Regression] Names of all function clones in g++ are "<built-in>", in both warnings and dumps

[manu at gcc dot gnu.org]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset="UTF-8", Size: 3571 bytes --]

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

--- Comment #13 from Manuel López-Ibáñez <manu at gcc dot gnu.org> ---
(In reply to Jakub Jelinek from comment #11)
> I mean, DECL_ABSTRACT_ORIGIN is set also for inlines, fnsplit created
> functions and many other cases, printing <clone> after the function name in
> all those cases might not be appropriate.

It is not clear to me why you want to print <clone> at all. It is an internal
detail.
>From gcc-bugs-return-448633-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Wed Apr 09 16:27:48 2014
Return-Path: <gcc-bugs-return-448633-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 20202 invoked by alias); 9 Apr 2014 16:27:48 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Delivered-To: mailing list gcc-bugs@gcc.gnu.org
Received: (qmail 20178 invoked by uid 48); 9 Apr 2014 16:27:44 -0000
From: "brian.freyburger at blandertechnologies dot com" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug c++/60796] New: Default move constructor not generated by explicit template instantiaion (C++11)
Date: Wed, 09 Apr 2014 16:27:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: new
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: c++
X-Bugzilla-Version: 4.8.1
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: brian.freyburger at blandertechnologies dot com
X-Bugzilla-Status: UNCONFIRMED
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields: bug_id short_desc product version bug_status bug_severity priority component assigned_to reporter
Message-ID: <bug-60796-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2014-04/txt/msg00653.txt.bz2
Content-length: 1236

http://gcc.gnu.org/bugzilla/show_bug.cgi?id`796

            Bug ID: 60796
           Summary: Default move constructor not generated by explicit
                    template instantiaion (C++11)
           Product: gcc
           Version: 4.8.1
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c++
          Assignee: unassigned at gcc dot gnu.org
          Reporter: brian.freyburger at blandertechnologies dot com

When you use explicit template instantiation in separate compilation units, and
disable implicit instantiation, a move constructor and move assignment operator
defined as "Þfault" is not generated.

See example here:

A.H:

#include <memory>

template <typename T>
struct A
{
  A (T*a) : a(a) {}

  A(A&&) = default;
  A& operator =(const A&) = default;

  std::shared_ptr<T> a;
};

extern template class A<int>;

A.C:

#include "A.H"

template class A<int>;

main.C:

#include "A.H"

template class A<int>;
int main()
{
  A<int> a = new int(19);
  A<int> b = std::move(a);
}


results:

g++ -std=c++11 A.C main.C
/tmp/ccvE1IqS.o: In function `main':
main.C:(.text+0xdc): undefined reference to `A<int>::A(A<int>&&)'
collect2: error: ld returned 1 exit status

[Bug ipa/60761] [4.9 Regression] Names of all function clones in g++ are "<built-in>", in both warnings and dumps

[glisse at gcc dot gnu.org]

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

--- Comment #14 from Marc Glisse <glisse at gcc dot gnu.org> ---
(In reply to Manuel López-Ibáñez from comment #13)
> It is not clear to me why you want to print <clone> at all. It is an
> internal detail.

Imagine a function void f(unsigned a, unsigned b) where gcc makes a clone
specializing a=0. If the function contains a comparison a<=b, you might get a
warning because the comparison is always true. As a user, I would be quite
confused...

Ok, this particular example won't happen, but I think it is still a reason why
writing <clone> and maybe some more details can be useful.
>From gcc-bugs-return-448638-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Wed Apr 09 17:54:55 2014
Return-Path: <gcc-bugs-return-448638-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 9058 invoked by alias); 9 Apr 2014 17:54:54 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Delivered-To: mailing list gcc-bugs@gcc.gnu.org
Received: (qmail 9001 invoked by uid 48); 9 Apr 2014 17:54:50 -0000
From: "izamyatin at gmail dot com" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug middle-end/60469] simple cilk plus program ICEs
Date: Wed, 09 Apr 2014 17:54:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: middle-end
X-Bugzilla-Version: unknown
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: izamyatin at gmail dot com
X-Bugzilla-Status: UNCONFIRMED
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields:
Message-ID: <bug-60469-4-c0wu16o4Md@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-60469-4@http.gcc.gnu.org/bugzilla/>
References: <bug-60469-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2014-04/txt/msg00658.txt.bz2
Content-length: 3755

http://gcc.gnu.org/bugzilla/show_bug.cgi?id`469

--- Comment #4 from Igor Zamyatin <izamyatin at gmail dot com> ---
Following works for me and shows no new errors in regtesting. Not sure it is a
good idea though...

diff --git a/gcc/c/c-array-notation.c b/gcc/c/c-array-notation.c
index 6a5631c..d7c6772 100644
--- a/gcc/c/c-array-notation.c
+++ b/gcc/c/c-array-notation.c
@@ -284,6 +284,7 @@ fix_builtin_array_notation_fn (tree an_builtin_fn, tree
*new_var)
     {
       an_loop_info[ii].var = build_decl (location, VAR_DECL, NULL_TREE,
                   integer_type_node);
+      DECL_CONTEXT (an_loop_info[ii].var) = current_function_decl;
       an_loop_info[ii].ind_init      build_modify_expr (location, an_loop_info[ii].var,
                TREE_TYPE (an_loop_info[ii].var), NOP_EXPR,
@@ -783,6 +784,7 @@ build_array_notation_expr (location_t location, tree lhs,
tree lhs_origtype,
       {
     lhs_an_loop_info[ii].var = build_decl (location, VAR_DECL, NULL_TREE,
                            integer_type_node);
+    DECL_CONTEXT (lhs_an_loop_info[ii].var) = current_function_decl;
     lhs_an_loop_info[ii].ind_init = build_modify_expr
       (location, lhs_an_loop_info[ii].var,
        TREE_TYPE (lhs_an_loop_info[ii].var), NOP_EXPR,
@@ -795,6 +797,7 @@ build_array_notation_expr (location_t location, tree lhs,
tree lhs_origtype,
      integer.  */
       rhs_an_loop_info[ii].var = build_decl (location, VAR_DECL, NULL_TREE,
                          integer_type_node);
+      DECL_CONTEXT (rhs_an_loop_info[ii].var) = current_function_decl;
       rhs_an_loop_info[ii].ind_init = build_modify_expr
     (location, rhs_an_loop_info[ii].var,
      TREE_TYPE (rhs_an_loop_info[ii].var), NOP_EXPR,
@@ -972,6 +975,7 @@ fix_conditional_array_notations_1 (tree stmt)
     {
       an_loop_info[ii].var = build_decl (location, VAR_DECL, NULL_TREE,
                      integer_type_node);
+      DECL_CONTEXT (an_loop_info[ii].var) = current_function_decl;
       an_loop_info[ii].ind_init      build_modify_expr (location, an_loop_info[ii].var,
                TREE_TYPE (an_loop_info[ii].var), NOP_EXPR,
@@ -1069,6 +1073,7 @@ fix_array_notation_expr (location_t location, enum
tree_code code,
     {
       an_loop_info[ii].var = build_decl (location, VAR_DECL, NULL_TREE,
                      integer_type_node);
+      DECL_CONTEXT (an_loop_info[ii].var) = current_function_decl;
       an_loop_info[ii].ind_init      build_modify_expr (location, an_loop_info[ii].var,
                TREE_TYPE (an_loop_info[ii].var), NOP_EXPR,
@@ -1165,6 +1170,7 @@ fix_array_notation_call_expr (tree arg)
     {
       an_loop_info[ii].var = build_decl (location, VAR_DECL, NULL_TREE,
                      integer_type_node);
+      DECL_CONTEXT (an_loop_info[ii].var) = current_function_decl;
       an_loop_info[ii].ind_init      build_modify_expr (location, an_loop_info[ii].var,
                TREE_TYPE (an_loop_info[ii].var), NOP_EXPR, location,
diff --git a/gcc/gimplify.c b/gcc/gimplify.c
index 7441784..b61a995 100644
--- a/gcc/gimplify.c
+++ b/gcc/gimplify.c
@@ -1732,6 +1732,7 @@ gimplify_var_or_parm_decl (tree *expr_p)
      be really nice if the front end wouldn't leak these at all.
      Currently the only known culprit is C++ destructors, as seen
      in g++.old-deja/g++.jason/binding.C.  */
+#if 0
   if (TREE_CODE (decl) == VAR_DECL
       && !DECL_SEEN_IN_BIND_EXPR_P (decl)
       && !TREE_STATIC (decl) && !DECL_EXTERNAL (decl)
@@ -1740,6 +1741,7 @@ gimplify_var_or_parm_decl (tree *expr_p)
       gcc_assert (seen_error ());
       return GS_ERROR;
     }
+#endif

   /* When within an OpenMP context, notice uses of variables.  */
   if (gimplify_omp_ctxp && omp_notice_variable (gimplify_omp_ctxp, decl,
true))

[Bug ipa/60761] [4.9 Regression] Names of all function clones in g++ are "<built-in>", in both warnings and dumps

[jamborm at gcc dot gnu.org]

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

--- Comment #15 from Martin Jambor <jamborm at gcc dot gnu.org> ---
(In reply to Jakub Jelinek from comment #12)
> Also, perhaps to make the change conservative enough for 4.9, might be best
> to not append anything now, and only look at DECL_ABSTRACT_ORIGIN (recurse
> on it) if !DECL_LANG_SPECIFIC.  More verbose printing can be perhaps
> deferred for stage1.

I agree, mostly because...

(In reply to Manuel López-Ibáñez from comment #13)
> It is not clear to me why you want to print <clone> at all. It is an
> internal detail.

...just printing "<clone>" really provides fairly little value.  If we
(hopefully from the next version on) manage to print details about
properties of the particular clone, it will become useful.
>From gcc-bugs-return-448710-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Thu Apr 10 12:08:23 2014
Return-Path: <gcc-bugs-return-448710-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 3608 invoked by alias); 10 Apr 2014 12:08:22 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Delivered-To: mailing list gcc-bugs@gcc.gnu.org
Received: (qmail 3574 invoked by uid 48); 10 Apr 2014 12:08:19 -0000
From: "jakub at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug target/60800] -Ofast -ffast-math miscompiles 178.galgel in SPEC CPU 2K
Date: Thu, 10 Apr 2014 12:08:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: target
X-Bugzilla-Version: 4.9.0
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: jakub at gcc dot gnu.org
X-Bugzilla-Status: UNCONFIRMED
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields: cc
Message-ID: <bug-60800-4-9yiUZYt54y@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-60800-4@http.gcc.gnu.org/bugzilla/>
References: <bug-60800-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2014-04/txt/msg00730.txt.bz2
Content-length: 465

http://gcc.gnu.org/bugzilla/show_bug.cgi?id`800

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jakub at gcc dot gnu.org

--- Comment #3 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Can you please bisect it to a particular gcc commit and/or single 178.galgel
source file?

[Bug ipa/60761] [4.9 Regression] Names of all function clones in g++ are "<built-in>", in both warnings and dumps

[manu at gcc dot gnu.org]

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

--- Comment #16 from Manuel López-Ibáñez <manu at gcc dot gnu.org> ---
(In reply to Martin Jambor from comment #15)
> (In reply to Manuel López-Ibáñez from comment #13)
> > It is not clear to me why you want to print <clone> at all. It is an
> > internal detail.
> 
> ...just printing "<clone>" really provides fairly little value.  If we
> (hopefully from the next version on) manage to print details about
> properties of the particular clone, it will become useful.

I'm not entirely convinced by the arguments given above. Templated C++ code in
diagnostics is already convoluted enough to add stuff that is not even in the
language and that users will have no idea about. Imagine (real G++ output):

std::basic_ostream<_CharT, _Traits>::__ostream_type& std::basic_ostream<_CharT,
_Traits>::operator<<(std::basic_ostream<_CharT, _Traits>::__ostream_type&
(*)(std::basic_ostream<_CharT, _Traits>::__ostream_type&)) [with _CharT = char,
_Traits = std::char_traits<char>, std::basic_ostream<_CharT,
_Traits>::__ostream_type = std::basic_ostream<char>] <clone>

For developer/debug dumps, of course this doesn't apply, but this is not what
this bug is about.


(In reply to Marc Glisse from comment #14)
> Imagine a function void f(unsigned a, unsigned b) where gcc makes a clone
> specializing a=0. If the function contains a comparison a<=b, you might get
> a warning because the comparison is always true. As a user, I would be quite
> confused...

This used to happen with template instantiations and it was considered a bug.
That is, the compiler should not give that kind of warning for generated code
if the original code does not show the same issue. If the original code shows
the same issue, then we should give a warning for the original code. 

In general, there are at least two kinds of warnings: those for which there is
a bug if we reach that code under certain conditions, and those for which the
code looks suspicious but we cannot prove that there is a bug under any
specific condition. Uninitialized warnings fall in the first category, whereas
"comparison is always true/false" falls under the second one. The first kind of
warnings would be improved by providing the exact conditions that may trigger
the bug, whereas the second kind become noise if only triggered for specific
conditions that are actually not present in the original code (like template
specializations, macro expansion, and function cloning).

For the first kind of bugs, if we explain the conditions better thanks to
optimization, great, but saying: we warn because we created a clone of the
function only leads to more questions: what is a clone? For the second kind,
saying that we warn because we created a clone sounds more like an excuse than
an actual analysis. ;-)
>From gcc-bugs-return-448717-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Thu Apr 10 14:01:09 2014
Return-Path: <gcc-bugs-return-448717-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 25861 invoked by alias); 10 Apr 2014 14:01:09 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Delivered-To: mailing list gcc-bugs@gcc.gnu.org
Received: (qmail 25820 invoked by uid 48); 10 Apr 2014 14:01:04 -0000
From: "mpolacek at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug c/60809] C99 struct initialiser with embedded self assignment
Date: Thu, 10 Apr 2014 14:01:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: c
X-Bugzilla-Version: 4.8.1
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: mpolacek at gcc dot gnu.org
X-Bugzilla-Status: UNCONFIRMED
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields: cc
Message-ID: <bug-60809-4-1iLGh9AJ4r@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-60809-4@http.gcc.gnu.org/bugzilla/>
References: <bug-60809-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2014-04/txt/msg00737.txt.bz2
Content-length: 686

http://gcc.gnu.org/bugzilla/show_bug.cgi?id`809

Marek Polacek <mpolacek at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |mpolacek at gcc dot gnu.org

--- Comment #1 from Marek Polacek <mpolacek at gcc dot gnu.org> ---
I see nothing surprising here; an assignment expression has the value of the
left operand after the assignment.  So we 1) set query2.ai_flags to AI_PASSIVE,
2) use this value to initialize .ai_protocol.

I'm not sure a warning here makes sense: an assignment-expression is perfectly
valid initializer.

[Bug ipa/60761] [4.9 Regression] Names of all function clones in g++ are "<built-in>", in both warnings and dumps

[jakub at gcc dot gnu.org]

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

--- Comment #17 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Author: jakub
Date: Thu Apr 10 16:20:07 2014
New Revision: 209278

URL: http://gcc.gnu.org/viewcvs?rev=209278&root=gcc&view=rev
Log:
    PR ipa/60761
    * error.c (dump_decl) <case FUNCTION_DECL>: If
    DECL_LANG_SPECIFIC is NULL, but DECL_ABSTRACT_ORIGIN is not,
    recurse on DECL_ABSTRACT_ORIGIN instead of printing
    <built-in>.

Modified:
    trunk/gcc/cp/ChangeLog
    trunk/gcc/cp/error.c

[Bug ipa/60761] [4.9 RegrImprove dump_decl for clones

[jakub at gcc dot gnu.org]

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

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Priority|P1                          |P3
            Summary|[4.9 Regression] Names of   |[4.9 RegrImprove dump_decl
                   |all function clones in g++  |for clones
                   |are "<built-in>", in both   |
                   |warnings and dumps          |

--- Comment #18 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
No longer a regression, keeping open as enhancement request to improve the
dumping for stage1.

[Bug ipa/60761] Improve dump_decl for clones

[jakub at gcc dot gnu.org]

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

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|4.9.0                       |4.9.1

--- Comment #19 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
GCC 4.9.0 has been released

[Bug ipa/60761] Improve dump_decl for clones

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60761

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|4.9.1                       |4.9.2

--- Comment #20 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
GCC 4.9.1 has been released.

[Bug ipa/60761] Improve dump_decl for clones

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60761

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|4.9.2                       |4.9.3

--- Comment #21 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
GCC 4.9.2 has been released.

[Bug ipa/60761] Improve dump_decl for clones

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60761

--- Comment #22 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
GCC 4.9.3 has been released.

[Bug ipa/60761] Improve dump_decl for clones

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60761

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|4.9.3                       |4.9.4

[Bug ipa/60761] Improve dump_decl for clones

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60761

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|4.9.4                       |---

[Bug ipa/60761] Improve dump_decl for clones

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60761

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Depends on|                            |102061

--- Comment #23 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
I filed PR 102061 for at least one of the issues mentioned here dealing with
.constprop is being exposed.


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102061
[Bug 102061] .constprop gets exposed in warning message