[RFC] Fix PR 43574

[Jakub Jelinek]

On Tue, Mar 30, 2010 at 01:11:18PM +0100, Richard Guenther wrote:
> On Tue, Mar 30, 2010 at 1:05 PM, Jie Zhang <jie@codesourcery.com> wrote:
> > On 03/30/2010 06:10 PM, Richard Guenther wrote:
> >>
> >> On Tue, Mar 30, 2010 at 10:15 AM, Jie Zhang<jie@codesourcery.com> Â wrote:
> >>>
> >>> flag_var_tracking and flag_var_tracking_assignments can have negative
> >>> values. But the generated options.c asserts that their values must be in
> >>> range [0, 255]. This patch adds a new option property "Signed". So
> >>> options
> >>> like flag_var_tracking and flag_var_tracking_assignments can use this new
> >>> property to specify that they can take negative value. "signed char"
> >>> instead
> >>> of "unsigned char" will be used as the type for such options and their
> >>> values will be checked in range between [-128, 127]. No regressions are
> >>> found on x86_64 with this patch. Is it OK?
> >>
> >> Hm. Â I wonder if it would be simpler to avoid assigning negative values
> >> to flag_var_tracking_*. Â We shouldn't extend infrastructure just because
> >> of some "abuses" ...
> >>
> > So you think we should use 3 instead of -1 now? If so, we need to scan all
> > the uses of these two flags and take care of all > 0 conditionals.
> 
> Indeed.  But it still looks more correct.

Using -1 or -2 for flag defaults that needs to be settled up later is very
common, many flags use this, so I wouldn't call it any kind of abuse.

What is IMHO instead wrong is allowing flag_var_tracking_* to change with
the optimize attribute, either it should be set for the whole CU or not at
all.  Or at least drop DEBUG_STMTs when inlining into a function that
isn't to be compiled with flag_var_tracking_assignments.

	Jakub