On Fri, Feb 03, 2017 at 10:02:48AM -0700, Martin Sebor wrote:
> On 02/03/2017 09:39 AM, Jakub Jelinek wrote:
> > On Fri, Feb 03, 2017 at 09:13:23AM -0700, Martin Sebor wrote:
> > > I'm not opposed to the changes, certainly not to cleaning things up,
> > > but I don't think now is the time to be making these tweaks. Jakub's
> > > patch is fine with me without those tweaks, and with the correction
> >
> > What do you mean by my patch without those tweaks?
> ...
> > I fear this isn't the last fix needed, the code is very complex and not
> > sufficiently covered by testcases, so if we don't want to make the code
> > more maintainable now, I'd be strongly for just turning
> > -fprintf-return-value off by default for the release. Bogus warnings
> > can be lived with or worked around, silent wrong-code is much worse.
>
> I mean without changes to the content of the notes. If you feel
> it important to simplify the code now that's okay with me.
I haven't changed anything in order to change the notes, that is just the
side-effect of arg{min,max} to always mean the range boundaries, and only
res. If you want to print what values the pass considered as shortest or
longest output, then it would need to remember (in other named fields)
those values that it picked and use suitable wording to tell those
values to the user. I think the ranges are very desirable to be printed
in any cases, and if further info is added, if it doesn't clutter the
message too much, why not.
> I'm not empowered to either approve or reject any changes so what
> say is obviously just my input into Jeff's decision. I also care
I'm not a maintainer of that part of GCC, so I can only wait for some
reviewer or maintainer too.
> a lot about this work so I'm not going to resist when faced with
> a threat of having it disabled. If leaving the optimization
> enabled is conditional on it then feel free to make whatever
> changes you see fit.
Leaving the optimization enabled by default should be dependent on
1) what value it brings 2) what are the risks (how much we can trust
it not to have other silent wrong-code issues lurking in).
That decision is of course again something some reviewer would need
to ack if I were to propose it, but with Fedora gcc package maintainer
hat on, that is an option I'm seriously considering at least for the
upcoming non-test mass rebuild, because we have at most days to resolve
stuff.
Jakub
