Re: Spinlocks and compiler/memory barriers
От | Robert Haas |
---|---|
Тема | Re: Spinlocks and compiler/memory barriers |
Дата | |
Msg-id | CA+TgmoYsd+_MBWfHUTZc0sPxvWsjnjHcM-NYNMs6SY198C84ww@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Spinlocks and compiler/memory barriers (Robert Haas <robertmhaas@gmail.com>) |
Ответы |
Re: Spinlocks and compiler/memory barriers
|
Список | pgsql-hackers |
On Tue, Jul 1, 2014 at 12:22 PM, Robert Haas <robertmhaas@gmail.com> wrote: >>> Since we have a Sun Studio machine in the buildfarm, we shouldn't give >>> up on SPARC completely, but maybe we should only add the cases for >>> sparcv8+ and above? That at least has some chance of getting tested. >> >> That we have code for sparcv7 is ridiculous btw. Sparcv8 (not 8+/9) is >> from 1992. v7/sun4c been dropped from solaris 8 if I see that correctly. >> >> I agree that v8 (in contrast to v8+ aka v9 in 32bit mode) support has to >> go as well. I'd personally vote for backpatching a note to >> installation.sgml saying that it's probably not working, and not do >> anything else there. That means we also should replace the ldstub by cas >> in the the gcc inline assembly - but we have buildfarm members for that, >> so it's not too bad. > > If you want to do that, it's fine with me. What I would do is: > > - Back-patch the addition of the sparcv8+ stuff all the way. If > anyone's running anything older, let them complain... > - Remove the special case for MIPS without gcc intrinsics only in > master, leaving the back-branches broken. If anyone cares, let them > complain... > - Nothing else. I've gone ahead and done the second of these things. Andres, do you want to go take a stab at fixing the SPARC stuff? -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
В списке pgsql-hackers по дате отправления: