similar to: [LLVMdev] is structtyp a firstclass typ?

Zappel-Phillip wrote: > Hello, > > I am writing an optimization pass which optimizes code based on an online > pointer analysis algorithm and need to detect pointers which are pointing to > derived types. I have not had any problem identifying pointers in general > using isa<PointerType>(...), but I can't seem to figure out how I can make > sure that the pointer is

Happy New Year all, I've just updated to the latest CVS version and cygwin port is still broken. When building full llvm: llvm[3]: Compiling crtend.c for Debug build (bytecode) llvm[3]: Compiling listend.ll for Debug build llvm[3]: Linking comp_main.bc component... assertion "(Result->isFirstClassType() || Result == Type::VoidTy || isa<OpaqueType>(Result)) && "LLVM

I got the following error in 1.5 release. As far as installation is concerned, everything went fine. llc hello.bc -o hello.bs llc((anonymous namespace)::PrintStackTrace()+0x17)[0xd435f1] llc((anonymous namespace)::SignalHandler(int)+0xbd)[0xd437ff] /lib64/tls/libc.so.6[0x3ff522e410] llc(llvm::Type::isFirstClassType() const+0x13)[0x8fc38d] llc(llvm::FunctionType::FunctionType(llvm::Type const*,

On Sun, 28 Mar 2004, Reid Spencer wrote: > The XPL compiler produced the attached OneOfEach.bc file without error > or warning from either LLVM or XPLC. However when I llvm-dis the file, I > get: > > llvm-dis: Failed value look-up for name 'entry' I'm guessing that 'entry' is a basic block? > The Bytecode Reader prints this out when it can't find the

Hello! I have tried to get the latest FirstClass Client 11.017 to work in Wine 1.3.33/34 for many weeks now but I'm now out of ideas what to do. http://bugs.winehq.org/show_bug.cgi?id=29150 Hope I did the bug report right? This is my first one here at WineHQ so please correct me if I did something wrong :-) 1st problem is that splash screen freezes and do not show the login screen. 2nd

Hi Chris, > Also note, LLVM 1.4 will be released in the next few days, so if waiting is > an option, you might choose to do so. Alright, I've got llvm and llvm-gcc from RELEASE_14 cvs and tried building it under cygwin. 1) The first problem is with llvm in SysUtils.c: int executeProgram(const char *filename, char *const argv[], char *const envp[]) { ................ execveTy

I have successfully installed and am running the win32 version of firstclass 9.106 (http://www.firstclass.com/Divisions/FAV13-0024FC95/?OpenItemURL=S047C50E4) client on wine 1.0.1 (lenny amd64). My problem occurs when the client attempts to open an html attachment: Code: err:winebrowser:get_url_from_dde Unabled to retrieve URL from string L"\"" err:winebrowser:wmain Usage:

On Tue, Jul 8, 2008 at 2:28 AM, Matthijs Kooijman <matthijs at stdin.nl> wrote: > Hi all, > > I've been discussing parameter attributes and their impact on first-class > struct parameters. Duncan and I came to the conclusion that the only attribute > that could be applied to structs currently, is the inreg attribute. However, > since there is no support anywhere for

Hi all, I've been discussing parameter attributes and their impact on first-class struct parameters. Duncan and I came to the conclusion that the only attribute that could be applied to structs currently, is the inreg attribute. However, since there is no support anywhere for that currently (transformation passes and backends?), it might be better to disallow the inreg attribute for struct

Hi, The checking about that if this is a terminator that it is at the end of the block has been applied twice (bellow). One is at Verifier::visitInstruction, and the other is at Verifier::visitTerminatorInst. Since visitInstruction is called when visiting each instruction, the checking at visitTerminatorInst seems redundant to me. Did I miss any case? void Verifier::visitInstruction(Instruction

Hi llvm, 1) The lib/VMCore/Verifier.cpp in 2.7 implements Verifier::VerifyType, which is empty in 2.6. I noticed that it does not check all types, for example, UnionTyID, OpaqueTyID, LabelTyID, MetadataTyID and etc are ignored in the 'default' branch. Does it mean we dont need to check them? Another question is: How much does Verifier.cpp check statically? Can I take it as a type checker

The XPL compiler produced the attached OneOfEach.bc file without error or warning from either LLVM or XPLC. However when I llvm-dis the file, I get: llvm-dis: Failed value look-up for name 'entry' The Bytecode Reader prints this out when it can't find the associated value for the name. Obviously I botched something in the XPL compiler but I would have thought the verified would

Hello, I am writing an optimization pass which optimizes code based on an online pointer analysis algorithm and need to detect pointers which are pointing to derived types. I have not had any problem identifying pointers in general using isa<PointerType>(...), but I can't seem to figure out how I can make sure that the pointer is pointing to a scalar value and not a function, array,

On Mar 6, 2010, at 9:13 AM, Jianzhou Zhao wrote: > Hi llvm, > > 1) The lib/VMCore/Verifier.cpp in 2.7 implements Verifier::VerifyType, > which is empty in 2.6. I noticed that it does not check all types, > for example, UnionTyID, OpaqueTyID, LabelTyID, MetadataTyID > and etc are ignored in the 'default' branch. Does it mean we dont > need to check them? They are

Jianzhou Zhao wrote: > Hi llvm, > > 1) The lib/VMCore/Verifier.cpp in 2.7 implements Verifier::VerifyType, > which is empty in 2.6. I noticed that it does not check all types, > for example, UnionTyID, OpaqueTyID, LabelTyID, MetadataTyID > and etc are ignored in the 'default' branch. Does it mean we dont > need to check them? We do need to check union. I'll add

I believe I failed to ask the question properly, I am not trying to determine whether the elements of an array are scalar type. Instead, I want to be able to iterate over the function's parameters and determine whether a pointer argument is actually an array being passed which contains scalar values, or simply a pointer with a single scalar value. In other words, I want to ignore functions

Dear Reid and Chris, I thought I should send this to the list in case anyone else is struggling to interpret bytecode files with the new docs. (1) First a bug I already mentioned to Reid. Unlike the other new module headers module 0x01 still uses the old 32-bit and 32-bit format instead of the new 5-bit and 27-bit format. Thus the first module in the file will be 0x00000001 followed by

Privet, > > Unfortunately, at the end of the process I got the following > > configure: WARNING: ***** llvm C/C++ front end was not > > found, or does not appear to be working. > Yes, Reid changed the CFE build instructions to add > "--program-prefix=llvm" to the end of the configure line, but > autoconf and Makefiles are not yet updated with that change.

Hello, I am testing the new cool LLVM python bindings that Mahadevan wrote over the past few weeks. I came across a problem in the python binding which directed me to use of 'cassert'[1] in LLVM itself. When LLVM users make a mistake in using the library's constructs they usually hit an assertion. This form of defensive programming is great for detecting errors as soon as they

The LLVM docs seem to indicate that integer types are considered primitive, however looking at the code I see `FirstDerivedTyID = IntegerTyID`, implying that integers are derived rather than primitive. Should the docs be updated? -------------- next part -------------- An HTML attachment was scrubbed... URL: