[Bug c++/30069] New: gcc rejects valid default template parameter
The test case below declares 3 global functions with exactly the
same signature, and another 3 member functions with the same signature.
The last of these is incorrectly rejected.
$ cat junk.cc
#include vector
using namespace std;
void foo11(const vectorchar = vectorchar());
void foo12(const vector char, allocator char=
vector char ());
void foo13(const vector char, allocator char=
vector char, allocator char ());
struct Foo {
void foo21(const vectorchar = vectorchar());
void foo22(const vector char, allocator char=
vector char ());
void foo23(const vector char, allocator char=
vector char, allocator char ());
};
$ /usr/local/gcc-4.3-20061104/bin/g++ -c junk.cc
junk.cc:16: error: expected ',' or '...' before '' token
junk.cc:16: error: template argument 1 is invalid
junk.cc:16: error: template argument 2 is invalid
junk.cc:16: error: default argument missing for parameter 2 of 'void
Foo::foo23(const std::vectorchar, std::allocatorchar ,
std::allocatorchar)'
--
Summary: gcc rejects valid default template parameter
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: ppluzhnikov at charter dot net
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=30069
[Bug c++/30069] gcc rejects valid default template parameter
--- Comment #1 from ppluzhnikov at charter dot net 2006-12-04 22:46 ---
It turns out that I've already seen this bug in MSVC-6.0,
and found a workaround.
This parses fine (note extra parenthesis) with gcc-3.4.0 and above:
struct Foo {
void foo23(const vector char, allocator char=
(vector char, allocator char ()));
};
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30069
[Bug libmudflap/19319] Mudflap produce many violations on simple, correct c++ program
--- Comment #26 from ppluzhnikov at charter dot net 2006-11-15 01:22
---
(In reply to comment 25)
Confirmed: using newer glibc:
GNU C Library development release version 2.3.5, by Roland McGrath et al.
and having rebuilt gcc-4.3-20061104 on it, I do not see violations on
make-3.81
Confirmed: the test case from comment 21 still shows 1 violation.
-
I also tracked down the violations I see on glibc-2.1.3
Here is the smallest test case:
#include ctype.h
int main()
{
const char *p = a;
return isblank(*p);
}
When compiled with '-fmudflap' there are no violations.
When compiled with '-fmudflap -D_GNU_SOURCE', there is a violation:
***
mudflap violation 1 (check/read): time=1163551808.269474 ptr=0x3feeb302 size=2
pc=0x3ff0d2fd location=`junk.c:6 (main)'
/usr/local/gcc-4.3-20061104/lib/libmudflap.so.0(__mf_check+0x3d)
[0x3ff0d2fd]
[0x8048850]
/usr/local/gcc-4.3-20061104/lib/libmudflap.so.0(__wrap_main+0x49)
[0x3ff0cdb9]
number of nearby objects: 0
In the first case, isblank() expands to call to isblank().
In the second, it expands into
(__ctype_b[(int) ((*p))] (unsigned short int) _ISblank)
And libmudflap (apparently) doesn't understand where __ctype_b
is pointing at. In fact, here is reduced test case that shows
the exact same problem regardless of glibc version:
$ cat junk1.c
extern int *array;
int main()
{
return array[0];
}
$ cat junk2.c
int _array[1];
int *array = _array;
$ gcc -g -c junk2.c
gcc -g -fmudflap junk1.c junk2.o -lmudflap \
-Wl,-rpath=/usr/local/gcc-4.3-20061104/lib ./a.out
***
mudflap violation 1 (check/read): time=1163552372.861362 ptr=0x80c9998 size=4
pc=0xe6d1bd location=`junk1.c:4 (main)'
/usr/local/gcc-4.3-20061104/lib/libmudflap.so.0(__mf_check+0x3d)
[0xe6d1bd]
./a.out(main+0x84) [0x8048748]
/usr/local/gcc-4.3-20061104/lib/libmudflap.so.0(__wrap_main+0x49)
[0xe6cc79]
Nearby object 1: checked region begins 8B after and ends 11B after
mudflap object 0x80ca0f8: name=`__mf_lc_shift'
bounds=[0x80c9990,0x80c9990] size=1 area=no-access check=0r/0w liveness=0
alloc time=1163552372.860997 pc=0xe6cc1d
Nearby object 2: checked region begins 9B after and ends 12B after
mudflap object 0x80ca028: name=`__mf_lookup_cache'
bounds=[0x8049990,0x80c998f] size=524288 area=no-access check=0r/0w liveness=0
alloc time=1163552372.860984 pc=0xe6cc1d
number of nearby objects: 2
The above violation goes away when I add
MUDFLAP_OPTIONS=-heur-start-end, and gmake-3.81 violations go away
when I add MUDFLAP_OPTIONS=-heur-proc-map but I had to dig up the
original mudflap design article:
http://gcc.fyxm.net/summit/2003/mudflap.pdf
to figure this out.
If you expect your future users to figure this out, I've got a
surprise for you: they most likely will not. These heuristics
probably should be enabled by default (at least on Linux), or at
least *prominently* displayed in the info/man pages.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19319
[Bug libmudflap/19319] Mudflap produce many violations on simple, correct c++ program
--- Comment #24 from ppluzhnikov at charter dot net 2006-11-14 04:26 --- Created an attachment (id=12615) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12615action=view) annotated transcript Might the problem be that I am compiling on an old glibc? Or that you didn't invoke ./make and didn't in fact run the resulting exe? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19319
[Bug libmudflap/19319] Mudflap produce many violations on simple, correct c++ program
--- Comment #21 from ppluzhnikov at charter dot net 2006-11-10 23:00
---
I was going to say the same thing, but p.van-hoof beat me to it.
Here is another trivial test case that shows 1 violation:
// Reduced from ex02-04.cpp from STL Tutorial and Reference Guide
#include string
using namespace std;
int main()
{
mapstring, long directory;
directory[Bogart] = 1234567;
directory[Bacall] = 9876543;
}
The violation was reproduced with gcc-4.3-20061104 snapshot on linux-i686.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19319
[Bug libmudflap/19319] Mudflap produce many violations on simple, correct c++ program
--- Comment #22 from ppluzhnikov at charter dot net 2006-11-10 23:30 --- I missed '#include map' in comment 21 above (sorry for cut/paste error). As I said in comment 16, this problem isn't limited to C++ code either. Instrument gmake-3.81, and you'll get 100,000+ violations -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19319
[Bug c++/21976] Incomplete types are not detected at template definition time
--- Comment #3 from ppluzhnikov at charter dot net 2006-10-19 17:34 ---
Here is another (very similar) test case:
template class T struct Dict {
struct Iterator;
Iterator begin() { return Iterator(); } // incomplete
};
template class T struct DictT::Iterator { Iterator() { } };
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21976
[Bug c++/28956] New: Illegal array initialization accepted
Consider:
struct Foo {
Foo(); // comment out - g++ fails with error: invalid initializer
};
void fn()
{
Foo f[2];
Foo g[2] = f;
}
The test above is accepted by g++ (tried 3.4.6, 4.0.0, 4.1.1 and 4.2-20060902).
EDG fails with:
$ edgcpfe pp.cpp
pp.cpp, line 8: error: initialization with {...} expected for aggregate
object
Foo g[2] = f;
^
1 error detected in the compilation of pp.cpp.
Here is the original test case (also accepted by all versions of g++):
template class T, class U
struct pair {
pair(const T t, const U u) : first(t), second(u) { }
T first;
U second;
};
struct Foo {
Foo(); // comment out - g++ fails with
// error: ISO C++ forbids assignment of arrays
};
int main()
{
Foo f[2];
pairint, Foo[2] p (1, f);
return 0;
}
And analysis of it by William M. (Mike) Miller | Edison Design Group, Inc.:
Could you please confirm that this is a g++ bug?
Yes, it's a bug. The Standard (12.6.2 paragraph 3) defines an initialization
like second(u) to be direct-initialization as described in section 8.5.
Section 8.5 paragraph 14 says that initialization of an array object is handled
in section 8.5.1. However, 8.5.1 does not provide for any way of initializing
an array from another array (except for the special case of a string literal,
8.5.2). Arrays can only be initialized to a value using the brace notation,
which is not permitted in a mem-initializer.
--
Summary: Illegal array initialization accepted
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: ppluzhnikov at charter dot net
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=28956
[Bug libmudflap/19319] Mudflap produce many violations on simple, correct c++ program
--- Comment #16 from ppluzhnikov at charter dot net 2005-12-14 17:46 --- Same picture using gcc-4.1-20051209 for i686-pc-linux-gnu: 7 bogus violations on original test, 1 on reduced test. Here are other version results: original reduced gcc-4.1-20051209 i686-pc-linux-gnu 7 1 gcc-4.2-20051210 i686-pc-linux-gnu 1 1 gcc-4.2-20051210 x86_64-unknown-linux-gnu0 0 gcc-4.2-20051210 x86_64-unknown-linux-gnu -m32 1 1 Encouraged by the absence of bogus warnings on x86_64 in 64-bit mode, I tried 4.2-20051210 on my real code. This resulted in 100s of bogus violations, though I have not been able to produce a reduced test case yet :-( I then tried 4.2-20051210 i686 on pure C real code, and got 100s more bogus violations. IMHO, the -fmudflap either needs to be made to work correctly on real C/C++ programs, or it should be removed altogether (bogus reports lead to a lot of wasted time, as each new user discovers the feature, and then finds out it doesn't work). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19319
[Bug c++/24680] New: [accept invalid] Invalid template code accepted
$ cat junk.cc
template typename T
struct List
{
struct D { int size; };
D *d;
List fill(const T t, int size = -1);
};
template typename T
ListT ListT::fill(const T t, int size)
{
resize(size ? 1 : d-size);
return *this;
}
$ /usr/local/gcc-4.1-20051001/bin/g++ -c junk.cc
# silently accepted
Replacing resize(size...); with resize(1); correctly rejects the bogus
source (g++ versions 3.4 and above):
junk.cc: In member function 'ListT ListT::fill(const T, int)':
junk.cc:13: error: there are no arguments to 'resize' that depend on a template
parameter, so a declaration of 'resize' must be available
junk.cc:13: error: (if you use '-fpermissive', G++ will accept your code, but
allowing the use of an undeclared name is deprecated)
--
Summary: [accept invalid] Invalid template code accepted
Product: gcc
Version: 4.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: ppluzhnikov at charter dot net
GCC build triplet: x86_64-redhat-linux
GCC host triplet: x86_64-redhat-linux
GCC target triplet: x86_64-redhat-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24680
[Bug c++/24680] Invalid template code accepted
--- Comment #3 from ppluzhnikov at charter dot net 2005-11-05 01:17 ---
Another variation of the same theme:
template typename T
ListT ListT::fill(const T t, int size)
{
this-resize(1);
this-resize(d-size);
return *this;
}
$ /usr/local/gcc-4.1/bin/g++ -c junk.cc
# silently accepted
$ edgcpfe --gnu_version=30400 junk.cc
junk.cc, line 13: error: class template ListT has no member resize
this-resize(1);
^
junk.cc, line 14: error: class template ListT has no member resize
this-resize(d-size);
^
2 errors detected in the compilation of junk.cc.
# same errors with 'edgcpfe --strict'
BTW, the test case is reduced from Qt4 sources, where 'resize()' is a typo:
reserve() was intended. IOW, g++ is hiding the bug from Qt developers.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24680
[Bug libmudflap/19319] Mudflap produce many violations on simple, correct c++ program
--- Comment #15 from ppluzhnikov at charter dot net 2005-10-23 23:47 --- On stock FC2, using the latest gcc-4.1 snapshot (20051022), I get 7 mudflap violations from the original test, 1 from the reduced test. This doesn't appear to be a heisenbug at all -- it reproduces with all gcc-4.x releases/snapshots on all i686 systems I tried! -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19319
[Bug preprocessor/21250] [4.1 Regression] line number 0 for built-in causes GAS to complain
--- Comment #8 from ppluzhnikov at charter dot net 2005-10-12 06:16 --- The patch above suppresses the '#0 built-in', but not if one does: /usr/local/gcc-4.1-20050813/bin/gcc -v -E -dD - /dev/null in which case it *still* produces (now arguably plain wrong): # 1 stdin #define __STDC_HOSTED__ 1 # 0 built-in #define __GNUC__ 4 # 0 built-in #define __GNUC_MINOR__ 1 ... The patch below makes it emit this instead: # 1 stdin # 1 built-in #define __STDC_HOSTED__ 1 # 1 built-in #define __GNUC__ 4 # 1 built-in #define __GNUC_MINOR__ 1 # 1 built-in #define __GNUC_PATCHLEVEL__ 0 # 1 built-in which roughly matches what gcc-3.x and 2.9x did. May I repeat my question: What is the problem of emitting '#1 built-in' anyway? --- gcc/c-opts.c.orig 2005-07-19 05:09:31.0 -0700 +++ gcc/c-opts.c2005-10-11 22:57:34.0 -0700 @@ -1309,7 +1309,7 @@ cb_file_change (parse_in, linemap_add (line_table, LC_RENAME, 0, - _(built-in), 0)); + _(built-in), 1)); cpp_init_builtins (parse_in, flag_hosted); c_cpp_builtins (parse_in); -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21250
[Bug preprocessor/21250] [4.1 Regression] line number 0 for built-in causes GAS to complain
--- Additional Comments From ppluzhnikov at charter dot net 2005-09-15 23:31 --- The line '#0 built-in' causes trouble for other tools that work with the output from 'gcc -E'; e.g. edgcpfe refuses to parse it: $ gcc -E - /dev/null junk.i edgcpfe --c junk.i stdin, line 1: error: invalid line number # 0 built-in ^ 1 error detected in the compilation of junk.i. What is the problem of emitting '#1 built-in' anyway? Since neither corresponds to a real line number, it's not clear what advantage '#0' has, especially if it is to be suppressed in the output. -- What|Removed |Added CC||ppluzhnikov at charter dot ||net http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21250
[Bug libmudflap/18885] linker does not link libmudflap automatically with -fmudflap
--- Additional Comments From ppluzhnikov at charter dot net 2005-08-19 14:48 --- Note that threaded programs need -lmudflapth instead of -lmudflap. The driver should add correct version of libmudflap automatically, or you'll get bug reports from users who link the wrong version in. Alternatively, libmudflap could use weak unresolved pthread_* symbols, so that a single version of libmudflap works in both threaded and non-threaded environment. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18885
[Bug c++/22008] New: ICE on valid code
The test was reduced from PlumHall test X_132p92:
$ cat x_132p92.cc
struct X_132p92
{
static int k; // [1]
X_132p92(const X_132p92 x);// [2]
};
void f_132p92(volatile X_132p92 x) // [3]
{
bool b = x.k = 1;
}
$ g++4 -c x_132p92.cc
x_132p92.cc: In function รข:
x_132p92.cc:8: internal compiler error: in create_tmp_var, at gimplify.c:368
Please submit a full bug report,
with preprocessed source if appropriate.
See URL:http://gcc.gnu.org/bugs.html for instructions.
Commenting out static at [1], copy-ctor at [2], or volatile at [3]
cures the bug.
--
Summary: ICE on valid code
Product: gcc
Version: 4.0.0
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: ppluzhnikov at charter dot net
CC: gcc-bugs at gcc dot gnu dot org
GCC build triplet: same
GCC host triplet: i386-redhat-linux, x86_64-unknown-linux-gnu
GCC target triplet: same
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22008
[Bug driver/12448] -MT / -MQ don't behave as documented.
--- Additional Comments From ppluzhnikov at charter dot net 2005-02-14 23:37 --- I just bumped into this bug as well. Still failing in gcc-3.4.3 a year later :-( The simplest test case: mkdir pr12448 cd pr12448 touch foo.c gcc -c -o foo.o -MD -MTfoobar foo.c cat foo.d Current output: foobar foo.o: foo.c Expected output: foobar: foo.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=12448
