[Bug c++/56908] New: Spurious warning when XOR-ing uint8_t values
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56908
Bug #: 56908
Summary: Spurious warning when XOR-ing uint8_t values
Classification: Unclassified
Product: gcc
Version: 4.7.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: hnik...@gmail.com
g++ -Wconversion displays what I believe is a spurious warning in my code:
warning: conversion to 'uint8_t {aka unsigned char}' from 'int' may alter its
value [-Wconversion]
-Wconversion is mandated by the project I'm working on. Since I'm striving for
warningless compilation, I looked into the function. Even after a careful
examination, I cannot find fault with it, nor an obvious way to get rid of the
warning without compromising the code's readability. The minimal example that
warns is:
#include stdint.h
#include stddef.h
void
xorblock(uint8_t* dest, const uint8_t* src, size_t len)
{
while (len--)
*dest++ ^= *src++;
}
Compiled with g++ -Wconversion a.cc, it prints the warning as:
a.cc: In function 'void xorblock(uint8_t*, const uint8_t*, size_t)':
a.cc:8:20: warning: conversion to 'uint8_t {aka unsigned char}' from 'int' may
alter its value [-Wconversion]
Both operands have the same type, which is appropriate for the calculation.
Casting the right-hand side of the compound assignment to either int, uint8_t,
or unsigned int fails to silence the warning. The warning does not occur with
gcc, only with g++.
The only way I found to remove the warning is to rewrite the assignment as a
non-compound assignment. But this precludes the use of the post-increment
operator and consequently makes the function harder to follow. (In this case
shorter is more readable, as *dest++ = *src++ is one of the most widely
understood C idioms.)
The warning happens with g++ 4.7 and 4.8, but not with g++ 4.6 series.
[Bug c++/39018] New: Cannot take address of template function
The following code fails to compile under g++ 4.3.2:
class Bar {};
templateint N
class Foo {
double val[N];
};
templateint N
void fun(FooN* ptr) {
}
typedef void (*T)(Bar*);
T funptr = (T) fun2;
The error message is:
$ g++ -c a.cc
a.cc:14: error: address of overloaded function with no contextual type
information
I don't know if the standard allows this, but it looks like it should be
allowed to take the address of a templated function, because it works in other
contexts (see below). It seems unambiguous because with foo2 we a specific
variant of the function is requested. Intel's C++ compiler (icpc versions 9.1
and 10.1) accepts it.
It is possible to work around this error by providing contextual type
information, although how to do that is not immediately obvious to everyone.
The workaround that worked for me is to replace the last line with:
typedef void (*U)(Foo2*);
T funptr = (T) (U) fun2;
which compiles without errors or warnings.
The error is similar to bug 29143, but I don't think it's a dup. In that case,
the contextual type information is present, but apparently ignored by the
compiler. In this case, context doesn't help with type determination, but it
shouldn't be necessary since foo2 uniquely identifies the function.
Detailed version information:
$ g++ -v
Using built-in specs.
Target: i486-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu 4.3.2-1ubuntu11'
--with-bugurl=file:///usr/share/doc/gcc-4.3/README.Bugs
--enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr --enable-shared
--with-system-zlib --libexecdir=/usr/lib --without-included-gettext
--enable-threads=posix --enable-nls --with-gxx-include-dir=/usr/include/c++/4.3
--program-suffix=-4.3 --enable-clocale=gnu --enable-libstdcxx-debug
--enable-objc-gc --enable-mpfr --enable-targets=all --enable-checking=release
--build=i486-linux-gnu --host=i486-linux-gnu --target=i486-linux-gnu
Thread model: posix
gcc version 4.3.2 (Ubuntu 4.3.2-1ubuntu11)
--
Summary: Cannot take address of template function
Product: gcc
Version: 4.3.2
Status: UNCONFIRMED
Severity: minor
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: hniksic at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39018
