[RFC] Fix PR 43574

[H.J. Lu]

On Tue, Mar 30, 2010 at 5:30 AM, Richard Guenther
<richard.guenther@gmail.com> wrote:
> On Tue, Mar 30, 2010 at 1:31 PM, Jakub Jelinek <jakub@redhat.com> wrote:
>> 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.
>
> Of course.  But I think we already avoid inlining functions with
> incompatible optimization attributes (but maybe I misremember
> that).  Other options in that category include those affecting
> semantics such as -fwrapv, -fno-strict-aliasing, -ffast-math ...
>
> Well.  I do not like the optimize attribute very much.
>

I don't like it either. Its design is flawed and its implementation is
incomplete. I think it should be disabled and start it over. I have
some ideas:

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37565


-- 
H.J.