On 13/8/5 10:06 PM, Mike Stump wrote: > On Aug 4, 2013, at 8:14 AM, Chung-Lin Tang <clt...@codesourcery.com> wrote: >> On 13/7/15 1:43 AM, Diego Novillo wrote: >>> Could you please repost the patch with its description? This thread >>> is sufficiently old and noisy that I'm not even sure what the patch >>> does nor why. >> >> Taking the same example in my first post: >> >> Under -fPIC, the code in rtlanal.c:nonzero_address_p() does not properly >> recognize the "PIC-reg + <constant>" form of load as a weak symbol; it >> returns 'true' immediately after seeing the pic-reg indexing, and does >> not test the wrapped symbol for DECL_WEAK. > > So, I can't help but think that others would say that looking into an unspec > is by nature, the wrong way to do it, unless that code is in the port. > > I think the followup from Bernhard points to a better solution, though the > wording in the comment was objectionable. Merely say that the symbol, if > weak and not defined, is then not local.
When I last tested that patch which moves the DECL_WEAK check, the testcases for C++ TLS wrappers fail. I don't remember the fine details, but effectively it filters out the TLS wrappers from being treated locally, causing them to be called through @PLT, and regressing on some tests specifically checking for that... The UNSPEC interpretation here is fairly restricted, FWIW. Earlier talk on this thread also mentioned that maybe specific RTL constructs for reasoning about PIC addresses should be introduced, rather than common idiomatic pattern, though that may be a long shot for now. Chung-Lin
