Re: gothic_moth, codlin_moth failures on REL8_2_STABLE
| От | Zdenek Kotala |
|---|---|
| Тема | Re: gothic_moth, codlin_moth failures on REL8_2_STABLE |
| Дата | |
| Msg-id | 4B991B02.6080103@sun.com обсуждение исходный текст |
| Ответ на | gothic_moth, codlin_moth failures on REL8_2_STABLE (Tom Lane <tgl@sss.pgh.pa.us>) |
| Ответы |
Re: gothic_moth, codlin_moth failures on REL8_2_STABLE
(Tom Lane <tgl@sss.pgh.pa.us>)
|
| Список | 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
В списке pgsql-hackers по дате отправления: