Re: [cfe-users] Reproducible builds
You could try something like this:
template
class X{}
static X x;
// or
char str[SOME_INT];
then compile it like this:
clang++ -D$RANDOM -c file.cpp -o file.o
RANDOM is a bash thing, but basically you just need to generate a random
number each time you compile and pass it in as a macro.
hth...
don
On Mon, Aug 24, 2015 at 12:57 AM, Stephan Gatzka via cfe-users <
cfe-users@lists.llvm.org> wrote:
> Hi!
>
> I just added support for reproducible builds (-frandom-seed=) into the
> qbs build system.
>
> For a automated test case I'd like to have a small snippet of C/C++
> code, which definitely leads to different object files if compiled
> twice.
>
> I wasn't able to write such a snippet, so any help would be very
> appreciated.
>
> Regards,
>
> Stephan
> ___
> cfe-users mailing list
> cfe-users@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-users
>
___
cfe-users mailing list
cfe-users@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-users
Re: [cfe-users] Reproducible builds
sorry, typo, should be -DSOME_INT=$RANDOM
On Mon, Aug 24, 2015 at 9:28 AM, don hinton wrote:
> You could try something like this:
>
> template
> class X{}
>
> static X x;
>
> // or
>
> char str[SOME_INT];
>
> then compile it like this:
>
> clang++ -D$RANDOM -c file.cpp -o file.o
>
> RANDOM is a bash thing, but basically you just need to generate a random
> number each time you compile and pass it in as a macro.
>
> hth...
> don
>
> On Mon, Aug 24, 2015 at 12:57 AM, Stephan Gatzka via cfe-users <
> cfe-users@lists.llvm.org> wrote:
>
>> Hi!
>>
>> I just added support for reproducible builds (-frandom-seed=) into the
>> qbs build system.
>>
>> For a automated test case I'd like to have a small snippet of C/C++
>> code, which definitely leads to different object files if compiled
>> twice.
>>
>> I wasn't able to write such a snippet, so any help would be very
>> appreciated.
>>
>> Regards,
>>
>> Stephan
>> ___
>> cfe-users mailing list
>> cfe-users@lists.llvm.org
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-users
>>
>
>
___
cfe-users mailing list
cfe-users@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-users
Re: [cfe-users] Reproducible builds
Sorry, didn't read closely enough. Looks like it's currently ignored: $ grep -n frandom_seed include/clang/Driver/Options.td 949:def frandom_seed_EQ : Joined<["-"], "frandom-seed=">, Group; http://reviews.llvm.org/D3391 On Mon, Aug 24, 2015 at 12:41 PM, Stephan Gatzka wrote: > Well, > > that's not exactly what I meant. In gcc, if you use -flto a c file > compiled twice leads to different binaries, if you don't add > -frandom-seed=. > > clang also supports the switch -frandom-seed=, but the object > files produced by clang are always binary equal. > > Meanwhile I think clang intorduced -frandom-seed only for gcc > compatibility: > > https://github.com/llvm-mirror/clang/blob/master/include/clang/Driver/Options.td#L949 > > > But thanks for the hint. :) > > Regards, > > Stephan > ___ cfe-users mailing list cfe-users@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-users
Re: [cfe-users] Why doesn't clang use colors for diagnostics by default?
Hi Victor: Try setting TERM to a color terminal, e.g., xterm-color or xterm-256color and see if that helps. I use xterm-256color inside tmux and it works fine. hth... don On Thu, Sep 10, 2015 at 2:40 AM, Victor via cfe-users < cfe-users@lists.llvm.org> wrote: > I'm using command like this: > > $ clang++ prg.cpp > > My Clang is built from sources. What libraries it needs to use colors > automatically? Or may be there is some option that I can specify for > configure? > > > On Wed, 9 Sep 2015 19:49:21 -0700 > Richard Trieu wrote: > >> Are you invoking Clang with "clang foo.cc" or "clang -cc1 foo.cc"? The >> first should detect if you have a color capable terminal and automatically >> turn on color diagnostics while the second needs the flag explicitly. The >> other possibility is that the Clang you are using was compiled with the >> libraries needed to detect a color terminal, and defaults to no color. >> >> On Mon, Sep 7, 2015 at 5:15 AM, Victor via cfe-users < >> cfe-users@lists.llvm.org> wrote: >> >> Hello, all. >>> >>> Why doesn't clang use colors for diagnostics by default? >>> My environment: >>> >>> $ cat /etc/*-release >>> Red Hat Enterprise Linux Server release 6.3 (Santiago) >>> >>> $ echo $TERM >>> xterm >>> >>> Doc here >>> http://clang.llvm.org/docs/UsersManual.html#formatting-of-diagnostics >>> says: "This option, which defaults to on when a color-capable terminal is >>> detected". Isn't xterm "a color-capable terminal"? >>> >>> If I give -fcolor-diagnostics explicitly, all works as expected. But why >>> must I do that? GCC uses colors by default. >>> ___ >>> cfe-users mailing list >>> cfe-users@lists.llvm.org >>> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-users >>> >>> > ___ > cfe-users mailing list > cfe-users@lists.llvm.org > http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-users > ___ cfe-users mailing list cfe-users@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-users
Re: [cfe-users] Why doesn't clang use colors for diagnostics by default?
Did you build clang? Do you have terminfo installed? I think that's what it checks. On Thu, Sep 10, 2015 at 11:49 AM, Victor wrote: > No. Still no luck. Tried both > > > On Thu, 10 Sep 2015 11:39:24 -0400 > don hinton wrote: > >> Hi Victor: >> >> Try setting TERM to a color terminal, e.g., xterm-color or xterm-256color >> and see if that helps. I use xterm-256color inside tmux and it works >> fine. >> >> hth... >> don >> >> On Thu, Sep 10, 2015 at 2:40 AM, Victor via cfe-users < >> cfe-users@lists.llvm.org> wrote: >> >> I'm using command like this: >>> >>> $ clang++ prg.cpp >>> >>> My Clang is built from sources. What libraries it needs to use colors >>> automatically? Or may be there is some option that I can specify for >>> configure? >>> >>> >>> On Wed, 9 Sep 2015 19:49:21 -0700 >>> Richard Trieu wrote: >>> >>> Are you invoking Clang with "clang foo.cc" or "clang -cc1 foo.cc"? The first should detect if you have a color capable terminal and automatically turn on color diagnostics while the second needs the flag explicitly. The other possibility is that the Clang you are using was compiled with the libraries needed to detect a color terminal, and defaults to no color. On Mon, Sep 7, 2015 at 5:15 AM, Victor via cfe-users < cfe-users@lists.llvm.org> wrote: Hello, all. > > Why doesn't clang use colors for diagnostics by default? > My environment: > > $ cat /etc/*-release > Red Hat Enterprise Linux Server release 6.3 (Santiago) > > $ echo $TERM > xterm > > Doc here > http://clang.llvm.org/docs/UsersManual.html#formatting-of-diagnostics > says: "This option, which defaults to on when a color-capable terminal > is > detected". Isn't xterm "a color-capable terminal"? > > If I give -fcolor-diagnostics explicitly, all works as expected. But > why > must I do that? GCC uses colors by default. > ___ > cfe-users mailing list > cfe-users@lists.llvm.org > http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-users > > > ___ >>> cfe-users mailing list >>> cfe-users@lists.llvm.org >>> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-users >>> >>> > ___ cfe-users mailing list cfe-users@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-users
Re: [cfe-users] Why doesn't clang use colors for diagnostics by default?
I meant the headers. If you use cmake, take a look at cmake/config-ix.cmake. Configure does something similar. Basically, if it finds the right headers, it will #define HAS_TERMINFO, and the code that checks it is terminalHasColors() in lib/Support/Unix/Process.inc. Not sure how gcc checks. On Thu, Sep 10, 2015 at 11:58 AM, Victor wrote: > Did you build clang? >> > Yes > > Do you have terminfo installed? >> > $ find /usr/share/terminfo -type f > /usr/share/terminfo/k/kon2 > /usr/share/terminfo/k/kon > /usr/share/terminfo/k/konsole-256color > /usr/share/terminfo/k/konsole > /usr/share/terminfo/v/vs100 > /usr/share/terminfo/c/cygwin > /usr/share/terminfo/c/cons25 > /usr/share/terminfo/t/teraterm2.3 > /usr/share/terminfo/t/teraterm > /usr/share/terminfo/g/gnome > /usr/share/terminfo/g/gnome-256color > /usr/share/terminfo/w/wsvt25 > /usr/share/terminfo/w/wsvt25m > /usr/share/terminfo/n/nxterm > /usr/share/terminfo/n/nsterm > /usr/share/terminfo/m/mrxvt > /usr/share/terminfo/m/mach > /usr/share/terminfo/m/mach-bold > /usr/share/terminfo/m/mach-color > /usr/share/terminfo/m/mlterm > /usr/share/terminfo/E/Eterm-88color > /usr/share/terminfo/E/Eterm-256color > /usr/share/terminfo/E/Eterm > /usr/share/terminfo/E/Eterm-color > /usr/share/terminfo/a/aterm > /usr/share/terminfo/a/ansis > /usr/share/terminfo/a/ansi80x25 > /usr/share/terminfo/p/putty-vt100 > /usr/share/terminfo/p/pcansi > /usr/share/terminfo/p/putty-256color > /usr/share/terminfo/p/putty > /usr/share/terminfo/s/screen.xterm-new > /usr/share/terminfo/s/sun > /usr/share/terminfo/s/screen-16color-bce > /usr/share/terminfo/s/screen-16color-s > /usr/share/terminfo/s/screen-16color-bce-s > /usr/share/terminfo/s/sun1 > /usr/share/terminfo/s/screen > /usr/share/terminfo/s/screen.rxvt > /usr/share/terminfo/s/sun2 > /usr/share/terminfo/s/screen.linux > /usr/share/terminfo/s/screen-256color-bce > /usr/share/terminfo/s/screen-16color > /usr/share/terminfo/s/screen-256color-s > /usr/share/terminfo/s/screen.xterm-xfree86 > /usr/share/terminfo/s/screen-256color-bce-s > /usr/share/terminfo/s/screen.teraterm > /usr/share/terminfo/s/screen-bce > /usr/share/terminfo/s/screen-s > /usr/share/terminfo/s/screen.mlterm > /usr/share/terminfo/s/screen-w > /usr/share/terminfo/s/screen.xterm-r6 > /usr/share/terminfo/s/screen-256color > /usr/share/terminfo/s/screen.Eterm > /usr/share/terminfo/j/jfbterm > /usr/share/terminfo/h/hurd > /usr/share/terminfo/r/rxvt-color > /usr/share/terminfo/r/rxvt-xpm > /usr/share/terminfo/r/rxvt-unicode > /usr/share/terminfo/r/rxvt-basic > /usr/share/terminfo/r/rxvt > /usr/share/terminfo/r/rxvt-88color > /usr/share/terminfo/r/rxvt-16color > /usr/share/terminfo/r/rxvt-cygwin-native > /usr/share/terminfo/r/rxvt-256color > /usr/share/terminfo/r/rxvt-cygwin > /usr/share/terminfo/x/xterm-xf86-v32 > /usr/share/terminfo/x/xterm-xi > /usr/share/terminfo/x/xterm-r5 > /usr/share/terminfo/x/xterm-vt220 > /usr/share/terminfo/x/xterm-new > /usr/share/terminfo/x/xterm-sun > /usr/share/terminfo/x/xterm-nic > /usr/share/terminfo/x/xterm-8bit > /usr/share/terminfo/x/xterm-old > /usr/share/terminfo/x/xterm-hp > /usr/share/terminfo/x/xterm-color > /usr/share/terminfo/x/xterm-256color > /usr/share/terminfo/x/xterm-pcolor > /usr/share/terminfo/x/xterm-basic > /usr/share/terminfo/x/xterm-noapp > /usr/share/terminfo/x/xterm-24 > /usr/share/terminfo/x/xterm-bold > /usr/share/terminfo/x/xterms > /usr/share/terminfo/x/xterm > /usr/share/terminfo/x/xterm-1003 > /usr/share/terminfo/x/xterm-sco > /usr/share/terminfo/x/xterm-1002 > /usr/share/terminfo/x/xterm-vt52 > /usr/share/terminfo/x/xterm-16color > /usr/share/terminfo/x/xterm-r6 > /usr/share/terminfo/x/xterm-xf86-v44 > /usr/share/terminfo/x/xfce > /usr/share/terminfo/x/xterm-xf86-v333 > /usr/share/terminfo/x/xterm-88color > /usr/share/terminfo/x/xterm-xfree86 > /usr/share/terminfo/x/xterm-xf86-v43 > /usr/share/terminfo/x/xterm-xf86-v40 > /usr/share/terminfo/x/xterm-xf86-v33 > /usr/share/terminfo/e/eterm > /usr/share/terminfo/e/eterm-color > /usr/share/terminfo/A/Apple_Terminal > > On Thu, 10 Sep 2015 11:53:48 -0400 > > don hinton wrote: > >> Did you build clang? Do you have terminfo installed? I think that's what >> it checks. >> >> On Thu, Sep 10, 2015 at 11:49 AM, Victor wrote: >> >> No. Still no luck. Tried both >>> >>> >>> On Thu, 10 Sep 2015 11:39:24 -0400 >>> don hinton wrote: >>> >>> Hi Victor: Try setting TERM to a color terminal, e.g., xterm-color or xterm-256color and see if that helps. I use xterm-256color inside tmux and it works fine. hth... don On Thu, Sep 10, 2015 at 2:40 AM, Victor via cfe-users < cfe-users@lists.llvm.org> wrote: I'm using command like this: > > $ clang++ prg.cpp > > My Clang is built from sources. What libraries it needs to use colors > automatically? Or may be there is some option that I can specify for > configure? > > > On Wed, 9 Sep 2015 19:49:21 -0700 > Richard T
Re: [cfe-users] Why doesn't clang use colors for diagnostics by default?
Actually, I just looked at the cmake code and it checks a list of libraries, i.e., tinfo, terminfo, curses, ncurses, and ncursesw. If any of them have setupterm, it will define HAVE_TERMINFO 1. So, at least that give you something to check. hth... don On Thu, Sep 10, 2015 at 12:06 PM, don hinton wrote: > I meant the headers. If you use cmake, take a look at > cmake/config-ix.cmake. Configure does something similar. > > Basically, if it finds the right headers, it will #define HAS_TERMINFO, > and the code that checks it is terminalHasColors() in > lib/Support/Unix/Process.inc. > > Not sure how gcc checks. > > > On Thu, Sep 10, 2015 at 11:58 AM, Victor wrote: > >> Did you build clang? >>> >> Yes >> >> Do you have terminfo installed? >>> >> $ find /usr/share/terminfo -type f >> /usr/share/terminfo/k/kon2 >> /usr/share/terminfo/k/kon >> /usr/share/terminfo/k/konsole-256color >> /usr/share/terminfo/k/konsole >> /usr/share/terminfo/v/vs100 >> /usr/share/terminfo/c/cygwin >> /usr/share/terminfo/c/cons25 >> /usr/share/terminfo/t/teraterm2.3 >> /usr/share/terminfo/t/teraterm >> /usr/share/terminfo/g/gnome >> /usr/share/terminfo/g/gnome-256color >> /usr/share/terminfo/w/wsvt25 >> /usr/share/terminfo/w/wsvt25m >> /usr/share/terminfo/n/nxterm >> /usr/share/terminfo/n/nsterm >> /usr/share/terminfo/m/mrxvt >> /usr/share/terminfo/m/mach >> /usr/share/terminfo/m/mach-bold >> /usr/share/terminfo/m/mach-color >> /usr/share/terminfo/m/mlterm >> /usr/share/terminfo/E/Eterm-88color >> /usr/share/terminfo/E/Eterm-256color >> /usr/share/terminfo/E/Eterm >> /usr/share/terminfo/E/Eterm-color >> /usr/share/terminfo/a/aterm >> /usr/share/terminfo/a/ansis >> /usr/share/terminfo/a/ansi80x25 >> /usr/share/terminfo/p/putty-vt100 >> /usr/share/terminfo/p/pcansi >> /usr/share/terminfo/p/putty-256color >> /usr/share/terminfo/p/putty >> /usr/share/terminfo/s/screen.xterm-new >> /usr/share/terminfo/s/sun >> /usr/share/terminfo/s/screen-16color-bce >> /usr/share/terminfo/s/screen-16color-s >> /usr/share/terminfo/s/screen-16color-bce-s >> /usr/share/terminfo/s/sun1 >> /usr/share/terminfo/s/screen >> /usr/share/terminfo/s/screen.rxvt >> /usr/share/terminfo/s/sun2 >> /usr/share/terminfo/s/screen.linux >> /usr/share/terminfo/s/screen-256color-bce >> /usr/share/terminfo/s/screen-16color >> /usr/share/terminfo/s/screen-256color-s >> /usr/share/terminfo/s/screen.xterm-xfree86 >> /usr/share/terminfo/s/screen-256color-bce-s >> /usr/share/terminfo/s/screen.teraterm >> /usr/share/terminfo/s/screen-bce >> /usr/share/terminfo/s/screen-s >> /usr/share/terminfo/s/screen.mlterm >> /usr/share/terminfo/s/screen-w >> /usr/share/terminfo/s/screen.xterm-r6 >> /usr/share/terminfo/s/screen-256color >> /usr/share/terminfo/s/screen.Eterm >> /usr/share/terminfo/j/jfbterm >> /usr/share/terminfo/h/hurd >> /usr/share/terminfo/r/rxvt-color >> /usr/share/terminfo/r/rxvt-xpm >> /usr/share/terminfo/r/rxvt-unicode >> /usr/share/terminfo/r/rxvt-basic >> /usr/share/terminfo/r/rxvt >> /usr/share/terminfo/r/rxvt-88color >> /usr/share/terminfo/r/rxvt-16color >> /usr/share/terminfo/r/rxvt-cygwin-native >> /usr/share/terminfo/r/rxvt-256color >> /usr/share/terminfo/r/rxvt-cygwin >> /usr/share/terminfo/x/xterm-xf86-v32 >> /usr/share/terminfo/x/xterm-xi >> /usr/share/terminfo/x/xterm-r5 >> /usr/share/terminfo/x/xterm-vt220 >> /usr/share/terminfo/x/xterm-new >> /usr/share/terminfo/x/xterm-sun >> /usr/share/terminfo/x/xterm-nic >> /usr/share/terminfo/x/xterm-8bit >> /usr/share/terminfo/x/xterm-old >> /usr/share/terminfo/x/xterm-hp >> /usr/share/terminfo/x/xterm-color >> /usr/share/terminfo/x/xterm-256color >> /usr/share/terminfo/x/xterm-pcolor >> /usr/share/terminfo/x/xterm-basic >> /usr/share/terminfo/x/xterm-noapp >> /usr/share/terminfo/x/xterm-24 >> /usr/share/terminfo/x/xterm-bold >> /usr/share/terminfo/x/xterms >> /usr/share/terminfo/x/xterm >> /usr/share/terminfo/x/xterm-1003 >> /usr/share/terminfo/x/xterm-sco >> /usr/share/terminfo/x/xterm-1002 >> /usr/share/terminfo/x/xterm-vt52 >> /usr/share/terminfo/x/xterm-16color >> /usr/share/terminfo/x/xterm-r6 >> /usr/share/terminfo/x/xterm-xf86-v44 >> /usr/share/terminfo/x/xfce >> /usr/share/terminfo/x/xterm-xf86-v333 >> /usr/share/terminfo/x/xterm-88color >> /usr/share/terminfo/x/xterm-xfree86 >> /usr/share/terminfo/x/xterm-xf86-v43 >> /usr/share/terminfo/x/xterm-xf86-v40 >> /usr/share/terminfo/x/xterm-xf86-v33 >> /usr/share/terminfo/e/eterm >> /usr/share/terminfo/e/eterm-color >> /usr/share/terminfo/A/Apple_Terminal >> >> On Thu, 10 Sep 2015 11:53:48 -0400 >> >> don hinton wrote: >> >>> Did you build clang? Do you have terminfo installed? I think that's >>> what >>> it checks. >>> >>> On Thu, Sep 10, 2015 at 11:49 AM, Victor wrote: >>> >>> No. Still no luck. Tried both On Thu, 10 Sep 2015 11:39:24 -0400 don hinton wrote: Hi Victor: > > Try setting TERM to a color terminal, e.g., xterm-color or > xterm-256color > and see if that helps. I use xterm-256color inside tmux and it
Re: [cfe-users] How to dump the vtable's or record's layout?
As per Reid's early response, try adding -emit-llvm-only or -emit-obj. http://clang-developers.42468.n3.nabble.com/Clang-3-4-fdump-record-layouts-not-producing-any-results-td4036285.html On Mon, Sep 14, 2015 at 1:27 PM, Yi-Hong Lyu via cfe-users < cfe-users@lists.llvm.org> wrote: > Hello all, > > I would like to dump the vtable's or record's layout therefore I download > the binary of Clang 3.7 for Linux from official site. But I got nothing > with: > > $ clang+llvm-3.7.0-x86_64-linux-gnu-ubuntu-14.04/bin/clang++ -cc1 > -fdump-vtable-layouts vtable.cpp > > or > > $ clang+llvm-3.7.0-x86_64-linux-gnu-ubuntu-14.04/bin/clang++ -cc1 > -fdump-record-layouts vtable.cpp > > I am wondering how to dump vtable's or record's layout? Is there anything > wrong with my instructions? > > Thanks, > Yi-Hong > > ___ > cfe-users mailing list > cfe-users@lists.llvm.org > http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-users > > ___ cfe-users mailing list cfe-users@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-users
Re: [cfe-users] How to dump the vtable's or record's layout?
btw, you might prefer to use -Xclang instead of using -cc1 directly, e.g, clang++ -Xclang -fdump-record-layouts vtable.cpp This way, you don't need to worry about passing additional parameters to -cc1, and you get nice colors if you have a color terminal. On Mon, Sep 14, 2015 at 5:24 PM, don hinton wrote: > As per Reid's early response, try adding -emit-llvm-only or -emit-obj. > > > http://clang-developers.42468.n3.nabble.com/Clang-3-4-fdump-record-layouts-not-producing-any-results-td4036285.html > > > On Mon, Sep 14, 2015 at 1:27 PM, Yi-Hong Lyu via cfe-users < > cfe-users@lists.llvm.org> wrote: > >> Hello all, >> >> I would like to dump the vtable's or record's layout therefore I download >> the binary of Clang 3.7 for Linux from official site. But I got nothing >> with: >> >> $ clang+llvm-3.7.0-x86_64-linux-gnu-ubuntu-14.04/bin/clang++ -cc1 >> -fdump-vtable-layouts vtable.cpp >> >> or >> >> $ clang+llvm-3.7.0-x86_64-linux-gnu-ubuntu-14.04/bin/clang++ -cc1 >> -fdump-record-layouts vtable.cpp >> >> I am wondering how to dump vtable's or record's layout? Is there anything >> wrong with my instructions? >> >> Thanks, >> Yi-Hong >> >> ___ >> cfe-users mailing list >> cfe-users@lists.llvm.org >> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-users >> >> > ___ cfe-users mailing list cfe-users@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-users
Re: [cfe-users] Unexpected include directories when cross-compiling
Take a look at the "Toolchain Options" and "Target-Specific Libraries" sections here: http://clang.llvm.org/docs/CrossCompilation.html Which will show you how to tell the compiler where to find stuff for your target system. hth... don On Tue, Sep 22, 2015 at 11:38 AM, Andreas Messer via cfe-users < cfe-users@lists.llvm.org> wrote: > Hello everybody, > > I'm currently planning to use clang to compile my ARM projects. One bug I > found in clang 3.5 - it tried to link the elf using the host's instead of > the > target's linker - is fixed in trunk source. Unfortunately I found an issue > with > the include files which - in my oppinion - is wrong. When cross compiling > for > the arm target clang adds the hosts include folders to the include search > paths by default: > > /tmp/test_clang $ clang -v --target=arm-none-eabi -c main.c -o main.o > clang version 3.8.0 (http://llvm.org/git/clang.git > 21b3f468fc871980e422404f35fcac7de83cfa9c) (llvm/trunk 248266) > Target: arm-none--eabi > Thread model: posix > InstalledDir: /usr/local/bin > "/usr/local/stow/llvm_r248266-clang_r248254/bin/clang-3.8" -cc1 -triple > armv4t-none--eabi -emit-obj -mrelax-all -disable-free > -disable-llvm-verifier - > main-file-name main.c -mrelocation-model static -mthread-model posix > -mdisable- > fp-elim -fmath-errno -masm-verbose -mconstructor-aliases -target-cpu > arm7tdmi > -target-feature +soft-float-abi -target-feature +strict-align -target-abi > aapcs > -mfloat-abi soft -v -dwarf-column-info -coverage-file > /tmp/test_clang/main.o - > resource-dir > /usr/local/stow/llvm_r248266-clang_r248254/bin/../lib/clang/3.8.0 > -fdebug-compilation-dir /tmp/test_clang -ferror-limit 19 -fmessage-length > 126 > -fallow-half-arguments-and-returns -fno-signed-char -fobjc-runtime=gcc - > fdiagnostics-show-option -fcolor-diagnostics -o main.o -x c main.c > clang -cc1 version 3.8.0 based upon LLVM 3.8.0svn default target x86_64- > unknown-linux-gnu > #include "..." search starts here: > #include <...> search starts here: > /usr/local/include > /usr/local/stow/llvm_r248266-clang_r248254/bin/../lib/clang/3.8.0/include > /usr/include > End of search list. > main.c:5:11: warning: self-comparison always evaluates to true [- > Wtautological-compare] > while(i == i) > ^ > 1 warning generated. > /tmp/test_clang $ > > This is not what I would expect, since this is wrong for cross compilation > in > almost any case. This can be somehow bypassed using -nostdinc option but > then > I have to manually add the .../lib/clang/3.8.0/include. What would be the > best > way to solve this? > > Another thing I noticed occurs when using the -sysroot option. clang then > tries to use $sysroot/usr/include. In my oppinion it should use > $sysroot/include instead. > > Kind regards, > Andreas > > > > ___ > cfe-users mailing list > cfe-users@lists.llvm.org > http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-users > > ___ cfe-users mailing list cfe-users@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-users
Re: [cfe-users] Anyway to prevent this code from compiling?
Try using initialization list syntax. That way the parser won't think you
are declaring a function.
OELock lock{mutex};
On Mon, Feb 29, 2016 at 12:02 PM, Brian Cole via cfe-users <
cfe-users@lists.llvm.org> wrote:
> Since switching over to clang C++11 on OS X, we had this weird C++ oddity
> surface while writing some new code. The problem is that ‘mutex’ is no
> longer a variable, it is a class type that can be interpreted as a function
> argument. That is, the following line of code can be interpreted as a
> function declaration now:
>
> OELock lock(mutex);
>
> Instead of a scoped lock acquisition as has been convention for some time
> now. The full code to recreate the subtle bug is as follows:
>
> #include
>
> using namespace std;
>
> struct OEMutex
> {
> void Acquire() {}
> void Release() {}
> };
>
> static OEMutex _mutex;
>
> class OELock
> {
> OEMutex &_mutex;
> OELock();
> OELock(const OELock&);
> OELock& operator=(const OELock&);
>
> public:
> OELock(OEMutex &mutex) : _mutex(mutex) { _mutex.Acquire(); }
> ~OELock() { _mutex.Release(); }
> };
>
> int main()
> {
> OELock lock(mutex);
> }
>
> Ideally, we would like the compilation to fail and tell the user the
> ‘mutex’ variable can not be found. Any clever C++ trick to do that? We’ve
> tried declaring the move constructors of OELock to be private, but it still
> compiles (maybe that’s SFINAE?).
>
> Thanks,
> Brian
>
>
> ___
> cfe-users mailing list
> cfe-users@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-users
>
>
___
cfe-users mailing list
cfe-users@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-users
Re: [cfe-users] Anyway to prevent this code from compiling?
you could try adding an extra set of parentheses, but you won't get as good
an error message.
OELock lock((mutex));
On Mon, Feb 29, 2016 at 1:15 PM, Brian Cole wrote:
> Was hoping for something that would be C++03 compatible as well since we
> still have C++03 compilers to target as well.
>
> From: don hinton
> Date: Monday, February 29, 2016 at 10:38 AM
> To: Brian L Cole
> Cc: "cfe-users@lists.llvm.org"
> Subject: Re: [cfe-users] Anyway to prevent this code from compiling?
>
> Try using initialization list syntax. That way the parser won't think you
> are declaring a function.
>
> OELock lock{mutex};
>
>
>
> On Mon, Feb 29, 2016 at 12:02 PM, Brian Cole via cfe-users <
> cfe-users@lists.llvm.org> wrote:
>
>> Since switching over to clang C++11 on OS X, we had this weird C++ oddity
>> surface while writing some new code. The problem is that ‘mutex’ is no
>> longer a variable, it is a class type that can be interpreted as a function
>> argument. That is, the following line of code can be interpreted as a
>> function declaration now:
>>
>> OELock lock(mutex);
>>
>> Instead of a scoped lock acquisition as has been convention for some time
>> now. The full code to recreate the subtle bug is as follows:
>>
>> #include
>>
>> using namespace std;
>>
>> struct OEMutex
>> {
>> void Acquire() {}
>> void Release() {}
>> };
>>
>> static OEMutex _mutex;
>>
>> class OELock
>> {
>> OEMutex &_mutex;
>> OELock();
>> OELock(const OELock&);
>> OELock& operator=(const OELock&);
>>
>> public:
>> OELock(OEMutex &mutex) : _mutex(mutex) { _mutex.Acquire(); }
>> ~OELock() { _mutex.Release(); }
>> };
>>
>> int main()
>> {
>> OELock lock(mutex);
>> }
>>
>> Ideally, we would like the compilation to fail and tell the user the
>> ‘mutex’ variable can not be found. Any clever C++ trick to do that? We’ve
>> tried declaring the move constructors of OELock to be private, but it still
>> compiles (maybe that’s SFINAE?).
>>
>> Thanks,
>> Brian
>>
>>
>> ___
>> cfe-users mailing list
>> cfe-users@lists.llvm.org
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-users
>>
>>
>
___
cfe-users mailing list
cfe-users@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-users
Re: [cfe-users] Anyway to prevent this code from compiling?
Or use initialization list with assignment:
OELock lock = {mutex};
On Mon, Feb 29, 2016 at 1:22 PM, don hinton wrote:
> you could try adding an extra set of parentheses, but you won't get as
> good an error message.
>
> OELock lock((mutex));
>
> On Mon, Feb 29, 2016 at 1:15 PM, Brian Cole wrote:
>
>> Was hoping for something that would be C++03 compatible as well since we
>> still have C++03 compilers to target as well.
>>
>> From: don hinton
>> Date: Monday, February 29, 2016 at 10:38 AM
>> To: Brian L Cole
>> Cc: "cfe-users@lists.llvm.org"
>> Subject: Re: [cfe-users] Anyway to prevent this code from compiling?
>>
>> Try using initialization list syntax. That way the parser won't think
>> you are declaring a function.
>>
>> OELock lock{mutex};
>>
>>
>>
>> On Mon, Feb 29, 2016 at 12:02 PM, Brian Cole via cfe-users <
>> cfe-users@lists.llvm.org> wrote:
>>
>>> Since switching over to clang C++11 on OS X, we had this weird C++
>>> oddity surface while writing some new code. The problem is that ‘mutex’ is
>>> no longer a variable, it is a class type that can be interpreted as a
>>> function argument. That is, the following line of code can be interpreted
>>> as a function declaration now:
>>>
>>> OELock lock(mutex);
>>>
>>> Instead of a scoped lock acquisition as has been convention for some
>>> time now. The full code to recreate the subtle bug is as follows:
>>>
>>> #include
>>>
>>> using namespace std;
>>>
>>> struct OEMutex
>>> {
>>> void Acquire() {}
>>> void Release() {}
>>> };
>>>
>>> static OEMutex _mutex;
>>>
>>> class OELock
>>> {
>>> OEMutex &_mutex;
>>> OELock();
>>> OELock(const OELock&);
>>> OELock& operator=(const OELock&);
>>>
>>> public:
>>> OELock(OEMutex &mutex) : _mutex(mutex) { _mutex.Acquire(); }
>>> ~OELock() { _mutex.Release(); }
>>> };
>>>
>>> int main()
>>> {
>>> OELock lock(mutex);
>>> }
>>>
>>> Ideally, we would like the compilation to fail and tell the user the
>>> ‘mutex’ variable can not be found. Any clever C++ trick to do that? We’ve
>>> tried declaring the move constructors of OELock to be private, but it still
>>> compiles (maybe that’s SFINAE?).
>>>
>>> Thanks,
>>> Brian
>>>
>>>
>>> ___
>>> cfe-users mailing list
>>> cfe-users@lists.llvm.org
>>> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-users
>>>
>>>
>>
>
___
cfe-users mailing list
cfe-users@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-users
Re: [cfe-users] Anyway to prevent this code from compiling?
Yes, get ride of using namespace std.
The problem is the parsing. Since mutex is a type, OELock lock(mutex) is
function declaration, i.e., returns an OELock and takes a mutex as a
parameter.
Could you use factory function instead?
lass OELock
{
OEMutex &_mutex;
OELock();
//OELock(const OELock&); // is this a problem for you???
OELock& operator=(const OELock&);
OELock(OEMutex &_mutex) : _mutex(_mutex) { _mutex.Acquire(); }
public:
static OELock makeLock(OEMutex &mutex) { return OELock(mutex);}
~OELock() { _mutex.Release(); }
};
OELock lock(mutex);
int main()
{
OELock lock = OELock::makeLock(mutex);
}
On Mon, Feb 29, 2016 at 1:28 PM, Brian Cole wrote:
> Anything that can be added to the OELock class to make it uncompilable in
> that context? Getting users to change how they initialize a scoped lock
> won’t be easy.
>
> A “just as easy” solution is to remove the ‘using namespace std’. I guess
> this is why Google banned ‘using namespace foo;’ in their style guide:
> https://google.github.io/styleguide/cppguide.html#Namespaces
>
> From: don hinton
> Date: Monday, February 29, 2016 at 11:22 AM
>
> To: Brian L Cole
> Cc: "cfe-users@lists.llvm.org"
> Subject: Re: [cfe-users] Anyway to prevent this code from compiling?
>
> you could try adding an extra set of parentheses, but you won't get as
> good an error message.
>
> OELock lock((mutex));
>
> On Mon, Feb 29, 2016 at 1:15 PM, Brian Cole wrote:
>
>> Was hoping for something that would be C++03 compatible as well since we
>> still have C++03 compilers to target as well.
>>
>> From: don hinton
>> Date: Monday, February 29, 2016 at 10:38 AM
>> To: Brian L Cole
>> Cc: "cfe-users@lists.llvm.org"
>> Subject: Re: [cfe-users] Anyway to prevent this code from compiling?
>>
>> Try using initialization list syntax. That way the parser won't think
>> you are declaring a function.
>>
>> OELock lock{mutex};
>>
>>
>>
>> On Mon, Feb 29, 2016 at 12:02 PM, Brian Cole via cfe-users <
>> cfe-users@lists.llvm.org> wrote:
>>
>>> Since switching over to clang C++11 on OS X, we had this weird C++
>>> oddity surface while writing some new code. The problem is that ‘mutex’ is
>>> no longer a variable, it is a class type that can be interpreted as a
>>> function argument. That is, the following line of code can be interpreted
>>> as a function declaration now:
>>>
>>> OELock lock(mutex);
>>>
>>> Instead of a scoped lock acquisition as has been convention for some
>>> time now. The full code to recreate the subtle bug is as follows:
>>>
>>> #include
>>>
>>> using namespace std;
>>>
>>> struct OEMutex
>>> {
>>> void Acquire() {}
>>> void Release() {}
>>> };
>>>
>>> static OEMutex _mutex;
>>>
>>> class OELock
>>> {
>>> OEMutex &_mutex;
>>> OELock();
>>> OELock(const OELock&);
>>> OELock& operator=(const OELock&);
>>>
>>> public:
>>> OELock(OEMutex &mutex) : _mutex(mutex) { _mutex.Acquire(); }
>>> ~OELock() { _mutex.Release(); }
>>> };
>>>
>>> int main()
>>> {
>>> OELock lock(mutex);
>>> }
>>>
>>> Ideally, we would like the compilation to fail and tell the user the
>>> ‘mutex’ variable can not be found. Any clever C++ trick to do that? We’ve
>>> tried declaring the move constructors of OELock to be private, but it still
>>> compiles (maybe that’s SFINAE?).
>>>
>>> Thanks,
>>> Brian
>>>
>>>
>>> ___
>>> cfe-users mailing list
>>> cfe-users@lists.llvm.org
>>> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-users
>>>
>>>
>>
>
___
cfe-users mailing list
cfe-users@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-users
Re: [cfe-users] Anyway to prevent this code from compiling?
That's a good point. Since mutex is a new c++11 feature, why is it injected into the std namespace when not compiling with c++11. I looked at the mutex header, and it doesn't test current value of __cplusplus. Should it? On Mon, Feb 29, 2016 at 3:07 PM, Jim Porter via cfe-users < cfe-users@lists.llvm.org> wrote: > On 2/29/2016 12:15 PM, Brian Cole via cfe-users wrote: > >> Was hoping for something that would be C++03 compatible as well since we >> still have C++03 compilers to target as well. >> > > If you're #including , haven't you locked yourself into C++11 (or > better) anyway? In that case, you should use curly braces for your > initializer (or at least stop saying `using namespace std;`). > > For existing code where `mutex` is a global variable, you'll be fine. If > you add > > #include > using namespace std; > > to existing code, you'll get a compiler error because the name `mutex` is > now ambiguous. > > If you wanted to warn about this in *all* cases, you'd need an additional > warning to detect function declarations in local scope, since that's what > C++ would treat this as. Clang doesn't have such a warning, but perhaps you > could convince someone to add it. > > - Jim > > > > ___ > cfe-users mailing list > cfe-users@lists.llvm.org > http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-users > ___ cfe-users mailing list cfe-users@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-users
Re: [cfe-users] Anyway to prevent this code from compiling?
Just looked online and stdlibc++ has this at the top the mutex header: https://gcc.gnu.org/onlinedocs/gcc-4.9.3/libstdc++/api/a01070_source.html #if __cplusplus < 201103L # include #else Shouldn't we perform the same sort of check? On Tue, Mar 1, 2016 at 8:57 AM, don hinton wrote: > That's a good point. Since mutex is a new c++11 feature, why is it > injected into the std namespace when not compiling with c++11. I looked at > the mutex header, and it doesn't test current value of __cplusplus. > > Should it? > > On Mon, Feb 29, 2016 at 3:07 PM, Jim Porter via cfe-users < > cfe-users@lists.llvm.org> wrote: > >> On 2/29/2016 12:15 PM, Brian Cole via cfe-users wrote: >> >>> Was hoping for something that would be C++03 compatible as well since we >>> still have C++03 compilers to target as well. >>> >> >> If you're #including , haven't you locked yourself into C++11 (or >> better) anyway? In that case, you should use curly braces for your >> initializer (or at least stop saying `using namespace std;`). >> >> For existing code where `mutex` is a global variable, you'll be fine. If >> you add >> >> #include >> using namespace std; >> >> to existing code, you'll get a compiler error because the name `mutex` is >> now ambiguous. >> >> If you wanted to warn about this in *all* cases, you'd need an additional >> warning to detect function declarations in local scope, since that's what >> C++ would treat this as. Clang doesn't have such a warning, but perhaps you >> could convince someone to add it. >> >> - Jim >> >> >> >> ___ >> cfe-users mailing list >> cfe-users@lists.llvm.org >> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-users >> > > ___ cfe-users mailing list cfe-users@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-users
Re: [cfe-users] Clang 3.9 running 50% slower than 3.7
It looks like you are rerunning cmake without first removing the cache, CMakeCache.txt. Since the option () command that sets LLVM_ENABLE_ASSERTIONS didn't include FORCE, the previous cached value is preserved. Therefore, I'd recommend always removing the cache -- I actually blow away the entire directory tree -- and starting from scratch. To ensure (re)builds don't take too long, I also use ccache. Although it works great for llvm, clang, etc..., it does break the libcxx and libcxxabi tests under check-all, but I've submitted a couple trivial patches that fix that problem. hth... don On Mar 17, 2016 11:26 AM, "David Blaikie via cfe-users" < cfe-users@lists.llvm.org> wrote: > > > On Wed, Mar 16, 2016 at 3:36 PM, jps...@gmail.com > wrote: > >> >> >> On Wed, Mar 16, 2016 at 5:55 PM, David Blaikie >> wrote: >> >>> >>> >>> On Wed, Mar 16, 2016 at 2:12 PM, jps...@gmail.com >>> wrote: >>> David and all, a couple more questions. I stumbled upon http://llvm.org/docs/Packaging.html and see a few other options. For a typical clang build where I am not hacking on clang, but I do want good error messages for debugging my programs, >>> >>> Define "my programs" - are you using LLVM as a library? If so, you >>> probably want a with-asserts build for development so you get better >>> failures when you use LLVM incorrectly. If you're just using Clang as a >>> normal compiler - a build without assertions should be just fine. If you >>> hit a crash in the compiler you can still file it, and we'll run in with an >>> assertions-enabled build to investigate further, generally. >>> >> >> Just using clang (and clang tools) -- not using LLVM as a library. So, >> running without assertions seems right for my needs. >> >> >>> >>> which options are recommended [1]? It seems like I should use --disable-assertions, but I'm not sure about enable-debug-symbols and enable-optimized (which seem at odds with each other?). >>> >>> If you're using LLVM as a library, but not expecting to be able to fix >>> any bugs in it yourself, probably optimized with assertiotns and without >>> debug info should be fine. >>> >>> If you're just using clang as a compiler, release (optimized), no >>> assertions, no debug info. >>> >>> >> >> It seems that just enabling -DCMAKE_BUILD_TYPE=Release is not sufficient >> to turn off assertions as I tried that and when I run clang-tidy --version >> it says " LLVM version 3.9.0svn; Optimized build with assertions." So, I'm >> going to try --disable-assertions --enable-optimized --disable-debug-symbols >> (or the environment variable equivalents). >> >> That seem right to you? >> > > Yeah, sounds about right. > > >> It's still confusing to me that there's no CMAKE_BUILD_TYPE that enables >> these sorts of options as a bundle, but I guess that's what I get from >> compiling from source. >> > > Yeah - not sure what the right recipe is for building things the same as > the official releases. No doubt it's written down somewhere... > > >> >> Thanks >> Jim >> >> >> >> >>> [1] >>> --disable-assertions--enable-debug-symbols--enable-optimized [2] $ clang --version clang version 3.9.0 (trunk 263648) Target: x86_64-apple-darwin15.0.0 Thread model: posix InstalledDir: /Users/jim/toolchains/llvm/bin On Wed, Mar 16, 2016 at 2:05 PM, jps...@gmail.com wrote: > Got it -- thanks! > > > On Wednesday, March 16, 2016, David Blaikie > wrote: > >> >> >> On Wed, Mar 16, 2016 at 7:25 AM, jps...@gmail.com via cfe-users < >> cfe-users@lists.llvm.org> wrote: >> >>> Hi, I recently installed "Release" clang (svn r263305) from source >>> on my OSX machine, and it's compiling a 20 file C++ program about 50% >>> slower than the natively installed clang 3.7 (that came with xcode, I >>> believe, although I don't use xcode). I currently have both sets of >>> tools >>> installed and am able to switch back and forth and verify using time >>> that >>> clang 3.7 takes about 30 seconds and clang 3.9 takes about 45 seconds, >>> on >>> average (all flags, settings, etc. are the same for both). I did build >>> with >>> "Release" as the build type, although I also did set >>> DLLVM_ENABLE_ASSERTIONS=ON (could this be the problem?). >>> >> >> Yes, the build system should print a warning telling you that an >> assertions enabled build can be up to ten times slower. Performance >> comparisons/measurements of an assertions enabled compiler aren't >> something >> we really do/tune for. >> >> >>> More details below. Please let me know if you have any ideas about >>> why this newer clang would be noticable slower. >>> >>> Generally, I'm just trying to use clang as a user, not a clang >>> developer, so if you have general recommendations for how to configure >>> this, please l
Re: [cfe-users] Clang 3.9 running 50% slower than 3.7
The svn version is under heavy development, so there are no guarantees that a particular revision will even compile and/or pass the tests, much less be suitable for any particular purpose. If you need more than that, I'd suggest you stick to either apple's version, or an official release. I live on or near thr ToT, because I'm interested in submitting patches. If that wasn't the case, I wouldn't bother. Sorry, I couldn't be more helpful. On Mar 23, 2016 8:30 AM, "jps...@gmail.com" wrote: > Hi Don and David, just wanted to see if you guys had any quick thoughts on > any of this before I just resign to live with a 35% slower clang than I'm > used to (it's possible that the previous version from Xcode is much slimmed > down or otherwise very carefully tuned in some way). > > Thank you, > Jim > > On Fri, Mar 18, 2016 at 9:42 AM, jps...@gmail.com > wrote: > >> David and Don, thanks for your tips. We're making progress as the new >> clang is only about 35% slower instead of 50% slower, but not quite at >> parity yet. Here's what I did: >> >> 1. deleted everything and started over, as Don suggested (I just checked >> out the source code from scratch again) >> >> 2. configured with cmake -G "Unix Makefiles" -DCMAKE_BUILD_TYPE=Release >> -DLLVM_ENABLE_ASSERTIONS=OFF ../llvm >> >> 3. built >> >> Now I'm seeing that clang-tidy --verbose correctly says this new version >> doesn't have assertions enabled, and is optimized (for some reason >> clang-tidy shows more details than clang when passing --verbose): >> >> clang-tidy --version >> LLVM (http://llvm.org/): >> LLVM version 3.9.0svn >> Optimized build. >> Built Mar 17 2016 (16:05:27). >> Default target: x86_64-apple-darwin15.0.0 >> Host CPU: westmere >> >> However, when doing my benchmarking with the xcode version of clang >> (3.7), it's still about 35% faster than my newly compiled version: >> >> Benchmarking compiling about 20 C++ files: >> Original from xcode (3.7): 27s >> >> New from svn (3.9): 37s >> >> >> I also noticed that the new clang binary is significantly larger than the >> original one. I'm sharing this as it may provide some clues to what's going >> on. I'm happy to grep for symbols if that would also be helpful. >> >> ORIGINAL FROM XCODE (3.7): >> ls -ltah >> /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang >> -rwxr-xr-x 1 root wheel42M Sep 22 19:25 >> /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang >> >> NEW FROM SVN (3.9): >> ls -ltah /Users/jim/toolchains/llvm/bin/clang-3.9 >> -rwxr-xr-x 1 jim staff54M Mar 17 17:00 >> /Users/jim/toolchains/llvm/bin/clang-3.9 >> >> >> Anyone have any ideas on anything else to try to get my newly compiled >> clang-3.9 as fast as my system-installed clang-3.7? Are there additional >> options I should be passing to configure the cmake files, other than >> Release and turning off LLVM assertions? >> >> Thanks very much. >> >> Jim >> >> >> >> >> >> >> >> On Thu, Mar 17, 2016 at 12:19 PM, don hinton wrote: >> >>> It looks like you are rerunning cmake without first removing the cache, >>> CMakeCache.txt. Since the option () command that sets >>> LLVM_ENABLE_ASSERTIONS didn't include FORCE, the previous cached value is >>> preserved. >>> >>> Therefore, I'd recommend always removing the cache -- I actually blow >>> away the entire directory tree -- and starting from scratch. >>> >>> To ensure (re)builds don't take too long, I also use ccache. Although >>> it works great for llvm, clang, etc..., it does break the libcxx and >>> libcxxabi tests under check-all, but I've submitted a couple trivial >>> patches that fix that problem. >>> >>> hth... >>> don >>> On Mar 17, 2016 11:26 AM, "David Blaikie via cfe-users" < >>> cfe-users@lists.llvm.org> wrote: >>> On Wed, Mar 16, 2016 at 3:36 PM, jps...@gmail.com wrote: > > > On Wed, Mar 16, 2016 at 5:55 PM, David Blaikie > wrote: > >> >> >> On Wed, Mar 16, 2016 at 2:12 PM, jps...@gmail.com >> wrote: >> >>> David and all, a couple more questions. I stumbled upon >>> http://llvm.org/docs/Packaging.html and see a few other options. >>> For a typical clang build where I am not hacking on clang, but I do want >>> good error messages for debugging my programs, >>> >> >> Define "my programs" - are you using LLVM as a library? If so, you >> probably want a with-asserts build for development so you get better >> failures when you use LLVM incorrectly. If you're just using Clang as a >> normal compiler - a build without assertions should be just fine. If you >> hit a crash in the compiler you can still file it, and we'll run in with >> an >> assertions-enabled build to investigate further, generally. >> > > Just using clang (and clang tools) -- not using LLVM as a library. So, > running without assertions seems right for my needs. > >
Re: [cfe-users] Problems with linking to libLLVMSupport.a: undefined reference to symbol
The only thing odd that I noticed is that although you specifically requested libc++, the linker tried to link libstdc++ and complained about a symbol it couldn't find. The symbol looks like std::string::_Rep::destroy which would be found in the standard library, so I'd guess some sort of mis-compile. Wish I could be of more help. hth... Don On Sunday, June 5, 2016, Schlottke-Lakemper, Michael via cfe-users < cfe-users@lists.llvm.org> wrote: > *bump* > > Is there really nobody here who has a possible answer? If not, do you have > any suggestions where else I could turn to for help? While I’m not an > expert on LLVM/Clang, I’ve done my share of compiling & linking other tools > and programs, so I think that I’ve exhausted all “obvious” explanations > (without success). > > Yours > > Michael > > On 31 May 2016, at 15:14 , Michael Schlottke-Lakemper < > m.schlottke-lakem...@aia.rwth-aachen.de > > > wrote: > > Hi folks, > > When trying to link to libLLVMSuport.a in our CFD application, we get the > following error at link time: > > /usr/lib64/gcc/x86_64-suse-linux/4.9/../../../../x86_64-suse-linux/bin/ld: > /pds/opt/llvm-20160530-r271230/lib/libLLVMSupport.a(Path.cpp.o): undefined > reference to symbol '_ZNSs4_Rep10_M_destroyERKSaIcE@@GLIBCXX_3.4' > /usr/lib64/libstdc++.so.6: error adding symbols: DSO missing from command > line > > For the full command & output of ‘—verbose’ see at the end of the mail. > This is not really understandable for me, since the only thing I changed > was to switch to a newer version of clang (before we used r253770, now it > is r271230). > > Any idea what I’m doing wrong or what I could try to fix this? > > P.S.: This is the command we used to compile clang (if it matters): > cmake ../llvm-20160530-r271230-src/ > -DCMAKE_INSTALL_PREFIX=/pds/opt/llvm-20160530-r271230 > -DCMAKE_BUILD_TYPE=Release -DLLVM_ENABLE_ASSERTIONS=On > -DCMAKE_C_COMPILER=clang -DCMAKE_CXX_COMPILER=clang++ > -DCLANG_DEFAULT_CXX_STDLIB=libc++ > > P.P.S.: Here is the full command + error output: > > /pds/opt/llvm-20160530-r271230/bin/clang++ -O0 -g3 -fno-inline > -DCOMPILER_ATTRIBUTES -std=c++14 -stdlib=libc++ -Wall -Wextra -pedantic > -Wshadow -Wfloat-equal -Wcast-align -Wfloat-equal -Wdisabled-optimization > -Wformat=2 -Winvalid-pch -Winit-self -Wmissing-include-dirs > -Wredundant-decls -Wpacked -Wpointer-arith -Wstack-protector > -Wswitch-default -Wwrite-strings -Wno-type-safety -Werror -Wunused > -Wno-infinite-recursion -Wno-undefined-var-template > -L/pds/opt/llvm-20160530-r271230/lib > -Wl,-rpath,/pds/opt/openmpi/lib64:/pds/opt/PointwiseV17.0R2/linux_x86_64/plugins:/pds/opt/intel-16.0.3/lib/intel64/:/pds/opt/llvm-20160530-r271230/lib:/pds/opt/StarCD/lib:/pds/opt/torque/lib > src/CMakeFiles/zfs.dir/zfscartesiangrid_inst_fv.cpp.o > src/CMakeFiles/zfs.dir/zfscartesiangrid_inst_lb.cpp.o > src/CMakeFiles/zfs.dir/zfscartesiangrid_inst_avg.cpp.o > src/CMakeFiles/zfs.dir/zfscartesiangrid_inst_dg.cpp.o > src/CMakeFiles/zfs.dir/zfscartesiangrid_hilbert.cpp.o > src/CMakeFiles/zfs.dir/zfsgridgenpar.cpp.o > src/CMakeFiles/zfs.dir/zfsgridgencell.cpp.o > src/CMakeFiles/zfs.dir/zfsfvbndrycnd3d.cpp.o > src/CMakeFiles/zfs.dir/zfsfvblock2d.cpp.o > src/CMakeFiles/zfs.dir/zfsfvblock.cpp.o > src/CMakeFiles/zfs.dir/zfsfvblock3d.cpp.o > src/CMakeFiles/zfs.dir/zfsstrctrdbndrycnd3d.cpp.o > src/CMakeFiles/zfs.dir/zfslbmblockdxqy.cpp.o > src/CMakeFiles/zfs.dir/zfsfvparticle.cpp.o > src/CMakeFiles/zfs.dir/zfslbmbndcnddxqy.cpp.o > src/CMakeFiles/zfs.dir/zfsfvbndrycnd.cpp.o > src/CMakeFiles/zfs.dir/zfsfvbndrycnd2d.cpp.o > src/CMakeFiles/zfs.dir/zfslbmblock.cpp.o > src/CMakeFiles/zfs.dir/zfsfvmbblock3d.cpp.o > src/CMakeFiles/zfs.dir/zfsstrctrdblck3d.cpp.o > src/CMakeFiles/zfs.dir/zfsfvmbbndrycnd3d.cpp.o > src/CMakeFiles/zfs.dir/zfspostprocessingblock.cpp.o > src/CMakeFiles/zfs.dir/zfsavgblock.cpp.o > src/CMakeFiles/zfs.dir/zfslbmbndcndd2q9.cpp.o > src/CMakeFiles/zfs.dir/zfsfvmbblock2d.cpp.o > src/CMakeFiles/zfs.dir/zfsfvmbbndrycnd2d.cpp.o > src/CMakeFiles/zfs.dir/zfsgeometry3d.cpp.o > src/CMakeFiles/zfs.dir/zfsmethods.cpp.o > src/CMakeFiles/zfs.dir/zfsstrctrdblck.cpp.o > src/CMakeFiles/zfs.dir/zfsstrctrdblckwindowinfo.cpp.o > src/CMakeFiles/zfs.dir/zfslbmblockd2q9.cpp.o > src/CMakeFiles/zfs.dir/zfsfileprocessingenv.cpp.o > src/CMakeFiles/zfs.dir/zfslbminterfacedxqy.cpp.o > src/CMakeFiles/zfs.dir/zfsfvparticleellipsoid.cpp.o > src/CMakeFiles/zfs.dir/zfsapplication.cpp.o > src/CMakeFiles/zfs.dir/zfslbmbndcnd.cpp.o > src/CMakeFiles/zfs.dir/zfsfvparticlespherical.cpp.o > src/CMakeFiles/zfs.dir/zfsfvcmbstnblock3d.cpp.o > src/CMakeFiles/zfs.dir/zfsfvcmbstnblock2d.cpp.o > src/CMakeFiles/zfs.dir/zfsdgblock_inst_2d_linearscalaradv.cpp.o > src/CMakeFiles/zfs.dir/zfsdgblock_inst_3d_linearscalaradv.cpp.o > src/CMakeFiles/zfs.dir/zfsdgblock_inst_2d_acousticperturb.cpp.o > src/CMakeFiles/zfs.dir/zfsdgblock_inst_3d_acousticperturb.cpp.o > src/CMakeFiles/zfs.dir/zfsdgcell.cpp.o > src/CMakeFiles/zfs.dir/zfsdginterpolation.cpp.o > src/CMakeFiles/zf
Re: [cfe-users] Problems with linking to libLLVMSupport.a: undefined reference to symbol
Btw, did you build all you dependencies yourself, including libmpi_cxx, and link them to libc++? Otherwise, I'd bet one of them links to libstdc++. On Monday, June 6, 2016, don hinton wrote: > The only thing odd that I noticed is that although you specifically > requested libc++, the linker tried to link libstdc++ and complained about a > symbol it couldn't find. > > The symbol looks like std::string::_Rep::destroy which would be found in > the standard library, so I'd guess some sort of mis-compile. Wish I could > be of more help. > > hth... > Don > > On Sunday, June 5, 2016, Schlottke-Lakemper, Michael via cfe-users < > cfe-users@lists.llvm.org > > wrote: > >> *bump* >> >> Is there really nobody here who has a possible answer? If not, do you >> have any suggestions where else I could turn to for help? While I’m not an >> expert on LLVM/Clang, I’ve done my share of compiling & linking other tools >> and programs, so I think that I’ve exhausted all “obvious” explanations >> (without success). >> >> Yours >> >> Michael >> >> On 31 May 2016, at 15:14 , Michael Schlottke-Lakemper < >> m.schlottke-lakem...@aia.rwth-aachen.de> wrote: >> >> Hi folks, >> >> When trying to link to libLLVMSuport.a in our CFD application, we get the >> following error at link time: >> >> /usr/lib64/gcc/x86_64-suse-linux/4.9/../../../../x86_64-suse-linux/bin/ld: >> /pds/opt/llvm-20160530-r271230/lib/libLLVMSupport.a(Path.cpp.o): undefined >> reference to symbol '_ZNSs4_Rep10_M_destroyERKSaIcE@@GLIBCXX_3.4' >> /usr/lib64/libstdc++.so.6: error adding symbols: DSO missing from command >> line >> >> For the full command & output of ‘—verbose’ see at the end of the mail. >> This is not really understandable for me, since the only thing I changed >> was to switch to a newer version of clang (before we used r253770, now it >> is r271230). >> >> Any idea what I’m doing wrong or what I could try to fix this? >> >> P.S.: This is the command we used to compile clang (if it matters): >> cmake ../llvm-20160530-r271230-src/ >> -DCMAKE_INSTALL_PREFIX=/pds/opt/llvm-20160530-r271230 >> -DCMAKE_BUILD_TYPE=Release -DLLVM_ENABLE_ASSERTIONS=On >> -DCMAKE_C_COMPILER=clang -DCMAKE_CXX_COMPILER=clang++ >> -DCLANG_DEFAULT_CXX_STDLIB=libc++ >> >> P.P.S.: Here is the full command + error output: >> >> /pds/opt/llvm-20160530-r271230/bin/clang++ -O0 -g3 -fno-inline >> -DCOMPILER_ATTRIBUTES -std=c++14 -stdlib=libc++ -Wall -Wextra -pedantic >> -Wshadow -Wfloat-equal -Wcast-align -Wfloat-equal -Wdisabled-optimization >> -Wformat=2 -Winvalid-pch -Winit-self -Wmissing-include-dirs >> -Wredundant-decls -Wpacked -Wpointer-arith -Wstack-protector >> -Wswitch-default -Wwrite-strings -Wno-type-safety -Werror -Wunused >> -Wno-infinite-recursion -Wno-undefined-var-template >> -L/pds/opt/llvm-20160530-r271230/lib >> -Wl,-rpath,/pds/opt/openmpi/lib64:/pds/opt/PointwiseV17.0R2/linux_x86_64/plugins:/pds/opt/intel-16.0.3/lib/intel64/:/pds/opt/llvm-20160530-r271230/lib:/pds/opt/StarCD/lib:/pds/opt/torque/lib >> src/CMakeFiles/zfs.dir/zfscartesiangrid_inst_fv.cpp.o >> src/CMakeFiles/zfs.dir/zfscartesiangrid_inst_lb.cpp.o >> src/CMakeFiles/zfs.dir/zfscartesiangrid_inst_avg.cpp.o >> src/CMakeFiles/zfs.dir/zfscartesiangrid_inst_dg.cpp.o >> src/CMakeFiles/zfs.dir/zfscartesiangrid_hilbert.cpp.o >> src/CMakeFiles/zfs.dir/zfsgridgenpar.cpp.o >> src/CMakeFiles/zfs.dir/zfsgridgencell.cpp.o >> src/CMakeFiles/zfs.dir/zfsfvbndrycnd3d.cpp.o >> src/CMakeFiles/zfs.dir/zfsfvblock2d.cpp.o >> src/CMakeFiles/zfs.dir/zfsfvblock.cpp.o >> src/CMakeFiles/zfs.dir/zfsfvblock3d.cpp.o >> src/CMakeFiles/zfs.dir/zfsstrctrdbndrycnd3d.cpp.o >> src/CMakeFiles/zfs.dir/zfslbmblockdxqy.cpp.o >> src/CMakeFiles/zfs.dir/zfsfvparticle.cpp.o >> src/CMakeFiles/zfs.dir/zfslbmbndcnddxqy.cpp.o >> src/CMakeFiles/zfs.dir/zfsfvbndrycnd.cpp.o >> src/CMakeFiles/zfs.dir/zfsfvbndrycnd2d.cpp.o >> src/CMakeFiles/zfs.dir/zfslbmblock.cpp.o >> src/CMakeFiles/zfs.dir/zfsfvmbblock3d.cpp.o >> src/CMakeFiles/zfs.dir/zfsstrctrdblck3d.cpp.o >> src/CMakeFiles/zfs.dir/zfsfvmbbndrycnd3d.cpp.o >> src/CMakeFiles/zfs.dir/zfspostprocessingblock.cpp.o >> src/CMakeFiles/zfs.dir/zfsavgblock.cpp.o >> src/CMakeFiles/zfs.dir/zfslbmbndcndd2q9.cpp.o >> src/CMakeFiles/zfs.dir/zfsfvmbblock2d.cpp.o >> src/CMakeFiles/zfs.dir/zfsfvmbbndrycnd2d.cpp.o >> src/CMakeFiles/zfs.dir/zfsgeometry3d.cpp.o >> src/CMakeFiles/zfs.dir/zfsmethods.cpp.o >> src/CMakeFiles/zfs.dir/zfsstrctrdblck.cpp.o >> src/CMakeFiles/zfs.dir/zfsstrctrdblckwindowinfo.cpp.o >> src/CMakeFiles/zfs.dir/zfslbmblockd2q9.cpp.o >> src/CMakeFiles/zfs.dir/zfsfileprocessingenv.cpp.o >> src/CMakeFiles/zfs.dir/zfslbminterfacedxqy.cpp.o >> src/CMakeFiles/zfs.dir/zfsfvparticleellipsoid.cpp.o >> src/CMakeFiles/zfs.dir/zfsapplication.cpp.o >> src/CMakeFiles/zfs.dir/zfslbmbndcnd.cpp.o >> src/CMakeFiles/zfs.dir/zfsfvparticlespherical.cpp.o >> src/CMakeFiles/zfs.dir/zfsfvcmbstnblock3d.cpp.o >> src/CMakeFiles/zfs.dir/zfsfvcmbstnblock2d.cpp.o >> src/CMakeFiles/zfs.dir/zfsdgblock_inst_2d_linearscalaradv.cpp.o
Re: [cfe-users] Casting assertion failed
Hi Daniel: This is because Expr derives from Stmt, not the other way around, so casting a Stmt to an Expr might fail. Try using dyn_cast<> instead and test for null. hth... don On Sun, Jul 31, 2016 at 3:45 AM, Daniel Kraut via cfe-users < cfe-users@lists.llvm.org> wrote: > Hello everyone, > > I am quite desperate right now finding a bug in my application. I am using > clang API to travel through its AST a do some static analysis - just > Visitor, no changes. I am getting this: > > /usr/lib/llvm-3.8/include/llvm/Support/Casting.h:237: typename > llvm::cast_retty::ret_type llvm::cast(Y*) [with X = clang::Expr; Y = > clang::Stmt; typename llvm::cast_retty::ret_type = clang::Expr*]: > Assertion `isa(Val) && "cast() argument of incompatible type!"' > failed. > (SIGABRT) (core dumped ...) > > Some input is fine, some gets this assertion fail. Does anyone have a hint > what code could raise this assertion fail? > > I'm using g++ to compile my app, no special flags just c++11. I have Clang > version 3.8.1 binaries - libclang-dev via Synaptic on my Xubuntu and on my > CentOS I downloaded binaries from web, both gets the same assertion fail. > > Thanks everyone who tries to help, > Daniel Kraut > > ___ > cfe-users mailing list > cfe-users@lists.llvm.org > http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-users > > ___ cfe-users mailing list cfe-users@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-users
Re: [cfe-users] clang -cc1 with -c gives 'unknown argument error
To get the proper -cc1 invocation, try passing -###, e.g.,
echo "" | clang -xc++ -c - -###
hth...
don
On Fri, Mar 3, 2017 at 8:50 AM Larry Evans via cfe-users <
cfe-users@lists.llvm.org> wrote:
> According to:
>
> https://gist.github.com/masuidrive/5231110
>
> -cc1 with -c should work; however, it doesn't:
>
> --{--cut here--
>
> /home/evansl/dwnlds/llvm/3.9/prebuilt/clang+llvm-3.9.0-x86_64-linux-gnu-ubuntu-16.04/bin/clang++
> --version
> clang version 3.9.0 (tags/RELEASE_390/final)
> Target: x86_64-unknown-linux-gnu
> Thread model: posix
> InstalledDir:
>
> /home/evansl/dwnlds/llvm/3.9/prebuilt/clang+llvm-3.9.0-x86_64-linux-gnu-ubuntu-16.04/bin
> uname -a
> Linux lje-OptiPlex-9020 4.4.0-65-generic #86-Ubuntu SMP Thu Feb 23
> 17:49:58 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux
> cat test.cpp
> int main()
> {
>return 0;
> }
>
>
> /home/evansl/dwnlds/llvm/3.9/prebuilt/clang+llvm-3.9.0-x86_64-linux-gnu-ubuntu-16.04/bin/clang++
> -cc1 -c -print-stats test.cpp
> error: unknown argument: '-c'
> Makefile:31: recipe for target 'bench' failed
> make: *** [bench] Error 1
>
> Compilation exited abnormally with code 2 at Fri Mar 3 11:46:43
>
> --}--cut here--
>
> Please, what am I doing wrong?
>
> -regards,
> Larry
> ___
> cfe-users mailing list
> cfe-users@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-users
>
___
cfe-users mailing list
cfe-users@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-users
Re: [cfe-users] Problem compiling simple main.c with llvm-5.0
Looks like AVR is experimental, so you'll need to pass it via -DLLVM_EXPERIMENTAL_TARGETS_TO_BUILD="AVR" As for the correct --target, you can take a look at the logic in llvm/cmake/config.guess to get an idea on how to construct one. hth... don On Wed, Dec 13, 2017 at 2:15 AM, via cfe-users wrote: > Hi, I am new to llvm, so my first question is if this is the right > mailing list to address respective problems using that software. > > I downloaded the llvm 5.0.0 binary bundle, and I can compile simple > main.c for x64_64 host. However, when > > .../bin/clang main.c --target=avr > error: unable to create target: 'No available targets are compatible with > this triple.' > 1 error generated. > > As --help is not much help, I tried guessing around using targets > elf32-avr, avr-unknown-none, all giving the same, unspecific diagnostic > (so much for "extremely useful error and warning messages"). > > https://clang.llvm.org/docs/CrossCompilation.html > > claims: > > > On the other hand, Clang/LLVM is natively a cross-compiler, meaning > > that one set of programs can compile to all targets by setting the > > -target option. > > I checked the v5.0 sources, there are plenty of modules dealing with > AVR, so that target should be supported. No? > > So I downloaded the llvm 5.0.0 source bundle and configured for AVR: > > $ cmake -G "Unix Makefiles" -DLLVM_TARGETS_TO_BUILD="AVR" > ../../source/llvm-5.0.0.src/ > > But: > > -- Constructing LLVMBuild project information > CMake Error at CMakeLists.txt:688 (message): > The target `AVR' does not exist. > > It should be one of > > > AArch64;AMDGPU;ARM;BPF;Hexagon;Lanai;Mips;MSP430;NVPTX; > PowerPC;Sparc;SystemZ;X86;XCore > > -- Configuring incomplete, errors occurred! > See also ".../build/llvm-5-avr/CMakeFiles/CMakeOutput.log". > See also ".../build/llvm-5-avr/CMakeFiles/CMakeError.log". > > The 5.0.0 release notes have some mention of AVR > > http://releases.llvm.org/5.0.0/docs/ReleaseNotes.html#change > s-to-the-avr-target > > so I'd expect this target is supported? > > Thanks for any help. > > ___ > cfe-users mailing list > cfe-users@lists.llvm.org > http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-users > ___ cfe-users mailing list cfe-users@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-users
