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_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
    parsing/diagnostic generation.

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.


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