On Tue, 9 Sep 2025, H.J. Lu wrote:
> > But this doesn't imply that recomputed model would be weaker.
> >
> > As I understand, the actual issue is that decl_default_tls_model does not
> > iterate the attribute list, and so can return a weaker model than what the
> > front-end assigned based on the attribute. But this doesn't seem to have
> > any relation to -fpic and shared libraries: you'll be in the same situation
>
> The interposiblility is controlled by targetm.binds_local_p,
> which is orthogonal to the TLS model.
This doesn't make sense, but see below:
> > with extern TLS:
> >
> > __attribute__((tls_model("local-exec")))
> > extern __thread int tls_undef;
> >
> > where decl_default_tls_model returns initial-exec instead. Is this situation
> > covered by existing tests? I expect your
> >
> > gcc_checking_assert (flag_shlib || new_model >= model);
> >
> > to fail on this.
>
> This is covered by c-c++-common/tls-attr-le-pic.c in
No, this test passes -fpic, I'm talking about non-pic situation (else
decl_default_tls_model would not return initial-exec).
> > But it's not a strong definition, it's common symbol. Anyway, just take
> > attribute-common instead of attribute-weak: weak symbols are interposable.
> >
>
> Since weak definition in executable can only be overridden by a strong
> definition in executable, weak attribute makes no difference.
Granted, it's not obvious how to construct a testcase that would uncover
the inconsistency, so maybe there's no pressing issue. But I still wonder
if simply diagnosing the redeclaration would be preferable.
Alexander
