|From:||YunQiang Su <wzssyqa(at)gmail(dot)com>|
|To:||Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>|
|Cc:||Andres Freund <andres(at)anarazel(dot)de>, pgsql-bugs(at)lists(dot)postgresql(dot)org|
|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|
Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> 于2019年6月18日周二 上午12:50写道：
> Andres Freund <andres(at)anarazel(dot)de> writes:
> > I think we're pretty much at the point where we should just rip out all
> > of our own spinlock implementations for non-common platforms, and solely
> > rely on compiler intrinsics... The open coded ASM really doesn't age
> > very well, and there's very little chance of us actually testing them
> > properly.
> It's completely not true that this code isn't tested; we have two
> different MIPS buildfarm machines that surely exercise spinlocks plenty.
Since NetBSD set the default ISA as MIPS I, and then we use ".set mips2",
in fact a bug.
I think that we should use some non-asm code for MIPS I ( our own
Do you have any NetBSD image that I can have a test of new patch?
> (There's a separate argument to be had about whether we should drop
> source-code support for platforms that aren't represented in the
> buildfarm. I'm not inclined to, but you could tenably hold that
> As for compiler intrinsics, I dunno. I don't have very much faith in
> the quality of those for non-mainstream platforms, either --- see
> for a not-too-old example. And a lot of platforms like this are running
> pretty old compilers, so even if the problems have been fixed it'll be a
> long time before we can depend on that.
> regards, tom lane
|Next Message||PG Bug reporting form||2019-06-22 17:49:15||BUG #15868: Creating foreign key fails to find data key that exists|
|Previous Message||Edward J. Sabol||2019-06-22 03:13:42||Re: BUG #15867: psql \copy from program does not work|