| From: | Zdenek Kotala <Zdenek(dot)Kotala(at)Sun(dot)COM> |
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Cc: | pgsql-hackers(at)postgreSQL(dot)org, postgresbuildfarm(at)Sun(dot)COM |
| Subject: | Re: gothic_moth, codlin_moth failures on REL8_2_STABLE |
| Date: | 2010-03-11 16:32:02 |
| Message-ID: | 4B991B02.6080103@sun.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2010-03-11 16:37:45 | Re: gothic_moth, codlin_moth failures on REL8_2_STABLE |
| Previous Message | Pavel Stehule | 2010-03-11 16:03:15 | Re: tsearch profiling - czech environment - take 55MB |