Обсуждение: problem compiling with egcs 1.1.1
Hi, I tried to compile 6.4 with latest egcs and have experienced problem to compile several files on my Linux x86 box. Sorry, I don't remember right now actually what files but will reinstall egcs and recompile. This problem is mentioned in egcs FAQ: http://egcs.cygnus.com/faq.html/#asmclobber Egcs becomes popular and I think it would be good if someone could fix sources to be egcs 1.1.1 compilant :-) Regards, Oleg _____________________________________________________________ Oleg Bartunov, sci.researcher, hostmaster of AstroNet, Sternberg Astronomical Institute, Moscow University (Russia) Internet: oleg@sai.msu.su, http://www.sai.msu.su/~megera/ phone: +007(095)939-16-83, +007(095)939-23-83
> I tried to compile 6.4 with latest egcs and have experienced
> problem to compile several files on my Linux x86 box.
I've had success compiling with egcs on Linux in the recent past, using
this version from rpms:
Reading specs from
/usr/local/lib/gcc-lib/i686-pc-linux-gnulibc1/egcs-2.91.57/specs
gcc version egcs-2.91.57 19980901 (egcs-1.1 release)
I don't use this compiler on a regular basis yet, since it has
undesirable rounding behavior for some floating point operations (e.g.
lots of trailing "9"s in some output which are not present in gcc-2.7.x
which screws up the Postgres regression tests).
But I can not recall having any fundamental compilation problems, and
certainly did not have to rewrite assembler code as suggested by your
url reference.
Send some specific examples of problems you are seeing and I can try
them on my libc5 machine.
- Tom
> Egcs becomes popular and I think it would be good if someone > could fix sources to be egcs 1.1.1 compilant :-) I am using EGCS 1.1 for the port to Windows NT ( actually Cygnus B20.1 but that is more or less EGCS 1.1 with some Windows related patches). As far as I can see there is just a little problem with the libpq++. For some reason I cannot link it. Joost Kraaijeveld Askesis B.V. Groenewoudeseweg 46 6524VB Nijmegen tel: 024-3888063 fax: 024-3608416 web: www.askesis.nl
Thomas, gcc version egcs-2.91.57 19980901 (egcs-1.1 release) has no problem to compile 6.4, and 1.1.1 release also compiles 6.4 fine. But several snapshots between 1.1 and 1.1.1 definitely have the problem I described. After that I read the FAQ and returns to 1.1 release. Today I installed 1.1.1 and recompile 6.4 - no problem ! Probably egcs people fixed the problem. Regards, Oleg On Tue, 8 Dec 1998, Thomas G. Lockhart wrote: > Date: Tue, 08 Dec 1998 15:25:04 +0000 > From: "Thomas G. Lockhart" <lockhart@alumni.caltech.edu> > To: Oleg Bartunov <oleg@sai.msu.su> > Cc: pgsql-hackers@postgreSQL.org > Subject: Re: [HACKERS] problem compiling with egcs 1.1.1 > > > I tried to compile 6.4 with latest egcs and have experienced > > problem to compile several files on my Linux x86 box. > > I've had success compiling with egcs on Linux in the recent past, using > this version from rpms: > > Reading specs from > /usr/local/lib/gcc-lib/i686-pc-linux-gnulibc1/egcs-2.91.57/specs > gcc version egcs-2.91.57 19980901 (egcs-1.1 release) > > I don't use this compiler on a regular basis yet, since it has > undesirable rounding behavior for some floating point operations (e.g. > lots of trailing "9"s in some output which are not present in gcc-2.7.x > which screws up the Postgres regression tests). > > But I can not recall having any fundamental compilation problems, and > certainly did not have to rewrite assembler code as suggested by your > url reference. > > Send some specific examples of problems you are seeing and I can try > them on my libc5 machine. > > - Tom > _____________________________________________________________ Oleg Bartunov, sci.researcher, hostmaster of AstroNet, Sternberg Astronomical Institute, Moscow University (Russia) Internet: oleg@sai.msu.su, http://www.sai.msu.su/~megera/ phone: +007(095)939-16-83, +007(095)939-23-83
> gcc version egcs-2.91.57 19980901 (egcs-1.1 release) has no problem
> to compile 6.4, and 1.1.1 release also compiles 6.4 fine.
> Today I installed 1.1.1 and recompile 6.4 - no problem !
> Probably egcs people fixed the problem.
What optimization level do you use? Do you find that the newer version
of egcs does a good job with floating point rounding, or are the
regression tests filled with ".999999" results? I much preferred the
gcc-2.7.x behavior wrt graceful rounding, and hope that at some point
egcs will also have it...
- Tom
> > gcc version egcs-2.91.57 19980901 (egcs-1.1 release) has no problem > > to compile 6.4, and 1.1.1 release also compiles 6.4 fine. > > Today I installed 1.1.1 and recompile 6.4 - no problem ! > > Probably egcs people fixed the problem. > > What optimization level do you use? Do you find that the newer version > of egcs does a good job with floating point rounding, or are the > regression tests filled with ".999999" results? I much preferred the > gcc-2.7.x behavior wrt graceful rounding, and hope that at some point > egcs will also have it... Why do people use egcs? It looks like an experimental version of gcc2, and I am not big on experimental compilers. I want something that works, 100% of the time. -- Bruce Momjian | http://www.op.net/~candle maillist@candle.pha.pa.us | (610) 853-3000+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania19026
"Thomas G. Lockhart" <lockhart@alumni.caltech.edu> writes:
> What optimization level do you use? Do you find that the newer version
> of egcs does a good job with floating point rounding, or are the
> regression tests filled with ".999999" results? I much preferred the
> gcc-2.7.x behavior wrt graceful rounding, and hope that at some point
> egcs will also have it...
Are you sure you are right to blame the compiler? I should think this
would be a C library issue, not the compiler's fault...
regards, tom lane
> Are you sure you are right to blame the compiler? I should think this
> would be a C library issue, not the compiler's fault...
Well, I've *got* to blame something! ;)
In my limited testing, the only variable was the compiler. I did not
change the C library. So, one can point fingers at the compiler for not
behaving the same as the old compiler, or one can surmise that there is
a deeper story of older C library misbehavior which was covered up by
the older compiler in a great conspiracy. I leaned toward blaming the
compiler, on the assumption that for most simple math compilers probably
generate inline code rather than going to a library. It may be that for
any compiler at high optimization levels you tend to see rounding
problems since they don't bother cleaning up results.
Don't know what the real story is, just that the ".9999" behavior
reminds me of my Unix boxes from a dozen years ago, not my recent ones.
So, has anyone tried a new egcs with a new glibc2? I figured that since
Oleg is a bleeding-edge kind of guy (new egcs, Linux kernel 2.1.1xx,
etc.) he probably has that new combination.
- Tom
On Wed, 9 Dec 1998, Thomas G. Lockhart wrote: > Date: Wed, 09 Dec 1998 17:58:39 +0000 > From: "Thomas G. Lockhart" <lockhart@alumni.caltech.edu> > To: Tom Lane <tgl@sss.pgh.pa.us> > Cc: pgsql-hackers@postgreSQL.org > Subject: Re: [HACKERS] problem compiling with egcs 1.1.1 > > > Are you sure you are right to blame the compiler? I should think this > > would be a C library issue, not the compiler's fault... > > Well, I've *got* to blame something! ;) > > In my limited testing, the only variable was the compiler. I did not > change the C library. So, one can point fingers at the compiler for not > behaving the same as the old compiler, or one can surmise that there is > a deeper story of older C library misbehavior which was covered up by > the older compiler in a great conspiracy. I leaned toward blaming the > compiler, on the assumption that for most simple math compilers probably > generate inline code rather than going to a library. It may be that for > any compiler at high optimization levels you tend to see rounding > problems since they don't bother cleaning up results. > > Don't know what the real story is, just that the ".9999" behavior > reminds me of my Unix boxes from a dozen years ago, not my recent ones. > > So, has anyone tried a new egcs with a new glibc2? I figured that since > Oleg is a bleeding-edge kind of guy (new egcs, Linux kernel 2.1.1xx, > etc.) he probably has that new combination. Hey, I'm not very bleeding edge man :-) I'm still afraid glibc2 (I'm slackware based Linuxoid). I'm using egcs almost everyday and the only problem I got was compilation of 6.4 with some snapshot of 6.4. I'm glad in 1.1.1 release the problem was gone. But on production servers ( I have 6 ppros ) I even never installed egcs. I hate to have additional problem but I want to test perspective tool for myself on my private computers to have own opinion. Oleg > > - Tom > _____________________________________________________________ Oleg Bartunov, sci.researcher, hostmaster of AstroNet, Sternberg Astronomical Institute, Moscow University (Russia) Internet: oleg@sai.msu.su, http://www.sai.msu.su/~megera/ phone: +007(095)939-16-83, +007(095)939-23-83
On Wed, 9 Dec 1998, Bruce Momjian wrote:
> > > gcc version egcs-2.91.57 19980901 (egcs-1.1 release) has no problem
> > > to compile 6.4, and 1.1.1 release also compiles 6.4 fine.
> > > Today I installed 1.1.1 and recompile 6.4 - no problem !
> > > Probably egcs people fixed the problem.
> >
> > What optimization level do you use? Do you find that the newer version
> > of egcs does a good job with floating point rounding, or are the
> > regression tests filled with ".999999" results? I much preferred the
> > gcc-2.7.x behavior wrt graceful rounding, and hope that at some point
> > egcs will also have it...
>
> Why do people use egcs? It looks like an experimental version of gcc2,
> and I am not big on experimental compilers. I want something that
> works, 100% of the time.
EGCS is about as 'experimental' as PostgreSQL, actually. From
what I've read about EGCS, its basically GCC in a more open development
model/scenario...those using and playing with it have anon-cvs access to
the source code, can follow along with the development, and have very open
and visible access to the developers...
About the only 'truly experimental' nature to EGCS is that there
are alot more ppl whom have access to the source code at development
stages, compoared to GCC where you basically see a release and that's
it...
Marc G. Fournier
Systems Administrator @ hub.org
primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org
> On Wed, 9 Dec 1998, Bruce Momjian wrote: > > > > > gcc version egcs-2.91.57 19980901 (egcs-1.1 release) has no problem > > > > to compile 6.4, and 1.1.1 release also compiles 6.4 fine. > > > > Today I installed 1.1.1 and recompile 6.4 - no problem ! > > > > Probably egcs people fixed the problem. > > > > > > What optimization level do you use? Do you find that the newer version > > > of egcs does a good job with floating point rounding, or are the > > > regression tests filled with ".999999" results? I much preferred the > > > gcc-2.7.x behavior wrt graceful rounding, and hope that at some point > > > egcs will also have it... > > > > Why do people use egcs? It looks like an experimental version of gcc2, > > and I am not big on experimental compilers. I want something that > > works, 100% of the time. > > EGCS is about as 'experimental' as PostgreSQL, actually. From That bad, huh. :-) Only joking. > what I've read about EGCS, its basically GCC in a more open development > model/scenario...those using and playing with it have anon-cvs access to > the source code, can follow along with the development, and have very open > and visible access to the developers... > > About the only 'truly experimental' nature to EGCS is that there > are alot more ppl whom have access to the source code at development > stages, compoared to GCC where you basically see a release and that's > it... I agree gcc2 took a long time to become usable, and it seemed to take too long, and the egcs people think the development model was part of the cause perhaps. I can see that. We add stuff in PostgreSQL, and with so many other people testing, we get good quick feedback that allows us to be more aggressive in adding features. Has anyone compared the code output or speed comparisons? -- Bruce Momjian | http://www.op.net/~candle maillist@candle.pha.pa.us | (610) 853-3000+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania19026
On Wed, 9 Dec 1998, Bruce Momjian wrote:
> I agree gcc2 took a long time to become usable, and it seemed to take
> too long, and the egcs people think the development model was part of
> the cause perhaps. I can see that. We add stuff in PostgreSQL, and
> with so many other people testing, we get good quick feedback that
> allows us to be more aggressive in adding features.
As do they...the egcs mailing list is pretty constant as far as
busy is concerned, with bug reports submitted daily on "todays" cvs
repository...its very scary :)
Marc G. Fournier
Systems Administrator @ hub.org
primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org
On Wed, Dec 09, 1998 at 05:58:39PM +0000, Thomas G. Lockhart wrote: > In my limited testing, the only variable was the compiler. I did not > change the C library. So, one can point fingers at the compiler for not > behaving the same as the old compiler, or one can surmise that there is > a deeper story of older C library misbehavior which was covered up by > the older compiler in a great conspiracy. I leaned toward blaming the > compiler, on the assumption that for most simple math compilers probably > generate inline code rather than going to a library. It may be that for > any compiler at high optimization levels you tend to see rounding > problems since they don't bother cleaning up results. FWIW, I understand this to be a problem mostly on the x86 architecture, where the floating point registers have higher precision than memory storage. Thus the results are somewhat unpredictable, depending on whether registers are spilled into memory. The -ffloat-store will help with explictly named variables, but not temporary intermediate results. While the egcs people may find a nice fix (the whole register spilling issue is being worked on), apparently the C standard is very clear that the .9999 behaviour is allowed. So perhaps fixing the postgres code is the best idea in the long run. Anthony
> On Wed, Dec 09, 1998 at 05:58:39PM +0000, Thomas G. Lockhart wrote: > > In my limited testing, the only variable was the compiler. I did not > > change the C library. So, one can point fingers at the compiler for not > > behaving the same as the old compiler, or one can surmise that there is > > a deeper story of older C library misbehavior which was covered up by > > the older compiler in a great conspiracy. I leaned toward blaming the > > compiler, on the assumption that for most simple math compilers probably > > generate inline code rather than going to a library. It may be that for > > any compiler at high optimization levels you tend to see rounding > > problems since they don't bother cleaning up results. > > FWIW, I understand this to be a problem mostly on the x86 architecture, > where the floating point registers have higher precision than memory > storage. Thus the results are somewhat unpredictable, depending on whether > registers are spilled into memory. The -ffloat-store will help with > explictly named variables, but not temporary intermediate results. Yes 80-bits vs. 64-bits. If the computation hits memory, you loose precision. A definate problem, and compiler-specific. -- Bruce Momjian | http://www.op.net/~candle maillist@candle.pha.pa.us | (610) 853-3000+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania19026
> While the egcs people may find a nice fix (the whole register spilling
> issue is being worked on), apparently the C standard is very clear
> that the .9999 behaviour is allowed. So perhaps fixing the postgres
> code is the best idea in the long run.
Thanks for the background. This is probably a good time to go slow, and
see if the compiler gets fixed up. Although the .9999 behavior may be
allowed, afaik most modern compilers seem to clean things up better than
that. No point putting work into code to work around an evolving
compiler for a single platform, at least not until it is clear that it
is a permanent feature.
- Tom