This is the mail archive of the
mailing list for the GCC project.
Re: [PATCH] PR19100: truthvalue_conversion vs. TREE_OVERFLOW (take 3)
- From: kenner at vlsi1 dot ultra dot nyu dot edu (Richard Kenner)
- To: roger at eyesopen dot com
- Cc: gcc-patches at gcc dot gnu dot org
- Date: Mon, 3 Jan 05 08:48:54 EST
- Subject: Re: [PATCH] PR19100: truthvalue_conversion vs. TREE_OVERFLOW (take 3)
The change is that the responsibility for setting this flag, if it's
required, has moved from the middle-end to the language front-ends,
initially only for integer-integer conversions. fold_convert no longer
sets this field, but each front-end's "convert" function may continue
to do so itself. Alternatively, the various language parsers can detect
such constant overflow at parse-time using int_fits_type_p instead,
and thereby avoid using TREE_CONSTANT_OVERFLOW entirely.
I'm not sure what "alternatively" means here. How else would overflow
be detected other than by using int_fits_type_p? And presumably this
is called for sizetype computations, right?
but my understanding is that the Ada front-end has its own more formal
notion of overflow, and doesn't use GCC's trees during
Partly. There is a requirement that static constants be computed exactly,
so there are done using an "infinite-precision" numeric library. However,
they are defined not to overflow since they are unbounded. When they are
converted to a normal type, the front end does the overflow check before
making GCC trees.
However, there are things that are constant for which the front end can't
know the value (e.g., sizes and positions in most composite types). In
that case the overflow is detected at run-time (but only when -gnato
is specified) or in constant folding, which is divided between the middle
end and front end and is the only case we need to worry about.