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: [PATCH] PR19100: truthvalue_conversion vs. TREE_CONSTANT_OVERFLOW


On Tue, 21 Dec 2004, Mark Mitchell wrote:
> I have a broader question.  In C, where signed overflow is
> implementation-defined behavior, why don't we just define it to wrap, as
> with unsigned arithmetic, in the usual modulo-2 way.  And then not set
> TREE_CONSTANT_OVERFLOW at all?  What do we want with nodes that are
> zero, but marked as having overflowed?

The GCC middle-end currently has the global variable flag_wrapv which
is used by the language front-ends to specify their required behaviour
on overflow.  The gcj front-end sets this value to true, can the C/C++
family front-ends default to false but can specify it via -fwrapv.

I agree that it would be possible to use the setting of flag_wrapv to
instruct the middle-end not to track overflows during constant folding.
Which would certainly help Java, and would improve C/C++ if they decide
to switch over to "wrapv" as a default.

However, in the 4.1 timeframe, I believe that Joseph Myers is working
on a far more significant overhaul of "overflow" tracking which will
mean that we won't have to represent it in middle-end trees at all.


> > And in the Boolean comparison cases, we were destructively modifying
> > the tree in-place (which in the middle-end is generally considered a
> > bad thing).
>
> Have you measured the memory impact of this change?

Unfortunately not.  I don't have a good idea of which codes this change
might affect and whether its even possible to get it to be measurable.
However, I do know that the truthvalue_conversion langhook shouldn't be
modifying it's argument, which may potentially be shared (or read-only)
or the conversion discarded.

If you think this hunk is too controversial (even if you don't
doubt its correct :), I'm happy to retest and apply the rest of the
patch without it.  I just didn't want to let this correction get
lost or forgotten.

Roger
--


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