At (time_t)712734125 "Martin v. Loewis" wrote:
> As you can see from PR#3747, this apparently comes from ptrdiff_t
> being signed on some architecture and unsigned on another. What part
> of the explanation in this PR is unclear to you?
I understand (more or less) why the compiler finds ambiguity
> > See PR#3747 at http://gcc.gnu.org/cgi-bin/gnatsweb.pl
> >
> > The fix is to not use unsigned int as a type in an overridden []
> > operator. changing the [] operator to have type int works.
>
> That fix did allow ftpgrab to compile under hppa, but I'm baffled
> as to how this can not be consi
> > > Why is it happening? Is it so because of more complex templates in recent
> > > libstdc++?
> >
> > If you are asking for compilation speed, yes, the main cause it that
> > libstdc++ consists of many more templates now. If you are asking for a
> > slow-down in an application, you need to provi
Package: libstdc++3
Version: 1:3.0.2-3
Severity: wishlist
Is libstdc++ still so much in flux on the stable branch that
(>= exact-version) in the shlibs file is justified?
Please cut us some slack and bump the version in the shlibs only when
necessary. Otherwise the move of programs that absolutel
> See PR#3747 at http://gcc.gnu.org/cgi-bin/gnatsweb.pl
>
> The fix is to not use unsigned int as a type in an overridden []
> operator. changing the [] operator to have type int works.
That fix did allow ftpgrab to compile under hppa, but I'm baffled
as to how this can not be considered a bug.
"Martin v. Loewis" wrote:
> > When compiling the same programs with these compilers, g++ 2.95 is
> > much (sometimes 3 times) faster than g++ 3.0, even without
> > optimizing (without -O).
>
> Not sure what you asking. Are you saying g++ 2.95 is faster, or that
> the generated code is faster?
>
>
6 matches
Mail list logo
