[Bug c++/38759] New: Incorrect warning/error when compiling with a typedef'ed ptr return type
When a pointer to type is typedef'ed to a new type gcc incorrectly warns about
const modifier if new typedef is used in function return type.
gcc info:
dluadrianc:/home/adrianc> gcc -v
Using built-in specs.
Target: i686-pc-linux-gnu
Configured with: ../gcc-4.3.1/configure --prefix=/usr --enable-languages=c,c++
--enable-shared --enable-threads=posix
Thread model: posix
gcc version 4.3.1 (GCC)
Command line:g++ -save-temps -Wall -ansi -Wextra -pedantic -Werror const.cc
Error message:
cc1plus: warnings being treated as errors
const.cc:10: error: type qualifiers ignored on function return type
Code
# 1 "const.cc"
# 1 ""
# 1 ""
# 1 "const.cc"
class Foo { };
const Foo *func1()
{
return 0;
}
typedef Foo* Bar;
const Bar func2()
{
return 0;
}
int main(int , char *[])
{
func1();
func2();
return 0;
}
--
Summary: Incorrect warning/error when compiling with a typedef'ed
ptr return type
Product: gcc
Version: 4.3.1
Status: UNCONFIRMED
Severity: minor
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: gnu at bluedreamer dot com
GCC build triplet: i686-pc-linux-gnu
GCC host triplet: i686-pc-linux-gnu
GCC target triplet: i686-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38759
[Bug c++/32730] New: std::string.find(x, std::string::npos) searchs from begining of string
string.find returns results when it should not:
x=4294967295 Found:a test
x=4294967294 Found:a test
x=4294967293 Found:a test
x=4294967292 Not found
x=4294967291 Not found
x=4294967290 Not found
x=4294967289 Not found
x=4294967288 Not found
x=4294967287 Not found
x=4294967286 Not found
Also happens on gcc4.1.2 FreeBSD gcc2.95.2 Unixware 7.1 and gcc4.1.1 Linux 64
[~]$ g++ -v --save-temps -Wall -ansi -pedantic str3.cpp
Using built-in specs.
Target: i386-redhat-linux
Configured with: ../configure --prefix=/usr --mandir=/usr/share/man
--infodir=/usr/share/info --enable-shared --enable-threads=posix
--enable-checking=release --with-system-zlib --enable-__cxa_atexit
--disable-libunwind-exceptions --enable-libgcj-multifile
--enable-languages=c,c++,objc,obj-c++,java,fortran,ada --enable-java-awt=gtk
--disable-dssi --enable-plugin
--with-java-home=/usr/lib/jvm/java-1.4.2-gcj-1.4.2.0/jre --with-cpu=generic
--host=i386-redhat-linux
Thread model: posix
gcc version 4.1.1 20070105 (Red Hat 4.1.1-52)
/usr/libexec/gcc/i386-redhat-linux/4.1.1/cc1plus -E -quiet -v -D_GNU_SOURCE
str3.cpp -mtune=generic -ansi -Wall -pedantic -fpch-preprocess -o str3.ii
ignoring nonexistent directory
"/usr/lib/gcc/i386-redhat-linux/4.1.1/../../../../i386-redhat-linux/include"
#include "..." search starts here:
#include <...> search starts here:
/usr/lib/gcc/i386-redhat-linux/4.1.1/../../../../include/c++/4.1.1
/usr/lib/gcc/i386-redhat-linux/4.1.1/../../../../include/c++/4.1.1/i386-redhat-linux
/usr/lib/gcc/i386-redhat-linux/4.1.1/../../../../include/c++/4.1.1/backward
/usr/local/include
/usr/lib/gcc/i386-redhat-linux/4.1.1/include
/usr/include
End of search list.
/usr/libexec/gcc/i386-redhat-linux/4.1.1/cc1plus -fpreprocessed str3.ii -quiet
-dumpbase str3.cpp -mtune=generic -ansi -auxbase str3 -Wall -pedantic -ansi
-version -o str3.s
GNU C++ version 4.1.1 20070105 (Red Hat 4.1.1-52) (i386-redhat-linux)
compiled by GNU C version 4.1.1 20070105 (Red Hat 4.1.1-52).
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: aa6f91b930c2d3bef702d56afc079b20
as -V -Qy -o str3.o str3.s
GNU assembler version 2.17.50.0.6-2.el5 (i386-redhat-linux) using BFD version
2.17.50.0.6-2.el5 20061020
/usr/libexec/gcc/i386-redhat-linux/4.1.1/collect2 --eh-frame-hdr -m elf_i386
--hash-style=gnu -dynamic-linker /lib/ld-linux.so.2
/usr/lib/gcc/i386-redhat-linux/4.1.1/../../../crt1.o
/usr/lib/gcc/i386-redhat-linux/4.1.1/../../../crti.o
/usr/lib/gcc/i386-redhat-linux/4.1.1/crtbegin.o
-L/usr/lib/gcc/i386-redhat-linux/4.1.1 -L/usr/lib/gcc/i386-redhat-linux/4.1.1
-L/usr/lib/gcc/i386-redhat-linux/4.1.1/../../.. str3.o -lstdc++ -lm -lgcc_s
-lgcc -lc -lgcc_s -lgcc /usr/lib/gcc/i386-redhat-linux/4.1.1/crtend.o
/usr/lib/gcc/i386-redhat-linux/4.1.1/../../../crtn.o
#include
#include
#include
int main(int argc, char *argv[])
{
std::string a("this is a test");
std::string b("a t");
for(unsigned long x=ULONG_MAX; x>ULONG_MAX-10; --x)
{
std::string::size_type y=a.find(b, x);
if(y==std::string::npos)
{
std::cout << "x=" << x << " Not found\n";
}
else
{
std::cout << "x=" << x << " Found:" << a.substr(y) << std::endl;
}
}
return 0;
}
--
Summary: std::string.find(x, std::string::npos) searchs from
begining of string
Product: gcc
Version: 4.1.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: gnu at bluedreamer dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32730
[Bug c++/32730] std::string.find(x, std::string::npos) searchs from begining of string
--- Comment #1 from gnu at bluedreamer dot com 2007-07-11 18:10 --- Created an attachment (id=13887) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13887&action=view) Source file Example source that causes bug -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32730
[Bug c++/32730] std::string.find(x, std::string::npos) searchs from begining of string
--- Comment #2 from gnu at bluedreamer dot com 2007-07-11 18:11 --- Created an attachment (id=13888) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13888&action=view) >From --save-temps -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32730
[Bug c++/32730] std::string.find(x, std::string::npos) searchs from begining of string
--- Comment #3 from gnu at bluedreamer dot com 2007-07-11 18:11 --- Created an attachment (id=13889) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13889&action=view) >From --save-temps -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32730
[Bug c++/44611] New: Including and hides ::signbit function
When both of these files are included - compiler cannot locate c global signbit
function.
adri...@dluadrianc:~/gcc_bug> g++ signbit.cc
signbit.cc: In function 'int main(int, char**)':
signbit.cc:18:42: error: 'signbit' was not declared in this scope
#include
#include
#include
int main(int argc, char *argv[])
{
float a=12.4234;
float b=-123.4333;
#ifdef _XOPEN_SOURCE
std::cout << "_XOPEN_SOURCE=" << _XOPEN_SOURCE << std::endl;
#endif
#ifdef _ISOC99_SOURCE
std::cout << "_ISOC99_SOURCE is here\n";
#endif
std::cout << "signbit a=" << signbit(a) << std::endl;
std::cout << "signbit b=" << signbit(b) << std::endl;
return 0;
}
adri...@dluadrianc:~/gcc_bug> gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/local/libexec/gcc/i686-pc-linux-gnu/4.5.0/lto-wrapper
Target: i686-pc-linux-gnu
Configured with: ../gcc-4.5.0/configure --enable-__cxa_atexit
--enable-languages=c,c++ --enable-threads --with-cpu=core2 --disable-nls
--with-arch=i686 --with-mpfr=/usr/local --with-gmp=/usr/local
--with-mpc=/usr/local --with-build-time-tools=/usr/local --enable-lto
Thread model: posix
gcc version 4.5.0 (GCC)
--
Summary: Including and hides ::signbit function
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: minor
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: gnu at bluedreamer dot com
GCC build triplet: i686-pc-linux-gnu
GCC host triplet: i686-pc-linux-gnu
GCC target triplet: i686-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44611
[Bug c++/44611] Including and hides ::signbit function
--- Comment #1 from gnu at bluedreamer dot com 2010-06-21 14:31 --- Created an attachment (id=20963) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20963&action=view) Source file -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44611
[Bug c++/44611] Including and hides ::signbit function
--- Comment #2 from gnu at bluedreamer dot com 2010-06-21 14:31 --- Created an attachment (id=20964) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20964&action=view) --save-temps output .ii file -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44611
[Bug c++/44611] Including and hides ::signbit function
--- Comment #3 from gnu at bluedreamer dot com 2010-06-21 14:32 --- Created an attachment (id=20965) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20965&action=view) --save-temps output .s file -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44611
[Bug c++/44611] Including and hides ::signbit function
--- Comment #9 from gnu at bluedreamer dot com 2010-06-21 16:07 --- > I agree the macro and template can't co-exist, but the template could be > available as both std::signbit and ::signbit, and I think that's required by > appendix D. Are these still relevant for c++0x? More so section 5 which says if they are macros in C they must be macros in C++ 17.4.1.2 Headers 4. Except as noted in clauses 18 through 27, the contents of each header cname shall be the same as that of the corresponding header name.h, as specified in ISO/IEC 9899:1990 Programming Languages C (Clause 7), or ISO/IEC:1990 Programming LanguagesC AMENDMENT 1: C Integrity, (Clause 7), as appropriate, as if by inclusion. In the C++ Standard Library, however, the declarations and definitions (except for names which are defined as macros in C) are within namespace scope (3.3.5) of the namespace std. 5. Names which are defined as macros in C shall be defined as macros in the C++ Standard Library, even if C grants license for implementation as functions. [Note: the names defined as macros in C include the following: assert, errno, offsetof, setjmp, va_arg, va_end, and va_start. end note] -- gnu at bluedreamer dot com changed: What|Removed |Added Component|libstdc++ |c++ http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44611
[Bug c++/44611] Including and hides ::signbit function
--- Comment #11 from gnu at bluedreamer dot com 2010-06-21 16:20 --- (In reply to comment #10) > (In reply to comment #9) > > Are these still relevant for c++0x? More so section 5 which says if they are > > macros in C they must be macros in C++ > > see 26.8 [c.math] paragraph 11 Thanks. I should probably start using the draft rather then my dusty old 14882 copy. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44611
[Bug c++/44611] Including and hides ::signbit function
--- Comment #13 from gnu at bluedreamer dot com 2010-06-21 16:31 --- (In reply to comment #12) > Is there a reason you changed the component back to c++? > This is not a problem in the C++ compiler front-end. > I didn't mean to change anything. All I did was reply (maybe browser cached some post back values) My apologies - please change it to whatever it should be. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44611
