similar to: A "Java Backend"

So we come back to my earlier comment: can you produce a one-file, < 100 lines that reproduce the issue? -- Mehdi > On Mar 24, 2016, at 10:16 AM, Lorenzo Laneve <lore97drk at icloud.com> wrote: > > Those lines of code are in a function that is called before calling the moduleToObjectFile() function > > On Mar 24, 2016, at 6:07 PM, Mehdi Amini <mehdi.amini at

You may want to try adding this code (copy/pasted from llc.cpp): // Initialize targets first, so that --version shows registered targets. InitializeAllTargets(); InitializeAllTargetMCs(); InitializeAllAsmPrinters(); InitializeAllAsmParsers(); // Initialize codegen and IR passes used by llc so that the -print-after, // -print-before, and -stop-after options work. PassRegistry

I’m using LLVM 3.8.0, and no, it’s the precompiled version That’s why it doesn’t give me enough info for debug > On 24 Mar 2016, at 1:53 AM, Mehdi Amini <mehdi.amini at apple.com> wrote: > > This code path is not likely to crash usually. Did you build LLVM yourself? Which version are you using and can you reduce the test case to be "minimal" so that someone can

Passes all need to be initialized before they are added into a pass manager. Are you calling TargetLibraryInfoWrapperPass::initializePass anywhere? -Chris > On Mar 24, 2016, at 10:41 AM, Lorenzo Laneve via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > The problems happens because PMTopLevelManager::findAnalysisPassInfo(AnalysisID AID) returns nullptr in

Those lines of code are in a function that is called before calling the moduleToObjectFile() function > On Mar 24, 2016, at 6:07 PM, Mehdi Amini <mehdi.amini at apple.com> wrote: > > You may want to try adding this code (copy/pasted from llc.cpp): > > // Initialize targets first, so that --version shows registered targets. > InitializeAllTargets(); >

The problems happens because PMTopLevelManager::findAnalysisPassInfo(AnalysisID AID) returns nullptr in PMTopLevelManager::addImmutablePass(ImmutablePass *P). This because PassRegistry::getPassRegistry()->getPassInfo(AID) call in it returns nullptr as well. Should I probably register the pass I want to add with PassRegistry::registerPass(const PassInfo &PI, bool ShouldFree) ? I didn’t do it

I'd like to make my compiler independent, just like Clang. Doesn't Clang call llc and then system's ld by itself? I don't want my compiler to depend by any other program. I guess there will be a class in the llvm library that generates the object files based on the system's triple and data layout, and then call the system's ld? > On Mar 19, 2016, at 11:48 AM, Bruce

Update: Sorry my bad. I built llvm and tried it with debugging version. It was an assertion (IR/LegacyPassManager.cpp:764) saying that it expects all immutable passes to be initialized. > On Mar 24, 2016, at 2:00 AM, Lorenzo Laneve <lore97drk at icloud.com> wrote: > > I’m using LLVM 3.8.0, and no, it’s the precompiled version > That’s why it doesn’t give me enough info for

I thought about something like that but I think it's not a good idea. Like writing an AST visitor on Clang for example would be cool but it isn't open to other frontends, and I think that this is a job for LLVM. What about java-* attributes that can be put on certain IR operations to indicate structures that are needed to know about the Java Bytecode structure, or operations that should be

Adding back the "all recipients" - sorry, sending message from my phone, I forgot... Since my runtime is for a Pascal compiler, it has to "adapt" the C startup into a suitable Pascal environment. This means running the init portion of other modules as well as discarding the argc, argv arguments. So, I have a C main, which calls __PascalMain, which is the "main" for

On Sat, Mar 19, 2016 at 9:51 PM, James Molloy via llvm-dev < llvm-dev at lists.llvm.org> wrote: > Hi Lorenzo, > > Clang doesn't call llc; LLVM is compiled into Clang. Clang does call the > system linker though. > > Making your compiler generate *object* code is very simple. Making it > fixup that object code and execute it in memory (JIT style) is also simple. >

If you plan on calling C runtime library functions, you probably want to do what I did: Cheat, and make a libruntime.a (with C functions to do stuff your compiler can't do natively) and then link that using clang or gcc. https://github.com/Leporacanthicus/lacsap/blob/master/binary.cpp#L124 At some point, I plan to replace my runtime library with native Pascal code, at which point I will be

Mips2Java solves the same problem. The latest version of Mips2Java is called NestedVM and is part of the larger Vexi project. Much work has been done on NestedVM and it is quite impressive. http://wiki.vexi.org/ Still, it could use a lot of improvement. It's biggest immediate problems are: 1) It doesn't integrate well into a standard (Ant-based) Java build 2) There is no documented

On 23 May 2016, at 12:00, Lorenzo Laneve <lore97drk at icloud.com> wrote: > > This is the point, No, you are still failing to make a point. > High-level OO languages don't use malloc(), they use something else. That’s not entirely true. They need to get the memory that they provide to programs from somewhere. They may provide their own pool allocators, but they will often

Sorry, that's a pure crash I think, assertions are not triggered. Xcode doesn’t map those 2 functions to line numbers because they’re in precompiled libraries On Mar 24, 2016, at 1:44 AM, Mehdi Amini <mehdi.amini at apple.com <mailto:mehdi.amini at apple.com>> wrote: > >> On Mar 23, 2016, at 5:41 PM, Lorenzo Laneve <lore97drk at icloud.com <mailto:lore97drk at

On 23 May 2016, at 12:16, Lorenzo Laneve <lore97drk at icloud.com> wrote: > > I'm not talking about a new library instead of the libc, I'm talking about letting people create a library optimized for a specific frontend, regardless of the target. It sounded as if you were talking about a library that sits underneath such a thing. Lots of languages have their own runtime

On Mon, Mar 21, 2016 at 8:04 PM, James Molloy <james at jamesmolloy.co.uk> wrote: > > A corrupted file could cause a fatal error or SEGV. > > Uhhh, that's not particularly useful. > "Corrupted" means really corrupted, like ELF header is broken. Is this really the case? > On Mon, 21 Mar 2016 at 19:02 Rui Ueyama <ruiu at google.com> wrote: >

I'm not talking about a new library instead of the libc, I'm talking about letting people create a library optimized for a specific frontend, regardless of the target. > On May 23, 2016, at 1:06 PM, David Chisnall <David.Chisnall at cl.cam.ac.uk> wrote: > >> On 23 May 2016, at 12:00, Lorenzo Laneve <lore97drk at icloud.com> wrote: >> >> This is the

On 23 May 2016, at 10:13, Lorenzo Laneve <lore97drk at icloud.com> wrote: > > I know but maybe malloc() is a bit higher level than a hypothetical __alloc(), which may be lower-level and then faster. How? > And malloc() is contained in the libc as Matthias said and so maybe a program using malloc() even for a non-C language linking against the crt is needed. On many *NIX

At least for Linux/Unix, there's very little you can actually achieve without at least some of the libc linked into your own system. Unless you actually write your own system call interface functions - which is dependent on the processor architecture (using `int X` [or `syscall`] in x86, perhaps `trap Y` in 68K, `swi` on ARM, etc) - values for X may vary depending on OS too, and ABI (different