search for: dllexportlinkage

...preserve current compiler behavior where necessary. All the other approaches appear to involve adding flags or attribute to an existing linkage type, so any existing compiler codes that deal with that particular linkage type will potentially have different behavior. For example, if you replace the DLLExportLinkage with ExternalLinkage+DLLExport_attribute, then codes that check hasExternalLinkage() will affect DLLExportLinkage symbols as well, which may or may not be the right thing. For example, LTO::addDefinedSymbol() currently does not handle dllimport/dllexport symbols, but if you change the semantics of...

On 23.04.2013 19:10, Gao, Yunzhong wrote: > I missed the discussion when I implemented dllexport/dllimport for our local tree. I > essentially implemented your approach#1. I was trying to avoid the various > external_linkage + some_attribute approaches because it seems that external_linkage > would imply the external linkage without the dllimport/dllexport semantics, and there > may

...type, so any > existing compiler codes that deal with that particular linkage type will > potentially have different behavior. Right. But normally LLVM API does not provide backward compatibility. The point is to make good code / API, not to fix the broken one with hinges and supports. > DLLExportLinkage with ExternalLinkage+DLLExport_attribute, then > codes that check hasExternalLinkage() will affect DLLExportLinkage > symbols as well, which may or may not be the right thing. In this case everything should work fine. If the behavior will be changed, then we'll find some subtle bug hiding...