similar to: [LLVMdev] unrecognized command line option "-Wno-long-double"

Hi, On 5 Jun, 2008, at 19:12, Mike Stump wrote: > The option is no longer needed and hasn't been for quite some time. > Just remove it. So, even in gcc 4.0.1 (the current for Mac OS X), it doesn't do anything? Thanks for the reply, - Filipe Cabecinhas

On Jun 5, 2008, at 3:15 AM, Filipe Cabecinhas wrote: > LLVM-gcc can't recognize this option, don't know why, because the gcc > in Mac OS X (quite old, compared to 4.2) can recognize it. The option is no longer needed and hasn't been for quite some time. Just remove it.

Hi Filipe, > LLVM-gcc can't recognize this option, don't know why, because the gcc > in Mac OS X (quite old, compared to 4.2) can recognize it. mainline gcc-4.2 doesn't recognize this option as far as I can see. Since llvm-gcc is based on gcc-4.2, it has inherited this behaviour from it. Ciao, Duncan.

On Wed, Jan 19, 2011 at 6:00 PM, Filipe Cabecinhas <filcab at gmail.com> wrote: > Hi, > I want to extend llvm-mc to make it disassemble whole files, instead of > sequences of bytes. > Most of the work to read from a Mach-O file is already done by lldb, but > that is outside llvm's repository and not useful to llvm-mc (as far as I > know). > Is anyone working on

Hi, I want to extend llvm-mc to make it disassemble whole files, instead of sequences of bytes. Most of the work to read from a Mach-O file is already done by lldb, but that is outside llvm's repository and not useful to llvm-mc (as far as I know). Is anyone working on something similar? Is it desirable to have llvm-mc disassemble whole files? Or should I create another project for that?

On Sun, Feb 7, 2010 at 12:30 AM, Filipe Cabecinhas <filcab at gmail.com> wrote: > Hi, > > Try these scripts to build llvm and llvm-gcc. It's the ones I use and I > managed to get them to work when I saw another build script using those > CFLAGS. > > They compile llvm and stuff using only x86_64, but you can then generate > code for i386 (just use a different

Ok, I'll submit a patch to turn that into a report_fatal_error saying you can't start an abbrev with an array or blob. Thanks, Filipe F On Fri, Jan 23, 2015 at 2:12 PM, Rafael Espíndola < rafael.espindola at gmail.com> wrote: > The restriction looks reasonable: A record starts with a code. The code > can be encoded as a literal or be part of the abbreviation. > >

Hi, I am trying to build llvm-gcc from svn and I am getting a "cc1: error: unrecognized command line option "-Wno-overlength-strings"" error. I have gcc 4.1.2 and Linux 2.6.18 on 64bit. Please tell me how to fix this error. Here is the command that caused this: gcc -c -g -O2 -DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -pedantic

> > I am trying to build llvm-gcc from svn and I am getting a "cc1: error: > unrecognized command line option "-Wno-overlength-strings"" error. I have > gcc 4.1.2 and Linux 2.6.18 on 64bit. Please tell me how to fix this error. > llvm-gcc is kind of end-of-life these days (ie: you should probably be using clang or dragonegg instead) but it looks like you're

On Wed, Apr 20, 2016 at 1:42 PM, Renato Golin via llvm-dev <llvm-dev at lists.llvm.org> wrote: > On 20 April 2016 at 13:18, Yury Gribov <y.gribov at samsung.com> wrote: >> Not when dead store happens in an external DSO where compiler can't detect >> it (same applies for single references). > > Do you mean the ones between the DSO and the instrumented code? >

Hi all! Fuzzing llvm's bitcode reader, I found a problem where the reader assumes that the first field in an abbreviation will not be an array or a blob (and asserts otherwise). I don't know if this is expected (but not documented) or not. The documentation, to me, reads like it doesn't disallow it, but we might be assuming all abreviations start with a full record, which would make

On Tue, Apr 19, 2016 at 1:18 PM, Filipe Cabecinhas <filcab at gmail.com> wrote: > Thanks for proposing this. It seems like it might be an interesting > tool for us too. But this proposal seems a bit hand-wavy, and I think > it's missing some crucial info before we start heading this way. > > At least for the tools you are currently starting to implement, it > would be

+1 On Wed, May 4, 2016 at 3:10 AM, Filipe Cabecinhas via llvm-dev < llvm-dev at lists.llvm.org> wrote: > Hi, > > On Wed, May 4, 2016 at 9:35 AM, Ronan KERYELL via llvm-dev > <llvm-dev at lists.llvm.org> wrote: > >>>>>> On Tue, 3 May 2016 16:36:01 -0400, Rafael Espíndola via llvm-dev < > llvm-dev at lists.llvm.org> said: > > > >

Hi Michael, >Interesting approach but how do you handle more complex offsets, e.g., when the pointer is part of an aggregate? Only one offset does not seem enough to handle generic cases. Yes, correct, this a little bit changed example is not working. #include <x86intrin.h> __m256d vsht_d4_fold(const double* ptr, unsigned long long i) { __m256d foo = (__m256d){ ptr[i], ptr[i+1],

Indeed. But the problem here is that Dinar is trying to keep information after a load/store is removed by instcombine For example: v4sf v = {p[0], p[1], p[2], p[3]}; v4sf v2 = shuffle(v, 0, 0, 2, 2); Some pass comes in and removes the p[3] and p[1]. Now you have smaller code, but lost the ability to use a vector load for all those values + shuffle. The code got scalarized because we lost the

The usual advice I provide people is "see what Clang does with an equivalent C construct" On Wed, May 4, 2016 at 12:18 PM, Stanislav Manilov < stanislav.manilov at gmail.com> wrote: > Hi, > > There is another benefit to keeping the CppBackend: it's great for > learning how to use the IR and the C++ API in particular, as can be seen > from this SO Q&A: >

Filipe Cabecinhas wrote: > Just a thought... How are you going to port llvm so it doesn't use libc? > Valgrind uses the same resources as the running program, so it can't use > the system libc's malloc nor any other functions so it doesn't get > "confused". I think you could to put LLVM into a different process. >> I think I'm the one who put

On Tuesday, June 26, 2012 at 5:43 PM, dag at cray.com wrote: > <dag at cray.com (mailto:dag at cray.com)> writes: > > > > - API instability is the exact same problem as code review latency -- > > > the API is no more stable, you're just deferring work. > > > > > > > > Yes, none of these things go away. That's not the point. The

On Wed, May 4, 2016 at 3:10 PM, Stanislav Manilov < stanislav.manilov at gmail.com> wrote: > As in "look at the source of clang" or as in "look at the -S -emit-llvm" > output? If you mean the former, then would that be easy for someone who > hasn't seen the clang source before? > Generally the latter - then potentially set some breakpoints & look at

Hi Michael, >I have a case where InstCombine removes a store and your approach would be >valuable for me if the entire access to an aggregate could be restored. Yes, no problem and we could add the aggregate pointer to this new intrinsic and in my particular case I should ignore it, but I am looking now at "speculation_marker" metadata and I am still not sure how to implement it