clang

问题 I compiled .S file using command: clang-8 -c funcs.s -o funcs.o -emit-llvm I found, that .o file was generated in ELF format. I was expected to see llvm-ir format (with "BC" characters at the beginning of resulting file). Seems, Clang ignores "-emit-llvm" flag. 回答1: Your question isn't fundamentally different from Is it possible to translate an assembly language to LLVM IR, optimize it and then recompile it to a different architecture?. asm source and binary executables / object files are

问题 This program compiles without errors, for example with clang -Wall -std=c11 a.c and gcc -Wall -std=c11 a.c . Is this a bug in clang and gcc? Because arithmetic is not defined on pointers to function types. #include <stdio.h> void f(void) {} int main(void){ void (*p)(void) = f; printf("%p\n", p); printf("%p\n", p + 1); return 0; } There's a constraint on addition that either both operands have arithmetic type, or one is a pointer to a complete object type. I believe p is a pointer to a

问题 I'm trying to understand the use of the "static" keyword as an array index in a function declaration in C. After reading this article, I tried to declare such a function, and purposefully passing it an array that is too short: #include <stdio.h> #include <stdlib.h> void print_string10(char string10[static 10]) { // Should trigger a warning if the argument is NULL or an array of less than 10 elements printf("%s\n",string10); } int main(void) { char short_string[] = "test"; print_string10(short

问题 I'm experimenting disassembling clang binaries of simple C programs (compiled with -O0 ), and I'm confused about a certain instruction that gets generated. Here are two empty main functions with standard arguments, one of which returns value and other does not: // return_void.c void main(int argc, char** argv) { } // return_0.c int main(int argc, char** argv) { return 0; } Now, when I disassemble their assemblies, they look reasonably different, but there's one line that I don't understand:

问题 This question already has answers here : Hiding instantiated templates in shared library created with g++ (5 answers) Closed 4 days ago . I have a C++ library with a C API, and I have set the -fvisibility=hidden compiler flag, and then I have set __attribute__ ((visibility ("default"))) on C API methods. However, I still see visible C++ symbols. When I create a debian package for my library, I get the following symbols file Why are these symbols still visible ? 回答1: You should run your

问题 I'm trying to do some work on GTK+ on OSX and I'm having a little trouble because, to be honest, I'm not all that familiar with Objective-C. I have enough programming experience that I quickly got up to speed on the basic syntax, and I can look up what I need in documentation. But the problems I'm having are related to linking the library and exposing the classes to the program I'm linking to. GTK+ is a C library, but the OSX backend includes a couple Objective-C classes. They're not exposed

问题 Consider the following simple code: struct Base { Base() = default; Base(const Base&); Base(Base&&); }; struct Derived : Base { }; Base foo() { Derived derived; return derived; } clang 8.0.0 gives a warning -Wreturn-std-move on it: prog.cc:21:10: warning: local variable 'derived' will be copied despite being returned by name [-Wreturn-std-move] return derived; ^~~~~~~ prog.cc:21:10: note: call 'std::move' explicitly to avoid copying return derived; ^~~~~~~ std::move(derived) But if one called

问题 int a; int a=3; //error as cpp compiled with clang++-7 compiler but not as C compiled with clang-7; int main() { } For C, the compiler seems to merge these symbols into one global symbol but for C++ it is an error. Demo file1: int a = 2; file2: #include<stdio.h> int a; int main() { printf("%d", a); //2 } As C files compiled with clang-7, the linker does not produce an error and I assume it converts the uninitialised global symbol 'a' to an extern symbol (treating it as if it were compiled as

问题 edit: scroll to bold section below for current status. CLion seems to be unable to autocomplete members of a type pointed to by a unique_ptr in clang 5. I either get "no suggestions" or I get suggestions for member functions on the unique_ptr itself: However, with 4.0.1, everything works fine: I also noticed that if I ask CLion to jump to the definition of the -> on c-> , in 4.0.1 it finds it: _LIBCPP_INLINE_VISIBILITY pointer operator->() const _NOEXCEPT {return __ptr_.first();} But in 5.0.0

问题 I am trying to access the Visual Studio 2019 version of clang from the command prompt. I am looking for the official way to do this. So far it doesn't appear to be documented in any of the MSVC/clang blog posts. (Please note that I am not looking for other ways to build/install clang on Windows. This question specifically relates to the VS2019 clang component.) Using the Visual Studio Installer, I have installed Visual Studio 2019 Professional (version 16.4.1) along with the optional "C++