similar to: [LLVMdev] Warnings about symbol visibility

http://lists.cs.uiuc.edu/pipermail/llvmdev/2008-August/016763.html On 2008-09-05, at 22:46, Talin wrote: > Recently I started getting these warnings - thousands of them - and > I'm > not sure what I did to cause them or how to solve them: > > ld: warning llvm::MemoryBuffer::getBufferStart() const has different > visibility (1) in

Recently I started getting these warnings - thousands of them - and I'm not sure what I did to cause them or how to solve them: ld: warning llvm::MemoryBuffer::getBufferStart() const has different visibility (1) in /usr/local/lib/libLLVMSupport.a(MemoryBuffer.o) and (2) in /usr/local/lib/libLLVMSupport.a(CommandLine.o) ld: warning

Hello, Opus currently always sets default visibility for exported functions when OPUS_BUILD macro is set. However, it is not a desirable behavior when libopus is statically linked with the final binary (e.g. libxul.so in firefox), since all symbols get exported even with -fvisibility=hidden. In firefox, this problem is partially solved by wrapping translation units with #pragma visibility

From: Thierry Reding <treding at nvidia.com> Checks whether or not the compiler supports the -fvisibility option. If so it sets the VISIBILITY_CFLAGS variable which can be added to the per directory AM_CFLAGS where appropriate. By default all symbols will be hidden via the VISIBILITY_CFLAGS. The drm_public macro can be used to mark symbols that should be exported. Signed-off-by: Thierry

On 30/07/14 15:31, Rob Clark wrote: > On Wed, Jul 30, 2014 at 9:48 AM, Thierry Reding > <thierry.reding at gmail.com> wrote: >> From: Thierry Reding <treding at nvidia.com> >> >> Checks whether or not the compiler supports the -fvisibility option. If >> so it sets the VISIBILITY_CFLAGS variable which can be added to the per >> directory AM_CFLAGS

Hi Peter, Thanks for the reply. I agree that the base class vtable may be not referenced by a derived class. However, the vtable of a derived class has to reference its parent type_info, and so having type_info internalized means that the class is final, doesn’t it? Thanks, Nikolai From: Peter Collingbourne [mailto:peter at pcc.me.uk] Sent: Wednesday, December 6, 2017 4:36 AM To: Gainullin,

Hi! I have a question about whole program devirtualization pass. According to my understanding devirtualization is performed only for the classes that have hidden LTO visibility and this visibility is controlled by attributes in the source level or command line options. So visibility analysis is currently performed only in the front-end. But LLVM has LTO internalization pass that uses

On Wed, Jul 30, 2014 at 9:48 AM, Thierry Reding <thierry.reding at gmail.com> wrote: > From: Thierry Reding <treding at nvidia.com> > > Checks whether or not the compiler supports the -fvisibility option. If > so it sets the VISIBILITY_CFLAGS variable which can be added to the per > directory AM_CFLAGS where appropriate. > > By default all symbols will be hidden

Unlike those happy few who are seeing thousands of visibility warnings, I get only one with gcc 4.3: lib/CodeGen/SelectionDAG/SelectionDAGBuild.cpp:3889: warning: ‘llvm::SDISelAsmOperandInfo’ declared with greater visibility than the type of its field ‘llvm::SDISelAsmOperandInfo::AssignedRegs’ Anyway know what this is about? Ciao, Duncan.

Hi Duncan, Does r55922 fix this for you? Dan On Sep 6, 2008, at 10:09 AM, Duncan Sands wrote: > Unlike those happy few who are seeing thousands of visibility > warnings, I get only one with gcc 4.3: > > lib/CodeGen/SelectionDAG/SelectionDAGBuild.cpp:3889: warning: > ‘llvm::SDISelAsmOperandInfo’ declared with greater visibility than > the type of its field

Hi, Mark > #pragma GCC visibility push(hidden) In theory - yes. > If so, what are the options I need to set when configuring llvm and > llvm-gcc? Well... No extra options are needed. > I'm able to compile the module with llvm-gcc (with the above pragma > included), but the kernel still rejects the module at load time saying the > module is compiled with PLT/GOT. Visibility

Gurus- Do llvm/llvm-gcc support pragma definitions for visibility like: #pragma GCC visibility push(hidden) If so, what are the options I need to set when configuring llvm and llvm-gcc? I'm able to compile the module with llvm-gcc (with the above pragma included), but the kernel still rejects the module at load time saying the module is compiled with PLT/GOT. Any Inputs, Insights? Thanks

On 28.12.2011, at 19:02, Jonathan Ragan-Kelley wrote: > Building on OS X 10.7.1 with the standard toolchain, I have seen the > following linker warnings going back a number of versions in trunk > whenever I build an executable linked with LLVM: > > ld: warning: direct access in llvm::fouts() to global weak > symbol llvm::formatted_raw_ostream::~formatted_raw_ostream()

On Tue, Feb 17, 2015 at 12:38 PM, Marc Dietrich <marvin24 at gmx.de> wrote: > Am Dienstag, 17. Februar 2015, 11:58:06 schrieb Sedat Dilek: >> On Tue, Feb 17, 2015 at 10:40 AM, Marc Dietrich <marvin24 at gmx.de> wrote: >> > Avoid redefined symbol errors in clang. Based on a suggestion from >> > Rafael Ávila de Espíndola <rafael.espindola at gmail.com> in

On Mon, Apr 01, 2013 at 03:49:14PM -0700, Peter Collingbourne wrote: > On Thu, Mar 21, 2013 at 02:12:27PM +0900, Joerg Sonnenberger wrote: > > On Wed, Mar 20, 2013 at 02:22:47PM -0700, Peter Collingbourne wrote: > > > I am trying to compile a dynamic loader using LLVM. Part of the IR > > > for this loader looks like this: > > > > > > @_rtld_local =

On Thu, Mar 21, 2013 at 02:12:27PM +0900, Joerg Sonnenberger wrote: > On Wed, Mar 20, 2013 at 02:22:47PM -0700, Peter Collingbourne wrote: > > I am trying to compile a dynamic loader using LLVM. Part of the IR > > for this loader looks like this: > > > > @_rtld_local = hidden alias %struct.rtld_global* @_rtld_global > > @_rtld_global = unnamed_addr global

On Tue, Feb 17, 2015 at 1:55 PM, Sedat Dilek <sedat.dilek at gmail.com> wrote: > On Tue, Feb 17, 2015 at 10:40 AM, Marc Dietrich <marvin24 at gmx.de> wrote: >> Patch 1 adds a check for the compilers visibility macro to configure.ac. >> Patch 2 avoids redefined symbol errors in clang of the tls entry points. >> Based on a suggestion from Rafael Ávila de Espíndola

On Tue, Feb 17, 2015 at 12:47 PM, Marc Dietrich <marvin24 at gmx.de> wrote: > Am Dienstag, 17. Februar 2015, 12:42:00 schrieb Sedat Dilek: >> On Tue, Feb 17, 2015 at 12:38 PM, Marc Dietrich <marvin24 at gmx.de> wrote: >> > Am Dienstag, 17. Februar 2015, 11:58:06 schrieb Sedat Dilek: >> >> On Tue, Feb 17, 2015 at 10:40 AM, Marc Dietrich <marvin24 at

Would it be possible to have the value of eval() preserve the "visibility" of the value of the expression? "PROBLEM": # Invisible > x <- 1 # Visible > eval(x <- 2) [1] 2 "TROUBLESHOOTING": > withVisible(x <- 1) $value [1] 1 $visible [1] FALSE > withVisible(eval(x <- 2)) $value [1] 2 $visible [1] TRUE WORKAROUND: eval2 <-

Sorry to intervene. Argument passed to 'eval' is evaluated first. So, eval(x <- 2) is effectively like { x <- 2; eval(2) } , which is effectively { x <- 2; 2 } . The result is visible. eval(expression(x <- 2)) or eval(quote(x <- 2)) or evalq(x <- 2) gives the same effect as x <- 2 . The result is invisible. In function 'eval2', res <-