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
--- 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
--- 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
--- 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
--- 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
--- 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
--- 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
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
--- 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
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
--- 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
--- 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
--- 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
--- 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
--- 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
.
--
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
--- 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
17 matches
Mail list logo