This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: PATCH COMMITTED: Don't break tests for enum in range
- From: kenner at vlsi1 dot ultra dot nyu dot edu (Richard Kenner)
- To: richard dot guenther at gmail dot com
- Cc: ebotcazou at adacore dot com, gcc at gcc dot gnu dot org, iant at google dot com
- Date: Thu, 07 Jun 2007 14:39:43 EDT
- Subject: Re: PATCH COMMITTED: Don't break tests for enum in range
- References: <m38xax41qf.fsf@localhost.localdomain> <200706062015.10039.ebotcazou@adacore.com> <m3tztkztmt.fsf@localhost.localdomain> <200706071215.25222.ebotcazou@adacore.com> <m3fy53yi0b.fsf@localhost.localdomain> <10706071504.AA05478@vlsi1.ultra.nyu.edu> <84fc9c000706070843y2a8d6c73g7d8b8980ef7337e2@mail.gmail.com>
> So, the most obvious answer to these points is that arithmetic is
> always performed in a type where TYPE_MIN/MAX_VALUE is
> naturally defined and so we can rely on two's complement arithmetic.
Right. In the Ada case, that's required by the language anyway.
> The question that is retained is, when we expose types with non-natural
> TYPE_MIN/MAX_VALUE to the middle-end, how do we handle
> conversions between the "base" and the "derived" type. Is it
> value-preserving, even if the value is outside of the "derived" types
> bounds? If not, how is it "truncated"?
I think it goes to the same question as before, which is what's meant if
the value is out of range. The answer to that question (which I tried to
propose a solution to in my last email) is the answer to this one, the
way I see it.