From mboxrd@z Thu Jan 1 00:00:00 1970 From: "John David Anglin" To: mark@codesourcery.com (Mark Mitchell) Cc: gcc@gcc.gnu.org Subject: Re: GCC 3.0 Status Report Date: Wed, 18 Apr 2001 13:51:00 -0000 Message-id: <200104182051.QAA04782@hiauly1.hia.nrc.ca> References: <20010418005508T.mitchell@codesourcery.com> X-SW-Source: 2001-04/msg00889.html > >>>>> "John" == John David Anglin 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)