On 2017.01.27 at 08:45 -0700, Martin Sebor wrote: > On 01/27/2017 12:44 AM, Markus Trippelsdorf wrote: > > On 2017.01.22 at 16:53 -0700, Martin Sebor wrote: > > > This is the last patch in the series. It adds logic to handle > > > non-constant width and precision with range information to help > > > reduce both false positives false negatives. The patch replaces > > > the scalar width and precision with two element arrays throughout > > > the pass and makes adjustments to reflect their bounds in the byte > > > counters. Since the basic infrastructure for this is present in > > > the code the changes are fairly mechanical. > > > > > commit c0a1f67fedb531abaf4760e8cd5b9b037ef5d4c4 > > > Author: Martin Sebor <mse...@redhat.com> > > > Date: Sun Jan 22 12:37:33 2017 -0700 > > > > > > 2017-01-22 Martin Sebor <mse...@redhat.com> > > > > > > * gimple-ssa-sprintf.c (adjust_for_width_or_precision): Change > > > to accept adjustment as an array. > > > (get_int_range): New function. > > > (struct directive): Make width and prec arrays. > > > (directive::set_width, directive::set_precision): Call > > > get_int_range. > > > (format_integer, format_floating): Handle width and precision > > > ranges. > > > (format_string, parse_directive): Same. > > > > This is the third time that you broke bootstrap with MPFR 2.x.x: > > > > > > > gcc/gimple-ssa-sprintf.c:1501: error: 'MPFR_RNDN' was not declared in this > > scope > > > > Please be more careful in the future. > > I'm sorry, but I'm not sure how to be more careful here. I can > realistically only build and test with one version of MPFR. I > proposed a solution to this problem in the past: to download > the oldest supported version of it and the other dependencies: > > https://gcc.gnu.org/ml/gcc-patches/2016-09/msg01596.html > > That was rejected by those who think GCC should target the latest, > which is what I have been doing. So I suggested an alternative > solution in response to your last message about this problem: > > https://gcc.gnu.org/ml/gcc-patches/2017-01/msg01886.html > > I haven't had a chance to implement it yet. You are welcome to > contribute a patch in the meantime to help forestall any further > accidental breakage.
Fortunately this was already done by Jakub's r244966. "MPFR_RNDN MPFR_RNDZ MPFR_RNDU MPFR_RNDD" are now "poisoned", so the issue cannot happen again. -- Markus
