[Bug middle-end/60832] add pretty-printer code for double-int/wide-int

[Bug middle-end/60832] add pretty-printer code for double-int/wide-int

[rguenth at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |diagnostic
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2014-04-14
     Ever confirmed|0                           |1

--- Comment #1 from Richard Biener <rguenth at gcc dot gnu.org> ---
Confirmed.  Btw, the fallback of using hex-style printing for too large
double-ints is bad.  Better go via GMP and its sprintf ability.

[Bug middle-end/60832] add pretty-printer code for double-int/wide-int

[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: 3729 bytes --]

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

--- Comment #2 from Manuel López-Ibáñez <manu at gcc dot gnu.org> ---
Author: manu
Date: Mon Sep 21 10:11:24 2015
New Revision: 227964

URL: https://gcc.gnu.org/viewcvs?rev=227964&root=gcc&view=rev
Log:
[PR middle-end/60832] Do not convert widest_int to tree just for printing it.

In do_warn_aggressive_loop_optimizations, we convert to a tree just to print a
widest_int. Apart from overly complicated, this results in printing '3u'
instead of just '3'.

Unfortunately, adding a printf-like conversion specifier would require making
pretty-print.c link with wide-int.cc, which will include a lot of new
dependencies into several other programs (gcov-tool for example). It would be
possible to add the conversion specifier to every FE pretty-printer, but this
still would require updating c-format.c, which is far from trivial. A simpler
approach is to convert to a string rather than to a tree.

In addition, "iteration 3 invokes undefined behavior within this loop" seems to
me clearer than "iteration 3 invokes undefined behavior; containing loop".

gcc/testsuite/ChangeLog:

2015-09-21  Manuel López-Ibáñez  <manu@gcc.gnu.org>

        PR middle-end/60832
        * gcc.dg/pr53265.c: Update.

gcc/ChangeLog:

2015-09-21  Manuel López-Ibáñez  <manu@gcc.gnu.org>

        PR middle-end/60832
        * tree-ssa-loop-niter.c (do_warn_aggressive_loop_optimizations):
        Print i_bound without converting it to a tree.



Modified:
    trunk/gcc/ChangeLog
    trunk/gcc/testsuite/ChangeLog
    trunk/gcc/testsuite/gcc.dg/pr53265.c
    trunk/gcc/tree-ssa-loop-niter.c
>From gcc-bugs-return-497706-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Mon Sep 21 10:36:29 2015
Return-Path: <gcc-bugs-return-497706-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 13269 invoked by alias); 21 Sep 2015 10:36:29 -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 13240 invoked by uid 48); 21 Sep 2015 10:36:25 -0000
From: "vries at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug tree-optimization/67666] single restrict pointer in struct looses restrict
Date: Mon, 21 Sep 2015 10:36:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: tree-optimization
X-Bugzilla-Version: 6.0
X-Bugzilla-Keywords:
X-Bugzilla-Severity: enhancement
X-Bugzilla-Who: vries at gcc dot gnu.org
X-Bugzilla-Status: UNCONFIRMED
X-Bugzilla-Resolution:
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: attachments.created
Message-ID: <bug-67666-4-XTiCt82Mdr@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-67666-4@http.gcc.gnu.org/bugzilla/>
References: <bug-67666-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: 2015-09/txt/msg01684.txt.bz2
Content-length: 214

https://gcc.gnu.org/bugzilla/show_bug.cgi?idg666

--- Comment #1 from vries at gcc dot gnu.org ---
Created attachment 36360
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id6360&actioníit
Tentative patch

[Bug middle-end/60832] add pretty-printer code for double-int/wide-int

[manu at gcc dot gnu.org]

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

--- Comment #3 from Manuel López-Ibáñez <manu at gcc dot gnu.org> ---
Created attachment 36361
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36361&action=edit
add %Wi %Wu %Wd for pretty-printing wides_int

This fails bootstrap at:

libcommon.a(pretty-print.o): In function `pp_format(pretty_printer*,
text_info*)':
/home/manuel/test1/src/gcc/pretty-print.c:543: undefined reference to
`print_dec(generic_wide_int<wide_int_ref_storage<false> > const&, char*,
signop)'
/home/manuel/test1/src/gcc/pretty-print.c:573: undefined reference to
`print_dec(generic_wide_int<wide_int_ref_storage<false> > const&, char*,
signop)'
collect2: error: ld returned 1 exit status
make: *** [gcov] Error 1

pretty-print.c is used all over the place and adding a dependency on
wide-int.cc will bring gmp and other stuff that is currently  not used (nor
linked with) various helper programs. If wide-int is only printed in the
middle-end, perhaps it is sufficient to add it to default_tree_printer.
Otherwise, it needs to be added to every FE. This is not difficult just
tedious. The difficult part is the c-format.c changes (I wish someone would fix
https://gcc.gnu.org/PR47781 so we can use a simpler syntax to define our custom
specifiers; in addition to the positive synergies it will bring with other GNU
projects that use custom specifiers and wish to use -Wformat).
>From gcc-bugs-return-497710-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Mon Sep 21 11:17:25 2015
Return-Path: <gcc-bugs-return-497710-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 72999 invoked by alias); 21 Sep 2015 11:17:24 -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 72959 invoked by uid 48); 21 Sep 2015 11:17:21 -0000
From: "miyuki at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug middle-end/67649] trunk build with valgrind fail in get_def_blocks_for
Date: Mon, 21 Sep 2015 11:17: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: 6.0
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: miyuki at gcc dot gnu.org
X-Bugzilla-Status: NEW
X-Bugzilla-Resolution:
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-67649-4-l2BvKFY7K9@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-67649-4@http.gcc.gnu.org/bugzilla/>
References: <bug-67649-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: 2015-09/txt/msg01688.txt.bz2
Content-length: 315

https://gcc.gnu.org/bugzilla/show_bug.cgi?idg649

--- Comment #7 from Mikhail Maltsev <miyuki at gcc dot gnu.org> ---
Probably. Will look at this today (valgrind has some sort of memory pool API, I
think it can be used here).
I need to configure GCC with --enable-checking=yes,valgrind to reproduce this,
right?