https://sourceware.org/bugzilla/show_bug.cgi?id=20427
--- Comment #5 from Nick Clifton <nickc at redhat dot com> --- Hi Stefan, > So, this is what happens if i re-write the test32.S program for the Sun > SPARC assembler: > .comm .gomp_critical_user_, 64, 8 > Relocation section '.rela.data' at offset 0xf8 contains 1 entries: > Offset Info Type Sym. Value Symbol's Name + Addend > 00000004 00000303 R_SPARC_32 00000008 .gomp_critical_user_ + 0 Interesting. I wonder if this is a bug in the Solaris assembler ? Maybe it knows that a symbol's value can only ever be 32-bits, so in this particular case the reloc will work. But what if the test really needed a (non-zero) 64-bit value to be installed into the memory location. For example, how does the Solaris assembler handle this: .data .global __kmp_unnamed_critical_addr __kmp_unnamed_critical_addr: .xword .gomp_critical_user_ + 0x1234567890 .type __kmp_unnamed_critical_addr,#object .size __kmp_unnamed_critical_addr, .-__kmp_unnamed_critical_addr Looking at the output for GAS, it seems that the addition in the reloc is truncated: 00000000 R_SPARC_UA64 .gomp_critical_user_+0x34567890 This is not reported as an error, either, so presumably it is expected behaviour. Which makes me think that your patch will be OK. But I would like to know the results of your search for other 64-bit tests. Cheers Nick -- You are receiving this mail because: You are on the CC list for the bug. _______________________________________________ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils