[Bug c++/33925] gcc -Waddress lost some useful warnings
--- Comment #3 from mec at google dot com 2009-07-31 16:04 --- Subject: Re: gcc -Waddress lost some useful warnings Yes, I think this is a bug, because the behavior of gcc doesn't match its documentation. First, I think the C++ standard forbids a function from having a null address: [conv.ptr] 4.10 -1- A null pointer constant is an integral constant expression (5.19) rvalue of integer type that evalutes to zero. A null pointer constant can be converted to a pointer type; the result is the null pointer value of that type and is distinguishable from every other value of pointer to object or pointer to function type. Even if you break this to allow for weak pointers to functions, the documentation for -Waddress says: http://gcc.gnu.org/onlinedocs/gcc-4.4.1/gcc/Warning-Options.html#Warning-Options "Warn about suspicious uses of memory addresses. These include the address of a function in a conditional expression such as void func(void); if (func) ... such uses typically indicate a programmer error: the address of a function always evaluates to true, so their use in a conditional usually indicate that the programmer forgot the parentheses in a function call ...". This documentation repeats the claim that "the address of a function is always true". More than that: "warnings are diagnostic messages that report constructions which are not inherently erroneous but which are risky or suggest there may have been an error". By enabling -Waddress, I believe the user intends to report all instances of "if (func)" with the expectation that most of them are mistaken versions of "if (func())" or "if (func(some_parameters ...))". If the user is building (non-standard) code where the addresses of some functions may be null and "if (func)" is likely the intended meaning, then they can decline to turn on -Waddress. If such code is common, you may want to re-think the inclusion of -Waddress in -Wall. As it is, -Waddress sometimes prints the message that it is documented to print, and sometimes does not. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33925
[Bug c++/35927] New: befriending a whole template in another namespace fails
In this program, Beta::Gamma declares ::Alpha as a friend, but the friendship
does not work.
===
[EMAIL PROTECTED]:~/exp-friend$ cat z1.cc
template
void Alpha(T* a) { a->Delta(); }
namespace Beta {
class Gamma {
public:
template friend void ::Alpha(T*);
private:
void Delta();
};
}
int main() {
Beta::Gamma* a = new Beta::Gamma;
::Alpha(a);
}
bash: /home/mec/gcc-4.2.1/install/bing++: No such file or directory
[EMAIL PROTECTED]:~/exp-friend$ /home/mec/gcc-4.2.1/install/bin/g++ -O2 -Wall -c
z1.cc
z1.cc: In function 'void Alpha(T*) [with T = Beta::Gamma]':
z1.cc:18: instantiated from here
z1.cc:11: error: 'void Beta::Gamma::Delta()' is private
z1.cc:2: error: within this context
[EMAIL PROTECTED]:~/exp-friend$ /home/mec/gcc-4.2.2/install/bin/g++ -O2 -Wall -c
z1.cc
z1.cc: In function 'void Alpha(T*) [with T = Beta::Gamma]':
z1.cc:18: instantiated from here
z1.cc:11: error: 'void Beta::Gamma::Delta()' is private
z1.cc:2: error: within this context
[EMAIL PROTECTED]:~/exp-friend$ /home/mec/gcc-4.3.0/install/bin/g++ -O2 -Wall -c
z1.cc
z1.cc: In function 'void Alpha(T*) [with T = Beta::Gamma]':
z1.cc:18: instantiated from here
z1.cc:11: error: 'void Beta::Gamma::Delta()' is private
z1.cc:2: error: within this context
[EMAIL PROTECTED]:~/exp-friend$
===
In this program, Beta::Gamma declares the specialization ::Alpha
as a friend. This works.
[EMAIL PROTECTED]:~/exp-friend$ cat z3.cc
template
void Alpha(T* a) { a->Delta(); }
namespace Beta {
class Gamma {
public:
friend void ::Alpha(Beta::Gamma*);
private:
void Delta();
};
}
int main() {
Beta::Gamma* a = new Beta::Gamma;
::Alpha(a);
}
[EMAIL PROTECTED]:~/exp-friend$ /home/mec/gcc-4.2.1/install/bin/g++ -O2 -Wall -c
z3.cc
[EMAIL PROTECTED]:~/exp-friend$ /home/mec/gcc-4.2.2/install/bin/g++ -O2 -Wall -c
z3.cc
[EMAIL PROTECTED]:~/exp-friend$ /home/mec/gcc-4.3.0/install/bin/g++ -O2 -Wall -c
z3.cc
[EMAIL PROTECTED]:~/exp-friend$
===
I think z1.cc is valid, per this clause from [temp.friend]:
"A template friend declaration specifies that all specializations of that
template, whether they are implicitly instantiated (14.7.1), partially
specialized (14.5.4) or explicitly specialized (14.7.3) are friends of the
class containing the template friend declaration.
I suspect it's a bug with the namespace part of "template friend
void ::Alpha(T*);".
--
Summary: befriending a whole template in another namespace fails
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: mec at google 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=35927
[Bug preprocessor/33143] preprocess should ignore trigraphs in /* */ comments
--- Comment #5 from mec at google dot com 2008-04-04 16:36 --- Doh! You are right, I was confused when I read "z1.cc:2:4" as an error on line 4. Both errors are in line 2, inside the #if block. Sorry for the noise. -- mec at google dot com changed: What|Removed |Added Status|WAITING |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33143
[Bug c++/33925] New: gcc -Waddress lost some useful warnings
gcc -Waddress got a little bit worse between gcc 4.0.4 and gcc 4.1.2. It would
be useful to get this warning, especially for C++ inline methods.
[EMAIL PROTECTED]:~/exp-address$ cat z2.cc
extern bool Alpha();
inline bool Beta(bool b) { return b; }
class MyClass { public: static bool MyMethod(bool b) { return b; } };
bool Gamma() {
if (Alpha) {
if (Beta) {
if (MyClass::MyMethod) {
return true;
}
}
}
return false;
}
[EMAIL PROTECTED]:~/exp-address$ /home/mec/gcc-4.0.4/install/bin/g++ -Wall -O2
-S
z2.cc
z2.cc: In function 'bool Gamma()':
z2.cc:6: warning: the address of 'bool Alpha()', will always evaluate as 'true'
z2.cc:7: warning: the address of 'bool Beta(bool)', will always evaluate as
'true'
z2.cc:8: warning: the address of 'static bool MyClass::MyMethod(bool)', will
always evaluate as 'true'
[EMAIL PROTECTED]:~/exp-address$ /home/mec/gcc-4.1.2/install/bin/g++ -Wall -O2
-S
z2.cc
z2.cc: In function 'bool Gamma()':
z2.cc:6: warning: the address of 'bool Alpha()', will always evaluate as 'true'
[EMAIL PROTECTED]:~/exp-address$ /home/mec/gcc-4.2.2/install/bin/g++ -Wall -O2
-S
z2.cc
z2.cc: In function 'bool Gamma()':
z2.cc:6: warning: the address of 'bool Alpha()' will always evaluate as 'true'
[EMAIL PROTECTED]:~/exp-address$ /home/mec/gcc-4.3-20071019/install/bin/g++
-Wall
-O2 -S z2.cc
z2.cc: In function 'bool Gamma()':
z2.cc:6: warning: the address of 'bool Alpha()' will always evaluate as 'true'
[EMAIL PROTECTED]:~/exp-address$
--
Summary: gcc -Waddress lost some useful warnings
Product: gcc
Version: 4.2.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: mec at google 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=33925
[Bug c++/33916] New: Default constructor fails to initialize array members
(This may be related to PR 30111 )
In this program, a default constructor fails to initialize the given array
members to zero. Results are shown with several versions of gcc.
===
#include
#include
namespace {
class Stats {
friend void alpha();
private:
int a_[12];
int b_[12];
};
void dirty_stack() {
char array[4096];
memset(array, 0x11, 4096);
}
void alpha() {
Stats my_stats = Stats();
for (int i = 0; i < 12; ++i) {
std::cout << my_stats.a_[i] << " ";
}
std::cout << std::endl;
}
}
int main() {
dirty_stack();
alpha();
return 0;
}
===
[EMAIL PROTECTED]:~/exp-array-default$ /home/mec/gcc-4.1.2/install/bin/g++
z3.cc &&
./a.out
0 0 0 0 0 0 0 0 0 0 0 0
[EMAIL PROTECTED]:~/exp-array-default$ /home/mec/gcc-4.2.2/install/bin/g++
z3.cc &&
./a.out
286331153 286331153 286331153 286331153 286331153 286331153 286331153 286331153
286331153 286331153 286331153 286331153
[EMAIL PROTECTED]:~/exp-array-default$
/home/mec/gcc-4.3-20071019/install/bin/g++
z3.cc && ./a.out
286331153 286331153 286331153 286331153 286331153 286331153 286331153 286331153
286331153 286331153 286331153 286331153
--
Summary: Default constructor fails to initialize array members
Product: gcc
Version: 4.2.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: mec at google 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=33916
[Bug c++/33752] gcc forgets about noreturn in this code
--- Comment #1 from mec at google dot com 2007-10-12 16:08 --- Created an attachment (id=14349) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14349&action=view) Test program Compile with: g++ -Wall -c z4.cc -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33752
[Bug c++/33752] New: gcc forgets about noreturn in this code
In the attached program, Beta::~Beta() is noreturn. gcc is smart enough to
figure out the noreturn in DeltaOne and DeltaTwo, but forgets about noreturn in
DeltaThree and issues an unwanted warning.
[EMAIL PROTECTED]:~/exp-non-void$ /home/mec/gcc-4.1.1/install/bin/g++ -Wall -c
z4.cc
z4.cc: In function 'bool DeltaTwo(bool)':
z4.cc:28: warning: unused variable 'b2'
z4.cc: In function 'bool DeltaThree(bool)':
z4.cc:42: warning: control reaches end of non-void function
[EMAIL PROTECTED]:~/exp-non-void$ /home/mec/gcc-4.2.1/install/bin/g++ -Wall -c
z4.cc
z4.cc: In function 'bool DeltaTwo(bool)':
z4.cc:28: warning: unused variable 'b2'
z4.cc: In function 'bool DeltaThree(bool)':
z4.cc:42: warning: control reaches end of non-void function
[EMAIL PROTECTED]:~/exp-non-void$ /home/mec/gcc-4.3-20070914/install/bin/g++
-Wall
-c z4.cc
z4.cc: In function 'bool DeltaTwo(bool)':
z4.cc:28: warning: unused variable 'b2'
z4.cc: In function 'bool DeltaThree(bool)':
z4.cc:42: warning: control reaches end of non-void function
--
Summary: gcc forgets about noreturn in this code
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: mec at google 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=33752
[Bug c++/33515] Inconsistent warning about "defined but not used"
--- Comment #2 from mec at google dot com 2007-09-21 05:59 --- Created an attachment (id=14237) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14237&action=view) Test program Compile with: gcc -Wall -S z3.cc This program does give a warning about a1 defined-but-not-used. I believe this is incorrect. The real point is that z2.cc and z3.cc should behave consistently. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33515
[Bug c++/33515] Inconsistent warning about "defined but not used"
--- Comment #1 from mec at google dot com 2007-09-21 05:58 --- Created an attachment (id=14236) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14236&action=view) Test program compile with: gcc -Wall -S z2.cc This program does not give a warning about a1 defined-but-not-used. I believe this is correct behavior. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33515
[Bug c++/33515] New: Inconsistent warning about "defined but not used"
Consider this code:
class Alpha { public: Alpha(); };
static Alpha* a1 = new Alpha;
Should this draw a warning about a1 defined-but-not-used? gcc 4.3-20070914
gives a warning on some programs but not others. Specifically, I see the
warning if a program has an unrelated syntax error. This is odd.
[EMAIL PROTECTED]:~/exp-defined$ cat z2.cc
class Alpha {
public:
Alpha();
~Alpha();
private:
int i;
};
static Alpha* a1 = new Alpha;
int Beta() {
return 0;
}
[EMAIL PROTECTED]:~/exp-defined$ /home/mec/gcc-4.3-20070914/install/bin/g++
-Wall
-S z2.cc
[EMAIL PROTECTED]:~/exp-defined$ cat z3.cc
class Alpha {
public:
Alpha();
~Alpha();
private:
int i;
};
static Alpha* a1 = new Alpha;
int Beta() {
return x;
}
[EMAIL PROTECTED]:~/exp-defined$ /home/mec/gcc-4.3-20070914/install/bin/g++
-Wall
-S z3.cc
z3.cc: In function 'int Beta()':
z3.cc:12: error: 'x' was not declared in this scope
z3.cc: At global scope:
z3.cc:9: warning: 'a1' defined but not used
[EMAIL PROTECTED]:~/exp-defined$
--
Summary: Inconsistent warning about "defined but not used"
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: mec at google 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=33515
[Bug c++/33514] Inconsistent warning for compile-time integer overflow
--- Comment #1 from mec at google dot com 2007-09-21 05:28 --- Created an attachment (id=14235) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14235&action=view) Test program Compile with: gcc -Wall -S z5.cc -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33514
[Bug c++/33514] New: Inconsistent warning for compile-time integer overflow
This is with gcc 4.3-20070914 snapshot.
The attached program has four sites with compile-time integer overflow: the
initializations of h4, h8, bp_i:h, and bp_lli:h. Only the last of these draws
a warning.
[EMAIL PROTECTED]:~/exp-integer-overflow$ cat z5.cc
#include
int l4 = 0x01010101;
int h4 = l4 * 0x80;
long long int l8 = 0x0101010101010101ll;
long long int h8 = l8 * 0x80;
template struct BitPattern {
// For int32:
// half_ones = 0x
// l = 0x01010101
// h = 0x80808080
static const T half_ones = (static_cast(1) << (sizeof(T)*4)) - 1;
static const T l = (sizeof(T) == 1) ? 1 : (half_ones / 0xff * (half_ones +
2));
static const T h = l * 0x80;
};
BitPattern bp_i;
BitPattern bp_lli;
int main() {
printf("%16.16llx\n", bp_lli.half_ones);
printf("%16.16llx\n", bp_lli.l);
printf("%16.16llx\n", bp_lli.h);
return 0;
}
[EMAIL PROTECTED]:~/exp-integer-overflow$
/home/mec/gcc-4.3-20070914/install/bin/g++ -Wall -S z5.cc
z5.cc: In instantiation of 'const long long int BitPattern::h':
z5.cc:25: instantiated from here
z5.cc:16: warning: integer overflow in expression
--
Summary: Inconsistent warning for compile-time integer overflow
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: mec at google 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=33514
[Bug c++/10541] [DR 354] Is NULL a valid pointer-type template argument?
--- Comment #8 from mec at google dot com 2007-09-03 15:47 --- DR 354 has been in state WP since October 2005. Is that good enough to unsuspend this issue? http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html#354 -- mec at google dot com changed: What|Removed |Added CC||mec at google dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=10541
[Bug preprocessor/33143] preprocess should ignore trigraphs in /* */ comments
--- Comment #1 from mec at google dot com 2007-08-22 00:35 --- Created an attachment (id=14093) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14093&action=view) C++ source file with trigraphs in comments and #if 0 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33143
[Bug preprocessor/33143] New: preprocess should ignore trigraphs in /* */ comments
http://gcc.gnu.org/onlinedocs/gcc-4.2.1/gcc/Warning-Options.html#Warning-Options-Wtrigraphs
-Wtrigraphs
Warn if any trigraphs are encountered that might change the meaning of the
program (trigraphs within comments are not warned about). This warning is
enabled by -Wall.
Right now, trigraphs in // comments are not warned about. Trigraphs in /* */
comments are warned about, but should not be. Trigraphs in #if 0 ... #endif
are also warned about, but it would probably be too sticky to change that
behavior.
Example:
[EMAIL PROTECTED]:~/exp-trigraph$ cat z1.cc
#if 0
??-??-
#endif
/*
??-??-
*/
// ??-??-
[EMAIL PROTECTED]:~/exp-trigraph$ /home/mec/gcc-4.2.1/install/bin/g++ -E z1.cc
# 1 "z1.cc"
# 1 ""
# 1 ""
# 1 "z1.cc"
z1.cc:2:1: warning: trigraph ??- ignored, use -trigraphs to enable
z1.cc:2:4: warning: trigraph ??- ignored, use -trigraphs to enable
[EMAIL PROTECTED]:~/exp-trigraph$ /home/mec/gcc-4.3-20070810/install/bin/g++ -E
z1.cc
# 1 "z1.cc"
# 1 ""
# 1 ""
# 1 "z1.cc"
z1.cc:2:1: warning: trigraph ??- ignored, use -trigraphs to enable
z1.cc:2:4: warning: trigraph ??- ignored, use -trigraphs to enable
--
Summary: preprocess should ignore trigraphs in /* */ comments
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: preprocessor
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: mec at google 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=33143
[Bug c++/33124] C++ frontend should not warn about new a[0] in template context
--- Comment #2 from mec at google dot com 2007-08-20 19:31 --- "new T[0]" looks like defined behavior to me. [expr.new] 5.3.4 -7- When the value of the expression in a direct-new-declarator is zero, the allocation function is called to allocate an array with no elements. The pointer returend by the new-expression is non-null. [Note: if the library allocation function is called, the pointer returned is distinct from the the pointer to any other object.] === cp/init.c even quotes that section in a comment before giving the warning. cp/init.c goes on to say "However, that is not generally useful, so we issue a warning". new T[0] is valid C++ and here is a useful case. -- mec at google dot com changed: What|Removed |Added CC| |mec at google dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33124
[Bug c++/32735] i686 sse2 generates more movdqa than necessary
--- Comment #4 from mec at google dot com 2007-07-12 01:33 --- Created an attachment (id=13897) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13897&action=view) Assembly code -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32735
[Bug c++/32735] i686 sse2 generates more movdqa than necessary
--- Comment #3 from mec at google dot com 2007-07-12 01:33 --- Created an attachment (id=13896) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13896&action=view) Assembly code -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32735
[Bug c++/32735] i686 sse2 generates more movdqa than necessary
--- Comment #2 from mec at google dot com 2007-07-12 01:31 --- Created an attachment (id=13895) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13895&action=view) Generated code -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32735
[Bug c++/32735] i686 sse2 generates more movdqa than necessary
--- Comment #1 from mec at google dot com 2007-07-12 01:30 --- Created an attachment (id=13894) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13894&action=view) Test program -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32735
[Bug c++/32735] New: i686 sse2 generates more movdqa than necessary
Test program attached.
Command line:
[EMAIL PROTECTED]:~/exp-sum-delta$ /home/mec/gcc-4.3-20070707/install/bin/g++
-v -S
-O2 -msse2 sum-delta.cc
Using built-in specs.
Target: i686-pc-linux-gnu
Configured with: /home/mec/gcc-4.3-20070707/src/configure
--build=i686-pc-linux-
gnu --host=i686-pc-linux-gnu --target=i686-pc-linux-gnu
--prefix=/home/mec/gcc-4
.3-20070707/install --enable-languages=c,c++,objc,obj-c++,treelang
--with-gmp=/h
ome/mec/gmp-4.2.1/install --with-mpfr=/home/mec/mpfr-2.2.1/install
Thread model: posix
gcc version 4.3.0 20070707 (experimental)
/home/mec/gcc-4.3-20070707/install/libexec/gcc/i686-pc-linux-gnu/4.3.0/cc1plus
-quiet -v -D_GNU_SOURCE sum-delta.cc -quiet -dumpbase sum-delta.cc -msse2
-mtune
=generic -auxbase sum-delta -O2 -version -o sum-delta.s
ignoring nonexistent directory
"/home/mec/gcc-4.3-20070707/install/lib/gcc/i686-
pc-linux-gnu/4.3.0/../../../../i686-pc-linux-gnu/include"
#include "..." search starts here:
#include <...> search starts here:
/home/mec/gcc-4.3-20070707/install/lib/gcc/i686-pc-linux-gnu/4.3.0/../../../../
include/c++/4.3.0
/home/mec/gcc-4.3-20070707/install/lib/gcc/i686-pc-linux-gnu/4.3.0/../../../../
include/c++/4.3.0/i686-pc-linux-gnu
/home/mec/gcc-4.3-20070707/install/lib/gcc/i686-pc-linux-gnu/4.3.0/../../../../
include/c++/4.3.0/backward
/usr/local/include
/home/mec/gcc-4.3-20070707/install/include
/home/mec/gcc-4.3-20070707/install/lib/gcc/i686-pc-linux-gnu/4.3.0/include
/home/mec/gcc-4.3-20070707/install/lib/gcc/i686-pc-linux-gnu/4.3.0/include-fixe
d
/usr/include
End of search list.
GNU C++ version 4.3.0 20070707 (experimental) (i686-pc-linux-gnu)
compiled by GNU C version 4.3.0 20070707 (experimental), GMP version
4.2
.1, MPFR version 2.2.1.
warning: GMP header version 4.2.1 differs from library version 4.1.4.
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
Compiler executable checksum: 1338ea4083517ffee92283f96caf8872
===
The loop for CallSumDeltas2 compiles to:
.L7:
movdqa %xmm1, %xmm0
pslldq $4, %xmm0
addl$1, %eax
paddd %xmm1, %xmm0
cmpl$1, %eax
movdqa %xmm0, %xmm1
pslldq $8, %xmm1
paddd %xmm1, %xmm0
movdqa %xmm0, %xmm1
movdqa %xmm0, foo1
jne .L7
===
This is two more movdqa then the hand-written code in CallSumDeltas3.
--
Summary: i686 sse2 generates more movdqa than necessary
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: mec at google 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=32735
[Bug c/32528] New: -save-temps when compiling standard input fails
This looks like a trivial bug in options processing. It's been not working for
a long time.
===
[EMAIL PROTECTED]:~/exp-save-temps-dash$ cat hello.c
#include
int main()
{
printf("Hello, world\n");
return 0;
}
[EMAIL PROTECTED]:~/exp-save-temps-dash$ cat hello.c |
/home/mec/gcc-3.4.6/install/bin/gcc -save-temps -x c -
cc1: error: unrecognized command line option "-.i"
[EMAIL PROTECTED]:~/exp-save-temps-dash$ cat hello.c |
/home/mec/gcc-4.0.4/install/bin/gcc -save-temps -x c -
cc1: error: unrecognized command line option "-.i"
[EMAIL PROTECTED]:~/exp-save-temps-dash$ cat hello.c |
/home/mec/gcc-4.1.2/install/bin/gcc -save-temps -x c -
cc1: error: unrecognized command line option "-.i"
[EMAIL PROTECTED]:~/exp-save-temps-dash$ cat hello.c |
/home/mec/gcc-4.2.0/install/bin/gcc -save-temps -x c -
cc1: error: unrecognized command line option "-.i"
[EMAIL PROTECTED]:~/exp-save-temps-dash$ cat hello.c |
/home/mec/gcc-4.3-20070622/install/bin/gcc -save-temps -x c -
cc1: error: unrecognized command line option "-.i"
[EMAIL PROTECTED]:~/exp-save-temps-dash$
--
Summary: -save-temps when compiling standard input fails
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: trivial
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: mec at google 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=32528
[Bug middle-end/32327] [4.2 Regression] Incorrect stack sharing causing removal of live code
--- Comment #22 from mec at google dot com 2007-06-15 13:15 --- With the test program, gcc 4.1.2 generates correct code and gcc 4.2.0 generates wrong code. Can someone increase the priority and severity of this PR? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32327
[Bug libstdc++/32208] New: Patch for 32158 has bad code in std::vector::_M_fill_initialize
[EMAIL PROTECTED]:~/exp-43-redux$ cat vector-fill.cc
// Copyright 2007, Google Inc. All rights reserved.
// Author: [EMAIL PROTECTED] (Michael Chastain)
#include
std::vector my_vector (117);
===
[EMAIL PROTECTED]:~/exp-43-redux$ /home/mec/gcc-4.3-20070601/install/bin/g++
-Wall
-S vector-fill.cc
/home/mec/gcc-4.3-20070601/install/lib/gcc/i686-pc-linux-gnu/4.3.0/../../../../include/c++/4.3.0/bits/stl_vector.h:
In member function 'int std::vector<_Tp, _Alloc>::_M_fill_initialize(size_t,
const _Tp&) [with _Tp = int, _Alloc = std::allocator]':
/home/mec/gcc-4.3-20070601/install/lib/gcc/i686-pc-linux-gnu/4.3.0/../../../../include/c++/4.3.0/bits/stl_vector.h:832:
warning: control reaches end of non-void function
===
This is from:
http://gcc.gnu.org/viewcvs/trunk/libstdc%2B%2B-v3/include/bits/stl_vector.h?r1=124243&r2=125223
Trivial lack of "void".
===
Also, shouldn't there also be an error about lack of return type for
_M_fill_initialize?
--
Summary: Patch for 32158 has bad code in
std::vector::_M_fill_initialize
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: mec at google 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=32208
[Bug c++/32158] uninitialized_fill compile failure if no default assignment operator
--- Comment #12 from mec at google dot com 2007-06-04 13:35 --- Verified with my two test programs with snapshot gcc-4.3-20070601. Thanks for the fast fix! -- mec at google dot com changed: What|Removed |Added Status|RESOLVED|VERIFIED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32158
[Bug c++/32158] uninitialized_fill compile failure if no default assignment operator
--- Comment #7 from mec at google dot com 2007-05-30 23:01 ---
I think the problem is independent of __is_pod. The new
std::uninitialized_fill has an "if" statement, not a template specialization.
Compilation always attempts to instantiate std::fill(__first_, __last_, __x),
whether that line is executed at run-time or not.
Here is an example with a class that is clearly not a POD.
===
#include
class Foo {
public:
Foo();
Foo(const Foo&);
~Foo();
private:
void* p;
void operator=(const Foo&);
};
void Alpha(Foo* start, Foo* end) {
Foo f;
std::uninitialized_fill(start, end, f);
}
[EMAIL PROTECTED]:~/exp-43-redux$ /home/mec/gcc-4.2.0/install/bin/g++ -Wall -S
u-fill-2.cc
[EMAIL PROTECTED]:~/exp-43-redux$ /home/mec/gcc-4.3-20070525/install/bin/g++
-Wall
-S u-fill-2.cc
u-fill-2.cc: In static member function 'static void std::__fill<
>::fill(_ForwardIterator, _ForwardIterator, const _Tp&) [with _ForwardIterator
= Foo*, _Tp = Foo, bool = false]':
/home/mec/gcc-4.3-20070525/install/lib/gcc/i686-pc-linux-gnu/4.3.0/../../../../include/c++/4.3.0/bits/stl_algobase.h:557:
instantiated from 'void std::__fill_aux(_ForwardIterator, _ForwardIterator,
const _Tp&) [with _ForwardIterator = Foo*, _Tp = Foo]'
/home/mec/gcc-4.3-20070525/install/lib/gcc/i686-pc-linux-gnu/4.3.0/../../../../include/c++/4.3.0/bits/stl_algobase.h:595:
instantiated from 'void std::fill(_ForwardIterator, _ForwardIterator, const
_Tp&) [with _ForwardIterator = Foo*, _Tp = Foo]'
/home/mec/gcc-4.3-20070525/install/lib/gcc/i686-pc-linux-gnu/4.3.0/../../../../include/c++/4.3.0/bits/stl_uninitialized.h:146:
instantiated from 'void std::uninitialized_fill(_ForwardIterator,
_ForwardIterator, const _Tp&) [with _ForwardIterator = Foo*, _Tp = Foo]'
u-fill-2.cc:15: instantiated from here
u-fill-2.cc:10: error: 'void Foo::operator=(const Foo&)' is private
/home/mec/gcc-4.3-20070525/install/lib/gcc/i686-pc-linux-gnu/4.3.0/../../../../include/c++/4.3.0/bits/stl_algobase.h:533:
error: within this context
[EMAIL PROTECTED]:~/exp-43-redux$
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32158
[Bug libstdc++/32158] New: uninitialized_fill compile failure if no default assignment operator
Here is a test program:
// Call uninitialized_fill on a type with a default copy constructor
// but no default assignment operator.
#include
#include
typedef std::pair MyPair;
void Alpha(MyPair* start, MyPair* end) {
MyPair my_pair(1, 2);
std::uninitialized_fill(start, end, my_pair);
};
===
This program compiles with gcc 4.2.0 and does not compile with gcc
4.3-20070525.
[EMAIL PROTECTED]:~/exp-43-redux$ /home/mec/gcc-4.2.0/install/bin/g++ -Wall -S
uninitialized-fill.cc
[EMAIL PROTECTED]:~/exp-43-redux$ /home/mec/gcc-4.3-20070525/install/bin/g++
-Wall
-S uninitialized-fill.cc
/home/mec/gcc-4.3-20070525/install/lib/gcc/i686-pc-linux-gnu/4.3.0/../../../../include/c++/4.3.0/bits/stl_pair.h:
In member function 'std::pair& std::pair::operator=(const std::pair&)':
/home/mec/gcc-4.3-20070525/install/lib/gcc/i686-pc-linux-gnu/4.3.0/../../../../include/c++/4.3.0/bits/stl_pair.h:69:
instantiated from 'static void std::__fill<
>::fill(_ForwardIterator, _ForwardIterator, const _Tp&) [with _ForwardIterator
= MyPair*, _Tp = std::pair, bool = false]'
/home/mec/gcc-4.3-20070525/install/lib/gcc/i686-pc-linux-gnu/4.3.0/../../../../include/c++/4.3.0/bits/stl_algobase.h:557:
instantiated from 'void std::__fill_aux(_ForwardIterator, _ForwardIterator,
const _Tp&) [with _ForwardIterator = MyPair*, _Tp = std::pair]'
/home/mec/gcc-4.3-20070525/install/lib/gcc/i686-pc-linux-gnu/4.3.0/../../../../include/c++/4.3.0/bits/stl_algobase.h:595:
instantiated from 'void std::fill(_ForwardIterator, _ForwardIterator, const
_Tp&) [with _ForwardIterator = MyPair*, _Tp = std::pair]'
/home/mec/gcc-4.3-20070525/install/lib/gcc/i686-pc-linux-gnu/4.3.0/../../../../include/c++/4.3.0/bits/stl_uninitialized.h:146:
instantiated from 'void std::uninitialized_fill(_ForwardIterator,
_ForwardIterator, const _Tp&) [with _ForwardIterator = MyPair*, _Tp = MyPair]'
uninitialized-fill.cc:14: instantiated from here
/home/mec/gcc-4.3-20070525/install/lib/gcc/i686-pc-linux-gnu/4.3.0/../../../../include/c++/4.3.0/bits/stl_pair.h:69:
error: non-static const member 'const int std::pair::first',
can't use default assignment operator
/home/mec/gcc-4.3-20070525/install/lib/gcc/i686-pc-linux-gnu/4.3.0/../../../../include/c++/4.3.0/bits/stl_algobase.h:
In static member function 'static void std::__fill<
>::fill(_ForwardIterator, _ForwardIterator, const _Tp&) [with _ForwardIterator
= MyPair*, _Tp = std::pair, bool = false]':
/home/mec/gcc-4.3-20070525/install/lib/gcc/i686-pc-linux-gnu/4.3.0/../../../../include/c++/4.3.0/bits/stl_algobase.h:533:
note: synthesized method 'std::pair& std::pair::operator=(const std::pair&)' first required here
[EMAIL PROTECTED]:~/exp-43-redux$
===
This patch looks relevant:
http://gcc.gnu.org/ml/libstdc++/2007-04/msg00016.html
===
I believe this program should compile, because std::uninitialized_fill is
defined to call placement new several times. std::pair has a
suitable copy constructor, but no assignment operator.
--
Summary: uninitialized_fill compile failure if no default
assignment operator
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: mec at google 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=32158
[Bug c/32102] New: -Wall stomps on -Wstrict-overflow
This is with the 4.3-20070525 snapshot.
Test program:
void Alpha();
void Beta() {
int i;
for (i = 1; i > 0; ++i)
Alpha();
}
This invocation produces no warnings:
/home/mec/gcc-4.3-20070525/install/bin/gcc -O2 -S -Wstrict-overflow=2 -Wall
z1.c
This invocation produces warnings:
/home/mec/gcc-4.3-20070525/install/bin/gcc -O2 -S -Wall -Wstrict-overflow=2
z1.c
z1.c: In function 'Beta':
z1.c:5: warning: assuming signed overflow does not occur when simplifying
conditional to constant
It looks like -Wall sets the strict overflow warning level to 1, quietly
stomping on the earlier setting.
--
Summary: -Wall stomps on -Wstrict-overflow
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: mec at google 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=32102
[Bug c++/31742] New: warn_unused_result prints no warning for return value with destructor
(This is similar to PR 27371)
When a function or method has attribute warn_unused_result, and the return type
has a destructor, gcc does not emit a warning. gcc 4.0.3 emitted a warning;
gcc 4.1.2 does not; gcc 4.3-20070427 does not.
[EMAIL PROTECTED]:~/exp-warn-unused-result$ cat warn.cc
int Alpha() __attribute__ ((warn_unused_result));
class C1 {
public:
C1();
~C1();
public:
int value_;
int Beta() __attribute__ ((warn_unused_result)) {
return value_;
}
C1 Gamma() __attribute__ ((warn_unused_result)) {
return *this;
}
};
extern C1 Delta() __attribute__ ((warn_unused_result));
int Foo() {
C1 c1;
Alpha();
c1.Beta();
c1.Gamma();
Delta();
return 0;
}
[EMAIL PROTECTED]:~/exp-warn-unused-result$
/home/mec/gcc-4.3-20070427/install/bin/g++ -Wall -S warn.cc
warn.cc: In function 'int Foo()':
warn.cc:22: warning: ignoring return value of 'int Alpha()', declared with
attribute warn_unused_result
warn.cc:23: warning: ignoring return value of 'int C1::Beta()', declared with
attribute warn_unused_result
[EMAIL PROTECTED]:~/exp-warn-unused-result$ /home/mec/gcc-4.1.2/install/bin/g++
-Wall -S warn.cc
warn.cc: In function 'int Foo()':
warn.cc:22: warning: ignoring return value of 'int Alpha()', declared with
attribute warn_unused_result
warn.cc:23: warning: ignoring return value of 'int C1::Beta()', declared with
attribute warn_unused_result
[EMAIL PROTECTED]:~/exp-warn-unused-result$ /home/mec/gcc-4.0.3/install/bin/g++
-Wall -S warn.cc
warn.cc: In function 'int Foo()':
warn.cc:22: warning: ignoring return value of 'int Alpha()', declared with
attribute warn_unused_result
warn.cc:23: warning: ignoring return value of 'int C1::Beta()', declared with
attribute warn_unused_result
warn.cc:24: warning: ignoring return value of 'C1 C1::Gamma()', declared with
attribute warn_unused_result
warn.cc:25: warning: ignoring return value of 'C1 Delta()', declared with
attribute warn_unused_result
--
Summary: warn_unused_result prints no warning for return value
with destructor
Product: gcc
Version: 4.1.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: mec at google 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=31742
[Bug c++/28408] New: What should be value of complex(1.0,0.0) *= -1?
Test program:
// Copyright 2006, Google Inc. All rights reserved.
// Author: [EMAIL PROTECTED] (Michael Chastain)
//
// Compute (1.0, 0.0) *= -1.0
#include
#include
std::complex d_1(1.0, 0.0);
int main() {
std::complex d_m1(1.0, 0.0);
d_m1 *= -1.0;
std::cout << "d_m1: " << d_m1 << std::endl;
std::cout << std::endl;
return 0;
}
===
This gives different results with the same version of gcc at different
optimization options. All of these are with glibc 2.3.5.
hollerith:~/exp-i$ /home/mec/gcc-3.4.6/install/bin/g++ z4.cc && a.out
d_m1: (-1,0)
hollerith:~/exp-i$ /home/mec/gcc-3.4.6/install/bin/g++ -O2 z4.cc && a.out
d_m1: (-1,0)
hollerith:~/exp-i$ /fast/mec/gcc-4.0.3/install/bin/g++ z4.cc && a.out
d_m1: (-1,0)
hollerith:~/exp-i$ /fast/mec/gcc-4.0.3/install/bin/g++ -O2 z4.cc && a.out
d_m1: (-1,0)
hollerith:~/exp-i$ /home/mec/gcc-4.1.1/install/bin/g++ z4.cc && a.out
d_m1: (-1,0)
hollerith:~/exp-i$ /home/mec/gcc-4.1.1/install/bin/g++ -O2 z4.cc && a.out
d_m1: (-1,-0)
hollerith:~/exp-i$ /home/mec/gcc-4.2-20060624/install/bin/g++ z4.cc && a.out
d_m1: (-1,0)
hollerith:~/exp-i$ /home/mec/gcc-4.2-20060624/install/bin/g++ -O2 z4.cc &&
a.out
d_m1: (-1,-0)
===
One might argue that (-1,0) is equals to (-1,-0). In that case, consider this
code:
std::complex d_m1(1.0, 0.0);
d_m1 *= -1.0;
std::complex d_i(sqrt(d_m1));
See PR 28406, which shows that sqrt((-1,0)) != sqrt((-1,-0)). So code like the
above produces materially different results with gcc 4.1.1 -O0 and gcc 4.1.1
-O2.
--
Summary: What should be value of complex(1.0,0.0) *= -1?
Product: gcc
Version: 4.1.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: mec at google 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=28408
[Bug libstdc++/28406] New: What should be value of sqrt(complex(-1.0,-0.0))?
Test program:
// Copyright 2006, Google Inc. All rights reserved.
// Author: [EMAIL PROTECTED] (Michael Chastain)
//
// Compute i = sqrt(complex(-1,-0))
#include
#include
std::complex d_m1(-1.0, -0.0);
int main() {
std::cout << "d_m1: " << d_m1 << std::endl;
std::complex d_i_sqrt = std::sqrt(d_m1);
std::cout << "d_i_sqrt: " << d_i_sqrt << std::endl;
std::cout << std::endl;
return 0;
}
===
This gives different results with different versions of gcc. All of these are
with glibc 2.3.5, which is important because libstdc++ calls down to glibc
csqrt.
hollerith:~/exp-i$ /home/mec/gcc-3.4.6/install/bin/g++ z2.cc && a.out
d_m1: (-1,-0)
d_i_sqrt: (0,1)
hollerith:~/exp-i$ /home/mec/gcc-3.4.6/install/bin/g++ -O2 z2.cc && a.out
d_m1: (-1,-0)
d_i_sqrt: (0,1)
hollerith:~/exp-i$ /home/mec/gcc-4.0.2/install/bin/g++ z2.cc && a.out
d_m1: (-1,-0)
d_i_sqrt: (0,-1)
hollerith:~/exp-i$ /home/mec/gcc-4.0.2/install/bin/g++ -O2 z2.cc && a.out
d_m1: (-1,-0)
d_i_sqrt: (0,-1)
hollerith:~/exp-i$ /home/mec/gcc-4.1.1/install/bin/g++ z2.cc && a.out
d_m1: (-1,-0)
d_i_sqrt: (0,-1)
hollerith:~/exp-i$ /home/mec/gcc-4.1.1/install/bin/g++ -O2 z2.cc && a.out
d_m1: (-1,-0)
d_i_sqrt: (0,-1)
hollerith:~/exp-i$ /home/mec/gcc-4.2-20060624/install/bin/g++ z2.cc && a.out
d_m1: (-1,-0)
d_i_sqrt: (0,-1)
hollerith:~/exp-i$ /home/mec/gcc-4.2-20060624/install/bin/g++ -O2 z2.cc &&
a.out
d_m1: (-1,-0)
d_i_sqrt: (0,-1)
===
What is the correct value?
ISO/IEC 14882 says:
26.2.8 [lib.complex.transcendentals]
template complex sqrt(const complex& x);
-12- Notes: the branch cuts are along the negative real axis.
-13- Returns: the complex square root of x, in the range of the right
half-plane. If the argument is a negative real number, the value returned lies
on the positive imaginary axis.
ISO/EIC 9899:TC2 says:
7.3.3 Branch cuts
Some of the functions below have branch cuts, across which the function is
discontinuous. For implementations with a signed zero (including all IEC 60559
implementations) that follow the specifications of annex G, the sign of zero
distinguishes one side of a cut from another so the function is continuous
(except for format limitations) as the cut is approached from either side. For
example, for the square root function, which has a branch cut along the
negative real axis, the top of the cut, with imaginary part +0, maps to the
positive imaginary axis, and the bottom of the cut, with imaginary part 0, maps
to the negative imaginary axis.
And LIA-3, Draft ISO/IEC FCD 10967-3 First edition 2004-06-22, says:
sqrtC(F)(x+i.y) = conjC(F)(sqrtC(F)(x+i.0)) if x is in F u {-inf, +inf} and y =
-0
===
ISO/EIC 14882 appears to require the (-0,1) answer, because (-1,-0) is a
negative real number. Argh ... it depends ... on what "is" is.
LIA-3 is clear but I don't know the standards status of LIA-3.
--
Summary: What should be value of sqrt(complex(-1.0,-
0.0))?
Product: gcc
Version: 4.1.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: mec at google 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=28406
[Bug libstdc++/28277] __builtin_alloca with no limit in libstdc++
--- Comment #5 from mec at google dot com 2006-07-05 22:43 --- The threads point is just a basic stack size issue: threads on linux have a fixed size which is often smaller than the main stack size limit. With an output width of 60 million, it's easy to see a failure, even on a main stack. hollerith:~/exp-string-width$ ulimit -Ss 8192 hollerith:~/exp-string-width$ /home/mec/gcc-4.2-20060624/install/bin/g++ z1.cc hollerith:~/exp-string-width$ a.out > /dev/null Segmentation fault I agree, this would be best fixed, carefully, in mainline, and then flow into releases in the fullness of time. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28277
[Bug libstdc++/28277] __builtin_alloca with no limit in libstdc++
--- Comment #2 from mec at google dot com 2006-07-05 22:20 ---
Sure, here is a test program for versa_string:
// Copyright 2006, Google Inc. All rights reserved.
// Author: [EMAIL PROTECTED] (Michael Chastain)
//
// Test operator<<(ostream&, const versa_string&)
#include
#include
int main() {
__gnu_cxx::__versa_string<
char, std::char_traits, std::allocator
> s("Hello world");
std::cout << s << std::endl;
std::cout.width(60);
std::cout << s << std::endl;
std::cout.width(6000);
std::cout << s << std::endl;
std::cout.width(6000);
std::cout << s << std::endl;
return 0;
}
This program allocates 60 million bytes on the stack in the last output
statement.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28277
[Bug libstdc++/28277] New: __builtin_alloca with no limit in libstdc++
libstc++ uses __builtin_alloca in several places: config/local/gnu/codecvt_members.cc include/ext/codecvt_specializations.h include/ext/vstring.cc include/bits/locale_facets.tcc include/bits/ostream.tcc include/bits/fstream.cc include/std/std_valarray.h src/valarray-inst.cc These have data-dependent sizes with no obvious limit, which does not mix well with threads and small stacks. -- Summary: __builtin_alloca with no limit in libstdc++ Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: mec at google 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=28277
[Bug c++/27603] wrong code, apparently due to bad VRP
--- Comment #1 from mec at google dot com 2006-05-14 16:55 --- Created an attachment (id=11463) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11463&action=view) C++ source code -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27603
[Bug c++/27603] New: wrong code, apparently due to bad VRP
Compile the attached program with: gcc -O0 wrong-code-tree-vrp.cc gcc -O2 wrong-code-tree-vrp.cc gcc -O2 -fno-tree-vrp wrong-code-tree-vrp.cc with gcc 4.1.0, native i686-pc-linux-gnu. The -O0 and -O2 -fno-tree-vrp versions produce the correct output: g1[3] == 100, g1[4] == 100. The -O2 version produces incorrect output: g1[3] == 101, g1[4] == 101. Works fine with gcc 4.0.3, native i686-pc-linux-gnu, -O2. Still broken with gcc 4.2-20060513, native i686-pc-linux-gnu, -O2. Haven't checked with gcc 4.1-LATEST yet. -- Summary: wrong code, apparently due to bad VRP Product: gcc Version: 4.1.0 Status: UNCONFIRMED Severity: major Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: mec at google 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=27603
[Bug libstdc++/17012] [DR 526] std::list's function, remove, looks like it is reading memory that has been freed.
--- Comment #11 from mec at google dot com 2006-01-21 22:04 --- You can make this visible at the C++ program level with a Key class that has a signature field. Init the signature in the constructor, clear the signature in the destructor, and check the signature in operator==. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17012
[Bug libstdc++/25896] New: hash_map::erase, unordered_map::erase fail if key is inside the table
This happens with both hash_map and unordered_map and their related classes. I
know that hash_map is not standard, and unordered_map is in TR1 so not
considered standard yet.
Here is a kernel of the problem:
hash_map c;
c.insert(...);
hash_map::iterator it = c.find("...");
c.erase(it->first);
This is deleting by key value, not by iterator.
it->first is a key value which belongs to the collection object.
hash_map::erase(const key&) takes the key by reference. It delegates to its
rep object, which is a hashtable. hashtable::ref looks like this in gcc 4.0.2:
if (__first)
{
...
while (__next)
{
if (_M_equals(_M_get_key(__next->_M_val), __key))
{
...
_M_delete_node(__next);
...
}
...
}
...
}
The actual key object is in a node of the hash table. After deleting that
node, the while() loop keeps using the deleted __key value with every other
node in the same bucket.
The following gcc versions have this problem with the following classes:
gcc 3.4.5
hash_map, hash_multimap, hash_set, hash_multiset
gcc 4.0.2
gcc 4.1-20060106
gcc 4.2-20060114
hash_map, hash_multimap, hash_set, hash_multiset
unordered_map, unordered_multimap, unordered_set, unordered_multiset
You could punt on hash_map and friends because they are non-standard, but it is
nasty to have a case where code compiles and links and runs and then a library
function reads a destroyed object. unordered_map and friends will eventually
(probably) be standardized so they are more serious.
--
Summary: hash_map::erase, unordered_map::erase fail if key is
inside the table
Product: gcc
Version: 4.0.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: mec at google 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=25896
[Bug c++/24746] New: unpleasant warning for "if (NULL)"
C++ programs with "if (NULL)" generate an unpleasant warning even with default
compiler options. Code with "if (NULL)" comes from of macro expansion or
auto-generated code.
Warnings are a matter of taste so I won't ask "make all the warnings match my
taste", but I do petition you to revisit which of these lines should generate
warnings and apply your own taste.
This patch looks like the last time these warnings were modified:
http://gcc.gnu.org/ml/gcc-patches/2005-01/msg02230.html
Mark Mitchell, C++ PATCH: PR 19457 a PR 19349
Test program:
int foo() {
if (__null) return -1;
if (!__null) ; else return -1;
if (__null == __null) ; else return -1;
if (__null != __null) return -1;
if (__null == __null) ; else return -1;
if (__null != 0) ; else return -1;
return 0;
}
int main() {
return foo() == 0;
}
Warnings shown:
hollerith:~/null-arithmetic$ /home/mec/gcc-4.0.2/install/bin/gcc -c
null-arithmetic.cc
null-arithmetic.cc: In function 'int foo()':
null-arithmetic.cc:2: warning: converting to non-pointer type 'bool' from NULL
null-arithmetic.cc:3: warning: converting to non-pointer type 'bool' from NULL
null-arithmetic.cc:4: warning: NULL used in arithmetic
null-arithmetic.cc:5: warning: NULL used in arithmetic
null-arithmetic.cc:6: warning: NULL used in arithmetic
null-arithmetic.cc:7: warning: NULL used in arithmetic
hollerith:~/null-arithmetic$ /home/mec/gcc-4.1-20051105/install/bin/gcc -c
null-arithmetic.cc
null-arithmetic.cc: In function 'int foo()':
null-arithmetic.cc:2: warning: converting to non-pointer type 'bool' from NULL
null-arithmetic.cc:3: warning: converting to non-pointer type 'bool' from NULL
null-arithmetic.cc:4: warning: NULL used in arithmetic
null-arithmetic.cc:5: warning: NULL used in arithmetic
null-arithmetic.cc:6: warning: NULL used in arithmetic
null-arithmetic.cc:7: warning: NULL used in arithmetic
--
Summary: unpleasant warning for "if (NULL)"
Product: gcc
Version: 4.0.2
Status: UNCONFIRMED
Severity: minor
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: mec at google 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=24746
[Bug c++/24745] New: unpleasant warning for "if (NULL)"
C++ programs with "if (NULL)" generate an unpleasant warning even with default
compiler options. Code with "if (NULL)" comes from of macro expansion or
auto-generated code.
Warnings are a matter of taste so I won't ask "make all the warnings match my
taste", but I do petition you to revisit which of these lines should generate
warnings and apply your own taste.
This patch looks like the last time these warnings were modified:
http://gcc.gnu.org/ml/gcc-patches/2005-01/msg02230.html
Mark Mitchell, C++ PATCH: PR 19457 a PR 19349
Test program:
int foo() {
if (__null) return -1;
if (!__null) ; else return -1;
if (__null == __null) ; else return -1;
if (__null != __null) return -1;
if (__null == __null) ; else return -1;
if (__null != 0) ; else return -1;
return 0;
}
int main() {
return foo() == 0;
}
Warnings shown:
hollerith:~/null-arithmetic$ /home/mec/gcc-4.0.2/install/bin/gcc -c
null-arithmetic.cc
null-arithmetic.cc: In function 'int foo()':
null-arithmetic.cc:2: warning: converting to non-pointer type 'bool' from NULL
null-arithmetic.cc:3: warning: converting to non-pointer type 'bool' from NULL
null-arithmetic.cc:4: warning: NULL used in arithmetic
null-arithmetic.cc:5: warning: NULL used in arithmetic
null-arithmetic.cc:6: warning: NULL used in arithmetic
null-arithmetic.cc:7: warning: NULL used in arithmetic
hollerith:~/null-arithmetic$ /home/mec/gcc-4.1-20051105/install/bin/gcc -c
null-arithmetic.cc
null-arithmetic.cc: In function 'int foo()':
null-arithmetic.cc:2: warning: converting to non-pointer type 'bool' from NULL
null-arithmetic.cc:3: warning: converting to non-pointer type 'bool' from NULL
null-arithmetic.cc:4: warning: NULL used in arithmetic
null-arithmetic.cc:5: warning: NULL used in arithmetic
null-arithmetic.cc:6: warning: NULL used in arithmetic
null-arithmetic.cc:7: warning: NULL used in arithmetic
--
Summary: unpleasant warning for "if (NULL)"
Product: gcc
Version: 4.0.2
Status: UNCONFIRMED
Severity: minor
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: mec at google 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=24745
[Bug tree-optimization/23509] [4.1 regression] ICE with ivopts
--- Additional Comments From mec at google dot com 2005-09-03 20:16 ---
Here is another test with confirmatory data.
Test case, reduced from some firefox code:
int punycode_decode(const char input[], unsigned char case_flags[])
{
int j;
for (j = 0; j < 128; ++j) {
if (case_flags)
case_flags[j] = input[j] - 65 < 26;
if (input[j] < 32)
return -1;
}
return 0;
}
With native i686-pc-linux-gnu, my results are:
gcc 4.0.1, command line "gcc -S -O3 z1.i", no error
gcc 4.1-20050819 snapshot, command line "gcc -S -O3 z1.i", ICE:
z1.i: In function 'punycode_decode':
z1.i:2: internal compiler error: in finalize_ssa_uses, at
tree-ssa-operands.c:580
gcc 4.1-20050902 snapshot, command line "gcc -S -O3 z1.i", ICE:
z1.i: In function 'punycode_decode':
z1.i:2: internal compiler error: in finalize_ssa_uses, at
tree-ssa-operands.c:580
gcc 4.1-20050902 snapshot, command line "gcc -S -O3 -fno-ivopts z1.i", no error
gcc 4.1-20050902 snapshot + zdenek patch, command line "gcc -S -O3 z1.i", no
error
zdenek patch is the version from
http://gcc.gnu.org/ml/gcc-patches/2005-08/msg01647.html .
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23509
[Bug c++/23512] wrong code with boolean refs, -O2
--- Additional Comments From mec at google dot com 2005-08-22 06:59 --- Created an attachment (id=9551) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=9551&action=view) source file to demonstrate wrong code -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23512
[Bug c++/23512] New: wrong code with boolean refs, -O2
gcc generates wrong code
command line: gcc -O2
works on: 3.4.4, 4.1.0-20050819
wrong code on: 4.0.1, 4.0.2-20050818
I am just guessing at the priority + severity levels.
Test program attached. It can be compiled and run standalone -- it succeeds
normally, and aborts if wrong-code is generated.
The wrong code is for the source line:
if (_v3 != _v4)
Where _v3 and _v4 are "const bool &".
--
Summary: wrong code with boolean refs, -O2
Product: gcc
Version: 4.0.1
Status: UNCONFIRMED
Severity: critical
Priority: P2
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: mec at google dot com
CC: dank at kegel dot com,gcc-bugs at gcc dot gnu dot org
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=23512
