Re: [PATCH 5/5] add support for width and precision ranges (PR 78703)

[Markus Trippelsdorf <markus@trippelsdorf.de>]

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 <msebor@redhat.com>
> > > Date:   Sun Jan 22 12:37:33 2017 -0700
> > > 
> > >     2017-01-22  Martin Sebor  <msebor@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