Re: gcc 4.3.0, -Wconversion: assignment-by operators for shorter types
on 27/05/2008 13:50 Manuel López-Ibáñez said the following:
Please, open a bug report: http://gcc.gnu.org/bugzilla/
Manuel,
I looked through open GCC bugs and it seems that the following bugs are
very similar to what I report:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34389
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32643
Should I still open a new one or maybe it's better to follow up on one
of those two.
And just in case, here's a better description of what I am reporting
(demonstration by comparison):
**
int main()
{
int int_x;
int int_y;
short short_x;
short short_y;
short_x += short_y;
short_x = short_x + short_y;
int_x += int_y;
int_x = int_x + int_y;
return 0;
}
**
$ g++ -Wconversion test-conv.cc -o test-conv
test-conv.cc: In function ‘int main()’:
test-conv.cc:8: warning: conversion to ‘short int’ from ‘int’ may alter
its value
test-conv.cc:9: warning: conversion to ‘short int’ from ‘int’ may alter
its value
$ g++ -dumpversion
4.3.0
2008/5/26 Andriy Gapon <[EMAIL PROTECTED]>:
If I write something like the following:
uint8_t x;
uint8_t y;
x ^= y;
and compile with gcc 4.3.0 with -Wconversion option, then I get the
following warning:
warning: conversion to 'unsigned char' from 'int' may alter its value
[-Wconversion]
While technically this warning is correct (because x and y are
implicitly advanced to "int"before actual xor operation), it seems that
it doesn't make much practical sense.
I think that this applies to all "assignment-by" operators working on
types shorter than int.
OTOH, proper implementation should be smart enough to warn about the
following:
uint8_t x;
uint16_t y;
x ^= y;
--
Andriy Gapon
--
Andriy Gapon
Re: gcc 4.3.0, -Wconversion: assignment-by operators for shorter types
on 27/05/2008 21:48 Andrew Pinski said the following: On Tue, May 27, 2008 at 11:29 AM, Andriy Gapon <[EMAIL PROTECTED]> wrote: Should I still open a new one or maybe it's better to follow up on one of those two. And just in case, here's a better description of what I am reporting (demonstration by comparison): The warnings with the below code is correct because of how C/C++ define promotions. It is ^/|/& where the warnings are not correct and should be solved. Thank you for the explanation! I didn't realize the difference. OTOH, do you think that those arithmetic warnings are practical (as opposed to being correct)? I understand the rules of the language(s) but honestly I expect the same behavior for short and for int in expressions like those. And in cases where I don't expect it I'll be careful about result type anyway. -- Andriy Gapon
Re: gcc 4.3.0, -Wconversion: assignment-by operators for shorter types
on 27/05/2008 22:00 Andrew Pinski said the following:
On Tue, May 27, 2008 at 11:56 AM, Andriy Gapon <[EMAIL PROTECTED]> wrote:
Thank you for the explanation! I didn't realize the difference.
OTOH, do you think that those arithmetic warnings are practical (as opposed
to being correct)?
I think so as the short int case has a defined overflow of the signed
short type that is SHRT_MAX + 1 is defined while INT_MAX + 1 is not.
I still feel like disagreeing.
Consider this:
*
int main()
{
short short_x;
short_x = short_x + 1;
short_x += 1;
short_x++;
++short_x;
return 0;
}
*
$ gcc43 -Wconversion test-conv2.c -o test-conv
test-conv2.cc: In function 'int main()':
test-conv2.cc:5: warning: conversion to 'short int' from 'int' may alter
its value
test-conv2.cc:6: warning: conversion to 'short int' from 'int' may alter
its value
I thought that in C all 4 forms were equivalent and this was purely a
style choice. Now they are different.
--
Andriy Gapon
gcc 4.3.0, -Wconversion against -O1
There is a very simple function:
/ func.c **/
#include
uint16_t my_htons(uint16_t hostshort)
{
return htons(hostshort);
}
/**/
$ cc func.c -Wconversion -Werror -c -o func.o
Exit 0
$ cc func.c -O1 -Wconversion -Werror -c -o func.o
cc1: warnings being treated as errors
func.c: In function ‘my_htons’:
func.c:5: error: conversion to ‘short unsigned int’ from ‘int’ may alter
its value
Exit 1
Adding -E flag I get the following code:
...
# 2 "func.c" 2
uint16_t my_htons(uint16_t hostshort)
{
return (__extension__ ({ register unsigned short int __v, __x =
(hostshort); if (__builtin_constant_p (__x)) __v = __x) >> 8) &
0xff) | (((__x) & 0xff) << 8)); else __asm__ ("rorw $8, %w0" : "=r"
(__v) : "0" (__x) : "cc"); __v; }));
}
Is there anything (smart) that either I or gcc or glibc/linux can do
about this?
No type-casts in *my* code help.
The warning seems to be uncalled for in this case, because I don't see
explicit 'int' type anywhere in the expanded code.
P.S. the code seems to be coming from /usr/include/bits/byteswap.h,
__bswap_16() macro in this way:
=== netinet/in.h ===
#ifdef __OPTIMIZE__
/* We can optimize calls to the conversion functions. Either nothing has
to be done or we are using directly the byte-swapping functions which
often can be inlined. */
# if __BYTE_ORDER == __BIG_ENDIAN
/* The host byte order is the same as network byte order,
so these functions are all just identity. */
# define ntohl(x) (x)
# define ntohs(x) (x)
# define htonl(x) (x)
# define htons(x) (x)
# else
# if __BYTE_ORDER == __LITTLE_ENDIAN
# define ntohl(x) __bswap_32 (x)
# define ntohs(x) __bswap_16 (x)
# define htonl(x) __bswap_32 (x)
# define htons(x) __bswap_16 (x)
# endif
# endif
#endif
--
Andriy Gapon
gcc 4.3.0, -Wconversion and conditional operator
void f(int x)
{
char c = x ? '|' : '/';
}
$ cc1: warnings being treated as errors
char.c: In function 'f':
char.c:3: error: conversion to 'char' from 'int' may alter its value
Exit 1
If I replace 'x' with a constant (0 or 1) in the condition, then the
code compiles.
I think gcc should be smarter here.
--
Andriy Gapon
