[LLVMbugs] [Bug 18529] Clang warns unused volatile global variable

bugzilla-daemon at llvm.org bugzilla-daemon at llvm.org
Mon Jan 20 11:06:40 PST 2014


http://llvm.org/bugs/show_bug.cgi?id=18529

David Blaikie <dblaikie at gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
                 CC|                            |dblaikie at gmail.com
         Resolution|---                         |INVALID

--- Comment #4 from David Blaikie <dblaikie at gmail.com> ---
(In reply to comment #3)
> (In reply to comment #1)
> > (In reply to comment #0)
> > > In the following instructions, I have a tiny program with a volatile global
> > > variable. Even the program is closed with a main function, the developers
> > > are still be able to reference this variable with its name after compilation
> > > and inject assembly code into the assembly file.
> > No, they are not. Since this is static global, the name of the variable in
> > the assembly file may be arbitrary.
> 
> I think even if the variable is given an arbitrary name, the variable is
> still there in the assembly file. Therefore the developers can still find a
> way to reference it, which is unknown to the compiler.

I'm not sure that's guaranteed to work - but I don't know the C standard too
well.

I suspect it isn't guaranteed and just using __attribute__((used)) on it is the
right answer.

Indeed the GCC documentation says precisely that:

"used
This attribute, attached to a function, means that code must be emitted for the
function even if it appears that the function is not referenced. This is
useful, for example, when the function is referenced only in inline assembly."

http://gcc.gnu.org/onlinedocs/gcc/Function-Attributes.html

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20140120/1f90c0b0/attachment.html>


More information about the llvm-bugs mailing list