late 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-redha
--- Comment #3 from ppluzhnikov at charter dot net 2005-11-05 01:17 ---
Another variation of the same theme:
template
List &List::fill(const T &t, int size)
{
this->resize(1);
this->resize(d->size);
return *this;
}
$ /usr/local/gcc-4.1/bin/g++ -c j
--- 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
ich 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
--- Comment #3 from ppluzhnikov at charter dot net 2006-10-19 17:34 ---
Here is another (very similar) test case:
template struct Dict {
struct Iterator;
Iterator begin() { return Iterator(); } // incomplete
};
template struct Dict::Iterator { Iterator
--- Additional Comments From ppluzhnikov at charter dot net 2005-09-15
23:31 ---
The line '#0 ' 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
--- Comment #8 from ppluzhnikov at charter dot net 2005-10-12 06:16 ---
The patch above suppresses the '#0 ', 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):
#
--- 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 reproduc
--- 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 versi
[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:
--- 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 -MTf
--- 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"
#incl
--- Comment #22 from ppluzhnikov at charter dot net 2006-11-10 23:30
---
I missed '#include ' 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+ vio
--- 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=12615&action=view)
annotated transcript
Might the problem be that I am compiling on an "old" glibc?
Or that
--- 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
ctor >&,
std::allocator)'
--
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 or
--- 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, a
17 matches
Mail list logo
