From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 15802 invoked by alias); 26 Mar 2003 21:16:00 -0000 Mailing-List: contact gcc-prs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-prs-owner@gcc.gnu.org Received: (qmail 15783 invoked by uid 71); 26 Mar 2003 21:16:00 -0000 Date: Wed, 26 Mar 2003 21:16:00 -0000 Message-ID: <20030326211600.15782.qmail@sources.redhat.com> To: nobody@gcc.gnu.org Cc: gcc-prs@gcc.gnu.org, From: Michael Marks Subject: RE: c/10226: unsigned short promotion with bitwise inversion Reply-To: Michael Marks X-SW-Source: 2003-03/txt/msg01836.txt.bz2 List-Id: The following reply was made to PR c/10226; it has been noted by GNATS. From: Michael Marks To: 'Glen Nakamura' , gcc-gnats@gcc.gnu.org, "'falk.hueffner@student.uni-tuebingen.de'" Cc: Subject: RE: c/10226: unsigned short promotion with bitwise inversion Date: Wed, 26 Mar 2003 13:08:47 -0800 This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C2F3DB.E49BAC30 Content-Type: text/plain; charset="iso-8859-1" Thanks, I had worked around it before I sent the report in... In fact your suggestion is the workaround I chose. I logged it because it did not seem to be regular to promote two like sized variables, especially because a bitwise inversion will always cause the failure. Any clue as to why the spec reads that way... we speculated that it is for 32 bit optimizations, but did not come up with anything better than that. Thanks to all of you for the quick response. I think that the warning misleads because it says ~unsigned to unsigned... correctly should be short unsigned to int. At least I think so. From another response earlier.... ---- Actually I understood that the warning was tied to that error. I would suggest: warning : ~ operator caused promotion of unsigned short to int Interestingly: Sun CC passes and Microsoft Fails without warning. Michael. Apparently, you didn't understand the warning. The C standard mandates that "~A" will promote A to int first. So gcc is behaving correctly here. Any suggestions on how the wording of the message could be improved to be clearer? -- Falk -----Original Message----- From: Glen Nakamura [mailto:glen@imodulo.com] Sent: Wednesday, March 26, 2003 12:06 PM To: gcc-gnats@gcc.gnu.org; gcc-bugs@gcc.gnu.org; mmarks@internetmachines.com Subject: Re: c/10226: unsigned short promotion with bitwise inversion http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&database=gcc&p r=10226 > unsigned short A = 0xDEAD; > unsigned short B; > B = ~A; > if ( B == ~A) { > printf("Pass\n"); > } > else { > printf("Fail\n"); > } I'll leave the final decision to the language lawyers, but I don't think this is a bug in GCC. The ~ operator is subject to integer promotion, so with the implicit conversions the expression becomes: if ((int) B == ~((int) A)) which is indeed false in the example above. In fact, I see the following warning when compiling with -Wall (GCC 3.3): warning: comparison of promoted ~unsigned with unsigned Perhaps "if (B == (unsigned short) ~A)" will behave as you expect. - glen ------_=_NextPart_001_01C2F3DB.E49BAC30 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: c/10226: unsigned short promotion with bitwise = inversion

Thanks, I had worked around it before I sent the = report in...
In fact your suggestion is the workaround I = chose.
I logged it because it did not seem to be regular to = promote two like sized variables,
especially because a bitwise inversion will always = cause the failure.
Any clue as to why the spec reads that way... we = speculated that it is for
32 bit optimizations, but did not come up with = anything better than that.

Thanks to all of you for the quick response.  I = think that the warning misleads
because it says ~unsigned to unsigned... correctly = should be short unsigned to int.
At least I think so.

From another response earlier....
----

Actually I understood that the warning was tied to = that error.

I would suggest:
warning : ~ operator caused promotion of unsigned = short to int

Interestingly: Sun CC passes and Microsoft Fails = without warning.

Michael.

Apparently, you didn't understand the warning. The C = standard mandates
that "~A" will promote A to int first. So = gcc is behaving correctly
here. Any suggestions on how the wording of the = message could be
improved to be clearer?

--
        Falk

-----Original Message-----
From: Glen Nakamura [mailto:glen@imodulo.com]
Sent: Wednesday, March 26, 2003 12:06 PM
To: gcc-gnats@gcc.gnu.org; = gcc-bugs@gcc.gnu.org;
mmarks@internetmachines.com
Subject: Re: c/10226: unsigned short promotion with = bitwise inversion


http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=3Dview%20au= dit-trail&database=3Dgcc&pr=3D10226
> unsigned short A =3D 0xDEAD;
> unsigned short B;
> B =3D ~A;
> if ( B =3D=3D ~A) {
>    = printf("Pass\n");
> }
> else {
>    = printf("Fail\n");
> }

I'll leave the final decision to the language = lawyers, but I don't think
this is a bug in GCC.  The ~ operator is = subject to integer promotion,
so with the implicit conversions the expression = becomes:
  if ((int) B =3D=3D ~((int) A))
which is indeed false in the example above.

In fact, I see the following warning when compiling = with -Wall (GCC 3.3):
warning: comparison of promoted ~unsigned with = unsigned

Perhaps "if (B =3D=3D (unsigned short) ~A)" = will behave as you expect.

- glen

------_=_NextPart_001_01C2F3DB.E49BAC30--