Bruce Momjian wrote:
Without looking at the code (I'm home now) the main difference is that the .s file will somewhere need a .text section. The issue in a .c file is that one is already in the context of a .text section given that one is in the tas_dummy() {} basic block. The .data and .text sections in the embedded asm code is then just confusing the assembler. When the optimizer is turned on, the .sections are possibly relocated, which allows the fbe backend to successfully compute the .size value.Tom Lane wrote:Alan Stange <stange(at)rentec(dot)com> writes:Tom Lane wrote:Nobody else has complained of this, so the least you could do is identify which Solaris version and exactly which compiler you'retalking about.I just tried building on all of these combinations:Solaris 10: compilers 6.2 and 11Solaris 9: compilers 8, 9, 10, 11 Solaris 8: compilers 6.2, 9, 11Postgresql 8.1.3 fails to compile on all of them with --enable-debugOK, that's a reasonably convincing sample ;-). Will fix. Thanks for the report!Uh, backend/port/tas/solaris*.s ASM files have "section" like: .section ".text" Are these OK? I didn't see you report any problems with these.
I'll remove the _tas: assembler code from the s_lock.c file and test if the code compiles/runs on one or two solaris+compiler combinations. I'll certainly compile on all again just to be sure.
-- Alan