feb-2002 libstdc++ outstanding

[Benjamin Kosnik]

> Yeah, that one's gonna be fun.  Right now the protection mode is set at
> the bottom-most layer of I/O code under our control.

Yeah. This, filebuf::fd, and filebuf::(special ctors) are all on my 
"to-review ASAP" list. I think a better approach is the Dietmar way.

> Hmm.  That would be an interesting experiment.

Yes, it would.

> IIRC, now that src/concept-inst.cc is in place, a user can simply define
> _GLIBCPP_CONCEPT_CHECKS to activate them on a per-translation-unit basis.
> Rebuilding with --enable-concept-checks isn't required, only convenient.
> (I'll mention this in the next round of doc updates.)

...aaah. Actually, this is probably even better. It would be wicked cool 
if -pedantic turned this on too, I think. The the library and compiler 
would both be super-strict.

> crap crap crap I knew I'd forgotten something.
> First thing tomorrow.  :-)

Thanks.

> > 	sparcv9 ICE on complex_value.cc in libstdc++ test suite
> > 	http://gcc.gnu.org/ml/libstdc++/2002-02/msg00222.html
> > 	complex types completely hosed on sparcv9. 
> 
> Once sparv9 comes back to bootstrap land, I can test possible fixes if
> anybody comes up with them.

I don't see any movement from the back-end folks, sadly. This is 
unfortunate. I believe their is a backend GNATS bug on this.

sparc port              Richard Henderson       rth@redhat.com
sparc port              David S. Miller         davem@redhat.com
sparc port              Jakub Jelinek           jakub@redhat.com

An inspection of the gcc-testresults for today shows it's still present...
http://gcc.gnu.org/ml/gcc-testresults/2002-03/msg00105.html

-benjamin