This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [RFC] Fix PR 43574


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.

Richard.

> ? ? ? ?Jakub
>


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]