On Mon, 2 Oct 2000, Tom Lane wrote:
> "Emils Klotins" <emils@grafton.lv> writes:
> > RedHat Linux 6.2 on Alphaserver DS10 (egcs-1.1.2, glibc-2.1.3,
> > libstdc++-2.9.0).
> > Postgresql-7.0.2 source
>
> > Compiles and installs just fine. However, both the regular initdb and
> > parallel regression testing's initdb stage fails with a core file and
> > message:
>
> > FATAL: s_lock (2030d360) at spin.c:116, stuck spinlock. Aborting.
> > FATAL: s_lock (2030d360) at spin.c:116, stuck spinlock. Aborting.
>
> I was just fooling with PG on a RedHat Alpha box that DEC kindly
> loaned to the project. It looks like the above problem is caused
> by compiler optimization; although src/template/linux_alpha
> optimistically sets CFLAGS=-O2, I had to back off to -O1 to avoid
> that same spinlock complaint, and I couldn't get 7.0.* to pass
> regression tests with anything but -O0. (And even there, there
> were a bunch of failures in the datetime-related tests; it looks
> like our abstime datatype breaks rather badly on this platform.)
To get pgsql running correctly (spinlocks and regression tests) on
Linux/Alpha, one needs the patches off of my web site (as someone already
pointed out in another response to this thread). You can reduce the
optimization levels on the compiler and make some progress, but w/o the
patches, you get nowhere in the end.
Also, some versions of egcs have been known to have problems on
Linux/Alpha, especially when it comes to optimization levels beyond the
default (none). I do know that gcc 2.95.2 (as distributed w/Debian 2.2)
works just fine with -O2. I seem to remember someone mentioning the
compiler with RedHat 6.2 does not work, and they had to upgrade to the
2.95.2 version before the optimization flags were safe.
Of course, there is no release of RH7 for alpha yet (that I know
of), but on the Intel side there are some rumblings that RedHat used a
somewhat broken version of gcc. On top of that, I never quite figured out
the alignment between the egcs and the gcc version numbers (i.e. how does
egcs 1.1.2 relate to gcc 2.95.2?).
I can tell you that with the patches on my web site and the gcc
2.95.2 compiler, everything works great with pgsql. Beyond that, I can not
promise you anything. If anyone wants to test on other compilers, I am
more than glad to help in anyway that I can. And if they report back to me
the results, I will add them to my web page.
> I haven't had time yet to try current sources on that box, but
> I'm optimistic that the new function manager will solve a lot of
> portability problems on Alphas. Still, I don't understand why -O2
> breaks spinlocks --- maybe egcs is misoptimizing around the inline
> assembly code of tas() ?
The last current sources I tested, about a month ago (8/15),
compiled w/o a single problem on my system (Debian 2.2, gcc 2.95.2), w/o
any patches and w/-O2. In other words, the need for special patches for
Linux/Alpha was removed, and now compiles out of the box. Once I get a bit
of time I plan to test more current snapshots, and will of course report
my results.
And yes, the new function manager made about 90% of the 7.0.2
Linux/Alpha patches unneeded. The rest I '#ifdef {linux-alpha}'ed and
submitted a patch (quite short if I remember), which was accepted. Even
patched the regression tests results for geometry to match the Linux/Alpha
output (which actually matched a few other platforms as well). So now even
all regression tests as well. :)
As for the spinlock, it is a compiler problem. At one time it had
non-local labels and therefore could not be inlined (i.e. multiple labels
w/the same name resulteD), but I fixed it by replacing all the labels with
local ones about a year or more ago. Compilers on Linux/Alpha have a
history of misbehaving when it came to the more aggressive optimization.
Only recently has most of the wrinkles been ironed out.
That is my two cents, hope they are of use. TTYL.
---------------------------------------------------------------------------
| "For to me to live is Christ, and to die is gain." |
| --- Philippians 1:21 (KJV) |
---------------------------------------------------------------------------
| Ryan Kirkpatrick | Boulder, Colorado | http://www.rkirkpat.net/ |
---------------------------------------------------------------------------
