On Wed, 2008-01-02 at 20:02 +0100, Martin Michlmayr wrote:
> Herbert, do you think you could take a quick long at this bug report
> before I forward it upstream to the GCC folks?
well, I couldn't reproduce that on a Debian EABI system with
ii gcc 4:4.2.2-1
ret
-- I'd say that's a regression...
>
> Herbert Valerio Riedel writes:
> > Package: libstdc++5-3.3-dev
> > Version: 1:3.3-2
> > Severity: minor
> >
> >
> > I just noticed, that std::conj() doesn't ge
template
struct Foo::InFoo2 {
// ...this still triggers error
};
regards,
--
Herbert Valerio Riedel /Phone: (EUROPE) +43-1-58801-18840
Email: [EMAIL PROTECTED] /Finger [EMAIL PROTECTED] for GnuPG Public
Key
GnuPG Key Fingerprint: 7BB9 2D6C D485 CE64 4748 5F65 4981 E064 883F 4142
On Sat, 2003-05-31 at 10:35, Martin v. Löwis wrote:
> Herbert Valerio Riedel <[EMAIL PROTECTED]> writes:
> > ...so... is _still_ not a buggy behaviour??
>
> No. Look at 8.5/9:
>
> # If no initializer is specified for an object, and the object is of
> # (possibly cv
On Fri, 2003-05-30 at 22:08, Phil Edwards wrote:
> On Fri, May 30, 2003 at 09:26:32PM +0200, Herbert Valerio Riedel wrote:
> > $ cat static_var.cc
> >
> > class bar {
> > public:
> > int operator()(int i) { return i; }
> > //bar (void) {} // default
Package: g++-3.3
Version: 1:3.3-2
Severity: normal
I'm not sure, whether this should work according to the ISO C++ specs or
not; IMHO it should work... :-)
$ cat static_var.cc
class bar {
public:
int operator()(int i) { return i; }
//bar (void) {} // default constructor
};
const bar b = ba
.end()). However, a call m.erase(p) where p is m.end() is a
> serious error that could corrupt the container."
--
Herbert Valerio Riedel /Phone: (EUROPE) +43-1-58801-18840
Email: [EMAIL PROTECTED] /Finger [EMAIL PROTECTED] for GnuPG Public
Key
GnuPG Key Fingerprint: 7BB
Package: libstdc++5-3.3-dev
Version: 1:3.3-2
Severity: normal
...according to TC++PL 3rd ed, section 17.4.1.7,
"Erasing end() is harmless."
but the following code either hangs or crashes when the end() iterator
is being passed to erase();
*** set_erase.cc
#include
#include
#include
int
ma
Package: libstdc++5-3.3-dev
Version: 1:3.3-2
Severity: minor
I just noticed, that std::conj() doesn't get inlined, as one'd expect it
to be;
it seems that a forward declaration like
template complex<_Tp> conj(const complex<_Tp>&);
keeps
template
inline complex<_Tp>
conj(const comp
Package: g++-3.3
Version: 1:3.3-2
Severity: normal
g++-3.3 fails to compile the following code (which would compile with
previous g++ versions):
$ cat in_class_class.cc
class Foo {
template struct InFoo;
};
template<>
struct Foo::InFoo {
// ...
};
$ g++ -c in_class_class.cc
in_class_cla
Package: g++-3.2
Version: 1:3.2.3-0pre6
Severity: normal
$ apt-get install libsigc++-1.2-dev
$ echo 'int main() {}' > main.cc
$ g++-3.2 -O2 -Wall -o main main.cc -lsigc-1.2
/usr/lib/gcc-lib/hppa-linux/3.2.3/../../../libsigc-1.2.so: undefined
reference to `__gxx_personality_v0'
/usr/lib/gcc-lib/hp
-0pre3 The GNU C++ compiler.
ii gcc-3.2-base 1:3.2.1-0pre3 The GNU Compiler Collection (base
ii libc6-dev 2.2.5-14.3GNU C Library: Development Librari
ii libstdc++5 1:3.2.1-0pre3 The GNU stdc++ library version 3
--
Herbert Valerio Riedel <[EMAIL PROTECTED]>
SE/Linux LU
Package: libstdc++5-dev
Version: 1:3.2.1-0pre3
Severity: normal
on debian/sparc /usr/include/c++/3.2/sparc-linux/bits/c++config.h states
incorrectly the existence of long double c math functions, thus
including causes the following kind of errors:
[..]
/usr/include/c++/3.2/cmath: In function `l
Package: g++-3.2
Version: 1:3.2.1-0pre2
Severity: important
see also
http://gcc.gnu.org/gcc-3.2/c++-abi.html
"g++-3.2 -v" outputs
Reading specs from /usr/lib/gcc-lib/alpha-linux/3.2.1/specs
Configured with: /build/buildd/gcc-3.2-3.2.1ds1/src/configure -v
--enable-languages=c,c++,java,f77,prot
14 matches
Mail list logo
