This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: -ftls-model docs/implementation inconsistency
- From: Jakub Jelinek <jakub at redhat dot com>
- To: Alexander Monakov <amonakov at ispras dot ru>
- Cc: gcc at gcc dot gnu dot org
- Date: Fri, 19 Jul 2013 18:14:36 +0200
- Subject: Re: -ftls-model docs/implementation inconsistency
- References: <alpine dot LNX dot 2 dot 00 dot 1307191846470 dot 1061 at monopod dot intra dot ispras dot ru> <20130719154105 dot GM23578 at laptop dot redhat dot com> <alpine dot LNX dot 2 dot 00 dot 1307191945350 dot 1061 at monopod dot intra dot ispras dot ru> <20130719155858 dot GO23578 at laptop dot redhat dot com> <alpine dot LNX dot 2 dot 00 dot 1307192003580 dot 1061 at monopod dot intra dot ispras dot ru>
- Reply-to: Jakub Jelinek <jakub at redhat dot com>
On Fri, Jul 19, 2013 at 08:08:26PM +0400, Alexander Monakov wrote:
> On Fri, 19 Jul 2013, Jakub Jelinek wrote:
> > The change of memory models based on flag_shlib is completely intentional,
> > it is similar to the linker TLS optimizations but at the compiler level,
> > so if you want to ad some comment to documentation, that is fine, but
> > I don't see anything to fix.
>
> The problem is that -ftls-model flag allows forcing local-exec TLS in
> shared objects, but does not allow forcing global-dynamic TLS. I don't see
> the rationale for providing one but not the other. It seems inconsistent.
If user code has __attribute__((tls_model ("global-dynamic"))) and the
compiler determines that it is not going to be used in a shared library,
then it of course optimizes it to a better code, and if we did that only at
the ld time, the generated code would be worse. That is the common case,
the case where people compile incorrectly objects that they want to link
into shared libraries is simply a user error that we shouldn't in any way
promote or support.
Jakub