Tom Lane said:
> Andrew Dunstan <andrew@dunslane.net> writes:
>> I am seeing a strange failure on the new box Sun donated, when trying
>> to
>
>> ccache gcc -O2 -fno-strict-aliasing -g -Wall -Wmissing-prototypes
>> -Wmissing-declarations -c tas.s /usr/ccs/bin/ld -r -o SUBSYS.o
>> dynloader.o pg_sema.o pg_shmem.o tas.o ld: fatal: relocation error:
>> R_SPARC_32: file tas.o: symbol <unknown>: offset 0xec1 is non-aligned
>> [etc]
>
>> What is odd is that the identical file seems to succeeed on the later
>> 8.0 and 8.1 branches.
>
> The solaris_sparc.s file seems identical in these branches up to CVS
> label ... but are the compilation options the same? The critical fix
> might be somewhere in the configure/Makefile chain.
Yes - see later email where I concluded that.
>
> Another thing to try is whether it works without ccache. We've seen
> plenty of trouble from that tool :-(
I am still waiting to see a smoking gun on it. So far there has been some
smoke but no gun or fire (sorry for mixed metaphor).
What I am thinking of doing is having buildfarm blow away the cache on
failure, so that ccache would be forced to recompile fropm scratch unless
the last case was a success. Thoughts?
>> Why do we have "mov 1,%o0" immediately followed by "mov 0,%o0"?
>
> Better read up on branch delay slots...
>
Yes, ok, I understand. I must have forgotten that one had to write the
assembler in that non-linear fashion to get the benefit of saving an
instruction cycle.
cheers
andrew
