similar to: Why StringRef is not a ArrayRef<char>

I'm have a [PATCH] isDereferenceablePointer: look through gc.relocates and I want to know how to test this patch. So far, I've found one candiate: speculative execution in SimplifyCFG (test/Transforms/SimplifyCFG/SpeculativeExec.ll). However, it's somewhat involved to show that SimplifyCFG does kick in for gc.relocate. Is there a better way to directly test it? Signed-off-by:

On Fri, May 22, 2015 at 4:14 PM, Keno Fischer <kfischer at college.harvard.edu> wrote: > This might be related to GOT relocations. I rewrote that part of > RuntimeDyldELFbecause I was seeing this issue. Have you tried trunk? > I didn't notice that you were running 3.5 the first time I read this. Keno's diagnosis is very likely to be correct. You should try trunk if

Eli Friedman wrote: > On Thu, Jul 28, 2016 at 6:13 PM, Ramkumar Ramachandra via llvm-dev > <llvm-dev at lists.llvm.org> wrote: >> We were just debugging a sporadic crash the other day, when we noticed >> that RIP-relative addressing was being used in a JumpTable, even when >> code and data were well over 4G apart. This is confusing, because we >> picked

So it appears that we get about half the crashes with the large code model. The rest are crashing in the same way. It could either mean that large code model still takes that crashing codepath and that the number of crashes only went down by chance, or that in one place in the flow, large code model is not matched to mean ELF::R_X86_64_PC64. I'm digging into this issue further, but any hints

Hi Dale, I don't think that Keno's rewrite is applicable for a bug fix release. We have, in the last year, moved to having some dot releases for our older releases, but these are definitely bug fix only and low risk as we don't want to break anything new. The release documentation is located here: http://llvm.org/docs/HowToReleaseLLVM.html for future reference. There's no

Provide a full-fledged example of working variable arguments on X86_64, since it's easily the most popular platform. Cc: Reid Kleckner <rnk at google.com> Signed-off-by: Ramkumar Ramachandra <artagnon at gmail.com> --- docs/LangRef.rst | 44 ++++++++++++++++++++++++++++++-------------- 1 file changed, 30 insertions(+), 14 deletions(-) diff --git a/docs/LangRef.rst

Hi Dmitri, Dmitri Gribenko wrote: > On Tue, Nov 13, 2012 at 6:02 PM, Ramkumar Ramachandra > <artagnon at gmail.com> wrote: >> Add several .gitignore rules to various directories to ensure a clean >> worktree after a default build. > > Hi, > > These gitignore lists require maintenance. Is is possible to express > the same set of filenames as patterns like

Hi, We are seeing sporadic crashes since we migrated to MCJIT on Win64. The same tests pass without issues on Mac64 and Linux64. The issue is this assertion failure in RuntimeDyldELF.c: RealOffset <= INT32_MAX && RealOffset >= INT32_MIN I haven't managed to successfully catch the failure in Visual to try and debug it. Any tips on how to make progress? Oh, and we're on

Philip Reames wrote: > T.M.K., there's no direct way to test it. There is. See the 'unittests/' directory which contains the C++ unit tests. See unittests/IR/UserTest.cpp for an example that builds up IR from a .ll-in-a-C-string then queries C++ API operations on it. Nick You have to construct a > transformation which happens with the information you added and not >

On Fri, Jul 29, 2016 at 9:57 AM, Ramkumar Ramachandra <artagnon at gmail.com> wrote: > Eli Friedman wrote: > > On Thu, Jul 28, 2016 at 6:13 PM, Ramkumar Ramachandra via llvm-dev > > <llvm-dev at lists.llvm.org> wrote: > >> We were just debugging a sporadic crash the other day, when we noticed > >> that RIP-relative addressing was being used in a

Hi, We were just debugging a sporadic crash the other day, when we noticed that RIP-relative addressing was being used in a JumpTable, even when code and data were well over 4G apart. This is confusing, because we picked CodeModel::Large, and expected this to be taken care of. Isn't that what gcc would do given a Large CodeModel? The default Relocation Model, Reloc::Default, folds into

On Wed, Jul 10, 2013 at 12:29 PM, Ramkumar Ramachandra <artagnon at gmail.com> wrote: > The instructions btr and bts are perfectly valid, and have existed since > Intel 386. GNU as supports them fine. Unfortunately, LLVM does not > support them, and barfs with: > > error: ambiguous instructions require an explicit suffix > > Fix this problem by disambiguating it

Hi, According to the GNU as documentation [1], .cfi_startproc simple is a valid directive. Unfortunately, LLVM complains with: error: invalid instruction mnemonic 'simple' I happened to notice it while attempting to compile linux.git with clang: see arch/x86/ia32/ia32entry.S:75. [1]: http://sourceware.org/binutils/docs-2.22/as/Pseudo-Ops.html#Pseudo-Ops Thanks.

Hi, I happened to notice that linux.git uses plenty of btr and bts instructions (not btrl, btrw, btsl, btsw). For examples, see arch/x86/include/asm/bitops.h. LLVM barfs on these due to ambiguity, while GNU as is fine with them. Surely, there must be architectures where the w/l variant is unavailable? LLVM must support those architectures, no? Thanks.

Hi, These warnings are included by default with -Wall in GCC 4.6 [1], and LLVM should support them instead of throwing -Wunknown-warning-option. [1]: http://gcc.gnu.org/gcc-4.6/porting_to.html Thanks.

Hi, When I pulled the latest changes, I found that --enable-optimized was ON by default, contrary to old behavior and documentation. I have to do a ./configure --disable-optimized to get the usual Debug+Asserts build. Is this an intentional change? Ram

----- Original Message ----- > From: "Paweł Bylica" <chfast at gmail.com> > To: "LLVMdev" <llvmdev at cs.uiuc.edu> > Sent: Friday, May 22, 2015 8:45:11 AM > Subject: Re: [LLVMdev] Problems with instruction scheduling > > > > Any comments? Not in particular, but I think we're pretty close to applying a rewrite by Jonas Paulsson

Hi, I have what appears to be an alignment/struct padding bug. An i64 is not correctly aligned to the 8-byte boundary, and this results in a mismatched struct size between C and LLVM. We are currently running 3.8, and did not see this bug in 3.5. Please advise. Ram -- %int128m_T = type { [2 x i64] } %cint32_T = type { i32, i32 } %creal_T = type { double, double } %struct0_T = type { float,

Jim Grosbach wrote: > No. The above rule is absolutely the wrong thing to do, as has been > previously noted. I don't give a shit about whether you think it is "absolutely wrong" or not; I did what hpa and the Intel manual outlined. If you have some _reason_ not to do that, bring it up. I reported four bugs a few days ago, and the community has shown ZERO (if not NEGATIVE)

----- Original Message ----- > From: "Paweł Bylica" <chfast at gmail.com> > To: "Hal Finkel" <hfinkel at anl.gov> > Cc: "LLVMdev" <llvmdev at cs.uiuc.edu>, "Jonas Paulsson" <jonas.paulsson at ericsson.com> > Sent: Friday, May 22, 2015 9:19:14 AM > Subject: Re: [LLVMdev] Problems with instruction scheduling > >