similar to: [LLVMdev] Internal compiler error in SelectionDAGBuild.cpp

Bug #4521 has been filed. traps.c has been also attached. Thanks, Won On Wed, Jul 8, 2009 at 1:38 PM, Bob Wilson <bob.wilson at apple.com> wrote: > > On Jul 8, 2009, at 11:16 AM, Won J Jeon wrote: > > Hello, > > While I was trying to cross-compile Linux OMAP kernel with llvm, I have the > following error message. > > CC arch/arm/kernel/traps.o >

On Jul 8, 2009, at 11:16 AM, Won J Jeon wrote: > Hello, > > While I was trying to cross-compile Linux OMAP kernel with llvm, I > have the following error message. > > CC arch/arm/kernel/traps.o > cc1: /home/wonjeon/llvm/lib/CodeGen/SelectionDAG/ > SelectionDAGBuild.cpp:5388: void > llvm::SelectionDAGLowering::visitInlineAsm(llvm::CallSite): >

Thanks for the bug report. The attached file isn't helpful for reproducing the problem. I don't have all the header files that are included, so I can't just try to run it through my version of llvm-gcc and see what happens. At a minimum, please attach the preprocessed source file along with the complete llvm-gcc command line that you used to compile it. That would

traps.i has been attached. I used 'make CROSS_COMPILE=llvm-arm-' to compile the kernel with default configurations provided by kernel package If you need more information, please let me know. Thanks, Won On Wed, Jul 8, 2009 at 3:00 PM, Bob Wilson <bob.wilson at apple.com> wrote: > Thanks for the bug report. The attached file isn't helpful for > reproducing the problem.

All, The following IR is causing the assert: \begin{ll} ; ModuleID = 'x.bc' target datalayout = "e-p:64:64:64-i1:8:8-i8:8:8-i16:16:16-i32:32:32- i64:32:64-f32:32:32-f64:64:64-v64:64:64-v128:128:128-a0:0:64- f80:128:128" target triple = "ia64-portbld-freebsd8.0" define void @__ia64_set_fast_math() nounwind { entry: tail call void asm sideeffect "mov.m

On Jan 10, 2008, at 10:29 AM, Thomas Jablin wrote: > Hi, > > I've figured out a little more. #if defined DBX_DEBUGGING_INFO || > XCOFF_DEBUGGING_INFO guards the declaration of type_queue, however, > neither is defined on Intanium. In gt-dbxout.h type_queue's uses are > unguarded and thus are undefined on Itanium. When I compared llvm- > gcc's > gt-dbxout.h

[correction] On May 20, 2008, at 1:45 PM, Marcel Moolenaar wrote: > All, > > The following IR is causing the assert: > > \begin{ll} > ; ModuleID = 'x.bc' > target datalayout = "e-p:64:64:64-i1:8:8-i8:8:8-i16:16:16-i32:32:32- > i64:32:64-f32:32:32-f64:64:64-v64:64:64-v128:128:128-a0:0:64- > f80:128:128" > target triple =

Devang Patel wrote: > On Jan 10, 2008, at 10:29 AM, Thomas Jablin wrote: > > >> Hi, >> >> I've figured out a little more. #if defined DBX_DEBUGGING_INFO || >> XCOFF_DEBUGGING_INFO guards the declaration of type_queue, however, >> neither is defined on Intanium. In gt-dbxout.h type_queue's uses are >> unguarded and thus are undefined on

> I recently made a major reorganization of the calling-convention > lowering code which cleared away one of the major obstacles to > doing this within codegen. > > Dan So what was the obstacle, and how was it cleared? And how do you see the large struct return working in codegen? Anything you care to tell me would be welcome. I will be starting on this today or tomorrow.

On Sep 16, 2009, at 5:58 AM, Kenneth Uildriks wrote: >> I recently made a major reorganization of the calling-convention >> lowering code which cleared away one of the major obstacles to >> doing this within codegen. >> >> Dan > > So what was the obstacle, and how was it cleared? The biggest obstacle is that there used to be two different methods for lowering

Hi, I have some blocked transactions. Does anybody have some advise on how I could mend this because I am unsure where to start? I believe this broke after I issued some set auth.allow commands: # gluster volume set oem-shared auth.allow 10.54.54.57,10.54.54.160,10.54.54.161,10.54.54.213,10.54.54.214,10.22.9.73,10.22.9.74 Kind regards, Sophie [2017-06-20 13:28:24.052623] E

If you're able to reproduce the infinite loop with -O3 then you should be able to dump out the IR that causes `opt -instcombine` to infloop, unless the bug is truly esoteric (e.g. only caused by a specific use-list ordering). Maybe take a closer look at the output from `opt -print-before-all -O3`? Alternatively you can use bugpoint to minimize the IR to get a small reproducer that causes

Hi everybody, I noticed today that my libLLVM-3.9svn.so has a ~1.7MB .data.rel.ro segment - i.e. data that needs to be touched by the dynamic linker even though it's ultimately read-only, and data that cannot be shared between multiple processes using LLVM. It turns out that a solid ~1.3MB of that data is in the tablegen'd MCInstrDesc tables - there a pointers for ImplicitUses,

Hello While building LLVM, the compiler (static analysis) is giving me a warning about "if (RangeUse[0] == 0 && RangeUse[0] == 0) {". Can somebody familar with the codebase look over it, maybe this should be "if (RangeUse[0] == 0 && RangeUse[1] == 0) {", otherwise sorry for the noise. Index: F:/dev/llvm/lib/CodeGen/SelectionDAG/SelectionDAGBuild.cpp

On 09.05.2016 05:19, Benjamin Kramer wrote: > On Mon, May 9, 2016 at 5:35 AM, Nicolai Hähnle <llvm-dev at lists.llvm.org> wrote: >> Hi everybody, >> >> I noticed today that my libLLVM-3.9svn.so has a ~1.7MB .data.rel.ro segment >> - i.e. data that needs to be touched by the dynamic linker even though it's >> ultimately read-only, and data that cannot be

I tried a couple of options (-mcpu=arm1136j-s, -mcpu=arm1136jf-s, -march=armv6, ...) to let the compile know the specific ARM processor, but the same issue is still there. I tried to take a look at .s file in /tmp directory, but it's already cleaned up. Is it because I enabled the optimization option when I compiled llvm? Regards, Won On Wed, Jul 8, 2009 at 1:28 PM, Dale Johannesen <dalej

Hi Ankur, > The flags "-view-sched-dags".. described in the doc doesn't seem to work. ( > "llc -help" doesn't list it ). as far as I remember, displaying DAGs during compilation is only enabled in "debug builds" [1] of LLVM. You probably have to re-configure and re-compile LLVM to enable this feature. Best regards, Christoph [1]

Hi, I'm looking for some feedback on the changes represented in the attached patches, which I'll describe below. I'm sending this to both the LLVM and Clang list because it affects both, though the main focus here is LLVM. Basically, I've partially implemented some changes for choosing multiple alternative constraints largely on the LLVM side. The Clang change is to output the

2010/1/22 Garrison Venn <gvenn.cfe.dev at gmail.com> > Yes. The issue here, as you pointed out, is that your personality function > is not called at all. > Even if you did nothing in the personality function, associated with the > setup caused by > llvm.eh.selector, but returned _URC_CONTINUE_UNWIND (8), it should still be > called. > Your results are acting like either

Hi, Is there a way to use regular expressions to capture two or more words in a sentence? For example, I wish to to find all the lines that have the words "thomas", "perl", and "program", such as "thomas uses a program called perl", or "perl is a program that thomas uses", etc. I'm sure this is a very easy task, I would greatly appreciate