Re: [HACKERS] Platforms with v6.3 trouble
От | Bruce Momjian |
---|---|
Тема | Re: [HACKERS] Platforms with v6.3 trouble |
Дата | |
Msg-id | 199802251519.KAA10778@candle.pha.pa.us обсуждение исходный текст |
Ответ на | Platforms with v6.3 trouble ("Thomas G. Lockhart" <lockhart@alumni.caltech.edu>) |
Список | pgsql-hackers |
> > >From what I understand, there are at least two platforms which are > having trouble with the macro inlining in v6.3. The alpha ports have > trouble inlining the slock assembler code, and the SCO port has trouble > inlining the cache lookup code. > > Since these macros were inlined only for performance reasons, would it > be possible to revert to non-inline function calls for these platforms? > It would seem that substituting a macro expansion for a compiled routine > could be done with a compiler switch (e.g. USE_INLINING) so it could be > turned on and off at will. > > For most of us, the performance gains are fantastic, but for those ports > which broke performance has degraded to zero :( Yes, how do we do that? Do we have inlined-versions of these files? Sounds messy. Can people run cpp separately on the files, then compile them? I wonder. I think this is an SCO-only problem, and seeing as their native compilers are notoriously buggy (Microsoft/SVr4 code), it is no wonder. The alpha problem has been solved by having a s_lock.c file, that only contains the alpha/linux locking code. They don't have local asm labels, and hence the workaround. I believe this is not a problem issue for 6.3. Anyone? Of course, we still have the initdb problem, or do we? -- Bruce Momjian | 830 Blythe Avenue maillist@candle.pha.pa.us | Drexel Hill, Pennsylvania 19026 + If your life is a hard drive, | (610) 353-9879(w) + Christ can be your backup. | (610) 853-3000(h)
В списке pgsql-hackers по дате отправления: