Re: icc vs. gcc-style asm blocks ... maybe the twain can meet?
От | Tom Lane |
---|---|
Тема | Re: icc vs. gcc-style asm blocks ... maybe the twain can meet? |
Дата | |
Msg-id | 13659.1440976586@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | icc vs. gcc-style asm blocks ... maybe the twain can meet? (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: icc vs. gcc-style asm blocks ... maybe the twain can meet?
|
Список | pgsql-hackers |
I wrote: > I came across some websites suggesting that icc will handle gcc-style > asm blocks as long as you give it the -fasm-blocks command line option. > It would be awfully nice to get rid of the __INTEL_COMPILER special > cases in s_lock.h and the atomics headers --- would someone who has > icc at hand check into this theory? Hmm ... wait a second. The main collection of asm blocks in s_lock.h believes that Intel's compiler will take gcc-style asm without any help: #if defined(__GNUC__) || defined(__INTEL_COMPILER) It has believed that since 2003. There are just two stanzas in s_lock.h that think icc needs its own implementation; one was introduced in 2005 and the other in 2014, and I'm betting both of them are confused about it. The other places where __INTEL_COMPILER is used to exclude an asm block are also of relatively recent vintage. I'm suspecting that they are cargo-cult programming rather than actually necessary special cases. It's possible that these extra implementations are worth the trouble to carry because icc is smarter about those special intrinsics than it is about asm blocks. However, unless someone can point to some solid evidence of that, I think we should get rid of 'em. That code is quite enough of an #ifdef snake's nest without carrying versions we don't demonstrably need. regards, tom lane
В списке pgsql-hackers по дате отправления: