Please delete this bug as this report does not contain kernal and libc info.
There is a duplicate bug 222377 which does.
Package: g++-2.95
Version: 1:2.95.4-19
When combine working with int32 and int64, not all operations performed
correctly.
Here is code example
=begin
#include
#include
#include
int main()
{
const long int offset = 1025;
FILE* F = fopen("samplefile", "r");
fseek(F, of
Package: g++-2.95
Version: 1:2.95.4-19
When combine working with int32 and int64, not all operations performed
correctly.
Here is code example
=begin
#include
#include
#include
int main()
{
const long int offset = 1025;
FILE* F = fopen("samplefile", "r");
fseek(F, of
> On Wed, Aug 21, 2002 at 11:55:27AM +0300, Alexei Khlebnikov wrote:
> > > I think this program should not terminate at all because i will
> > > always be one greater than oldi.
> > > I think gcc3.0 has a problem with no optimization then but since
> > > ther
> I think this program should not terminate at all because i will
> always be one greater than oldi.
> I think gcc3.0 has a problem with no optimization then but since
> there is later version that works gcc 3.1.1, upgrade.
With no optimization the program runs correctly by the rules of integers
r
>> I think, libs compiled with gcc 2.95 just should reside in separate
>> directory, say, /usr/lib/gcc-2.95-compat. Gcc 3.2.x should be run as
>> gcc or gcc-3.2. Gcc 2.95.x should be run as gcc-2.95.
>
>That will work; the question then is how to automatically create all
>those packages - you'ld n
> When g++ 3.2 becomes the next Debian compiler, it will be necessary to
> recompile a lot of packages. Also, it will be necessary to have the
> old binary packages, and their shared libraries, coexist.
>
> Is there a specific plan to implement this coexistence? I can think of
> the following strat
On Tue, 29 Jan 2002 14:31:03 -0500
Daniel Jacobowitz <[EMAIL PROTECTED]> wrote:
DJ> You should add swap space in that case. And:
>> Note that /etc/security/limits.conf contains these lines:
>> *harddata10
>> *hardrss 10
>> *
On Tue, 29 Jan 2002 11:03:02 -0500 (EST)
"Christopher C. Chimelis" <[EMAIL PROTECTED]> wrote:
CCC> On Tue, 29 Jan 2002, Daniel Jacobowitz wrote:
>> > I have a problem: my shared library cannot be linked, because it's too
>> > big (all objs are 140 megs in size). I compile sources with "-g" option
Hello all.
I have a problem: my shared library cannot be linked, because it's too big (all
objs are 140 megs in size). I compile sources with "-g" option. As I
understand, g++ produces level 2 debug info in stubs+ format.
I want to use breakpoints and see stack backtraces. Can I switch to level
On Fri, 25 Jan 2002 08:22:18 +0100
"J.H.M. Dassen (Ray)" <[EMAIL PROTECTED]> wrote:
JD(> [Please do not use HTML in email. This is email, not the web]
JD(> On Fri, Jan 25, 2002 at 16:57:10 +1300, Etienne Le Sueur wrote:
>> I have recently tried to install g++, using dpkg. When I do so, dpkg
>> re
On Wed, 16 Jan 2002 13:36:47 +0300
"ALEXANDER SHISHCKIN" <[EMAIL PROTECTED]> wrote:
AS> Hi everyone!
AS> Here's my trouble: a few days ago I've upgraded gcc
AS> to 3.0 and the package name no longer looks like 'gcc',
AS> but 'gcc-3.0'.
AS> Now other packages depending on 'gcc' fail to install.
AS>
Hm, seems like you still not configured russian support. Let's continue in
english.
On Tue, 15 Jan 2002 11:03:56 +0300
Alexander Shishckin <[EMAIL PROTECTED]> wrote:
>> Во-вторых, если конфликт с версиями библиотек, надо апгрейдить библиотеки,
>> а не компилятор.
AS> Ok, I got my compiler up an
On Mon, 14 Jan 2002 14:31:04 +0300
"ALEXANDER SHISHCKIN" <[EMAIL PROTECTED]> wrote:
AS> I got trouble when upgrading from GCC 2.95 to 3.0.3.
AS> None of the programs are working with it saying that
AS> GNU C compiler can make binaries or so.
AS> Where can I get info on fixing this?
Please describ
Wartan Hachaturow wrote:
> What is the best (easiest :) way to get a gcc capable of
> producing i386-aout targets? I've apt-getted the source of
> gcc-2.95, but it has really scared me, and I didn't found
> the way to accomplish this.
AFAIK, producing i386-aout targets is a linker's, not compiler
Ugh, sorry for late answer. I was ill and thinked about this subject.
"Martin v. Loewis" wrote:
> > Please answer somebody wether it is a bug and wether I should submit it to
> > GNATS.
>
> I believe this is not a bug, because there are no const-qualified
> function types in C++.
>
> If you don'
Suryakant wrote:
> Can anyone please point me where I can get installabel gcc compiler
> (gcc 2.9.1 . or later but stable )
You can get any release you want from http://gcc.gnu.org.
Hello there.
Seems like I've discovered a bug in g++-3.0 (or, at least, g++-2.95).
The following code is rejected by g++-3.0:
template
void tpl_func (const TFunc& func)
{
return;
}
static bool compare_ints (int a, int b)
{
return (a < b);
}
Hello, maintainers.
I don't know what the package has the bug, so I write to 3 maintainers
(packages: menu, dwww, libstdc++3-doc).
I have the following versions of these packages installed on my system:
ii menu 2.1.5-10 provides update-menus functions for some app
ii dwww
"Martin v. Loewis" wrote:
> > > > 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
> >
"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?
>
>
Hello all.
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).
Why is it happening? Is it so because of more complex templates in recent
libstdc++?
Is g++ 3.0 really a step further ?
Regards,
Alex
Zoltan Nagy wrote:
> When I use the g++-3.0 ( gcc version 3.0.2 20010922 (Debian prerelease)
> ) the compiler doesn't link the libstdc++. It might be a bug.
Firstly, the compiler does not link at all. It is linker's task.
Secondly, the linker links it [libstdc++] fine for me (g++ is the same vers
"Martin v. Loewis" wrote:
> > Probably, I've found an error in libstdc++. I can't catch "out_of_range"
> > exception.
> This is not a bug in the library, but in your code. You need to
> include before using out_of_range.
Thank you very much for explaining.
My appologies to you and all the reade
Probably, I've found an error in libstdc++. I can't catch "out_of_range"
exception.
This is the code:
=== begin ===
#include
using namespace std;
int func (vector vec, unsigned idx)
{
try { return vec[idx]; }
catch (out_of_range e) { /* do smth */ }
}
=== end ===
After a command "g++ -c err
G++ emits strange warning. It is really annoying me, because I include similar
header to many files.
This is the code.
=== begin ===
template
class A
{
//public:
private:
typedef _TTN _TN;
};
template
class B : virtual public A <_TN, _NY>
{
_TN func () = 0;
};
=== end ===
This warning messag
"Martin v. Loewis" wrote:
> I think so. I fail to see the bug in your report, though. Your code is
> illegal (or, rather, ill-formed - some GNU coding style advises us not
> to claim that you are breaking the law by writing the code).
>
> > template
> > struct SGBMb : public SGBb <_TW>
> > {
> >
Am doing right by posting this here? (A copy has gone to GNATS as well.)
== begin error.cpp ==
template
struct SGBb
{
typedef _TTW _TW;
_TW sy;
void* st;
SGBb <_TW> (_TW _sy, void* _st)
: sy (_sy), st (_st) {}
};
template
struct SGBMb : public SGBb <_TW>
{
typedef _TTWO _TWO;
Andrey Rybakov wrote:
> g++ depend on libstdc++2.10-dev
> libstdc++2.10-dev depend on g++
It's not a bug, it's a feature. :)
It means that these 2 packages should be installed together.
(Forget rpm, enjoy dpkg! :)
"Christopher C. Chimelis" wrote:
> On Mon, 23 Jul 2001, Alexei Khlebnikov wrote:
>
> > I am faced with a problem: my classes hierarchy is not compiled by G++ 3.0
> > Debian prerelease.
>
> Can you send me the code and a copy of the failure? I can try to com
Hello all.
I am faced with a problem: my classes hierarchy is not compiled by G++ 3.0
Debian prerelease.
I use woody branch and I don't want to switch to sid because I want to have a
somewhat stable system.
G++ 3.0 Debian prerelease ICEs on my (legal) code. I've wrote a bug report to
GNATS and re
31 matches
Mail list logo
