|From:||Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>|
|To:||YunQiang Su <wzssyqa(at)gmail(dot)com>|
|Subject:||Re: BUG #15844: MIPS: remove .set mips2 in s_lock.h to fix r6 build|
|Views:||Raw Message | Whole Thread | Download mbox | Resend email|
YunQiang Su <wzssyqa(at)gmail(dot)com> writes:
> Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> 于2019年6月16日周日 下午12:28写道：
>> I found that specifying -march=mips2 gets it to accept the s_lock.h
>> code without ".set mips2". Given that we don't make any pretense of
>> actually running on MIPS-I hardware, I wonder if some hack involving
>> forcing -march would be sane? You'd get better code quality across
>> the board, presumably.
> -march is not a good idea, since r6 cannot compatible with the previous version.
> If you use -march=mips2 or something else, it will failed to build for r6.
> Which -march to use should be determined by finial user or distribution vendor.
Sure, the trick would be to not override a (default or specified)
architecture setting that's higher than mips2. I was imagining
using AC_EGREP_CPP() to see if __mips expands to exactly 1. But
on reflection, probably a better idea is to just see if asm with
ll/sc/sync compiles, and add -march=mips2 if not.
(We should not do anything if --disable-spinlocks has been specified,
btw, since then we don't need those asm commands to work. This is
and would remain the workaround for building PG for MIPS-I, if some
benighted soul insists on doing that.)
>> (BTW, have you got any recommendations for booting recent Debian/MIPS
>> under qemu? I can't get anything newer than wheezy to work.)
> I have an r6 one:
> It is buster.
Thanks for the pointer.
regards, tom lane
|Next Message||Tao Xu||2019-06-17 02:08:38||Re: BUG #15853: DROP TABLE CASCADE drops sequence that other tables depend on|
|Previous Message||Tom Lane||2019-06-16 14:15:22||Re: BUG #15854: postgres wtih Docker: binding port fails with release greater than 9.6.13|