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
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
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 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
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
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
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 --with
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 both
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 /
"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
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 besid
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
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 iness
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 OpenBSD-fo
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 fo
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 /usr/lib/gcc-lib/sparc64-unknown-openbsd3.6/3.3.2/specs
Configure
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 buil
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:
> http://www.pgbui
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 beli
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:
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=spoonbil
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:
> http://www.pgbuildfarm.org/cgi-bin/show_log.pl?nm=spoonbill&dt=2004-11-18%201
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=spoonbill&dt=2004-11-18%2016:02:58
cheers
andrew
---(e
23 matches
Mail list logo
