This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH] PR32219, weak hidden reference segfault [PING^2]

On 13/8/5 10:06 PM, Mike Stump wrote:
> On Aug 4, 2013, at 8:14 AM, Chung-Lin Tang <> 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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]