[llvm] r227414 - [LPM] Try again to appease powerpc64 in its self host. I've been unable
Hal Finkel
hfinkel at anl.gov
Thu Jan 29 08:13:21 PST 2015
----- Original Message -----
> From: "Ulrich Weigand" <Ulrich.Weigand at de.ibm.com>
> To: "Hal Finkel" <hfinkel at anl.gov>
> Cc: "Chandler Carruth" <chandlerc at gmail.com>, "Commit Messages and Patches for LLVM" <llvm-commits at cs.uiuc.edu>,
> "Rafael EspĂndola" <rafael.espindola at gmail.com>, "Bill Schmidt" <wschmidt at linux.vnet.ibm.com>
> Sent: Thursday, January 29, 2015 9:17:56 AM
> Subject: Re: [llvm] r227414 - [LPM] Try again to appease powerpc64 in its self host. I've been unable
>
> Hal Finkel <hfinkel at anl.gov> wrote on 29.01.2015 13:49:21:
>
> > I was able to reproduce the problem with r227415 on my PPC64 P7
> > box,
> > and setting:
> > CMAKE_EXE_LINKER_FLAGS:STRING=-Wl,--no-tls-get-addr-optimize -
> > Wl,--no-tls-optimize
> > CMAKE_MODULE_LINKER_FLAGS:STRING=-Wl,--no-tls-get-addr-optimize -
> > Wl,--no-tls-optimize
> > made the problem go away. Given that the bug is actually in the
> > linker, I think this is really the proper solution. Can we add
> > these
> > to our build flags for PPC64 for now?
>
> It's probably indeed the best to use the linker flag for now.
>
> However, I think adding them to the LLVM build flags is the wrong
> place; there is nothing special about compiling the LLVM code base
> as such. Rather, the problem is using clang/LLVM to compile *any*
> coding using general-/local-dynamics TLS variables.
>
> So I think the flags should be added by the clang compiler driver
> whenever it invokes the linker on PowerPC. (At least for now,
> and in 3.6. They can be removed again once Bill has changed the
> code generation to again ensure use of r3 as expected by broken
> linkers ...)
Agreed. Can you please post a patch?
-Hal
>
> Bye,
> Ulrich
>
>
--
Hal Finkel
Assistant Computational Scientist
Leadership Computing Facility
Argonne National Laboratory
More information about the llvm-commits
mailing list