Hi Tom,
I'm sorry that I did not look on it early. I played with it and there
are some facts. gothic(sparc) and codlin(x86) uses Sun Studio 12 nad I
setup them to use very high optimization.
Gothic:
-------
-xalias_level=basic -xarch=native -xdepend -xmemalign=8s -xO5
-xprefetch=auto,explicit
Codlin:
-------
-xalias_level=basic -xarch=native -xdepend -xO4 -xprefetch=auto,explicit
-xO5 is highest optimization, -xO4 is little bit worse
A play with flags and found that
"-xO4 -xalias_level=basic" generates problem.
"-xO3 -xalias_level=basic" works fine
"-xO5" works fine
As documentation say:
Cite from Sun studio compiler guide:
http://docs.sun.com/app/docs/doc/819-5265/bjapp?a=view
------------------------------------------------------------------------
xalias_level=basic
------------------
If you use the -xalias_level=basic option, the compiler assumes that
memory references that involve different C basic types do not alias each
other. The compiler also assumes that references to all other types can
alias each other as well as any C basic type. The compiler assumes that
references using char * can alias any other type.
For example, at the -xalias_level=basic level, the compiler assumes that
a pointer variable of type int * is not going to access a float object.
Therefore it is safe for the compiler to perform optimizations that
assume a pointer of type float * will not alias the same memory that is
referenced with a pointer of type int *.
-x04
-----
Preforms automatic inlining of functions contained in the same file in
addition to performing -xO3 optimizations. This automatic inlining
usually improves execution speed, but sometimes makes it worse. In
general, this level results in increased code size.
------------------------------------------------------------------------
I redefined bitfields to char in HLWORD and it works. Your guess is
correct. But question still where is the place when bitfields works bad.
Any idea where I should look?
IIRC, I had this problem also on head, when I tried to fix tsearch
regression test for Czech locale. This problem appears and disappears.
Zdenek
Dne 11.03.10 00:37, Tom Lane napsal(a):
Since the buildfarm is mostly green these days, I took some time to look
into the few remaining consistent failures. One is that gothic_moth and
codlin_moth fail on contrib/tsearch2 in the 8.2 branch, with a
regression diff like this:
*** 2453,2459 ****
<body>
<b>Sea</b> view wow<u><b>foo</b> bar</u> <i>qq</i>
<a href="http://www.google.com/foo.bar.html"; target="_blank">YES </a>
! ff-bg
<script>
document.write(15);
</script>
--- 2453,2459 ----
<body>
<b>Sea</b> view wow<u><b>foo</b> bar</u> <i>qq</i>
<a href="http://www.google.com/foo.bar.html"; target="_blank">YES </a>
! ff-bgff-bg
<script>
document.write(15);
</script>
These animals are not testing any branches older than 8.2. The same
test appears in newer branches and passes, but the code involved got
migrated to core and probably changed around a bit.
I traced through this test on my own machine and determined that the
way it's supposed to work is like this: the tsearch parser breaks the
string into a series of tokens that include these:
ff-bg compound word
ff compound word element
- punctuation
bg compound word element
The highlight function is then supposed to set skip = 1 on the compound
word, causing it to be skipped when genhl() reconstructs the text.
The failure looks to me like the compound word is not getting skipped.
Both the setting and the testing of the flag seem to be absolutely
straightforward portable code; although the "skip" struct field is a
bitfield, which is a C feature we don't use very heavily.
My conclusion is that this is probably a compiler bug. Both buildfarm
animals appear to be using Sun Studio, although on different
architectures which weakens the compiler-bug theory a bit. Even though
we are not seeing the failure in later PG branches, it would probably be
worth looking into more closely, because if it's biting 8.2 it could
start biting newer code as well. But without access to a machine
showing the problem it is difficult to do much.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
