regarding type promotion

regarding type promotion

[Sivaprasad.pv]

Hi All,

If we consider following sample C language code :

long long int k=0x123;
int p=1;
k = k + p << 33;

Here the value in variable 'p' is shifted by 33 and then the result 
(only 32 bit result)was promoted to 64 bit.
Is it an expected behavior?
Is there any way to specify in gcc to perform implicit type promotion 
first and then perform operation on it (without explicit type casting).

Thanks,
Siva Prasad

Re: regarding type promotion

[Andrew Haley]

Sivaprasad.pv wrote:

> If we consider following sample C language code :
> 
> long long int k=0x123;
> int p=1;
> k = k + p << 33;
> 
> Here the value in variable 'p' is shifted by 33 and then the result
> (only 32 bit result)was promoted to 64 bit.
> Is it an expected behavior?

Yes.

> Is there any way to specify in gcc to perform implicit type promotion
> first and then perform operation on it (without explicit type casting).

I'm not sure exactly what you mean by "without explicit type casting",
but the correct way to write this is

   k = k + (long long)p << 33;

The promotion rules are part of the language standard.

Andrew.

Re: regarding type promotion

[Eljay Love-Jensen]

Hi Siva,

> If we consider following sample C language code :
> 
> long long int k=0x123;
> int p=1;
> k = k + p << 33;
> 
> Here the value in variable 'p' is shifted by 33 and then the result
> (only 32 bit result)was promoted to 64 bit.

Yes, that's correct.

((k) = ((k) + ((p) << (33))));

Using L to mark long long, and I to mark int, and @ to mark promotion:

L(L(k) = L(L(k) + L@(I(I(p) << I(33)))));

Also note that where int is 32-bit, doing a i << 33 is undefined behavior.
It could shift to zero.  It could leave the number as-is.  It could shift by
one.  It could... DESTROY THE UNIVERSE.  So be careful with that.

(If shifting a 32-bit int by 33 with GCC does destroy the universe, please
file a bug <http://gcc.gnu.org/bugs.html>.)

> Is it an expected behavior?

Yes.

> Is there any way to specify in gcc to perform implicit type promotion
> first and then perform operation on it (without explicit type casting).

Yes.

long long k=0x123; // <-- implicit promotion 0x123 --> 0x123LL
long long p=1; // <-- implicit promotion 1 --> 1LL
k = k + p << 33;

HTH,
--Eljay

Re: regarding type promotion

[Bob Plantz]

On Tue, 2008-08-19 at 10:30 +0530, Sivaprasad.pv wrote:

> Is there any way to specify in gcc to perform implicit type promotion 
> first and then perform operation on it (without explicit type casting).

I spent over three decades reading other people's code -- both in
industry and teaching. I always encouraged my students to use explicit
type casting, even when not needed, for it's self-documenting value.

Another rule I gave them is "multiplication and division have higher
precedence than addition and subtraction; use parentheses in all other
cases."

Both "rules of thumb" help the reader to see your intent and minimize
your chances of making a mistake.

Bob

Re: regarding type promotion

[Richard Harvey Chapman]

Bob Plantz wrote:
> Another rule I gave them is "multiplication and division have higher
> precedence than addition and subtraction; use parentheses in all other
> cases."
++

I used to always get tripped up in embedded code because "==" has 
precedence over "&" which I do not believe is intuitive to most people.

unsigned int value;
#define BITSET 0x1234

// Wrong: always true if value is odd since BITSET == BITSET is 
evaluated first
//        which reduces to "(value & 1)"
if (value & BITSET == BITSET) {} // Bits are set

// Right:
if ((value & BITSET) == BITSET) {} // Bits are set

Re: regarding type promotion

[Richard Harvey Chapman]

Bob Plantz wrote:
> Another rule I gave them is "multiplication and division have higher
> precedence than addition and subtraction; use parentheses in all other
> cases."
++

I used to always get tripped up in embedded code because "==" has
precedence over "&" which I do not believe is intuitive to most people.

unsigned int value;
#define BITSET 0x1234

// Wrong: always true if value is odd since BITSET == BITSET is
evaluated first
//        which reduces to "(value & 1)"
if (value & BITSET == BITSET) {} // Bits are set

// Right:
if ((value & BITSET) == BITSET) {} // Bits are set

Re: regarding type promotion

[Ian Lance Taylor]

Richard Harvey Chapman <hchapman@3gfp.com> writes:

> Bob Plantz wrote:
>> Another rule I gave them is "multiplication and division have higher
>> precedence than addition and subtraction; use parentheses in all other
>> cases."
> ++
>
> I used to always get tripped up in embedded code because "==" has
> precedence over "&" which I do not believe is intuitive to most
> people.

That's why gcc warns about it, with -Wparentheses, which is part of
-Wall.

Ian

Re: regarding type promotion

[Richard Harvey Chapman]

Ian Lance Taylor wrote:
> That's why gcc warns about it, with -Wparentheses, which is part of
> -Wall.
Interesting. I've never noticed that. I guess it is because g++ doesn't 
warn about it. Is this a bug in g++?

Thanks,

H.

hchapman@anthrax:~$ gcc --version
gcc (GCC) 4.1.2 20061115 (prerelease) (Debian 4.1.1-21)
Copyright (C) 2006 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

hchapman@anthrax:~$ gcc -Wall -o a a.c
a.c: In function "main":
a.c:9: warning: suggest parentheses around comparison in operand of &
hchapman@anthrax:~$ g++ -Wall -o a a.c
hchapman@anthrax:~$

Re: regarding type promotion

[Richard Harvey Chapman]

I should have included the program source.

H.


hchapman@anthrax:~$ cat a.c
#include <stdio.h>

int main()
{
  unsigned int value = 1;
#define BITSET 0x1234

  // Wrong: always true if value is odd since BITSET == BITSET is 
evaluated first
  if (value & BITSET == BITSET)
  {
    printf("One\n");
  }

  // Right:
  if ((value & BITSET) == BITSET)
  {
    printf("Two\n");
  }

  return(0);
}

Re: regarding type promotion

[Ian Lance Taylor]

Richard Harvey Chapman <hchapman@3gfp.com> writes:

> Ian Lance Taylor wrote:
>> That's why gcc warns about it, with -Wparentheses, which is part of
>> -Wall.
> Interesting. I've never noticed that. I guess it is because g++
> doesn't warn about it. Is this a bug in g++?

It was a bug, yes.  It was fixed in gcc 4.3.

Ian