Re: GCC 3.0 Status Report

["John David Anglin" <dave@hiauly1.hia.nrc.ca>]

> >>>>> "John" == John David Anglin <dave@hiauly1.hia.nrc.ca> writes:
> 
> First, note that Vax Ultrix is not a primary platform the release, so
> these patches are not a high priority for me.
> 
>     John> http://gcc.gnu.org/ml/gcc-patches/2001-04/msg00762.html

I understand your priorities but as I noted this problem affects all
ports.  Hey, next time I will provide an analysis on the i386!  What
I am saying is that you have to be careful in ignoring problems on
low priority targets because they may well affect the high priority
ones as well.

> I would prefer a patch that simply did something like:
> 
>   minnode = build_int_2 (TREE_INT_CST_LOW (minnode),
>                          TREE_INT_CST_HIGH (minnode));
>   if (unsignedp)
>     TREE_TYPE (minnode) = unsigned_type_node;
> 
> I think the hack where you adjust things according to the signedness
> at the end is confusing.

The sign adjustment at the end is a bit of a hack but it was a compromise
which allows just one pass through the values as before, and an overall
simplification of the code.

I don't believe your suggestion works directly because minnode has
has the signedness of enumtype after the loop.  The testing for signed
values could be put into the loop as in my patch.

I liked the idea of using the actual type and precision specified in
the original values for the minimum precision estimation, rather than
copying the min and max nodes after the loop and resetting their type
and precision.  Doing the precision calculation in the loop is probably
less complicated than the comparisons needed to determine the min and
max values in the list.

Dave
-- 
J. David Anglin                                  dave.anglin@nrc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6605)