[Bug 215819] head r311147's clang 3.9.1 for powerpc64: locore.o generation messed up: generates R_PPC64_ADDR16_DS instead of R_PPC64_TOC16_DS with .toc

2017-01-10 Thread bugzilla-noreply
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=215819 --- Comment #6 from Mark Millard --- Created attachment 178691 --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=178691=edit Have TOC_REF(...) in instructions use @toc notation for clang Have TOC_REF(...) in

[Bug 215819] head r311147's clang 3.9.1 for powerpc64: locore.o generation messed up: generates R_PPC64_ADDR16_DS instead of R_PPC64_TOC16_DS with .toc

2017-01-07 Thread bugzilla-noreply
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=215819 --- Comment #3 from Mark Millard --- (In reply to Mark Millard from comment #0) I found how to control the behavior based on the assembler notation @toc being missing vs. being present. If llvm should change is

[Bug 215819] head r311147's clang 3.9.1 for powerpc64: locore.o generation messed up: generates R_PPC64_ADDR16_DS instead of R_PPC64_TOC16_DS with .toc

2017-01-06 Thread bugzilla-noreply
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=215819 --- Comment #2 from Mark Millard --- (In reply to Mark Linimon from comment #1) -r311147 is just the version I tested. It does not show how long the problem has existed. Usually folks want to know if the current (or

[Bug 215819] head r311147's clang 3.9.1 for powerpc64: locore.o generation messed up: generates R_PPC64_ADDR16_DS instead of R_PPC64_TOC16_DS with .toc

2017-01-06 Thread bugzilla-noreply
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=215819 Mark Linimon changed: What|Removed |Added Assignee|freebsd-b...@freebsd.org