On November 23, 2004 06:18 pm, Michael Fuhr wrote:
On Tue, Nov 23, 2004 at 12:47:28PM -0800, Darcy Buskermolen wrote:
I'm guessing we need to add some more configure logic to detect gcc
versions 3.4 on sparc trying to produce 64bit code and disable
optimizations, or else bail out and ask
On November 19, 2004 10:55 am, you wrote:
The answer is: it's a gcc bug. The attached program should print
x = 12.3
y = 12.3
but if compiled with -O or -O2 on Stefan's machine, I get garbage:
$ gcc -O ftest.c
$ ./a.out
x = 12.3
y = 1.47203e-39
$ gcc -v
Reading specs from
Tom Lane wrote:
Darcy Buskermolen [EMAIL PROTECTED] writes:
I can confirm this behavior on Solaris 8/sparc 64 as well.
bash-2.03$ gcc -m64 -O2 test.c
bash-2.03$ ./a.out
x = 12.3
y = 2.51673e-42
bash-2.03$ gcc -m64 -O3 test.c
bash-2.03$ ./a.out
x = 12.3
y = 12.3
bash-2.03$
Hmm. I hadn't
On Tue, Nov 23, 2004 at 09:57:03AM -0800, Darcy Buskermolen wrote:
I can confirm this behavior on Solaris 8/sparc 64 as well.
gcc 3.4.2 on Solaris 9/sparc 64 appears to be okay.
% gcc -v
Reading specs from /usr/local/lib/gcc/sparc-sun-solaris2.9/3.4.2/specs
Configured with: ../configure
Darcy Buskermolen wrote:
On November 19, 2004 10:55 am, you wrote:
The answer is: it's a gcc bug. The attached program should print
x = 12.3
y = 12.3
but if compiled with -O or -O2 on Stefan's machine, I get garbage:
$ gcc -O ftest.c
$ ./a.out
x = 12.3
y = 1.47203e-39
$ gcc -v
Reading specs from
Stefan Kaltenbrunner [EMAIL PROTECTED] wrote:
Darcy Buskermolen wrote:
On November 19, 2004 10:55 am, you wrote:
The answer is: it's a gcc bug. The attached program should print
x = 12.3
y = 12.3
but if compiled with -O or -O2 on Stefan's machine, I get garbage:
$ gcc -O ftest.c
On November 23, 2004 11:37 am, Jim Seymour wrote:
Stefan Kaltenbrunner [EMAIL PROTECTED] wrote:
Darcy Buskermolen wrote:
On November 19, 2004 10:55 am, you wrote:
The answer is: it's a gcc bug. The attached program should print
x = 12.3
y = 12.3
but if compiled with -O or -O2 on
On Tue, Nov 23, 2004 at 12:47:28PM -0800, Darcy Buskermolen wrote:
I'm guessing we need to add some more configure logic to detect gcc versions
3.4 on sparc trying to produce 64bit code and disable optimizations, or else
bail out and ask them to upgrade.
Shouldn't that be gcc versions 3.3?
On Tue, Nov 23, 2004 at 11:34:44AM -0700, Michael Fuhr wrote:
gcc 3.4.2 on Solaris 9/sparc 64 appears to be okay.
But gcc 3.3.2 on Solaris 9/sparc 64 isn't.
% gcc -m64 test.c
% ./a.out
x = 12.3
y = 12.3
% gcc -O -m64 test.c
% ./a.out
x = 12.3
y = 2.51673e-42
% gcc -O2 -m64 test.c
% ./a.out
Tom Lane wrote:
Andrew Dunstan [EMAIL PROTECTED] writes:
Meanwhile, what do we do? Turn off -O in src/template/openbsd for
some/all releases?
Certainly not. This problem is only known to exist in one gcc version
for one architecture, and besides it's only affecting (so far as we can
tell) one
Stefan Kaltenbrunner said:
Tom Lane wrote:
Andrew Dunstan [EMAIL PROTECTED] writes:
Meanwhile, what do we do? Turn off -O in src/template/openbsd for
some/all releases?
Certainly not. This problem is only known to exist in one gcc version
for one architecture, and besides it's only
Andrew Dunstan [EMAIL PROTECTED] writes:
I guess my concern is that on Sparc64/OpenBSD-3.6* at least, this bug is
exposed by the seg tests but might well occur elsewhere and bite us in
various unpleasant ways.
The experimentation I did to develop the test case suggested that the
problem only
Tom Lane wrote:
The answer is: it's a gcc bug. The attached program should print
x = 12.3
y = 12.3
but if compiled with -O or -O2 on Stefan's machine, I get garbage:
$ gcc -O ftest.c
$ ./a.out
x = 12.3
y = 1.47203e-39
woa - scary. I will report that to the OpenBSD-folks upstream - many
thanks
Stefan Kaltenbrunner wrote:
Tom Lane wrote:
The answer is: it's a gcc bug. The attached program should print
x = 12.3
y = 12.3
but if compiled with -O or -O2 on Stefan's machine, I get garbage:
$ gcc -O ftest.c
$ ./a.out
x = 12.3
y = 1.47203e-39
woa - scary. I will report that to the
Andrew Dunstan [EMAIL PROTECTED] writes:
Meanwhile, what do we do? Turn off -O in src/template/openbsd for
some/all releases?
Certainly not. This problem is only known to exist in one gcc version
for one architecture, and besides it's only affecting (so far as we can
tell) one rather
The fix for unflushed changed to pg_database records seems to have fixed
the problem we were seeing on spoonbill ... but it is now seeing
problems with the seg module:
http://www.pgbuildfarm.org/cgi-bin/show_log.pl?nm=spoonbilldt=2004-11-18%2016:02:58
cheers
andrew
Andrew Dunstan [EMAIL PROTECTED] writes:
The fix for unflushed changed to pg_database records seems to have fixed
the problem we were seeing on spoonbill ... but it is now seeing
problems with the seg module:
Tom Lane wrote:
Andrew Dunstan [EMAIL PROTECTED] writes:
The fix for unflushed changed to pg_database records seems to have fixed
the problem we were seeing on spoonbill ... but it is now seeing
problems with the seg module:
Andrew Dunstan [EMAIL PROTECTED] writes:
We're only seeing it now because up to now the run on this platform was
bombing out on the error you so brilliantly fixed last night.
Consistently? I'd have thought that problem would only fail once in a
while. It's hard to believe the timing would
Tom Lane wrote:
Andrew Dunstan [EMAIL PROTECTED] writes:
We're only seeing it now because up to now the run on this platform was
bombing out on the error you so brilliantly fixed last night.
Consistently? I'd have thought that problem would only fail once in a
while. It's hard to
Andrew Dunstan [EMAIL PROTECTED] writes:
Tom Lane wrote:
Consistently? I'd have thought that problem would only fail once in a
while. It's hard to believe the timing would work out to make it a 100%
failure.
You can see the history of the latest build runs here:
Tom Lane wrote:
Can we get personal accounts on the buildfarm
machines?
That's up to the owner of each machine - it's a distributed system.
I've sent email to the owner of this one.
When I get a few minutes soon I hope to start some discussion on
-hackers about what members we want in the
22 matches
Mail list logo
