Bug#175799: package description deceptive
Package: libstdc++5 Version: 1:3.2.2-0pre3 Severity: normal libstdc++3 - The GNU stdc++ library version 3 libstdc++3-dbg - The GNU stdc++ library version 3 (debugging files) libstdc++3-dev - The GNU stdc++ library version 3 (development files) libstdc++3-doc - The GNU stdc++ library version 3 (documentation files) libstdc++5 - The GNU stdc++ library version 3 libstdc++5-dbg - The GNU stdc++ library version 3 (debugging files) libstdc++5-dev - The GNU stdc++ library version 3 (development files) libstdc++5-doc - The GNU stdc++ library version 3 (documentation files) libstdc++5-pic - The GNU stdc++ library version 3 (shared library subset kit) What's wrong with that picture? (hint: 3 != 5) -- System Information: Debian Release: testing/unstable Architecture: powerpc Kernel: Linux redwald 2.4.19-powerpc #1 Mon Sep 9 09:01:43 EDT 2002 ppc Locale: LANG=C, LC_CTYPE=C Versions of packages libstdc++5 depends on: ii gcc-3.2-base 1:3.2.2-0pre3 The GNU Compiler Collection (base ii libc6 2.3.1-9 GNU C Library: Shared libraries an ii libgcc11:3.2.2-0pre3 GCC support library -- no debconf information
Bug#175809: Strange or incorrect floating point behaviour
Package: g++-3.2
Version: 3.2.2 20021212 (Debian prerelease)
Note that this problem most likely is present in other g++ versions, and
also, in similar forms, in other gcc languages.
It was discussed in comp.lang.c++.moderated, cf.
news:<[EMAIL PROTECTED]> and the followup postings.
Posters suggested it might be a bug in the implementation of
-ffloat-store and/or related to floating point expressions evaluated at
compile-time and at runtime with different precisions.
Mathematically, a >= b implies ka >= kb for k >= 0. While I'm well
aware that not all properties of the reals carry over to floating point
arithmetic, I certainly would expect this *particular* implication to
carry over. However, g++ -O3 thinks otherwise.
In the code below, the last assertion fails under certain circumstances.
It's these circumstances which make the behaviour really mysterious:
The assertion does *not* fail if *any* of the following conditions is
satisfied:
1) The bound() template is replaced by a function. (Change the #if 1 to
#if 0.)
2) Lines (1) or (2) are commented out.
3) 2.5 is replaced by other values, e.g. 4.
4) -O2 is specified instead of -O3 (it *does*, however, fail with
-O2 -ffloat-store).
My first guess was that this has something to do with internal usage of
80 bit floating point values, but this doesn't go well with observation
4).
#include
#if 1
template< typename T > inline void bound( T & x , T const& u
) {
#else
inline void bound( double& x , double const& u
) {
#endif
assert( 1. <= u ) ;// (1)
if( x < 1. ) { x = 1. ; } // (2)
if( x > u ) { x = u ; }
}
int main() {
const double u = 2.1 ;
double x = 3 ;
bound( x , u ) ;
assert( u >= x ) ;
assert( 2.5*u >= 2.5*x ) ; // fails!!!
}
--
| voice: +43 (0)676 6253725 *** web: http://www.cosy.sbg.ac.at/~gwesp
|
| Passts auf, seid's vuasichdig, und lossds eich nix gfoin!
| -- Dr. Kurt Ostbahn
gcc-3.2 not autobuilding on ARM?
Looking at the 'update_excuses' and buildd logs, it seems the most recent version of gcc-3.2 isn't building on ARM. It's failing after a veerry long command line which appears to have improperly embedded carriage returns in it (though that could be an artifact of the logging). That's as far as I could get without an ARM to work on. This is gonna keep the newest gcc-3.2 out of testing; anyone looking at it? --Nathanael
Re: gcc-3.2 not autobuilding on ARM?
Nathanael Nerode writes: > Looking at the 'update_excuses' and buildd logs, it seems the most > recent version of gcc-3.2 isn't building on ARM. It's failing after a > veerry long command line which appears to have improperly embedded > carriage returns in it (though that could be an artifact of the > logging). That's as far as I could get without an ARM to work on. > This is gonna keep the newest gcc-3.2 out of testing; anyone > looking at it? I hope Phil will be looking at this. We should not take care of testing at this point. some architectures don't even have glibc-2.3.1 at the moment.
Re: gcc-3.2 not autobuilding on ARM?
Further investigation indicates that it's almost certainly due to bogus line breaks in the middle of the command line. This appeared when autobuilding ds3-0pre3, but not ds2-0pre3, and only on ARM. I still don't know where the line breaks are coming from.
Re: gcc-3.2 not autobuilding on ARM?
On Wed, Jan 08, 2003 at 10:58:01AM -0500, Nathanael Nerode wrote: > Further investigation indicates that it's almost certainly due to bogus line > breaks in the middle of the command line. This appeared when autobuilding > ds3-0pre3, but not ds2-0pre3, and only on ARM. > > I still don't know where the line breaks are coming from. Are you looking at the same log I am? More likely the breaks are just emitted due to the logs being passed back and forth via email; mail daemons have this odd prejudice against buffer-overflowing length lines. It's failing linking libjava. If I had to guess, I'd say that it ran out of memory. Libjava is stupidly large. -- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer
Bug#175809: Strange or incorrect floating point behaviour
On Wed, Jan 08, 2003 at 10:16:35AM +0100, Gerhard Wesp wrote:
> Package: g++-3.2
> Version: 3.2.2 20021212 (Debian prerelease)
>
> Note that this problem most likely is present in other g++ versions, and
> also, in similar forms, in other gcc languages.
>
> It was discussed in comp.lang.c++.moderated, cf.
> news:<[EMAIL PROTECTED]> and the followup postings.
> Posters suggested it might be a bug in the implementation of
> -ffloat-store and/or related to floating point expressions evaluated at
> compile-time and at runtime with different precisions.
>
> Mathematically, a >= b implies ka >= kb for k >= 0. While I'm well
> aware that not all properties of the reals carry over to floating point
> arithmetic, I certainly would expect this *particular* implication to
> carry over. However, g++ -O3 thinks otherwise.
> My first guess was that this has something to do with internal usage of
> 80 bit floating point values, but this doesn't go well with observation
> 4).
I don't _think_ this is a bug, but my floating point fu is fairly weak.
> #include
>
> #if 1
> template< typename T > inline void bound( T & x , T const& u
> ) {
> #else
> inline void bound( double& x , double const& u
> ) {
> #endif
> assert( 1. <= u ) ;// (1)
> if( x < 1. ) { x = 1. ; } // (2)
> if( x > u ) { x = u ; }
> }
At whatever particular flags work or not, I bet this is complex enough
to cause or not cause the value to be computed at run time. Roughly.
> int main() {
> const double u = 2.1 ;
2.1 can not be represented precisely in IEEE FP, of course.
> double x = 3 ;
>
> bound( x , u ) ;
>
> assert( u >= x ) ;
> assert( 2.5*u >= 2.5*x ) ; // fails!!!
The compiler is certainly allowed to compute 2.5*u at compile time. It
does so using an extremely high precision real library, if I recall
correctly. This could be a bug in that library but it's more likely
that the result is a more accurate answer to one bit or thereabouts.
Use a debugger/disassembler? Tell us what the numbers actually _are_?
--
Daniel Jacobowitz
MontaVista Software Debian GNU/Linux Developer
Re: gcc-3.2 not autobuilding on ARM?
On Wed, 2003-01-08 at 15:32, Matthias Klose wrote: > Nathanael Nerode writes: > > Looking at the 'update_excuses' and buildd logs, it seems the most > > recent version of gcc-3.2 isn't building on ARM. It's failing after a > > veerry long command line which appears to have improperly embedded > > carriage returns in it (though that could be an artifact of the > > logging). That's as far as I could get without an ARM to work on. > > This is gonna keep the newest gcc-3.2 out of testing; anyone > > looking at it? > > I hope Phil will be looking at this. We should not take care of testing at > this point. some architectures don't even have glibc-2.3.1 at the moment. Yes, I'm on the case. I'm also trying to debug the bootstrap failure with gcc-snapshot. p.
Re: gcc-3.2 not autobuilding on ARM?
On Wed, 2003-01-08 at 15:32, Matthias Klose wrote: > I hope Phil will be looking at this. We should not take care of testing at > this point. some architectures don't even have glibc-2.3.1 at the moment. BTW, all architectures except hurd-i386 have glibc-2.3.1 built now. p.
array wrapper
Hello,
thank you for maintaining gcc and libraries.
Inspired a little by libstdc++5-doc:
/usr/share/doc/gcc-3.2-base/libstdc++/html/23_containers/wrappers_h.txt
I use attached array wrapper.
Probably it could be useful for others, but don't know where to post
it.
It is nice to erite in my numerical program
WALK_THROUGH_WITH(Elements, e) {
// compute something on element *e
}
instaed of fidling with pointers. I pay nothing for it, no run time,
no memory.
Best regards
Hans
--
You can find a Vim desktop calendar here: http://www.moolenaar.net/
Happy Vimming in 2003!
/*
* Demo of the not so big generalization (templating) of the array;
* Hans Ginzel <[EMAIL PROTECTED]>
* created: 7.1.2003
*/
#include
#include "array.h"
#define E_MEM 5
int compare_int(const void *aa, const void *bb) {
const int *a = (const int *)aa,
*b = (const int *)bb;
return *a < *b ? -1
: *a > *b ? 1
: 0;
}
int main() {
TArray A;
if (A.Init(5)==0) {
cerr << "Cannot allocate memory for Container" << endl;
return E_MEM;
}
cout << "A.size = " << A.size() << endl;
A[3]=5;
cout << "A[3] = " << A[3] << endl;
int i=10;
for (typeof(A.begin()) c = A.begin(); A.eof(c); A.next(c), i--) {
*c = i*i;
cout << *c << endl;
if (i==7) cerr << "Item " // n-th element, indexing from zero
<< A.index(c) << " contains error." << endl;
}
A.sort(&compare_int);
cout << endl << "Sorted: " << endl;
WALK_THROUGH_WITH(A, c) { cout << *c << endl; }
typeofAI(A) n = A.index(1);
unsigned int o = 2;
cout << endl << "A[1] = " << *n
<< "\t A[2+2] = " << *A.offset(n, o) << endl;
return 0;
}
// vi: set ts=4 sw=4 nowrap:
/*
* Not so big generalization (templating) of the array;
* without any peformance or memory lost.
*
* Hans Ginzel <[EMAIL PROTECTED]>
* created: 7.1.2003
*
* Probably use -O3 or -finline-functions by compiling.
* See /usr/share/doc/gcc-3.2-base/libstdc++/html/23_containers/wrappers_h.txt
*
* This header file is free software WITHOUT ANY WARANTY;
* you can redistribute it and/or modify it under the terms of the
* GNU General Public License (http://www.gnu.org/copyleft/gpl.html).
*
*/
#ifndef ARRAY_H
#define ARRAY_H
#include
#define ptr_int long
template
class TArray {
private:
N _n;
T*_p;
public:
TArray() { _p = 0; _n = 0; }
~TArray() { if (_p!=0) { delete[] _p; } }
inline N Init (const N n) { _p = new T[n];
return _n = _p==0 ? 0 : n; }
inline T * begin () const { return _p; }
inline T * end () const { return _p + _n; }
inline bool begof (const T *p) const { return p < _p; } // prior to begin of array
inline bool eof (const T *p) const { return p >= _p + _n; } // beyond the end of array
inline T * next (T *&p) const { return p++; }
inline T * prev (T *&p) const { return p--; }
inline T * succ (T *&p) const { return p+1; }
inline T * prec (T *&p) const { return p-1; }
inline T * first () const { return _p; }
inline T * last () const { return _p + _n - 1; }
inline T & operator [] (N const i) { return _p[i]; }
inline T * index (const N n) const { return _p + n; }
inline N index (T *p) const { return (N)(p - _p); }
inline N size () const { return _n; }
inline T * offset (T *p,
const signed ptr_int o) const { return p + o; }
inline void sort () { qsort(_p, _n, sizeof(T), &T::compare); } // Declare compare() static in T!
inline void sort ( int(*compare)(const void *, const void *) )
{ qsort(_p, _n, sizeof(T), compare); }
inline void sort ( T *start, N count )
{ qsort(start, count, sizeof(T), &T::compare); }
inline void sort ( T *start, N count,
int(*compare)(const void *, const void *) )
{ qsort(start, count, sizeof(T), compare); }
};
#define typeofAI(A) typeof((A).begin()) // typeof(Array.Item) *
#define WALK_THROUGH_WITH(A, v) for (typeofAI(A) (v) = (A).begin();\
! (A).eof((v)); A.next((v)))
#undef ptr_int
#endif /*ARRAY_H*/
// vi: set ts=4 sw=4 nowrap:
Bug#175799: package description deceptive
Branden Robinson writes: > Package: libstdc++5 > Version: 1:3.2.2-0pre3 > Severity: normal > > libstdc++3 - The GNU stdc++ library version 3 > libstdc++5 - The GNU stdc++ library version 3 See http://gcc.gnu.org/libstdc++/: What... is your name? The GNU Standard C++ Library v3, or libstdc++-v3. Older snapshots of this library were given the name libstdc++-2.9x up until the release of GCC 3. This is a complete rewrite from the previous libstdc++-v2. Any idea how to make this clearer in the package description?
Bug#175799: package description deceptive
On Wed, Jan 08, 2003 at 10:57:30PM +0100, Matthias Klose wrote: > Branden Robinson writes: > > Package: libstdc++5 > > Version: 1:3.2.2-0pre3 > > Severity: normal > > > > libstdc++3 - The GNU stdc++ library version 3 > > libstdc++5 - The GNU stdc++ library version 3 > > See http://gcc.gnu.org/libstdc++/: > > What... is your name? > > The GNU Standard C++ Library v3, or libstdc++-v3. Older snapshots of > this library were given the name libstdc++-2.9x up until the release > of GCC 3. This is a complete rewrite from the previous libstdc++-v2. > > Any idea how to make this clearer in the package description? So the "version" no longer equals the shared object version? If that's the case, I suggest a short paragraph in the package's extended description clarifying this. -- G. Branden Robinson|Men use thought only to justify Debian GNU/Linux |their wrong doings, and speech only [EMAIL PROTECTED] |to conceal their thoughts. http://people.debian.org/~branden/ |-- Voltaire pgpvRz0tgtMVr.pgp Description: PGP signature
Bug#175799: package description deceptive
On Thu, Jan 09, 2003 at 12:22:00AM +0100, Matthias Klose wrote: > wording/spelling/intention clear? > > Description: The GNU Standard C++ Library v3 > This package contains an additional runtime library for C++ programs > built with the GNU compiler. > . > libstdc++-v3 is a complete rewrite from the previous libstdc++-v2, which > was included up to g++-2.95. The first version of libstdc++-v3 appeared > in g++-3.0. Well, what really confused me was the disconnect between the soversion and the "version". But this happens with other things, too. If it's not a FAQ, then I'd say go with what you've got above and close the bug. If it *is* a FAQ, I suggest explaining the incongruity. :) Thanks for guiding my stupid mind through this. -- G. Branden Robinson| Debian GNU/Linux | If encryption is outlawed, only [EMAIL PROTECTED] | outlaws will @goH7Ok=http://people.debian.org/~branden/ | pgpIzLz8tH0PM.pgp Description: PGP signature
(ad) Internet Domain Free Auction Site - Visit NOW !
Title: Nabitel information broadcast mail Sorry for interrupting you - click refuse for no more mail... - Welcome to Domain Free Auction site - Domain Auction: Do you want to sell or buy Internet domains? The DomainLinkers.com is the best place to deal your domains! Do not hesitate to visit NOW! Sell or Buy Your Internet Domains ! Have a nice day. Thank you.
