This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
Re: ostream and long long
- To: Phil Edwards <pedwards at disaster dot jaj dot com>
- Subject: Re: ostream and long long
- From: Andris Pavenis <andris at hal dot astr dot lu dot lv>
- Date: Fri, 27 Jul 2001 00:09:35 +0300 (EEST)
- cc: Gabriel Dos Reis <gdr at codesourcery dot com>, David Durham <david dot durham at wcom dot com>, <gcc-bugs at gcc dot gnu dot org>
On Thu, 26 Jul 2001, Phil Edwards wrote:
> On Thu, Jul 26, 2001 at 10:53:46AM +0300, Andris Pavenis wrote:
> > On 25 Jul 2001, Gabriel Dos Reis wrote:
> > > If --enable-long-long, then the accompanying C99 mathematical
> > > functions should be availble for long long support. They are not
> > > unreleated.
> >
> > Do we really need sqrtf(), sqrtl(), sinl() and similar functions to
> > support long long? I think the best would be to check for functions
> > we really need for --enable-long-long instead of disabling it
> > if at least one of functions added with c99 is missing
>
> Your definition of "functions we really need" for long long support may be
> very different from somebody else's. If all you want to do with a long
> long is print it, then no, sqrtl() isn't needed for op<<. Maybe another
> user thinks of "really" supporting long long as just being able to do
> basic trig, and overloaded operators are an extra unnecessary feature.
But this for configuring libstdc++-v3 but not something else, so I think
the crititical question is what libstdc++-v3 needs to support
--enable-long-long. Also sqrtl() is function for taking square root from
long double and as I think it's not related to support of long long
support. And the same is about widfe character related functions.
> Gaby is correct; this was a tricky rat's nest in the past. And even if it
> were possible to /easily/ separate "support for printing long long" from
> "support for long long trig" from "support for long long <foo>", I really
> don't want to see a bunch of different enabling/disabling macros through
> the code. Either it works or it doesn't; either we support it or we don't.
>
> Rather than try to split long long support into pieces along arbitrary
> "this is basic support / no, only this over here is basic support" lines,
> I'd prefer to concentrate on why the ENABLE_LONG_LONG result flag is being
> set to false, when the config.log seems to show that they are supported.
So for many targets (I think) this support will be disabled however
it could be supported.
Andris