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
wro
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; howeve
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,
>
>
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 tri
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-comp
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
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
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
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@list
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 OE
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 wrot
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.
>
> F
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
> s
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-u
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 hin
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,
>
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 hinto
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.
O
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., x
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:
>
>
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,
>
> tha
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
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.
ht
23 matches
Mail list logo
