Re: [PATCH] Improved diagnostics for casts and enums

2017-04-30 Thread Volker Reichelt
On 28 Apr, Volker Reichelt wrote: > On 27 Apr, Martin Sebor wrote: >> On 04/27/2017 01:29 AM, Volker Reichelt wrote: >>> Hi, >>> >>> the following two patches aim at improving GCC's diagnostics to help >>> the user to get rid of old-style casts. While old-style pointer casts >>> are really bad and

Make ipa-inline-analysis to compute expected runtime without specialization

2017-04-30 Thread Jan Hubicka
Hi, this patch fixes the underlying issue of PR 79224. Both inliner and ipa-cp is trying to maximize performance benefit at a given code size expense. The problem is that perfomrance benefit is computed by comparing estimated time of offline function to inline/specialized time. This is however

Re: Who broke options.h?

2017-04-30 Thread Gerald Pfeifer
On Tue, 25 Apr 2017, Jakub Jelinek wrote: > Committed to trunk, 7.x will need to wait until 7.1 is released, > the rc1 is already in the works and this isn't anything new, I > see the same thing already in GCC 4.0. Thanks, Jakub! Are you planning to apply this to GCC 7 after the release of 7.1?

Re: Add st[pr]ncpy to stmt_kills_ref_p

2017-04-30 Thread Martin Sebor
On 04/29/2017 01:17 AM, Marc Glisse wrote: Hello, this patch seems rather trivial, once one knows that those functions always write exactly n characters (they fill with 0 as needed at the end). Nice! Now it just needs to be made to work the other way around too, so the dead str{,n}cpy calls i

Re: Add st[pr]ncpy to stmt_kills_ref_p

2017-04-30 Thread Marc Glisse
On Sun, 30 Apr 2017, Martin Sebor wrote: On 04/29/2017 01:17 AM, Marc Glisse wrote: Hello, this patch seems rather trivial, once one knows that those functions always write exactly n characters (they fill with 0 as needed at the end). Nice! Now it just needs to be made to work the other way

Re: Who broke options.h?

2017-04-30 Thread Jakub Jelinek
On Sun, Apr 30, 2017 at 07:49:45PM +0200, Gerald Pfeifer wrote: > On Tue, 25 Apr 2017, Jakub Jelinek wrote: > > Committed to trunk, 7.x will need to wait until 7.1 is released, > > the rc1 is already in the works and this isn't anything new, I > > see the same thing already in GCC 4.0. > > Thank

Re: [PATCH] adding missing LTO to some warning options (PR 78606)

2017-04-30 Thread Tom de Vries
On 01/10/2017 11:16 PM, Martin Sebor wrote: + __builtin_sprintf (d, "%32s", "x"); /* { dg-warning "directive writing 32 bytes into a region of size 12" "-Wformat-length" { xfail *-*-* } } */ This xpasses for me on an older system: ... XPASS: gcc.dg/pr78768.c -Wformat-overflow (test for warn

Re: [PATCH] warn on mem calls modifying objects of non-trivial types (PR 80560)

2017-04-30 Thread Pedro Alves
Hi Martin, Thanks much for doing this. A few comments below, in light of my experience doing the equivalent checks in the gdb patch linked below, using standard C++11. On 04/29/2017 09:09 PM, Martin Sebor wrote: > Calling memset, memcpy, or similar to write to an object of > a non-trivial type (

Re: [PATCH] RISC-V: Don't built 64-bit multilibs on 32-bit targets

2017-04-30 Thread Joseph Myers
On Sat, 29 Apr 2017, Richard Biener wrote: > On April 29, 2017 3:59:27 AM GMT+02:00, Palmer Dabbelt > wrote: > >We've been telling people that "riscv32-*" and "riscv64-*" are exactly > >the same toolchain aside from defaults for "-march" and "-mabi", but it > >appears we were lying. As far as I

Re: [PATCH] warn on mem calls modifying objects of non-trivial types (PR 80560)

2017-04-30 Thread Joseph Myers
On Sat, 29 Apr 2017, Martin Sebor wrote: > +The safe way to either initialize or "reset" objects of non-trivial Should use TeX quotes in Texinfo files, ``reset''. -- Joseph S. Myers jos...@codesourcery.com

Re: [PATCH] RISC-V: Don't built 64-bit multilibs on 32-bit targets

2017-04-30 Thread Palmer Dabbelt
On Sun, 30 Apr 2017 16:38:35 PDT (-0700), jos...@codesourcery.com wrote: > On Sat, 29 Apr 2017, Richard Biener wrote: >> On April 29, 2017 3:59:27 AM GMT+02:00, Palmer Dabbelt >> wrote: >> >We've been telling people that "riscv32-*" and "riscv64-*" are exactly >> >the same toolchain aside from de