* regarding type promotion
@ 2008-08-19 8:38 Sivaprasad.pv
2008-08-19 13:24 ` Andrew Haley
` (2 more replies)
0 siblings, 3 replies; 10+ messages in thread
From: Sivaprasad.pv @ 2008-08-19 8:38 UTC (permalink / raw)
To: gcc
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
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: regarding type promotion
2008-08-19 8:38 regarding type promotion Sivaprasad.pv
@ 2008-08-19 13:24 ` Andrew Haley
2008-08-19 15:35 ` Eljay Love-Jensen
2008-08-19 16:33 ` Bob Plantz
2 siblings, 0 replies; 10+ messages in thread
From: Andrew Haley @ 2008-08-19 13:24 UTC (permalink / raw)
To: Sivaprasad.pv; +Cc: gcc
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.
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: regarding type promotion
2008-08-19 8:38 regarding type promotion Sivaprasad.pv
2008-08-19 13:24 ` Andrew Haley
@ 2008-08-19 15:35 ` Eljay Love-Jensen
2008-08-19 16:33 ` Bob Plantz
2 siblings, 0 replies; 10+ messages in thread
From: Eljay Love-Jensen @ 2008-08-19 15:35 UTC (permalink / raw)
To: Sivaprasad.pv, GCC-help
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
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: regarding type promotion
2008-08-19 8:38 regarding type promotion Sivaprasad.pv
2008-08-19 13:24 ` Andrew Haley
2008-08-19 15:35 ` Eljay Love-Jensen
@ 2008-08-19 16:33 ` Bob Plantz
2008-08-19 16:34 ` Richard Harvey Chapman
2008-08-19 16:45 ` Richard Harvey Chapman
2 siblings, 2 replies; 10+ messages in thread
From: Bob Plantz @ 2008-08-19 16:33 UTC (permalink / raw)
To: Sivaprasad.pv; +Cc: gcc
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
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: regarding type promotion
2008-08-19 16:33 ` Bob Plantz
@ 2008-08-19 16:34 ` Richard Harvey Chapman
2008-08-19 17:02 ` Ian Lance Taylor
2008-08-19 16:45 ` Richard Harvey Chapman
1 sibling, 1 reply; 10+ messages in thread
From: Richard Harvey Chapman @ 2008-08-19 16:34 UTC (permalink / raw)
To: gcc
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
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: regarding type promotion
2008-08-19 16:34 ` Richard Harvey Chapman
@ 2008-08-19 17:02 ` Ian Lance Taylor
2008-08-19 22:07 ` Richard Harvey Chapman
2008-08-19 22:36 ` Richard Harvey Chapman
0 siblings, 2 replies; 10+ messages in thread
From: Ian Lance Taylor @ 2008-08-19 17:02 UTC (permalink / raw)
To: Richard Harvey Chapman; +Cc: gcc
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
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: regarding type promotion
2008-08-19 17:02 ` Ian Lance Taylor
@ 2008-08-19 22:07 ` Richard Harvey Chapman
2008-08-20 2:28 ` Ian Lance Taylor
2008-08-19 22:36 ` Richard Harvey Chapman
1 sibling, 1 reply; 10+ messages in thread
From: Richard Harvey Chapman @ 2008-08-19 22:07 UTC (permalink / raw)
To: gcc
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:~$
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: regarding type promotion
2008-08-19 17:02 ` Ian Lance Taylor
2008-08-19 22:07 ` Richard Harvey Chapman
@ 2008-08-19 22:36 ` Richard Harvey Chapman
1 sibling, 0 replies; 10+ messages in thread
From: Richard Harvey Chapman @ 2008-08-19 22:36 UTC (permalink / raw)
To: gcc
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);
}
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: regarding type promotion
2008-08-19 16:33 ` Bob Plantz
2008-08-19 16:34 ` Richard Harvey Chapman
@ 2008-08-19 16:45 ` Richard Harvey Chapman
1 sibling, 0 replies; 10+ messages in thread
From: Richard Harvey Chapman @ 2008-08-19 16:45 UTC (permalink / raw)
To: gcc
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
^ permalink raw reply [flat|nested] 10+ messages in thread
end of thread, other threads:[~2008-08-19 23:54 UTC | newest]
Thread overview: 10+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2008-08-19 8:38 regarding type promotion Sivaprasad.pv
2008-08-19 13:24 ` Andrew Haley
2008-08-19 15:35 ` Eljay Love-Jensen
2008-08-19 16:33 ` Bob Plantz
2008-08-19 16:34 ` Richard Harvey Chapman
2008-08-19 17:02 ` Ian Lance Taylor
2008-08-19 22:07 ` Richard Harvey Chapman
2008-08-20 2:28 ` Ian Lance Taylor
2008-08-19 22:36 ` Richard Harvey Chapman
2008-08-19 16:45 ` Richard Harvey Chapman
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).